Hi David,
On Jan 22, 2013, at 2:44 AM, David Carlisle <davidc@nag.co.uk> wrote:
> 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.
I think it would be useful to publish that document. Creating an extension spec is the best path to getting this change into HTML5, if you can get implementation support. For HTML 5.1, you could just file a bug to be considered by the new set of editors
For what it's worth, and speaking with my implementor hat on rather than my chair hat, it seems reasonable to support predefined entities for the one extra public identifier, given that at least one major browser once supported it without obvious compat issues. But this is an area where WebKit HTML parser experts would have to weigh in.
- Maciej
>
> 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.