W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2001

Re: Cannot render MathML

From: William F. Hammond <hammond@csc.albany.edu>
Date: Fri, 2 Feb 2001 11:50:21 -0500 (EST)
Message-Id: <200102021650.LAA04098@pluto.math.albany.edu>
To: ian@hixie.ch
Cc: mozilla-mathml@mozilla.org, www-talk@w3.org
Ian Hickson <ian@hixie.ch> writes:

> > 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
> > 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.
> 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
Received on Friday, 2 February 2001 11:50:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:02 UTC