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

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

From: Simon Sapin <simon.sapin@exyr.org>
Date: Wed, 31 Jul 2013 19:24:27 +0100
Message-ID: <51F9565B.6030205@exyr.org>
To: www-style@w3.org
Le 31/07/2013 18:15, Brad Kemper a écrit :
> On Jul 30, 2013, at 6:14 AM, Alan Stearns <stearns@adobe.com> wrote:
>
>> That's what Lea was originally asking for. I think it would be a good
>> thing to add. I think float:outside/inside are fine as well. But a general
>> mechanism for styling content on left/right pages would be better than
>> adding special-case values to each property you might want to change
>> depending on the spread location.
>
> 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.

Yes, if a mechanism exists to style differently fragments of different 
pages of the same element, it should work with whatever page selectors 
are supported on @page. And yes, it is very desirable.

*But*

This is not at all as obvious a feature as it may seem. (In fact, I 
believe we already had a very long discussion about this last year.) 
Fragmentation is a result of layout, which itself is based on the 
cascade (the computed values of properties.) Now we’re talking about 
fragmentation affecting the cascade. At first glance this is a huge 
layering violation and introduce circular dependencies.

Still, the CSS Overflow spec has something similar with its 
::nth-fragment() pseudo-element:

http://dev.w3.org/csswg/css-overflow/#fragment-pseudo-element
http://dev.w3.org/csswg/css-overflow/#style-in-fragments

At this point I don’t have a good mental model of how this would be 
implemented (and thus I’m not certain that it can.) My understanding is 
that there is:

1. First the "normal" cascade giving the computed values of properties 
for *elements*. (Ignoring rules that have ::nth-fragment())

2. Then layout as usual, with each fragment/box going back to the 
cascade to have (possibly) its own computed values affected by rules 
with ::nth-fragment().

Even this has its limitations. For example, the third fragment of an 
element could not be a table while everything else is inline, that just 
doesn’t make sense. This is why the CSS Overflow spec limits this to the 
limited set of properties that apply to the '::first-letter' pseudo-element.

(See http://www.w3.org/TR/CSS21/selector.html#first-letter )

I particular, 'float' is not one of the allowed properties. Having 
'float' depend on the page could make sense for elements that stay 
within one page, but there is no way to guarantee that this is the case.

-- 
Simon Sapin
Received on Wednesday, 31 July 2013 18:24:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:32 UTC