Re: The non-polyglot elephant in the room

Hi Alex, 

Just for the record:I do not feel that Henri represented my points of 
view very well in that "rebuffal". Se my previous comment. 
http://lists.w3.org/Archives/Public/public-html/2013Jan/0116


Leif Halvard Silli

Alex Russell, Mon, 28 Jan 2013 10:56:11 -0500:
> I agree with Henri on all points.
> On Jan 21, 2013 4:47 AM, "Henri Sivonen" wrote:
>> 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.
>> 
>>> 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.
>> 
>> --
>> Henri Sivonen
>> hsivonen@iki.fi
>> http://hsivonen.iki.fi/

>> 
>>

Received on Monday, 28 January 2013 17:26:09 UTC