Re: The non-polyglot elephant in the room

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, 21 January 2013 09:46:42 UTC