On Thu, Oct 9, 2008 at 12:04 PM, François REMY <fremycompany_pub@yahoo.fr> wrote:
Another possibility I think great for both your queries is :
 
    #top-courses, #additionnal-courses {
 
        @rule ul {
            display: inline-block;
        };
 
        @rule h3 {
            color: darkblue;
         };
 
        border: none;
    }

I'd have to look, but I think that would mess with the parsing rules as currently written.  I'd rather have an equivalent syntax that meshes more naturally with existing content, like what you have below:
 
An equivalent, with your proposals will be :
 
    @scoped ( :any(#top-courses, #additionnal-courses) ) {
 
        :root {
            border: none;
        }
    
        ul {
            display: inline-block;
        }
    
        h3 {
            color: darblue;
        }
    }

 Looks like I didn't mention it, but my intention is for @scoped to accept arbitrary selectors, not just simple selectors.  So (assuming :any() was implemented) there would be nothing wrong with the above.  After all, being able to avoid typing a single simple selector is a fairly minor benefit (though I have a use-case in my current work that this would aid me with quite a bit, as I explained in the original email), but sometimes one runs into a situation where a fairly complex selector would be repeated over and over again.

On Thu, Oct 9, 2008 at 12:10 PM, Brad Kemper <brkemper.comcast@gmail.com> wrote:

On Oct 9, 2008, at 8:53 AM, Tab Atkins Jr. wrote:

I want to talk about two issues of syntactic sugar that I believe would be very useful to us authors.  Neither actually change anything in the way CSS works or produce new burden on implementors - both are merely sugary conventions that would allow us authors to shorten some thing we currently write out manually.  I know I've seen both of these suggested before in various syntaxes; I just want to bring them together in what I think is an appropriate syntax for each, so as to provoke new discussion in a thread specially dedicated to them.

(1) Scoped selectors within a stylesheet.

Good, semantic authoring often entails a relative paucity of named hooks into the document (in the form of ids and classes), with most of the actual CSS targetting being done through relatively complex selectors descending from some named hook.  Frex, a navigation menu may *only* id its enclosing div, and target all of its styling purely by structurally descending from that #id.  The issue with this is that you have large swathes of selectors that share a common prefix, which must be repeated on every single rule.  This can be simplified by creating a block in which every rule is assumed to be scoped to an area.  My first thought is an @ rule, something like the following:

@scoped( #nav-menu ) {
h1 {
//This is equivalent to the selector "#nav-menu h1",
//and so won't target <h1>s across the rest of the page.
...
}
ul {
...
}
more rules...
} //end of scope

I would find benefit from this immediately, as all of the sites I operate on utilize the same basic mechanisms.  They consist of a template which is styled by a dedicated sheet, and then has content piped in from a database which also pulls in the page-specific styling.  The page-specific styling should *never* affect the outside template, and current I accomplish that by iding the content container and just prefixing *every* rule in *every* page with that id.  I've purposely made the id extremely short (it's just "bc" for "body content") so it's not overly burdensome to type, but that's still a lot of meaningless typing that could easily be taken out with the addition of a single scoping line.

Even past the convenience factor, there's a safety factor.  I hand-craft the styles across my company's site, because nobody else in the company really has appropriate skill to do so, but even I sometimes forget to use the #bc prefix on a rule.  The damage is usually immediatley obvious, as I suddenly give every header some enormous background or something, but it's also unnecessary.  Forcing other people who are relative newbs at styling to remember to arbitrarily prefix all their rules with #bc as well is just frustration waiting to happen.  I could, of course, build a CSS parser that alters the rules myself, but why reinvent the wheel every time when it can be simply fixed in the language itself?

Ignoring any possible optimizations, this is a simple matter of the parser doing a simple textual concatenation before handing the selectors to the matcher.  This construct should also be nestable, for obvious reasons.


(2) Multi-matching selector

