W3C home > Mailing lists > Public > public-html@w3.org > February 2013

Re: Extension Specification for XHTML5 entity definitions.

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 20 Feb 2013 16:38:13 +0100
To: David Carlisle <davidc@nag.co.uk>
Cc: public-html@w3.org
Message-ID: <20130220163813634881.92f67c87@xn--mlform-iua.no>
David, the XHTML5 entity definitions extension[1] shows this DOCTYPE 
example:

<!DOCTYPE PUBLIC
         "-//W3C//ENTITIES HTML MathML Set//EN//XML"
         "some/path/htmlmathml-f.ent"
       >

Since that DOCTYPE declaration would trigger quirks-mode if parsed as 
HTML, I suggest that you add the string "html " between "<!DOCTYPE " 
and "PUBLIC", 

<!DOCTYPE html 
          PUBLIC "-//W3C//ENTITIES HTML MathML Set//EN//XML"
          "some/path/htmlmathml-f.ent"
       >

I you want, I can file a bug about this, if the extension is 
represented in bugzilla …

Justification: According to the extension, the motivation behind the 
extension is that both Web browsers and XML tools should be able to 
handle HTML5’s named character entities equally. And thus, while the 
extension does not make the above doctype declaration conforming in the 
HTML5 syntax, the risk is high that documents with that DOCTYPE 
declaration would be served as HTML. Hence, the extension should 
present a DOCTYPE that triggers no-quirks mode. I would even suggest 
that triggering no-quirks mode should be a requirement.

[1] http://www.w3.org/2003/entities/2007doc/xhtml-pubid.html#background


Leif H

David Carlisle, Fri, 25 Jan 2013 08:45:30 +0000:
> On 25/01/2013 05:47, Maciej Stachowiak wrote:
>> FWIW in my day job we clone bugs all the time to track resolution
>> for multiple releases, when there is a stable branch and a trunk. So
>> it doesn't seem like an undue burden to me. Perhaps it does to
>> others though.
> 
> 
> It's not the actual cloning that's hard (or at least I assume it isn't)
> It's that it fragments discussion and makes it very hard to know where
> to send comments. In a more tightly controlled project in a day job
> things might be different but in a situation where there are external
> reviewers making comments and then it is an internal editorial decision
> in which version component they are handled, expecting the external
> reviewer to maintain separate bug reports (so separate discussion
> threads) for every component seems onerous to me.
> 
> That's a general observation about the process rather than this
> particular case. Some extra bugzilla bureaucracy is nothing compared to
> the overhead of having to push an entire specification through the REC
> track just to get one line added which should have been added two years ago.
> 
> David
> 
Received on Wednesday, 20 February 2013 15:38:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:37 UTC