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