Re: Polyglot Markup Formal Objection Rationale

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