- From: David Carlisle <davidc@nag.co.uk>
- Date: Tue, 22 Jan 2013 10:44:39 +0000
- To: Maciej Stachowiak <mjs@apple.com>
- CC: public-html@w3.org
On 18/01/2013 19:40, Maciej Stachowiak wrote: > My understanding was that the HTML5 spec rules just matched what > essentially all browsers already did for XHTML/XML parsing. If > that's not the case, it would be useful new information to know the > details. It isn't clear to me what the next course of action should be, this is a simple (but serious) spec bug that could have a one line fix inserted, preferably into HTML 5.0, or, if it of it misses the boat on that, in 5.1. But the longer a bug goes unfixed the longer the compatibility problem with implementations that implement the broken specification. I made a separate extension specification as that appeared to be required by the decision process for a bug being handled by a tracker issue, but the intention there is really just to make explicit what the change to the main HTML spec should be and to provide some rationale. So, we'd rather not go through the motions of formally proposing http://www.w3.org/2003/entities/2007doc/xhtmlpubid.html as a REC-track spec in /TR, however if that is required by the process we are prepared to do that. It would be simpler for everyone (and better for document production on the web) if the HTML spec was simply updated. As this would arguably be a new feature (although I'd rather just call it a fix to a broken existing feature) you may want to flag it as "at risk" if it goes in to 5.0 after CR Just to highlight that a minor implementation change is required. There has been no argument proposed that the change is not an improvement, the only reasons offered for not changing are compatibility issues, but as demonstrated in my last reply, the existing spec is not compatible with existing content and inconsistently implemented in current browsers so the compatibility argument is weak at best. David
Received on Tuesday, 22 January 2013 10:45:10 UTC