- From: Alex Russell <slightlyoff@google.com>
- Date: Mon, 28 Jan 2013 10:56:11 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: "www-tag@w3.org List" <www-tag@w3.org>, public-html WG <public-html@w3.org>
- Message-ID: <CANr5HFUni74siyE5k9TkRObtP4TEpb=w4Prmu5RdfZmi2dpENQ@mail.gmail.com>
I agree with Henri on all points. On Jan 21, 2013 4:47 AM, "Henri Sivonen" <hsivonen@iki.fi> 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. > > -- > Henri Sivonen > hsivonen@iki.fi > http://hsivonen.iki.fi/ > >
Received on Monday, 28 January 2013 15:56:47 UTC