[whatwg] several messages about XML syntax and HTML5

Sun Dec 3 23:55:32 PST 2006

I've been having a lot of trouble following this discussion, because I 
can't work out what it is that is being asked for. There seem to be 
multiple discussions going on, and it isn't clear to me that everybody 
really knows what they are arguing for or against.

I've changed the spec to allow a (meaningless) "xmlns" attribute on the 
root <html> element, for the same reasons /> is allowed on void elements 
now. I don't think it's a particularly useful thing, but I'm curious to 
see what people think. (Like anything in the spec, we might remove it in 
due course, based on real world experiences with the spec.)

There seem to be other issues being raised, though. Here's some possible 
things I think people might be asking for, based on the thread so far and 
on discussions on IRC:

Possible Request A: We want a way to add proprietary markup to HTML 
documents, and have them be usable by text/html browsers.

Possible Request B: We want a way to add markup representing standard 
vocabularies other than HTML (e.g. MathML, SVG, DocBook, RDF) to HTML 
documents, and have them be usable by text/html browsers.

Possible Request C: We want XML-style draconian error handling for 
text/html.

Possible Request D: We want HTML-style graceful error handling for XML 
content sent.

Possible Request E: We want to use XML syntactic sugar in HTML.

Possible Request F: We want a powerful tool chain like the XML one.

Are there other requests? What are they?

Let's address each of the above in turn:

* Possible Request A: We want a way to add proprietary markup to HTML 
documents, and have them be usable by text/html browsers.

This won't work, because the browsers won't support that proprietary 
markup. This has nothing to do with the specs. (The same problem exists in 
XML.) For the same reason, proprietary markup is poor for accessibility. 
HTML actually has a mechanism to add custom/proprietary semantics to 
general HTML semantics, which works hand-in-hand with good accessibility 
techniques and _does_ work in existing browsers, namely the "class", 
"rel", and (for now) "profile" attributes. This is how microformats.org 
work. This doesn't require any sort of XML markup.

* Possible Request B: We want a way to add markup representing standard 
vocabularies other than HTML (e.g. MathML, SVG, DocBook, RDF) to HTML 
documents, and have them be usable by text/html browsers.

These should be raised as distinct feature requests. We're already looking 
at adding Math markup to HTML (probably in a way compatible with MathML 
renderer implementations). SVG is not semantically rich (it's 
presentational), and so probably belongs not in the document layer (HTML) 
but in the presentation layer (CSS+XBL) or the embedding layer (external 
documents using <object> and fallback content for accessibility).

* Possible Request C: We want XML-style draconian error handling for 
text/html.

This won't work, because of the existence of legacy text/html content 
that would trigger error messages. (Browsers with draconian text/html 
handling wouldn't even get any market share.)

* Possible Request D: We want HTML-style graceful error handling for XML 
content.

This is out of scope of the HTML5 specification. Speak to the XML guys. 
XML currently requires draconian error handling and has no defined 
gracefull error handling.

You should ask yourself, though, why is it that you want to use XML, if 
you don't like what it implies?

* Possible Request E: We want to use XML syntactic sugar in HTML.

This wouldn't work, because new syntactic sugar in HTML would have to be 
compatible with legacy content and legacy browsers. The XML syntactic 
sugar (like <![CDATA[]]>) doesn't really work well in HTML (what with it 
becoming a comment and all). Some things -- xmlns="", />, ' -- are 
already allowed in HTML5. We could theoretically add PIs as well, I guess. 
I don't see what else we could add. (And PIs are a bad idea in both XML 
and HTML anyway, except for stylesheets, where for backwards compatibility 
reasons we have to rely on <link> in HTML anyway.)

* Possible Request F: We want a powerful tool chain like the XML one.

By introducing HTML5 parsers and serialisers that plug onto the ends of 
existing XML toolchains, we can leverage the XML tool chain without having 
to force authors to use XML. Work is already in progress to enable this. 
The parser specification (new in HTML5) enables this. The lack of such a 
spec for previous versions of HTML is, IMHO, the reason why there has 
never been a strong HTML tool chain.

Down to specific e-mails sent over the weekend:

On Fri, 1 Dec 2006, Robert Sayre wrote:
> 
> Almost. I want to understand why non-HTML5-defined semantics would be 
> harmful. I don't think we're in danger of each web author inventing 
> their own elements.

