The end of the clearfix hack? | Hacker News Reader

The end of the clearfix hack?

rachelandrew.co.uk

123 pointspmontra78 comments

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?!

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

Here's the "clearfixed" version which is nonsensical: 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.

This is a great explanation, thanks. I'd never quite understood this either.

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

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

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!

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

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.

Nothing that yet another otherwise meaningless wrapping div won't solve..

> 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

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

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).

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....

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.

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

Floats remain useful for their original purpose: floating an inset piece of content inside a wider textual context e.g. an illustration picture or a pull quote. And for that you might still need a clearfix-type workaround.

Yes, and further to this - genuine question - Why would you use float-based layouts over flexbox for reasons other than backwards compatibility?

About the only reason I can think of off the top of my head is that you / your team already fully grok floats, they are sufficiently powerful for your use case, and you don't want to invest the time to learn flexbox to achieve the same outcome as you could already achieve.

Susy grid system is currently float-based and the most efficient way I'm aware of to create semantic CSS layouts with wide compatibility.

http://susy.oddbird.net/

In this case, flexbox actually is a bit awkward - one is often forced to pair flexbox with calc in this sort of situation. If the content, including text, is too long, it pushes the right container down a level unless the width is fixed to an appropriate size - this is doable with calc (for fluid layout) if one has control over the size of the left container, but otherwise it may be difficult to obtain the desired UI with flexbox.

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.

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

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.

It's all about the nested flex'd elements.

Do you have an example that would accomplish that? As in, one element centered vertically to the parent flexbox, and its sibling attached to the top of the column, but not effecting each others position?

Is there any reason to not use flexboxes nowadays? I've still been using floats, inline-block, etc. so my websites are compatible with older browsers, but I would rather just switch to using all of the new CSS properties.

There are a couple of bugs with IE and older versions of the stock (deprecated) Android browser using flexbox, but I think they're all handled easily enough. Also, they don't work with IE9 - God forbid you're still supporting that browser.

Still supporting IE8, and testing components in IE7. 150k visits last month from IE7, sigh.

150k? That's insane. What's the location for those visits? I'm kind of intrigued.

Well, that’s out of ~90m visits a month total. This is for GOV.UK, so I suspect most of them are government internal.

Do you think Gov.uk should be supporting that 0.25% of users, seems like it's probably a waste of resources. Can't you just settle for graceful degradation? Is there some DDA angle (supporting screenreaders) or other mitigation that's not obvious?

It’s not about percentages, it’s about numbers. We don’t actually go out of our way to support it on pages and we don’t tell other departments to test in it, but if you’re building a pattern library it makes sense to do the hard work up front. In terms of graceful degradation, yep. In our current patterns project we’ve dropped all JS for IE7 beyond the HTML5shim.

Our support schedule is at https://www.gov.uk/service-manual/technology/designing-for-d...

Like 5% of our traffic comes from IE 6-8.... Thank god for jQuery. And, I can't recall the percentage, but a surprisingly large amount from the stock Android browser (not Chrome, the one that ships on really old phones).

We have internal support for IE9. Our non-internal traffic for it is almost non-existent. We were getting a small portion of traffic from the stock Android browser as well, but we were finally able to convince them to drop support for it.

IE8 is bad enough. IE7 sounds like torture.

We're also on the cusp of CSS grids being available in all major browsers, and – considering people have started upgrading much faster – it should be supported for >95% of users within the next year.

You don't float anything?

The linked article uses an image floated left, with text wrapping around it. Curious to know how you'd [sanely] accomplish the same result in flexbox?

Floats aren't just for structural layout. Even with 100% browser support for Flexbox, I'll still be floating some things.

> Floats aren't just for structural layout.

In fact floats aren't for structural layout at all, they were used for it because there were no structural layout tools available at the time.

Does anyone know the drawbacks of simply using:

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

See bottom example here 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)

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.

If the browser doesn't support display: table, you could just put overflow: auto on the container and it'll expand to contain the floats.

http://caniuse.com/#feat=css-table

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

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.

Why doesn't it just crop the element to fit, as with everything else?

That was my immediate thought then I tried it out. I suspect it's to do with causing some hasLayout which recalculates the content dimensions.

hasLayout is IE-only and dead since IE7

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

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

This is my go-to fix also. Have used it for years with no side effects or bugs as a result.

Always used that one and could not care less about clearfix.

In case you want elements to appear outside the parent, like a dropdown menu.

In ancient times some browsers required setting a width or height as well.

This will cut off larger diffuse drop shadows, which is one immediate downside I can think of.

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.

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 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.

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.

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.

> IE10/11 are at about ~4% global usage

it doesn't mean anything for a business. for all you know 50% of users visiting a specific website could still be using IE10/11. global numbers were always irrelevant.

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.

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.

I'm not sure if users on a 4-year-old browser are as valuable as the others.

I suppose it would be useful to find out then.

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...

I'd imagine the 20% of the US population that has a disability translates into rather less than 4% of potential users of the average website helped by any particular engineering solution... (apart from basic common-sense design principles like not having tiny buttons or a layout so sensitive it breaks if people bump the text size up)

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.

Me challenging them is what got me not supporting IE9 :) .

Global usage is not the number that matters for businesses though - it's userbase percentage, and unfortunately that number for IE is quite higher than I'd like (over 10%).

Could be worse ... could be IE 8 and 9 (my case)

I work with a large enterprise client still utilizing IE9.

`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.

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.'