Re: Adding a font to the current stack (smarter fallbacks)

On Jan 11, 2012, at 12:50 , Tab Atkins Jr. wrote:

> On Wed, Jan 11, 2012 at 12:10 PM, David Singer <singer@apple.com> wrote:
>> On Jan 11, 2012, at 9:49 , Oliver St. John wrote:
>>> This is a common problem for *all* list-valued properties in CSS; right now, they're always atomic, and you must re-specify the entire list if you want to change one part of it.
>>> 
>>> We'd like to fix it, but no one's figured out how to do so yet.
>>> Suggestions welcome.  ^_^
>> 
>> 
>> well, additions could be handled generally by having syntax to say list now should contain "this that <<and all the list that this would have had if this rule hadn't been here>>"
>> 
>> subtractions and re-orderings are harder, but then, should you be removing stuff from other people's style sheets?
> 
> Who said anything about "other people's" stylesheets?  This is useful
> for a single stylesheet controlled by a single person.
> 
> Even simple additions are hard.  What do you do if three different
> rules are attempting to add to a declaration?

OK, I wasn't clear.

Multiple style-sheets can supply a value for a list-structured value class.  There is a defined way to order them, so that in any given context, we know which one 'wins' (applies).  Take that ordering, and inspect each list; for each occurrence of the <<special syntax/keyword>> substitute the value that came out of the next one down in the list.

That allows additions before or after, but not deletions or additions in the middle.

If all the stylesheets are yours, you could probably get the same effect with variables.  It becomes interesting when they are not.


> 
> The best approach I know of so far is to, somehow, add syntax to all
> list-valued properties effectively turning them into shorthands with
> numbered longhands, where the numbers correspond to each entry in the
> list.  This doesn't make it easy to compose multiple things "in front"
> of each other, but if you explicitly carve out "holes" in the list,
> you can then have different rules target different holes and not
> interfere with each other.
> 
> 
> On Wed, Jan 11, 2012 at 12:23 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> Perhaps some special use of inherit?
>> #special { font-family: LeagueGothicRegular, inherit; }
> 
> No, this is a completely different concept than 'inherit'.  You're not
> attempting to alter the value you received from your parent, you're
> trying to alter the value "behind you" in the cascade.
> 
> ~TJ

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 11 January 2012 23:13:57 UTC