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

A dedicated property to clear descendant floats (was: Proposal for "overflow:clip" for stronger painting isolation)

From: Marat Tanalin <mtanalin@yandex.ru>
Date: Sat, 19 Oct 2013 00:28:33 +0400
To: www-style@w3.org
Message-Id: <197541382128113@web28j.yandex.ru>
18.10.2013, 19:48, "Tab Atkins Jr." <jackalmage@gmail.com>:
> Getting a container element to contain its floats has been addressed
> directly in the Sizing spec, though it hasn't gotten implementation
> yet. You can set "min-height: contain-floats;" to make it work:
> <http://dev.w3.org/csswg/css-sizing/#the-contain-floats-value>.

`min-height: contain-floats` looks somewhat interesting, but what if a web developer needs for an element to have both self-clearing _and_ some numeric `min-height`? Using a property for something that is not directly related to it and just causes unneeded limitations looks like a spec-design mistake.

What I as a web developer see as a good usable solution for self-clearing is to have a _dedicated_ property intended (exactly and solely) for the purpose of self-clearing (self-clearing is that some people call "clearfix" for some reason).

Possible syntax I propose for self-clearing:

    .example {
        self-clear: both;
    }

Possible values of the proposed `self-clear` property and their meaning are the same as for existing `clear` property. Unlike `clear` property that clears floats located _before_ the element, the `self-clear` property performs clearing of floats contained _inside_ the element.

Unlike `min-height: contain-floats`, it makes it possible to easily combine self-clearing with a numeric `min-height` and with anything else not related to self-clearing:

    .example {
        self-clear: both;
        min-height: 500px;
    }

=====

Below are some more thoughts about why it would be nice to have a dedicated property for self-clearing.

There are multiple techniques for self-clearing currently, but in fact they all are _workarounds_ that have _side effects_.

For example, using zero-sized `:after` pseudoelement for the purpose of self-clearing:

    .example:after {
        clear: both;
        content: " ";
        display: table;
    }

makes it impossible to use the `:after` pseudoelement for other purposes.

So even using preprocessors (where self-clearing construct can be encapsulated in a mixin) it cannot be abstracted entirely and we are forced to always remember exact way of self-clearing we're using; otherwise we end up with being confused like "Why my `:after` pseudoelement does not obey it's styles or behaves unexpected way" (answer is "because the pseudoelement is already used for self-clearing and its self-clearing styles are interfering with its styles added without taking into account that it's already used for self-clearing") or "Why self-clearing has stopped to work when I've used `:after` pseudoelement" (answer is "because self-clearing is implemented via `:after` pseudoelement itself, and the pseudoelement should not be used for anything else").

Thanks.
Received on Friday, 18 October 2013 20:29:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC