- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 02 Jul 2008 16:19:06 -0700
- To: www-archive@w3.org
Grant, Melinda wrote: > fantasai wrote: >> Grant, Melinda wrote in response to adding named pages without >> making 'page' a non-inherited property: >> >>> Haven't thought about it, but one option would be to add page-list >>> or some such. >> >> And how would that interact with 'page'? (Two properties that try to >> control the same thing in CSS doesn't really work.) > > I dunno, last one in or some such. Last one specified in the cascade? Yeah. That doesn't work. It's a little complicated to understand why, so we've had many proposals over the years -- from spec editors -- that rely on doing that and.. those proposals have had to get scrapped and rethought because you can't do it. The cascading order is effectively per-property: once the cascade is over every property has a value, and you don't know which properties' values had a higher cascade weight. You can have a value for each property that says "check the other property", but ultimately one property has to always override the other. > What's your proposal? If we're sure we want named page lists in the future... We could make 'page' non-inherited, and add an exception in the spec saying that UAs may treat it as inherited in CSS3 because that's how it was specified in the previous CR. I don't think it will have much effect on existing content. Hmm.. we'd need to add another special value, so we have the initial value mean "look at my parent" and some other value mean "put me on a normal, unnamed page even though my ancestor suggests a named page". I'm not coming up with anything brilliant today. :/ Michael, any thoughts on this? The discussion started with this: http://lists.w3.org/Archives/Public/www-style/2008Jul/0029.html ~fantasai
Received on Wednesday, 2 July 2008 23:19:46 UTC