- 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