Re: [CSS basic box model] Proposal: new value for the clear property

Tab Atkins Jr. wrote:
> On Sun, Jun 6, 2010 at 12:58 PM, Markus Ernst <derernst@gmx.ch> wrote:
>> I suggest to add a value "inside" (or whatever better keyword) to the clear property. clear:inside will be applied to the containing element of the floating blocks, rather than to the following element.
>>
>> Use case 1: A box with images inside, with a background color and a border around the box.
>>
>> <div class="imagebox">
>>  <img src="img1.jpg" alt="">
>>  <img src="img2.jpg" alt="">
>>  ...
>> </div>
>>
>> .imagebox {
>>  border:2px solid red;
>>  background:yellow;
>>  clear:inside;
>> }
>> .imagebox img {
>>  float:left;
>>  margin:10px;
>> }
>>
>> Without clear:inside I need to add a clearing element such as <div style="clear:left"> as the last element of the box, which is ok as a workaround, but not as a concept.
>>
> 
> The current popular hack to make this work is to apply overflow:hidden
> to the container.  That, or using table-*, or any of the other similar
> hacks, all have the effect of making the container a "block formatting
> context" or BFC.  BFCs don't allow their child floats to escape from
> them, or allow sibling (ancestor?) floats to intrude into them either.
> 
> There's been requests before for ways to force an element into
> becoming a BFC, which would solve this without the side effects of
> applying overflow or using display:table.  That would work.
> 
> The only thing I'm not sure of is if it's strictly necessary to summon
> up a full BFC to solve the case of making a container wrap its
> descendant floats.  It may be that it's sensical to create a
> lower-octane property that does *just* this.  But then again, it might
> not make sense to wrap floats without being a BFC.  I'm not quite
> knowledgeable enough on the arcane details to tell whether it makes
> sense to slice the concepts any thinner.
> 
> In any case, though, I don't like the specific approach advocated
> here.  ^_^  I can easily want an element to both wrap its descendant
> floats, *and* clear any sibling floats.  The current ability of
> 'clear' and what is being proposed here are thematically related, but
> functionally perpendicular.  We'd either have to let 'clear' accept
> two values (like "[left | right | both] || inside") or create a
> separate property for this ability.
> 
> ~TJ
> 
> 

overflow:hidden is indeed a popular hack, but a nasty one.  At the very
least, overflow:auto should be preferred so that you stand a fighting
chance of still being able to reach your content when you bump up the
text size.  If you actually /want/ a block formatting context (with
everything that implies: prohibition of margin collapsing, acting as
scope for dependent clears, avoidance of sibling floats) then 'float',
and 'display:inline-block' can be equally as useful as 'overflow'.  Of
course, they all have their own idiosyncrasies, since there is currently
no such thing as a "neutral" block formatting context.

However, exploiting a BFC for the sole purpose of containing floated
dependents is rather like using a NASA robot to wield a sledgehammer to
crack a nut....  An (also popular) alternative way, which doesn't
involve BFCs, is to use the "easyclearing" technique:

div:after {
        content: ".";
        display: block;
        clear: both;
        height: 0;
        overflow: hidden;
}

This technique is well-known and has been around for many years.
(Despite first appearances, there's nothing magic about it; the end
result follows perfectly logically from the specified behaviour of the
various CSS properties used.  Note the use of the :after pseudo-element.)

Since the technique doesn't involve creating a BFC, you avoid the other
features which define them.  Most notably, a container with easyclearing
applied will still collapse margins, both with its siblings and with its
children.

Both approaches described above have valid use cases, and choosing
between them really should boil down to whether you really do want a BFC
or not.

Note that when I appealed for a "neutral" BFC in [1], fantasai drew my
attention to a proposed clear-after property[3] which is more the kind
of thing that Markus had in mind.  It got dropped from the Basic Box
Model spec, though.

Cheers,
Anton Prowse
http://dev.moonhenge.net

[1] http://lists.w3.org/Archives/Public/www-style/2008May/0262.html
[2] http://lists.w3.org/Archives/Public/www-style/2008Dec/0201.html
[3] http://www.w3.org/TR/2002/WD-css3-box-20021024/#the-clear-after

Received on Monday, 7 June 2010 19:16:53 UTC