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

-------- Original-Nachricht --------
> Datum: Mon, 07 Jun 2010 21:15:38 +0200
> Von: Anton Prowse <prowse@moonhenge.net>

> 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

The clear-after property does indeed look like doing exactly what I was aiming for. (As an alternative, Tab's idea of allowing multiple values to the clear property is mentioned in the link you provided.) Do you know what were the reasons to drop this? Is there any chance clear-after (or clear:after with multiple values) will make it back into the spec?

Thank you also for the "easy-clearing technique" which will make things easier as long as there is no really clean solution - adding an empty element without touching the HTML is certainly better than the workarounds I mentioned in my original posting.
-- 
GMX.ch - Schweizer FreeMail-Dienst mit über 800.000 Mitgliedern
E-Mail & mehr! Kostenlos: http://portal.gmx.net/de/go/chfreemail

Received on Monday, 7 June 2010 20:54:06 UTC