Re: [css3-page] comments on last ED

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. 
authors?

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.

Done.


>     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:

http://www.w3.org/TR/css3-break/#forced-breaks


>     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').

Done.


>     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:
http://lists.w3.org/Archives/Public/www-style/2013Feb/0097.html

(And issue 2 too)
http://lists.w3.org/Archives/Public/www-style/2013Feb/0096.html

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 
non-normative.

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 
boxes.


>     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