- From: William F. Hammond <hammond@csc.albany.edu>
- Date: Fri, 2 Feb 2001 11:50:21 -0500 (EST)
- To: ian@hixie.ch
- Cc: mozilla-mathml@mozilla.org, www-talk@w3.org
Ian Hickson <ian@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
Received on Friday, 2 February 2001 11:50:41 UTC