SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 70 of 70
  1. #51
    Design Your Site Team bronze trophy Erik J's Avatar
    Join Date
    May 2007
    Location
    Countryside, Sweden
    Posts
    3,407
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    Erik it's the overflow:hidden on #wrapper that is affecting opera for some reason. If you use the old clearfix it seems to work ok.
    Thanks!!! I was loosing track all the time.

    Quote Originally Posted by Kravvitz View Post
    By the way, there are overflow issues in FF1.0-2.0 in the max- and min-width combos (in both Paul's and Erik J's versions; the exact issue is different in each version though).
    Maybe the revised version has no issues?

    HTML Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>CSS Max/Min-width in IE6 on a Fluid Page with a Sticky Footer</title>
    <meta name="generator" content="PSPad editor, www.pspad.com">
    <style type="text/css">
    html{
    	overflow-y:scroll; /* ALL; add an empty scrollbar */
    }
    html,
    body{
    	margin:0;
    	padding:0;
    	height:100&#37;;
    	font-size:100%;
    }
    body:before { /* Opera; resized min-height trigger */
    	float:left;
    	margin-top:-30000px;
    	height:100%;
    	content:"";
    }
    h1, p{
    	margin:10px;
    	text-align:justify;
    	font-size:100%;
    }
    #wrapper{
    	z-index:2;
    	position:relative;
    	margin:auto;
    	width:80%;
    	min-width:600px;
    	max-width:60em;
    	min-height:100%;
    	text-align:left;
    }
    * html #wrapper{
    	height:100%; /* IE6; content will grow the height */
    }
    #header{
    	height:80px;
    	background:#f99;
    	overflow:hidden; /* avoid margin collapse */
    }
    * html #sidebar{
    	margin-right:-3px; /* IE6; the three pixel jog */
    }
    #sidebar{
    	float:left;
    	width:150px;
    }
    #content{
    	overflow:hidden; /* clear adjacent float */
    }
    * html #content{
    	display:inline-block; /* IE6; trip hasLayout */
    	overflow:visible; /* IE6; the italic bug */
    }
    #clearfooter{
    	clear:both;
    	padding-bottom:50px;
    	height:0.01%; /* IE8; resized min-height trigger */
    	font-size:0;
    }
    #footer{
    	z-index:1;
    	position:relative;
    	margin:-50px auto 0;
    	padding:1px 0; /* avoid margin collapse */
    	width:80%;
    	min-width:600px;
    	max-width:60em;
    	height:48px;
    }
    
    
    /* fake column backgrounds and page borders */
    #page-bg{
    	float:left;
    	z-index:-1;
    	position:relative; /* Opera; extended scroll if AP */
    	bottom:-49px;
    	margin:-9999px -10px 0;
    	border:solid #ccc;
    	border-width:0 10px;
    	width:100%;
    	height:9999px;
    	background:#fcc;
    }
    #sidebar-bg{
    	float:left;
    	margin-top:-50px;
    	width:150px;
    	height:100%;
    	background:#f66;
    }
    #footer-bg{
    	clear:left;
    	height:50px;
    	background:#f99;
    }
    
    
    /* IE6 extra style for the max-width and min-width */
    * html .max-width-left{
    	float:left;
    	margin-right:-30em; /* give space for half the max-width */
    	display:inline;
    	width:50%; /* what is left acts like a max-width buffer */
    }
    * html .max-width-right{
    	float:right;
    	display:inline;
    	margin-left:-30em; /* give space for half the max-width */
    	width:50%; /* what is left acts like a max-width buffer */
    }
    * html .min-width-set{
    	float:left;
    	display:inline;
    	position:relative; /* keep the positioned child in stacking context (bugfix) */
    	margin-left:600px; /* set the min-width buffer */
    }
    * html .min-width-use{
    	display:inline-block; /* for hasLayout, float would shrinkwrap the content */
    	position:relative; /* makes IE6 show the negative margin part (bugfix) */
    	margin-left:-600px; /* use the min-width buffer */
    }
    </style>
    </head><body>
    
    <div id="wrapper">
    <!--[if lte IE 6]>
    <div class="max-width-left"></div>
    <div class="max-width-right"></div>
    <div class="min-width-set">
    <div class="min-width-use">
    <![endif]-->
    	<div id="header"><p>Header</p></div>
    	<div id="sidebar"><p>Sidebar</p></div>
    	<div id="content">
    		<h1>In this page IE6 is served extra CSS and HTML <em>but no javascript</em>. It is a centered 80% fluid width page with 60em max-width and 600px min-width. It has a sticky footer and two fake column backgrounds.</h1>
    		<p><img style="float:left; margin-right:10px; background:red;" src="" width="150" height="150"></p>
    		<p><img style="float:right; margin-left:10px; background:red;" src="" width="150" height="150"></p>
    		<p>Lorem ipsum dolor sit amet consectetuer tempus justo ornare nec interdum. Tellus Sed nulla quis Nunc adipiscing laoreet ac sociis laoreet mauris. Sem id pellentesque tellus. Cursus augue vel id consequat sem justo Sed interdum ligula ut. Molestie egestas rutrum pede.</p>
    		<p>Consectetuer Mauris justo leo suscipit pharetra adipiscing et id orci tortor. Wisi velit dolor ultrices iaculis pulvinar. Platea mollis adipiscing quis in lacinia Vestibulum molestie sem sagittis id. Nibh Nam pede gravida magnis purus. Pretium nec ac eu et id id mollis Sed et elit.</p>
    		<p>Rhoncus neque aliquam dolor id et natoque porttitor pellentesque sollicitudin enim. Dictumst turpis et sed. Tincidunt consectetuer massa mauris ut. Consectetuer Mauris justo leo suscipit pharetra adipiscing et id orci tortor. Wisi velit dolor ultrices iaculis pulvinar. </p>
    		<p>Bottom line</p>
    	</div>
    	<div id="clearfooter"></div>
    <!--[if lte IE 6]>
    </div></div>
    <![endif]-->
    </div>
    
    <div id="footer">
    <!--[if lte IE 6]>
    <div class="max-width-left"></div>
    <div class="max-width-right"></div>
    <div class="min-width-set">
    <div class="min-width-use">
    <![endif]-->
    	<div id="page-bg">
    		<div id="sidebar-bg"></div>
    		<div id="footer-bg"></div>
    	</div>
    	<p>Footer</p>
    <!--[if lte IE 6]>
    </div></div>
    <![endif]-->
    </div>
    
    </body></html>
    Happy ADD/ADHD with Asperger's

  2. #52
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Kravvitz
    By the way, there are overflow issues in FF1.0-2.0 i
    Hi Kravvitz, haven't seen you around for a while

    Thanks for the info

    I didn't actually check less than FF3 but I do now remember firefox always having an issue with overflow on earlier versions. If I can find my old copy of Firefox Ill take a look

  3. #53
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by erik
    Thanks!!! I was loosing track all the time.
    It also seems to be an issue on the new sticky footer code also if you add overflow:hidden to the main container (the demo doesn't use it anyway so it's not an issue but it would have an effect if someone adds it in). Opera is very inconsistent (where's Simon ).

  4. #54
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by erik
    Maybe the revised version has no issues?
    That seems to be working in FF2 now Erik (I changed mine also)

  5. #55
    Design Your Site Team bronze trophy Erik J's Avatar
    Join Date
    May 2007
    Location
    Countryside, Sweden
    Posts
    3,407
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the info Paul, I've still not got all test browsers up and running.
    Happy ADD/ADHD with Asperger's

  6. #56
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Great to see so many successful attempts! This was another fun quiz.

    Quote Originally Posted by Paul O'B View Post
    We create 2 floats of 50&#37; width that stretch all the way across the containing block (or viewport in our case)… we use a negative margin on each float to create some negative space.

    Some of the above entries used the negative margin on the reverse side of the float to the way that my original was created resulting in a horizontal scrollbar appearing on the right side of the browser hence the need for extra code to hide this in certain browsers.
    Yep, I did it that other way too, and indeed you do have to put overflow:hidden on the container. (This is not a problem for IE6, however, since you have to do something special to get anything to overflow the hasLayout inner content box in the first place, and you could give that overflowing content position:relative which "beats" overflow:hidden on an ancestor anyway. And if for some reason you wanted to use this technique for other browsers instead of real max-width, you already have to put non-'visible' overflow on the inner content box.)

    It didn't occur to me to do it Paul's way. With the other way, the floats disappear outside of the containing block when you narrow the browser, ensuring that they can't possibly interfere with the context at widths less than the desired max-width. In Paul's way, the floats move in the opposite direction and visually overlap each other, but the negative margins ensure that they don't interfere with each other. (With that method, at widths less than the desired max-width, there's a bug in IE6 with how the floats are rendered, which you can see if you give them a background colour and a large height. Seemingly it's only thanks to /another/ bug that this doesn't cause the technique to fail in IE6.) Also, at narrow widths, float drop occurs (whereas it doesn't with the other method), but it's not a serious problem because you have to go /really/ narrow before it happens.
    I have set the float to only 1px high which means that when the page is squashed the float drop is only 1px.
    With either method it's important that the margin-box height of the floats is made as small as possible, else they might potentially interfere with other things on the page. (Actually, setting them to 1px high doesn't actually "work" properly, since IE6 will automatically increase the height of an empty hasLayout box to be the height of a line box, usually around 1.2em. To be on the safe side, you can use a padding-top of 1px, an explicit height of 1.2em and a margin-bottom of -1.2em, which really does give a 1px-high margin box.)

    Both techniques are essentially the same. I do think this is the only way to achieve this without using tables. Actually, I only noticed RyanReese's post just now; his table method is pretty cool for IE6! (You could use conditional comments to hide the TABLE tags from other browsers and then use the display:table equivalent for good browsers, but be wary of this though; it's not completely clear to me whether that max-width behaviour is specified in the sample table-shrink algorithm in the CSS21 spec, and anyway the table-shrink behaviour is actually optional in CSS21.)

    All we need do now is create another container that sits between these 2 floats (which it will do automatically) and to stop the text wrapping under the floats we use overflow other than visible which makes the element form a rectangular block that won't allow its content to wrap under the float. For IE6 we merely need to induce haslayout to create the same effect.
    Indeed, this is the minor difference between IE6/7 and CSS21 browsers. In CSS21 browsers we need the inner content box to be a block formatting context. Block formatting contexts arise from various properties, of which the only usable and sensible one for our purposes is non-'visible' overflow (eg overflow:auto). The CSS21 spec doesn't say very much about the interaction between block formatting contexts and floats, apart from a deliberately vague sentence about how browsers are permitted to make them narrower if desired so that they fit next to floats. Hence, although this technique works in all current browsers, it might be unwise to rely on it; I recommend using real 'max-width' for IE7 and good browsers!

    [hasLayout is the IE6/7 sort-of-equivalent of block formatting contexts. Ironically, non-'visible' overflow doesn't cause hasLayout in IE6 (though it does in IE7) so we can't use the same property to get the desired effect in all browsers. Instead, as usual, zoom:1 or similar rules do the job for IE6.]

    (I am ignoring the 3px difference that the 3px jog will apply to this element).
    In fact, the 3px jog bug doesn't seem to arise in your "floats overlap" method, apart from when the browser width is between 0px and 6px wider than the max-width. It does affect the other "floats outside" method, but it is fixable by putting side margins of -3px on the floats for IE6, apart from in this same 6px region.


    If we give the element a margin:0 10% then effectively we are giving it an 80% width. So we have almost a full implementation of max-width (within reason).
    Hah! This is very nice! Whilst I thought about using side margins on the inner content box, it didn't occur to me to do it using percentages and thus making the resulting width meaningful. (I don't use percentages much.) So let me correct my earlier statement : *Apart from percentage widths*, I strongly believe that there is no way to mimic a combination of 'width' and 'max-width' in IE6 using only HTML and CSS . (For example, I can't see a usable way of using the container to restrict the width of the inner content box, since it interferes with what happens after the max-width is reached.) Of course, the use of margins in this percentage technique will cause more work or problems if other parts of the layout want to legitimately occupy that margin space.


    Finally, as some of the solutions demonstrate, it's easy to combine the max-width technique with the min-width technique. I noted that, with the "floats outside" max-width method, the 3px jog bug causes a small miscalculation of the left edge of the inner content box when using the margin variant of the min-width technique, but not with the border variant. I didn't try other combinations, but the "floats overlap" max-width seems to behave better than the "floats outside" max-width as regards this bug.

  7. #57
    CSS & JS/DOM Adept bronze trophy
    Join Date
    Mar 2005
    Location
    USA
    Posts
    5,482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Erik J
    Maybe the revised version has no issues?
    I was talking about the version without the sticky footer. The ones with the sticky footer seem not to have the bug.
    We miss you, Dan Schulz.
    Learn CSS. | X/HTML Validator | CSS validator
    Dynamic Site Solutions
    Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.

  8. #58
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Thanks for your comments Anton and as usual they are very thorough and interesting.

    I would take one small issue with your comment about overflow though especially because it's a technique I have been using and advocating for years and according to my research is exactly as intended.

    Quote Originally Posted by Anton
    The CSS21 spec doesn't say very much about the interaction between block formatting contexts and floats, apart from a deliberately vague sentence about how browsers are permitted to make them narrower if desired so that they fit next to floats. Hence, although this technique works in all current browsers, it might be unwise to rely on it; I recommend using real 'max-width' for IE7 and good browsers!
    The specs do actually go on to clarify this point and the following statement from the specs do confirm it.
    Quote Originally Posted by w3c
    an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space.
    This is the basis I use in many sites for catering for column layouts that have dynamic conent in one column and the resulting column needs to fill the space but keeping a rectangular block.

    e.g.
    http://www.pmob.co.uk/temp/3col-overflow-toggle.htm

    I have used this technique many times now and it has proved to be robust and extremely useful.

    Of course if you need overlow to be visible then another approach is needed.

    (As an aside I have spent a lot of time studying overflow and its effects on different browsers ever since I invented the technique for clearing floats and although at the time a lot of people dismissed it as a buggy behaviour it has now become almost the de facto method for clearing floats and again it is behaving as the specs say it should.)

    Regarding the basic max-width solution although I said it works in all browsers I would agree with you and say only use it for ie6 in real life and let good browsers have the proper min and max width properties.

    Thanks for your comments and glad you enjoyed the quiz

    As mentioned by Raffles earlier in the quiz we should have started these 10 years ago and then we'd all be very famous

  9. #59
    Hibernator YuriKolovsky's Avatar
    Join Date
    Nov 2007
    Location
    Malaga, Spain
    Posts
    1,072
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    you did start them in 2004 paul, its just that we weren't around back then.

  10. #60
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by YuriKolovsky View Post
    you did start them in 2004 paul, its just that we weren't around back then.
    lol - doesn't time fly when you're having fun

  11. #61
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,782
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Interesting solutions-never woulda thought of that..
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  12. #62
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    Quote Originally Posted by Anton P View Post
    The CSS21 spec doesn't say very much about the interaction between block formatting contexts and floats, apart from a deliberately vague sentence about how browsers are permitted to make them narrower if desired so that they fit next to floats. Hence, although this technique works in all current browsers, it might be unwise to rely on it; I recommend using real 'max-width' for IE7 and good browsers!
    The specs do actually go on to clarify this point and the following statement from the specs do confirm it.
    Quote Originally Posted by w3c
    an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space.
    That was the sentence I was referring to . The terms "may" and "if there is sufficient space" have been deliberately left vague and undefined. In fact the latest draft of the spec is even clearer:
    Quote Originally Posted by w3c
    CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower.
    Bert Bos (co-editor of the spec) has stated in the past that the narrowing of block formatting contexts (in ways which violate the usual method of determining the content area width) was originally introduced to allow tables to be inserted next to floats instead of underneath them, since browsers were already implementing this and authors apparently demanded it. This permissive behaviour was then implemented by browsers for most if not all block formatting contexts, and so it ended up in the spec. However, neither spec editors nor browser implementors seem to express much happiness with this behaviour; yet it cannot be dropped completely, because too many pages would break. The consensus appears to be that it will not be defined further in CSS21.

    Quote Originally Posted by Paul O'B
    This is the basis I use in many sites for catering for column layouts that have dynamic conent in one column and the resulting column needs to fill the space but keeping a rectangular block.
    For sure. When building grid-like layouts by exploiting CSS21 behaviour, overflow:auto is the only usable and sensible technique for "expand to fit" columns.
    it's a technique I have been using and advocating for years and according to my research is exactly as intended.
    Oh it certainly works in some older and all current major browsers in the basic situations.(*) And that's lucky for us, because it really is the best method for flexible-width "columns" in CSS21! But no browser is obliged to permit that behaviour. (Not that any mainstream browser could realistically avoid it, for the same reason of page-breakage.) Of more concern, perhaps, is what browsers will do in the future when CSS3 layout techniques are commonplace; they'd be well within their right to drop the behaviour then. I too advocate this method, but with a health warning: it's safe at the moment, but carries a small element of risk. (<bitter laugh>Oh for the day when IE6, 7 and 8 die and we can start using CSS3 layout at will! Shame we'll probably be dead ourselves by then</bitter laugh> )

    Of course if you need overlow to be visible then another approach is needed.
    Trouble is, you often need overflow to be visible! . This is particularly true of narrow columns when a user might increase the text size in their browser, or even of wider columns if they contain long URLs with no suitable breaking points (or languages such as German with very long words, in the current environment in which browsers don't have any native word-breaking heuristics). Given that the only suitable inducer of block formatting contexts is non-'visible' overflow, I would certainly say that overflow:auto should be used in place of overflow:hidden, because overflow will at least be reachable at the cost of an ugly scrollbar. But even then I advocate this technique only because there's no other way!

    (As an aside I have spent a lot of time studying overflow and its effects on different browsers ever since I invented the technique for clearing floats and although at the time a lot of people dismissed it as a buggy behaviour it has now become almost the de facto method for clearing floats and again it is behaving as the specs say it should.)
    If I recall correctly, the use of specific CSS properties (overflow, float, absolute positioning etc) to induce block formatting contexts, and their accompanying narrowing next to floats, was introduced in the spec some time in the early 2000s, with the float-clearing behaviour following a year later as one of their characteristics. No doubt the spec was written to reflect the most widespread browser behaviour at that time, although I can certainly imagine it might not have been ubiquitous.

    I would respectfully disagree and say that the easyclearing method popularised by PositionIsEverything in 2004 is probably the de facto method of float-enclosing. It's also the "correct" method in CSS21. (There may well be a dedicated property for this in CSS3.) Whilst creating a block formatting context will certainly also work to enclose floats, it's overkill: aside from float-enclosing, you also get the three other defining behaviours of block formatting contexts: margin collapsing is inhibited, overlap with floats is prevented, and scope for 'clear' is provided. These may be desirable... but may not be, especially the inhibition of margin collapsing.

    (Also, from an educational point of view, I feel that the use of overflow in particular is a bit iffy, because I can imagine many authors believing that it works because the float is "overflowing" the container and so by specifying the "overflow" property it can be avoided, which would be a rather grave misunderstanding. Some of my own developers would probably be guilty of this,*sigh* )


    (*) IE8 overlaps block formatting contexts and floats in right-to-left text direction in some situations (as I discovered from test cases which I created a few months ago as supporting evidence for an appeal for more explicit specification of "block formatting contexts next to floats" behaviour, as it happens!)

    Still, can't complain: IE8 certainly surpassed my expectations. I barely even check sites in it any more! Who'd have believed that we'd be saying that about an IE?!

  13. #63
    Resident curmudgeon bronze trophy gary.turner's Avatar
    Join Date
    Jan 2009
    Location
    Dallas
    Posts
    990
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Anton P
    Given that the only suitable inducer of block formatting contexts is non-'visible' overflow, I would certainly say that overflow:auto should be used in place of overflow:hidden, because overflow will at least be reachable at the cost of an ugly scrollbar. But even then I advocate this technique only because there's no other way!
    That's not quite true. There are several means of setting a new block formatting context besides using overflow hidden||auto. The display property offers table, inline-table, table-cell, and inline-block; all creating a new block formatting context.

    As with any non-trivial property, there are gotchas, but they're different for each method.

    cheers,

    gary
    Anyone can build a usable website. It takes a graphic
    designer to make it slow, confusing, and painful to use.

    Simple minded html & css demos and tutorials

  14. #64
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Anton
    I would respectfully disagree and say that the easyclearing method popularised by PositionIsEverything in 2004 is probably the de facto method of float-enclosing.
    I would have to disagree as I rarely see it in the forums these days and overflow:hidden is the most widely used in all the code I look at these days (not many people have looked at 26,000 sites lol). Overflow also has the added benefit of curing IE's dreaded float drop in many cases which is a big issue with floated columns.

    I do agree and as I said before if you want content to be visible or as you point out expect to have long words or unbroken urls then another approach is needed. In fixed width sites with static controllable content then overflow is a valuable and useful tool.

    The pie clearfix is not perfect either has some side affects and can introduce extra space at the bottom of a page (which is why I avoid it in my 100&#37; layouts) and will of course cause an element to clear any floated columns to its side should the author be caught unaware.

    I've never been fond of the pie clearfix method even though I have used it a lot but I don't see much of a need to use it these days although its useful for when overflow is not suitable. It was certainly a clever invention and deserves its recognition though.

    Suzy (Claire cambell) makes similar points to mine in this post (and she makes them a lot better than me) when clearing was discussed in a thread a while back.

    Of course in the end everyone can make their own choice as CSS is never black or white and there is always a cavaet somewhere.

    I too advocate this method, but with a health warning: it's safe at the moment, but carries a small element of risk.
    lol I agree - nothing is ever 100% safe and I still remember when firefox changed its behaviour with how the clear property (FF1.5 iirc) was working and immediately broke many thousands on sites. This was especially embarrassing for standards compliant authors who mistakenly took Firefox's original behaviour to be the correct one.

    I believe that if a property is working as the specs define it (even if the specs are a little vague) and that it is working as expected in all the major browsers then it's pretty safe to assume that this will continue to be the case.

    The specs could change anyway so you are never 100% safe (take negative z-index for example which was redefined in css2.1).

    You may some good and interesting points and I agree with most of them but on some we'll just have to agree to disagree

  15. #65
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by gary.turner View Post
    Quote Originally Posted by Anton P View Post
    Given that the only suitable inducer of block formatting contexts is non-'visible' overflow, I would certainly say that overflow:auto should be used in place of overflow:hidden, because overflow will at least be reachable at the cost of an ugly scrollbar. But even then I advocate this technique only because there's no other way!
    That's not quite true. There are several means of setting a new block formatting context besides using overflow hidden||auto. The display property offers table, inline-table, table-cell, and inline-block; all creating a new block formatting context.
    The operative word was "suitable". The values 'table', 'inline-table' and 'table-cell' are very specialised display types whose behaviour is still only very loosely defined; it remains to be seen whether progress will be made there before CSS21 reaches Recommendation. I certainly wouldn't advocate using them in situations other than the ones for which they were intended. To be sure, there are significant inconsistencies between current browsers in all but the most simple of cases.

    (In fact, 'table-caption' also induces a block formatting context, but is equally problematic. Also, pedantically speaking, it's not the element which has display:table or display:inline-table which forms the BFC, but rather the anonymous block which contains it. The spec is still very much unfinalized at this level of detail, however.)

    As for display:inline-block, if 'width' is 'auto' then it has the same shrink-to-fit behaviour as for floats, which means it is not necessarily functional as a replacement for the width-neutral non-'visible' overflow as a layout unit. (Also, it behaves externally like an inline element, which isn't ideal for something which should ideally behave like a block and so that could be problematic.) Finally, inline-block has only recently be usable cross-browser (since the death of Firefox 2 this summer) and so it is only now being subject to real scrutiny. The spec is certain to change slightly as regards this behaviour before it reaches Recommendation.

    But I would agree that display:inline-block is the most promising candidate, at least in some situations, for replacing 'overflow'. It's something to keep an eye on in the final pre-CSS3 era. I'd definitely want to wait a while for the spec to bed down a bit before relying on it as a mission-critical layout unit though!


    (Love your signature, btw! )

  16. #66
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Paul O'B View Post
    I rarely see it in the forums these days and overflow:hidden is the most widely used in all the code I look at these days (not many people have looked at 26,000 sites lol).
    That makes me sad, but I'll certainly defer to you there (I still see an easyclearing majority, but from a far smaller sample size and a more specialized demographic.)

    Overflow also has the added benefit of curing IE's dreaded float drop in many cases which is a big issue with floated columns.
    Yes, that's certainly a welcome side-effect!

    The pie clearfix is not perfect either has some side affects and can introduce extra space at the bottom of a page
    That is indeed a peculiar feature (which only affects Firefox IIRC? I never did figure out what Fx thinks it's doing there. It only seems to happen at the bottom of the page, though, when the clearfix is applied to the outer container.)

    and will of course cause an element to clear any floated columns to its side should the author be caught unaware.
    Certainly; but then again one's columns should all be separate block formatting contexts, else this is the least of one's worries since a typographically-used 'clear' will also suffer from this problem. (Unfortunately it's often the case that a technique carries the blame for an architectural error made elsewhere.)

    Suzy (Claire cambell) makes similar points to mine in this post (and she makes them a lot better than me) when clearing was discussed in a thread a while back.
    I confess to being unconvinced. (No substantive argument was actually given for rejecting :after, which is doing exactly what it /should/ be doing, namely placing generated content after the last child and then applying clear to it, in an exact CSS analogue of the old "clearing div" markup technique.) The impression I get from that thread is that the root problem is simply this: that many people struggle with the clearfix technique because they don't really understand why it works (which is not entirely surprising since the examples discussed involve a lot of cruft for browsers which no longer need supporting; in its modern form it contains no cruft).

    Of course in the end everyone can make their own choice as CSS is never black or white and there is always a cavaet somewhere.
    Absolutely, I'm in 100% agreement I find myself repeating that exact phrase on a daily basis around the office!

    I believe that if a property is working as the specs define it (even if the specs are a little vague) and that it is working as expected in all the major browsers then it's pretty safe to assume that this will continue to be the case.
    (Yet clearfix has far more right to claim to be working as the specs define it than reliance on the narrowing of block formatting contexts does .)

    I agree with most of them but on some we'll just have to agree to disagree
    I completely agree . I don't think I'm going to convert you!

  17. #67
    SitePoint Enthusiast
    Join Date
    Jan 2009
    Posts
    42
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Correction:
    Quote Originally Posted by Anton P View Post
    Quote Originally Posted by Paul O'B
    I believe that if a property is working as the specs define it (even if the specs are a little vague) and that it is working as expected in all the major browsers then it's pretty safe to assume that this will continue to be the case.
    (Yet clearfix has far more right to claim to be working as the specs define it than reliance on the narrowing of block formatting contexts does .)
    Apologies, I momentarily mixed up the two topics of conversation ("columns" and float-enclosing). We were discussing float-enclosing; yes, the float-enclosing behaviour of block formatting contexts works completely as specified, and there is no vagueness. This part of the spec is very stable and will not change in CSS21.

  18. #68
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,556
    Mentioned
    183 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Anton
    I completely agree . I don't think I'm going to convert you!
    lol - I don't know you may well convert me yet as you put forward some strong arguments

  19. #69
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,287
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Paul
    I've never been fond of the pie clearfix method even though I have used it a lot but I don't see much of a need to use it these days although its useful for when overflow is not suitable. It was certainly a clever invention and deserves its recognition though.
    I pretty much only use Tony's clearfix when I can't reasonably use overflow, but depending on what I'm doing on a page, I can run into plenty of instances where I can't use overflow (esp on 100% height pages!).

    My problem with clearfix is the constant need to add extra bs code just to make IE do what it's supposed to. Not a problem if the box already has layout... but I don't care for the extra 30 lines of code some versions of the clearfix have. Bleh. (of course this is gone if you simply refuse to add the IE-Mac junk, though what's funny is you see the IE/Mac junk on pages who don't otherwise have code for IE/Mac)

    For Firefox I've been using this (I guess the space didn't work on earlier browsers? But it seems to work fine nowadays):
    content: " ";
    display block and clear and all that
    height: 0; (or font-size: 0 but I haven't been using it)

    If I can simply add "overflow: hidden" to enclose floats I'll use that every time over a convoluted :after setup simply because it's less code every time. While overflow seems to simply take advantage of a rule in the specs (that containers who need to deal with overflow simply must know how large their children are, even floated ones, and thus then enclose them), the :after hack feels more... hackish to me (invent non-existant content simply to have somebody to clear a float for visual purposes). As usual, this is just my feelings as a codemonkey.

  20. #70


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •