- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Thu, 21 Feb 2013 00:56:23 +0100
- 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. 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