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

Re: [css3-page] comments on last ED

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Thu, 21 Feb 2013 00:56:23 +0100
Message-ID: <512562A7.3070606@kozea.fr>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
CC: "www-style@w3.org" <www-style@w3.org>
Le 20/02/2013 11:19, Daniel Glazman a ťcrit :
> Here are some comments on the latest css3-page ED:

Thanks for the review!

>     Honestly, I have a strong concern about the 16 page-margin
>     boxes. When I try to print from a browser on a office printer,
>     here's what I get:
>       http://pics.lockerz.com/s/284292098
>     it allows me to specify the usual six page-margin boxes but not the
>     10 extras. Furthermore, the specification does not say how the
>     settings in that dialog set/conflict/collide/override the ones in
>     the stylesheets attached to the printed document. I think that is a
>     concern.

I donít have a good answer to this.

This hasnít been an issue yet since none of the implementation of 
page-margin boxes so far have user controls like this. I guess the 
underlying question is: how much control do we want to give to users vs. 

There is always the possibility, as HŚkon suggested, to have that UI do 
something equivalent to a user stylesheet and let the cascade resolve 
conflicts. But I donít really like the idea of mixing these default 
headers (URL, date, Ö) with author-defined page-margin boxes.

>     The prose says in section 5.1 that "margin at-rules may be
>     interleaved with the declarations in the page context". I would
>     prefer such a wording "An @page rule can also contain other
>     at-rules, interleaved between declarations. The current
>     specification only allows margin at-rules inside @page for the time
>     being.


>     I think a definition for blank pages is missing: if an element is a
>     running element (then rendered inside a page-margin box) triggering
>     a page-break before and after, is it a blank page?

Iím not sure what a running element is, but I just clarified the 
definition of the :blank pseudo-class that was in ß5.2.

css3-break defines that multiple forced break values that apply between 
the same to siblings are combined:


>     Section 5.1 does not say that @page rules can happen anywhere in a
>     stylesheet, w/o restrictions like the ones existing for @import.

Added a sentence near the beginning of the section:
"Ď@pageí rules are allowed at the top-level of a stylesheet, as well as 
wherever rule-sets are allowed."

>     Section 5.1 should establish a link between 'page name' in second
>     paragraph and section 9.1 (the 'page' property').


>     Page margin boxes names are not rtl-compliant. Since they use left
>     and right, a UA will have to look at the system's locale and the
>     document's language to apply the print settings discussed above.

Page-margin boxes names are based on the physical location, consistent 
with the :left and :right selectors. Note that whether the first page is 
on the left or on the right depends on the writing mode and direction.

I guess we could add names based on the logical position, and they would 
cascade with the existing names depending on the writing mode/direction 
on the root element. Maybe in the next level?

>     GRAMMAR: there is a problem in the 'page-body' production. It allows
>     the following:
>       @page {
>         property: value
>         @top-left { property value }
>       }
>     where the first declaration in @page does not end with a ; making the
>     whole thing usually invalid...

It does not. After a declaration you either end the {} block or have a 
semi-colon followed by more page-body stuff (which can be empty.)

This form of grammar (doing recursion instead of repetition) is unusual, 
but is required to cover this syntax while staying LL(k).

>     Case-sensitivity of page names not mentioned in section 5, only in
>     section 9.1, not linked from section 5.

Is this solved by adding the link, as mentioned above?

>     Section 6.1 says "(margin at-rules) should come after any
>     declarations in the page context as legacy clients may not handle
>     declarations after margin at-rules correctly" BUT grammar in section
>     5.3 clearly allows a declaration AFTER a margin at-rule. This is
>     inconsistent.

Itís a "should" (not "must"), and only meant for authors (not 
implementations). Clarified.

"may" in "legacy clients may not handle declarations" is supposed to 
mean that non-conformant clients exist, not that doing this is 
conformant. Is this clear enough?

>     Not sure the page and page counters' definition in section 7.1
>     should not belong to the GCPM spec.

I agree on the principle. But this feature has been stable since 
forever, and I donít want it to be blocked by everything else in GCPM.

>     I have implementation concerns about the last paragraph before issue
>     2 "If a size property declaration is qualified...". The MQ can come
>     not from inside the stylesheet but also from a media attribute in
>     the markup, making it a bit difficult for a css parser to reach it.

I want to remove this part:

(And issue 2 too)

Iíve been waiting for some feedback. Should I bring it up in a conf call?

>     'spilling' is totally undefined in section 8.2 item 4.

Indeed. Itís marked up as a keyword, but I believe that is accidental. 
The whole section is under a "should". I wonder if that makes it 

Filed: https://www.w3.org/Style/CSS/Tracker/issues/312

>     section 8.3 second item says "in the upper left corner". Including
>     for rtl documents?

Again, a "should". I think UAs are allowed to go against the "should" 
and pick another corner based on the writing mode.

Filed: https://www.w3.org/Style/CSS/Tracker/issues/313

>     Section 9.1 item 2 of the list following example 28 uses "iff". I
>     have no idea if this is a typo or means "if and only if". If the
>     latter, then the use of the abbreviation here is a mistake
>     potentially harmful to non natively english readers.

Given the emphasis Iíd say the latter. Fixed.

>     What happens with
>       div { page: foo; }
>       span.blah { page: bar; }
>       <div>foo<span class="blah">bar</span>foo</div>
>     ? Three pages?
>     Should the page property be limited to block-level boxes?

The page property "Applies to: 	boxes that create class 1 break points"
Class 1: http://www.w3.org/TR/css3-break/#btw-blocks

'page' applies to block-level boxes and a few others, but not to inline 

>     Section 7 and appendix A don't list the same properties. For
>     instance bidi properties are in appendix A for page boxes and not in
>     section 7. One of the two should probably go.

Agreed. Filed as https://www.w3.org/Style/CSS/Tracker/issues/311

Simon Sapin
Received on Wednesday, 20 February 2013 23:56:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:08 UTC