Re: Polyglot markup and authors

Jirka Kosek, Wed, 30 Jan 2013 23:18:44 +0100:
> On 28.1.2013 5:43, Leif Halvard Silli wrote:

> http://www.zdrojak.cz/clanky/polyglot-aneb-webovym-koderem-pod-oboji/

> 
> The conclusion is simple -- except very narrow use-cases usage of
> polyglot doesn't make sense. […]

Google-translated, the article says: «The only case is when the site 
must go processed using existing tools based on XML.» Comment: That 
Henri's parser has been designed to solve that case means that that use 
case is important enough. Note therefore, as Sam has pointed out, that 
Henri's parser supports exactly one programming language. 

The article also says: «XHTML sending the wrong MIME type is basically 
functional, but you need to pay attention to some details.» And the 
description of how you do that, is what you find in Polyglot Markup. 
Being a description of that, is perhaps Polyglot Markup's most 
important justification.

And our debate tells me that an authoritative description is good to 
have: In this our debate, Henri claimed that the greater than (>) is 
forbidden in polyglot markup. No it is not. Further, you describe 
white-space in your article, and before we started to write Polyglot 
Markup, myths about that proliferated in the HTMLWG. Now, we can 
instead point to Polyglot Markup.

> Personally I don't have preference whether polyglot should or shouldn't
> be REC.

There will be an option for "no preference" in the poll, I think. 
However, I would ask you to consider voting yes ...

> Leif you seem to put a lot of energy to promoting polyglot.

Indeed.

> I have seen
> something similar 10 years ago -- a lot of energy was put into promoting
> XHTML

Thanks for the comparison. I'm blushing …

> -- unfortunately this created many false expectations on the web
> developers side. We shouldn't repeat this mistake again with polyglot.

Did you - or did you not - have a preference? And what possible mistake 
is it that you think we could make? Much is said about waste of time. 
But is it a waste of time if BlueGriffon offers a bug-free Polyglot 
Markup option? Is it a waste of time if Sam creates Ruby tools that 
produces polyglot markup? 

Everything in Polyglot Markup is fully compatible with both HTML5 and 
XHTML5. Thus the this talk about mistake and other cries of danger and 
reference to "Appendix C", appears to have no basis whatsoever. It is 
just an all to easy reference to make.

I agree that we should not - and we do not - promote Polyglot Markup as 
Appendix C. Appendix C was not normative. We should not repeat the 
mistake of making an non-normative polyglot description.

But what is is the risk with Polyglot Markup? Polyglot Markup 
*promotes* HTML5 - the text/html-serialization by being XHTML code that 
is absolutely and completely obedient to the HTML serialization's 
rules. Polyglot Markup does as well implement many important XML best 
practises.

I (dare say that) I know you are 100% behind all those best practices. 
Therefore it is a mystery for me you aren't fully behind Polyglot 
Markup. 

Let me take an example: Take a look at BlueGriffon. Did see all the 
messages to Daniel about how BlueGriffon should only offer UTF-8 
support for its XHMTL output? And how the XHTML output should not 
include a XML declaration. And so on and so fort? I said it. Henri 
said. Some others said.

So what did come out of that? Well, you know what? BlueGriffon now 
offers those best-practices. Not as the sole output. But as one of the 
outputs. That output option has also gotten a name. It is called 
Polyglot Markup.

Is it the name that is wrong? Is it the name that makes you blind?

So where is the danger? Where is the possible mistake?
-- 
leif halvard silli

Received on Wednesday, 30 January 2013 23:41:42 UTC