Re: XHTML character entity support

On Tue, Nov 3, 2009 at 4:49 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.
>

What you're saying is we should codify how _all_ user agents must
handle the doctypes on the blessed list, not just browsers.

That's just not going to work. I can already tell you that it won't
work for the ebook industry, which makes heavy use of XHTML.

>> 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?
>

What do you mean by 'different conformance classes'?

>> 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.
>

It seems to me as if the XML core already has, and the browser
companies don't like it.

>>> 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.
>

This is not an incremental change. Frankly, I'm not sure what it is.

>> 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.
>

What people? The browser developers? The web page developers?  Who has
to redesign? This is not a new situation. In fact, this situation is
pretty much the way it's been for years.

>> 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.
>

At this point in time, I'm waiting for Alexey to post a bug with his
proposed changes. I want to see what people want to put into the spec,
before I continue responding. Perhaps whatever it is will be innocuous
enough not to generate any additional concern. If not, then at least
we'll all be on the same page about what is being asked.

> Alexey, please forgive me if I misunderstood your concerns.
>
> -Boris
>
>

Shelley

Received on Wednesday, 4 November 2009 17:05:33 UTC