W3C home > Mailing lists > Public > www-style@w3.org > February 2012

[css-multivalued][proposal] Lists as first-class CSS citizens

From: François REMY <fremycompany_pub@yahoo.fr>
Date: Tue, 21 Feb 2012 18:37:44 +0100
Message-ID: <43DECC654A634338B138CC77BBA6D1A3@FREMY2>
To: "CSS 3 W3C Group" <www-style@w3.org>
Hi,

Based on my experience in the list, I gathered some attempts to “add” elements to a list property like “transform”, “background” or “font-family”. Here’s a proposal I make to solve that problem, in the long run. I called my proposal CSS Multivalued Properties but mayby someonelse can find a better name. Here’s some very rough draft I made about it :

  CSS Multivalued Properties

  While some properties have been extended in the recent years to include list support (aka variable numbers of identically formatted values using the same definition and usually separated by commas), lists are still considered as an atomic type in CSS. This is very unfortunate because there’s no way to add, remove or modify elements of those collections from multiple sources. Changing one element of the list requires the full knowledge about all elements of the collection, which is sometime impossible or undesirable.

  This specification introduces the concept of multivalued properties. A multivalued property is a property whose acts like an indexed dictionary whose each element has its own independent effect (ie: that is not influenced by other element in the collection). 

  Two kinds of indexes can be used in multivalued properties. The first one is an integer index, and the second is an identifier. The order of the elements inside a multivalued property is the following: (1) all the non-empty integer-indexed elements (in increasing order) followed by (2) all the non-empty identifier-indexed elements, ASCII-sorted.

  The equivalent representation of the CSS 3 value of a multivalued property is the concatenation of the CSS 3 value of all elements in the collection, generally joined by commas (“,”).

  Sample in CSS 3

  .reversed { transform: rotate(180deg); }
  .zoomedIn { transform: scale(1.1); }

  Sample in CSS 3 + Multivalued Properties

  .reversed { transform[rotation]: rotate(180deg); }
  .zoomedIn { transform[zoom]: scale(1.1); }

  In the case of the CSS3 code, it’s not possible to have a “reversed zoomedIn” element. If the current proposition is accepted, it will become possible to do so and have the expected result.

  Modifying an element in the collection is also valuable:

  Sample in CSS 3

  .box { 
       background: url(‘bl-bg.png’) bottom left no-repeat, 
                   url(‘bg-tile.png’); 
  }

  nav { 
       background: url(‘nav-bg-tile.png’); 
  }

  nav.box { 
       background: url(‘bl-bg.png’) bottom left no-repeat, 
                   url(‘nav-bg-tile.png’); 
  }

  Sample in CSS 3 + Multivalued Properties

  .box { 
       background[bl]: url(‘bl-bg.png’) bottom left no-repeat; 
       background: url(‘bg-tile.png’); // or background[0]: xxx
  }

  nav { 
       background: url(‘nav-bg-tile’); // idem
  }

  When a multivalued property is redefined, all the integer-indexed elements are discarded, but the identifier-indexed ones are not (or should they?). It’s also possible to redefined integer-indexed elements one by one.

  To reset one element by its index, each element syntax recognizes a special ‘unset’ keyword. An element having ‘unset’ as value is completely ignored. To unset all indexes of a multivalued property, this specification defines the star identifier (*), which matches all identifier-indexed AND integer-indexed  elements of the collection.

  Sample in CSS 3 + Multivalued Properties

  :root { 
       background[a]: url(tl) top left no-repeat; 
       background[0]: url(tr) top right no-repeat;
       background[1]: url(br) bottom right no-repeat;
       background: url(bl) bottom left repeat;
  }

  :root.nobg { background[*]: unset; }

  Result

  The root element has two backgrounds defined by default: “url(tl)” at top left and “url(bl)” at bottom left. However, it has no background at all in the case it has the “nobg” class associated to him.

If someone from the working group is interested enough, I’m ready to start a more constructed working draft about the feature (+core grammar changes, if any). I think that the change I’m proposing to introduce will play well with all existing browsers who’ll simply ignore the indexed properties but continue to parse normally all other properties.

Any constructive remark is also warmly welcomed.

Best regards,
François
Received on Tuesday, 21 February 2012 17:38:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT