Re: Extend use of namespaces

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 15:46:57 UTC