W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: [css3-page] 6.3 ++

From: Håkon Wium Lie <howcome@opera.com>
Date: Wed, 20 Feb 2013 17:48:17 +0100
Message-ID: <20772.65105.709070.477264@gargle.gargle.HOWL>
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style <www-style@w3.org>
Also sprach Simon Sapin:

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

Sure. The "symmetry is a goal" statement should be in a note, not part of the algorithm.

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

I'll try go through this.

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

Ok. How about adding an informative statement basically saying "ease
of use, symmetry, and balancing is a goal". Or just saying it's
similar to tables. This way, people will get the gist without having
to go through the algorithm.

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

Agreed. I'm all for publishing.

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Wednesday, 20 February 2013 16:49:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC