Is clearfix deprecated? - html

You are aware of the age-old problem: Containers containing floated elements don't automatically expand their height to enclose their children.
One approach to fix this is the "clearfix" which adds a number of CSS rules to ensure a container stretches properly.
However, just giving the container overflow: hidden seems to work just as well, and with the same amount of browser compatibility.
According to this guide, both methods are compatible across all browsers that are important today.
Does this mean that "clearfix" is deprecated? Is there any advantage left in using it over overflow: hidden?
There is a very similar question here: What is the different between clearfix hack and overflow:hidden vs overflow:auto?
but the question isn't really answered there.

You can pretty much use overflow: hidden all the time.
But, there are exceptions. Here's an example of one:
Overflowing a container div horizontally but not vertically
The question there was:
There's a fixed height on this: http://jsfiddle.net/je8aS/2/
Without the fixed height: http://jsfiddle.net/thirtydot/je8aS/5/
How to clear the floats without using a fixed height?
overflow: hidden doesn't work: http://jsfiddle.net/thirtydot/je8aS/6/
You have to use some other method of clearing floats, such as clear: both:
http://jsfiddle.net/je8aS/3/
The clearfix class also works: http://jsfiddle.net/thirtydot/je8aS/11/
Here's a more important example of when you can't use overflow: hidden:
http://fordinteractive.com/misc/overflow/
That's not to say that clearfix is the only alternative - display: inline-block cleanly fixes that example:
http://jsbin.com/ubapog

As mentioned in another answer the downside to hidden is that it will, surprisingly ermm hide things like dropdown menus. However there is another way to contain with one line, by floating the parent container. This generally works where overflow: hidden has a downside, and also floating helps with a lot of legacy IE issues, again especially in lists. If you can use a width then I would use a "float in a float", or display: inline-block.
I'm not saying the "clearfix" has no use - but to me it's too widely entrenched into CMS themes (like Wordpress and Drupal) that I think in a lot of cases it's used too much and on divs that don't actually need to be cleared or contained.
I can't actually think of a situation where I can't use either overflow or float, over clearfix, but my brain's in holiday mode - but as it, clearfix, is a copy/paste solution that's sometimes the easiest thing to recommend, however it has to be the one which sets hasLayout for IE, which of course both overflow and float do too now as well.
added
this has just come up again: and brain not in holiday mode..
I'm really starting to think yes, clearfix is not necessary (at least I haven't yet found an example where it is) even #thirtydot's example above can be worked around with display: inline-block and still have IE6 support, the container having a fixed width has the IE7 and below hasLayout requirement, and by making it an inline-block for all other browsers it can be centered and the "offset" sticky-out elements will work fine while the container does stretch vertically
Example
I've also seen reference to a new improved clearfix for those collapsing margins using :before as well as :after in the clearfix hack, but unless I'm missing something the the demo is flawed - there is uneven whitespace in the pre elements and the "clearfixed" boxes do not actually contain any floats, as soon as you do float the elements in them, each method performs the same.
Note margins on pre elements don't react the same as others anyway (so try it with padding instead of margin to see the same picture while testing).. and there is also another IE "foible" whereby IE doesn't contain margins properly if they're not explicitly specified and in the demo there is explicit margins on the h2 but not the p so all things being equal a clearfixed element as demo'd by TJK in that page is artificially forcing the containment of the margins on a normal block element, much the same way as 1px top/bottom padding would do because browsers do this differently anyway!
If you do then float the elements inside those containers (the point of clearing anyway) - the margins do then contain as you would probably like them to, as they would if inside a new Block Formatting Context - without any extra :before part to the hack, all clearfix variations work equally well!
See the demo reloaded
So to my mind there is no need for this "clearfix" way anymore, simply find the best way to create that new Block Formatting Context, using haslayout for older IE's.. the properties for both are the same!
as TJK does point out in his article : http://www.yuiblog.com/blog/2010/09/27/clearfix-reloaded-overflowhidden-demystified/
Better alternatives
If you can apply a width to the
element containing floats, then your
best option is to use:
display: inline-block; width: <any
explicit value>;
I think that's fair and even with 100% elements which might need padding, you can do it in conjunction with box-sizing
.clearfix {
display: inline-block;
width: 100%;
*width: auto;
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}

