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.
Related
I've scoured the internet (and Stack Overflow) searching for a solution to this simple problem, but to no avail.
The user agent stylesheet is telling me that it's being overridden by my styles, but is still applying it's own. Take a look:
Original code snippet:
Here, it shows clearly that the original display:block; is being overridden, as it should be.
,
Yet here, under the computed tab, it is still applying display:block. The container is set to display:table.
I isolated the effected elements in scratch html/css files, and there is no problems with overriding the user agent stylesheet there, as can be seen here:
.
What on earth could be causing this? Thanks in advance.
Also, !important doesn't work.
Edit: All of the screenshots decided to embed themselves overnight so it looked like a total mess, which is fun. Rather than delete this question out of embarrassment, I just cleaned that up real fast, although it's still pretty convoluted-looking but whatever.
Looking at your screenshot of the element's computed styles, I notice that its float is set to left. Floating an element tends to blockify it, and in the case of a table-row, that does indeed turn it into a block and ultimately detach it from its table container, as a table-row cannot normally be floated. This is not a case of the UA stylesheet overriding your styles, but how the display and float properties interact.
In order for a table layout to work you cannot float any of its internal table elements, including row groups, rows, and cells. (You can float the table itself.) As I am not familiar with your layout I won't be able to suggest a proper and complete answer to your question, but the key here is to remove the float declaration from that element. Since this declaration doesn't appear in your own styles it must be elsewhere — look for it among the rest of the element's styles. If necessary, override it using float: none.
(There may of course be other factors causing this blockification that as others have mentioned require a proper reproduction of your problem to diagnose, but this is what I could glean from just the screenshots you've provided and is a very common and likely cause.)
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.
While applying css I am getting the desired result without the use of the position property i.e:-
position:relative; or
position:absolute; etc...
But, I am a bit worried - is this the right way?
I mean, is applying position property for styling with css considered a good practice?
Thanks
Whether it is best to style the position property depends on your specific situation. If you have need to take elements out of the flow of the page, then you may want to use it.
But no, the position property is definitely not mandatory.
If you have styled your page without using position - and your satisfied that it is fully functional, there's nothing wrong with that.
Read about positioning to properly understand when to and why we change it from the default.
No. For the vast majority of things, position: static (the default) is fine.
Other positioning schemes should be used with a light touch. You can achieve some very powerful effects with them, but for most purposes such things are not needed, and used improperly they can create very fragile layouts.
Going by the CSS tutorial here:
http://www.w3schools.com/css/css_positioning.asp
They are good if you wish to affect the positioning of the image, for example if you need to move it slightly or position it next to another image.
more reading can be found here with examples:
http://quirksmode.org/css/css2/position.html
Personally I always position them, but I do not think it matters
Every element is static positioned by default
You cannot use z-index:property without the position property
You will not get the desired effect for z-index,if you are not specifying any of the position properties(relative,absolute,fixed)
left/right/top/bottom/z-index have no effect on a static positioned element.
NOTE:Just spend a few minutes here too position
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/
I'm working on a web app... unfortunately it has to work with the worst piece of software ever written, yes ie6.
I really like the CSS display:table and display:table-cell properties, but of course it doesn't work in ie.
Has anyone found any fixes for this? I have been looking, but haven't found anything.
Conditional CSS, .htc files, javascript...anything?
I would really like to avoid making everything with floats and clears
Sorry. There isn't a fix to make IE6 support CSS display:table. The only way to acheive this layout in IE6 is to actually use <table> elements.
First question: do you really need to support IE6? If you can simply drop support for it, you'll solve yourself a whole ton of problems, including this one. Current global usage of IE6 is below 3%, and even lower in most developed countries.
If you do still need to support IE6, then your most obvious solution is simply to swallow your semantic markup pride and just use a <table> tag.
As described by #Tom, the next best solution is to write your layout using display:inline-block;.
inline-block allows you to define your elements as blocks, but still keep them in the text flow (kinda the way the <img> tag works by default). If you combine this with fixed element widths, and wapper divs around rows, you could acheive something similar to a table, although it may be hard to get it to expand dynamically with the page width.
The one big "gotcha" bug around this is that inline-block only works in IE6/7 for elements that have a default style of display:inline. In other words, it works for a <span> but not for a <div>. Not a disaster, but something to be aware of, especially since you're specifically asking about IE6 support. Other than that, the good news is that you should be able to get away with using display:inline-block without any other hacks or work-arounds.
IE does not support display:table and display:table-cell but IE7 and below do support display:inline-block. The common way to make this work is by doing the following:
display:-moz-inline-stack;
display:inline-block;
zoom:1;
*display:inline;
Keep in mind that CSS gives you a lot of positioning power and given some context of how you want your layout to look I might be able to give you a better solution.
Due to misunderstanding let me clarify the code above.
display:-moz-inline-stack; is declared for older versions of Firefox.
zoom:1; IE has a property called hasLayout, this is a way to trigger it.
*display:inline is known as a *property hack used to hide this line from all non-IE browsers
The zoom:1 and *display:inline effectively allow block level elements to behave like inline elements (so that inline-block will work in IE6+)
For more information please read:
http://blog.mozilla.com/webdev/2009/02/20/cross-browser-inline-block/
http://foohack.com/2007/11/cross-browser-support-for-inline-block-styling/