W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > November 2009

Re: XHTML character entity support

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 03 Nov 2009 20:16:23 -0500
Message-ID: <4AF0D5E7.9030201@mit.edu>
To: Shelley Powers <shelley.just@gmail.com>
CC: "public-xml-core-wg@w3.org" <public-xml-core-wg@w3.org>, "public-html@w3.org" <public-html@w3.org>
On 11/3/09 7:14 PM, Shelley Powers wrote:
>> 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.

No, I actually don't care that much about how non-browser UAs handle 
this, actually.  They can do whatever they want as far as I personally 
am concerned.

>> Some UAs will, some won't.  This is why we have different conformance
>> classes, no?
>
> What do you mean by 'different conformance classes'?

http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements

If that list doesn't match reality, it should be fixed.

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

XML core has said "you can have behavior A or behavior B and it's all 
fine by us".  In practice, behavior A is a non-starter on the web.  All 
the browsers that support XHTML implement behavior B.  We'd like to make 
life easier for future browser makers by making it clear that in this 
particular case behavior A is not in fact OK, so they don't have to 
discover it the hard way.

Since the details of why behavior A in this case is not OK are not 
generically applicable to all XML, this can't be resolved in XML core. 
I don't know how to make this any clearer....

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

It's a specific requirement on certain classes of UAs that claim support 
for XHTML1.  Sounds like an incremental change to me.

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

Yes.

> The web page developers?

No.

> Who has to redesign?

People who implement a new browser assuming that not handling HTML 
entities in XHTML1 is ok.

> This is not a new situation. In fact, this situation is
> pretty much the way it's been for years.

YES!  And it's a bad situation, and we're trying to get out of it! 
Assuming you were referring to the "you must spend several thousand 
man-years reverse-engineering to implement a web browser" situation.  I 
realize you happen to not care about that problem, but I do.

-Boris
Received on Wednesday, 4 November 2009 01:17:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:41 UTC