See A above.

> > Well, SVG itself would arguably be bad because it is poor from a 
> > semantic standpoint.
> 
> HTML is poor from a semantic standpoint.

HTML is actually pretty rich, all things considered. SVG, on the other 
hand, is media-specific and presentational.

On Sat, 2 Dec 2006, Mike Schinkel wrote:
> 
> But please take into consideration that almost nobody writes web pages 
> using a DOM; they write web pages using text editors and dynamically 
> using string concatonation. As such there is great value for users in 
> having them be as similar as possible. If they converge, it will 
> accelerate chaos on the web.

With the addition of xmlns="" (see above), they are now as close as 
possible, I believe.

On Sat, 2 Dec 2006, Elliotte Harold wrote:
> 
> This enables the use of the very powerful XML toolchain for processing 
> HTML. In fact, prior to the widespread adoption of XML there were, near 
> as I could tell, no reliable open means of parsing HTML documents. There 
> were a few proprietary, incompatible, buggy engines locked up in various 
> browsers; and that was about it.

See F above.

> What I don't understand is why some members of this working group is so 
> dead set on actively preventing HTML from being XML. The non-draconian 
> error handling I understand. But why are you disappointed that <!DOCTYPE 
> html> is well-formed XML? Why the active hostility to well-formedness?

What I'm "hostile" towards is the fiction that you can take an XML parser 
and attempt to parse an HTML document. The two formats aren't the same, 
using the wrong parser is simply that, wrong.

   http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_and_XHTML

On Sat, 2 Dec 2006, Elliotte Harold wrote:
> Lachlan Hunt wrote:
> 
> > HTML 2.0 to 4.01 documents could, in the same way you're insisting on 
> > using XML tools on the back end, be reliably parsed using SGML tools.
> 
> Surely you jest. [...]
>
> Secondly, anyone who actually tried to use an SGML parser to handle HTML 
> rapidly hit a wall since most HTML documents were not even close to 
> actually conformant to the SGML spec or the HTML DTD.

Exactly. And the *exact same situation* exists today with XML.

Anyone who actually ties to use an XML parser to handle HTML rapidly hits 
a wall, since most HTML documents are not even close to actually 
conformant to the HTML or XML specs. Even if we were to require that HTML5 
documents use exactly XML syntax, this would still be the case.

On Sat, 2 Dec 2006, Elliotte Harold wrote:
> 
> The other half could be addressed by one little box in the corner of 
> Firefox's status bar that's a smiley face if the page is valid, and a 
> frown if it isn't.

A browser that shipped with a frowy face showing on 93% of pages would do 
very badly in usability studies (and thus very badly in the market).

> It used to be that the Cafe au Lait and Cafe con Leche home pages became 
> malformed on a regular basis through my carelessness or typos. That 
> stopped once I implemented an XML toolchain that e-mailed me when it 
> noticed a mistake on those pages. (That was actually a side effect of 
> another project, not the specific intent.)

You can do that with HTML5 too. (Or HTML4, in theory.)

> Fixing a page to be well-formed and even valid XHTML is not hard, and 
> well within the abilities of most people hand authoring HTML. The 
> problem is when we don't realize we have a problem in the first place. 
> Once we've noticed the problem, we're 90% of the way to solving it.

Making it conformant HTML5 is even easier than making it conformant XML 
(and you don't even need to make it syntactically correct to get 
interoperable behaviour, with HTML5, since the parser has defined error 
handling behaviour).

What is it about XML that you like, that you don't get with HTML, that 
makes you request that we make HTML more like XML?

On Sat, 2 Dec 2006, Elliotte Harold wrote:
> Lachlan Hunt wrote:
> 
> > The Yellow Screen of Death is about as annoying as you can get.  I 
> > really don't understand how you can go on about the benefits of XML 
> > because it requires well-formedness, but then turn around and say XML 
> > can be served as text/html which just makes all your arguments null 
> > and void.
> 
> Perhaps because you believe the MIME type is a magic incantation that 
> somehow changes the document's nature, and I don't.
>
> The document is what it is. A sequence of bytes is either a well-formed 
> XML document or it isn't. I can call it XML, but that doesn't mean it 
> is; and I can say it's not XML, but that doesn't mean it isn't.

