Re: [CSSWG] Minutes and Resolutions 2009-12-02

On Dec 3, 2009, at 5:49 AM, Tab Atkins Jr. wrote:

> On Thu, Dec 3, 2009 at 3:00 AM, Alan Gresley <alan@css-class.com> wrote:
>> 1. For rtl, does clear: left on an element clear an element with float:
>> start or float end (or only float: left)? I would think the later case (end)
>> since the direction is reversed.
>> 
>> 2. For rtl, does clear: right on an element clear an element with float: end
>> or float: start (or only float: left)? I would think the later case (start)
>> since the direction is reversed.
> 
> They'd clear anything to the left/right of them, which would include
> float:start/end if appropriate. 

Hmm. That seems like it might lead to unexpected outcomes, but perhaps it is something that the author could work around. I'm not certain.

> 
>> 3. Rejecting the previous to questions, should the values clear: start and
>> clear: end also be used (or only used) to clear floated elements with the
>> values of start and end? This seems more logical and maybe would keep it
>> simple.
> 
> It's possible.  Can you think of a use-case where you'd want to clear
> in a text-direction-dependent way?  (One that comes to mind is the
> "floating stack" of elements that float and clear in the same
> direction.  But is that a layout thing that's adequately served by
> right/left, or a typographic thing that needs start/end?)

There could be a layout that is primarily ltr that uses float and clear for layout purposes (so that the navigation bar is on the left and a footer at the bottom, for instance). Within that, there could be a large rtl block in which you have a drop-cap-like ornament with 'float:start'. In this case, I think you could want 'clear:start' for the paragraph after ornament, and then 'clear:all' for the footer. I'm not sure that 'clear:both' makes sense when there are more than two possible values for 'float', except for legacy purposes, but 'clear:all' does make sense, and is a more standard CSS keyword.

Received on Thursday, 3 December 2009 15:52:58 UTC