- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Wed, 20 Feb 2013 15:56:42 +0100
- To: Håkon Wium Lie <howcome@opera.com>
- CC: fantasai <fantasai.lists@inkedblade.net>, www-style <www-style@w3.org>
Le 20/02/2013 14:56, Håkon Wium Lie a écrit : > 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. The algorithm is indeed more complex than I would like. Multiples iterations have already simplified it, but I think than at least some of the complexity is intrinsic to the desired behavior (eg. centering and balancing at the same time.) I disagree that the two approaches are the same. When you say for example "symmetry is a goal", the draft’s algorithm tries to accomplish that goal but there are many ways to also accomplish the same goal with an overall different behavior. Even "proportional to the amount of content" is not obvious. As you can see, the current algorithm has results that are proportional to either min-content, max content or (max-content minus min-content) depending on which case you’re in. > Perhaps you could add a note (or issue) in 6.3 saying that we may find > simpler ways to describe the algorithm? If there is a simpler way the describe the same behavior (not just its high level goals), I’d love to know about it and just have it in the spec. I don’t think this note is useful. As always in CSS though, implementations are free to use a different algorithm or add whatever optimization, as long as the behavior is the same. > > > 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". Done. > > > 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. It definitely is. I just don’t have a solution to propose at this time. (It’s an area where WeasyPrint is pretty bad.) But the issue is the same as it has always been, and I don’t think it should block a new Working Draft. -- Simon Sapin
Received on Wednesday, 20 February 2013 14:57:12 UTC