On Wed, Jan 11, 2012 at 8:25 PM, John Daggett <jdaggett@mozilla.com> wrote:
> Sylvain Galineau wrote:
>> An extension to @font-face would not solve the general problem of
>> CSS value lists redefinitions, but since fonts already have an
>> indirection mechanism, something like this may be an option. (Though
>> I suspect John Daggett may have 79 reasons I should be ashamed of
>> myself for suggesting such a thing…)
>>
>> Otherwise it sounds like something Variables might be able to tackle?
>
> Yeah, I think some form of variable substitution is the right way to
> go here rather than extending @font-face, since you really are looking
> to substitute *families* rather than individual fonts.
I'm not so confident in the ability of Variables to handle this. Take
a simple example - I have several classes which can apply to an
element, each of which wants to add an entry to the 'animation' stack.
Right now, I have two choices, neither of them great: I can assume
that the classes won't be used together, so each just has the "base"
animation stack plus their addition, but they'll clobber each other if
they *do* get used together, or I can explicitly handle every
combination of classes and manually combine the font stacks. For
three classes, that's 8 combinations, and obviously it goes up from
there.
How would variables work here? The only thing I can think of is
something like this:
base {
animation: data(first-animation), data(second-animation),
data(third-animation), base-animation;
data-first-animation: none;
data-second-animation: none;
data-third-animation: none;
}
base.one { data-first-animation: the-first-animation; }
base.two { data-second-animation: the-second-animation; }
base.three { data-third-animation: the-third-animation; }
This seems somewhat heavyweight of a solution, however.
I was thinking of something like:
base {
animation: none, none, none, base-animation;
}
base.one { animation-1: the-first-animation; }
base.two { animation-2: the-second-animation; }
base.three { animation-3: the-third-animation; }
The two aren't that different, I suppose.
Obviously, both of these rely on there being a no-op value for
plugging the unused spots. Many list-valued properties have this, but
without exhaustively checking, I'm not sure they all do. We'd need to
either define a new global value, or record as a design constraint
that it's required that new list-valued properties have such a value.
~TJ