W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: Extend use of namespaces

From: Peter Linss <peter.linss@hp.com>
Date: Fri, 17 Sep 2010 09:38:42 -0700
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style <www-style@w3.org>
Message-Id: <1654ECB8-9E02-4D5A-B980-7279E548CBA6@hp.com>
To: Paul Duffin <pduffin@volantis.com>
The whole purpose of namespace support in CSS isn't to add namespaces  
_to_ CSS, but to let CSS address namespaces used in the styled  
document. Since those namespaces are only exposed in element types and  
attributes, that's where namespaces apply.

Overloading that mechanism for other purposes would just lead to  
confusion and problems down the road. If there's ever a need  
identified to add namespaces to CSS itself we'd create a new syntax  
for that to keep it separate.

On Sep 17, 2010, at 8:46 AM, Paul Duffin wrote:

> It seems to me to be incredibly inconsistent that namespaces can be  
> used for one part of CSS (type selector) and not in other places.
> ----- Original Message -----
>> On Fri, Sep 17, 2010 at 6:58 AM, Paul Duffin <pduffin@volantis.com>
>> wrote:
>>> CSS 3 selectors adds namespace support but at the moment that is
>>> only for elements but extending it to cover other 'identifiers',
>>> would have a number of benefits:
>>> * It could replace the convention that browser vendors have to use a
>>> vendor specific prefix starting with a '-'.
>> It appears to be replacing that convention with a nearly identical
>> one. Rather than -browser-foo, you have browser|foo. I'm not seeing
>> any particular benefit here.
> To be honest the whole vendor prefix things is a mess. At the moment  
> if I want to use various CSS 3 features, properties etc. across a  
> wide range of devices I have to define every single vendor specific  
> prefix, even though the vendor is implementing a standard.
> e.g.
> .... {-webkit-.....; -moz-......; -o-......; ......;}
> The CSS 3 specification is changing over time and as a result the  
> meaning / allowable values of properties change, while still using  
> the same name. Once a vendor has implemented one version then if it  
> changes they will find it difficult to support the new version  
> without breaking anything. We could end up with a situation where  
> each browser vendor has to have multiple prefixes, e.g. -webkit- for  
> the first version of a property, -webkit2- for the next version of a  
> property, -webkit3- for the next version and so on.
> The prefix 'convention' provides no indication of the version of the  
> specification that is being implemented.
> When it comes to 'interim' implementations there is no need to have  
> browser specific prefixes, instead the relevant CSS specification  
> can define namespaces that are used until it is standard.
> e.g. An author would just have to write:
> @namespace fbox http://w3c/css-flexible-box-2009-08
> ... {display: fbox|box; fbox|box-flex: 1}
> And that would work on any browser that supported that version of  
> the flexible box specification. Already better than having to add 4  
> copies of each property, one for each vendor prefix.
> If the standard was changed then they would have to extend that:
> @namespace fbox http://w3c/css-flexible-box-2009-08
> @namespace fbox2 http://w3c/css-flexible-box-2010-05
> ... {display: fbox|box; display: fbox2|box; fbox|box-flex: 1; fbox2| 
> box-flex}
> Still better than having -webkit- and -webkit2- copies.
> Once the standard was finished then you could remove the namespaces  
> altogether, e.g:
> .. {display: box; box-flex: 1}
> The above situations gets MUCH worse when using vendor specific  
> selectors as they cannot be combined because an invalid selector  
> will invalidate the whole rule. That means you have to copy the  
> whole rule.
> Whether this is something that you want to do right now, do you  
> think that the use of | as a prefix/name separator (akin to :) could  
> be protected in the syntax so it is not used for any other purpose.  
> That way you can always add support for it in future.
>>> * It would allow custom pseudo elements to be declared and used
>>> within XBL 2.0. At the moment it predefines a number of 'generic'
>>> pseudo elements http://www.w3.org/TR/xbl/#matching1 which is fine
>>> but it would be better if binding authors could define their own
>>> custom elements with names that are more specific to their binding.
>> As Anne said, we can solve this problem for XBL by just introducing a
>> new pseudoelement. Extra complexity atop that isn't necessary.
> I don't think that allowing a pseudo element name to be namespaced  
> is all that complicated.
Received on Friday, 17 September 2010 16:39:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:47 UTC