- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 29 Jan 2008 12:37:49 +0100
- To: temp17@staldal.nu, public-html-comments@w3.org
Disclaimer: still not an official WG response. On Tue, 29 Jan 2008 10:56:05 +0100, <temp17@staldal.nu> wrote: > > Henri Sivonen skrev: >>>> or just use the HTML-compatible subset of the XML syntax. >>> >>> That would work, but why doesn't the HTML5 WD recommend that? >> Browsers won't parse text/html as XML, so taking the trouble to jump >> through additional hoops would be a waste of authoring effort. > > That would make it possible (in most cases) to serve the same content as > both text/html and application/xhtml+xml. There are benefits and drawbacks with doing this. Benefits: * You can feed your own content to your own server side XML tools if your toolset doesn't feature an HTML parser yet. * You can embed MathML and/or SVG inline and have it work for existing XHTML browsers and degrade reasonably in HTML-only browsers. * You can catch a subset of markup errors on your own blog by just loading it in your XHTML browser. Drawbacks: * You will discriminate users with XHTML browsers as soon as an error slips through your system. * You're exposed to scripting and CSS differences between HTML and XHTML that would have been the same if you used only text/html. * If you don't generate the HTML and XHTML versions using HTML and XML serializers respectively, you're also exposed to parsing differences such as <script> being a CDATA element in text/html but not in XML, or that character entities such as isn't available in XML. These lists aren't exhaustive, but my point is that for some authors the benefits outweigh the drawbacks (or some drawbacks don't apply to them), for others the benefits don't apply but the drawbacks do. So it's not clear to me why the spec should recommend something that just has drawbacks for many authors. -- Simon Pieters Opera Software
Received on Tuesday, 29 January 2008 11:38:06 UTC