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

Tex Texin <tex@i18nguy.com> wrote:
> FWIW, I like this suggestion very much.

Thank you.


> Besides the bloat, it will be a more effective way for authors to document
> what's common and what's different between rule sets

Thanks. I think it can also help alleviate the common gripe CSS users have of
"there is no not() selector" - this could leapfrog those elements in the cascade
that they rather not style with the rule, rather than restating it over and over
as is done now.


> However, you might want to consider some guidelines for location or ordering
> of these indirections, since you can have circuitous references. Or you could
> limit the levels of indirection.

Excellent point. This could potentially be left up to the UAs with a minimum
level of implementation:

"User Agents are required to support at least 3 "selections" through the rule
function. After that they may stop obeying rule functions, or continue, using
some method of circuitous reference detection."

I also realize after posting this somewhat breaks CSS syntax, so if something
else would be preferred - such as rule: "div.section"; - I'm happy with that.


> Relative references need to be clarified. If div.section {font-size : 10%},
> then does p.section use 10% of its parent, or does it gain the calculated value
> of div.section's font-size?

10% of the p tag's parent.

I think that the rule() function (or property) would obey the normal CSS rules
of cascade and specificity with the addition that selectors called through rule()
are less specific than properties at the same level, thus, given:

http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#specificity

div.section { font-size: 10%; }
p.section { rule( "div.section" ); font-size: 100%; }

The 100% wins, as its specificity flag is 011 and the 10% would be 000, I
suppose. I believe specificity is the place to handle the issue of "where does
rule() stand?" but it may not be in one of the existing parts of this flag. I'm
discussing this with Boris over e-mail presently and am happy to discuss it here.


> Also, I assume this is just a "compile-time" relationship. If I make a change
> dynamically with the DOM to div.section, p.section is not updated right?

If that is necessary to make this reasonable for UAs, then yes, but otherwise I
don't see why breaking this link after load time makes sense. The div.section
rule would cascade into the p.section.

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

Received on Tuesday, 21 October 2003 17:41:59 UTC