W3C home > Mailing lists > Public > www-tag@w3.org > January 2013

Re: The non-polyglot elephant in the room

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 28 Jan 2013 10:56:11 -0500
Message-ID: <CANr5HFUni74siyE5k9TkRObtP4TEpb=w4Prmu5RdfZmi2dpENQ@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: "www-tag@w3.org List" <www-tag@w3.org>, public-html WG <public-html@w3.org>
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:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:51 UTC