- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 6 Nov 2012 19:49:44 +0100
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Cc: public-html@w3.org
Daniel Glazman, Tue, 06 Nov 2012 19:04:19 +0100: > On 04/11/12 15:59, Lachlan Hunt wrote: > >> At the HTML F2F, I was asked to provide rationale for my previously >> filed formal objection to the Polyglot Markup specification. > > > Here's what I wrote in my comments on this spec during the may 2011 > LC vote: > > "Implementing myself a content editor for html5 (both > serializations), I am still uncertain about the usefulness of this > document, in other terms I doubt implementors will refer to this > document and really implement tools conformant to it. I think then > this document should leave the REC track and become a Note." > > Of course, I never got an answer. > > More than a year later, I still don't know why we have that document > on the REC track. It's still useless to me as an editor vendor. > I then support entirely Lachlan's objection here. You can at least have my answer: I think it was Boris who asked me, rhetorically, why one would author anything but HTML-compatible XHTML. First, when in XHTML mode, then BlueGrifon and SeaMonkey Composer are already relatively polyglot. (The only exceptions is, I think, the XML encoding declaration, which it inserts even for HTML files. Plus that it uses <meta http-equiv=* caontent=* /> - which never is allowed per HTML5, not even in pure XHTML5. It could even seem as if BlueGriffon adheres to the restriction to only have "safe" content inside <script> and <style>.) Second, if BlueGriffon were serious about polyglot markup, then e.g. BlueGrifofon’s Wizard function did not need to ask me choose between HTML formats and also did not need to ask me about the encoding. Also, for generated files, then I would be able to choose the format simply by changing the file suffix. I look forward to that day. -- leif halvard silli
Received on Tuesday, 6 November 2012 18:50:16 UTC