Re: [css3-page] 6.3 ++

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