Sorry Gabriel, perhaps I should have been more specific. You example shows commas being used to separate values being passed to a function which resolves a clipping region - this seems pretty standard and intuitive...
On the other hand - what I am talking about is modules (like background or transition) whose values can be multiple (not expressed in shorthand, but actually multiple) to reflect something like multiple layers of a background - as described (again, for example) here: http://www.w3.org/TR/css3-background/#layering background-image: url(flower.png), url(ball.png), url(grass.png); background-position: center center, 20% 80%, top left, bottom right; background-origin: border-box, content-box; background-repeat: no-repeat; This means that a particular element has more than one value for a module property - which isn't generally the case prior to this in CSS. A serious distinction between your example and mine is that given that your example is merely providing values to a function its meaning is generally pretty obvious with or without the commas and its impact is very contained. There is really nothing in or about CSS that would lead me to believe that I could override the third argument somehow (definitely correct me if I am wrong about that) - however, overriding individual properties with via a rule with greater specificity or processed later is exactly the sort of thing that CSS has been designed to do since day 1 when it comes to my case - and I don't see how this allows it. Given the array-like nature - CSS has no (to the best of my knowledge) good way of dealing with those kinds of things that would seem to be "common"... As far as I can tell, you wouldn't be able to create a rule which added a new layer, nor a way to identify the right layer in an array/list to override a property on. There is also potentially some disagreement and lack of clarity in terms of how properties will balance in there... The drafts still have lots of red comments and I've seen some discussion that it might not be 100% consistent between browsers (we would expect that for a while) or even maybe between module specifications. I think that reading what people were thinking when this was getting drafted would be very informative to me in trying to understand the decisions, considerations and direction. -Brian On Fri, Jun 10, 2011 at 11:16 AM, Gabriele Romanato < [email protected]> wrote: > Hi Brian. > The problem with CSS commas is that they're not required in all cases. > Consider this example: > > #test { > clip: rect(10px, 10px, 10px, 5px); > } > > CSS specs say that for the clip property commas are optional, but some > browsers don't allow them to appear between values, meaning that for some > browsers they're not allowed, even though that specs say the contrary. > > This happens also for the new properties. In other words, commas are > property-dependent, because the CSS syntax says that they can be considered > as separators. > With the CSS3 properties, things get more complicated with the widespread > use of browser-specific extensions (aka vendor prefixes). > > I think that you should document yourself by reading the browser-specific > implementations, not the specs, because the properties you mentioned are so > far supported only via vendor prefixes. > When browsers will implement them without prefixes, then you can go > straight to the official CSS3 module specs and read how they actually work. > > HTH :-) > > Gabriele Romanato > > -- > http://www.css-zibaldone.com/ > http://www.css-zibaldone.com/test/ (English) > http://www.css-zibaldone.com/articles/ (English) > http://onwebdev.blogspot.com/ (English) > > ______________________________________________________________________ css-discuss [[email protected]] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
