W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

[Bug 12725] Document should be on the Note-track

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 May 2011 01:22:27 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QPPHP-00046r-1n@jessica.w3.org>

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no

--- Comment #1 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-05-26 01:22:24 UTC ---
(In reply to comment #0)

> These are guidelines, and as such, they should be non-normative
> descriptions referring to the normative requirements in the HTML
> specification itself. If this document is to be published, it
> should instead be on the Note-track.

It should be added that TBL's initially gave this description of what the TAG
was looking for:

]] The document should be couched as a specification. It specifies a set of
documents, defined by various constraints,  most (though not all, because of
the constraints on what scripts do) of which can be checked by a validator.  [[


These suggestions from TAG/TBL are reflected in the name of the document:
"Polyglot Markup: HTML-Compatible XHTML Documents".

The word "guideline" doesn't really seem fitting for a document that aims to be
very accurate in describing the subset of XML and HTML. A guideline can be
deviated from - and you could still be claiming to "be polyglot".  Whereas a
specification does not allow such deviation.

There are at least two definitions of "polyglot": parallel syntaxes and shared
syntaxes. E.g. "<p></p>" is a shared syntax which both XML and HTML understand.
Whereas the use of "xml:lang" and "lang" on the same element, is an example of
parallel syntax where the one language more or less ignores the syntax of the
other language - what counts is that the net-effect of xml:lang in XML and lang
in HTML, is the same.

Henri, who also would like to see the document become a Note, has often applied
a very strict defintion of polyglot markup:

]] While I agree that in this case the DOM difference does no harm, relaxing
goal from "identical" to "compatible" is a definitional slippery slope.[[

TO WHICH ONE COULD ASK: Making it a note should of course not be interpreted as
an invitation to create a document which follows a "definitional slippery
slope". But nevertheless: A very strict and accurate definition does lend som
support to the specification route.

OTOH: serving a page as polyglot markup does not always lead the author to the
goal of having a document that works equally well as XML and as HTML. In a
given situation where a document is served as XML to some UAs and HTML to
others, it might therefore be beneficial - depending of course on the goals of
the author - to add XML-incompatible, browser specific JavaScript (aka
HTML5shiv) on the HTML-layer. And if doing such a thing should be seen as a
failure to create a polyglot markup, then - clearly, there is one usecase less
for polyglot markup.

OTOH, again, for non-XML parsers, one might add conditional comments, so that
the page, formally isn't breaking with polyglot markup ...

THEN AGAIN, polyglot markup should of course not be seen as goal in itself. And
it could perhaps with some right, be claimed that, if "polyglot markup"
represents a specificaiton, then it *does* become more of a goal in itself. 

It could seem as if those who are opposed to Polyglot Markup being a spec are
focused on polyglot markup as a strategy for catering for HTML5-incompatible
browsers: The idea sought propagated seems to be that Polyglot Markup should
not be seen as "the" strategy. Instead HTML5shivs etc are a better strategy.
Henri's comment in the Last call poll could be interpreted that way -  see bug
12790. But then again, when polyglot markup discusses javascript, it currently
focuses on scripts that work exaclty the same in HTML and in XML, so from that
angle it doesn't formally apply.


 * PRO: The spec can be couched as a spec but  *also* as a guideline.  (The
principles can be useful even if one does not follow them 100%)
 * PRO: A specification should have better chances of e.g. validator support.
 * CON: Dangerous if the needleye to is so small that no one are able create
such a page?


We should keep in mind that authors would have different goals of using
polyglot markup:

* some are interested in the XML aspect, in itself, for some reason. [To my
knowledge, Polyglot Markup represents the first definition of XHTML which
doesn't rely on a DTD, which is of interest in  itself - from a XML point of
view. Of course, our mileages might vary ...] The view that Polyglot Markup
represents XHTML5, is therefore sometimes heard. (Personally, I don't mind if
it is perceived that way, as I'm interested in tool support for polyglot markup
...) The XML-aspects of Polyglot Markup are, on the whole, very interesting as
it is the first real description of HTML-compatible XML.

* Some are interested in the browser compatibilty aspect - for some reason.
(This interest represents a form of XML-focus as well, one could claim, as one
then trust the extensibility of XML ).  If the focus is on browser
compatibility, then - as always when Web authors create pages, this is a matter
of testing what works. If something non-polyglot gives a better result, broadly
speaking, then the author will probably follow that path.

* While others might be interested in the "XML tool chain" aspect.  For tool
chains, I suspect that round-tripping is important - thus the tool chain use
case is interest in a strict definition.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 26 May 2011 01:22:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:50 UTC