The mime type application/mathml+xml should be supported by Mozilla. See URL for a few pointer. It is used for instance by the MML tests on W3C: http://www.w3.org/Math/testsuite/
cc'ing Gerv. Needs to be added to the Accept: header. RFC 3236 just registeredapplication/xhtml+xml; what is the status of the RFC for this content-type?
http://www.ietf.org/rfc/rfc3236.txt?number=3236 (Januar 2002): |Status of this Memo | | This memo provides information for the Internet community. It does | not specify an Internet standard of any kind. Distribution of this | memo is unlimited. See also: http://www.w3.org/TR/MathML2/chapter7.html#N40759
A better document: The Math2 standard points to http://www.ietf.org/rfc/rfc3023.txt (Januar 2001, Category: Standards Track) 8.16 Application/mathml+xml Content-type: application/mathml+xml <?xml version="1.0" ?> MathML documents are XML documents whose content describes mathematical information, as defined by [MathML]. As a format based on XML, MathML documents SHOULD use the '+xml' suffix convention in their MIME content-type identifier. However, no content type has yet been registered for MathML and so this media type should not be used until such registration has been completed.
As I understand this, the way this should work is that you should serve the document as application/xml, and Mozilla should use XML namespaces to determine that it's MathML and act accordingly. However, I'm not sure who to check with to verify this assertion. Gerv
Gerv: your assertion is not entirely correct. If the document is pure MathML, it should be served with a MathML content type. If it uses multiple namespaces, for example XHTML plus MathML, then a generic XML content type would be fine. Nominating for 1.0. We currently support application/xhtml+xml, and image/svg+xml. Anyone who wants to test our MathML support will likely find their way to the MathML test suite at the W3C and lo and behold, we can't even _load_ half of it, let alone render it. I'm sure we render much of it okay, but an end user will not realize that. They might try a few pages, give up and lose faith in our MathML support...
Keywords: mozilla1.0, nsbeta1
OS: Linux → All
Hardware: PC → All
caillon: are you saying that the W3C test suite does not load because we do not send this type in our Accept: header? > If the document is pure MathML, > it should be served with a MathML content type. My understanding of the way Mozilla works internally is that it uses XML namespaces to work out what to do with some XML it gets, and so the standard XML content-type is fine for any sort of XML. If I'm incorrect about this, please find a hacker who wrote/understands the relevant code to tell me I'm wrong. Gerv
> caillon: are you saying that the W3C test suite does not load because we do > not send this type in our Accept: header? I did not say that. I said the test suite does not load half of the pages. Half of the suite is using application/mathml+xml and the other half uses text/html See for yourself at one of the tests which we fail to load: http://www.w3.org/Math/testsuite/Presentation/TokenElements/mi/miAtoken5.mml > My understanding of the way Mozilla works internally is that it uses XML > namespaces to work out what to do with some XML it gets, and so the standard > XML content-type is fine for any sort of XML. That is correct. *If* the document is sent as XML mime type _that we recognize_ then we use namespaces. If we don't recognize the mime type, then we won't even load the document, we'll present a download dialog, and all the namespace processing in the world won't help us. But saying that application/xml is an appropriate type for any type of XML, is like saying that text/plain is an appropriate type for any type of text document, or image/jpeg is appropriate for any image file. If you have a document which is _specifically_ MathML, and MathML _only_, then is there a reason to use a generic type, and not the specific type? The current recommendation for XHTML as I understand it is to use the specific XHTML type application/xhtml+xml and _not_ application/xml when the document is pure XHTML. We do support that. This should apply to MathML as well, and thus we should support the specific MathML type, application/mathml+xml So what I'm saying in a nutshell is that we should add application/mathml+xml to our internally supported XML mime types so that we _can_ process it and not present the user with a download dialog.
> That is correct. *If* the document is sent as XML mime type _that we recognize_ > then we use namespaces. If we don't recognize the mime type, then we won't even > load the document, we'll present a download dialog, and all the namespace > processing in the world won't help us. If this is the case, then it has _nothing_ to do with the Accept: header. That header is merely a set of suggestions to the server. What MIME types Mozilla "recognises" is different code entirely. According to choess in comment 1, this bug is about the Accept: header, and it's adding the MathML MIME type to the Accept: header that I'm resisting. If you want to add it somewhere else, it's nothing to do with me and I couldn't care less :-) Gerv
> If this is the case, then it has _nothing_ to do with the Accept: header. Correct. This needs to be handled elsewhere. Though an entry in the Accept: header would be nice if MathML is enabled to allow authors to serve MathML if accepted, and perhaps an image if not.
The growing list of MIME types that end in +xml that we will have to add to our Accept: header (including all those that we can instantly support simply by adding a few rules to ua.css) is exactly the reason I am against the proliferation of +xml MIME types. I don't see what is wrong with using text/xml and then deciding how to handle it (including which DOM to use, and whether to hand it to an external application) based on the namespace of the root element. But I guess this is not the right forum to be complaining about that.
Hixie is correct. What we should be doing is passing all "*+xml" types to Mozilla to handle. If we aren't currently doing that (and popping up a download dialog instead) then that's a bug. We should have only the basic XML types in Accept:. The problem of a site finding out whether MathML is supported or not is an orthogonal one. The best way to do this is to check for Gecko date from the date it got turned on. Gerv
That won't work for two reasons. First of all, there is no guarentee that all +xml MIME types are XML. For example, text/x-uuencoded+xml isn't XML. Secondly, you can't sniff based on Gecko date because just because there is no guarentee that any particular distribution will enable everything. For instance, my build has SVG and MathML enabled, Mozilla test builds have only MathML enabled, and an unnamed other distributor has MathML disabled in its nightly builds.
OK, so what's the Hixie Plan (TM), then? :-) Gerv
Banish the +xml MIME types, and rely on UA Capability Negotiaiton technologies that are being developed.
Right... and the plan for right now? Gerv
I plan for the long term. The short term plan is irrelevant since on the short term Mozilla has no market share.
Right... Everyone else, back in the world of this bug, let's make sure all +xml MIME types are passed to Mozilla rather than presenting a Download dialog. I'm still not sure what to do about the MathML support detection problem. I'd very much like to avoid extending Accept:, because I can see SVG queueing up to be next. Gerv
I'm serious. Content-Type sniffing is pathetic. You don't want to do it. Look at the flak IE has got from the standards community over doing exactly that. I've already given you several reasons why it won't work in this case. I do think we should pass some specific MIME types that we support over to our XML processor, application/mathml+xml being one of them. I do _not_ think we should pass other MIME types that we _don't_ support to our XML processor. If they are not using the text/xml MIME type then we have _no_ reason to assume that styling it with CSS is going to be of any help whatsoever. In fact, I can't think of a single XML vocabulary which has its own MIME type that we could handle without some explicit C++ support (this includes all the obvious types like XHTML, SVG, MathML, and XUL). If we want a short term solution, though, I don't see why we wouldn't want to add everything we support to the Accept: headers. Especially things as high profile as MathML and SVG. The text/xml MIME type with its implications of support for mixed namespace content should come first, of course, but the MathML MIME type seems like a nice clear way to indicate what we support.
> I'm serious. Content-Type sniffing is pathetic. You don't want to do it. Look > at the flak IE has got from the standards community over doing exactly that. Yer wot? IE got a lot of flak for _ignoring_ Content-Type and going on file extension or file content sniffing instead. Content-Type is the right way to determine what class of document it is, in general. > I do think we should pass some specific MIME types that we support over to our > XML processor, application/mathml+xml being one of them. I do _not_ think we > should pass other MIME types that we _don't_ support to our XML processor. If I'm sold. OK; we only need to fix the specific problem that's making us put up download dialogs for application/mathml+xml. > If we want a short term solution, though, I don't see why we wouldn't want to > add everything we support to the Accept: headers. The reason not to do this is that the Accept: header gets sent with every HTTP request and we need to make a very good case for making it any bigger, because the cost adds up on slow connections. (/me wonders why they couldn't have used "app" instead of "application"). Gerv
Our current accept header: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, video/x-mng, image/png, image/jpeg, image/gif;q=0.2, text/css, */*;q=0.1 Seems like adding application/mathml+xml and image/svg+xml is reasonable. Heck, I could even see an argument for adding our XUL MIME type. Are there any studies anywhere on the effects of an extra few hundred bytes in each GET header? I would have thought we added that much already simply from the Gecko/ and Netscape/ UA string additions, not to mention the dozens of bytes we add each time a user adds a language.
We've had this argument before in other bugs - about the XUL MIME type, certainly. Navigator 3.x put all the MIME types it supported into its Accept: header, and the result was 4k long. On a 28.8k modem, if you've just requested a page and are sending several GETs, the current few hundred bytes of header take significant time to transmit. It's important to keep a lid on this figure, and not let it creep upwards. We've already had customers (from IBM) complaining about the length. Everything's a trade-off. Having said that, we may have to put SVG and MathML in. :-( Gerv
This MUST be added before 1.0. If not this will happen: ALL MathML files will be provided with this MIME, as there's no way to prevent MSIE to use it's internal parser and it will look like Mozilla not being able to handle MathML.
Kai, I'm not exactly sure what you just said... are you saying that MSIE has MathML support? Please clarify :)
no, it doesn't, but what about Plugins? They need (at least in normal Browsers) a Plugin to get involved. So you'll need another Mime then text/xml.
There's no reason plugins for XML content can't be keyed off the root element's namespace. Indeed for mixed-content documents that's the only solution.
*** Bug 144719 has been marked as a duplicate of this bug. ***
So, the convergence from the discussion seems to have come down to: 1) support application/mathml+xml like the others (xlst/xhtml/svg) -- helpwanted... 2) close the eyes and add application/mathml+xml in the Accept: header (and xul, and svg, and xbm, and etc too?!? As comment 19 said, why din't they (also) allow app/* for something that is sent on the net so frequently -- the standards can have side-effects sometimes).
Or associated numeric codes could be supported as well (as in the case for HTTP responses), e.g., assuming 404 = text/xml, 503 = text/html, one could say "Accept: 404,503,video/x-mng,etc", and that will scale much better in the long run.
Hixie: The whole point of the "+xml" suffix to MIME types is so that applications can tell if data is XML even if they don't know about its exact type. Read Appendix A of RFC 3023. Based on the contents of RFC 3023, I think it is completely safe to assume that all registered *+xml types are XML. If there is a problem with brain damaged experimental types using +xml when they shouldn't, those types should be handled specially on a case-by-case basis.
FYI - saw this proposal to extend the content-type: http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-02.txt Example: For an XHTML document containing SVG, MathML, SMIL, and XLink content: Content-Type: application/xhtml+xml Content-features: (| (xmlns="http://www.w3.org/1998/Math/MathML") (xmlns="http://www.w3.org/2001/SMIL20/") (xmlns="http://www.w3.org/2000/svg") (xmlns="http://www.w3.org/1999/xhtml") (xmlns="http://www.w3.org/1999/xlink") )
I had missed the two references to RFC 3023 in this bug, my bad. I retract my objections to treating */*+xml as XML.
AAAAAh, it is such a pitty!! Mozilla can do MathML. But I only can use Amaya to see my web pages. This really shouldnt have happened. Some comments, to what had been written here. > That won't work for two reasons. First of all, there is no guarentee > that all +xml MIME types are XML. For example, text/x-uuencoded+xml > isn't XML. Secondly, you can't sniff based on Gecko date because just > because there is no guarentee There is a difference between Content-Type and Enconding-type. Unfortunately the mime type "application/gzip gz" has raised terrible confusion about this. There should have been something like "application/packager gz zip tgz". The existence of "application/gzip" is a *BUG* in the mime specifications. > I plan for the long term. The short term plan is irrelevant since on > the short term Mozilla has no market share. It needs to have a market niche at least (mathml, svg, proper css). My pages are now viewable without formulas by all browsers and with the formulas they can be seen with Amaya only. Amaya is taking Mozillas market niche away! I can not make my pages with xml extension! If I make my pages xml, Konqueror and Opera will not show one single character any more. I can live with only the formulas not beeing displayed. Then I can suggest to those, who want to see the formulas too, to use Mozilla or Amaya. But I can not live with Opera and Konqueror just showing nothing. As I read here, this is only, because you are trying to be clean with mime types, which is not possible anywhay. XML ist not a file format. Its a langauage, that can be embedded anywhere. To say, that Mozilla should not find out about XML through mime is note the same as saying, that Mozilla should do sniffing. If xhtml can contain MathML, Mozilla must just assume possible existence of MathML and if there is no MathML, where is the Problem? Why should I tell gcc that it will encounter template classes when parsing c++? It will parse C++ and than find out by itself. Isnt this why doctype and xmlns have been added to (x)html? Instead of mime type "application/something+otherthing" I would suggest "application/n-faculty" for short 8-)
See also bug 155730. (Your pages display in Opera & Konqueror when served as application/mathml+xml, but not text/xml? That's bizarre.)
re: comment #30 > > FYI - saw this proposal to extend the content-type: > http://www.ietf.org/internet-drafts/draft-stlaurent-feature-xmlns-02.txt Link is a moving target. Latest link at: http://www.simonstl.com/ietf/ -- Registration of xmlns Media Feature Tag.
Keywords: nsbeta1 → nsbeta1-
Important for me. I want to use: <object type="application/mathml+xml" data="formula.mml"> <img src="formula.png" alt="foo foo foo" /> </object> to display MathML for aware browsers and picture for unaware.
That won't work as you expect. (In fact, you can already do that with <object type="text/xml" data="formula.mml">.) The reason it doesn't work as you might want is because you have to specify the height & width of the <object>. Something that you cannot tell in advance with those nested formulas & user fonts. Another issue is a neat alignment w.r.t. the "baseline". In short, it had been tried (with type="text/xml") but it looked very ugly. Better not to count on that.
I've been trying to do the same as described in comment #37 (<object> tag pointing to MathML file, with fallback to rasterized equation). Using text/xml or application/xml doesn't work, since there are certain popular browsers that will happily "render" the MathML bits as a parse tree or by stripping out tags instead of falling back to the image. Using <object type="application/mathml+xml"> works in Amaya, and correctly falls back to the alternate version in MSIE, classic Netscape, iCab, etc. It also incorrectly falls back in Mozilla, which could render the MathML but doesn't recognize the MIME type. Additionally, if Moz sent it in the Accept: header as Amaya does, it would be possible to tailor pages to use inline MathML (much more reliable placement than <object>s) or images without unreliable UA sniffing (oops, this one is Gecko, but has no MathML built in...) or manual "click here for MathML version" links.
Also it should be noted that some websites such as sciencedirect.com start to send mathematical formulas as application/mathml+xml. Currently this results in Firefox downloading the file. The user must subsequently open the file in a MathML-aware viewer (such as Firefox). An example of this is this page: http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6V7D-4HSXVY7-1&_user=779890&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000043220&_version=1&_urlVersion=0&_userid=779890&md5=09d911435f20b4f81cf2ab6a540a1b97 (might not be open access). Clicking on a formula results in downloading the file. It would be a great plus if formulas could be displayed directly without additional steps.
So finally, this bug is likely to be fixed in the same way as bug 160882 and not using bug 155730 as indicated in comment 35. (see bug 155730 comment 62)
Assignee: rbs → fred.wang
Status: NEW → ASSIGNED
No longer depends on: 155730
Created attachment 416267 [details] [diff] [review] Add application/mathml+xml mime type This patch applies on top of attachment 413793 [details] [diff] [review].
Attachment #416267 - Flags: review?(bzbarsky)
Comment on attachment 416267 [details] [diff] [review] Add application/mathml+xml mime type Looks fine to me. Do you want me to push this, or can you do that yourself?
Attachment #416267 - Flags: review?(bzbarsky) → review+
(In reply to comment #44) > (From update of attachment 416267 [details] [diff] [review]) > Looks fine to me. Do you want me to push this, or can you do that yourself? No I can't, so I would appreciate if you could push it for me. Note however, that as I says in comment 42, the patch applies on top of the one for bug 530275 (I made comment on it after your review, but I've just realized that you were not cc'ed, so I guess you have not read them...)
Pushed http://hg.mozilla.org/mozilla-central/rev/41eb585e76c3 Might be nice to write a test here.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(In reply to comment #46) > Pushed http://hg.mozilla.org/mozilla-central/rev/41eb585e76c3 > Thanks! > Might be nice to write a test here. Yes, I'm going to attach one...
Created attachment 428310 [details] [diff] [review] reftest
Doesn't that reftest depend on the exact pixel sizes of "200%" fonts?
Created attachment 428422 [details] [diff] [review] reftest Yes, previous test could be incorrect if the default size was too large and make the text go outside the <object/>. Here is a simplified version, without text at all.
Comment on attachment 428422 [details] [diff] [review] reftest Can we name those mathml-type-supported instead of Bug124709? r=me with that (and ideally a changeset that has a User and commit message in it).
Attachment #428422 - Flags: review?(bzbarsky) → review+
Created attachment 429088 [details] [diff] [review] reftest
Attachment #428422 - Attachment is obsolete: true
Pushed that test as http://hg.mozilla.org/mozilla-central/rev/18d0466b9a93 Thank you again!
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.