Cannot render MathML

1 view
Skip to first unread message

Tim Smith

unread,
Jan 30, 2001, 7:54:39 PM1/30/01
to
I've downloaded the latest MathML enabled version (I tried both Linux
and Windows2000) that claim to have MathML support... but the browser
just will not display MathML.

I'm confused. Can someone help.


nospam@nospam

unread,
Feb 1, 2001, 5:28:40 AM2/1/01
to
Tim Smith wrote:


My mistake, It can only render xml files.

So this works.... http://www.mozilla.org/projects/mathml/start.xml

But MathML codes within HTML, XHTML, or w3c MML test files, do not.

Ian Hickson

unread,
Feb 1, 2001, 5:48:41 AM2/1/01
to mozilla...@mozilla.org
On Thu, 1 Feb 2001 nos...@nospam.netscape.com wrote:
>
> My mistake, [Mozilla MathML builds] can only render xml files.

>
> So this works.... http://www.mozilla.org/projects/mathml/start.xml
>
> But MathML codes within HTML, XHTML, or w3c MML test files, do not.

Nor should they, unless they are sent over the network as text/xml. Can
you point us to a URI that shows the problem?

--
Ian Hickson )\ _. - ._.) fL
Netscape, Standards Compliance QA /. `- ' ( `--'
+1 650 937 6593 `- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________


Paul Topping

unread,
Feb 1, 2001, 2:17:35 PM2/1/01
to Ian Hickson, mozilla...@mozilla.org
Ian,

This restriction, that XML can only be embedded in an XHTML document, is
pretty painful for us MathML people. It means that we can't produce a single
document that will work with Mozilla and Internet Explorer. I realize that
if Microsoft would support XHTML in IE, this would also resolve the problem,
but we can't make Microsoft do this.

I think I understand the politics behind the decision to not support XML in
HTML, I even sympathize with it. The world needs to move to XHTML - it would
make lots of things easier. That said, Mozilla already compromises this by
supporting HTML with all the hacks that both Netscape and Microsoft have
added over the years.

Is there no wiggle room on this issue within the Mozilla community? There
are lots of people in education, science, engineering, etc. hoping for
MathML support to be eventually released in the Netscape browser. These same
people have been assuming that a single page could be displayed in other
browsers as well, especially IE.

As another data point in favor of supporting XML islands in HTML within
Mozilla, let me refer you to the "XML in HTML" meeting
(http://www.w3.org/TR/NOTE-xh) that the W3C held in May,'98. Several MathML
types, myself included, were at that meeting. At one point, the Netscape and
Microsoft contingents got together in a corner of the room and hammered out
the details of how this would be handled in both their browsers in order to
get cross-platform compatibility. I know that a Netscape commitment (never
fulfilled) is certainly not a Mozilla commitment, but the existence of this
agreement is proof that XML in HTML is not just another Microsoft ploy and
others thought it was a good idea at the time.

Actually, a carefully prepared XHTML document basically does work in both IE
and Mozilla, but it has to be served up with two different MIME types.
Perhaps this restriction could be removed? Perhaps Mozilla could snoop into
a document far enough to read the DOCTYPE, and if its XHTML + MathML, fire
off the right parser even if the MIME type and extension say it should be
HTML.

Paul

----------------------------------------------------------------
Paul Topping email: pa...@dessci.com
phone: 562-433-0685
Design Science, Inc. http://www.dessci.com
"How Science Communicates"
MathType, WebEQ, MathPlayer, Equation Editor, TeXaide
----------------------------------------------------------------

William F. Hammond

unread,
Feb 1, 2001, 5:15:24 PM2/1/01
to mozilla...@mozilla.org
Paul Topping writes:

> I think I understand the politics behind the decision to not support XML in
> HTML,

You are saying that MSIE will not support the <math> tags currently
used in Mozilla test docs (which are otherwise XHTML served as text/xml)
rather than saying that MSIE is refusing to support a W3C recommendation,
right?

> Mozilla, let me refer you to the "XML in HTML" meeting
> (http://www.w3.org/TR/NOTE-xh) that the W3C held in May,'98. Several MathML
> types, myself included, were at that meeting. At one point, the Netscape and
> Microsoft contingents got together in a corner of the room and hammered out
> the details of how this would be handled in both their browsers in order to
> get cross-platform compatibility. I know that a Netscape commitment (never

Looking there it's unclear to me just what was actually agreed, and
the doc has no formal status.

> Actually, a carefully prepared XHTML document basically does work in
> both IE and Mozilla, but it has to be served up with two different
> MIME types. Perhaps this restriction could be removed? Perhaps
> Mozilla could snoop into a document far enough to read the DOCTYPE,
> and if its XHTML + MathML, fire off the right parser even if the MIME
> type and extension say it should be HTML.

Or look for something that is consciously put out for this purpose
in a text/html serving as a "meta" tag.

-- Bill


Paul Topping

unread,
Feb 1, 2001, 5:38:11 PM2/1/01
to William F. Hammond, mozilla...@mozilla.org
> William F. Hammond writes:
>
> Paul Topping writes:
>
> > I think I understand the politics behind the decision to
> not support XML in
> > HTML,
>
> You are saying that MSIE will not support the <math> tags currently
> used in Mozilla test docs (which are otherwise XHTML served
> as text/xml)
> rather than saying that MSIE is refusing to support a W3C
> recommendation,
> right?

MSIE renders an XHTML document only if it is served to it with an HTML MIME
type. It it is served as XML, it will display it as a sort of heirarchical
tree of elements. We have tried to find a way to make it display as HTML,
but to no avail. Unfortunately, Mozilla does the exact opposite: it requires
that the document be served as XML and won't display XHTML as a formatted
document if it is served as HTML. I'm not a standards expert, but it seems
like there should be more flexibility on both sides.

> > Mozilla, let me refer you to the "XML in HTML" meeting
> > (http://www.w3.org/TR/NOTE-xh) that the W3C held in
> May,'98. Several MathML
> > types, myself included, were at that meeting. At one point,
> the Netscape and
> > Microsoft contingents got together in a corner of the room
> and hammered out
> > the details of how this would be handled in both their
> browsers in order to
> > get cross-platform compatibility. I know that a Netscape
> commitment (never
>
> Looking there it's unclear to me just what was actually agreed, and
> the doc has no formal status.

Perhaps I should have clarified. Both parties agreed on the mechanism to be
used to delimit an XML "island" within an HTML doc. The obvious implication
is that this mechanism would be implemented in some future version of each
browser. However, it was noted that there was no promise as to which version
of each browser such functionality would be introduced.

> > Actually, a carefully prepared XHTML document basically does work in
> > both IE and Mozilla, but it has to be served up with two different
> > MIME types. Perhaps this restriction could be removed? Perhaps
> > Mozilla could snoop into a document far enough to read the DOCTYPE,
> > and if its XHTML + MathML, fire off the right parser even
> if the MIME
> > type and extension say it should be HTML.
>
> Or look for something that is consciously put out for this purpose
> in a text/html serving as a "meta" tag.

Sure. It seems that the MIME type and the DOCTYPE are somewhat redundant but
I would think that if the MIME type says "HTML" and the DOCTYPE says
"XHTML", the browser should display the document formatted as XHTML.

Ian Hickson

unread,
Feb 1, 2001, 7:26:08 PM2/1/01
to Paul Topping, mozilla...@mozilla.org
On Thu, 1 Feb 2001, Paul Topping wrote:
>
> This restriction, that XML can only be embedded in an XHTML
> document, is pretty painful for us MathML people. It means that we
> can't produce a single document that will work with Mozilla and
> Internet Explorer. I realize that if Microsoft would support XHTML
> in IE, this would also resolve the problem, but we can't make
> Microsoft do this.

We are doing exactly what Microsoft and Netscape and all the other W3C
members have agreed to, i.e., we are doing what the W3C specs say we
should do.


> Actually, a carefully prepared XHTML document basically does work in
> both IE and Mozilla, but it has to be served up with two different
> MIME types. Perhaps this restriction could be removed? Perhaps
> Mozilla could snoop into a document far enough to read the DOCTYPE,
> and if its XHTML + MathML, fire off the right parser even if the
> MIME type and extension say it should be HTML.

It's not that simple. Because of differing comment syntaxes, there is
no way to firmly determine if a document is XML or HTML.


> MSIE renders an XHTML document only if it is served to it with an
> HTML MIME type. It it is served as XML, it will display it as a sort
> of heirarchical tree of elements. We have tried to find a way to
> make it display as HTML, but to no avail. Unfortunately, Mozilla
> does the exact opposite: it requires that the document be served as
> XML and won't display XHTML as a formatted document if it is served
> as HTML. I'm not a standards expert, but it seems like there should
> be more flexibility on both sides.

Mozilla specifically went to the HTML working group and asked for
guidance. We are now doing exactly what the HTML working group told us
we should do.

Have you tried asking Microsoft to implement what they agreed to?
(Namely, the W3C recommendations?)


> Perhaps I should have clarified. Both parties agreed on the
> mechanism to be used to delimit an XML "island" within an HTML doc.

But neither party is working on Mozilla's MathML implementation.

Can you find us some documentation of this XML island stuff? I
couldn't find any normative documents describing it.

Cheers,

Paul Topping

unread,
Feb 1, 2001, 8:45:05 PM2/1/01
to Ian Hickson, mozilla...@mozilla.org
> On Thu, 1 Feb 2001, Paul Topping wrote:
> >
> > This restriction, that XML can only be embedded in an XHTML
> > document, is pretty painful for us MathML people. It means that we
> > can't produce a single document that will work with Mozilla and
> > Internet Explorer. I realize that if Microsoft would support XHTML
> > in IE, this would also resolve the problem, but we can't make
> > Microsoft do this.
>
> We are doing exactly what Microsoft and Netscape and all the other W3C
> members have agreed to, i.e., we are doing what the W3C specs say we
> should do.

You may be doing what the W3C specs say to do but Mozilla certainly
implements more than what the W3C recommends as does Microsoft. All I think
we want is for Mozilla to be bit more flexible.

> > Actually, a carefully prepared XHTML document basically does work in
> > both IE and Mozilla, but it has to be served up with two different
> > MIME types. Perhaps this restriction could be removed? Perhaps
> > Mozilla could snoop into a document far enough to read the DOCTYPE,
> > and if its XHTML + MathML, fire off the right parser even if the
> > MIME type and extension say it should be HTML.
>
> It's not that simple. Because of differing comment syntaxes, there is
> no way to firmly determine if a document is XML or HTML.

Are you talking about comments before the DOCTYPE? I think W3C standards are
pretty clear on what can appear in a document before the DOCTYPE and it's
very little.

> > MSIE renders an XHTML document only if it is served to it with an
> > HTML MIME type. It it is served as XML, it will display it as a sort
> > of heirarchical tree of elements. We have tried to find a way to
> > make it display as HTML, but to no avail. Unfortunately, Mozilla
> > does the exact opposite: it requires that the document be served as
> > XML and won't display XHTML as a formatted document if it is served
> > as HTML. I'm not a standards expert, but it seems like there should
> > be more flexibility on both sides.
>
> Mozilla specifically went to the HTML working group and asked for
> guidance. We are now doing exactly what the HTML working group told us
> we should do.

Same comment above. Mozilla handles the same arbitrary, ugly HTML that makes
up most of what's on the web, as it should to be a practical browser. I
don't think you can hide behind a "we're just following W3C orders"
statement. If Mozilla only implemented what was a W3C standard, it would
have no future in the real world.

> Have you tried asking Microsoft to implement what they agreed to?
> (Namely, the W3C recommendations?)

Sure, but I don't expect anything I say will carry much weight with them.

> > Perhaps I should have clarified. Both parties agreed on the
> > mechanism to be used to delimit an XML "island" within an HTML doc.
>
> But neither party is working on Mozilla's MathML implementation.

I don't follow your point here.



> Can you find us some documentation of this XML island stuff? I
> couldn't find any normative documents describing it.

There aren't any normative documents, just the meeting notes I referred to
before. I haven't looked at this issue in detail, but I think the basic idea
is that you refer to a namespace in the document, either by associating an
element name prefix in the <head> or using a namespace attribute on each
element (i.e. <math xmlns=...>). Microsoft implements the former, but not
the latter. The HTML parser can thereby identify XML chunks within the
mostly HTML document and pass them off to appropriate s/w to render.

Ian Hickson

unread,
Feb 1, 2001, 9:02:18 PM2/1/01
to Paul Topping, mozilla...@mozilla.org
On Thu, 1 Feb 2001, Paul Topping wrote:
>>>
>>> This restriction, that XML can only be embedded in an XHTML
>>> document, is pretty painful for us MathML people. It means that we
>>> can't produce a single document that will work with Mozilla and
>>> Internet Explorer. I realize that if Microsoft would support XHTML
>>> in IE, this would also resolve the problem, but we can't make
>>> Microsoft do this.
>>
>> We are doing exactly what Microsoft and Netscape and all the other
>> W3C members have agreed to, i.e., we are doing what the W3C specs
>> say we should do.
>
> You may be doing what the W3C specs say to do but Mozilla certainly
> implements more than what the W3C recommends as does Microsoft. All
> I think we want is for Mozilla to be bit more flexible.

"More than" is not the same as "different to" -- when there is a spec,
that's what we try to implement.


>>> Actually, a carefully prepared XHTML document basically does work
>>> in both IE and Mozilla, but it has to be served up with two
>>> different MIME types. Perhaps this restriction could be removed?
>>> Perhaps Mozilla could snoop into a document far enough to read the
>>> DOCTYPE, and if its XHTML + MathML, fire off the right parser even
>>> if the MIME type and extension say it should be HTML.
>>
>> It's not that simple. Because of differing comment syntaxes, there
>> is no way to firmly determine if a document is XML or HTML.
>
> Are you talking about comments before the DOCTYPE? I think W3C
> standards are pretty clear on what can appear in a document before
> the DOCTYPE and it's very little.

Ok, so if the following was sent as text/html, would you use the XML
or the HTML parser?

<!-- -- -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Example</title>
</head>
<body>
<math xmlns="...">
<!-- MathML stuff -->
</math>
</body>
</html>

Note: If you say HTML then we wouldn't be able to interpret the MathML
stuff (since that is XML). If you say XML then that should fail, since
that document is invalid XML (the comment at the top is invalid).


>>> MSIE renders an XHTML document only if it is served to it with an
>>> HTML MIME type. It it is served as XML, it will display it as a
>>> sort of heirarchical tree of elements. We have tried to find a way
>>> to make it display as HTML, but to no avail. Unfortunately,
>>> Mozilla does the exact opposite: it requires that the document be
>>> served as XML and won't display XHTML as a formatted document if
>>> it is served as HTML. I'm not a standards expert, but it seems
>>> like there should be more flexibility on both sides.
>>
>> Mozilla specifically went to the HTML working group and asked for
>> guidance. We are now doing exactly what the HTML working group told
>> us we should do.
>
> Same comment above. Mozilla handles the same arbitrary, ugly HTML
> that makes up most of what's on the web, as it should to be a
> practical browser.

We only do this for one reason and one reason alone: so that people
are able to adopt our browser. We only support _old_ quirky content.
The idea is to force people to do things the W3C way in the future.

This is why, for example, we have almost no CSS quirks.


> I don't think you can hide behind a "we're just following W3C
> orders" statement. If Mozilla only implemented what was a W3C
> standard, it would have no future in the real world.

Why not? What's the point of asking the W3C for guidance if we then
completely ignore what the world experts told us to do?


>> Have you tried asking Microsoft to implement what they agreed to?
>> (Namely, the W3C recommendations?)
>
> Sure, but I don't expect anything I say will carry much weight with
> them.

Well, since they are the ones at fault here...

The address to write to is wa...@microsoft.com, or on the web:
http://register.microsoft.com/regsys/custom/wishwizard.asp?fu=http://www.microsoft.com/mswish/thanks.htm


>>> Perhaps I should have clarified. Both parties agreed on the
>>> mechanism to be used to delimit an XML "island" within an HTML
>>> doc.
>> But neither party is working on Mozilla's MathML implementation.
> I don't follow your point here.

You said both parties -- meaning Netscape and Microsoft -- had come to
an agreement. Why does it matter if Microsoft and Netscape come to an
agreement, since Mozilla MathML is a Mozilla project with almost no
Netscape support?


>> Can you find us some documentation of this XML island stuff? I
>> couldn't find any normative documents describing it.
>
> There aren't any normative documents, just the meeting notes I
> referred to before. I haven't looked at this issue in detail, but I
> think the basic idea is that you refer to a namespace in the
> document, either by associating an element name prefix in the <head>
> or using a namespace attribute on each element (i.e. <math
> xmlns=...>). Microsoft implements the former, but not the latter.
> The HTML parser can thereby identify XML chunks within the mostly
> HTML document and pass them off to appropriate s/w to render.

XML-in-HTML is technically infeasible since they use different
grammars. e.g. "<strong/>" means something different in XML than it
does in HTML (in XML it means "empty <strong> element" and in HTML it
means "malformed <strong> element start tag").

This is why XML was introduced in the first place, instead of
piggy-backing on HTML or using ISO 8879:1986 SGML without DTDs.

Paul Topping

unread,
Feb 1, 2001, 9:32:45 PM2/1/01
to Ian Hickson, mozilla...@mozilla.org
> -----Original Message-----
> From: Ian Hickson [mailto:i...@hixie.ch]
>
> On Thu, 1 Feb 2001, Paul Topping wrote:
> >>>
> >>> This restriction, that XML can only be embedded in an XHTML
> >>> document, is pretty painful for us MathML people. It means that we
> >>> can't produce a single document that will work with Mozilla and
> >>> Internet Explorer. I realize that if Microsoft would support XHTML
> >>> in IE, this would also resolve the problem, but we can't make
> >>> Microsoft do this.
> >>
> >> We are doing exactly what Microsoft and Netscape and all the other
> >> W3C members have agreed to, i.e., we are doing what the W3C specs
> >> say we should do.
> >
> > You may be doing what the W3C specs say to do but Mozilla certainly
> > implements more than what the W3C recommends as does Microsoft. All
> > I think we want is for Mozilla to be bit more flexible.
>
> "More than" is not the same as "different to" -- when there is a spec,
> that's what we try to implement.

Right. I would never ask anyone to implement something that violated a W3C
spec ;-).

I would say Mozilla should interpret this as HTML and, therefore, the MathML
would fail. And I would say to the author, "Don't put HTML comments in an
XHTML document." Such a document is neither HTML nor XHTML.

The situation I think we should be concerned with is when Mozilla is
presented with a valid XHTML document, but served as text/html. I don't
really care what happens with invalid ones.

> >>> MSIE renders an XHTML document only if it is served to it with an
> >>> HTML MIME type. It it is served as XML, it will display it as a
> >>> sort of heirarchical tree of elements. We have tried to find a way
> >>> to make it display as HTML, but to no avail. Unfortunately,
> >>> Mozilla does the exact opposite: it requires that the document be
> >>> served as XML and won't display XHTML as a formatted document if
> >>> it is served as HTML. I'm not a standards expert, but it seems
> >>> like there should be more flexibility on both sides.
> >>
> >> Mozilla specifically went to the HTML working group and asked for
> >> guidance. We are now doing exactly what the HTML working group told
> >> us we should do.
> >
> > Same comment above. Mozilla handles the same arbitrary, ugly HTML
> > that makes up most of what's on the web, as it should to be a
> > practical browser.
>
> We only do this for one reason and one reason alone: so that people
> are able to adopt our browser. We only support _old_ quirky content.
> The idea is to force people to do things the W3C way in the future.

Of course. But I don't think I'm asking for something that violates either
the letter or the spirit of any W3C spec. It is simply a matter of handling
an error situation (namely, when the browser is presented with an XHTML
document served as text/html) in a way that benefits users.

> This is why, for example, we have almost no CSS quirks.
>
>
> > I don't think you can hide behind a "we're just following W3C
> > orders" statement. If Mozilla only implemented what was a W3C
> > standard, it would have no future in the real world.
>
> Why not? What's the point of asking the W3C for guidance if we then
> completely ignore what the world experts told us to do?

Same point as above. I'm not asking for a violation of W3C guidelines (as
far as I know).



> >> Have you tried asking Microsoft to implement what they agreed to?
> >> (Namely, the W3C recommendations?)
> >
> > Sure, but I don't expect anything I say will carry much weight with
> > them.
>
> Well, since they are the ones at fault here...

Both Microsoft and Mozilla implement only some of the W3C specs and, at the
same time, implement stuff that isn't in any W3C spec. There is no "fault"
here.

> >>> Perhaps I should have clarified. Both parties agreed on the
> >>> mechanism to be used to delimit an XML "island" within an HTML
> >>> doc.
> >> But neither party is working on Mozilla's MathML implementation.
> > I don't follow your point here.
>
> You said both parties -- meaning Netscape and Microsoft -- had come to
> an agreement. Why does it matter if Microsoft and Netscape come to an
> agreement, since Mozilla MathML is a Mozilla project with almost no
> Netscape support?

As I said in my original email on this topic, which was sent to you:

"I know that a Netscape commitment (never fulfilled) is certainly not a
Mozilla commitment"

> >> Can you find us some documentation of this XML island stuff? I


> >> couldn't find any normative documents describing it.
> >
> > There aren't any normative documents, just the meeting notes I
> > referred to before. I haven't looked at this issue in detail, but I
> > think the basic idea is that you refer to a namespace in the
> > document, either by associating an element name prefix in the <head>
> > or using a namespace attribute on each element (i.e. <math
> > xmlns=...>). Microsoft implements the former, but not the latter.
> > The HTML parser can thereby identify XML chunks within the mostly
> > HTML document and pass them off to appropriate s/w to render.
>
> XML-in-HTML is technically infeasible since they use different
> grammars. e.g. "<strong/>" means something different in XML than it
> does in HTML (in XML it means "empty <strong> element" and in HTML it
> means "malformed <strong> element start tag").
>
> This is why XML was introduced in the first place, instead of
> piggy-backing on HTML or using ISO 8879:1986 SGML without DTDs.

If the fact that the W3C had a meeting to discuss how to do XML-in-HTML
(http://www.w3.org/TR/NOTE-xh) doesn't convince you, nothing will.


Ian Hutchinson

unread,
Feb 1, 2001, 10:02:29 PM2/1/01
to Ian Hickson, Paul Topping, mozilla...@mozilla.org

On Thu, 1 Feb 2001, Ian Hickson wrote:

> On Thu, 1 Feb 2001, Paul Topping wrote:
>
> > MSIE renders an XHTML document only if it is served to it with an
> > HTML MIME type. It it is served as XML, it will display it as a sort
> > of heirarchical tree of elements. We have tried to find a way to
> > make it display as HTML, but to no avail. Unfortunately, Mozilla
> > does the exact opposite: it requires that the document be served as
> > XML and won't display XHTML as a formatted document if it is served
> > as HTML. I'm not a standards expert, but it seems like there should
> > be more flexibility on both sides.
>
> Mozilla specifically went to the HTML working group and asked for
> guidance. We are now doing exactly what the HTML working group told us
> we should do.
>

Actually Mozilla is failing to implement the abilities presumed by w3c's
own documents. For example if you look in
http://www.w3.org/TR/xhtml1/#guidelines
you'll find several references to XHTML documents being served as type
text/html. The clear implication is that this is a sensible thing to
do. However, Mozilla appears not to be willing to implement the ability to
render such documents (at least with MathML).

Overall, those of us who are more interested in actually making
mathematical documents available than in the standards legalisms are very
discouraged at the pedantic approach adopted by w3c and now Mozilla.

For example, early Amaya releases supported MathML within HTML in the way
that had been agreed, in <math> </math> tags. But recent releases have
REMOVED that capability.

This is progress?

Let's get on with making MathML rendering as widespread as possible,
rather than removing or refusing to implement functionality because it
does not sit well with the standards lawyers!

Ian Hutchinson.


Paul Topping

unread,
Feb 1, 2001, 10:08:39 PM2/1/01
to Ian Hutchinson, Ian Hickson, mozilla...@mozilla.org
Hi,

I have put a "Hello, world" XHTML document on my site at
http://www.dessci.com/hello.htm. It is served as text/html. If I send it to
the W3C's Validation Service (http://validator.w3.org/), it says my document
is valid XHTML. Of course, the validator is probably just ignoring the MIME
type and reading the document itself. Hmmm, that's an idea! Why doesn't
Mozilla do that?

Sorry, I couldn't resist.

Paul

----------------------------------------------------------------
Paul Topping email: pa...@dessci.com
phone: 562-433-0685
Design Science, Inc. http://www.dessci.com
"How Science Communicates"
MathType, WebEQ, MathPlayer, Equation Editor, TeXaide
----------------------------------------------------------------

> On Thu, 1 Feb 2001, Ian Hickson wrote:

Robert Miner

unread,
Feb 1, 2001, 10:15:22 PM2/1/01
to i...@hixie.ch, Pa...@dessci.com, mozilla...@mozilla.org

Hi Ian,

Indulge me in a little history. I was the co-chair of the W3C Math WG
at the time of the San Jose about mixing XML and HTML, and a big part
of the reason for the meeting was the Math WG's request for a solution
to the problem of XML in HTML. As you know, MathML and RDF were two
of the first serious XML applications, and there was an urgent need to
come up with a solution.

Jon Bosak, Vidur Apparao, Paoli and the W3C contingent went back and
forth about whether it was realistic to expect people to shift to
XHTML or whether we could coerce them somehow, or if there was some
bearable hack that would enable us to get MathML and RDF into exiting
HTML. The conclusion, as you saw in the Notes pointed to, at least
the people there ended agreeing on a hack until the world switched to
XHTML.

Now what has happened is that Microsoft and the IE team went with that
solution, and you folks have deemed the time ripe to go with the XHTML
strategy.

In IE5.5, Microsoft implemented "element" behaviors, which is a
variety of the scheme that Chris Wilson, Daniel Glazman and Vidur
Apparao described in a W3C Note, Behavioral Extensions to CSS
[http://www.w3.org/TR/becss]. In the MS implementation, you bind a
plug-in to an XML namespace to render XML data islands. The net
result is that a couple outfits (including us) are putting out
plug-ins to render MathML via this scheme in IE.

So what we are headed for is MathML support in both Mozilla and IE,
with the same XHTML+MathML document rendering properly in both,
provided it is served up as text/html in one and text/xml in the
other. So in practical terms, this means people who want to use the
Web for math and science are screwed. It was extremely frustrating
when Neil Soiffer and I were creating the W3C MathML Test Suite to be
in a situation where we could set it up to work with IE or with
Mozilla, but not both. At present, the pages ship as text/html, which
is part of the reason for the constant stream of folks writing to this
mailing list saying, "what's wrong, is my MathML-enabled Mozilla is
broken?"

I totally applaud your support of standards. But surely you can see
why I am a little depressed at the lack of a practical solution for
math after all the effort put into it at W3C. It's long history: Dave
Raggett's proposal for math in HTML 3 was cut; the Math WG's request
for a <math> tag in HTML 3.2, which failed; our request for a
mechanism to put MathML in HTML 4 , which was deferred on the promise
of a general solution to the XML in HTML problem. And finally now,
after 5 years of prosecuting our case on the standards side of things,
MathML is a first class citizen at W3C, that fits in perfectly as an
XHTML module, and with requirements in the charters of a sackful of
working groups. But to no avail -- it still doesn't work in Netscape
and IE at the same time. Grrrr.

We're just looking for a solution. Don't you have any ideas?

--Robert

------------------------------------------------------------------
Robert Miner Rob...@dessci.com
MathML 2.0 Specification Co-editor 651-223-2883
Design Science, Inc. "How Science Communicates" www.dessci.com
------------------------------------------------------------------

William F. Hammond

unread,
Feb 1, 2001, 11:19:46 PM2/1/01
to mozilla...@mozilla.org
Robert Miner <Rob...@dessci.com> writes:

> Indulge me in a little history.

These recollections certainly match what I saw go by in discussions.
I spent a certain amount of time talking to Ron Whitney in the summer
of '96 about the importance of the Math WG getting a clear idea of
what its overall mimetype context was going to be. Later we chatted
about it in the emj list.

> In IE5.5, Microsoft implemented "element" behaviors, which is a
> variety of the scheme that Chris Wilson, Daniel Glazman and Vidur

And we know the Moz approach.

But I am unclear about the legitimate cover that either approach
actually has. For example is there a clear rule that forbids using
text/html for a small xml superset of XHTML as defined by one of
the three dtd's?

And as Ian Hutchinson said, the main concern here is getting things
that work.

As to the text/html v text/xml, it seems clear to me if W3C
is promoting XHTML as the successor to traditional HTML, then
text/html needs to be recognized in this context and, provided
that XHTML is properly identified when served as XML, that also
needs recognition. (There is also application/xml that probably
should be covered, RFC on xml mimetypes, again when properly
identified.)

So now you're talking about xml documents that are not quite
under a well-defined overall xml document type. That, I think,
is why neither approach really has "cover".

Whatever is done about this should be public. There are other
potential players on the scene now.

So I think the question should be taken to the public forum
www-...@w3.org where one, in principle, can air it before all of
those concerned with writing browser code.

Good night!

-- Bill

Robert Miner

unread,
Feb 1, 2001, 11:41:12 PM2/1/01
to ham...@csc.albany.edu, mozilla...@mozilla.org

Hi.

> And as Ian Hutchinson said, the main concern here is getting things
> that work.

Hear, hear! I would die a happy man if math worked right in browsers.

> So now you're talking about xml documents that are not quite
> under a well-defined overall xml document type.

I agree. And the MIME type issue is similarly problematic for
documents that mix XML dialects.

I still think some basic document snooping should go a long way to an
actual, practical solution. I would much rather have to go to even
moderately great pains with careful document declarations and have it
work, than have some more idealistic proposal that doesn't. Who
wouldn't?

Ian Hickson

unread,
Feb 2, 2001, 3:35:24 AM2/2/01
to Robert Miner, Pa...@dessci.com, mozilla...@mozilla.org
On Thu, 1 Feb 2001, Robert Miner wrote:
>
> [snip interesting and factually correct history]

>
> Now what has happened is that Microsoft and the IE team went with
> that solution, and you folks have deemed the time ripe to go with
> the XHTML strategy.

Yep. Largely because by the time Mozilla 1.0 comes out, it is hoped
that XHTML will be supported in other UAs too. Mozilla 1.0 is still
some way off. We have to design a solution that works when it is
released, not one that is out of date when it is released.


> In IE5.5, Microsoft implemented "element" behaviors, which is a
> variety of the scheme that Chris Wilson, Daniel Glazman and Vidur
> Apparao described in a W3C Note, Behavioral Extensions to CSS
> [http://www.w3.org/TR/becss].

You can do this in Mozilla using XBL. XBL is supported in text/html,
it is not limited to XML. So you could embed your MathML that way if
you wanted -- you wouldn't even need to write your own plugin.

This would work by including tags like this in your HTML:

<math style="-moz-binding: url(mymaths.xml#a)"></math>

...and then embedding your MathML in mymaths.xml like this:

<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="a">
<content>
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<msup>
<mfenced>
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</mfenced>
<mn>2</mn>
</msup>
</mrow>
</math>
</content>
</binding>
</bindings>

However this is currently non-standard, just like HTCs and Microsoft's
XML data islands.


> So what we are headed for is MathML support in both Mozilla and IE,
> with the same XHTML+MathML document rendering properly in both,
> provided it is served up as text/html in one and text/xml in the
> other.

All that simply because of a bug in IE that doesn't treat XHTML
documents sent as text/xml correctly. i.e. this problem is caused by a
bug in Microsoft code not Mozilla code. Yes?


> So in practical terms, this means people who want to use the Web for
> math and science are screwed. It was extremely frustrating when Neil
> Soiffer and I were creating the W3C MathML Test Suite to be in a
> situation where we could set it up to work with IE or with Mozilla,
> but not both.

So write a funky .htaccess file which sends .xhtml files back as
text/html to IE and text/xml to everything else.


> [...] And finally now, after 5 years of prosecuting our case on the


> standards side of things, MathML is a first class citizen at W3C,
> that fits in perfectly as an XHTML module, and with requirements in
> the charters of a sackful of working groups. But to no avail -- it
> still doesn't work in Netscape and IE at the same time. Grrrr.

I agree that it is a problem -- but the bug is in IE, not Mozilla. We
do it correctly, as per the W3C.


> We're just looking for a solution. Don't you have any ideas?

Sure. Use the script I just wrote which is available at:

http://software.hixie.ch/utilities/cgi/xhtml-for-ie/

It requires you to use Apache and have CGI scripts and .htaccess files
enabled. I don't really know of a solution otherwise.

I hope this helps -- please send me feedback if there are problems
with that script. (But read the docs first!)

Ian Hickson

unread,
Feb 2, 2001, 3:41:21 AM2/2/01
to Ian Hutchinson, Paul Topping, mozilla...@mozilla.org
On Fri, 2 Feb 2001, Ian Hutchinson wrote:
>> Mozilla specifically went to the HTML working group and asked for
>> guidance. We are now doing exactly what the HTML working group told us
>> we should do.
>
> Actually Mozilla is failing to implement the abilities presumed by w3c's
> own documents. For example if you look in
> http://www.w3.org/TR/xhtml1/#guidelines
> you'll find several references to XHTML documents being served as type
> text/html. The clear implication is that this is a sensible thing to
> do. However, Mozilla appears not to be willing to implement the ability to
> render such documents (at least with MathML).

That section refers to ways of making XHTML appear to older user agents as
SGML-based HTML4, and is not talking about including namespaces in
documents sent as text/html. We support everything in this appendix.

Ian Hickson

unread,
Feb 2, 2001, 4:08:39 AM2/2/01
to Paul Topping, mozilla...@mozilla.org

Ok, we are agreed.

How about this document, also sent as text/html? How should it be
interpreted?

<html>


<head>
<title>Example</title>
</head>
<body>

<ol> <li> Hello <li> World </ol>
<!-- several dozen kilobytes of text... -->


<math xmlns="...">
<!-- MathML stuff -->
</math>
</body>
</html>

Note: If you say HTML then the MathML will fail, and if you say XML
then that means we'd have to download almost the entire document,
incrementally rendering it as HTML (since a priori it looks like HTML)
and upon finding the xmlns attribute starting over, reparsing the
whole thing as XML, and complaining about the XML error on line 6.


This argument can go on for a long time, by the way. This is one of
the reasons why it was decided *not* to do any XML sniffing, and just
assume (as the working group asked us to) that everything sent as
text/html is old fashioned tag soup.


> The situation I think we should be concerned with is when Mozilla is
> presented with a valid XHTML document, but served as text/html. I
> don't really care what happens with invalid ones.

Do you mean well-formed, or valid? Valid XHTML documents cannot
contain MathML, by the definition of 'valid'.

>> We only [have quirks] for one reason and one reason alone: so that


>> people are able to adopt our browser. We only support _old_ quirky
>> content. The idea is to force people to do things the W3C way in
>> the future.
>
> Of course. But I don't think I'm asking for something that violates
> either the letter or the spirit of any W3C spec. It is simply a
> matter of handling an error situation (namely, when the browser is
> presented with an XHTML document served as text/html) in a way that
> benefits users.

The problem is how to determine that a document served as text/html is
in fact XHTML. Can you suggest a good algorithm?

Just to help you, here are some things that we have already thought of
and which do not work:

* looking for DOCTYPEs (an XHTML document with a DOCTYPE cannot do
anything more than an HTML4 document -- in particular, it can't
contain maths),

* looking for the "xmlns" attribute before starting the real parser
(it is very hard to accurately determine what is a real 'xmlns'
attribute and what is just the text 'xmlns' in a string -- the only
real way of being sure would be to use the XML parser to check, and
loading an XML parser for every single page before firing up the
HTML parser would incur a performance loss that is unacceptable),

* looking for XML PIs (they are optional),


>> Why not? What's the point of asking the W3C for guidance if we then
>> completely ignore what the world experts told us to do?
> Same point as above. I'm not asking for a violation of W3C
> guidelines (as far as I know).

The guidelines are sufficiently vague that we e-mailed the HTML
working group directly for an answer. The answers we received (which
were vague in themselves) boiled down to "don't sniff and assume tag
soup if you get text/html). (You'll find the threads around early
September in w3c-html-wg and www-html, I believe David Baron posted
the first question).


>> Well, since they are the ones at fault here...
> Both Microsoft and Mozilla implement only some of the W3C specs and,
> at the same time, implement stuff that isn't in any W3C spec. There
> is no "fault" here.

Accepting data islands in HTML4 (which is what IE does) is against
HTML4, ISO8879:1986 SGML, and contradicts the spirit of XML,
namespaces-in-XML, and XHTML.

On the other hand what Mozilla does is the official W3C solution to
the problem.

Looks to me like Microsoft is indeed at fault here...


> As I said in my original email on this topic, which was sent to you:
>
> "I know that a Netscape commitment (never fulfilled) is certainly not a
> Mozilla commitment"

Exactly. So to what they agreed is irrelevant to Mozilla.


> If the fact that the W3C had a meeting to discuss how to do XML-in-HTML
> (http://www.w3.org/TR/NOTE-xh) doesn't convince you, nothing will.

The W3C members (which also includes me) often have meetings. Just
because we talk about stuff doesn't mean we think it is possible or
even a good idea, as I'm sure you know.

The XML in HTML Meeting happened in February 1998. The problem
mentioned in that document has since been solved by the Namespaces in
XML spec detailed in http://www.w3.org/TR/REC-xml-names which was
published last year.

David Carlisle

unread,
Feb 2, 2001, 4:17:35 AM2/2/01
to Pa...@dessci.com, mozilla...@mozilla.org

> Are you talking about comments before the DOCTYPE? I think W3C standards are
> pretty clear on what can appear in a document before the DOCTYPE and it's
> very little.

No, the problem with XML islands is that they mean that the document as
a whole is neither XML nor SGML so not usable by any tools except tools
(ie internet explorer) that accept a completely ad hoc format.

XML is a subset of SGML by virtue of an SGML declaration that specifies
things like the /> empty element syntax, but you can't locally change
thee SGML declaration for an element, so there is no way to have an SGML
document using HTML syntax except within XML elements where it uses
XML syntax.

Actually there is a way, you could declare XML to be CDATA (like script)
but then the DOM for the XML element would just be a flat character
string not any structure.

Incidentally two things that possibly may work today are
(my preferred choice)
serve as text/xml but link to an XSL stylesheet that rewrites to HTML
for IE

or serve as text/html but have a meta tag to force the content type back
to text/xml (does that work for mozilla?) if so you could have some
javascript that hid the meta tag from IE.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp

David Carlisle

unread,
Feb 2, 2001, 4:36:04 AM2/2/01
to ham...@csc.albany.edu, mozilla...@mozilla.org

> For example is there a clear rule that forbids using
> text/html for a small xml superset of XHTML as defined by one of
> the three dtd's?

No, a browser is _allowed_ to send all text/html to the XML parser, and
process them as XHTML. That would be a good thing, except for the
inconvient fact that there are apparently one or two existing pages
already served as text/html which would fail if given to an XML parser.

For the purposes of geting MathML most easily rendered cross platform,
an algorithm that would work for us would be to try parsing as XML first
and if it fails try parsing as HTML, but that probably isn't practical
(perhaps it is?) It would certainly make error reporting for non well
formed XML files hard (as they would have gone to the HTML parser)

> So now you're talking about xml documents that are not quite
> under a well-defined overall xml document type.

You can use a well defined XHTML+MathML DTD if you like (one is
included with the MathML spec, and built in to the W3C validator.
Which incidentally require _yet another_ mime type, see
http://www.w3.org/Math/validator.

The problem isn't the doctype, the problem is deciding which parser to
use XML or HTML. since both the HTML and XHTML specs allow the use of
text/html it's a bit hard.

Looking for the DOCTYPE to decide whetehr to switch to XML is dodgy as
comments and PI's may appear first, however if the xML file has an XML
declaration that must start at the first byte of the file, (modulo byte
order mark) so something that would be feasible is the following
algorithm

If served as text/html use HTML parser unless the file starts with an
XML declaration, in which case pass to XML parser and process as an
XHTML family document.

Ian Hickson

unread,
Feb 2, 2001, 6:12:00 AM2/2/01
to David Carlisle, ham...@csc.albany.edu, mozilla...@mozilla.org
On Fri, 2 Feb 2001, David Carlisle wrote:
>
> Looking for the DOCTYPE to decide whetehr to switch to XML is dodgy as
> comments and PI's may appear first, however if the xML file has an XML
> declaration that must start at the first byte of the file, (modulo
> byte order mark) so something that would be feasible is the following
> algorithm
>
> If served as text/html use HTML parser unless the file starts with an
> XML declaration, in which case pass to XML parser and process as an
> XHTML family document.

That would work great except that most people will want to avoid using a
PI in a file sent as text/html since some legacy browsers are known to
choke on XML PIs in HTML.

David Carlisle

unread,
Feb 2, 2001, 6:34:33 AM2/2/01
to i...@hixie.ch, ham...@csc.albany.edu, mozilla...@mozilla.org

> That would work great except that most people will want to avoid using a
> PI in a file sent as text/html since some legacy browsers are known to
> choke on XML PIs in HTML.

Isn't life full of unfortunate historical problems;-)


Actually your script to serve the file with different mime types
depending on the client looks more promising (and ought to
work ok on the w3.org server)

Robert Miner

unread,
Feb 2, 2001, 7:31:41 AM2/2/01
to i...@hixie.ch, Rob...@dessci.com, Pa...@dessci.com, ald...@ibm.us.com.geomtech.com, i...@ams.org, mozilla...@mozilla.org

Hi Ian,

> You can do this in Mozilla using XBL. XBL is supported in text/html,
> it is not limited to XML. So you could embed your MathML that way if
> you wanted -- you wouldn't even need to write your own plugin.
>
> This would work by including tags like this in your HTML:
>
> <math style="-moz-binding: url(mymaths.xml#a)"></math>
>
> ...and then embedding your MathML in mymaths.xml like this:

This would be fine if you could inline the MathML. But since you
can't, this is obviously no improvement from the point of view of
preparing a workable multi-browser document. Still, I didn't realize
that you were in fact supporting XML data islands in this way. Thanks
for the info.

> All that simply because of a bug in IE that doesn't treat XHTML
> documents sent as text/xml correctly. i.e. this problem is caused by a
> bug in Microsoft code not Mozilla code. Yes?

Sure. I beat up on them, too, whenever they make decisions
detrimental to the use of MathML, and we have raised this issue with
the IE folks. But from my point of view, the case for calling
Mozilla's behavior a bug is just about as strong -- to me, you are
just failing to correct for a bad MIME type.

> So write a funky .htaccess file which sends .xhtml files back as
> text/html to IE and text/xml to everything else.

Sure. I can manage solutions like this. But as a general solution
for the rank and file scientific community, putting documents on a
variety of server platforms that they don't generally control, it is a
little weak. If we are really forced into such an extremity, I
actually prefer a 'polymediator' solution, such as that proposed by
Ka-Ping Yee.

As I said before, I think a little enlightened snooping is a much more
practical solution, and it sounds like David has described a workable
scheme.

> On Fri, 2 Feb 2001, David Carlisle wrote:
>
> Looking for the DOCTYPE to decide whetehr to switch to XML is dodgy as

> comments and PI's may appear first, however if the XML file has an XML


> declaration that must start at the first byte of the file, (modulo
> byte order mark) so something that would be feasible is the following
> algorithm
>
> If served as text/html use HTML parser unless the file starts with an
> XML declaration, in which case pass to XML parser and process as an
> XHTML family document.

In the case where you have a completely valid XHTML + MathML document
with a proper DOCTYPE declaration starting at the first byte of the
file, it doesn't seem like you give up anything in acting on the DOCTYPE
instead of a MIME type. MIME types on the Web (as opposed to email,
etc) are notoriously flaky, and as noted above, frequently beyond the
control of the author. By contrast, the DOCTYPE is completely in the
hands of the author, and therefore seems to me like a better guide to
the actual document contents.

In fact, it would be fine with me to just implement this for the
specific case of a DOCTYPE explicitly declaring MathML + XHTML, so as
to errode your general policy as little as possible.

It sounds like one of your prime motivations in your current strategy
is not so much that you belive MIME types are more reliable guides to
document contents than DOCTYPE declaration, but rather that this is
what the HTML Working Group suggested you do. Obviously that has got
to carry a lot of weight with you. However, from my point of view,
this is just one W3C WG (probably unknowingly) making a suggestion to
the detriment of another W3C WG, and there is a simple solution.

I suggest Angel and Patrick (our WG co-chairs) approach Steve
Pemberton about changing the HTML WG's suggestion vis a vis MathML.
We have successfully done this kind of thing in the past, e.g asking
the Schema WG to change their position on character entities (and on
this occasion Pemberton was on our side). Resolving this kind of
problem is precisely what W3C is for. If you feel you need official
sanction before you can act on a what seems to me to be a clearly
superior practical solution, we will go get it for you.

And of course, it is Mozilla, so I guess I could just go crazy and
hack the parser ;-)

Ian Hickson

unread,
Feb 2, 2001, 7:46:08 AM2/2/01
to Robert Miner, Pa...@dessci.com, ald...@ibm.us.com.geomtech.com, i...@ams.org, mozilla...@mozilla.org
On Fri, 2 Feb 2001, Robert Miner wrote:
>
> But from my point of view, the case for calling Mozilla's behavior a
> bug is just about as strong -- to me, you are just failing to correct
> for a bad MIME type.

I don't think any specs say that we are allowed to correct a bad MIME
type, certainly not the HTTP spec... :-)


> In the case where you have a completely valid XHTML + MathML document
> with a proper DOCTYPE declaration starting at the first byte of the
> file, it doesn't seem like you give up anything in acting on the
> DOCTYPE instead of a MIME type.

Unfortunately most web browsers are not validating web browsers, so
knowing it is a valid DOCTYPE won't help you (since non-validating parsers
have to sniff the FPI instead of going in and studying the DTD).

Mozilla is a non-validating parser...


> And of course, it is Mozilla, so I guess I could just go crazy and
> hack the parser ;-)

This would be a great idea -- to make sure you don't waste your time,
though, I would strongly recommend proposing a sniffing scheme first of
all, and making sure it hasn't already been considered and dumped for some
reason. Someone who has done a lot of work in this area is David Baron, it
would be a good idea to ping him before doing any work. (His e-mail
address is dba...@fas.harvard.edu.)

David Carlisle

unread,
Feb 2, 2001, 8:21:04 AM2/2/01
to i...@hixie.ch, Rob...@dessci.com, Pa...@dessci.com, ald...@ibm.us.com.geomtech.com, i...@ams.org, mozilla...@mozilla.org

> I don't think any specs say that we are allowed to correct a bad MIME
> type, certainly not the HTTP spec... :-)

but serving an XHTML+MathML as text/html isn't bad (I think, accordinmg
to the XHTML modularisation docs) it just under specifies what's in the
entity. Mozilla's approach of sending text/html documents to the html
parser isn't bad either. It's just that the combination of the two
doesn't really work too well.

I agree with you that serving as text/xml (or text/xml+html in the style
of the mime types for xml rfc) would be better, but if looking for
<?xml as the first 5 characters in the file caused the html parser
to give up and pass it to the xml parser, I don't really think that any
standards conformance would be compromised.

As you said some older HTML browsers might do the wrong thing with the
<? but if the file has got inline MathML in it, then older browsers are
going to have bigger problems than the xml declaration to deal with.

As Robert just commented, we could probably do the mime type switch on
the server for the test suite, but it's harder to tell end users that
they may only serve mathml files if they have access to server
configuration files and access to cgi scripts. (I couldn't do this from
my "home" ISP, for example, well not without paying more money to get
their commercial service which includes script access)

William F. Hammond

unread,
Feb 2, 2001, 8:26:49 AM2/2/01
to mozilla...@mozilla.org
David Carlisle writes:

> Actually your script to serve the file with different mime types
> depending on the client looks more promising (and ought to
> work ok on the w3.org server)

No. Browser-based content negotiation is a terrible thing.
In addition, this would place burdens on authors.

-- Bill


William F. Hammond

unread,
Feb 2, 2001, 8:22:53 AM2/2/01
to mozilla...@mozilla.org
We do realize, don't we, that the W3C root page at www.w3.org is an
xhtml document served with mimetype text/html.

And, doing as they do (let's hope as their docs say):

<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">

So there it is. Look for the doctype's root tag having an xmlns if
indeed the xml PI is a problem. I would also think about something
like

<meta
name="xmlExtensionElement"
content="math"
scheme=string-that-flags-the-right-namespace-for-mathml
/>

but then I'm only a very interested onlooker.

Also for the near term future the preponderance of text/html will be
old (and not valid) HTML, much less conforming xml, so if Mozilla's
xml parser chokes on that stuff it should try the old html treatment
first, looking for an xmlns attribute on the root tag.

-- Bill

Ian Hickson

unread,
Feb 2, 2001, 8:43:32 AM2/2/01
to William F. Hammond, mozilla...@mozilla.org

As I mentioned earlier, we cannot use the 'xmlns' attribute. It is very


hard to accurately determine what is a real 'xmlns' attribute and what is
just the text 'xmlns' in a string -- the only real way of being sure would
be to use the XML parser to check, and loading an XML parser for every
single page before firing up the HTML parser would incur a performance

hit that is unacceptable.

Don't forget that XML as text/html is the exception rather than the rule.
The vast majority of pages are of some indeterminate version of tag soup
based on HTML 3.2.

Ian Hickson

unread,
Feb 2, 2001, 8:52:13 AM2/2/01
to David Carlisle, Rob...@dessci.com, Pa...@dessci.com, mozilla...@mozilla.org
On Fri, 2 Feb 2001, David Carlisle wrote:
>>
>> I don't think any specs say that we are allowed to correct a bad MIME
>> type, certainly not the HTTP spec... :-)
>
> but serving an XHTML+MathML as text/html isn't bad

# However, XHTML Documents which follow the guidelines set forth in
# Appendix C, "HTML Compatibility Guidelines" may be labeled with the
# Internet Media Type "text/html", as they are compatible with most HTML
# browsers. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^ -- http://www.w3.org/TR/xhtml1/

As I understand the intent of that paragraph, it means that XHTML sent as
text/html is intended to be compatible with legacy UAs. MathML is
certainly _not_ compatible with legacy UAs.

Unfortunately, the XHTML1 spec has kept up a long tradition of the HTML
working group, namely being not very specific.


> I agree with you that serving as text/xml (or text/xml+html in the
> style of the mime types for xml rfc) would be better, but if looking
> for <?xml as the first 5 characters in the file caused the html parser
> to give up and pass it to the xml parser, I don't really think that
> any standards conformance would be compromised.

The first note in appendix C, which must be followed in order for XHTML1
documents to be sent as text/html, suggests not using XML PIs...

I still don't understand why Mozilla should bloat itself to get around a
bug in a Microsoft product. This seems backwards to me.

David Carlisle

unread,
Feb 2, 2001, 8:58:20 AM2/2/01
to ham...@csc.albany.edu, mozilla...@mozilla.org

> We do realize, don't we, that the W3C root page at www.w3.org is an
> xhtml document served with mimetype text/html.

yes but that would work OK in mozilla as well.
If you serve some xhtml as text/html and pass it to an html parser
then you are OK if the parser is a browser with traditionally lax error
reporting, and doesn't report things like <br /> as a syntax error.
If you used the same heuristic with something stricter (eg nsgmls)
then you fail, as nsgmls needs to know in advance that it's dealing with
HTML or XML.

Now the fact of the matter is that Mozilla only supports MathML in
XML (which is reasonable) and MathML is supported in IE via some
behaviour extensions that are (bizarrely) only available within HTML.

so the W3C home page works fine in either case, (not using the XML
parser of either system) but an XHTML+MathML document does not work
in the same way (and can't really, as one has to get at least the MathML
bits to something other than the HTML parser)

> Also for the near term future the preponderance of text/html will be
> old (and not valid) HTML, much less conforming xml, so if Mozilla's
> xml parser chokes on that stuff

It doesn't choke because it doesn't see it:-)
If it _did_ see it, then the XML spec would enforce that it gave
fatal errors on most web pages.


> it should try the old html treatment

I'd rather that the HTML parser (which is of necessity a bunch of ad
hoc rules anyway) had a rule to hand over <?xml documents to the XML
system than corrupt the XML parser with any such heuristics.

David Carlisle

unread,
Feb 2, 2001, 9:04:12 AM2/2/01
to i...@hixie.ch, Rob...@dessci.com, Pa...@dessci.com, mozilla...@mozilla.org

> As I understand the intent of that paragraph,

hmm.

> I still don't understand why Mozilla should bloat itself to get around a
> bug in a Microsoft product. This seems backwards to me.

'cause you're so reasonable it's worth asking:-)

And this is becoming a real not just theoretical problem.
We are being asked by people what they should do to put their
MathML documents (which normally are HTML+MathML) on the web,
and basically we don't know the answer, not without commiting to one
particular rendering engine, which rather defeats the point of the
platform neutral XML encoding.

Gervase Markham

unread,
Feb 2, 2001, 10:08:54 AM2/2/01
to
> particular rendering engine, which rather defeats the point of the
> platform neutral XML encoding.

Mozilla works on almost any platform you care to name. Using IE binds you
to Windows. If you want platform-neutrality, the path is clear. What's the
problem?

Oh, you mean _that_ meaning of "platform". :-)

Gerv

Robert Miner

unread,
Feb 2, 2001, 10:17:22 AM2/2/01
to i...@hixie.ch, Rob...@dessci.com, Pa...@dessci.com, ald...@ibm.us.com.geomtech.com, i...@ams.org, mozilla...@mozilla.org

Hi.

> This would be a great idea -- to make sure you don't waste your time,
> though, I would strongly recommend proposing a sniffing scheme first of
> all, and making sure it hasn't already been considered and dumped for some
> reason. Someone who has done a lot of work in this area is David Baron, it
> would be a good idea to ping him before doing any work. (His e-mail
> address is dba...@fas.harvard.edu.)

Thanks, I'll ask him. And I really do think we should bring the issue
up with the HTML WG, since I doubt they realize the implications for
MathML, and it is a serious problem for us.

David Carlisle

unread,
Feb 2, 2001, 10:36:14 AM2/2/01
to gervase...@univ.ox.ac.uk, mozilla...@mozilla.org

> Oh, you mean _that_ meaning of "platform". :-)

OK then I could have said "application neutral". I want people to
put the files on the web in a way that lets unknown readers process them
with unknown applications. Me, I'll probably read them using TeX
which runs on even more platforms than Mozilla.
but even I wouldn't want to force everyone to use TeX, or at least I
wouldn't admit to that on a public list.

Robert Miner

unread,
Feb 2, 2001, 10:35:12 AM2/2/01
to i...@hixie.ch, dav...@nag.co.uk, Rob...@dessci.com, Pa...@dessci.com, mozilla...@mozilla.org

Hi.

> I still don't understand why Mozilla should bloat itself to get around a
> bug in a Microsoft product. This seems backwards to me.

It's kind of a stretch to call a few lines of code in the already
compromised HTML parser to hand a document starting <?xml... to the
XML parser "bloat". Especially, when by doing so, you enormously
increase the usefulness of Mozilla to huge communities of authors who
can control what goes into a document's content, but can't control
what MIME type their server ships it with.

If you really care about nudging the world towards standard XHTML, it
wouldn't hurt to be more a little more concerned about the constraints
decisionmakers in the real world have to face, rather than the more
doctrinaire and idealistic debates of the standards community.

It would be great if everyone spontaneously decided they could afford
to publish their content in a fashion that worked in Mozilla, but not
in the other 85% of the worlds browsers. But it ain't going to
happen (except maybe for hand-held devices, etc)...

William F. Hammond

unread,
Feb 2, 2001, 11:50:21 AM2/2/01
to i...@hixie.ch, mozilla...@mozilla.org, www-...@w3.org
Ian Hickson <i...@hixie.ch> writes:

[snip]


> > So there it is. Look for the doctype's root tag having an xmlns if
> > indeed the xml PI is a problem. I would also think about something

[snip]


> > old (and not valid) HTML, much less conforming xml, so if Mozilla's

> > xml parser chokes on that stuff it should try the old html treatment
> > first, looking for an xmlns attribute on the root tag.

[snip]


> As I mentioned earlier, we cannot use the 'xmlns' attribute. It is very
> hard to accurately determine what is a real 'xmlns' attribute and what is
> just the text 'xmlns' in a string -- the only real way of being sure would

Let's be careful here. And I guess it's a given that an old client
might fumble over an xml PI.

We agree that something served through http as "text/html" is initially
regarded as old html, possibly tag soup, to begin with.

If, however, that document is sound XHTML -- whatever XHTML extensions
are involved aside, the first tag given by a '<' followed immediately
by a word character (in usascii, the range A-Za-z) will be its root
tag, which *must* be "html".

So an xml-aware browsing client should:

1. Look for the first document instance tag as described above.
2. If that matches exactly the string '<html xmlns="', then the
xml parser should be called.

This is hardly "sniffing".

And it's not a big performance hit.

What better way is there for telling a client that something served as
"text/html" needs to go through the xml parser when it is given that
some extant widely distributed clients won't handle xhtml when served
as "text/xml" whether they are within spec or not.

-- Bill


Dan Connolly

unread,
Feb 2, 2001, 1:06:18 PM2/2/01
to William F. Hammond, i...@hixie.ch, mozilla...@mozilla.org, www-...@w3.org
"William F. Hammond" wrote:
[...]

> So an xml-aware browsing client should:
>
> 1. Look for the first document instance tag as described above.
> 2. If that matches exactly the string '<html xmlns="', then the
> xml parser should be called.

yes, this is the way I think it should be done.

For editing tools, I think there's a little bit more to
it; see also:

silent recovery from errors considered harmful
From: Dan Connolly (conn...@w3.org)
Date: Mon, Aug 28 2000
http://lists.w3.org/Archives/Public/www-amaya/2000JulSep/0237.html

> This is hardly "sniffing".
>
> And it's not a big performance hit.
>
> What better way is there for telling a client that something served as
> "text/html" needs to go through the xml parser when it is given that
> some extant widely distributed clients won't handle xhtml when served
> as "text/xml" whether they are within spec or not.
>
> -- Bill

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Roger B. Sidje

unread,
Feb 19, 2001, 8:37:53 PM2/19/01
to Ian Hickson
Ian Hickson wrote:
>
> This would work by including tags like this in your HTML:
>
> <math style="-moz-binding: url(mymaths.xml#a)"></math>

Tested with <div>...</div> (or <p>, instead of <math>) and it worked...
---
RBS

Reply all
Reply to author
Forward
0 new messages