This was suggested just recently and also came up in the jQuery thread a few moments ago, and I would also benefit greatly from this.  The idea is that, rather commonly, you have to apply the same style across several elements with different classes or whatnot.  This isn't burdensome when you're writing a single group of selectors, but when you have a large chunk of selectors that all have to be generalized you quickly run into a nightmare of typing.  For example, in something I'm typing *right now*, I have a lot of selectors which look like this:
#top-courses div.chapters h3, #additional-courses div.chapters h3 { ... }

#top-courses and #additional-courses are two (of several) sections which all share a similar structure, but they have some special styling needs that set them apart from the others.  Right now I need to duplicate every selector I make, which adds up to quite a few in this particular example.  With a multi-matching combinator I could avoid the duplication.  It would look something like this:
:any( #top-courses, #additional-courses ) div.chapters h3 { ... }

...with the :any pseudoclass being simple sugar that stands for any of the selectors contained within it.  :any should accept arbitrary selectors, separated by commas, since it's basically just performing a simple textual substitution in the selector.  Though there are surely optimizations that can be performed, in the simple case all that's needed is for the parser to transform away the :any and produce two separate selectors to be handed to the matcher.

It is certainly possible for authors to get the same functionality by going into the code and adding additional classes.  That's why this is syntax sugar, not new functionality.  ^_^  Doing such means altering the document when you just want to save some typing in the stylesheet, and possibly leaks presentational classes into the document (some times you can certainly come up with a semantic reason for the class, of course).  As well, style authors don't always have access to the document source, particularly in cases like writing up Stylish-like user-stylesheets.


Thoughts on these proposals?  Any ideas for other simple bits of sugar that would help us authors out?  I'm looking specifically for ones that don't add new functionality, but rather only shorten the amount of typing we have to do when writing styles.

~TJ

I agree that those would be valuable. There was some discussion back in February about "selector variables" (from Jens Meiert) and "selector constants" (from me), that were also syntactic sugar for selectors. They solved some of the same problems, but your ideas above do even better for certain cases. Your #1 above is actually pretty similar to how Alan Gresley misunderstood my proposal, which has value in its own right:

http://lists.w3.org/Archives/Public/www-style/2008Feb/0145.html

Cool.  I wasn't following the list back then, so thank you for pointing it out.  Selector constants solve a similar problem to the @scoped rule, but there they let you dump a complex selector anywhere within a selector.  @scoped misses out on this, but results in even *less* typing (using a selector constant for a common prefix still means typing a prefix over and over, even though it's shorter).  You're right that they both have interesting value, and I can see a definite purpose for constants that would make writing chunks of selectors more maintainable and easier to understand.
 


I wonder if it might even be possible to leave out the @scoped, and just have it like this to do the same thing:


#nav-menu {
h1 {
       //This is equivalent to the selector "#nav-menu h1",
       //and so won't target <h1>s across the rest of the page.
       ...
       }
ul {
       ...
       }
       more rules...
} //end of scope

That would mean that the parser would have to not only look for property names inside the curly braces, but also for other selectors. And that way, not only is there less to write, but you could include styling for the base selector, like this:

#nav-menu {
       border: 2px solid red;
       background-color: blue;

       
       h1 {
       //This is equivalent to the selector "#nav-menu h1",
       //and so won't target <h1>s across the rest of the page.
       ...
       }
       ul {
       ...
       }
       more rules...
} //end of scope

It would be slightly less writing, but now we're talking about the difference of a couple characters, compared to the linear savings of the proposal itself.  I don't see any particular reason to need this simplification, but I don't think I'd be against it either.  I just suspect it would be more work for implementors than adding in a new at-rule.

Styling the base selector could also be accomplished in one of two ways.  Either :root can have its meaning changed within the context of a @scoped rule to refer to the scoping element (Francois implicitly used this approach), or we can just go the brain-dead simple route of stating the base selector by itself.  Frex:

#nav-menu {
  ... //for the nav-menu itself
}
@scoped ( #nav-menu ) {
  ... //for the children of nav-menu
}

I don't have a preference either way, but I have absolutely nothing against the simple method here.

~TJ