Re: [css3-page][css3-mediaqueries] Page size conflicts

Le 20/02/2012 23:44, Brad Kemper a écrit :
> On Feb 20, 2012, at 1:20 PM, Simon Sapin<simon.sapin@kozea.fr>
>> ***Note***: This whole message is based on the idea that results of
>> media queries could vary across pages (if pages have different
>> sizes). However, as Øyvind pointed out, media query expression
>> never depend of the result of applying a stylesheet:
>>
>> http://lists.w3.org/Archives/Public/www-style/2012Feb/0976.html
>
> I saw that, but my premise was that @page could carve itself out an
> exception, without creating any circular logic.

Why not, but css3-page should then make very clear that there is an 
exception to the rule in css3-mediaqueries which should also mention the 
exception. The wording will also need to be changed, since the current 
example (ratio of a printed document) becomes an exception.


>> But note that both Regions and Selectors (for ::first-line and
>> ::first-letter) defined a limited set of properties that can be
>> used in such contexts.
>
> So does css3-page.

It does for the page context and the page margin context. I was talking 
about properties in "normal" rulesets (on elements) inside media queries 
that vary across pages. (We really need a name for that.)
But for property that should not change across pages, maybe we can just 
keep the value of the first fragment, as you suggested below for floats.


>> For example, it would not make sense for fragments of the same
>> element to have different values for the 'display' property.
>>
>> While it would be technically possible to have the same kind of
>> behavior for page breaks (different style across pages like above)
>> I think it is a bad idea.
>
> It is a core feature of @page and that entire spec. You can have
> different styles (within limits) for the first page, left page, right
> page, and arbitrary named pages, than what you have in general for
> all other pages.

Within limits. As I understood them, the limits were that anything 
inside @page could change but not the elements on the page. I spent 
quite some time on css3-page but it never occurred to me that the page 
content (elements) could be styled differently. The spec does not 
mention it.

I first thought this was a loophole due to unforeseen interactions 
between the 'size' property and media queries. But if this is a feature 
we want, the behavior need to be spec’ed much more precisely.


>> For example:
>>
>> 1. @media all and (color) { #foo { float: left }}
 >> 2. @media all and (min-width: 15cm) { #foo { float: left }}
>>
>> The result of the media query 1 does not vary across pages, but 2
>> does. I think that 'float' should not change across pages, so it
>> would not be allowed in 2. Should we forbid it in 1 too or keep the
>> rules (seemingly) inconsistent?
>
> I don't understand why #2 should be prohibited. It seems like a
> reasonable thing to me. See below for more (where I say, "Ah, I
> see")...

I didn’t think of keeping the value of the first fragment. That could work.


 >> 2. @media all and (min-width: 15cm) { @page { size: 21cm 29.7cm }}
>>
 >> * It was agreed earlier in this thread that 2 has a conflict and
 >> should just be forbidden/ignored.
>
> Yes, it was, by Boris and fantasai, rather quickly. As I consider
> this more, I'm not sure of why it needs to be like that though.
> Wouldn't it be just as good or better to say that an @size inside a
> media query does not affect the results of any media queries?  That
> seems simpler to me, with no big downside. Is there real value in
> media queries ever basing their results on an @size? What am I
> missing?

Maybe I am missing something. I don’t see how this would work in example 2.

Boris’s proposal is: resolve the page size without considering @media 
blocks that depend on the result. Then apply the rest of the stylesheet 
with this page size.

Are you saying that the page size should be allowed to change in the 
second step? Then the decision we made for some media queries can become 
"wrong".

I think that such a stylesheet is nonsense anyway, we just need to agree 
on how to handle it. I think that Boris’s proposal is simpler but this 
is not a strong opinion.


>> * As explained above, 3 could work but I think it is a bad idea.
>
> I disagree with that. Aren't you then completely gutting any media
> query that is based on a width of any sort?
 > [...]

I had never seen the mentioned and I didn’t understand how it would work 
in some cases. So I rejected it completely for consistency.

I see now that it could work. Depending on the property, the value would 
be allowed to change (like color) or the value of the first fragment 
would be kept (like float, display).


>> To sum up, I think that anything in a media query should only be
>> allowed if either:
>>
>> * It is in the @page context (or nested in @page, like margin
>> boxes), but is not the 'size' property (as in 1)
>
> So, in #1, you would allow the margin property to be valid because it
> was inside @page, but otherwise not? But then you couldn't use that
> query for continuous media!

I meant this for paged media. Continuous media can keep any media 
queries. Their result never change inside a document so there is no 
conflict.

The @page cascade gives a result for a given page, which by definition 
is never fragmented. So no conflict here either, except for the 'size' 
property.

 > Or if you did allow it for continuous
 > media only, then it would be really unexpected to have the styles
 > disappear when printed, even when the query otherwise matched and all
 > the pages were the same size.

Good point.

>> * The media query expression does use the page size and thus can
>> not vary across pages (as in 5 and 6)
>
> Did you mean "doesn't"? If not, I'm more confused.

Yes. Sorry for the typo.


Anyway, I’m not sure all of this is that useful for authors. But I have 
a bit of a conflict of interest, the alternative (no exception, media 
queries resolved with the default page size) being so much easier for me 
as an implementer :)

-- 
Simon Sapin

Received on Tuesday, 21 February 2012 00:45:11 UTC