Re: [css3-page] Styling elements differently based on whether they appear on a left or right page

On Sep 2, 2013, at 8:06 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

> On Sep 1, 2013, at 3:24 PM, Lea Verou <lea@verou.me> wrote:
> 
>> On Jul 31, 2013, at 20:15, Brad Kemper <brad.kemper@gmail.com> wrote:
>>> Let us also not forget :first pages and named pages, which @page can select as easily as :left and :right. Thus, if the mechanism is an @content{} block with rulesets within, itself inside the @page{} block, then it would be a good general way of styling content based on if it appears in right/left/first/or other special pages.
>> 
>> Why do we need an @content rule? I can see the issues with parsing (potentially infinite lookahead), since we faced the same issues in CSS Hierarchies. The way we resolved them in Hierarchies was to require the & before every nested selector. I think it would be more consistent if we did the same here, then & would become the universal symbol to mean "nested selector" in CSS, regardless of the nesting type.
> 
> If the "&" means "continue the selector chain from outside the brackets here", then I don't think it fits for what we are talking about for @page. The thing we need for @page is not nesting selectors. Nested selectors are a new type of shorthand, which could always be expanded out to a more verbose longhand. What we need for @page is something else: a way to say "use these rules when in this context" (it cant be expanded into a longer form). As such, @content is conceptually more similar to @media. There is no real nesting, or need for multiple levels of nesting. Using a nesting selector would weaken and confuse the meaning of that selector, and perhaps confuse the meaning of what you are trying to select within @page.

Also:

Using "&" before each page-specific rule would be much, much worse, IMO, that writing a single @content block. There might be many such rules per page, and I'd much, much rather write @content once, that to write something extra for each rule.

Slightly off topic:
Hierarchies has not received a lot of review yet, but my view so far is that writing "&" so many times makes it more likely that it will be accidentally left off. I can see why you'd want it when modifying the outer selector with a class, pseudo-class, attribute selector, etc., but why is it needed for embedded rules that could have continued the outer rule with a space character?

Received on Monday, 2 September 2013 15:16:15 UTC