- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Wed, 22 Feb 2012 08:42:04 +0000 (GMT)
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: CSS 3 W3C Group <www-style@w3.org>
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