- From: Håkon Wium Lie <howcome@opera.com>
- Date: Wed, 20 Feb 2013 14:56:04 +0100
- To: Simon Sapin <simon.sapin@kozea.fr>
- Cc: fantasai <fantasai.lists@inkedblade.net>, www-style <www-style@w3.org>
Also sprach Simon Sapin: > > First, section 6.3 still seems complicated. I think the underlying > > model is quite simple and I've sketched a 6.3-replacement here: > > > > http://lists.w3.org/Archives/Public/www-style/2010Aug/0155.html > > > > Which seems easier to read and still has the required specificity? > > Well, I’ve been going through multiple revisions of this algorithm on > www-style for more than a year now, and have requested feedback numerous > times. The current version is close to what both PrinceXML and > AntennaHouse implement, based on feedback from Micheal Day and Murakami-san. I will not insist on making changes, but I think (hope?) the two approaches say the same thing using two methods. And, given a choice between two equals, I will always choose the simpler. I agree that there seems to be a high level of interoperability between PrinceXMl and AntennaHouse, and that this interoperability is valuaeble. Perhaps you could add a note (or issue) in 6.3 saying that we may find simpler ways to describe the algorithm? > Also, the linked proposal seems to specify high level goals but not the > actual behavior. Is there something more specific in the ED’s algorithm > you would like to change? I have not been able to go through it in detail. My head hurts when I try. > > Second, I described a use case here: > > > > http://lists.w3.org/Archives/Public/www-style/2010Aug/0152.html > > > > Basically, I'd like to make sure that 'width' is honored on margin > > boxes, even when neighboring boxes have no content. I can't quite > > determine if this is supported in the current section 6.3. > > Yes, the current algorithm does that. Basically: > > * Any non-auto value is used unchanged > * Auto margins are always zero > * The rest of the algorithm picks a values for auto widths in various cases. Good. > > Third, I'd like to see comma-separated page selectors: > > > > @page foo, bar { > > @bottom-right: { > > content: counter(page); > > } > > } > > Yes, we resolved to do that on the 2013-01-30 conf call. It was actually > already described in prose but not in the grammar. I clarified the prose > and updated the grammar. Good. > > I suggest removing the at-risk comment > > Done. Super. > > I also suggest adding and example > > Filed an issue on this: https://www.w3.org/Style/CSS/Tracker/issues/305 > > > Same overall story for multiples pseudo-classes in the same selector: > > @page :blank:left Yes. > > Fourth, the draft refers to 'page-break-before'/'page-break-after'. I > > suggest referring to 'break-before'/'break-after' instead > > Done. Thanks. > > Fifth, returning to 6.3: where is 'outer width' defined? > > CSS 2.1 defines "outer edge", and sometimes uses "outer width" as short > for width of the outer edge. > > http://www.w3.org/TR/CSS21/box.html#outer-edge > > We could add a link if you think it helps. How about just saying that "/outer width/ refers to the width of the /outer edge/, as defined in CSS 2.1". > > Sixth, I think the draft should say something about abspos elements: > > which page is the containg block -- the first or the natural page? > > I don’t know. Relationships between abspos/fixed pos and fragmentation > (including pagination) are very fuzzy for me. I don’t know how it’s > supposed to work or where it’s supposed to be defined. For implementors, it's a key issue, no? I'll do some more testing to try document interoperability. -h&kon Håkon Wium Lie CTO °þe®ª howcome@opera.com http://people.opera.com/howcome
Received on Wednesday, 20 February 2013 13:56:40 UTC