overflow:hidden is very 'powerful' (I've been using it for several years, and I agree to what David said) but at the same time exposes to a problem. If i.e. inside the container you have some abs elements that you have to drag and drop outside of it, u won't be able to see them outside the container. In this particular case u need to use that 'clearfix' trick ;)

Yes, it's "deprecated" by CSS Display L3:
Created the flow and flow-root inner display types
to better express flow layout display types and to create an
explicit switch for making an element a BFC root. (This should
eliminate the need for hacks like ::after { clear: both; } and
overflow: hidden that are intended to accomplish this purpose.)
So now, the proper way is
display: flow-root;
Sadly it's a recent addition, so browsers haven't implemented it yet.

I've been recommending the overflow: hidden method for many years. It is widely supported.

I recently discovered to my pleasant surprise that overflow:hidden works perfectly nowadays. I had been using the clearfix method up until around 6 months ago and it is quite bloated in comparison.

Note: Make sure you have the correct DOCTYPE set if you're just testing. Caught me out a few times and I always forget!
In IE9 for instance the following just won't work without <!DOCTYPE html> at the top.
<!DOCTYPE html>
<html>
<style>
#bottom_panel {
overflow: hidden;
background: orange;
border:1px solid red;
}
#bottom_panel .col1 {
background: red;
float: left;
width: 100px
}
#bottom_panel .col2 {
background: yellow;
float: left;
width: 70px
}
#bottom_panel .col3 {
background: green;
float: left;
width: 150px
}
.clear {
clear: both;
}
</style>
<div id="bottom_panel">
<div class="col1">this is col 1</div>
<div class="col2">this is col 2. It's taller than the other columns because it's got more text in ot</div>
<div class="col3">this is col 3</div>
</div>
<div>
This should not be floating around! Should be underneath the columns!
</div>
</html>

I wouldn't say that clearfixing is deprecated. However, I would say that most versions of the clearfix currently being used are outdated.
According to the experts, this is the version your should use today:
.clearfix:after {
content: "";
display: table;
clear: both;
}

Related

CSS best practice between margin-top and margin-bottom when both can work?

What is the CSS best practice when you want to give space to an element placed just after a first element.
Asume this html
<div class="a-block">lorem</div>
<div class="another-block">ipsum</div>
Should you use this css
.a-block { margin-bottom: 10px; }
or
.another-block { margin-top: 10px; }
?
i would use :nth-child width margin-top
div:not(:first-child) {
margin-top: 10px
}
<div class="a-block">lorem</div>
<div class="another-block">ipsum</div>
<div class="another-block-1">ipsum</div>
<div class="another-block-2">ipsum</div>
In my opinion, margin-top in the second block is a better practice.
Indeed, the first div shouldn't take care about others divs since it was the first.
If the second is removed I shouldn't have to remember to remove margin-bottom from the first.
Using margin-top would eliminate the need of using a next sibling selector. It also removes the need of removing the bottom-margin from the last-child to avoid padding discrepancies when using text in panels or boxes.
Since nobody has mentioned it yet, I wanted to add that you could use both at once. This will cause them to meld together through a feature called margin collapsing. In certain situations this could as well be the best practice since you can use it to declare "this element need at least this much space below it". Note that margin collapsing may backfire on you if you accidentally use properties that disable it, such as floats, borders or flexbox.
.a-block {
margin-bottom: 10px;
}
.another-block {
margin-top: 10px;
}
div {
background-color: #e0e0e0;
}
.float {
float: left;
clear: both;
width: 100%;
}
<div class="a-block">Only 10px margin</div>
<div class="another-block">between these elements</div>
<hr />
<div class="a-block float">Double margin because</div>
<div class="another-block float">of the float</div>
It is completely up to the context in which the CSS is needed - is the short answer. It depends whether you need the first element pushed down as well as all the other elements. or you need the first element to be flush with the top of the parent but you need the bottom element to have a margin at the bottom.
The common sense thing to think is that the first element is already there so the second element will surely need to be "pushed" down, so the natural thing to do would be to add margin bottom to the previous element (at least that is the way that my brain works).
Current CSS browser support dictates that this is the preferred method. Due to the fact that, in CSS, there is a "next sibling" selector (~), an "adjacent element" selector (+) , and :first-child is more widely supported than :last-child is (purely because it is more difficult to implement in a browser than :first-child is). Namely this :last-child support issue is IE8 but this still affects us today when developing for certain clients.
There are no previous sibling selectors, so this makes me prefer the method of adding margins and paddings to the bottom of elements and not the top. Purely just to keep everything in my CSS to be using the same principal of "pushing things down from above or selecting the first element"
You should always be consistent on how you apply the styles.
For example, if you have a hero and think about the inside elements. For example, you have a title, optionally a button and optionally text below that. You can end up with having margins or padding that should not be there and were intended to have a button there.
Also, the point about collapsing margins is important when you have a design with different use cases. Padding doesn't collapse but if used improperly, can cause elements not to center 'properly'.

