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

Re: [css3-page] 6.3 ++

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Wed, 20 Feb 2013 15:56:42 +0100
Message-ID: <5124E42A.6060105@kozea.fr>
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".


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

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