Re: XHTML character entity support

On 11/3/09 4:13 PM, Shelley Powers wrote:
> What we're talking about now, is the XHTML serialization. That has
> always had doctypes, which have defined the external entities. It's
> only with the XHTML+RDFa doctype, or unknown doctypes, that we run
> into inconsistency issues, and that's only because 3 browsers throw an
> error, the other just spits out the original entity text.

I'm not worried about the XHTML+RDFa doctype or unknown doctypes at the 
moment.

> Hard coding information about how UAs are supposed to respond to
> entities for a doctype not in the blessed list

I'm talking about the spec codifying how UAs are supposed to respond to 
doctype that _are_ in the blessed list.  And that response needs to be 
as if the DTD were loading, for entity-dereferencing purposes, even if 
the UA is non-validating.

> Second that the UAs will all want to emulate browser behavior

Some UAs will, some won't.  This is why we have different conformance 
classes, no?

> Lastly, that this is an issue that
> should be resolved in HTML, rather than in the XML core.

I don't see how XML core can possibly resolve an issue specific to some 
XHTML DTDs.

>> Of course there's nothing in the Deliverables section directly addressing
>> this part of the scope...
>
> Of course not, because browser are not the only HTML UAs.

That's a non-sequitur, honestly.  We have deliverables that are somewhat 
browser-specific, and we could be missing this deliverable even if 
browsers _were_ the only HTML UAs.  The charter is just what it is.

>> So we're not _required_ to define this, but defining it is certainly within
>> our scope, if my charter-lawyering is not off.
>
> No, disagree: not in our scope. We're not browser nannies.

Our scope includes making incremental changes to XHTML1 as needed. 
That's what's being talked about here, last I checked.

> And that's the only whole purpose of having people from different
> interest groups involved in these specifications: HTML5 has to meet
> the needs of a diverse audience.

Sure.  I'm not sure why you're saying that one particular audience's 
needs should not be met in this case.

> I don't see it as a concern. If someone really wants to create a whole
> new browser, they should be able to read all the specifications and
> determine what they need to do.

Yes, exactly.

> They shouldn't have to follow a
> codified path, if there's another that works as well

That's the point.  For the XHTML doctypes there _isn't_ another path 
that works well at this point.  We'd do people a disservice if we made 
them think there is and force them to redesign based on unhappy user 
feedback as a result.

> We should minimize codifying extraneous non-standards based behavior
> as much as possible. How external entities are defined, and used, is
> the under the care of XML core, not HTML5.

External entities used in documents with the XHTML1 doctypes seem to 
fall pretty directly into this group's purview.

> Of course, we may not be on the same thread as the original author, Alexey, now.

I think Alexey's concerns were two-fold:

1) That the de-facto treatment of the XHTML1 doctypes is not actually
    specced anywhere.
2) That innerHTML behavior in such documents is not consistent with
    parsing of the document itself in some UAs, and is certainly not
    interoperable across UAs.

Alexey, please forgive me if I misunderstood your concerns.

-Boris

Received on Tuesday, 3 November 2009 22:50:08 UTC