In the Web Apps 1.0 world, an HTTP message whose headers say text/html is 
an HTML document, regardless of what sequence of bytes the body of the 
message actually say. An HTTP message whose headers say text/xml, or use 
some other XML MIME type, is an XML document. It's the MIME type that 
decides how it is processed. If it is processed as an HTML document, then 
it _is_ an HTML document, possibly with errors. So says the spec.

On Sat, 2 Dec 2006, Mike Schinkel wrote:
> 
> "Striving to be XHTML, but if not consider me HTML5."

Browsers wouldn't implement this due to performance concerns (it was 
considered for XHTML-as-text/html back in the day). It also would result 
in dramatically different renderings, just because there was a minor 
well-formedness error one day.

On Sat, 2 Dec 2006, Mike Schinkel wrote:
> 
> And as I write this email, it's finally come to me one method that would 
> work for even the most clueless and apathetic of web publishers: What if 
> Google, Yahoo, and Microsoft Live were to display a human-readable 
> string, denoting the content type, hyperlinked to a web page that gives 
> the details of that content type.  For example, assume some future 
> version of that the Web Apps current-work page was written in XHTML 1.0 
> yet it failed the validator; it could look like this (example from 
> Google):
> 
> 	Web Applications 1.0
> 	The list of active formatting elements; 9.2.4.3.3. Creating and 
> 	inserting HTML elements; 9.2.4.3.4. Closing elements that have 
> 	implied end tags; 9.2.4.3.5. ...
> 	whatwg.org/specs/web-apps/current-work/ - Similar pages - XHTML 1.0
>       (WARNING)
> 
> The "XHTML 1.0" would link to a description of XHTML 1.0 and it's 
> content type and how it can be viewed, etc. etc. But the "WARNING" could 
> be in BOLD RED type linking to a warning page that explained why the 
> "Web Applications 1.0" page failed XHTML 1.0 validation, and it could 
> include a link to a validator for retesting (The search engines could 
> even use <BLINK> if they *really* wanted it to be effective; doh!)

I have huge doubts that this would pass even elementary usability testing, 
because most users would just say "I don't care".

On Sat, 2 Dec 2006, James Graham wrote:
> 
> SVG is a pretty good example because (some) browsers _do_ support the 
> SVG "semantics" (in the sense that they understand when to draw a 
> circle, when to draw a path, etc.). I think a lot of people who are 
> complaining at the moment might be happy if there was a possibly to do:
> 
> <svg subtreeNS="http://www.w3.org/2000/svg">
> <!-- SVG content here -->
> </svg>
> 
> And similarly with say, MathML. I don't think there's anything desirable 
> about calling the attribute xmlns because the semantics would differ 
> from that attribute (it would only allow namespaces on a per-subtree 
> basis).
> 
> I don't pretend to know how parsing would work though.

The above is being considered. It doesn't necessarily require any XML, 
though.

On Sat, 2 Dec 2006, Shadow2531 wrote:
> 
> It seems html5 could allow xmlns and xml:lang for text/html without 
> problem, but it still wouldn't be treated as XML, so why allow it?

Requiring xml:lang seems like a bad idea (since it's longer for no good 
reason), and enabling it without requiring it would result in there being 
three different language attributes with weird fallback rules, which would 
end up being a huge source of bugs and an implementation nightmare. 
Browsers have enough trouble implementing this stuff without having to 
give them incomprehensible namespace confusion like this.

On Sat, 2 Dec 2006, Mike Schinkel wrote:
>
> That approach of saing "better tools should be provided" will work if 
> and only if the people doing the specifying also *ensure* that there are 
> tested, working tools freely available in the public domain on all major 
> platforms, and that those tools are easy enough for the lay person to 
> use in (almost) all contexts.

There is work on this. Join #whatwg on Freenode to take part if you're 
interested.

On Sun, 3 Dec 2006, Christian Schmidt wrote:
> 
> PHP developers can parse HTML using DOMDocument::loadHTML(). If they 
> want, they can then convert the DOMDoucment to SimpleXML:

Would be interesting to see these upgraded to HTML5. :-)

On Sat, 2 Dec 2006, Elliotte Harold wrote:
> > 
> > If you want to use XHTML, then use XHTML, send it with an XML MIME 
> > type, and be happy.
> > 
> > If you want to use HTML, then use HTML, send it with an HTML MIME 
> > type, and be happy.
> 
> What's wrong with option 1 is that it doesn't work in the browser with 
> the majority of the installed base, something I used to think mattered 
> to this group.

So why not use option 2 then?

> Consequently I and many others choose option 3:
> 
> Use XHTML, send it with an HTML MIME type, and be happy.

This is equivalent to doing option 2 with a rose-tinted glasses on.

On Sun, 3 Dec 2006, Mike Schinkel wrote:
> >>
> >> Use XHTML, send it with an HTML MIME type, and be happy.
> > No!
> 
> Why not?  What's wrong with doing that?

Well, it's impossible. If you _think_ you're using XHTML, but you process 
it with an HTML processor (e.g. by sending it as text/html), then you're 
really just using HTML, with a lot of syntax errors.

> Lachlan Hunt wrote:
> > > There were a few proprietary, incompatible, buggy engines 
> > > locked up in various browsers; and that was about it.
> > OpenSP, which is free software,
> 
> Will a recommendation to use OpenSP be included in the spec?

HTML5 isn't based on SGML, so no. You have to write your own parser, or 
use one of the HTML5 parsers being written as we speak.

> Maybe I should ask a different question. If people write XHTML badly, 
> what makes you think they will write HTML5 any better?

They won't.

> As I understand it, serving with the correct mime type for XHTML isn't 
> an option, assuming you want people to be able to read it with current 
> browsers, or am I wrong on that?

This is basically correct, yes. (It's possible if you're an advanced 
author.)

> And what MIME type should he be using that will work on today's 
> Internet?

text/html. Which means using HTML, not XHTML, because text/html content 
is processed as HTML, not XHTML.

On Sun, 3 Dec 2006, Mike Schinkel wrote:
> 
> That's an excellent point. My answer is that I was sold on the benefits 
> of XHTML, and I still believe in them so I don't want to give up on the 
> hope that I can eventually get there.

Just out of interest, could you say what those are? It's likely that HTML5 
actually has the same benefits, so that you don't lose them by using HTML5 
instead of XHTML5.

The following e-mail very clearly describes the problem, I think:

On Sun, 3 Dec 2006, Henri Sivonen wrote:
>
> First, there's XHTML--all of it the way it works as application/xhtml+xml.
> I'll call it XHTML_all. Then there's a subset of XHTML that when served as
> text/html to a browser that handles text/html according to requirements
> imposed by the real-world legacy still appears to "work" for the casual
> observer. I'll call this XHTML_compatible.
> 
> At this point, it is important to realize that pro-XHTML advocacy is based on
> reasoning derived from the properties of XHTML_all when it is processed as
> application/xhtml+xml. This reasoning is then applied to XHTML served as
> text/html. This is logical and intellectually honest if and only if XHTML_all
> equals XHTML_compatible.
> 
> I'll name the difference of XHTML_all and XHTML_compatible as
> XHTML_incompatible. Lachlan gave examples that indicate that
> XHTML_incompatible is not empty. Hence, XHTML_compatible is a proper subset of
> XHTML_all.
> 
> Now if you wish to serve your documents as text/html, it follows that you
> can't just happily do things that guarantee that your documents are members of
> XHTML_all. Instead, you have to *make an effort* to make sure that your
> documents fall into XHTML_compatible. The equality of XHTML_all and
> XHTML_compatible is not true--it is political obfuscation to hide an
> inconvenient truth. If your documents fell into XHTML_incompatible, things
> would *break*, which would be *bad*. This means that you lose any benefits
> that hinge on you only having to ensure targeting XHTML_all.
> 
> If you are making the text/html compatibility effort, you might as well adjust
> your effort to producing HTML5 instead of XHTML_compatible, unless you
> specifically want to participate in upholding a political appearance that
> doesn't match the technical reality and in doing so confuse newbies into
> believing that the political obfuscation is the truth (which leads them to
> waste time on finding out the truth the hard way).

On Sat, 2 Dec 2006, Michel Fortin wrote:
> 
> Having two markups pose the same problem as having two incompatible HD 
> DVD formats. Browsers do (or will) accept both formats, so as long as 
> the media type is known it'll work fine for them. But what about every 
> other piece of software in the middle that does not talk directly to the 
> browser?
> 
> That's the real difficulty when dealing with HTML and XHTML: the choice 
> isn't really about tools, it's a choice between two incompatible 
> exchange format. That's the reason why I think it's compelling to have a 
> common subset between HTML and XHTML. If you can output something valid 
> for both HTML and XHTML at the same time, then you don't have to worry 
> about what format is supported on the other end.

