[Lachlan wrote: IE has no native support for XHTML at all.]
So it's not "native" support but there _is_ support. How can you tell if there 
is support, well, you do test-cases. If one can produce a test-case of valid 
XHTML served as HTML to IE and IE parses it correctly, then there is support. 
Why should we care if IE use an SGML or an XML parser to process the markup? 
The main thing is that markup is parsed correctly and there is no data loss. 
How can IE do this reliably? Because valid XHTML markup written to 
comparability guidelines is a sub-set of HTML.

[Lachlan wrote: If you serve invalid, ill-formed XHTML to any browser as 
text/html, will there be any data loss?  The answer is the same [No].]
That's not strictly the case, because whenever you write any markup not to 
specification, there is a chance of it being parsed incorrectly, resulting in 
data loss or incorrect association of data. I speak as a software engineer who 
has written parsers, but don't take my word for it. Try this test: take a bunch 
of real use Word documents, save them out as HTML and then run HTML Tidy on 
them. I bet there will be some data loss. That is not to say that Tidy has a 
bad parser (on the contrary); but markup not written to specification is at 
risk for data loss. Even WCAG 2.0 recognizes it in Guideline 4.1.

As far as MIME types are concerned, we live in the real world, and until IE 
natively supports XHTML, we need to serve XHTML 1.0 as HTML to IE. We should 
not throw the baby (XHTML) out with the bathwater (IE 6).

User agents come and go, so how one browser parses markup is so trivial in the 
larger scheme of things. What is really important is content. If people write 
content in HTML they are creating legacy data because it is not easily parsable 
from a content management perspective. Content written in HTML cannot easily be 
re-purposed. If you have 1,000 documents and you want to change some markup in 
all of them, it is very difficult to do this if these documents are in HTML. If 
the documents are in XML (XHTML), then this is a trivial task using 
off-the-shelf technologies like DOM/SAX parsers or XSLT. So we need to start 
writing content in XML and if it's content destined for the Web, then XHTML is 
perfect. The next step is: if you write it in XHTML, then why not serve it in 
XHTML (even if right now it's still processed by some current browsers as HTML).


-------- Original Message --------
From: Lachlan Hunt
Date: 12/3/2005 5:50 AM
> Vlad Alexander (XStandard) wrote:
>> Lachlan, you have been on this list long enough to know that when you
>> make extreme statements such as "since you're new, you might want to
>> stick with HTML4" or "IE does not support XHTML", that debate will ensue.
> So be it.  If there are still people that don't understand XHTML for
> what it is, yet blindly attempt to use it, then the issues need to be
> discussed.
>> This is not what newcomers to Web Standards need. A better approach
>> would have been to ask why this person needs/wants to use
>> XHTML and if he/she has a good reason to do so, give this person
>> advice on how to do it right.
> Thank you for this very constructive advice, in future I will be more
> careful about how I phrase such things.  But my message still stands:
> XHTML is not appropriate for an inexperienced HTML author to use,
> particularly with the current level of browser support.
>> To address your statement that "IE does not support XHTML" - this is
>> not true. IE does support XHTML 1.0 - you and I just don't like the
>> level of support IE offers.
> No, the fact is that IE has no native support for XHTML at all.  By the
> same logic you're claiming that it has limited support, then I could
> invent my own FooML language using similar element names and attributes
> to HTML, register the MIME type application/fooml+xml for it to use,
> serve it as text/html and claim that IE has limited support:
> <!DOCTYPE FooML SYSTEM "http://example.org/fooml/dtd";>
> <fooml xmlns="http://example.org/fooml/namespace";>
> <title>This is a FooML Document</title>
> <p>If I serve this as text/html, then IE will seem to support it.</p>
> <p>I can even use scripts with a MIME type it it doesn't normally
> recognise.</p>
> <script content-type="application/ecmascript">
> alert("Hello World!");
> // Since "content-type" is an non-existent attribute in HTML,
> // the MIME type is ignored and tag soup browsers assumes it's
> // JavaScript, even though most current browsers only widely
> // recognise text/javascript.
> </script>
> </fooml>
> Would you agree that IE has no support for FooML, or would you claim
> that it has limited support because the result is acceptable, when
> served with the wrong MIME type?
>> If you serve valid XHTML as HTML to IE, will there be any data loss? No!
> If you serve invalid, ill-formed XHTML to any browser as text/html, will
> there be any data loss?  The answer is the same, but that doesn't make
> it right.
>> Now, I don't want to give Hickson any more of my attention. But I will
>> say that he and his groupies are not interested in teaching people how
>> to use XHTML correctly.
> I am interested in teaching people to use XHTML correctly, but
> experience shows that newcomers are far better off sticking with HTML4
> until they are confident enough to fully understand the ramifications of
> using XHTML.
> If we want to teach XHTML correctly, I'm all for doing so, but *we
> should actually teach XHTML /correctly/*.  Despite any objections to the
> contrary, that means using the correct MIME type and gaining a full
> understanding of all the differences between HTML and XHTML, rather than
> just doing half the job by teaching them the syntax, getting them to
> throw in a few extra slashes and leaving it at that, thinking the rest
> is all the same as HTML.  That is *not* teaching them correctly, and
> it's doing much more harm than good.

The discussion list for  http://webstandardsgroup.org/

 See http://webstandardsgroup.org/mail/guidelines.cfm
 for some hints on posting to the list & getting help

Reply via email to