- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Thu, 16 Sep 2010 20:36:30 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org list" <www-style@w3.org>
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] > Well, sure. The point is, though, that @font-face doesn't define > something that can just be substituted into a property. It defines > something special in CSS. Variables just get substituted where they > are used. 'The point is' that it *is* a substitution for a custom data type for one particular property. It doesn't make a lot of sense to plug a font descriptor anywhere other than through font-family but that doesn't make it any less of a name-based substitution. Extending the pattern to another data type is thus not at all illogical. Except that this one plugs in a lot of places and the proposal naturally takes advantage of the extra level of indirection to add all kinds of new capabilities. Which may create its own problems but I like the idea of extending existing data types into richer objects. > > > > But I agree that addressing variables in general seems more > reasonable > > than making something up for colors alone. > > > > Although in fairness these look more like brushes than colors. Which > may > > be of value in its own right. > > I agree; I used the term "paint servers", but overall the <image> > concept captures all of this, and it's different than the <color> > concept (though you can upgrade a <color> into an <image>). Right. While the desire to 'solve' variables generally means this proposal should depend on a Variables module for its syntax, I'd rather talk about the capabilities and use-cases being suggested. So let's keep the generic variable syntax concern separate from the ability to define complex color/brush objects.
Received on Thursday, 16 September 2010 20:37:12 UTC