The problem is that the common subset would be just that -- a subset. The 
common subset of HTML and XHTML has very few useful features!

On Sat, 2 Dec 2006, Mike Schinkel wrote:
> 
> So what guidance would you publish after HTML5 is released with regards to
> people in each of the following situations:
> 
> 1.) Currently coding HTML(4) but trying to move to XHTML

Stay with HTML4 or move to HTML5 instead for new content. Leave existing 
content alone.

> 2.) Currently coding XHTML and cleaning up only HTML(4)

There are almost no authors actually coding XHTML. There are many authors 
who think they are, but are only testing it in HTML browsers. My advice to 
them would be to move to HTML5 for new content, but leave their exsting 
content alone.

> 3.) Currently coding only in XHMTL

Again, these authors are probably really coding HTML, not XHTML, though 
with an XHTML DOCTYPE and maybe some talismans like an XHTML namespace. My 
advince would be to switch the talismans to the HTML5 ones and continue 
as before.

> 4.) Currently offering a CMS/web app generates HTML(4) using string
> concatonation, with plans to move it to XHTML

Move it to HTML5 instead (requires minimal changes, basically just 
making the DOCTYPE shorter).

> 5.) Currently offering a CMS/web app generates HTML(4) and XHTML both using
> string concatonation

Move to HTML5 and XHTML5 respectively, making sure to serve HTML5 content 
using text/html and XHTML5 content using application/xhtml+xml.

> 6.) Currently offering a CMS/web app generates HTML(4) with string
> concatonation and XHTML with an XML pipeline

Drop the string concatenation, and move to outputting HTML5 using an XML 
pipeline with an HTML5 serialiser on the end. (This would basically mean 
dropping the HTML4 code, simplifying the CMS, and making very few changes 
to the XML serialiser.)

> 7.) Currently offering a CMS/web app generates XHTML with an XML pipeline

