W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: Issue 101 Resolution

From: Peter Moulder <peter.moulder@monash.edu>
Date: Mon, 11 Oct 2010 15:24:26 +1100
To: www-style list <www-style@w3.org>
Message-id: <20101011042426.GA1143@bowman.infotech.monash.edu.au>
On Sun, Oct 10, 2010 at 09:58:15PM +0200, Anton Prowse wrote:
> On 10/10/2010 17:58, Alan Gresley wrote:

> >...

> >I will mention that rule 3 has an exception that none of the other rules
> >have. All other rules are one sided where rule 3 has something left
> >taking an interest in what is right. The reason why this important is
> >that CSS2.1 rules of floats are all about TTB block progression and LTR
> >inline progression (bias to top and left).

I don't really follow the above, i.e. I don't see the connection between the
first two sentences and the third.  Also, I don't see any left bias over right
in any of the float placement rules.  (Though I agree that the rules are all
about TTB block progression and horizontal inline progression.)  As such,
I also don't understand the claim that followed (not cited above) that
"This has to be fined tuned since the mirror computations must happen for
RTL inline progression".

> I don't see any particular importance of Rule 3 here.  Clearly all
> writing modes and directions need to be specced and implemented
> appropriately.

I don't think we'll see horizontal block progression well supported within
a CSS2.1 timescale.  CSS2.1 (including CSS2.1 float layout in particular) is
full of asymmetries between horizontal and vertical, which reflects the
assumption that block progression is vertical (and more specifically TTB in
some cases, such as the "dropped down" parts of float positioning rules).

Because so many fundamental parts of CSS2.1 have an asymmetry between
horizontal and vertical, I think we should assume vertical block progression
when discussing what CSS2.1 float rules should be; and in practice that
pretty much also implies assuming TTB block progression.  (I.e. I'm not
aware of any BTT block progression cases that occur in real scripts other than
in conjunction with horizontal block progression or things not supported by
CSS2.1 such as rotated layout.)

An assumption of TTB block progression may make some horizontal–vertical
asymmetries justifiable in float positioning rules.

Coming back to how that's relevant to rule 3, I don't know what
Alan Gresley had in mind, but one relevance is just that it suggests that
horizontal–vertical asymmetry is not by itself enough reason to disallow
horizontal overflow to differ from vertical overflow in the way that
Anton Prowse drew attention to (and initially supported) in Tab Atkins'
proposed wording.  (Of course there may nevertheless be other reasons to
decide against the change.)

Received on Monday, 11 October 2010 04:25:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC