Re: null namespace Re: Next steps for the ARIA syntax discussion

HI Boris,

On May 23, 2008, at 3:15 AM, Boris Zbarsky wrote:

> Robert J Burns wrote:
>> I understand how you're reading it (with no contradiction), but I'm  
>> saying it is a mistake to read it that way.
>
> Since that way was confirmed by people who were actually involved in  
> writing this prose, I'm not sure what makes it "a mistake"...
>
>> one should keep this in mind whether writing a W3C recommendation  
>> or implementing one.
>
> At the same time, one can't just implement something different from  
> the recommendation if you think it improves the author experience.   
> Well, one can, but then one shouldn't claim to be implementing the  
> recommendation.
>
>> When an implementor reads the spec (especially a W3C spec) that  
>> should be foremost in their mind in shaping their reading (not  
>> trying to force a construed reading that avoids contradiction).
>
> I don't think any forcing happened here.
>
>> If an attribute is to be treated as from a certain vocabulary, then  
>> why should it be appearing in separate namespaces?
>
> Maybe I'm missing something here.  Can you give an example where  
> this happens?
>
>> Well, that's the question I keep asking. Could you share with me a  
>> few of the problems the null namespace avoids. I'd be happy to  
>> concede to your position, but I've been hard-pressed to find what  
>> advantages there might be.
>
> Consider the following problem.  How does one create an HTML image  
> element with a "src" attribute that points to your image?  Right now  
> one can do:
>
>  var img =
>    document.createElementNS("http://www.w3.org/1999/xhtml", "img");
>  img.setAttribute("src", "whatever");
>
> and this works in both XHTML and HTML..  Now if the src attribute  
> had to be in the XHTML namespace, the author would have to use  
> setAttributeNS.  Would that work in HTML?  I sort of doubt it.  Plus  
> it would have the additional aggravation of having to pass the  
> namespace to the setAttributeNS call.
>
> Consider also styling such a document.  Say you want to match images  
> that have an src attribute.
>
>  img[src]
>
> would not match them in HTML if the XHTML namespace has been set as  
> the default namespace and the default namespace applies to attribute  
> selectors.  If it doesn't apply to them, why not?  If it does, you  
> get compatibility issues between HTML and XHTML.

I don't see how that would break. Not specifying a namespace does not  
imply null namespace, does it? If it did, that would already break  
HTML / XHTML appendix C compatibility for selectors such as:

a {color: red;}

  The things that WOULD break would be:

• CSS that expected null namespace (I haven't read the draft CSS  
namespace thoroughly, so I don't even know how an author specified the  
null namespace for attributes or elements)
• Perhaps some DOM methods, but I can't think of any effected by  
changing the null namespace to instead a means for scoping

Also, using CSS to select elements are much greater than using them  
with attribute selectors. So if it works now with element selectors  
and XML namespaces then there's no reason it couldn't work the same  
for attributes.


>> I'm not sure this is the case. There may be some other minor  
>> problems, but it certainly wouldn't have to create problems with  
>> since the DOM implementation could be changed the same time the  
>> parsing implementation was changed.
>
> So setAttribute should either not follow the DOM spec or the DOM  
> spec should be changed?

The browsers are not following the DOM spec now in terms of  
namespaces, so don't pretend that attributes must somehow be  
different. I'm saying let's just have the implementations violate the  
DOM spec in the same ways their violating the DOM spec for elements.

> Let me see if I have it straight:  if we change XML Namespaces,  
> HTML, DOM, and CSS in lockstep here, in all UAs at once, it'll all  
> work afterward.  That may be, but that that's a big counterfactual  
> to assume.
>
>> Since I'm saying that we should simply stop having elements or  
>> attributes in the null namespace (within a compound document), then  
>> it may not be such a difficult problem.
>
> It breaks any existing content that uses attributes from script,  
> unless you also change all the DOM implementations (and the DOM  
> specs, since you're proposing changes that would violate the DOM  
> specs) somehow...

Again, it wouldn't break such documents if he DOM is also changed to  
match the parsing. In other words creating attributes with a DOM  
method involving namespace argument that is null would not create an  
element that is in the null namespace but instead create an element  
that is not yet attached to an element. Once the attribute is attached  
to an element it would be given the namespace of that element (if it  
didn't already have one).  So in a compound document, leaving the  
namespace argument null is a convenience (similar to the convenience  
of scoping and leaving off the namespace prefix) but that doesn't  
imply that the attribute needs to be in the null namespace. To me this  
is the proper reading of the spirit of the namespaces recommendation.  
Obviously we could ask some of the participants in creating that  
recommendation, but that's the general thrust I read in that  
recommendation.

My point is that this is fixable in XML namespaces. It is also  
something that shouldn't be reproduced in text/html namespaces.  
Finally, the reason this topic arose is that some (e.g., Anne) of the  
same people who don't care about this problem in the situations I've  
outlined claim that the problem would be an undue burden for authors  
in the case of ARIA. Why is that? I agree it is an undue problem for  
authors. But it is an undue problem for authors with the current  
implementation of XML namespaces too.

Take care,
Rob

Received on Friday, 23 May 2008 10:22:40 UTC