- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Mon, 2 Sep 2013 08:06:18 -0700
- To: Lea Verou <lea@verou.me>
- Cc: Alan Stearns <stearns@adobe.com>, Håkon Wium Lie <howcome@opera.com>, www-style list <www-style@w3.org>
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.
Received on Monday, 2 September 2013 15:06:49 UTC