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

All ok for now, except the remark about leaving levels of indirection up to
UAs.
Please don't as that will have authors designing different behaviors for
different UAs based on the supported levels of indirection and/or users
experiencing unexpected behaviors because authors miscounted indirections.
I would suggest just picking what you think is a reasonable number.

The comment on specificity is ok, but it might make the point more strongly to
give this example instead:

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

Since the 100% is more specific, it wins even though the indirection rule comes
later.


Are forward references ok? I would presume so.  e.g.

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

How do you handle missing selectors in rules? Ignore it or ignore the
containing rule?

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

Is font-size set to 100% or is all of p.section now ignored?
If all the rules are ignored then this has the interesting side effect of
acting like #IF DEFINED (div.does-not-exist)...

tex


Chris Moschini wrote:
> 
> 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/

-- 
-------------------------------------------------------------
Tex Texin   cell: +1 781 789 1898   mailto:Tex@XenCraft.com
Xen Master                          http://www.i18nGuy.com
                         
XenCraft		            http://www.XenCraft.com
Making e-Business Work Around the World
-------------------------------------------------------------

Received on Tuesday, 21 October 2003 18:16:13 UTC