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

[Bug 12790] New: Polyglot markup: WWW usecases + "alternative solutions that have been identified"

From: <bugzilla@jessica.w3.org>
Date: Wed, 25 May 2011 22:33:54 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-12790-2486@http.www.w3.org/Bugs/Public/>

           Summary: Polyglot markup: WWW usecases + "alternative solutions
                    that have been identified"
           Product: HTML WG
           Version: unspecified
          Platform: All
               URL: http://www.w3.org/TR/html-polyglot/#introduction
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML/XHTML Compatibility Authoring Guide (ed: Eliot
        AssignedTo: eliotgra@microsoft.com
        ReportedBy: xn--mlform-iua@xn--mlform-iua.no
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, eliotgra@microsoft.com


a) describe how Polyglot Markup can on the WWW: content negotation etc 
    (currently only "XML tool chains" are listed as a use case)
b) describe alternatives to using Polyglot Markup on the WWW:
     use of "modernizing" javascript libraries, browser specific markuip via
     conditional commments etc.


Henri made this comment in his no vote in the Last Call poll:

]] I think publishing this document on the REC track sends the message that the
W3C encourages Web authors to use polyglot markup and I think such implied
encouragement would be bad due to the cost/benefit characteristics of using
polyglot markup to solve problems compared to alternative solutions that have
been identified. [[


(1) Henri's "alternative solutions" remains to be identified. But the document
SHOULD point to alternative strategies.  Currently, Polyglot Markup only
describes when it is a useful choice, and says nothing about other ways to the
same goal. Which leads me to another point:

(2) The only use case mentioned by the document is "XML tool chains". The
document has so far not mentioned, as a use case, that polyglot markup might be
used when it is useful to serve XML to some user agents (due to the native
exensibility featurs of XML) and HTML to others. For instance, this is how Sam
Ruby uses polyglot markup in his blog, AFAICT.  Thus, together with this
strategy also belongs HTTP content negotiation: that some UAs get XML while
others get HTML. And as well: to this strategy also belongs the fact that some
legacy user agents "sniff" the .html extension as "text/html" even when the
HTTP header tells that it is XML.

I say this because I suspect that one of Henri's points is that another
strategy, rather than polyglot markup, is to use some kind of javascript
library to handle the less-capable user agents - instead of using
XML-plus-content negotiation. But before Henri's (possible) point make any
sense to discuss, the draft itself should not only list "XML tool chains" as
the sole incentitive to use Polyglot Markup, but should also list WWW use cases
for Polyglot Markup.

(3) An important "philosophical" problem arises when if a "HTML5 shiv"
javascript is added to a polyglot document: Can such a document be classified
as a "polyglot markup" document when it makes use of scripts which would not
have worked in XML? THe word "poly", btw, means "multi". Specifically, it does
not mean "duo" or "bi". Thus "polyglot" does not mean "biglot". I would say
that a non-XML compatible javascript could be added to a polyglot document.

QUESTIONS (relating to (3)): 
* Should be the definition of Polyglot Markup be tightened to say that it
defines the _biglot_ subset of HTML and XML? 
* Should the definition further be _expanded_ to say that that JavaScript
libraries can be used -  in ways which are not compatible with this biglot
subset - to create identical DOMs too?

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 Wednesday, 25 May 2011 22:33:56 UTC

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