Move to HTML5 with an XML pipeline. (This is basically the same as number 
6, except that there's no code to drop first.)

On Sun, 3 Dec 2006, Mike Schinkel wrote:
> 
> P.S. Any chance of splitting 
> http://www.whatwg.org/specs/web-apps/current-work/ into multiple files?  
> It overwhelms IE7 so much as to be practically unusable (Yes I have 
> FireFox, but it's not my default browser.)

It will be split in due course, but not while it's actively developed, as 
that would be a significant increase in development cost.

On Sat, 2 Dec 2006, Henri Sivonen wrote:
> 
> I think putting subtrees rooted at <svg> or <math> in the SVG and MathML 
> namespaces respectively (and allowing /> to close elements while the 
> tokenizer is looking at such a subtree) would be more forward-compatible 
> with future SVG and MathML revisions. (Subtrees rooted at children of 
> SVG <foreignObject> and MathML <annotation-xml> would be put in the 
> XHTML namespace.)

I'm not sure this would be compatible enough, but it's one of the things 
I'm looking at doing.

On Sat, 2 Dec 2006, James Graham wrote:
> 
> Ignoring the _syntax_ for a moment, there have been reasons given for 
> wanting to use XML _features_ in HTML5 - the desire to embed MathML or 
> SVG in a HTML document, for example. You suggest punting these use cases 
> to XHTML5, without addressing the fundamental problem that the XML 
> parsing model is unsuitable for the web, so denying authors the 
> possibility of rich (what XML would regard as "mixed namespace") 
> content.

Adding MathML or SVG to HTML doesn't require using XML, necessarily. But 
we're looking at that. (Mainly we need implementation experience to be 
able to make educated design choices here.)

On Sat, 2 Dec 2006, Elliotte Harold wrote:
> James Graham wrote:
> 
> > Well I think you're hugely mistaken. Any model without support for 
> > error recovery is not suitable for hand authoring (and only marginally 
> > suitable for machine authoring).
> 
> You mean like almost every programming language ever invented? When's 
> the last time you saw error recovery in a C compiler?

JavaScript is a more apt example, since it's used on the Web... and it has 
error recovery all over the place.

> I don't believe most web documents are hand authored any more.

I'd be interested in seeing statistics on this.

> Consider that essentially every page generated by Blogger, Moveable Type 
> or WordPress is not hand authored.

Actually, all those _are_ hand authored. They all use templates that were 
very carefully written by HTML authors by hand.

> Almost every page at sites like Amazon.com or walmart.com is not hand 
> authored.

Again, most of the HTML on those pages was hand-authored. Sure, it was 
written in Perl scripts (or whatnot), but it was still, at one point, 
hand-authored, and not generated by a markup editor like Dreamweaver.

> Hand authoring is a distinct minority on the web today.

I would need statistics to be convinced of this. My own research doesn't 
back this up.

On Sat, 2 Dec 2006, Elliotte Harold wrote:
> 
> The allow me to summarize. There are two basic classes of web authors
> 
> 1. Those who prefer to hand author HTML in text editors and are 
> competent to produce well-formed XHTML.
> 
> 2. Those who do not have the level of skill necessary to hand author 
> HTML in a text editor, and therefore must use tools.

I think this is a false dichtomy. I think there is a FAR bigger set, 
namely those who do not have the level of skill necessary to hand author 
HTML in a text editor, but do so anyway.

> Also, let me once again distinguish between well-formed and valid. I'm 
> happy once the document is well-formed. Valid I can live without.

Given that we're talking about HTML here, I don't see what you mean (since 
for you, as you've told me, "well-formed" means XML).

Why do you need well-formedness? Is it to ensure interoperability? HTML5 
ensure interoperability even in the absense of syntactic correctness, by 
defining clear error handling rules. Is this not enough? Why not?

On Sun, 3 Dec 2006, Elliotte Harold wrote:
> 
> WordPress allows angle brackets. However I almost never use them. Instead I
> use its markdown format. Most other users do the same, I think. [...]
>
> I suspect the others you mention are similar. I don't ever remember using
> angle brackets on Blogger, but it's been a while.

It would be better to have hard data to work with, rather than having to 
rely on our opinions of this. My own research does not suggest that most 
authors use tools. That over three quarters of pages have major syntactic 
errors leads me to suspect that tools are not going to save the syntax.

On Sat, 2 Dec 2006, Robert Sayre wrote:
> 
> It would not take much to add an "if the element has an 'xmlns' 
> attribute" to the "A start tag token not covered by the previous 
> entries" state in "How to handle tokens in the main phase" section of 
> the document.

This would break millions of pages, sadly. There are huge volumes of pages 
that have bogus xmlns="" attributes with all kinds of bogus values on the 
Web today. I worked for a browser vendor in the past few years that tried 
to implement xmlns="" in text/html content, and found that huge amounts of 
the Web, including many major sites, broke completely. We can't introduce 
live xmlns="" attributes to text/html.

That doesn't mean we can't introduce MathML, SVG, or other language 
vocabularies to HTML5 in other ways, though, and this is being examined.

On Sat, 2 Dec 2006, Sam Ruby wrote:
> 
> The question is: what would the HTML5 serialization be for the DOM which is
> internally produced by the script in the following HTML5 document?
> 
>   http://intertwingly.net/stories/2006/12/02/whatwg.logo

Currently, there wouldn't be one. We could extend HTML5 to have some sort 
of way of doing this, in the future. (It isn't clear to me that we'd want 
to allow inline SVG, though. It's an external embedded resource, not a 
semantically-rich part of the document, IMHO.)

On Sat, 2 Dec 2006, Robert Sayre wrote:
> 
> I don't think we need to settle this issue in December 2006, but I do 
> think there is ample evidence of interoperable but undocumented behavior 
> that HTML5 implementors will need to consider.

Could you elaborate on this?

On Sat, 2 Dec 2006, Sam Ruby wrote:
> 
> Does the WHATWG have a process for capturing unresolved issues that need 
> to be worked?

All mails sent to the list go into my inbox (in little folders) until I've 
replied to them (which I do when I've resolved the issue).

On Sun, 3 Dec 2006, Mike Schinkel wrote:
>
> Why are XML Data Islands disasterous?

Mostly because they have almost as much in common with XML as HTML5 does. 
(That is to say, they aren't XML Data Islands, they're "Microsoft Custom 
Markup Extensions For HTML".)

On Sun, 3 Dec 2006, Sam Ruby wrote:
>
> In the hopes that it will bring focus to this discussion:
> 
> http://wiki.whatwg.org/wiki/HtmlVsXhtml

This has now been updated with a more complete list of differences.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'