W3C home > Mailing lists > Public > www-style@w3.org > September 2013

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

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 2 Sep 2013 08:15:44 -0700
Message-Id: <820874E2-8748-4463-8FFD-1BAF676FE9AD@gmail.com>
Cc: Alan Stearns <stearns@adobe.com>, Håkon Wium Lie <howcome@opera.com>, www-style list <www-style@w3.org>
To: Lea Verou <lea@verou.me>
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.


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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:31 UTC