Re: [css3-cascade] Proposed property: rule( sSelector ); - syntax

Boris Zbarsky [bzbarsky@MIT.EDU] wrote:
> Chris Moschini wrote:
>> p.section { color: @rule( "div.section" ); }
>
> This looks like a declaration for the color property.... except it does 
> not follow the normal declaration rules.  That is, it has an immediate 
> effect on things as soon as the rule matches the content instead of only 
> being looked at once all the matching rules are known and the cascade 
> has been considered.

Hmmm. Well my understanding is the process for a CSS-implementing UA is:

1) Read-in all style rules.
2) Get to a place in the DOM, and pass through style rules, creating a sort order
of rules that apply to this Element.
3) Apply the properties that win (either by applying all properties from least
important to most, or simply determining most important per property and applying
it).

Finding an @rule() for a property *could* demand a second pass of step 2, in a
simple implementation. That is, the above CSS might require passing through once
for rules that apply to p.section, then again for the color value, as if you had
a div.section.

A more complex implementation could avoid this second pass by linking p.section's
color definition to div.section during the CSS parse, so when it's time for step
2, the sort order accounts for this added part of the cascade.

Though the second approach would perform better, both must be aware of infinite
loops. Perhaps the Recommendation, as Tex has suggested, could limit
"indirections" to an arbitrary number - let's say 5 for balanced performance and
author flexibility.


If all of this amounts to something that is too difficult to implement in a way
that performs as well as CSS should, the @rule() function could be limited to
only referring to an exact-match CSS selector applied to the page and no other
interpretation; thus the above example would add whatever color value div.section
specifies to the cascade sort order for that value, but no other (no div, no
.section). This limitation would still fill the gap I'm trying to see filled in
CSS.

"Forward indirections" as Tex mentioned could also be restricted if they were
prohibitive to high-performance implementation. They would certainly be of little
need to authors, and preventing such forward requests could be seen as just as
intuitive as allowing them.

-Chris "SoopahMan" Moschini
http://hiveminds.info/
http://soopahman.com/

Received on Wednesday, 22 October 2003 13:13:06 UTC