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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 21 Feb 2012 16:31:44 -0800
Message-ID: <CAAWBYDCe4zAWHoKaedSey1E2eK74XVU=HodghW9DJEOR_GBwmw@mail.gmail.com>
To: Fran├žois REMY <fremycompany_pub@yahoo.fr>
Cc: CSS 3 W3C Group <www-style@w3.org>
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 00:32:31 GMT

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