How to make more divs after each other non-wrapping, but the entire list wrapping?

I have divs after each other that look like this.
<div class="tag">one tag</div>
<div class="tag">second tag</div>
<div class="tag">third tag</div>
...50 more of them....
(in CSS)
.tag {
display:inline
}
I found out that I have too many of them and they start breaking in the middle, and I don't want that.
However, when I set the nowrap like this
.tag {
display:inline;
white-space:nowrap;
}
all of them are on one line, making more than 100% of the window. I don't want that.
What I want: if there are too many of these divs on one line, the list of the divs can break, but the divs themselves don't. I just don't want to break the divs in the middle.
I hope I tell it clearly enough.
If I understand right, you want them to lay side to side, and then break to a new line when the row is full, but not in the middle of a div.
All you need is
.tag {
float: left;
}
See fiddle here for demo.
You can also add padding-left: 5px; if you want some space between them.
.tag {
display:inline;
white-space:nowrap;
float:left;
}
That worked. (and adding "clearing" empty div with clear:both under that.)
Depending on the browsers you need/want to support, you may find using
.tag {
display:inline-block;
vertical-align:top;
}
a better solution. Since it is a <div> that you want to apply this to, the style will not work out of the box for IE5-7 - see http://www.quirksmode.org/css/display.html#t03. There are workarounds of course - How to fix display:inline-block on IE6? - if you want to use it with those browsers.
The benefit of inline-block is that you do not need to clear the floated content and also that your elements are not rendered out of normal flow. I try to avoid floating elements where possible as in my experience it has caused layout problems.
However, there are a couple of potential catches with this approach. One of which I have already addressed, by adding a vertical-align:top rule. See a previous answer for why this happens - https://stackoverflow.com/a/12950536/637889
The other is due to potentially unwanted white-space between the inline-block elements. See http://css-tricks.com/fighting-the-space-between-inline-block-elements/ for some clever ways around this.

Element's left edge is dynamic (inline...), but right edge is fixed?

