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

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

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

> I've already said what would be easier: that is it is much easier for 
> authors to not have attributes from the same vocabulary in two different 
> namespaces.

I'm still not sure I have seen an example of this.

> How would it make it more difficult to author XHTML?

By adding incompatibilities with HTML that prevent the same page working 
right in, say, IE as HTML and Safari as XHTML.

> I think 
> part of the problem here is that you've become so accustomed to thinking 
> about things in one way that you're not considering how this could be 
> different.

I've considered it pretty carefully, actually, and I think either 
approach works reasonably fine in a vacuum.  Transitioning from one to 
the other is pain without end, though.

> It's talking about two different things technically, but those two 
> different things should be mapped one-to-one to make namespaces work 
> smoothly (and other parts of the spec make this clear).

Uh...  No, I don't see how that makes much sense.  HTML itself has cases 
where the same attribute means different things on different elements, 
so even there it doesn't make much sense to talk about the semantics of 
that attribute "in the HTML namespace": you have to know what element 
it's on to know what it means.

> It's been a while since I've worked on this, but surely you can 
> understand that having the same attribute in separate namespaces is a 
> problem.

You keep saying this, but I have yet to see an example of this happening...

> The point is the null namespace needlessly makes 
> authoring compound documents more difficult (for no reason as far as I 
> can tell).

I'd love to see an example where it actually causes a problem.  I've 
been trying to construct one and failing.

> Aaron mentioned XSLT. XEvents is another XML 
> vocabulary involving attributes that can be used on both foreign and 
> domestic elements.

You mean that there are xev:* attributes that mean the same thing no 
matter what element they're on?  That seems reasonable...

> I think the problem can be fixed now (rather than later) with serious 
> damage to existing content. However, it needs to be fixed especially 
> before CSS3 namespaces become widely used (that's an area where I think 
> it could require some transitioning work).

CSS3 namespaces is pretty widely used in some circles.

>> Of course if implementations don't (e.g. can't) implement the spec as 
>> written, that's no good for authors either.
> 
> I think you're underestimating implementors.

Speaking as an implementor, I don't think I am.

> However, there's nothing to 
> prevent an implementation that makes sure every element and every 
> attribute in a compound document is in a namespace.

Except web compat and having to rewrite a whole lot of code and change a 
lot of specs and hope you got all the corner cases?  Probably not.

-Boris

Received on Friday, 23 May 2008 03:16:49 UTC