Re: Extend use of namespaces

Actually, based on the CSS Namespace specification I think that you are mistaken.

The CSS namespace specification http://www.w3.org/TR/2008/CR-css3-namespace-20080523/#css-qnames says:
* "It does not define where such names are valid or what they mean: that depends on their context and is defined by a host language..."
* "CSS qualified names can be used in (for example) selectors and property values as described in other modules"
* "The syntax of delimiting namespace prefixes in CSS was deliberately chosen so that these CSS clients would ignore the style rules rather than possibly match them incorrectly."

It explicitly says that it is intended to be used in property values and not just "to let CSS address namespaces used in the styled document".

"(for example)" implies to me that these are not the only usages to be made of them, and that the intent was that they would also be used in other places. The only specification that uses them at the moment is the selectors but that is not 

I think that the syntax CSS already has is perfectly fine and I think it would be much more confusing to have 2 separate mechanisms.

----- Original Message -----
> 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 17:23:05 UTC