Here is a demonstration: http://jsbin.com/egezog/edit#html,live
Sorry if this is newby, but I can't figure this out. I have a title, and I need (in decoration purposes) a line going from its edge to the right of the page (not an actual page, but a wrapper, but I have overflow hidden anyway). The wrapper is fixed in width, but the titles vary in length. I can't use absolute position, and I prefer not to use tables. And if we get this sorted out...
Here: http://jsbin.com/ibeciv/edit#html,live. So in the end, I actually prefer this all right aligned. You may ask, why do I need advice if it's there, implemented? Well, as you may see, the title is in two rows, which is unacceptable in my situation, and also, I prefer not to use tables.
I guess I can use float:right, to right align, but well, it depends on the implementation that I hope you'll advise to me. Thanks!
PS: jsfiddle is down for me right now, so here I used jsbin.
http://jsbin.com/ujiquq/edit#html,live
Will work in IE8 and all modern browsers. The background of the parent element can be anything. The line will still be vertically centered no matter what font-size is chosen.
HTML:
<h3><span>The title</span></h3>
CSS:
h3:after {
content: '\00200B';
background: url(data:image/gif;base64,R0lGODlhAgABAIAAAP8AAAAAACH5BAAAAAAALAAAAAACAAEAAAICBAoAOw==) left center repeat-x;
display: block;
overflow: hidden;
}
h3 > span {
float: right;
padding-left: 5px;
}
Here is a solution without using tables:
http://jsbin.com/ujawej/5/edit
And here is the one with tables (from my comment):
http://jsbin.com/osovev/2
Write like this:
HTML
<div class="title"><span>Title Here</span></div>
CSS
.title {text-align:right;border-bottom:1px solid red;}
span{background:#fff;float:right;margin-top:-9px;}
Check this http://jsbin.com/ibeciv/3/edit
UPDATED
Check this http://jsbin.com/ibeciv/4/edit

Mysterious ':after' css rule

I have recently inherited a large web project. Before taking this on, I had primarily been working with applications, so some of the technology is new to me.
The css has the following class:
.group:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}
Lots of things all over the website have group as one of their classes. As far as I can see, this is the only bit in the css that references it.
I tried taking away the group class in some places, as it didn't seem to be doing much. However, this caused all kinds of weird things to go wrong - for instance, colour from one element would seem to run on to the next. I don't see why adding a period to the end of the elements is stopping this.
Could anyone elighten me?
Edit: Here is one of the places where the group class is used. If I remove it, so that the div has only the class wrapper, the whole page breaks.
<div id="header">
<div class="wrapper group">
<div class="fl">
myHandle |
features |
about
</div>
<asp:Panel ID="pnlNotLoggedIn" runat="server" cssclass="fr">
sign in |
sign up
</asp:Panel>
</div>
</div>
That's more commonly known as "clearfix" - though "group" is arguably a more semantic class name, if less recognizable.
It's a technique to "clear/contain floats": http://www.ejeliot.com/blog/59
More information on clearfix:
http://www.positioniseverything.net/easyclearing.html
http://www.yuiblog.com/blog/2010/09/27/clearfix-reloaded-overflowhidden-demystified/
What you're seeing is a .clearfix effect using the :after pseudo-class. When the hidden content block is added, the .group element will wrap all it's floated contents, which allows background colors to fill the correct area.
I could be mistaken, but it looks like .group:after is being used as a .clearfix in a way. While it may not seem like it's doing much, it's allowing the page to render correctly, so you should just leave it where it is.
:after is a pseudo-class which allows you to insert content after a selctor. In this case, it's adding a clear fix to properly clear .group which probably has floated content. This can cause the container not to expand to contain all the content. It's a rough equivalent of
<div class="group">
…content here…
<div style="clear:both"></div>
</div>
The advantage of :after is that it doesn't require extra markup.
Also the fact that there is a clear: both; property defined implies that there are floats (e.g. float: right; or float: left;) in common use, and this class is being used to neutralize those.

div Height: 0 problem in IE

to clear: both my content i use this:
CSS:
.clr {
clear: both;
height: 0; /* i have tried 0.001em to */
line-height: .001em;
overflow: hidden;
}
HTML:
<div class="clr"> </div>
it works perfectly in every navigator. But in IE 7 & 8 the div still have a height of a few pixels. How can i avoid this?
It's a IE font problem.
Add
font-size: 0;
to your css declaration
Just coming across this and the answer Ben gave makes sense but it was incomplete in dec of 2011 on IE 7 (legacy support necessitates this.
font-size:0; is a good start but didn't initially do it for me.
Along this line of thought, you need to be mindful of line-height. If you set line-height higher up in the DOM, likely due to the nature of these things, it get inherited ( as was happening to me )
If you have set line-height on a parent, be sure to set it explicitly on the child you are trying to use to force the clear:
font-size:0;
line-height:0;
-Brandt
Have you tried using "easy clearing" (or "clearfix") for markup-less clearing. It's usually much simpler:
http://oncemade.com/renaming-and-extending-easy-clearing-aka-clearfix/
Using empty DIVs to aid presentation is generally bad practice. You might consider changing the CSS of the elements you to clear. A lot of the time clearing can be replaced by the use off inline-block. See http://google.co.uk/notebook/public/06909424369135510368/BDROpQwoQ4-fhwfsj#SDRZLQgoQtfHkwfsj.
Rich