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

Thank you for your response. I'm aware of the variables-based solution and I support any change making it more suitable. I already proposed to support default value and I continue to do so. I don't think, however, it's a good solution. 
 
I'm following courses right now and I'll make a more complete response this afternoon.
 
In the meantime, I'm just throwing my main concern (I have others but they will have to wait), for your consideration: properties like transform and backgrounds are not inherited while variables are. 
 
What happens if a 'foo' is ancestor of another 'foo'? You can of course use a rule to undefine vars for children but it becomes very suboptimal.


----- Mail original -----
De : Tab Atkins Jr. <jackalmage@gmail.com>
À : François REMY <fremycompany_pub@yahoo.fr>
Cc : CSS 3 W3C Group <www-style@w3.org>
Envoyé le : Mercredi 22 février 2012 1h31
Objet : Re: [css-multivalued][proposal] Lists as first-class CSS citizens

I support the general idea of getting syntax support for list-valued
property manipulation.  I definitely support integer indexes.

I like the idea of named indexes, but I really don't like the
implementation you describe.  For starters, identifiers aren't
restricted to ASCII, so ASCII-sorting doesn't work.  ^_^  Using the
name to sort is bad, too - in your example, if you wanted the 'zoom'
transform to come before the 'rotate' one, you'd have to change the
names to something like 'a-zoom' and 'b-rotate'.

In the previous discussion about list-valued properties, I noted that
Variables solves the problem for free, with only slightly more syntax
than the minimum case.  For example, your first example could be
written as:

.foo {
  transform: data(rotate) data(zoom);
  data-rotate: rotate(0); // identity
  data-zoom: scale(1); // identity
}
.foo.rotated { data-rotate: rotate(180deg); }
.foo.zoomed { data-zoom: scale(1.1); }

If I add the ability to give default values for unset vars, it gets
even shorter:

.foo { transform: data(rotate, rotate(0)) data(zoom, scale(1)); }
.foo.rotated { data-rotate: rotate(180deg); }
.foo.zoomed { data-zoom: scale(1.1); }

This depends on every list-valued property having a no-op value.  I
think this is true for all the parallel-lists (like text-shadow), but
not the fallback-lists (like font-family), but I'd have to do a search
to check.  If there are enough without that we think it matters, or if
we just wanted to make it work generically without people having to
memorize the no-op value for every property, we could add this into
Variables directly with a value that always represents a no-op.

Your other examples can be similarly converted into Variables.  This
isn't without its problems - vars being used for different properties
can accidentally collide unless you deliberately prefix them.  But it
gets us a lot of the way there without having to add more new syntax
that violates the Core Grammar.

~TJ

Received on Wednesday, 22 February 2012 08:42:37 UTC