Re: Extend use of namespaces

On Sun, 19 Sep 2010 12:47:14 +0200, Paul Duffin <pduffin@volantis.com>  
wrote:
> I really don't understand why you would want to replace a general  
> approach (namespaces) that will be familiar to everyone that needs to  
> use it with some special cases (:svg). Would you add special cases for  
> XForms, MathML, ..., as well? It seems like complicating things just for  
> the sake of it. The way in which namespaces were added to XML may not be  
> perfect but they work and they are effective. They mean I can take two  
> separate languages defined by two separate groups and use them together  
> even though that may not have been designed for that explicit purpose.

Yeah, in theory. In practice it is quite a bit of work and the languages  
need to be explicitly designed for it. E.g. you can only use other  
namespaced content in SVG in the <foreignObject> container. Again though,  
I'm not advocating adding special cases, I just have not seen the need.  
And so far all your arguments are from theory. From theory it is very easy  
to imagine the most complicated systems. (Which is one of the reasons we  
ended up with namespaces in the first place. There would be hundreds to  
millions of markup languages requiring a URL because otherwise the  
identifier would not be unique enough, yadayada.)


> Without them I would have to check for conflicts and pray that future  
> enhancements to those languages did not introduce conflicts.
>
> Namespaces are not as complicated as you make out, neither from an  
> author's perspective or from an implementation perspective.

I think you are wrong.

http://wiki.whatwg.org/wiki/Namespace_confusion


> CSS 2.1 states:
> "Pseudo-classes classify elements on characteristics other than their  
> name, attributes or content; in principle characteristics that cannot be  
> deduced from the document tree."
>
> So using a pseudo class for this purpose goes against that principle  
> because a document tree for a namespaced document will include  
> namespaces.

@namespace is not going away I think, not to worry. Having said that,  
changing prose of a specification because we have identified new needs is  
not at all unprecedented. Specifications are not untouchable. Rather they  
continuously evolve.


>> People have indeed suggested that browser vendors use a
>> common prefix, e.g. -wd1-box-sizing, which would be much shorter than
>> what you have here and have the same effect, but the CSS WG rejected  
>> that
>> because browsers will have implementation differences, and each wants
>> to have their own strategy. Feel free to disagree with that decision but
>> lets not add the cloud of confusion that is namespaces on top of that,  
>> as
>> they have absolutely nothing to do with it.
>
> Namespaces may not have been intended to be used this way but that does  
> not mean that there is no advantage in reusing the capability to do so.  
> I can't yet see a disadvantage, and no one has yet pointed one out.

More complex is a disadvantage I have pointed out. Maybe you do not accept  
it, but please...


> [...]

I have no interest in repeating this discussion. It has already been had  
here in the past, recently even:

http://lists.w3.org/Archives/Public/www-style/2010Jul/thread.html#msg48


> You are right, a prefix will do the same job as namespaces.
>
> You could just as well do (note no leading - as CSS specifications are  
> guaranteed not to use them):
>     ... {...; CR-css3-ui-20040511-box-sizing: border-box; ...}
>     ... {...; CR-css3-ui-20040511-box-sizing: content-box; ...}
>     ... {...; display: WD-css3-flexbox-20090723-box; ...}
>
> As you would:
>     @namespace ui "http://www.w3.org/TR/2004/CR-css3-ui-20040511/"
>     @namespace fb "http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/"
>
>     ... {...; ui|box-sizing: border-box; ...}
>     ... {...; ui|box-sizing: content-box; ...}
>     ... {...; display: fb|box; ...}
>
> So you could think of namespaces as a way for page authors to define  
> their own aliases for the 'prefix'. It will save both time and space.

Except there is no need to prefix it with the whole draft identifier. It  
could just be -wd1-, -wd2-, etc. as different drafts would not define the  
same property twice. And if they would we'd just increase the number.  
Anyway, we are not going in that direction.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Sunday, 19 September 2010 11:08:07 UTC