Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Is it good idea to add clearfix to all div elements to prevent container collapse situations?
Or to use it just on classes like this ?
<div class="container">
More div elements...
</div>
.container::after {
clear: both;
content: “”;
display: table;
}
You use a clearfix only when the child elements are using floats, to avoid collapse situation. Otherwise no need to use clearfix
.clearfix::after{
content:"";
display:table;
width:100%;
clear:both;
}
As #Chandra Shekar worte, you should only use it when using floats. But note one detail if you use it:
In the CSS rule you posted, you wrote: content: “”; Those are typographical quotes which won't work as desired. Change that to regular quotes, like content: "";, or also single (non-typographical) quotes like content: '';
In my opinion, it's a terrible idea, for the following reasons:
Clearfix is a hack. It was introduced as a workaround for
another hack — using floats as a main block layout tool, which they
were never meant to be (as well as tables!). When float are used for
what they were meant to (incut illustrations, tables etc. in long
texts) the fact they cross the boundaries of blocks (in both
directions, from outside to inside and vice versa) is a feature, not
bug. Clearing everything inselectively would lead to ugly holes in
the document, text would not nicely flow around floats anymore.
Clearfixes add pseudo elements to the blocks. These pseudo
elements have zero size and are invisible if the hack is used for
what it was invented (to make the block contain nested floats and,
optionally, margins of its children). But it is not definitely the
case in other situations. For example, if you turn such block into
Flexbox container and set it justify-content:space-between, you
would get unwanted space at the end of the container.
It's because this pseudo element would turn into flex element and
it would follow Flexbox placement rules, affecting the
position of other elements. Same for Grid layout.
Clearfix hacks based on the clear property are not ideal
even for for containing floats! The 'clearfixed' blocks stay in the same block formatting context (BFC) as their neighbourhood, so they may be affected by other floats in the document (e.g. a floated previous column). The other approach for containing floats, based on creating the new BFC (mostly used in
form of overflow:hidden, but there are other alternatives, each
with its own strengths and downsides) is in general much more
reliable. Please check out this Codepen demo that compares the
effect of different solutions to containing floats problem:
https://codepen.io/SelenIT/details/qrORXm/.
Personally, I'd recommend not using floats for layout at all, so no 'clearfixing' would be needed for anything. Flexbox has much more layout possibilities than floats ever had, and browser support for it became extremely good now. Use clearfixes as a last resort, if no other way to solve the specific layout problem can help you.
Related
I have a div that I would like to keep inline-block but I want to keep any other elements from appearing on the same line as it.
I know that display:block will clear all the elements after it.
I know that adding a BR tag will clear all the elements after it.
But I would rather use a style such as clear:both except that only works for floating elements.
Is there a CSS style that I can use to clear all the elements after it while continuing to use inline-block?
I've seen another similar question here but no one actually answered the question. I'm 100% not interested in alternatives such as using floats. There was one answer using CSS using content after but it does not work (link).
#Container:after {
content:"\a ";
white-space:pre;
}
Here is a link to an example on JSFiddle. I want to add a break after BorderContainer20016.
Let me repeat. I'm 100% not interested in alternatives such as using floats.
This question already has answers here:
Is there a reason why CSS doesn't support ids and classes, starting from numbers?
(8 answers)
Closed 7 years ago.
Here's a strange one. This seems pretty simple but just isn't working.
Fiddle
I have images within a container. Images with class="1" should take up the full width of the container div. Images with class="2" should be able to fit 2 images side by side, taking up the full width of the container div. Images with class="3" should be able to fit 3... you get the idea.
However, even though the classes are being applied (inspect the elements!), the styles are not. The only thing that seems to work is a general style for #container img, which Iyou can test in the fiddle by removing the ".1" or ".2" from either style. As soon as you add .1, the images no longer take on the style, even if they are class="1"!
All I can think tis that maybe tags don't support the class attr? But I don't think that's true.
CSS class selectors cannot start with a number.
Use an attribute selector or (more sensibly) better class names.
The problem is that
In CSS, identifiers [...] cannot start with a digit.
That means that class selectors can start with a digit, but you must escape it properly.
To escape a digit d, you can use \00003d or \3d (note the whitespace).
For example,
.\31 {
background: #0f0;
}
<div class="1">Foo bar</div>
What is the purpose of an empty comment in a clearfix div? I assume this is for some sort of older browser shim; not sure why you would want to go around putting empty comments everywhere though. Seems just one or two CSS rules would be a heck of a lot easier to maintain.
If the website has two divs next to eachother using display: inline-block, the whitespace between those divs will add annoying space in the layout. To combat this, developers use html comments that start right after the closing tag of the left div, and end right before the opening tag of the right div, with no space between the tags.
CSS can (or could at the time) only format elements and pseudo-elements. An element after the float is needed for clearing the float, i.e. for returning to the normal document flow.
The clear declaration is in the "one or two CSS rules", particularly those whose selector contains (or is) .clearfloat. That fixes the height of the box of the float having an otherwise last child element that is not a float. I should look like so:
.clearfloat {
clear: both;
}
More elaborate and hackish workarounds are known, for example:
.clearfloat {
clear: both;
height: 0;
font-size: 0;
line-height: 0;
overflow: hidden;
}
But in some layout engines (particularly MSHTML < 8) the clearing element must have content. Yet we do not want that dummy element to be visible. Hence the (empty) comment.
This is actually pretty common. I wondered about this as well when I was younger. As far as I know, this is to signal to other programmers that the contents of the div were left intentionally empty, and this serves as a completely "blank" content in the div.
In other cases, it may be used to remove whitespace.
I'm digging through some older code on a site that I'm working with, which uses iconize. The way that it seems to work is by adding a class like this...
a[href=$='.pdf']{
padding: 5px 20px 5px 0;
background: transparent url('icon.gif') no-repeat center right;
}
Is there any benefit to doing it that way than the way that I'd have done it? Something like this...
a[href=$='.pdf']:after{
content: url('icon.gif');
vertical-align: sub;
}
Here's a fiddle to demonstrate both of them...
JSFiddle
My question is... What are the benefits, if any, of using pseudo-elements vs. standard padding and background positioning for appending/prepending images to elements?
Just a few initial and later thoughts. I may still think of some more to add.
Padding/Background
Advantage(s):
Works for IE6-7 (i.e. older browsers).
If one wanted to overlap the icon with the text, especially if centered, this would be easier to implement.
Disadvantage(s):
More thought needed to implement (must calculate some factors).
For older browsers, only one background was supported, so if another background was needed, then there was a conflict to be resolved.
If browser is set to not print background images, then a "gap" for the padding will still exist in the printed text, but no image will be there. This could be resolved through print media css.
Pseudo-Elements
Advantage(s):
Easier to implement (no calculations needed).
It can have its own padding, border, opacity, etc. applied if desired, just as if it were a real element.
Related to #2, it can actually be moved outside the element if needed or desired.
Semantically, it is being implemented in a more appropriate manner. The icon is not really a "background," but neither is it an essential part of the html that a content img might be, so the pseudo-element fits the bill for enhancing the presentation, but not causing issues if it is missing (in older browsers).
In CSS3 browsers (and possibly CSS2), usually less code can be used to switch between right or left aligned icons (see "Discussion about code length" below).
Disadvantage(s):
Only one (of each type) allowed per element, so if it is needed for something else on an element, then you can have conflict.
Not supported in older browsers.
Some elements (replaced elements) cannot take pseudo-elements, so this would not even be an option.
Discussion about code length
EHLOVader noted in a comment to the question that part of his concern was extra coding that might be needed for pseudo-elements as opposed to background/padding if one wanted to switch to a left side icon. He gave this codepen example. However, it can be made to be less code to do a pseudo-element. Assuming .iconleft is a class used to put the icon left rather than right, and .iconit the class that sets an icon at all, then the following code concisely makes it happen for CSS3 browsers using the :not() selector (here is the fiddle, using the original .pseudo class of the OP for iconing):
.iconit:not(.iconleft):after,
.iconit.iconleft:before {
content: url('http://www.jasonapollovoss.com/web/wp-content/uploads/2010/09/pdf_icon_small.png');
vertical-align: sub;
}
The same could be done with CSS2 browsers if an iconright class is used to explicitly set an icon to the right, or iconleft to the left (no iconit class needed then):
.iconright:after,
.iconleft:before {
content: url('http://www.jasonapollovoss.com/web/wp-content/uploads/2010/09/pdf_icon_small.png');
vertical-align: sub;
}
What makes pseudo-classes so useful is that they allow you to style content dynamically. In the example above, we are able to describe how links are styled when the user interacts with them. As we’ll see, the new pseudo-classes allow us to dynamically style content based on its position in the document or its state
Read more http://coding.smashingmagazine.com/2011/03/30/how-to-use-css3-pseudo-classes/
It seems that the community here agrees that the old "clearfix" hack has now been depreciated and superseded by overflow:hidden. Unfortunately there are situations where even using this method causes problems. (For example: This would look like this if it worked correctly.)
The main problem with using the old fashioned <div class="clear"> seems to be that it creates a div element for sole purpose of altering the presentation -- which seems to be muddying the ideal of pure semantic markup with presentation.
Other than that, though, it appears to work well with all browsers and in all situations (which cannot be said for "clearfix" or overflow:hidden).
Are there any other drawbacks to using clear:both? Is it really that bad to use? Or is it just personal preference?
It's fine. Not as nice as a pure CSS method, no, but there are times when overflow:hidden / auto just won't work well (for example, when you want an absolutely positioned element to 'pop' out of its container).
Yes, it adds a maintainability cost, and yes, it's theoretically suboptimal for SEO, but it's hardly a cardinal sin.
There are side effects
clear: both has a side effect that if there are any other floats present in the same block formatting context, the clear: both element will be forced below them. Sometimes this is what you want. Sometimes it isn't. This jsbin demonstrates a case where it will eat your lunch:
The trick is in controlling which floats a cleared element should interact with. You do this with block formatting contexts, an insulated rectangle inside of which all floats and cleared elements interact. Floats and cleared elements outside of a block formatting context cannot interact with floats or cleared elements inside.
This is one important drawback to keep in mind when using clear: both. Is it really that bad to use? No. You just have to be aware of how floats and clears interact and how to prevent them from doing so when you need to. In many situations these issues don't come up, so choosing a method for clearing floats can be a matter of personal preference. But some situations demand a deeper consideration of how floating and clearing works. Every clearing method has side effects, so you have to pick the right one for your situation. There are detailed answers at Which method of 'clearfix' is best?
clear:both simply means that there are no floats allowed to the left or right. An alternate method does exist, but it isn't safe for older browsers.
.element:after { content:""; clear:both; }
I'm pretty sure clear: is standard, floats are just tricky if you do not fully understand them (it took me a while).
The reason the white space exists is that floated elements do not actually 'exist', in the sense that they give no definitive dimensions for the container to wrap around. You can use clear:left clear:right or clear:both on an item after the float and it will create a hard line, the same as using the <div class="clear"></div> method.
Personally, I use the tried-and-true hack and add pseudo elements for when it's (hopefully) supported all around.