Re: The non-polyglot elephant in the room

On 1/21/13 4:46 AM, Henri Sivonen wrote:
> On Sun, Jan 20, 2013 at 2:18 AM, Leif Halvard Silli
> <xn--mlform-iua@xn--mlform-iua.no> 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.
>
>> Bud do we agree
>> * that tools that do not output HTML5-conforming XML is an existing,
>>    real, problem?
> Disagree.
>
>> * 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.
>
>> 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.
>
> 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 but not as
> text/html is exactly the kind of bad effect of the polyglot doc that
> makes me think this group should not have taken polyglot as a work
> item in the first place and should not publish it as a REC now that
> that the Process gives no choice but REC or Note.
>
> (If you want to bother the developers of these products, I think
> asking them to offer HTML editing without pretending anything about it
> being XHTML editing at the same time would be more productive.)
>
>> The elephant in the room is that, perhaps apart from Sam's tools, few
>> tools output XHTML code that is HTML(5)-conforming. A positive focus on
>> Polyglot Markup could have an impact on that situation.
> I think that would be a negative focus due to waste of developer time.
>
> I am opposed to this working group encouraging polyglot markup or
> appearing to encourage polyglot markup, because I don't want to spend
> time at implementing something as useless as polyglot validation and I
> don't want to be explaining to a horde of designers why I don't if
> this polyglot stuff finds its way into an A List Apart article or
> similar. Also, I'd much rather see the development time of authoring
> tools such as BlueGriffon go into providing a better UI for authoring
> HTML instead of chasing polyglot markup.
>
Please correct me if my characterization is wrong, but it appears to me 
that this entire affair is about content-type (mime type) squatting 
i.e., trying to squeeze (X)HTML into content-type: text/html. If this is 
true, why on earth would such an endeavor be encouraged by the W3C or 
its TAG?

-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen