- 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>
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:55 UTC