XSL Stylesheet for Cross Browser MathML viewing
Roger B. Sidje
> er there is an accepted bug in IE6 which means it rejects the mathml dtd
> so adding a DTD would limit the cross browser portability at the present
> time.
Hope IE6 can resolve the bug sooner rather than later so that we
don't have to continuously work around their bugs.
> > This will affect
> > the rendering in m0.9.9+ since MathML data that used to be loaded
> > at startup are now catalog driven.
>
> Oh as the output from XSLT never has any entity references, i thought
> that mozilla's special casing of the mathml dtd wouldn't be required here
> (and it seems to work on my mozilla?)
m0.9.9 is fine. It will only affect m0.9.9+ (and onwards).
[Note: there are PUA values in the Mozilla's mathml.dtd to handle
surrogate and plane-1 characters via entities given that the
MathML spec is ahead of the means at our disposal ATM, especially
w.r.t. cross-platform support.]
> Having read the bug report through, is it right that if, in the mozilla
> case, I add a link element pointing to mozilla's copy of mathml.css
> then everything would be fine? (If so, what URI can I use to find
> mozilla's installed copy?)
What about adding the DOCTYPE for Mozilla instead?
More and more things are being made catalog driven (as per
the catalog spec) to avoid doing unnecessary things upfront,
especially those things that are deemed tangential for the
majority of users.
---
RBS
David Carlisle
> Hope IE6 can resolve the bug sooner rather than later so that we
> don't have to continuously work around their bugs.
true, and they say they will, although given that there's one or two
IE6's already deployed even if the fix is released tomorrow it will
take a while before the current IE6 can be ignored by the stylesheet.
Of course you should not be too hard on MS over this bug, all software
has bugs, during the development of the stylesheet, much of the work was
involved in keeping it working in mozilla's XSLT (which in earlier
mozilla's was not a very full implementation, although the latest 0.9.9
release seems a lot more stable).
> [Note: there are PUA values in the Mozilla's mathml.dtd to handle
> surrogate and plane-1 characters via entities given that the
> MathML spec is ahead of the means at our disposal ATM, especially
> w.r.t. cross-platform support.]
see what I mean about having to work around mozilla "features":-) The
output from XSL never has entity references so the dtd, and the entity
definitions in there do not affect the output of (any) XSLT transformation.
> What about adding the DOCTYPE for Mozilla instead?
that's harder as that is specified on xsl:output so can't be
conditional, a transform either adds a doctype or it doesn't.
> More and more things are being made catalog driven (as per
> the catalog spec)
It's not clear that that is wise, given the move towards schema (usually
dtd-less) processing. I think it would be much more robust if mozilla
would for example detect the mathml namespace being declared on the
<html >document element rather than use the presence of a dtd
declaration.
Especially for results of mozilla's built in XSLT engine, note that XSLT
stylesheets have no information about the DTD specified on the input
so even an "identity transform" will remove any DTD information.
This stylesheet could add a MathML+XHTML dtd always, but what if the
input was XHTML+MathML+SVG? that would also work in an SVG enabled
mozilla, but the stylesheet would then remove any reference to SVG in
the DOCTYPE.
David
(this is getting a bit mozilla specific, maybe we should drop www-math
from the cc)
_____________________________________________________________________
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
>
> > Hope IE6 can resolve the bug sooner rather than later so that we
> > don't have to continuously work around their bugs.
>
> true, and they say they will, although given that there's one or two
> IE6's already deployed even if the fix is released tomorrow it will
> take a while before the current IE6 can be ignored by the stylesheet.
> Of course you should not be too hard on MS over this bug, all software
> has bugs
Understood. I am usually lenient (not hard) with bugs given that I know
how hard some bugs can be. (I can see that this applies to you too and to
most of us who are not just end-users.)
> > [Note: there are PUA values in the Mozilla's mathml.dtd to handle
> > surrogate and plane-1 characters via entities given that the
> > MathML spec is ahead of the means at our disposal ATM, especially
> > w.r.t. cross-platform support.]
>
> see what I mean about having to work around mozilla "features":-) The
> output from XSL never has entity references so the dtd, and the entity
> definitions in there do not affect the output of (any) XSLT transformation.
What I meant was that if the substitution uses combined or surrogate
code points, they won't be supported (now). Whereas if the substitution
uses the corresponding entities, they will be supported (now) if fonts are
installed. The internal remapping to PUA values is transparent to users.
In the future, things could be different. (But as we have seen, that
future could be several years since too many things are involved.)
> > What about adding the DOCTYPE for Mozilla instead?
>
> that's harder as that is specified on xsl:output so can't be
> conditional, a transform either adds a doctype or it doesn't.
Too bad.
> > More and more things are being made catalog driven (as per
> > the catalog spec)
>
> It's not clear that that is wise, given the move towards schema (usually
> dtd-less) processing. I think it would be much more robust if mozilla
> would for example detect the mathml namespace being declared on the
> <html >document element rather than use the presence of a dtd
> declaration.
The catalog support is *very* basic now because its main aim is to
resolve performance issues that are deemed detrimental to the majority
of users. To be precise, it is not really the catalog spec in the literal
sense, but its principles that are used. In this context "catalog" means
things done on demand based on the XML vocabularies in the current document.
(m1.0 is freezing in a week or so and with the moving specs at W3C, a
browser would never ship...)
Testing the namespaces in <html> goes along the same lines as testing the
DOCTYPE to see if it has "plus MathML" or "plus SVG", except that ATM
the DOCTYPE is/was simpler practically since it came early on (although
other unanticipated problems such as printing came along). Another aspect
of testing the DOCTYPE could be to support standalone documents/fragments
that don't necessarily have <html>. Also, it could allow to kick off other
specialized things that are not necessarily layout-only. (It should be
recalled that the interactivity & complexity of the browser framework
comes with its chords & constraints re:footprint and performance, and doing
things on demand is been championed. I remember to have added myself to the
cc:list of a performance bug about the cookie manager to see how cookies
folks will make people eat cookies on demand instead of eating them
unconditionally...).
But your point is noted, checking _both_ the DOCTYPE and the namespaces
in <html> might help to cover other edge cases in real word situations
(work-around the bug in IE6 for cross-browser support). And since <html>
is relatively early in the document, Mozilla could perhaps do a sniffing
as done for the charset.
But ideally, would all this really worth the trouble given that using the
DOCTYPE works fine? Furthermore, all XHTML documents must have a DOCTYPE
declaration per the XHTML spec. And speaking w.r.t. Mozilla, how to load
MathML entities from <html>?! There is probably a way, but since some
issues aren't that obvious, don't be hard on Mozilla too (not you
personally since I have seen that you don't hit Mozilla too hard :-)
> Especially for results of mozilla's built in XSLT engine, note that XSLT
> stylesheets have no information about the DTD specified on the input
> so even an "identity transform" will remove any DTD information.
Is this a bug in Mozilla's XSLT engine?
> This stylesheet could add a MathML+XHTML dtd always, but what if the
> input was XHTML+MathML+SVG? that would also work in an SVG enabled
> mozilla, but the stylesheet would then remove any reference to SVG in
> the DOCTYPE.
No, but the test used to see what is in the DOCTYPE could be improved --
it was mainly the principle of doing things on demand that was of
interest. If someone comes with a patch to refine things in one file,
it will be less scary for review -> super-review -> driver-approval.
> (this is getting a bit mozilla specific, maybe we should drop www-math
> from the cc)
Done.
---
RBS
David Carlisle
> Whereas if the substitution
> uses the corresponding entities, they will be supported (now)
Yes I realise that but there is no way to generate XML using entity
references using XSLT, especially in mozilla, where the result of the
XSLT transform is just a DOM that is passed to the renderer, so there is
no parsing to be done, so nowhere for entity references to go, there is
just DOM nodes with character data.
> In this context "catalog" means
> things done on demand based on the XML vocabularies in the current document.
But I think Namespaces are the right carrier for "XML Vocabularies" not
a DTD which can only ever express one fixed collection. You can't in any
natural way use the doctype to recognise a document that has
xhtml+mathmml+svg+... even if you have the ability to render all the
components.
> But ideally, would all this really worth the trouble given that using the
> DOCTYPE works fine?
It really doesn't work fine in a system like mozilla that is putting
potentially all incoming XML through an XSLT transform. An identity XSLT
transform will remove the doctype.
> And speaking w.r.t. Mozilla, how to load
> MathML entities from <html>?!
You never need to do that. If a file uses entity references it has to
have a <!DOCTYPE otherwise it is a fatal non-well formed error.
But the output from XSLT hasn't got any entity references and hasn't got
a DOCTYPE.
>> Especially for results of mozilla's built in XSLT engine, note that XSLT
>> stylesheets have no information about the DTD specified on the input
>> so even an "identity transform" will remove any DTD information.
>
>Is this a bug in Mozilla's XSLT engine?
No. It is a mandated feature of XSLT. Basically the Xpath tree model of
a document is "after the parse" so there is no node representing the DTD
and no nodes for entity references. XPath can not tell what DTD was
specified (or even if a DTD was specified at all) and XSLT can not
generate different DTDs depending on teh input (although a stylesheet
can specify a fixed DTD that is put at the top of all output whatver the
input is)
David
David Carlisle
PS
I accept that getting plane 1 characters working (anywhere) at present
is difficult, and I think mozilla having a set of entity references
pointing to PUA as a workaround is a perfectly sensible mozilla specific
action.
But I don't think that it can work to ask tools to generate mathml with
entity references rather than character data, entity references are just
so fragile, as soon as you process the document with any XML tool they
are likely to be expanded away.
The MathML spec does warn users that plane 1 support might be a while
coming, and we did make sure that every character can be reprended just
using characters below 2^16. So I think that authors/tools should
probably use the <mi mathvariant="fraktur">A</mi> form for a while until
plane 1 support is wide spread.
David Carlisle
Also,
Is it just the CSS file that is loaded on demand or other internal
stuff?
It really is no problem for me to put in whatever is required to load
the mathml css file in the output from the stylesheet if it is running
in mozilla. (So long as it is
elements/attributes/processing-instructions.
It's just adding a doctype that's hard:-)
If I can modify the stylesheet so it works with the mathml detection in
the current mozilla I'm certainly happy to do that. (What do I need to
test this by the way, would I get your new loading on demand version if
I downloaded the windows "nightly" binary? rather than the .9.9
milestone release I have now?
Steve Swanson
exist in 0.9.9.
"David Carlisle" <dav...@nag.co.uk> wrote in message
news:2002032210...@penguin.nag.co.uk...
Roger B. Sidje
>
> > In this context "catalog" means
> > things done on demand based on the XML vocabularies in the current document.
>
> But I think Namespaces are the right carrier for "XML Vocabularies" not
> a DTD which can only ever express one fixed collection. You can't in any
> natural way use the doctype to recognise a document that has
> xhtml+mathmml+svg+... even if you have the ability to render all the
> components.
Good point.
> Also,
> Is it just the CSS file that is loaded on demand or other internal
> stuff?
The DTD file too [generally speaking here, i.e., when the DOCTYPE is
present]. Optional things that might come along are likely going to be
loaded on demand in order to wholeheartedly gain acceptance (footprint
and performance are at stake). The entire Mozilla development three
was closed for several days because of that performance bug 124570 :-(
So W3C, if they haven't done it already, really need to agree on a way
to tell what is in a document -- like these good variables that are
declared on top of a program.
> It really is no problem for me to put in whatever is required to load
> the mathml css file in the output from the stylesheet if it is running
> in mozilla. (So long as it is
> elements/attributes/processing-instructions.
> It's just adding a doctype that's hard:-)
Let's try to fix the problem on Mozilla' side while it still possible.
Indeed making remote documents access a resource:// file might choke due
to the constraints that the security module imposes on such operations.
So the file would have to be kept online or something, and this will
have its other troubles.
I will open a bug on detecting MathML from the declaration of its
namespace in <html> and see how it goes. I have now realized that
my analogy with the sniffing of the charset doesn't reflect the real
problem here. Indeed, since this an "after the transform" problem,
what seems needed here is to see if the resulting transformed DOM
node of <html> has an attribute which is a declaration of the
MathML namespace. Hmm... interesting.
---
RBS
David Carlisle
> Indeed making remote documents access a resource:// file might choke due
> to the constraints
> I will open a bug on detecting MathML from the declaration of its
> namespace in <html> and see how it goes.
Thanks, as I say i'm happy to modify the stylesheet in any way I can to
help, (just so long as it's not adding a doctype:-) I've also grabbed
the current nightly build so if you want me to try anything...
Roger B. Sidje
>
> > I will open a bug on detecting MathML from the declaration of its
> > namespace in <html> and see how it goes.
Bug 132844 - "Transformed docs lack the DOCTYPE, detect the
MathML namespace within <html>"
http://bugzilla.mozilla.org/show_bug.cgi?id=132844
> Thanks, as I say i'm happy to modify the stylesheet in any way I can to
> help, (just so long as it's not adding a doctype:-) I've also grabbed
> the current nightly build so if you want me to try anything...
Not much you can do now. But if bug 132844 is not resolved in due in
time,
you could always include a link to mathml.css as a fallback.
---
RBS
Roger B. Sidje
>
> > Indeed making remote documents access a resource:// file might choke due
> > to the constraints
> I did wonder:-)
>
> > I will open a bug on detecting MathML from the declaration of its
> > namespace in <html> and see how it goes.
> Thanks, as I say i'm happy to modify the stylesheet in any way I can to
> help, (just so long as it's not adding a doctype:-) I've also grabbed
> the current nightly build so if you want me to try anything...
I have checked in a fix that will make the load on demand to continue to
work in a transparent way. So no action is needed on your part, except
to try it out with tomorrow's nightly build :-) Now, if a document has
the XHTML + MathML DOCTYPE, mathml.css is speedily loaded early on,
otherwise the first MathML element that is encountered when processing
the document will trigger the load.
Looking at your listing in http://www.w3.org/Math/XSL/, Mozilla isn't
listed on the Windows section. Likely an omission since I saw that it is listed
in your table further down at http://www.w3.org/Math/XSL/Overview-tech.html.
However the green flag for IE6 on CSS/JavaScript whilst it is red on Mozilla
may cause people who are just cruising through the page to wonder whether
CSS/JavaScript isn't supported in Mozilla. Perhaps an orange color can help
to differentiate with the fact that it means that what is needed isn't yet
implemented (on your side). I am nitpicking since it appears that the row of
IE6 is all green, but one cell... So every cell counts...
---
RBS