W3C home > Mailing lists > Public > www-tag@w3.org > January 2013

Re: The non-polyglot elephant in the room

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 22 Jan 2013 23:13:24 +0100
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-html WG <public-html@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <20130122231324081333.d23ebe51@xn--mlform-iua.no>
Henri Sivonen, Mon, 21 Jan 2013 11:46:13 +0200:
> On Sun, Jan 20, 2013 at 2:18 AM, Leif Halvard Silli wrote:
>> I suppose we agree:
> …
>> * that 99% of the time, XHTML documents end up being consumed as HTML.
> 
> Disagree. I expect page views in Gecko, WebKit and Trident to add up
> to more than 1% of the time, and they always consume XHTML (by
> definition application/xhtml+xml) as XML.

I meant that well-formed XHTML markup 99% of the time end up being 
consumed as HTML. I'm still sure you agree.

>> Bud do we agree
>> * that tools that do not output HTML5-conforming XML is an existing,
>>   real, problem?
> 
> Disagree.

I suppose this just a variant of what you said above.

>> * that most authors don't know what "putting an HTML parser in
>>   the XML tool chain" even means?
> 
> They don’t need to. The people who need to know are people who want to
> consume HTML and use existing XML tooling for processing the data.

Let's not mention things in Polyglot Markup that its readers don't need 
to know.

>> Very few editors actually claim to output XHTML5. The following are all
>> that I found, and they all do it wrongly, in some way or another:
>> 
>> * Some add the XML prologue + the HTML5 DOCTYPE:
>>   OXYGEN XML, BlueGriffon, NetBeans (at least its EaselDemo,
>>   which doesn't even default to UTF-8.). The XML prologue makes it
>>   non-conforming as text/html, but at least the DOCTYPE makes it
>>   _not_ trigger quirks mode.
>> * These tools skip the DOCTYPE: XMLmind, SEEDit. This is conforming
>>   XHTML5, but as HTML5, it is non-conforming and triggers quirks mode.
> 
> It’s not wrong to produce XHTML that doesn’t work if served as
> text/html. Whether these tools do it wrongly depends on whether the
> output is correct for serving as application/xhtml+xml.

You are banging in open doors.

> Having people bother the developers of these products with bug reports
> that the products are somehow wrong when the products say they produce
> XHTML and the output works as application/xhtml+xml [ … ]
> (If you want to bother the developers of these products,   

Let me cite the XMLmind developer a few days ago:

]] Your are 100% right. We would *really* like to add <!DOCTYPE html> 
to 
all our document templates.[[
http://www.xmlmind.com/pipermail/xmleditor-support/2013-January/010261.html


And later: ]] This is embarrassing. We were completely wrong. We were 
persuaded that  <!DOCTYPE html> was not well-formed XML. We were so 
sure about it that we didn't actually test files similar to what's 
above! (or more simply re-read the XML spec in that respect: 
http://www.w3.org/TR/xml/#NT-doctypedecl )

Starting from next release, we'll add <!DOCTYPE html> to our (X)HTML5 
templates. Many thanks for taking the time to report this problem."[[
http://www.xmlmind.com/pipermail/xmleditor-support/2013-January/010263.html


> asking them to offer HTML editing without pretending anything about it
> being XHTML editing at the same time would be more productive.)

There isn't a shortage of developers who want to hold bug reporters’s 
hands. I can assure you that I try to understand the product before I 
report bugs.
-- 
leif halvard silli
Received on Tuesday, 22 January 2013 22:13:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 January 2013 22:13:54 GMT