Closed mezzoblue closed 11 years ago
I guess my main question is, if we did this, would anyone actually care? I'm not aware of real world scenarios where people are converting formats between parsers.
As a datapoint: there's been a number discussions in the html5 boilerplate issue tracker around supporting polyglot and never has it resolved in a compelling usecase that's persuaded the community.
No, it's not necessary, but it's a nice-to-have. If you have the choice between a stripped down HTML5 that is still valid (think removing optional quotes etc.) and one that (for a few extra characters) could be thought of as XHTML5, then it makes sense to me, to go with the more belt and braces version.
XSL is still very used and it's a W3C convention (I think the only official template language). It's not legacy stuff, it's actually pretty powerful and need the XHTML compatibility in documents.
Copying & pasting @GaryJones' comment on #1 here:
"One thing that would be worth reading is http://www.w3.org/TR/html-polyglot/ which outlines how to make the code into a polyglot document - one that can be read by HTML and XML parsers (i.e. can be served as HTML5 or the XHTML variant of HTML5). Since the markup is going to be controlled (rather than having user-added content), then it's perfect for something like this.
That would mean keeping in the otherwise optional closing slashes on empty elements (reverting #11)."