Re: ISSUE-4: Versioning, namespace URIs and MIME types ISSUE-60

Hi Ian,

On Feb 19, 2009, at 11:12 PM, Ian Hickson wrote:

> On Thu, 19 Feb 2009, Robert J Burns wrote:
>>
>> HTML5 has specified error-handling for the 'img' element. I guess  
>> it is
>> not an issue then. But you began this particular thread with an  
>> example
>> of an 'img' element which you claimed was a compatibility problem in
>> that alternate text for the image might either be expressed as the  
>> value
>> of the 'alt' attribute or in the contents of the element.
>
> The only problem I was trying to show is that an implementation that
> implements both XHTML2 and XHTML1 in the same namespace would be faced
> with an irreconcilable difference in semantics when an element in the
> "http://www.w3.org/1999/xhtml" namespace with the tag name "img" is
> created without any other context, since the two specs have  
> conflicting
> requirements (or rather, since XHTML2 has requirement that conflict  
> with
> the requirements imposed by legacy content). This is merely intended  
> to
> show that if XHTML2 does use the same namespace as XHTML1, the two
> languages cannot be sanely implemented in the same user agent.

Certainly it can be implemented by the same user agent, it just  
requires error-handling specified either in a standard fashion or by  
each individual user agent.

> The point being that HTML5 has no real choice regarding what  
> namespace it
> uses,

There are always choices, but if you simply mean we would prefer to  
use the existing namespace, I agree.

> and that any compatibility issue that XHTML2 has is actually not a
> clash with XHTML5 but a clash with XHTML1.

We still haven't identified any clashes at all (none that cannot be  
handled by some basic error-handling). The failure of HTML5 to specify  
such error handling is a problem as far as I am concerned. It is very  
low hanging fruit to permit richer content models in an XML  
serialization of HTML5 and, if we specify any vocabulary enhancements  
at all, that would be the place to begin.

> I also indicated that in my
> opinion this is not necessarily even a problem for XHTML2, since it  
> may be
> (as indicated by XHTML2 itself in section 1.1.2) that "strict  
> element-wise
> backwards compatibility is no longer necessary", and thus that  
> software
> need not implement both languages at all.

I think you're making way too much of this one sentence. Its hard to  
imagine this was intended as a normative criterion. In any event  
whether it is necessary for a vocabulary specification to concern  
itself with backwards compatibility is a completely separate issue  
from whether a UA implementing that vocabulary need concern itself  
with backwards compatibility. And I don't think you can read that  
sentence to say anything to such an implementation about its  
requirements, recommendations or options. HTML5 takes on that task of  
dealing with backwards compatibility itself, and XHTML2 does not. But  
from that we cannot conclude that an XHTML2 implementation does not  
need to deal with backwards compatibility (only that the XHTML2  
recommendation does not). Moreover, HTML5 in this particular case  
deals with backwards compatibility by simply refusing to add new low- 
hanging fruit capabilities that would be beneficial for authors and  
users alike. This isn't a case to be celebrated as HTML5 being  
backwards compatible, but rather HTML5 simply fails to add some  
obvious new features. Of course if HTML5 adds no new features its easy  
to claim it has focussed on backwards compatibility.

To make this clear, it would be very easy to HTML5 to permit fallback  
contents within an 'img' element and to specify that that content  
should be treated as alternate text for an image over the contents of  
the 'alt' attribute, if both were specified. If only one is specified  
then that serves as the alternate text for the 'img' element. XHTML2  
could specify the same type of error-handling if it wanted to address  
backwards compatibility. Though both can change nothing about their  
specifications and still claim to have error-handling built in, both  
specifications fail to deal with the opposite method of specifying  
alternate content. In my view that is still an incomplete  
specification of error-handling.

Take care
Rob

Received on Friday, 20 February 2009 04:59:17 UTC