
The end of the clearfix hack? - pmontra
https://rachelandrew.co.uk/archives/2017/01/24/the-end-of-the-clearfix-hack/
======
OJFord
I'm not really a front-end kind of person, but whenever I've written any CSS
this has, I think, literally _always_ bitten me. I try to read about it and
understand it 'properly' every time, but clearly I never do.

Why is the unhacked behaviour desirable? If I put a thing in a thing, surely I
want it to stay _in_ the thing?!

~~~
masklinn
Because the original purpose of floats is not layout (where you want the thing
to stay in the other thing) it's typographic floats, like pull quotes or info
boxes or pictures. In that case, even if your float is in a paragraph you
don't want to "expand" the paragraph past the end of the float if the float is
longer than the paragraph, you want the following paragraph to be laid out
around the float instead.

Here's a demo:
[http://codepen.io/anon/pen/ggGgWb](http://codepen.io/anon/pen/ggGgWb)

Here's the "clearfixed" version which is nonsensical:
[http://codepen.io/anon/pen/xgXgry](http://codepen.io/anon/pen/xgXgry)

That floats were press-ganged into layout does not mean their basic behaviour
is bad, it just means they were used for something that was never intended
(due to a lack of actual layout tools in CSS until CSS3) and they were not
very good at it.

And note that the lack of layout tools was not limited to "applicative"
layouts, most papers are laid out in multiple text columns yet that fairly
simple and common layout was not supported either until CSS3.

~~~
lomnakkus
Those demos look completely identical on my browsers (Chromium, Firefox). The
CSS change is there, but the rendered output looks identical.

~~~
masklinn
That is odd, I just opened them in Firefox 51 and I do get the rendering I was
expecting: [http://imgur.com/a/Bke7v](http://imgur.com/a/Bke7v)

~~~
lomnakkus
Oh, I see what happened. I have a minimum font size which makes the first
paragraph tall enough so that it wraps all the way around the image -- so the
clearfix is effectively redundant with my font sizes. The image clears it up,
thanks!

~~~
masklinn
Ah, makes sense, I should probably have explicitly set a small font size but
completely forgot about the possibility of that issue.

------
bartl
I don't like the idea that this is tacked onto the "display" property.
"display" is for the _outer_ display properties of the div, but this flow-root
is for the _inside_.

You cannot have a div that is both `display: inline-block` and `display: flow-
root` at the same time, for example.

~~~
masklinn
> I don't like the idea that this is tacked onto the "display" property.
> "display" is for the outer display properties of the div

That's really not true[0], "display: flex", "display: grid" or "display:
table" are all _inner_ display properties, which is why inline-flex, inline-
grid or inline-table exist ("display: flex" sets the outer display mode to
"block" and the inner one to "flex", "display: inline-flex" sets the outer
display mode to "inline" and the inner one to "flex").

Which is why CSS3 split display properties between _outer display_ (block,
inline or run-in) and _inner display_ (flow, flow-root, table, flex, grid or
ruby), which can be specified independently e.g. `display: inline flow-root`.

Furthermore `display: inline-block flow-root` makes no sense

1\. `inline-block` is specifically a "legacy" display property which impacts
both inner and outer display (and thus is not compatible with a separate inner
display property)

2\. `inline-block` already means `inline flow-root` so `display: inline-block
flow-root` would expand to `display: inline flow-root flow-root`

[0] and has not been since CSS2 and display: table, possibly CSS1's display:
list-item

~~~
jpfed
That makes it look like the "display" property will turn into a css shorthand
for "inner" and "outer" display properties... is that the case?

~~~
masklinn
It is already that, it's been that pretty much all along, but for most of its
history you couldn't set the inner and outer variants separately, you had to
use "precomposed" values like inline-table. AFAIK you can't set the inner and
outer display types via separate properties.

Furthermore there are values which have more complex interactions/natures than
just inner/outer e.g. "contents" (which removes the element's box but leaves
the descendants — including pseudo-elements), "list-item" (which can be
combined with any outer type but only the flow or flow-root inner types, and
generates an internal pseudo-element), or the "internal values" which only
make sense within wider display context (table and ruby).

~~~
gsnedders
There was, briefly, in Display Level 3 drafts, display-inline and display-
outside properties, with display being a shorthand additionally supporting
legacy values (like inline-block). It's now expected to be in Level 4[1].

[1]: [https://lists.w3.org/Archives/Public/www-
style/2014Sep/0399....](https://lists.w3.org/Archives/Public/www-
style/2014Sep/0399.html)

------
talmand
I've seen enough comments about using floats for layout that I think some
people need to read the article. The example in the article is not using float
for layout. It is using it for the original purpose, floating an element to
the side for other elements to flow around. The problem shown is when the
floated element is taller than the resulting containing parent. Which is a
common problem and a valid use of float.

------
neals
I've moved away from float entirely and mastered the Flexbox. Which has made
my live easier.

~~~
devwastaken
I really like flexbox, but its still missing functionality and somewhat
misleading in its options. Everything is row-column based, but you can select
between row or column, but in the column option, only justify-content will
position content vertically. If you want something like forcing an element to
be in the middle vertically, and have an element above it, you can't do that.
align-self only works on rows. I really don't understand why they didn't make
it work vertically if you have column mode.

~~~
mark242
A flexbox "column" can also be a row. You can have a container item centered
vertically and also have it include two items.

~~~
devwastaken
In this case, I needed two children elements, one would be centered vertically
in the column, and the other would be at the top of the column, but they would
not effect each others position. I could only make one where the two elements
were next to each other, or they effected each others positions, so the
centered element was not actually centered. I ended up putting in three
elements, the bottom one the same size as the top, but hidden, so the center
element would stick between the two.

------
JohnDotAwesome
Does anyone know the drawbacks of simply using:

    
    
        .container {
          display: table;
          width: 100%;
        }
    

See bottom example here
[http://codepen.io/jrf0110/pen/xgXPGj](http://codepen.io/jrf0110/pen/xgXPGj)

I've never had to use the clearfix hack (that's probably a lie, but I can't
recall a time in my career where I didn't just use the display: table; width:
100%; method)

~~~
camtarn
It wasn't supported until IE8. For those of us who had to support IE6 till
well after its sell-by date, prop-based clearing was an important tool in the
toolbox.

------
dutchbrit
I usually use overflow:hidden on containers, what are the pro's and cons of
this compared to clearfix?

~~~
martin-adams
Interesting, I did not know that overflow:hidden resized the parent container
to the floated elements.

It looks like the difference may be some legacy IE6 thing.

~~~
rossriley
You can set overflow to visible too, just setting overflow to non-auto is
enough to trigger it.

~~~
SippinLean
No, just auto, hidden, overlay, and scroll. Visible will not trigger the
clearfix.

------
ygra
So a draft standard that's implemented in the current beta (alpha?) versions
of Chrome and Firefox. So the end for the hack is nigh ... in about 5 years, I
guess.

~~~
stupidcar
This isn't really true anymore. All the major browser vendors push out new
releases pretty frequently. Even Apple and Microsoft tend to put out a new
release at least every six months or so. And because of the ubiquity of
software / OS updates, these tend to get deployed to the majority of users
fairly rapidly.

For example, consider a feature like arrow function support in JavaScript:
[http://caniuse.com/#feat=arrow-functions](http://caniuse.com/#feat=arrow-
functions) Click "usage relative" to scale by the relative popularity of
different browser versions.

Despite only being standardised and implemented in browsers last year, arrow
functions are already supported in the large majority of deployed web clients,
including Edge, Firefox, Chrome and Safari, both desktop and mobile.

Nowadays, new features, particularly relatively small and uncontroversial ones
like display: flex-root, can get implemented across browsers very quickly.

~~~
Bahamut
A lot of people still have to support IE10/11, including myself - until
browser support is mostly on evergreen browsers & browsers keep up to date on
implementing the new standards, ability to use the standards hinges upon a
couple of years buffer in some cases.

It still is largely true unfortunately.

~~~
stupidcar
As I already said: browser support _is_ mostly on evergreen browsers, and
browsers _do_ keep up to date implementing the new standards. The stats make
this very clear. To say otherwise is to promote a view of the world that is
ten years out of date.

IE10/11 are at about ~4% global usage. Less than Opera Mini. And a large
number of those users will have access to another browser. We've found many
enterprises keep IE around to access legacy services, but let people install
Chrome in order to access things that need a modern browser.

The days when it was worth supporting IE for new development work has long
since passed. Company policies that mandate doing so should be challenged as a
waste of time and money.

~~~
inopinatus
4% is a high number in this context. If I cause a problem for 4% of my users,
I will be spending the next week answering support issues and nothing else.
When it is two orders of magnitude less, then we can talk.

~~~
saurik
Yeah: 4% of users of my site means like 40,000 people :/. For websites that
sell things, I always think of it in terms of "if you could do some more
engineering work and get 4% more revenue, would you?". I do not understand
people who feel like 4% is some tiny number.

~~~
stupidcar
But that revenue isn't free. It has a cost in terms of time and effort in
engineering the IE support, and then maintaining it. This is time and effort
that could be better spent enhancing the site in other ways. For example, ~20%
of the US population has a disability[1]. Investing effort in improving
accessibility would be more sensible, economically speaking, than maintaining
IE support, but I still see developers spending hours working around IE CSS
bugs, while doing almost nothing to improve accessibility.

[1]
[http://www.census.gov/newsroom/releases/archives/facts_for_f...](http://www.census.gov/newsroom/releases/archives/facts_for_features_special_editions/cb12-ff16.html)

~~~
saurik
Most of the people in that 20% likely have a disability that keeps them from
working or walking but not from using a computer in a normal fashion.

That said, you are responding to my incredulity, and _I_ take disabilities
sufficiently at least sufficiently seriously that a blind person presents
every year at the conference we have been running for our ecosystem and we get
tons of praise for our support of their issues.

In some cases, I will even argue that supporting old browsers is related to
accessibility: if you are making a product such as a communications tool, one
where many if not most users don't directly pay you for their use as you make
money from a subset of users, people on older browsers are often people with
older computers, who have lower income and less ability to arbitrarily plunk
down money to upgrade their technology.

Just as we legally mandate people consider the needs of the disabled, I
personally think we might be in need of some regulation that demands we also
consider the needs of the poor and disconnected: there are tons of users (by
which I mean "entire percentage points, by number competitive with blind
people as a group of users but with less sympathy from the public") using
older versions of browsers because they were stranded by Apple on an older
iPod or iPhone with an out-of-date version of MobileSafari, or who would have
to pay for a new version of Windows to even be able to use Chrome, or whose
only access to a computer is a shared facility where the computers run
something they have no control over. When we build websites that don't let
them use our service, we essentially are building an implicit class hierarchy.

------
drinchev
`float` should not be used for layouts, but for placement an image inside text
( e.g ), which is it's purpose.

Nowadays I don't use floats anymore. Flexbox is the current layout
recommendation and I encourage you not to create legacy CSS stylesheet layouts
with float.

~~~
camtarn
To borrow and mangle a Zawinski quote:

'Some people, when confronted with a layout problem, think "I know, I'll use
floats." Now they have two problems.'

------
JustSomeNobody
> The end of the clearfix hack?

Not until all browswers support it.

~~~
pix64
You could make a JS polyfill fairly easy.

~~~
dinodino
I do agree, we still need to wait for all older browser to implement this
(especially think of all the mobile browsers nowadays).

If making a polyfill is the solution, we risk ending up with a bigger polyfill
file than the actual CSS implementation in the browser. If that is the case we
can better do styling with JS.

------
ino
I see that you can use "height: 100%" on the inner item to fill the height of
the parent that has "display: flow-root".

I've had difficulties implementing similar things in the past.

~~~
bchen
To make a child element the same height as the parent, you can set the parent
container to position: relative, and in the child element, set it to position:
absolute; top: 0; bottom: 0. The downside of this trick is that the child
element is now absolutely positioned and no longer behaves the same.
Alternatively, you can use flexbox to do this, if using it is an option.

~~~
pix64
My favorite use of this is making a resizable box that always maintains the
same aspect ratio. Padding % is out of the element's width. So width: 100%,
padding-top: 50% will make a block that is 2:1 that resizes automatically.

------
nailer
Just use flex and avoid the float mess entirely.

(Obviously: starting from date supporting old browsers costs more than
supporting them brings in, which depends on your product and your customers)

------
dfar1
I will remove clearfix from my stylesheets once ie9 supports it, or in 2050..
.whichever one comes first. :)

