Re: The non-polyglot elephant in the room

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/
>
>