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

[Bug 12792] Publish the polyglot 'Sample Page' as 'application/xhtml+xml'

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 May 2011 11:41:21 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QPYwL-0006PV-HZ@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 #2 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-05-26 11:41:20 UTC ---
(In reply to comment #1)
> Isn't the entire point of attempting to make a polyglot document is for the
> purpose of serving it as text/html?

HTML5 constitutes «A vocabulary and associated APIs for HTML and XHTML». The
important point, thus, is the vocabulary. The MIME type is just a vehicle.

Why should Polyglot Markup describe how to constrain oneself to javascript
scripting that works in both XML and HTML if only 'text/html' should be used?

> If you want to serve a document as XML, why take the time and trouble to
> attempt to make it a polyglot document? Why not instead just make sure it's
> well-formed XML, and serve it as such?

You say "if you want to serve it as XML". As told above, I think the purpose of
using polyglot on the World Wide Web (as opposed on ly use it inside a tool
chain) is an issue of wanting to make use of the HTML5 vocabulary as broadly as
possible. Thus, if someone chooses Polyglot for WWW-purposes, then it is a
strategy choice - a way to achive compatibility.

If polyglot markup is selected only as a XML tool chain strategy, then you can
in fact publish it it in a non-polyglot way - that is: you don't need to
constrain yourself w.r.t. to scripting.

That said:

* I agree that "want to serve XHTML as HTML" definitely is one of the usecass
for polyglot markup. This is also clear form the title: "HTML-compatible
XHTML". Because, after all, we do not want to see the kind of XHTML that e.g.
XML 1.0 uses, where an anchor element affects the entire paragraph because the
author apparently thinks that the "/>" makes the element end: [*]

<h2><a name="sec-intro" id="sec-intro"/>1 Introduction</h2>

[*] http://www.w3.org/TR/xml/ 


* Wanting to serve as XML because this allows legacy user agent to support the
new HTML5 elements, is definitely a use case. Sam's, blog is one such use case,
AFAICT. This use case has also been described in the WHATwg blog, on March the
18th 2009, by Simon Pieters (though he didn't mention polyglot markup back

So ultimately, the main benefit of HTML-compatible XHTML is that it gives you
more freedom w.r.t. how to serve the page. Which in turn gives you better
opportunity to choose the serving method that gives you best compatibility. 

And in this case - for this Sample Page, serving it as XML increases the Web

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 11:41:23 UTC

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