Re: Polyglot Markup Formal Objection Rationale

Daniel Glazman, Tue, 06 Nov 2012 21:18:18 +0100:
> On 06/11/12 19:49, Leif Halvard Silli wrote:
> 
>> 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, the <meta> issue is known and filed as a bug. Next version coming.

I wonder how you are going to resolve it. 

   1. Ditching <meta charset=*/> completely, always, from XHTML5?
   2. Only ditch <meta charset=* /> when user *doesn't* want XHTML5
      in UTF-8?

If you do 2., then why not ditch the XML encoding declaration too? As 
long as you are offering XHTML5, at all, then my prediction is that 
very soon you end up with the solution in Polyglot Markup.

> Second, if BlueGriffon did what you outline above - and I tried

Interesting, considering what you initially said about the lack of need 
for this spec ... But given that you still have that <meta> bug, it 
sounds as if it would be possible test of the idea - or ideas - more 
thoroughly.

> - users
> will still be pinging about it, requesting html5 or xhtml5 and encoding
> settings.

There is more than one way to approach it:

  1. Simplest: Add polyglot markup as a 5th format option 
     (in addition to HTML4,XHTML,HTML5 and XHTML5.)
  2. Lure: Always use polyglot syntax, but allow users to
     pick other names for it ... such as XHTML5 and HTML5 ...
     Because, after all <br/> is always conforming. As is
     the HTML namespace declaration.
  3. Settings. Allow more customization. Allow user to
     never be asked about syntax, for instance ... 

> Writing a spec is one thing; having it match the market and users'
> expectations is another one, sorry.

Sure. And implementing it in such a way that users accept what they 
didn't know that they needed - or realize that they get it - is a third 
thing.
-- 
leif halvard silli

Received on Wednesday, 7 November 2012 00:29:32 UTC