This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
PROBLEM: The current version of Safari does not render the SVG of the SamplePage. The sample page: http://dev.w3.org/html5/html-xhtml-author-guide/SamplePage.html The reason for this is that the page is served as 'text/html', and that legacy user agents do not support SVG in 'text/html' mode. Therefore, the page should be served as 'application/xhtml+xml' instead, however preferrably _still_ with the file extension .html. BENEFITS: 1) Demonstrates the features of polyglot markup. 2) All HTTP-conforming, legacy user agents (including legacy Webkit based ones) will perceive it as XML, and will thus - if they support XML - render the SVG. 3) Some HTTP-non-conforming, legacy user agents will - due to the .html extension - "sniff" the document as "text/html". This will make then render everything *but* the SVG. (Alternatively, if the page is served with a .xhtml extension, those UAs will not render it all.) [Of course, a sub-issue here is how to provie some kind of fallback to those user agents.] HOWTO: Simply change the file name from 'SamplePage.html' to 'SamplePage.html.xhtml'. That's should be it (provided Apache is set up as it usually is). Do not change the link to the page. Then IE9 will treat it as XHTMl, while IE6-IE8 will treat it as HTML. Example page that does the same thing: http://www.malform.no/messages/issue-30.html http://www.malform.no/messages/issue-30.html.utf8.xhtml Additionally/Optionally, you cold also add "proper" content negotation too.
Isn't the entire point of attempting to make a polyglot document is for the purpose of serving it as text/html? 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?
(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/ However: * 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 then): http://blog.whatwg.org/supporting-new-elements-in-firefox-2 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 compatibility.
mass-move component to LC1
Created attachment 1025 [details] polyglot sample page on Safari Screenshot of the sample page in question rendering on Safari
AFAICT, the SVG in the polyglot sample page [1] renders beautifully in Safari 5.1 (7534.50), Internet Explorer 9 (9.0.8112.16421), FireFox 6.0, and Google Chrome (13.0.782.215 m). I've attached a screenshot of the page in the version of Safari I tested in. Thanks, Eliot [1] http://dev.w3.org/html5/html-xhtml-author-guide/SamplePage.html
(In reply to comment #6) > SVG in the polyglot sample page [1] renders beautifully in Safari 5.1 (7534.50), Back then it did not work. And it still does not workin Opera ... However, I understand that my focus on browser compatibility and browser tricks (such as content-negotiation, which could also have been an option) will not bring us forward. I will save the subject of browser hacks and browser tricks to another occassion ... Thus, let me instead focus more strictly on making the SamplePage demonstrate the featurs of Polyglot Markup. Because, as is, served as text/html and only as text/html, I don't feel that it demonstrates polyglot markup in any significant way - except, on the coding level. To really demonstrate that it is polyglot markup, the page be presented once as XML and once as HTML. HENCE: Couldn't you just publish the document as both XML and as HTML - two copies of same document, to demonstrate that that the page not only validates as XHTML and HTML but also can be consumed as both XHTML and XML? You could then change the following text: ]] You can view the page live at http://dev.w3.org/html5/html-xhtml-author-guide/SamplePage.html. [[ in to this: ]] You can view the page live, served as text/html, at http://dev.w3.org/html5/html-xhtml-author-guide/SamplePage-as-HTML. And served as application/xhtml+xml at http://dev.w3.org/html5/html-xhtml-author-guide/SamplePage-as-XML. [[ I note, btw, that the sentence before the above quote, contains a link from 'polyglot markup' to a section (http://www.w3.org/TR/html-polyglot/#dfn-polyglot-markup) which defines what polyglot markup by pointing out that it can be served as either HTML or as XML: ]] Polyglot markup is [ snip ]. It is recommended that these documents be served as either text/html (if the content is transmitted to an HTML-aware user agent) or application/xhtml+xml (if the content is transmitted to an XHTML-aware user agent). [[ PS: You could of course keep two copies of the same document. But in case you are afraid that the two could get out of sync, you could e.g. use Server Side Includes to publish a duplicate. This is simplest if you create an XML copy first, and the use aServer Side Include file to publish a HTML version: 1) * Create 'SamplePage-as-XML.xhtml' - the same file as now, but with a new name and with the '.xhtml' as suffix. * You do not need to include '.xhtml' in the public link, you can instead use a 'cool URI' to 'SamplePage-as-XML' without suffix (because W3.org supports content negotiation, so you don't ned to show the suffix to the public.) 2) * Create 'SamplePage-as-HTML.shtml' - this page should only contain the following string: <!--#include virtual="SamplePage-as-XML" --> * Refer to this page with a cool URI to 'SamplePage-as-HTML' Voila. You can now update the XML version, and it will be reflected in the .shtml version.
Rather than created an extra example page, I am going to treat this by the following note: The example document is served as 'text/html'. Some legacy user agents do not support SVG in when served up as 'text/html' as it is in this example. The example page could also be served as 'application/xhtml+xml' instead, with the file extension .html, maintaining adherence to Polyglot markup and enabling the rendering of the SVG.