- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 23 Jan 2013 22:33:26 -0800
- To: Lea Verou <lea@w3.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Sylvain Galineau <sylvaing@microsoft.com>, Mounir Lamouri <mounir@lamouri.fr>, www-style list <www-style@w3.org>
On Jan 23, 2013, at 2:24 PM, Lea Verou <lea@w3.org> wrote: > My 2 cents: [...] > 3) *-opacity properties are masking the real issue here. Authors need to individually set color and alpha and had wanted to do that for a while, in many different properties. This is a value-related problem, not a property-related problem. Introducing an *-opacity property for every property that accepts a <color> value adds redundancy to the language, not to mention it’s inelegant. I generally agree with this. I guess the question is if we want to define the scope of the problem that widely, if it is really as needed in other properties as it is for the 'color' property. Perhaps it is, and we should, but I'm not sure. > Perhaps a solution could be to introduce an alpha(<color>, <number>) function, which in combination with CSS Variables Somehow, that doesn't seem all that elegant to me. > provides a rudimentary solution for all these use cases. CSS preprocessors have a multitude of such functions and frankly, they're the only thing I miss as an author when I compare existing CSS preprocessors with our new preprocessor-inspired specs (Variables and nesting). [...] > 5) Why adopt a fill property from SVG that does exactly the same thing as the existing color property? It sounds very confusing. Am I missing something? I agree. Stroking text is a separate problem, and if we ever had a 'text-stroke' property, it would likely include a 'text-stroke-color', and we would be better of with a way to modify its alpha in the same way that we would for 'color', if we want to take the 'setting alpha separately from the other color components' idea that far.
Received on Thursday, 24 January 2013 06:39:46 UTC