Re: Selector Sugar

 -------------- Original message ----------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>

> > 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 agree with everything you just said.

> > 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.

Well, the savings in typing time is not that great, but the simplicity is the benefit to me. If we can have the same behavior but with less symbols and new words, etc. then it just seems like a win/win. It would be easier to read and just as easy to understand. If its extra work up front (but not impossible or nearly so) to make it simpler and easier for others afterward, then I am for that.