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

The non-polyglot elephant in the room

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sun, 20 Jan 2013 01:18:57 +0100
To: Noah Mendelsohn <nrm@arcanedomain.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, "www-tag@w3.org List" <www-tag@w3.org>, "public-html@w3.org" <public-html@w3.org>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>
Message-id: <20130120011857091063.5c25c67c@xn--mlform-iua.no>
Noah Mendelsohn, Sat, 19 Jan 2013 09:50:39 -0500:
> On 1/19/2013 6:56 AM, Leif Halvard Silli wrote:
>> With this clarification, I hope the TAG understands
why I suggest adding that line and is OK with it.

> If individual TAG members want to discuss here the merits of 
> proposals that's great, and obviously that will help catch areas of 
> disagreement.

Some provocative (?) thoughts:
* Idea for a new spec: "Smart ways to produce HTML using XML tools".
* Idea for the XHTML5 section of the HTML5 spec: Add a "story"
  regarding when to *not* produce XHTML5 …

I suppose we agree:
* that XHTML5 syntax on the text/html Web, should be HTML5-compatible. 
* that 99% of the time, XHTML documents end up being consumed as HTML.

Bud do we agree
* that tools that do not output HTML5-conforming XML is an existing,
  real, problem?
* that most authors don't know what "putting an HTML parser in
  the XML tool chain" even means?

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.

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. By contrast, 
regardless how well the scope section is written, Polyglot Markup is 
hardly going to increase the number of authors that place an HTML 
parser in their XML tool chain. It is much more likely that such a 
scope section, if it gets cryptic enough, could leave many frustrated 
for no good reason and serve as snake oil blame ammunition.
leif halvard silli
Received on Sunday, 20 January 2013 00:19:21 UTC

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