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
Related
The page I am working on is displaying perfectly in Chrome, Firefox, Opera and Safari (in both Mac and Windows) except in IE 7 & 8. The header is suppose to look like this:
but in IE it appears like this:
before we were using position: relative; for our class container in our charity.css file, but i had to remove that as it was creating problems in IE w/ my drop-down menus.
Can someone PLEASE help me?! I am so out of ideas now :(
Here is the [page] (however, i would have to remove the link later) Any help will be highly appreciated!!
Edited: here is the jsfiddle: http://jsfiddle.net/walahh/QwFL6/ it's not exactly the same page...but hopefully you will get the idea.
The only change I can think of would cause a somewhat significant change in your markup.
Basically, I'm pretty sure that this has to do with float:left and float:right elements not being cleared. IE is notorious for incorrectly propagating the float property to elements which weren't intended to be floated. To avoid this - when floating - it is common to do something like this...
CSS:
.fl { float: left; }
.fr { float: right; }
.clr { clear: both; }
And then doing this in your markup:
<div>
<div class="fl"></div>
<div class="fl"></div>
<div class="clr"></div><!-- This element stops float from going to unintended elements -->
</div>
This is ideally how you would position floated elements for cross browser support.
If reworking your markup isn't doable, you could try adding empty elements, with a clear: both; style, as the LAST SIBLING of floated elements. So...taking your ul#secondNav as an example you could try this...
<ul id="secondNav">
<li class="stuff"></li>
<li class="stuff"></li>
<li class="stuff"></li>
<li style="clear: both;"><!-- Leave empty --></li>
</ul>
So apparently the fix was pretty simple....i was making it way too complicated.
What I (also) didn't know was "In IE the z-index can not be higher than the contain element's z-index."
So I went back to the original file, where they had .container{width:940px; margin:0 auto; position: relative;} and left it as it is. Then added z-index values for the #header{.....; z-index:1; } and #mainNav{...; z-index:2;} And that took care of the...
hidden drop-down menu(s)
messed up header
here is the modified code: http://jsfiddle.net/walahh/QwFL6/3/
hope this helps someone :) and thank you everyone who took their time to read my post and help me.
So I started tweaking the html/css of this page. Nothing fancy as far as I can see.
Now it looks completely wrong in Firefox (see for yourself) and fine in every other browser I can think of. The html has been validated by the W3 tool. I am mystified, has anyone ever come across this before?
You just need to clear the floats. Try adding this to your stylesheet:
table.layouttbl
{
clear: both;
}
This might help too.
Try clearing the float you put on your menu.
<table cellspacing="0 " cellpadding="0" class="layouttbl" style="clear: left;">
You can put it in an actual style rule, or add another element and attach the clear to that instead.
Add overflow: hidden to .page class in Site.css (line 108)
Add a new property: .layouttbl {float: left}
This fixes your issues in firefox. Make sure to check the site in other browsers as well.
Your menu div has no need to float, remove float from that #divMenu. Be careful since you're defining #divMenu in 2 different places
I have a bunch of paragraphs on a page:
<p> ... </p>
<p> ... </p>
<p> ... </p>
The CSS rule for those paragraphs is:
p {
margin: 20px 0;
page-break-inside: avoid;
}
Live demo: http://jsfiddle.net/KE9je/2/show/
If I understand the page-break-inside property correctly, the above should ensure that no paragraph is split between two pages. (A paragraph is either displayed on the "current" page, or if it doesn't fit completely, it's moved to the next page.)
This doesn't seem to work in Chrome. Open the demo, right-click the page, choose "Print...". You'll see a print preview - the fifth paragraph is split between page 1 and 2.
What am I doing wrong? How can I make this work in Chrome?
Actually, it DOES work in Chrome, and the solution is really silly!!
Both the parent and the element onto which you want to control page-breaking must be declared as:
position: relative;
Check out this fiddle (or in fullscreen)
This is true for:
page-break-before
page-break-after
page-break-inside
However, controlling page-break-inside in Safari does not work (in 5.1.7, at least)
I hope this helps!!!
This worked best for me:
.no-page-break {
display: inline-block;
width: 100%;
page-break-inside: avoid;
}
You can also specify the height if needed.
I've been fighting with this for a while and as well as follow the advice in the other answers I had to make sure that the element and all parent elements had the styling Display: block;.
I know this is an old question but Chrome has changed since it was originally answered and this may help.
It looks like page-break-inside:avoid works in Chrome based on the height of the element, so if you are floating a bunch of elements in a div, page-break-inside:avoid will not work.
It's possible to get around this by explicitly defining the height the element you don't want broken up. jQuery example:
$('#page_break_inside_avoid_element').height($('#page_break_inside_avoid_element').height());
According to SitePoint, Chrome is not supported here, only Opera (and IE 8 buggy)...
http://reference.sitepoint.com/css/page-break-inside
Other references:
http://www.webdevout.net
http://www.reddit.com/r/css/comments/jdeim/pagebreakinside_avoid_doesnt_work/
Stack Overflow threads:
Cross-browser support of `page-break-inside: avoid;`
"page-break-inside: avoid "- does not work
Google Chrome Printing Page Breaks
Which browsers support page break manipulation using CSS and the page-break-inside element?
Google Chrome Forum:
http://www.google.com/support/forum
I will not post the W3Schools link (due to general unreliability) but they also state it's only supported in Opera, for whatever it's worth.
I recently worked on the pdf download story which was having dynamic rows of data in table format which include various charts images(tech used=>Angular + Spring + Thymleaf + Puppeteer)
Some of the key points for handling page-breaks
Try to use <div></div>blocks instead of HTML tables
Do not use display: flex on the parent container on which you want page-break-inside: avoid(use float in child element)
.child1{
float: left;
}
3.If you are rendering div in loop and page-break-inside: avoid; not working
You should use this CSS hack to work on a particular div
<div class="parent-container">
<div class="child1"></div>
<div class="child2"></div>
</div>
.parent-container{
position: relative;
page-break-inside: avoid;
}
.parent-container::after {
content: "";
display: block;
height: 200px;
margin-bottom: -200px;
}
Check if the parent container display is not inline-block!!
If so, then it will never work! I waste few hours to figure it out.
Works in Chrome 87
For Bootstrappers, be aware that page-break-inside or others may not (highly) work under container or row or other classes of bootstrap even if you change manually the position property. When I exclude container and row, it worked like a charm!
I solved it: my problem was "a" parent div (not "the" parent div) set as display: flex.
I set it to display: block and it works.
I just tested this with a larger paragraph in IE9, Chrome 14 and Firefox 7, and it looks like only IE9 works as expected. You might have to resort to adding page breaks manually where you want them with
page-break-after:always
Of course that's only any good to you if you know the content length in advance.
What worked for me (in both FFox & Chrome, that is)
.container {
column-gap: .4em;
columns: 3;
padding: .4em;
}
.contained {
page-break-before: avoid;
page-break-inside: avoid;
page-break-after: always;
}
And that's it ; I didn't need position.
check if the parent(or top level container) display is flex ; remove it and try again；
it works for me in chrome71
Here is how I solved this while writing a css for printing.
For example, you put some pictures in an HTML file like this:
<div class="bottom">
<figure>
<img src="img01.jpg" alt="Front View">
<figcaption>Front View</figcaption>
</figure>
<figure>
<img src="img02.jpg" alt="Rear View">
<figcaption>Rear View</figcaption>
</figure>
</div>
And write the css like this:
.bottom figure{
page-break-inside: avoid;
}
Sometimes it won’t work as you expect, because the default value of display for most elements is block or inline, which is not ‘page-break friendly’. I usually change it like this:
.bottom{
display: contents;
}
This aims to disappear the container, making the child elements children of the element the next level up in the DOM.
As for your question, I suggest you to have a look at the display mode of the container of the paragraph to see whether it is set to block. If so, change it to contents and try again.
I hope this help.
After a huge digging, it seems to be a very silly, annoying and simple issue.
The key to fixing this issue is:
First, let's define what's parent and child.
Child: It's the element that we need to prevent/avoid cutting through in-between pdf pages
Parent: It's the direct parent/container of the child
Now we have the parent and the child very obvious, the next step is to give both parent and child some easy-to-implement rules. so let's do that
Parent rules
display: block;
Child rules
display: block; position: relative: page-break-inside: avoid;
That's it!
It Works for me, like this:
.print{position: absolute;}
.print p{page-break-inside: avoid}
Also page-break-inside: avoid may not work if one of parent elements has fixed height (say height: 1000px). I guess that's because browser is trying to fit content in specified height first and only then thinks about page breaking.
Changing to height: 100% fixed it for me.
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.
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;
}