detecting MathML builds
David Carlisle
Can you detect client side (from eg javascript) that the page is running
in a MathML enabled mozilla. (In particular so as to something else in
a non MathML build)
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
Roger B. Sidje
>
> Can you detect client side (from eg javascript) that the page is running
> in a MathML enabled mozilla. (In particular so as to something else in
> a non MathML build)
No, it isn't possible at the moment. There was some discussion about
adding 'MathML' and similar keywords to the user-agent string. But it
didn't caught up because it seemed a dubious idea to add all the
supported features that Mozilla might ever support on the UA string...
There is bug 46029 on the customization of the UA string though:
http://bugzilla.mozilla.org/show_bug.cgi?id=46029
screenshot: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=28056
Perhaps, what could be done would be to add the recognition of MathML in
the standardized DOM function, DOMImplementation.hasFeatures(feature, version),
that Mozilla already supports. This could tell the script what features exist
in the current UA -- although there is a nuance re: DOM support vs. layout support.
http://www.w3.org/TR/2001/WD-DOM-Level-3-Core-20010605/core.html#ID-102161490
To avoid ambiguities, W3C recommends to use unique names for the feature
argument, e.g., namespace URIs. Perhaps, something like the following could
be added to the list of supported features in Mozilla MathML-enabled build?
DOMImplementation.hasFeatures("[mathml-namespace]", ""); // i.e., any version,
or something else if the user wants a precise answer.
---
RBS
Gervase Markham
> > in a MathML enabled mozilla. (In particular so as to something else in
> > a non MathML build)
>
> No, it isn't possible at the moment.
A "correct" (or possibly correct) way of doing this is adding MathML's
MIME type to the "Accept" header. The Accept header is now a pref,
network.http.accept.default , and so changing it in MathML builds to add
this should not be a problem.
Using DOMImplementation.hasFeatures might also be good; is this what that
call is actually for, or are we abusing it a bit? Also, a server can't
know if MathML is supported until after the doc is sent, which isn't very
good.
Gerv
Roger B. Sidje
>
> A "correct" (or possibly correct) way of doing this is adding MathML's
> MIME type to the "Accept" header. The Accept header is now a pref,
> network.http.accept.default , and so changing it in MathML builds to add
> this should not be a problem.
BTW, what is the JS function that client-side scripts need to use to
grab the Accept header information?
> Using DOMImplementation.hasFeatures might also be good; is this what that
> call is actually for, or are we abusing it a bit? Also, a server can't
> know if MathML is supported until after the doc is sent, which isn't very
> good.
Yep, it is in line with the spec, so long as the parties involved have
agreed on what string to use for their 'feature' argument and what that
means. There is a specific mention of MathML and SVG in the spec as examples
of why what would need to know what is there or not.
W3C has its own reserved strings, e.g., feature="Core" and version="3.0"
to tell whether or not "DOM Level 3 Core" is implemented by the UA.
There is a nuance re: MathML DOM vs. MathML Layout -- Maybe different
strings should be used to distinguih these features.
But you raised a good point with server-side detection. The Accept header
would solve that, with the side-effect of a long list all the features that
Mozilla might ever support. In this case, perhaps adding the short 'MathML'
to the UA string wasn't a bad idea after all, since the UA string and the
Accept header are always sent together.
---
RBS
David Carlisle
Thanks for the detailed response.
If some mechanism could be added it would be really useful I think in order
to make pages which degrade gracefully on non MathML browsers.
I agree that the user-agent string might get rather long by the time you
have a mathml+svg+xsl+.. build, but a call from javascript would
work just as well for what i have in mind at present.
Ian Hickson
>>> Can you detect client side (from eg javascript) that the page is running
>>> in a MathML enabled mozilla. (In particular so as to something else in
>>> a non MathML build)
>>
>> No, it isn't possible at the moment.
>
> A "correct" (or possibly correct) way of doing this is adding MathML's
> MIME type to the "Accept" header.
Isn't that "text/xml" ?
--
Ian Hickson )\ _. - ._.) fL
Netscape, Standards Compliance QA /. `- ' ( `--'
+1 650 937 6593 `- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
Gervase Markham
> > MIME type to the "Accept" header.
>
> Isn't that "text/xml" ?
AIUI, text/xml is XML which can be displayed as text if the type of the
XML is not recognised, whereas application/xml should not be displayed as
text. So it would probably be application/xml if anything. Further to
that, though, MathML should really have its own MIME type so we can
distinguish between user agents which support XML in general, and those
which support MathML in particular.
After all, the MIME type of XUL is not application/xml.
Gerv
Gervase Markham
> grab the Accept header information?
I don't think client-side scripts are permitted to access preferences
information without jumping through some security-related holes first. I
would have thought this was a case for using the DOM stuff you outline
instead.
> Yep, it is in line with the spec, so long as the parties involved have
> agreed on what string to use for their 'feature' argument and what that
> means. There is a specific mention of MathML and SVG in the spec as examples
> of why what would need to know what is there or not.
Has the MathML WG thought about this?
> But you raised a good point with server-side detection. The Accept header
> would solve that, with the side-effect of a long list all the features that
> Mozilla might ever support.
No. If you compile a build with MathML, you add application/mathml+xml to
the Accept: header. The header should only contain things that version of
Mozilla supports, not things it might support in the future.
> In this case, perhaps adding the short 'MathML'
> to the UA string wasn't a bad idea after all, since the UA string and the
> Accept header are always sent together.
You would never add "MathML" because Accept: is made up of MIME types. I
assume the MIME type for mathml is application/mathml+xml ?
Gerv
David Carlisle
> Has the MathML WG thought about this?
> I assume the MIME type for mathml is application/mathml+xml ?
That's what the recent XML mime type implies. (Although along with most
of the others it hasn't yet been registered)
Ian Hickson
>
Only because of a bug in Mozilla which means that we create the document
object before looking at the root document node. (Sorry, can't find the
number right now). The intention is to support text/xml as the MIME type
for XUL as soon as we have fixed that bug. (Just like XBL's MIME type is
text/xml, and ditto with XHTML.)
Roger B. Sidje
>
> > Yep, it is in line with the spec, so long as the parties involved have
> > agreed on what string to use for their 'feature' argument and what that
> > means. There is a specific mention of MathML and SVG in the spec as examples
> > of why what would need to know what is there or not.
>
> Has the MathML WG thought about this?
No, I don't think so. David Carlisle is co-editor of the MathML spec.
> > But you raised a good point with server-side detection. The Accept header
> > would solve that, with the side-effect of a long list all the features that
> > Mozilla might ever support.
>
> No. If you compile a build with MathML, you add application/mathml+xml to
> the Accept: header. The header should only contain things that version of
> Mozilla supports, not things it might support in the future.
Yes, but they add up as more features are supported. And when one
remembers that it is sent for every operation with the server, such
as content negotation, fetching of each image, etc...
> > In this case, perhaps adding the short 'MathML'
> > to the UA string wasn't a bad idea after all, since the UA string and the
> > Accept header are always sent together.
>
> You would never add "MathML" because Accept: is made up of MIME types. I
> assume the MIME type for mathml is application/mathml+xml ?
I mean to the UA string -- not the Accept header block itself.
---
RBS
Gervase Markham
> > the Accept: header. The header should only contain things that version of
> > Mozilla supports, not things it might support in the future.
>
> Yes, but they add up as more features are supported. And when one
> remembers that it is sent for every operation with the server, such
> as content negotation, fetching of each image, etc...
Not when we implement a system to change the Accept: header based on the
context of the resource requested. The big win here is for images, but
it's good for other stuff too.
I am official "Guardian of the Accept Header", by the way :-)
> > > In this case, perhaps adding the short 'MathML'
> > > to the UA string wasn't a bad idea after all, since the UA string and the
> > > Accept header are always sent together.
> >
> > You would never add "MathML" because Accept: is made up of MIME types. I
> > assume the MIME type for mathml is application/mathml+xml ?
>
> I mean to the UA string -- not the Accept header block itself.
Sniffing capabilities based on the UA string is icky. This is what Accept:
is _for_. Anyway, if MathML gets turned on by default, you could just say
"All things which have a Gecko date after XXXX", couldn't you?
Gerv
David Carlisle
> Anyway, if MathML gets turned on by default,
Ohh yes please
William F. Hammond
> To: gervase...@univ.ox.ac.uk
>
> > Anyway, if MathML gets turned on by default,
>
> Ohh yes please
This is so very important.
Most of my colleagues in the academic world will have no interest in
taking the extra measures required to generate XHTML+MathML content
UNLESS it gives them a means of online delivery to parties who cannot
or do not use PDF readers.
-- Bill