+The set-up: So you want to have a static container box in the normal flow, +and in it you want to place an absolutely positioned element. It's understood that this +element will calculate its position based on its +nearest positioned ancestor, +thus the container is given 'position: relative' to keep it in the flow, yet serve as a positioned holder +for the absolutely positioned contents. +
++The demo: +
+ ++This box (".container1", green border) has been given 'position: relative', making it a +positioned container for the +absolute boxes. (red and blue borders) It is dimensioned horizontally by margins and +vertically by content. It does not have 'width' and 'height'. +The corner boxes are given 'position: absolute', +and placed in the corners by using the value '0' on 'top', 'bottom', 'left', and 'right', as needed +for each element. Example: +
+
+div.lowerleft {
+ left: 0;
+ bottom: 0;
+ border: 6px solid #00f;
+}
+
+
+
+Behaviors:
+Current IE and Opera 6 have some weird problems.
+(so what else is new?) Most older browsers are scary as heck.
+
+Moz/Gecko: Appears flawless. Open Source rocks! +
++Opera 7: Also flawless. Mozilla has a real competitor. +
++Konqueror 3.3: Another browser gets it right. +
++IE5.5/Win: +The upper left box (red) correctly touches the left green border, but overlaps the upper green border. +the upper right box is the same vertically; however, it completely ignores the right green border, moving +to the right viewport edge. The lower right box also moves all the way to the right, and both lower boxes +(blue) ignore the bottom green border. You will find them way down, alongside this text. +
++IE6/Win: +The blue boxes are strangely missing. But, as Lon Kraemer +points out, they can be located way down the page if the page is reloaded after the browser +cache is emptied. The exact vertical position depends on the 'text size' setting (boxes are lower +with larger settings), and window size, which is even more variant. (this is a better browser?) +
+
+IE5.x/Mac:
+The blue boxes end up sitting on top of the red boxes!
+It appears this browser thinks that the green bordered container box has a height of 0px,
+as far as positioning is concerned.
+At least that would explain the placement of the red and blue boxes.
+
+Op6/Win: +Like IE, Op6 ignores the bottom green border, but does honor the right border. In addition, +that browser displays a positioning bug unique to Op6, which is detailed in +Going Absolutely Buggy. +
++Various others: +You have to see it to believe it. +
++Quick quiz: Can you guess why IE and Op6 (Windows) place the blue +boxes where they are, vertically? See below for answer. (I've always wanted to do this) +
++Fixes: +The IE/Win bug may be squelched by defining any width or height (any units) for the container box. +Note: A width will also cure the 1px rounding error gaps seen (at some screen sizes) +between the small boxes and the right/bottom green borders. See a similar +Mozilla bug. +
+ ++Update July 2, 2008: +The width/height fix actually confers "hasLayout" on boxes in IE, but now there's a +better way to do it. +
+ ++The IE/Mac bug needs a height applied to the relative container or it treats the container as 0px high +when placing the lower boxes. Thanks, Philippe! +
++To fix Op6/Win, a height value must be applied to the container. A width will not cure this Opera bug. +As for other browsers, you're on your own. +
+ ++Live demo, with Zoom Fix applied: +
+ ++Answer to quiz: +when vertically positioning those lower blue boxes, IE5.5 and Op6 treat the container as if it +had a 'height' value of '100%'. In those browsers this is equal to the height of the viewport. +To prove it, scroll until the top green border just touches the top viewport edge, and yes indeed, +the blue boxes just touch the bottom of the viewport! +
++You may notice 1px gaps between the corner boxes and the border of the container. These are +instances of the 1px Rounding Error, which +is found in all browsers under certain circumstances. +
++Screenshots thanks to Rob Stevenson, +Lon Kraemer, Jeroen Van Gorkum, +Philippe Wittenbergh, +Casper Gielen, +and Damelon Kimbrough of the +css-discuss list. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 2, 2008
+Created July 1, 2002
+
I've provided advanced CSS consulting for
+Milo 
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ ++These articles cover a varety of CSS topics and other related issues. +Some are written by Guest Authors, and others were written by John Gallant, Holly Bergevin, occasionally for +publication at +Communitymx.com. +The CMX partner agreement prevents us from publishing them +here, so those articles are linked from this page. +
+ ++Community MX is a subscription site with a mix of free and for-pay articles, but +it is not necessary to subscribe in order to read all these articles. +
+ ++That's right, CMX offers a +free 10 day trial, +during which time you may read all of the +CMX published articles without paying a cent, and no strings +attached. But beware! CMX has been known to be +extremely habit forming! It is entirely possible that you will find yourself +unable to live without CMX, once you see all it has to offer +a web developer. We're sneaky that way. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: June 21, 2009
+Created July 3, 2004
+
+ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++In 7 seconds you will be redirected to the PIE articles page, +Where you may follow the new link. If redirect fails, click here. +
+ +
+Return to p.i.e.
+Return to Articles
+
+
+A Guest Article by Hiroki Chalfant +
+ +The Star-HTML hack +was a very elegant way to easily target style rules at IE and apply fixes. +Internet Explorer 7 has +fixed the Star-HTML hack, +taking away the elegance. This article introduces a simple method for targeting +CSS rules at IE that uses only one stylesheet and works for all versions +of IE. It will require some minimal markup using Internet Explorer's +conditional comments +and CSS descendant selectors.
+ +Here is a quick example. The css-controlled boxes below have detected whether your browser is IE/Win or not, using only conditional comments and a single CSS +file. That file uses only clean rules with no strange complications in the selectors:
+ +This browser is
IE/Win
This browser is
not IE/Win
+A wrapper may be made to enclose the content of a page, and then you can write +descendant CSS rules that mention that wrapper's ID or class name in the selector. +But what if only IE thought that wrapper existed? Then those rules would only work for IE, +while other browsers would ignore the rules completely. +
+ ++This is more or less how it was with the Star-HTML hack, where a mysterious +wrapper seemed to be surrounding the HTML element in IE browsers. This made +possible a very clean and easy selector construction: * html #myelement {}. +Now this trick is different because IE7 has lost the mystery wrapper and will not +read that selector as IE6 does. What we need is a way to make a new wrapper +to use that only IE can see. But how can this be done? +It so happens that you can use Conditional Comments +to make IE think there is a wrapper between the body and the entire page contents. +IE's view of the page element hierarchy will become different from all non-IE browsers, +letting us write CSS to take advantage of the difference. The code is not very difficult, but the +syntax is a bit different and must be correct for the method to work. +
+ ++Conditional Comments +behave just like simple HTML comments, but they have a specific syntax that IE/Win +browsers can recognize. When that syntax is exactly correct, IE/Win browsers +will look inside the comment and parse whatever is inside. +
+ +The starting tag for the new wrapper will go directly after the body start tag, +and the wrapper's end tag is placed directly preceding the body's end tag. +Each of these div tags will be wrapped in a conditional comment, allowing only +IE/Win browsers to parse those div tags.
+ +<!DOCTYPE your favorite doc type>
+<html>
+
+<head>...</head>
+
+ <body>
+
+ <!--[if IE]>
+ <div id="IEroot">
+ <![endif]-->
+
+ <p id="IE">This browser is IE.</p>
+
+ <p id="notIE">This browser is not IE.</p>
+
+ <!--[if IE]>
+ </div>
+ <![endif]-->
+
+ </body>
+
+</html>
+
+
+The first block of code after the body tag has a starting div tag with an ID +of #IEroot inside a conditional comment; remember, +only IE sees this div.
+ +The last block of code before the closing body tag is a closing div tag +inside another conditional comment; this closing div tag will +match the starting div tag in the first block of code. Again, only IE will see +this closing tag.
+ +Between the opening and closing of the #IEroot div is where all of the normal +page markup will go. In this example it is just a box with some content, but the idea +is for the #IEroot div to be the ancestor of all page content.
+ +Using CSS, style the page as usual for non-IE browsers. Then in the same stylesheet, +use #IEroot as a prefix in descendant selectors to target specific rules at IE. The +example below styles the div called #anyelement to have a red border in non-IE browsers, and a blue border in IE.
+ + /* all browsers make border red */
+#anyelement {
+ border : 2px solid red;
+ }
+
+ /* all browsers see this, but only IE thinks #IEroot exists
+ as an element and makes border blue */
+#IEroot #anyelement {
+ border-color : blue;
+ }
+
+
+The first rule is a simple rule to apply a red border to #anyelement; this rule is seen by all browsers, even IE.
+ +The second rule changes the color of #anyelement's border to blue, but the selector is a little different than the first rule. +The second rule's selector is a descendant selector; it's interpreted as: the element with the ID of "anyelement" that is a descendant +of the element with the ID of "IEroot" should have the following rules applied.
+ +Since #IEroot was created using conditional comments +and only IE can see the contents of conditional comments, then in IE, #anyelement is a descendant of #IEroot and the descendant selector +matches. Therefore, this rule will apply to IE, making the border of #anyelement blue for all IE browsers, versions 5 through 7. And +because #IEroot is the first div and wraps the entire page, it can be used throughout the stylesheet to target rules at IE. This is used +just like the star-HTML hack was used, except that you cannot target the body tag with this method because the body element is not and cannot +be a descendant of #IEroot.
+ +Here is a live demo page. Be sure to view in both IE and non-IE browsers.
+ +Using this technique you can target part of a stylesheet at IE with confidence that this method won't +be affected by future browser releases.
+ ++Normally the CSS code will be clean, and the #IEroot rules will simply override key rules in the main styles +to make IE behave correctly. Some coders will want the option to write a rule that all non-IE browsers will +read, but that IE will not. A Child combinator can be used in a certain way: +
+ +body>#wrapper #anyelement {
+ styles for non-IE only...
+ }
+
+
++Just add a prefix to any selector for a page element (#anyelement) with body>#wrapper. +Of course, you will need to have a #wrapper element in the page, or some other major element that is a direct +child of the body. The clean HTML should have #wrapper directly inside the body element so that the selector above +will work. +
+ ++The Child combinator (>) selects the element on the right only if it is a direct child of +the element on the left. +
+ ++IE6 and below won't read the rule, for the simple reason that those browsers don't support the child selector itself. +IE7 does support it, but IE7 also happens to think there is an element called #IEroot! For IE7, a selector like +body>#IEroot>#wrapper would work, but the selector we described above does not include #IEroot. +IE7 thinks #IEroot is in the HTML, so IE7 ignores the rule. Thus all IE/Win versions are blocked from seeing this +type of selector. +
+ +Conditional comments allow special syntax constructions for checking the IE version and are proprietary to Internet Explorer for Windows. +A conditional comment is an HTML element that, in IE may conditionally be read, but, to all other browsers looks like an HTML comment and is ignored. +Here is an example of some markup with conditional comments:
+ +<!--[if IE]>
+<p>Only IE shows this paragraph.</p>
+<![endif]-->
+
+<p>A paragraph that all browsers display</p>
+
+
+
+In the above example, the first block of code has a paragraph of text inside a +conditional comment. Internet Explorer has been designed to examine all HTML comments for +certain syntaxes, and when it finds such syntax IE will simply read and parse whatever is inside +the conditional comment. Because conditional comments are hidden inside syntactically +correct HTML comments, all other browsers just see a comment and do not display the paragraph +contained within it.
+ +The next paragraph is outside the conditional comment and displays normally.
+ +If you want to test your conditional comments in different versions of IE, one simple method is to have multiple versions of IE installed +as standalones. But there is a problem with standalones: they don't support conditional comments correctly. +This article will help you fix conditional comments +and many other things in your standalone IE's.
+ +If you haven't installed multiple IE's yet, go +here to download a fast, easy, and complete multiple IE installer +with all the tweaks done for you.
+ + +Conditional comments support targeting of specific browser versions, which means divs can +be created that will be used in CSS selectors to target not just IE in general, but specific versions of IE. +Here is an example of how this might be done:
+ +<!--[if gte IE 7]>
+<div id="ie7andup">
+<![endif]-->
+
+ <!--[if IE 6]>
+ <div id="ie6only">
+ <![endif]-->
+
+ <!--[if IE 5.5000]>
+ <div id="ie5-5only">
+ <![endif]-->
+
+ <!--[if lt IE 5.5000]>
+ <div id="ie5-01only">
+ <![endif]-->
+
+<div id="anyelement">a box with some content</div>
+
+[... more page content ...]
+
+
+ <!--[if IE]>
+ </div>
+ <![endif]-->
+
+
+
+Only one of the four conditional divs will be created in IE, depending on the version of the +viewing browser, and none of them will be created in other browsers. Note that only one generic +all-IE div end tag is required, so no need to have multiple CC's for this task.
+ +The first div, #ie7andup, will be created in IE version 7 and up. The "gte" means "Greater Than or Equal to."
+ +The second div, #ie6only, will be created in IE version 6 alone.
+ +The third div, #ie5-5only, will be created in IE version 5.5.
+ +The fourth div, #ie5-01only, will be created in IE version 5.01. The "lt" means "Less Than." IE4 is not included, +since conditional comments were not introduced into IE until version 5.
+ ++When targeting IE5.5 you must add the zeros to the 5.5 or the browser may ignore the +conditional comment. <!--[if lt IE 5.5]> is not good enough, +it must be <!--[if lt IE 5.5000]>. There is no good reason for this, +that's just how it works. +gte IE 7 stands for "greater than or equal to IE7," +while lt IE 5.5000 stands for "less than IE5.5." When writing these CC's, exact +conformance to the syntax is required. Any error will cause the CC to become a normal HTML comment. +
+ +The corresponding CSS looks like this:
+ + /*** All browsers ***/
+
+#anyelement {
+ border : 2px solid black;
+}
+
+ /*** For IE 7 and up ***/
+
+#ie7andup #anyelement {
+ border-color : blue;
+}
+
+ /*** For IE 6 ***/
+
+#ie6only #anyelement {
+ border-color : green;
+}
+
+ /*** For IE 5.5 ***/
+
+#ie5-5only #anyelement {
+ border-color : purple;
+}
+
+ /*** For IE 5.01 ***/
+
+#ie5-01only #anyelement {
+ border-color : red;
+}
+
+
+
+See a live demo of the method. You will need multiple versions of IE to view all the variants.
+ +Not only is IE styled differently, but different versions of IE are styled differently. For example, this method makes it easy to fix the +box model problem +in IE 5.x +while not affecting IE 6 or 7. Each new #IEroot ID is customized to indicate what IE versions are targeted, +in effect "labeling" each special IE rule by version number. This helps when later doing site maintenance, +and team environments benefit as well from the reduced potiential for confusion.
+ ++This Guest Article is authored by Hiroki Chalfant + +
+ + + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+
+Last updated: Febuary 2, 2007
+Created Febuary 2, 2007
+
I've provided advanced CSS consulting for
+Milo 
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ +
+Return to Articles.
+Return to p.i.e.
+
+This tutorial was written due to popular demand. I owe special thanks to David Tiley for +his strong encouragement and help improving this, my first foray into the world of graphics +creation. Thanks Dave! +
+ ++The Four Sided PNG Drop Shadows Method provides a way to +place a large drop shadow or glow image onto a smaller box of any arbitrary +size, and it works very well indeed. However, what that article doesn't provide is a step-by-step guide showing +graphics novices how to go about making that large drop shadow. It's time to remedy the omission. +
+ ++For this graphics tutorial I've decided to use Gimp, +because of its universal availability and because Gimp is now a rather sophisticated graphics editor. +Gimp is Open Source (free!) and is rapidly improving with a huge fan/user base, so its future is very bright. +This tutorial assumes at least a basic familiarity with graphics editors in general, but does not assume +that the reader is a guru. +
+ +
++In Gimp's main window, go to +File>New (Ctrl+N). In the New Image dialog, +click on the Advanced Options expander to see all the options. Specify a width +and height that will be larger than the maximum shadow you will need. This can be a +difficult decision. If you make it too small then a large shadowed box might show a gap somewhere +along the box edge, but making the shadow image very wide and tall leads to unnecessary bandwidth +and load times. Luckily these shadow images are mostly full transparency so even a huge one is +surprisingly small in file size. +I've chosen 300px as the size for this demo, but more typically it would be 1000px or even larger. +
++If your shadow is to be entirely shades of gray, you can set the Color space field to "Grayscale" +as I've done here. This makes the resulting PNG file about 40% smaller than if all the color channels were used. +If the shadow is to have some color in it, make sure you leave the color space setting at "RGB color" or it won't +be possible to do so. +
++The Fill with, Template, resolution, and Comment +fields are fine with the default settings. The Reset button is handy for returning to the default settings +if they've been changed and you can't remember what they were. +
+
++ With everything set, click "OK" to create your image. +
++You should see a new window with a dashed line surrounding the new image. +The checkerboard pattern is there to reveal the fact that the image is transparent. +That checkerboard won't show up on the finished image so don't worry about it. +The rulers seen along the left and top edges in the screenshot are a Gimp option I've +chosen under: View>Show Rulers (Shift+Ctrl+R). +You may find those rulers to be very handy for some kinds of graphics work. +Notice how in the screenshot with the title bare text "Untitled-1.0" there's an +asterisk before the file name? That's to show that the image hasn't been saved (or has unsaved changes). +
+
++I like to work with a solid light background to judge the shadows against, so let's go ahead and fill that image with some white. +In the Toolbox Window, click the Bucket Fill Tool (Shift+B) +to activate it, then click on the foreground swatch The little white rectangle overlapping the black one in the graphic) +and set it to white. (click the double pointed arrow to switch the two colors) I actually prefer an off-white color so that +the image stands out against the white image window background, so that's what I've done for the graphic images in this tutorial. + Now left-click on your image directly and the image layer should fill with your chosen foreground color. +
++We don't want our finished shadow image to have that white color, so make a new layer to work on. This layer will +contain the actual shadow which will become the finished production image. Go to +Layer>New Layer (Shift+Ctrl+N). In the dialog leave all the defaults alone and click OK. +
+
++There should now be two layers showing in the Layers dialog (as shown) with the new layer highlighted. +Make sure this layer is always highlighted from now on or you'll be working on that white background +layer instead! Be aware that you can drag the layers in the Layers dialog past each other to change their +stacking order and also temporarily hide them by clicking those little eyeball icons on the layer boxes. +Go ahead and try it just for fun. +
++Gimp has a very flexible dialog/dock system, but it can take some getting used to. If you can't find +the Layers dialog or any other dockable dialog, go to Windows>Dockable Dialogs +for a complete button list of those dialogs. These "docks" are separate windows that can hold persistent +dialogs such as Layers and History in a handy group format. To learn how dialogs are added to and +removed from docks, see +Dialogs and Docking +in the Gimp online manual. +
+ +
++The next step is to select the entire image and shrink that selection box by the amount you want for your drop shadow width. +This width is critical to the Four Sided PNG Drop Shadows Method. +The CSS for the method must be tailored to match the shrink length you will choose, but once you make +the correct modifications to the code, any shadow width will work fine. + +Go to Select>All (Ctrl+A) and that should start the 'marching ants' going around your image. +
++Go to Select>Shrink (Alt+S>H) to bring up the Shrink Selection dialog. +
+
++The length value you choose will be the width of your shadow. I've picked 10px in this demo. For now don't worry +about varying shadow widths on different sides, just make it as big as the widest shadow you will need. +
++Make sure the Shrink from image border checkbox is checked, or else the shrink action +won't work. This seems to be true only when the entire image is selected. Otherwise you need +to uncheck the box for it to work. Don't ask me why, I have no idea. That's just the way Gimp does it. Oh well. +
++Now you should be seeing something like the screenshot to the right, with a select box some distance +inward from the image edge. Ignore the extra dashed line around the image edge, it has no actual effect. +You can tell which is the real selection by the 'marching ants' effect on the inner line. +
+ +
+Be aware that the
+Four Sided PNG Drop Shadows Method
+requires that the image area outside the select box be the same size on all sides of the image.
+It doesn't matter what kind of graphics you place in these side-areas. Shadows, border lines, transparency, whatever, as long as the distance
+from the select box to the image edge is the same on all sides. Your content box (div.shadow-four) will end up with its
+edge exactly aligned with the select box line, so any backgrounds or borders that you wish to have appear within the selected region
+are best applied to div.shadow-four, not the main drop shadow image.
+
+Also be aware that the width of this area outside the select box (taken as a px length value) must be doubled
+and used as the px length values for all css lengths in the method except the relative shift offsets on
+.shadow-four, which get the px length values without doubling, but as negative values of course.
+
+
+Here comes the fun part. To bring up the Drop Shadow dialog, go to:
+Filters>Light and Shadow>Drop Shadow
+
+The default values in this dialog need to be changed to match your desired drop shadow parameters. +
++Here's what the options do: +
++If the Allow resizing checkbox is checked, the resulting shadows may enlarge +your image on one or more sides, causing the PNG drop shadows method to work incorrectly. +Generally you should always uncheck this box. +
++The procedure here is to try some settings, hit OK and see what results. Usually it's +not quite what you want, so you then go to Edit>Undo (Ctrl+Z) +and try again repeatedly until it's just right. +
++If you only want a simple shadow all around the select box, just set the offsets to zero and give the blur radius +something close to 10px. It's not always necessary or desirable to exactly match the shrink length you use. +For instance, if you set the opacity to a low level you can widen the blur radius quite a lot without apparent clipping. +I suggest you play around with various settings to see what effects you can get. +
+
++For this demo I chose X and Y offsets of 2px, a blur radius of 10px, a color of black, and an opacity of 60%. Note that +those positive offsets along with the blur radius would cause image enlargement at the right and bottom edges if the +"Allow resizing" checkbox were checked, but I keep it unchecked so I won't have to manually clip that excess +later. Note that the offsets may also be negative, pulling the shadow up and to the left instead of down and right. +
++Bring up the Drop Shadow dialog and insert the values as described, then hit OK. +
++Now the shadow is in place and looking mighty fine, but check out the title bar of the image window. +Three layers? Where did that come from? Well, it so happens that Gimp creates a new layer called +Drop Shadow when making +a drop shadow and puts the actual shadow on that layer. Furthermore, this new layer is placed on top of the +selected layer. It's not a problem but be aware that this is happening so you won't be confused by it. +
+
++By the way, you may rename any layer in the Layers dialog simply by double clicking the name and typing a +new one. In the future when you're building hi-rise multi-layer images it'll be nice to have descriptive +names on all of them, eh? Oh yes. +
++See that opacity slider in the Layers dialog? If you click on the Drop Shadow layer you can re-adjust +the opacity of the shadow on-the-fly, fine tuning it to your exact desires. Sweet. +
+ ++Before you can save, make sure you go to the Layers dialog and click that eyeball icon on the Background layer. +Doing that will kill the white background and reveal the checkerboard again. Now all is in readiness. +To save the image, just go to File>Save As (Shift+Ctrl+S) and in the +Save As dialog choose the location to save, and name the file too. +You can get a Select File Type field by clicking the expander +just above the Help button, but it's quicker to just type the .png extension on the file name. +
++When you hit the Save button, a new Export File dialog pops up. The reason for this is that +your image has layers and the PNG format doesn't do layers (except for the proprietary Fireworks PNG format). +This dialog will automatically compress the layers to a single layer for you. Make sure that the +Merge Visible Layers radio +button is selected. This will exclude the white background layer from the exported PNG because you just +made it invisible by clicking the eyeball icon for that layer. Now hit the Export button. +
++Yet another box pops up (sigh), the Save as PNG dialog. Just uncheck all the +checkboxes (unless you feel the need to check some of them) and keep the compression slider at the maximum level. +Hit Save. Woohoo! You've finally got your excellent drop shadow image! +
+ ++I hope you liked my first graphics tutorial. I know this one doesn't break any new ground, but +quite a few people have asked me for advice on making these shadow images, so here you go! +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: June 23, 2009
+Created June 20, 2009
+
I've provided advanced CSS consulting for
+Milo
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ +
+Return to Articles.
+Return to p.i.e.
+
+This article is largely obsolete due to an
+improved method that covers all sides of a box and needs
+only one shadow image to work. However, some may prefer this method or have already implemented
+it, so this article will remain for the time being.
+
+Special Notice: I've written a
+tutorial for making drop shadows, using the free Gimp
+graphics editor. Enjoy!
+
+This article will describe a modification to existing drop shadow methods, employing +semi-transparent .png's. Therefore the method is meant for use in in IE7 and +the other modern browsers, but not in IE6 and below, which do not correctly display +such .png's. IE/Mac can display .png's correctly but will have trouble with the +CSS used in the method. We have a +minimal demo page +available, complete with helpful tips in the source comments. +
+ ++The PNG Drop Shadow method works in Gecko browsers, Opera, Safari, and IE7. It is made to degrade +gracefully to a basic box without dropshadows in earlier IE versions, since those +browsers don't support the partially transparent .png's used in the method. +IE/Mac does not support the method at all, due to the lack of +widths on some floated or positioned elements, and also because of the relative +shifting effects used. The +IE Machack +may be used to dumb down the code in a way similar to the IE6 dumb-down technique. +
+ ++Say what you want about drop shadows, they are everywhere on the web and in print, +and for good reason. There's just no other way to get a three-dimensional effect +without making page elements physically move around. Such shadows might be placed on any +sides of a box, but the common usage is to have them on the right and bottom edges, +and we will confine ourselves to that convention. +
+ ++There have been a lot of methods developed to display drop shadows, and all the +early ones made use of tables. These days it's usually considered bad practice to +use tables for "window-dressing" of this kind, and so +tableless methods +have been developed to do the same thing. Unfortunately, all current drop shadow +methods tend to have undesirable side-effects and/or display weaknesses of one kind +or another. +
+ ++Let's quickly review the existing methods, or you can just +skip to the new method. +
+ ++It's possible to use nested DIV's and simple background colors to fake the look +of drop shadows, as long as you just want to suggest a drop shadow. +Phoenity.com offers a method using +backgrounds on several nested DIV's, along with two trickier methods. +
+ ++Essentially the background method starts with some DIV's nested together and being all the same size. +Then beginning with the outer DIV, each successive child DIV is given a progressively +darker background, and relative positioning allows them to be shifted up and to +the left by 1px more for each successive DIV. This creates a content box that is +backed by other boxes of the same size, each one a bit farther down and to the +right than the one in front of it, simulating a drop shadow. Very simple indeed. +
+ ++Unfortunately, clients are high-maintainance creatures, and they usually require that +drop shadows be "fuzzy." Oh sure, real shadows usually are fuzzy, but clients +could be more reasonable, yes? Well, no, clients seem to have all the +money, and the money is saying "fuzzy" too, so we had better listen to the +money, yes? +
+ ++The obvious solution is to go with images of some kind, and that's where it starts to +get complicated. First the fuzzy drop shadow images must be made, requiring graphic +skills. We can't help you there, but assuming you can get by that hurdle, next +comes trying to arrange code so the image or images end up looking drop-shadow-like. +
+ ++Of course you may always add a customized dropshadow to any existing image using +a graphics program, and also create one separately for use in a padded DIV that contains +some content, but this will not work when a site is pulling arbitrary content out +of a database. +
+ ++Thus Requirement Number One: The ideal drop shadow method +must work on any arbitrary element. +
+ ++This requirement has been met in the past by using a table, with cells that contain +the important corner bits of the shadow while the long cells along the right and +bottom sides are allowed to stretch out the fuzzy image to any needed length. +However this kind of table trickery is really bad practice, due to major accessibility +issues and also because of code complexity. We will assume that you don't want to go there. +
+ ++CSS doesn't utilize table cells, but it does have backgrounds, and these will be our +primary tools for creating drop shadows. We've already seen how simple background-colored +DIV's can get the job done, and backgrounds are not limited to colors but may +also accept images. Furthermore, CSS allows backgrounds to be +positioned against any of the four sides +of a designated box. Cool, that's just what we need for drop shadows! +
+ ++The imaged drop shadow approach does have a serious problem, and that's +file size. Using pure CSS for a drop shadow may not look great, but +the server hit is very small. So what exactly is the bandwidth cost of +using images? Well, the main +shadow.png +image used in our +demo page is +only 3.5kb, while its dimensions are a quite-large 800x600 pixels. The file weight +is this small because most of the area in shadow.png consists of simple transparency. +The two corner .png's used are just 275 bytes each +(upperrightfade.png and +lowerleftfade.png), +so all three images together sum to just 4kb total. A typical web page .jpg is +far more than a mere 4kb. Since this drop shadow method re-uses these .png's for every +instance on a site, that 4kb is a one-time hit and will then be cached, requiring no +further bandwidth expense. +
+ ++Way back in 2003, Dunstan Orchard explained his +Easy CSS drop shadows +method, later reprised and improved at A List Apart +by Sergio Villarreal in the +CSS Drop Shadows +article. Dunstan's method uses a drop shadow that is very wide and tall (we're +doing the same thing), and positions that background into the lower right corner +of a box. Any parts of the background that would display beyond the edges of the +parent box are automatically clipped off visually. Then an +inner nested element is shifted up and to the left via negative margins, allowing +the background on the parent to show. +
+ ++Sadly, the place where the background is clipped looks very sharp and not at all +fuzzy, potientially making a client unhappy. Sergio soon had this pointed out to him, +so he then went beyond Dunstan with the +CSS Drop Shadows II: Fuzzy Shadows +article, where Sergio shows a neat method of applying a masking background to the main image +via one extra nested DIV. It works by having the image start pure white (or the color +of the page background) along the top and left edges, and that white then quickly +fades to transparency just a short distance from those edges. Most of this .png +image is blocked off by the opaque content box, leaving just a bit showing. +Those two bits that show in the upper right and lower left corners will then +partially mask the main shadow image where it is cut off, giving the appearance +of a nice end-fade. +
+ ++Because of that opaque white portion of the masking .png, +the method must be placed in front of a solid white page background, or +some other color that will serve in place of the white in the masking +.png image. +
+ ++Then along came Brian Williams' +Onion Skinned Drop Shadows, +which uses two DIV's instead of one to mask the corners, allowing a simpler way to offest +the content box, and thus allowing a slight lessening of the shadow thickness merely +by adjusting the CSS rules. +
+ ++Those are great methods, but they have one really serious flaw, in that these masking +backgrounds must overlie the main drop shadow background image. You may be saying, +"What of it?", and in +the case of a .jpg or .gif image, you are right +to ask. Those image formats work fine with this method. But there is another +format, .png, and it is much more effective for drop shadows than +either .jpg or .gif can ever be. +
+ ++In a .jpg, all displayed pixels must be fully opaque, meaning +you can't see thru them. In the .gif format, all pixels may be +fully opaque or fully transparent, so you may either see thru a pixel completely +or not at all. That's fine if you know what solid color the shadow will be cast upon, +because the shadow image may then be faded to that color and it will look great. +
+ ++Now think about our ideal drop shadow. It's supposed to be a shadow, +right? When you see a real shadow caused by one object fall across other objects, +can't you still see those other objects, even if they are darkened? Sure, and that +is where the non-png formats fall down. They don't allow you to look thru the +shadow. +
+ ++The .png format does allow this, because a pixel may be set to +any transparency from 0% to 100%. So our ideal shadow image may start at the outer +edge at fully transparent, and gradually become more colored and less transparent +as it gets closer to the object that is supposedly casting the shadow. +
+ ++Thus Requirement Number Two: The ideal drop shadow method must use the .png format. +
+ ++Okay, you know the drill by now, it's.. (drum roll..) +IE6 . Again! (sigh) IE just +does not support the png format when partial transparency is used. It's +been a web-scandal for years, given that most all competing browsers started supporting .png +long ago. Happily IE7 does support the .png format properly, so when +that version takes over the user base we may begin employing imaged drop shadows that look +good even when placed against patterns or objects on the screen. +
+ ++There is one way to make IE6 "support" partially transparent .png's, using a +Microsoft proprietary feature, the alphaimageloader filter. +Unfortunately, use of this filter means that it is not really a background anymore, +and so cannot be positioned. Even worse, the filter must be applied to a box that +has Layout, and +that would wreck the method in IE6. These and other MS filter problems are covered at +Ingo Chao's website. +
+ ++Okay, we merely need to wait a while, and our beautiful .png drop shadows will work +in most browsers, yes? Well, yes and no. The fact is, those two imaged drop shadow +methods we mentioned earlier cannot work with .png images. There's a simple reason, +and it will become clear if you think about shadows "twice" as hard. +
+ ++If you put on sunglasses, the world gets darker, correct? And what happens if you +put on two pairs of sunglasses at the same time? Darker still. Well, the +same thing happens to partially transparent .png's when they are overlaid one atop +another. Basically the alpha transparency of the two .png's are added, making the +result less transparent, hiding twice as much of what is behind them. +
+ +
+
+That's great for the cases where different shadows are supposed to cross over
+each other, as in the graphic to the left. This image was taken from our
+demo page, where the
+kitty's shadow crosses the clock's shadow. The arrow indicates the region where
+the .png shadows cross, and it's easy to see how the pixels are added together and become
+less transparent, producing a darkening effect similar to the way real shadows behave.
+
+It isn't so pretty if such darkening occurs within a single drop shadow. +
+ ++Here's the basic problem. The Onion Skin method works by placing a couple +of small "masking" .gifs directly in front of the sharp clipped ends +on the main shadow image. One edge is opaque and the same color as the page background, +while the other edge of that same masking image matches the main drop shadow image, with a +gradient between the pure color edge and the complex shadow edge. +
+ ++The increasingly white portion of the masking image makes the linear main shadow +appear to fade toward white, masking the spot where it would appear clipped, so +you never see that sharp clipped shadow-end. But this means that even if the main +image is a semi-transparent .png, both ends of the composite drop shadow will be +completely opaque, necessarily masking off any pattern on the page background, +and we are using .png to avoid hiding the page background. +
+ ++That's no good, so what if we substitute partially transparent .png's +for both the main and corner background images, what happens then? Remember that they are +fully overlapping each other. You guessed it, the screen area they both +occupy becomes twice as dark as desired, again ruining the drop shadow effect. +
+ ++ +So this method cannot be used with the .png format, and that will become a big +problem as IE7 becomes more prevalent and clients get hungry for better drop shadows. +Obviously we need a new method! +
+ ++The only way a .png drop shadow can ever work is to avoid any overlaps between the +different images that make up the drop shadow, meaning that they must exactly +touch at all times, but must not overlap. The current methods cannot +do this, so some new tricks must be employed, and CSS is so powerful that it +gives us just the tools we need do it. Let's begin with the basic HTML structure. +
+ ++Yes, nested DIV's are again needed, and for the same old reasons, to provide extra +backgrounds and the ability to shift the content box. Some may say that nested DIV's +are no better than the table method, but just try and compare the two code constructions +by eye and you will see a huge difference. The tabled drop shadow approach leaves +cells scattered willy-nilly around the intended content, while nested DIV's keep +all their start and end tags in two tight groups. +
+ ++Besides that, such non-content table cells are very unpleasant for those vision-impared +users who use screen readers. If it helps, imagine that our two groups of DIV +tags are really "supertags," since the start and end tags all occupy the same two spots +in the source, just like simple tags do. Hey, one string of code could +be considered as one "tag", right? +
+ ++Anyway, Let's start with the HTML needed for this method: +
+ +<div class="outerpair1">
+ <div class="outerpair2">
+ <div class="shadowbox">
+ <div class="innerbox">
+ <img width="400px" height="315px" src="kitty.jpg" alt="" />
+</div></div></div></div>
+
+
++.outerpair1 and .outerpair2 are mainly used to +hold and display two small .png backgrounds for the sharp corners. In addition, +.outerpair1 may also receive an optional extra class to provide a width +or extra styling. The .outerpair2 DIV gets method-essential padding. +The .shadowbox DIV holds the main .png drop shadow background, and +.innerbox employs relative positioning to shift the content +so that it does not cover the dropshadow. +
+ ++We'll study these elements one at a time along with their related CSS properties. +
+ +
+
+The .outerpair1 DIV is the outermost box, and so this element
+interacts with the rest of the page elements outside the drop shadow group. As
+such, this DIV may be floated or made absolute to enable "shrink-to-fit" around
+a sized content element like an image or flash movie, or alternatively .outerpair1
+may be directly sized via a CSS width.
+
+.outerpair1 is fairly bug free in Explorer, so there is not too much that can go +wrong regarding any CSS applied to the DIV. Be aware that if the DIV group contains +flexible content like text, and is placed inside a column element that is already +width-controlled, there will then be no need set a width on the .outerpair1 DIV. +The column itself will control the width of the drop shadow DIV group. Still, +you may apply margining to .outerpair1 if you wish, further constraining its width +within that width-controlled column element. +
+ ++Besides being the "outside face" of the DIV group, .outerpair1 serves to +display the upper-right-corner background .png that will terminate the right side +of the drop shadow at the top end. +
+ +
+
+Next comes .outerpair2, which displays another small .png in the
+lower left corner, terminating the bottom drop shadow at the left end. It's a
+shame that both of these background images can't be applied onto just one div,
+but elements are restricted to one background each. It's not possible to predict
+how far apart the corners will be, and background images cannot be scaled, so
+there is no choice but to use two DIV's for this purpose.
+
+It is technically possible to combine these two DIV's into one, by using +a method similar to that found in the +CSS Drop Shadows II +article, but then the resulting drop shadow couldn't be placed over patterns or +other objects because there would be opaque ends on the drop shadows. If it were +done with a .png, the end-fades would not be smoothly rounded but would instead be +oddly squared off. +
+ ++.outerpair2 also supplies a major piece of the method via its +top and left padding, which is +sized to match the thickness of the drop shadow. This padding (outside the dotted +red lines in the graphic) forces any elements nested inside of .outerpair2 to be +8px smaller both horizontally and vertically, and keeps that element down in +the lower right corner of .outerpair2. We have thus prepared a nesting spot for +the next DIV, so let's bring it in. +
+ +
+
+
+As you can see, .shadowbox (bordered blue in the graphic) has
+just one function, to display shadow.png as a background image, positioned
+into the lower right corner of the .shadowbox DIV. This DIV occupies the space
+delineated by the padding on .outerpair2. The first graphic to the right
+shows how the shadow.png image is actually much wider than needed, and extends
+beyond the left and top edges of the .shadowbox DIV. That would look terrible
+if it were displayed in a browser that way, but luckily it is not.
+
+Background images are never allowed to display beyond the edges of their +parent element, and any that do will get clipped off at the parent box edges, +as shown in the 2nd graphic to the right. The blue bordered .shadowbox is the +parent for this background, so the clipping occurs at the left and top edges of +.shadowbox, exactly where it touches the two other background images. +
+ ++Note that all the colored and black borders in these graphics are for explanatory +purposes only, and the method itself does not need them. +
+ ++So now our shadowed DIV group is nicely falling into place, but we aren't done +quite yet. There is still a need to place an actual content DIV in there, but +where? The obvious location would be a box the same size as .shadowbox and stuffed +into the upper left corner of .outerpair2, but that can't normally happen because any +further nested DIV's must fall inside .shadowbox! +
+ ++Okay, it's true that the .innerbox DIV must go inside the .shadowbox DIV, but it +need not be displayed there, as we shall see. +
+ +
+
+
+Let's go ahead and plop .innerbox inside .shadowbox, and sure
+enough it ends up covering the entire shadow.png background. That's no good,
+so to fix it we make .innerbox "relative" and apply negative left
+and top values similar to the paddings on .outerpair2.
+
+When such relative shifting occurs to a box, it's as though the box were lifted +bodily from the page and shifted sideways in front of the other page content. After +it comes to rest, it covers up anything that lies behind it. More importantly, +that shifted box does not change its dimensions. So not only does it +go where we want it to, but it's the correct size when it gets there. Perfect! +
+ ++The two graphics to the left reveal how .innerbox is first placed neatly +within .shadowbox, and then is shifted up into the desired location. Now the +drop shadow is starting to look pretty darned good, isn't it? +
+ ++Some may wonder why we haven't used negative margining for this operation, but that +method just doesn't work, for certain complicated CSS reasons. We could try to explain +it, but it really doesn't matter much. Besides, we aren't sure we understand it +ourselves! All we really know for sure is that negative margins don't get the job done. +
+ ++The last step is perfectly obvious, just drop some kind of content into .innerbox +and that content will appear to throw a .png shadow onto any patterns or elements +that are behind it. Woohoo! +
+ +
+
+
++It should be kept in mind that this DIV stack is arranged a bit differently than the +Onion Skin stack, +which has the main shadow background at the back, with the corner backgrounds masking +it off from in front. Our .png method requires that the corner backgrounds be +behind .shadowbox (enclosing .shadowbox), because those DIV's must be +larger than the .shadowbox DIV. It isn't really feasible to have larger elements +inside smaller ones, at least not without great complications. +
+ ++Also, by doing it this way it's easy to pad the .outerpair2 DIV so that the smaller +.shadowbox DIV fits nicely inside, with the three shadow .png's in full contact +but never overlapping. Works for us. +
+ ++It must be made clear that the primary consideration when applying this technique +is that of width. The height will take care of itself, but width matters a lot. +If the content placed within the DIV group has an intrinsic width +(as do images, flash movies, Iframes, etc...) or if it's a block element with a +stated width, and .outerpair1 is either floated or made absolute, +.outerpair1 will shrink-to-fit. This means that the outermost DIV will want to shrink +down to the width of that innermost pre-sized content, constraining .outerpair2 and +.shadowbox down as well in the process. The result is a nice well-formed shadow group. +
+ ++If the content element is widthless, perhaps as a simple paragraph, then the text +in that paragraph will want to "inflate" the paragraph to fill as wide a space +as possible. Positioning or floating on .outerpair1 will not +stop the text from inflating the entire DIV group to the maximum space available. +For this case it is necessary to apply a width to either that content element, +the .innerbox DIV, the .outerpair1 DIV, or an external bounding box such as a +column container. +
+ ++Just remember, a block of text always exerts inflationary width pressure, and float or position-induced +shrink-to-fit behavior loses when it goes head to head with that text inflation pressure. A real assigned +width is needed somewhere, or else the text will expand into any horizontal space available outside the shadow +group, widening the entire group as it goes. +
+ ++Let's take a hard look at the PNG Drop Shadow method. +
+ ++First, it's true that .innerbox could be discarded and its CSS applied to the +image itself. Usually that works fine, but it won't work in IE7 for all cases, +and we wanted to make the method as fool-proof as possible (present company excepted). +
+ ++Be careful when adding inner elements that have top margins, because these will +"escape" from .innerbox and then ram against the top padding on .outerpair2, +forcing a gap in the shadow arrangement. If .innerbox has a width or height, +IE will trap the margin there and will look okay while Firefox will appear broken. +Just add a 1px top padding on .innerbox to insure any internal margins are trapped +there and won't escape to cause damage amongst your shadow group divs. +
+ ++Some very weird background bugs can occur in IE7 for reasons that are still not +entirely clear. One bug seems to double the shadow.png application, causing an +overlap darkening, but often only within "zones" of 150px in height and only along the +right side. We have seen these mysterious IE zones before, and now there is a bit +of light on the subject. +
+ ++Another set of bugs may occur if .innerbox is replaced by a non-div element like +a paragraph. It just goes buggy, that's all, IE doesn't really need a reason. +By having .innerbox be a DIV, those non-div bugs are avoided. +
+ ++The current construction seems to be immune to the weird IE background bug, but +be warned that tweaking the method could easily resurrect the IE bug. To modify +the method, open the display in IE7 and make changes one at a time, checking +carefully each time in IE7. Otherwise +you could do a lot of beautiful work for Firefox only to be faced with a really +nasty bug that refuses to die. Don't let this happen to you. +
+ ++A very important point is that .outerpair2 and +.shadowbox must never receive either a +width or height. The reason is that this would trigger +Layout, causing +any .outerpair1 shrink-to-fit to fail in all IE versions. Just try it and see! +Further, any other CSS properties that trigger layout are also to be avoided. +It shouldn't be an issue since those two DIV's are there only to support the +technique and really ought not be messed around with, but mistakes do happen +so be careful. +
+ ++As mentioned, IE7 supports the method as does Firefox, Opera, and Safari. IE6 and +IE/Mac will need to have most CSS in the technique hidden from them, and IE/Mac +will have additional trouble in the cases where .outerpair1 is floated or made +absolute for shrink-to-fit purposes. While IE/Win can easily get CSS that displays +a simple unstyled set of nested DIV's, IE/Mac will be problematic in the +shrink-to-fit case without a width on a floated or positioned .outerpair1 DIV. +
+ ++It so happens that IE7 obeys the child combinator ">" while +IE6 and below do not, so any rules you wish to hide from earlier IE/Win versions +need only have this CSS operator in the selector. IE7 will read the rule and can +also handle the .png's that go with it, and IE6 will ignore the entire rule, so +everyone is happy. Examine the source of the +demo page for details on +this trick. Alternatively you may use +Conditional Comments +to achieve the same effects. It's not very hard to perform the dumb-down itself, +so we'll just give the general theory. +
+ ++Basically the idea is to hide all styling on .outerpair2, .shadowbox, and .innerbox, +along with the background on .outerpair1, from the gaze of IE6 and below. Any widths, +floating, or positioning on .outerpair1 should be shown to all browsers. That's all +there is to it, and the resulting DIV group will act like a single DIV when rendered in IE6. +
+ ++This method is very new, and we would be very happy to hear about any problems +you may encounter when using it. Also we want to link to any coders who demo +useful modifications to the method on a stable web page. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: June 20, 2009
+Created May 1, 2006
+
I've provided advanced CSS consulting for
+Milo
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ +
+Return to Articles
+Return to p.i.e.
+
+This article has been revised as of May 2009 to add improvements to the method which
+make it possible to have only a single drop shadow image, rather than the three that
+were required in the original version. The obsolete three-image all-around shadow method
+when discussed in this article will be referred to as the "previous version."
+This new simplified version of the method was inspired by a question from
+Antonio Vong, who
+asked if it was possible to make it work with only one big shadow image. I had previously
+thought not, but further thought led me to develop the rather obvious revised method
+explained here, oy. Thanks, Antonio!
+Special Notice: I've written a
+tutorial for making drop shadows, using the free Gimp
+graphics editor. Enjoy!
+On the Web:
+Go see how Scott Schiller achieved
+this same four-sides PNG effect.
+Nice use of scripting on the demo page too!
+From Paris, Matthieu Larcher has a new
+custom buttons tutorial
+based on the four-sides method. Woohoo!
+
+
+In the PNG Drop Shadows article we explored a new +CSS method that uses the PNG image format to apply drop shadows to any arbitrary +box, producing excellent looking shadows. That's great, but the method limits us to +having shadows on just two sides of the content box. Clients aren't going to be satisfied +with that stricture for very long, so we need to pump up our shadows to cover all four +sides of the box, just in case. +
+ ++Okay, normally drop shadows are not used all the way around a box, but some designers want it, +and what about a 360 degree "glow" effect? Lots of people can go for that, right? +
+ ++Before delving into the guts of the new method, check out a separate demo page showing a live example +of an all-around +glow effect +in all its glory. Note that the demo page uses hovering to modify the background-position property on +the div group, but this is just a visual extra and isn't needed for the new shadow method to work. +
+ ++As with the old two-sided method, the four-sided method does NOT work in IE6/Win, +due to the lack of support for semi-transparent PNG images. +That browser needs to be given dumbed down +code via hiding hacks so that it gets just the content object and not any of the shadow trickery. +If older browsers must display exactly like modern ones, you might want to avoid using this +method for the time being. +
+ ++The basic method described here works flawlessly in IE7+, Firefox, Opera, and Safari. +
+ ++In PNG Drop Shadows the DIV classes were named .outerpair1, +.shadowbox, and so forth. This time we'll dispense with descriptive names and go with a simple +numerical system, using the classes .shadow-one, .shadow-two, +on up to .shadow-four, along with two new empty divs (.corner-a and .corner-b) +that are placed inside .shadow-one, but before the .shadow-two div starts. Since the group of six div +tags will never need altering, it's simpler and more intuitive to use a number-based class system. +This arrangement makes it almost impossible to accidentally mix-up the order of the div group. +
+ ++While it's true that this method uses two more divs than the old method, +it can still be used to handle the old method by updating the old CSS to reflect +the new class nomenclature and by keeping the two new empty divs unstyled. +Without any styling applied, those divs will have no visible effect on the old method. +
+ ++This way you can use the new html generically across a site, applying either method with ease and +complete safety. Cool! +
+ ++The following HTML is all you need: +
+ +<div class="shadow-one">
+ <div class="corner-a"></div>
+ <div class="corner-b"></div>
+ <div class="shadow-two">
+ <div class="shadow-three">
+ <div class="shadow-four">
+ Content...
+</div></div></div></div>
+
+
++The CSS for the new four-sided method is similar to the two-sided method, but there's a few differences. +Here's what the new CSS code looks like: +
+ +.shadow-one {
+ position: absolute;
+ padding-top: 100px;
+ padding-left: 100px;
+ }
+
+.corner-a {
+ position: absolute;
+ right: 0;
+ top: 0;
+ width: 100px;
+ height: 100px;
+ background: url(shadow.png) right top no-repeat;
+ }
+
+.corner-b {
+ position: absolute;
+ left: 0;
+ bottom: 0;
+ width: 100px;
+ height: 100px;
+ background: url(shadow.png) left bottom no-repeat;
+ }
+
+.shadow-two {
+ background: url(shadow.png) right bottom no-repeat;
+ }
+
+.shadow-three {
+ position: relative;
+ left: -100px;
+ top: -100px;
+ background: url(shadow.png) left top no-repeat;
+ }
+
+.shadow-four {
+ position: relative;
+ left: 50px;
+ top: 50px;
+ }
+
+
+
+
++Besides the code above, the method requires a shadow image The graphic to the left +shows a scaled down example of the full image, which has a semi-transparent shadow +surrounding a large transparent rectangular area. The actual PNG image used should +be as large as needed to cover any desired content box. The images need to be transparent +(other than the shadow or glow itself) so that body background patterns and the like will +be visible thru them. +
+ ++The center does not really need to be transparent, but if you ever want +something behind the div group to "show thru" some part of the content area, it will +have to be transparent for that to happen. +Just be sure that the distance between the outer image edge +and the inner shadow edge is precisely the length you intend. In the case of this article I've +chosen 50px as the width of this shadow zone. +
+ ++Making the image is simple if you have access to a good graphics program. +Check out my tutorial for making drop shadows in Gimp. +
+ ++If you don't want RGB color in your shadows or glows, you may convert the PNG to grayscale, greatly reducing +the final file size of the images. I used Gimp 2 +to do this and cut about 40% off the weight of the files. +
+ ++The graphics that follow have colored borders and backgrounds for some areas to better illustrate the method, +but these borders and background colors would not be used in an actual production page. +
+ +
+.shadow-one {
+ position: absolute;
+ padding-top: 100px;
+ padding-left: 100px;
+ }
+ /* Use position: relative when
+ not using position: absolute */
++The outer div gets some method (absolute positioning in this case) to make it +"shrink-to-fit" and collapse all the divs in the group around the content element. +Floating or a width applied to the div or a surrounding container can also do the +trick. In most cases the content element should have either an intrinsic or stated width, +so that the shrink-to-fit behavior on .shadow-one has something rigid to collapse against. +
++If you want to float this div rather than absolutely position it, make sure you apply +position: relative; so the two small corner divs remain inside and don't fly away to some +positioned parent further out (the HTML element is the default positioned parent, btw). +
++No background is applied here (unlike previous version) but top and left paddings are applied +(dotted red lines) to constrain .shadow-two into a smaller area. The .shadow-one div is required to be positioned +as absolute, relative, or fixed, so that the corner divs will use .shadow-one as a positioned +base for their own locations. If you want to float this div, use relative positioning. +
+
+.corner-a {
+ position: absolute;
+ right: 0;
+ top: 0;
+ width: 100px;
+ height: 100px;
+ background: url(shadow.png) right top;
+ }
++This div is empty and is positioned to the upper right corner of .shadow-one so that its +background is showing the upper right corner of shadow.png. Note that the padding on +.shadow-one has no effect on any absolutely positioned children, which only care about +the actual edges of their positioned parent. +
+
+.corner-b {
+ position: absolute;
+ left: 0;
+ bottom: 0;
+ width: 100px;
+ height: 100px;
+ background: url(shadow.png) left bottom;
+ }
++This empty div is positioned to the lower left corner of .shadow-one, and its background +shows shadow.png's lower left corner. +
+
+.shadow-two {
+ background: url(shadow.png) right bottom;
+ }
++This div has only one purpose, to show shadow.png aligned into its lower right +corner. The padding on .shadow-one is exactly the same size as .corner-a and +.corner-b, so all three divs adjoin perfectly without overlaps, and so do the shadow +images they have as backgrounds. +
+
+.shadow-three {
+ position: relative;
+ left: -100px;
+ top: -100px;
+ background: url(shadow.png) left top;
+ }
++Relative positioning is used along with negative left and top +values to drag this div up and left by exactly the size of the corner divs. This shift +automatically places .shadow-three in precisely the spot needed to complete the four-sided drop shadow. +
++Again shadow.png is applied, but this time in the upper left corner of the div. +Now the four sided shadow is complete, but the current div is in the wrong location +for the content. Next we'll get that content into the correct spot. +
+
+.shadow-four {
+ position: relative;
+ left: 50px;
+ top: 50px;
+ }
++The innermost div in the group is relatively shifted down and to the right by exactly half of the corner div +size, placing it directly over the empty region within all those shadow images. Now any content elements within will +have nice all-around shadows that automatically adjust to any content size, as long as that size does not exceed +the size of shadow.png. +
++The intrinsic or stated width of the content will control the width of the entire div group as it shrinks +horizontally and vertically around that content. Note that rendered heights of divs are shrink-to-fit by default, +and the height of even irregular content like a text block won't be a problem once the width of that block +is controlled in some way. +
++In the event your doctype is "strict," any IMG elements will, by default, show a 3px space +below the image. This baseline space is meant to allow character descenders +(like the hook on a lowercase j) a space where they can show. To avoid the space, +just make sure the image is given display: block; and +no baseline space will be added. +
+ ++Just when we thought IE6 had no more surprises to reveal, along comes yet another type +of HTML comment bug to throw on the pile, and it has chosen to attack my baby, +the PNG Drop Shadow technique. +
++This time it's personal. +
+ +
+
++Discovered by one Judebert +(self-portrait to left), the "unpleasantness" has the effect of hashing-up the drop shadows when ordinary +HTML comments are inserted between certain of the starting div tags in the shadow group. Apparently the +presence of those comments is affecting or disrupting the relative positioning used in the technique. Nice catch, Judebert! +
+ ++Using hasLayout via the "zoomfix" on the divs will stop the bug, but then the shrink-to-fit +behavior is disabled, so that's no-go. The proper fix is obvious: Just don't use comments in +the div group like poor Judebert did and you'll be okay. +
+ ++In a production page it would be useful to separate out the background-image calls +from the rules for the divs and create a multiple selector rule that would apply the +background to all those divs at once. The background-position for each div would +be applied individually. This way you can change the shadow image by editing +just the path in a single background-image call rather than in four different places. +The live demo +employs that trick. +
+ ++Be aware that the live demo +has the background-position values set to hide all the backgrounds +off-screen, to be pulled into the divs when the outer div is hovered. That's really cool to look at, but it's not +required for the method to work. Therefore this discussion deals only with the basic method and doesn't +detail how to change BG positions during hover. Study the live demo code if you're curious about the way this is handled. +
+ ++By now you may have realized that this four-sides method is not confined only to shadows and glows. +Indeed, any reasonably clean frame-like image may be adapted to surround any arbitrary content box. +The image below has been "framed" via the method, incorporating both a solid visual element and a +drop shadow into a single displayed frame. +
+ ++Go ahead and hover the live demo below to resize the content image and div group, showing how +the frame/shadow automatically adjusts to fit the content size. +
+ +
+ +The method clips off the large BG image at some unknown spot that's different for each content dimension, +so for it to work well you need to stay away from some frame designs. It would not do to have a row of smiley faces, +only to have one of them get clipped right thru the middle! +
+ ++So there you are, a nice clean way to frame content that's bulletproof in all modern browsers +later than IE6, along with the potential to use hovering in a number of interesting ways. +Next time I'll discuss one of those ways in detail, but until then, enjoy! +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: April 12, 2010
+Created November 4, 2008
+
+ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++In 7 seconds you will be redirected to the PIE articles page, +Where you may follow the new link. If redirect fails, click here. +
+ ++In 7 seconds you will be redirected to the PIE articles page, +Where you may follow the new link. If redirect fails, click here. +
+ +
+Return to p.i.e.
+Return to Articles
+
+This page explains how to feed specially prepared CSS to Internet Explorer, primarily +to supply the "zoom fix" and confer +hasLayout +on an element. Making Internet Explorer think a certain box "has layout" can correct +most of the float-induced or list-related bugs found in that browser. This fix cannot be used globally +on all elements without causing major difficulties, but proper application of the fix is vital +if you want to do any really advanced CSS layouts, particularly if floats are used. +
+ ++Primarily we need to apply such fixes just so we can use floats and list elements without +major bug problems. Finding the elements that need the fix is a matter of trial and error +for the most part. Simply move the fix to different suspect elements until the bug goes away +(if you're lucky!). There is a method to IE's madness, but the details are invoved and ultimately +useless. Experimenting with the zoom fix is fast and usually effective. After using the fix on a few +pages you'll get a feel for the kind of elements that might benefit from hasLayout. +
+ ++Besides doing hasLayout fixes, we might also need to feed special +scripts to IE6 and lower for PNG support or any-element hovering, and possibly for modified +width or height values on some boxes for the benefit of IE5.5 and lower only, due to the different +way those old IE browsers handle CSS boxes when borders or paddings are used on the boxes. +
+ ++In order for the method to succeed, it's essential that it be employed on pages displaying in +"standards mode." +This is because a browser running in "quirks mode" will display the same way decade-old +browsers once did, to comply with backwards-compatibility for very old web pages. +
+ ++Besides the mode issue, it's important that you create your CSS layouts in a modern non-IE browser, +and then attempt to correct any issues that IE may have with your standards-based code. Do NOT +build sites while checking only in IE, or its many bugs and incorrect behaviors will lead to bad code +and many difficulties in other browsers. +
+ ++Place the following code block in the head section of every page to be IE-corrected. Be careful to +have this code block following the primary CSS file or calling link (the one that's read by all browsers), +or else the new IE-only rules may not be able to override the relevant main CSS rules. +For more info on the subject, see the +specificity section +in the W3C specs. +
+ +<head>
+
+ <link rel="stylesheet" type="text/css" href="myprimary.css" />
+
+ <!--[if IE]>
+ <link rel="stylesheet" type="text/css" href="myiehacks.css" />
+ <![endif]-->
+
+ <!--[if lte IE 6]>
+ <script type="text/javascript" src="myiescripts.js"></script>
+ <![endif]-->
+
+ <!--[if lt IE 6]>
+ <link rel="stylesheet" type="text/css" href="myiehacks-5.5.css" />
+ <![endif]-->
+
+</head>
+
++You can change the link calls or add more, but don't mess with the +Conditional Comments +unless you know what you're doing. +
+ ++The first CC feeds myiehacks.css to all versions of IE. +This file is used mainly to give any +hasLayout +fixing required for IE6. IE7 does have some +remaining bugs that require such fixing, but even if a given hasLayout bug occurs only in IE6 +and below the fix will not harm IE7 and so does not need to be hidden from IE7. Versions before +IE5.5 generally have the same hasLayout bugs as IE6. +
+ ++Generally this file will contain a "zoom" rule, shown below with examples of elements to be given +hasLayout. The zoom property is one of those that triggers hasLayout on a box in IE, but the +value "1" is equal to 100% of zoom so no zooming actually occurs. Only the hasLayout triggering +takes place. +
+ +.somebuggyelement,
+.somebuggyelement a,
+.colwrapper div {
+ zoom: 1;
+ }
+
+
++Whenever you discover an element that needs the fix for IE, just add it to the multiple selector, +making sure to separate it from the other selectors by a comma. Note: don't use a comma after the +last selector or strict browsers will properly ignore the entire rule! +
+ ++The second CC targets IE6 and below for any scripting calls such as the Suckerfish script +or the various PNG support scripts. These scripts force IE6 to emulate support for any-element +CSS hovering and semi-transparent PNG images. IE7 natively supports both those things, +thus IE7 need not see (and be slowed by) any such scripts unnecessarily. +
+ ++The third CC is targeted to IE5.5 and lower only. +myiehacks-5.5.css will contain any widths or heights for boxes +that don't display correctly due to the +Box Model Problem. +If you do not wish to support IE5.5 in this way you can simply delete the last conditional comment completely along with its link. +
+ ++ Be aware that IE5/Win does not support zoom and so can't be fixed by this method. If you must support + that browser, you can make a duplicate of the zoom rule within the last CC and change "zoom: 1;" + to "height: 1%;". This rule will harmlessly trigger hasLayout in IE5/Win, but it must not + be read by IE7 (or any other modern browser) or else big problems will occur. +
+ ++BTW, these CCs are bulletproof and immune to any future IE +browser changes. They will always perform exactly as advertised, +because they're a proprietary Microsoft feature, not some browser +flaw to be exploited. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 2, 2008
+Created: July 2, 2008
+
+and many other big sites. +In 7 seconds you will be redirected to the PIE articles page. +Go to the article "How To Attack An IE/Win Bug". +If redirect fails, click here. +
+ + + + + + + diff --git a/articles/ie7-dehacker.html b/articles/ie7-dehacker.html new file mode 100755 index 0000000..4112bdd --- /dev/null +++ b/articles/ie7-dehacker.html @@ -0,0 +1,668 @@ + + + + + + + + +
+Return to p.i.e.
+Return to Articles
+
+If you only want to know the quick and dirty way to feed rules to IE only, +go to this page which explains +one method to do so. +
+ ++In 2005 Microsoft started cleaning up a lot of its selector support problems, +but a lot of coders were using these IE problems to hack special rules for the +Explorer browser. In the long run the newly-supported CSS selectors will +make our jobs easier, but in the short run it mean rewriting stylesheets +and updating our IE-coddling methods so they don't explode in our faces. +
+ ++A number of CSS hacks that relied on IEwin's failure to support +certain advanced selectors are failing to "work" because IE7 now supports those selectors +and so reads CSS rules not intended for it. If this is you, read on... +
+ ++It's a simple fact that the majority browser (IE/Win) cannot be made +to handle complex CSS designs without the ability to induce +hasLayout +on certain buggy elements within those layouts. +The zoom fix +triggers hasLayout on a box and is utterly critical when it comes to taming IE's +many list and float bugs, and we would be greatly restricted in the choice of designs . +
+ ++However, aside from the zoom fix, it is possible to go entirely or almost hack-free +by intelligently working around IE's CSS failures. When we design our sites we try to make +the CSS as clean as possible, and only feed IEwin custom styles as a last resort, +and only when forced to do so by client requirements. Other modern browsers are held to +a higher standard and if problems do occur in them and can't be worked around, +we just shrug and assume the problem will be fixed eventually. Only when that +problem is a page-breaker will we go so far as to redesign the page. +
+ ++As we say, this is our design philosophy, and you are entitled to yours as well. +Anyway, let's get right into the heart of the issue, specifically the changes we can +expect from IE7, and new ways to handle old problems. +
+ ++Let's look at what we are told will be the relevant changes to IE7. There are two +CSS "combinators" that will become supported, and one element structure +will be eliminated. First the two CSS combinators: +
+ ++This selector uses a ">" symbol as a "combinator" that is +placed between two parts +of a CSS selector, and indicates that the target of the rule is the element on the +right side of the ">" combinator, but only when that element +is a direct child of the element to the left of the combinator. Thus, the +selector table>td can never target any element, because TD's +are never direct children of tables, only of TR's. On the other hand, +the selector tr>td would select every TD on the page, since +all TD's are direct children of TR's. +
+ ++The main difference between the Child combinator and the familiar space combinator +is that the space combinator is a "descendant" combinator, meaning that +the element to the right of the space only needs to be between the tags of the +element on the left to be selected. So with the selector +table td, all TD's will selected, since TD's always fall +between the tag pair of one table or another. +
+ ++The Child combinator is quite useful for targeting rules to direct children of +an element, without also targeting the more deeply nested descendants as well. +Unfortunately, up until IE7 there was no point in using it for its intended purpose, +since so few of the viewing public would get the benefits of the styling. +
+ ++It did however have a "useful" function in the writing of rules that IEwin would reliably +ignore, such as html>body .targetelement. It works because +the body is always a direct child of html, making that part of the selector true at all times. +Then the space combinator in front of .targetelement (or any other +selected element) allows the styles to be applied anywhere within the body element. +
+ ++IEwin just ignores the entire rule because it cannot recognize that child combinator. +Now that support is coming, IE7 will be able to view such hacked CSS. But since +that browser will still have quite a few failings, letting it get a look +at those hacks could be less than desirable, to say the least. +
+ ++This selector is a "+" combinator symbol placed between parts of a selector, and is very +similar to the Child combinator. The only difference between the two is that while +the Child combinator points to direct children of an element, the Adjacent Sibling combinator +points to an element which directly follows another element in the source. +
+ ++Thus the selector tr+td cannot select anything, because TD's never +directly follows a TR. Instead, TD's are contained inside TR's, and that +is not considered to be "following" the TR. However, the selector tr+tr +would select any TR that directly followed another TR, which means that every TR +within a table would be selected except for the very first TR in that table. +
++Get it? An adjacent sibling element not only follows its previous sibling, but is +also completely separate from it. Further, if two DIV's are in sequence and each +contains a paragraph, those two paragraphs are not considered siblings, because they +reside in different parent elements. The fact that one follows another means nothing +unless the following sibling starts at the same point where the previous sibling ends. +
+ ++It's possible to point a Sibling selector at any one of a sequence of adjacent +elements, simply by repeating the use of the combinator, so the selector +td+td+td would select all TD's that come directly after +two previous TD's. This also means that the the third, fourth, fifth, and any +remaining TD's in a table row would receive the styles attached to such a selector, +since they all have two TD's directly before them in the table row. +
+ ++The first two TD's in the next table row would not be selected, because they are +enclosed in a different TR. But then of course any remaining TD's in that row would +be selected, just as in the previous table row. +
+ ++Be aware that IE7 likes to count HTML comments as siblings, so if you start using this +combinator as intended then be sure to place comments inside the siblings, not on the outside +where they will fall between the siblings and be counted as one of them! Oy... +
+ ++Again, the Adjacent Sibling combinator will come in real handy for the future, but right now +there are CSS hacks out there that utilize it, much like the Child combinator. +Not good. +
+ ++Clearly we need to begin eliminating these hacks from our CSS files before +our clients start screaming bloody murder, not after. +
+ ++Oh, you want to know about that structural thing? Well, the hack that uses +it is called the star-html hack, and it works by taking advantage +of an oddity in Explorer's treatment of the Document Object Model, +or DOM for short. Simply stated, all web pages start with a root element +called html, which then contains two children, the head +and the body elements. Those two then contain other children, and so forth. +
+ ++Most browsers obey this arrangement, but Explorer for both +Win and Mac do not. +They seem to think there is a mysterious element enclosing the html element! +It's pretty strange, but in fact this extra outer "root" element has no apparent +ill effects on web pages, and remained unnoticed for years, until +Edwardson Tan +began experimenting with CSS selectors. He found that a selector written as +* html .targetelement would apply the styles to +.targetelement, but only for the IE browsers. +
+ ++Think about it. That star is the "universal" selector, so it points +to any element, but it comes before html. Therefore, +the full selector in effect says: "Select .targetelement when it +is contained within html, and when html is +contained within any other element". +
+ ++Obviously since html is the root element on the page, it cannot +be contained by any other element, but that's exactly what IE thinks! We don't +know the name of this element, but the star selector part of that hack does not care, +as long as there is such an element surrounding html. +
+ ++As you can imagine, this hack has proved quite useful, particularly when wrapped in +a different hack +that hides the star-html hack from IEmac. By doing that, you create a +combination hack which will feed rules directly to IEwin, and no other browser. +Such a combo hack is perfect for handling box model issues and anything else that +IEwin needs to see exclusively, particularly the Holly hack. +
++Sadly, Microsoft has seen fit for some reason to lose that strange "root" +element in IE7, leaving html as the correct root. That's very compliant of +them, but it presents a problem. Yep, just as with the newly supported combinators, +any pages that use this hack will start breaking in IE7, but this time it's because +IE7 will not be able to read those special rules it needs so badly. +
+ ++Happily for us, Microsoft also saw fit to develop a browser feature called +Conditional Comments +(back in the IE5win version). CC's allow coders to write an HTML comment in a way +that will "alert" IEwin, causing it to peek inside the CC +and parse what it finds there. Other browsers do not have this feature, and so +they see just a normal comment, ignoring it and all it contains. +
+ ++See where we are going with this? Those formerly useful (but now embarrassing) CSS +hacks in our stylesheets may be stripped out of the stylesheets and placed into a +separate stylesheet file. Then that new "IEwin hacks" CSS file may be called into +the page via a head link that has been +hidden within a conditional comment. All other browsers (even IEmac) will see a +normal comment and just pass over it to the following code. IEwin however will look +inside the CC, see the link, call the special hack-filled CSS file, and add those +rules to the cascade just like any other stylesheet. Sweet! Here's how it would look: +
+ +
+<!--[if IE]>
+<link rel="stylesheet" type="text/css" href="iehacks.css" />
+<![endif]-->
+
+Okay, it's not as convenient as the seductively useful star-html hack, but unlike +that hack, CC's are not going to go away, ever. Furthermore, CC's boast rock solid +reliability and safety. Not even the W3C Validator will know that the CC is anything +other than a normal comment, so the page will validate just fine, even if your hack +file is stuffed full of invalid proprietary MS rules. +
+ ++Of course we all understand that this CC enabled CSS file is for rules that will +make IEwin behave as close to the specs as possible, right? What's that? You really +want to use all those cool MS proprietary scrollbar stylings, do you? Well if you must, +at least this method will squirrel away those icky rules apart from the nice clean +CSS in the main sheet. That way, validation is assured. +
+ ++From reading +Mezzoblue's +blog comments we see that if one is using XSLT, the brackets contained within the +CC tags can cause trouble. Happily +Nick Fitzsimons also saw those comments, +and Nick has described for us how to go about +generating CC's via XSLT. +Thanks Nick! + + + +
+ ++Anyway, let's get right into the details of cleaning up a typical hack-ridden web +page, shall we? BTW, there's lots of pages just like that, right +here at PIE! Oh well... +
+ ++Rather than embarrassing anyone by exposing their hacks to public ridicule, we were going +to do one of our own pages, but it seems that none contain any hacks other than +the star-html hack. So instead we will show how to strip out hacks that might be +found in other real world web pages. +
+ ++All the discussion to follow assumes that IEwin is in "standards" mode, via a +correct doctype. +If IEwin is allowed to fall back to "quirks" mode +by an old, incorrect, or missing doctype, all bets are off, and the observed behaviors +might appear radically different. Microsoft has said that IEwin's future improvements +will depend on IE being in standards mode, and quirks mode will be left for sites that +must maintain lots of legacy code that would break if handled strictly according +to the standards. +
+ +
+#wrapper {
+ border: 10px solid black;
+ width: 770px; /* IE5.x/win sees this.. */
+ voice-family: "\"}\"";
+ voice-family: inherit;
+ width: 750px; /* ..but not this "standards" width value.. */
+ }
+
+html>body #wrapper {
+ width: 750px; /* ..or this reinforcement of the standards width. */
+}
+
+That's the well known +Tantek hack, +and it feeds a special width to IEwin versions before IE6 to combat the +box model problem, +and also gave Opera 5 a second hacked rule using the Child selector, because +that browser was also fooled by the primary Tantek hack just like the early IEwin's +were. All of this mess was superseded by the simpler star-html hack, but many web pages +still have the Tantek hack. The specific goal of the above example hack is to +create a wrapper box that is 770px wide when the 10px side borders are added on to +the stated 750px width. +
+ ++Technically this hack does not need to be stripped out, because the hack primarily works +via the use of escapes to hide certain critical characters from the early IE's. IE6, IE7, +and all other modern browsers are not fooled by these legal escapes, so nothing can +go wrong by letting IE7 see the hack. Not even the last part is dangerous, because +that Child hack simply feeds the "standards" width, which IE6 and IE7 are +already getting from the first part of the hack. If IE7 suddenly starts reading that +Child hack, it will get the correct value anyway. +
+ ++Still, as long as we are stripping dangerous hacks, let's remove that one as well. +Naturally the border rule and all other ordinary CSS rules are left within the main +CSS file, along with the "standards" compliant 750px width. Remember +that our CC enabled hacks.css file will be seen only by IEwin, +versions 5 and up, so no hacks to hide the file from IEmac are needed. +
+ ++It so happens that CC's come in several varieties that different versions of +IEwin will either read or ignore, depending on the code placed within the starting +tag of the conditional comment. See the +Microsoft page +for specifics, and +Taming Your Multiple IE Standalones +here at PIE for lots more details and useful tips on CC's. +
+ ++So you could create two different hack files, one that all IEwin versions can +see for general hacks, and another just for box model issues and whatever other +hacking might be needed specifically for IEwin versions prior to IE6: +
+ +
+<!--[if IE]>
+<link rel="stylesheet" type="text/css" href="iehacks.css" />
+<![endif]-->
+
+<!--[if IE 5]>
+<link rel="stylesheet" type="text/css" href="iehacks-5.css" />
+<![endif]-->
+
+By adding that "5" in the start tag, you are saying that only versions +of IEwin that begin with a 5 should read the CC. IE5.5's version does begin with +a 5, so it does read the CC along with IE5win. +
+ ++Once these files exist, it is a simple matter to segregate box model widths and +heights within the version 5 only file. This does avoid the need for any CSS +hacking at all, but of course there is one more special CSS file to deal +with, possibly increasing the chances of errors and difficulties in the future. +
+ ++When using this method, make sure that the links for the CC's come later than +the main CSS file link in the source, and that the rules within the CC's have at least the same +or higher +specificity +than any similar rules in the main sheet. If not, your +hacks will not override those primary rules for IEwin, and will fail to do their jobs. +Also be sure that if the two different CC linked CSS files have conflicting rules, +that the ordering and/or specificity is proper, or there could be trouble there too. +
+ ++Once stripped, the above hack is replaced in the iehacks.css +file with this code: +
+ +
+iehacks.css
+
+#wrapper {
+ width: 770px;
+ wid\th: 750px;
+}
+
+See that red-colored "escape" inside the second property name? It's a legal +'escape' backslash and should be ignored, but when it is inside the +property name it is not ignored by IE5 and IE5.5 +for Windows. Instead it causes those browsers to ignore the following "t" +character in this case, thus making the property name unreadable to them. So the result is that +all the IEwin versions get the widened width, and then IE6 and IE7 will see and +obey the second rule with the standards width. Just remember that the escape must +not come directly before any of the first six alphabetical characters, because they +have special meanings when preceeded by an escape. If we had written it as +"wi\dth", then IE6 and IE7 would ignore the "d" and see +"with" as the property name. Not good. Specifically the forbidden characters are +a, b, c, d, e, and f. +
+ ++Happily there is always at least one character inside every property that isn't one +of the first six, and so may be safely escaped this way. However, you can't escape +the "w" in "width", because IE5.5 is somehow able to ignore +the escape when it comes first. Keep the escape within the name and it will work every time. +Since IE5 and IE5.5 are the browsers that are fooled by the escape and are also the +ones with the box model problem, it's a perfect fit and won't cause trouble in the +future. +
+ ++These combinators when used as hacks are always meant to prevent IEwin +from seeing a rule that would cause it to break in some way. So when one appears +in a CSS file, it can't simply be removed without depriving the other browsers +of the styles within that rule. Yes, the Child hack portion of the selector can +be deleted, leaving a simple rule for IE7, but then older IEwin's would see it +and break. Somehow we need to simplify the rule without letting IEwin get a look at it. +
+ ++In fact, this is not actually possible, so instead we will let IEwin see the simple +unhacked rule, and then "negate" that rule from within the general CC, +where non-IEwin browsers won't be affected. +
+ ++One common use for the Child hack is to give IEwin a +height +while other browsers get only a +min-height. +Since IEwin will always +enlarge any dimension +when needed to keep content contained, a height is actually treated as a min-height by IEwin. +The important thing is not to let other browsers see the height meant for IEwin only. +Typically it is done this way: +
+ +
+#wrapper {
+ min-height: 500px; /* IEwin does not support min-height */
+ height: 500px;
+}
+
+html>body #wrapper {
+ height: auto;
+}
+
+This sets both a min-height and height to the same value, and then in the Child-hacked rule +where IEwin is not paying attention, the height is set back to the default auto. +Unfortunately IE7 will be able to read that second rule, and it so happens that IE7 +will still expand boxes just like earlier IEwin versions. This means that the +above rule will make IE7 also reset the height to auto, and so the desired min-height +"effect" will be lost in that browser. +
+ ++The answer here is to delete the Child hack and its auto value completely, +and then move the height declaration out of the first rule, sending it instead +to the iehacks.css file. IEwin still gets the length value for height that it needs, +and no other browsers are troubled by it. The problem is now solved, at least until +an IEwin version comes along that does not expand boxes improperly! +
+ ++Even then it is not a big problem, because CC's are so flexible. Let's say that +IE8 has arrived, and it has been redesigned so that it correctly obeys box +dimensions like other browsers. Hopefully such a radically different IE version +will also support min-height. But in any case, we will not want the height rule +meant for IE7 and lower versions to be seen by an IE8 that we have described. +It's also likely that many other things will be improved at the same +time, so there may be a sizable group of special IEwin rules that IE8 should not see. +Thus we would write our CC link call this way: +
+ +
+<!--[if lt IE 8]>
+<link rel="stylesheet" type="text/css" href="iehacks.css" />
+<![endif]-->
+
+See that "lt" in the tag code? It stands for "less than" IE8, +so IE8 would be excluded from reading this CC, and won't get the the linked stylesheet. +Depending on future realities within the IE browsers, various combinations of +CC's could be made to handle most anything. Still, let's hope MS does not cause +too many complications for us, eh? +
+ +
+There happens to be something called the
+Owen hack,
+which has the selector
+head:first-child+body {}. This hack was useful because it could not be read
+by Opera 6, while Op7 had no trouble with it. Nowadays few care about Op6, but the
+hack still lurks within a few stylesheets, and MS is warning against its continued
+use.
We know the sibling selector will be obeyed by IE7, but the Owen hack also
+contains "head:first-child." That is an advanced CSS
+pseudoclass
+which IEwin does not currently support, but this MS warning seems to intimate that
+:first-child and possibly other such selectors might be slated for
+support in IE7! True or not, this should be a clear indication that using any
+advanced selectors to exclude weak-but-evolving browsers may be counter productive.
+A word to the wise, eh?
+
+There's not too much left to say about this hack. It hides a rule from non-IE +browsers, but allows IEwin and IEmac to view the rule. IE7 will be excluded from +viewing the hack, so any such hacked rules that you think IE7 should see will need to be +moved into iehacks.css, or into a more specifically targeted CC linked stylesheet. +
+ ++The only wrinkle is with the IEmac browser. There may be the occasional hacked +rule that you want IEmac to see along with the IEwin browsers, but once the special rule +is stashed inside the CC, poor IEmac won't be able to access that file or the rules +it contains. The answer to this problem is something we call the Mac-only hack, +dreamed up by Tantek Çelik himself (who has been a Microsoft programmer +among many other things). It is the older +Mac hiding hack +with a new twist. It's constructed from a special pair of CSS comments, between which +you may place CSS rules that only IEmac will read. +Assuming that IEmac needs something unique such as a width on a normally widthless +float, you can write this into your main stylesheet: +
+ +
+/*\*//*/
+#floatedbox {width: 200px;}
+/* */
+
+You can find out how it works +here, but as for this +being an undesirable hack, don't worry about it. The hack depends entirely on a parsing +error in the IEmac engine, caused by the escape within the top comment. No browser +later than Nav 4 has any problem with this arrangement, and no future browser +will either. Furthermore, IEmac is no longer being developed by MS, so there is zero chance +of problems developing as we are seeing with IE7. Use it in good health! +
+ + + ++By now you should have a pretty good idea of what's coming at us soon. If your +code is shot thru with CSS hacks like ours, you have two options: Fix it now or +participate in a slow-motion train wreck. It's your choice. +
+ ++There's no point in chewing out Microsoft either. We have been screaming for years +that they should do what they are about to do. Okay, it would be nice for them to fix +all the bugs at the same time, but face it, that ain't gonna happen. MS is definitely +starting to take their issues seriously tho, and IE7 will be just the first step +toward a more compliant Explorer. If MS is willing to face lots of bad vibes in +order to approach full compliance, we prefer to see it as a good sign +for the future. +
+ ++Anyway, why not have a positive attitude? It can't hurt anything, and a lot less +stomach acid is produced as a result. That's our policy and we're stickin' to it! +
+ + + + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 4, 2008
+Created October 26, 2005
+
350px
One of the keys to success in liquid layouts is a complete set of tools for +precisely controlling a document's width, as viewed on the screen.
+ +Non-support in IE6 has rendered the CSS2
+min-width
+property useless for now (IE7 supports this property). However, with a few devious styles and some innocuous IE6-fixes,
+we can impose a natural minimum width on any element.
And as an added bonus, there's a new type of width governance-- a cross between +a fixed width and a percentage width.
+ + + +Most CSS properties that control spacing are about making an element smaller + +than it would otherwise have been. Margins, padding, and borders all shrink an +element inside its containing space. But negative margins are unique in +that they make an element larger than its parent.
+ +The narrowest an ordinary element can be is zero pixels wide. So if an element can be +expanded 700px wider than its parent element, that nested child element's +minimum possible width becomes 0px + 700px, or exactly 700px.
+ ++In other words, if the parent element is 0px wide and its child is always 700px +wider than its parent, that child element cannot ever be narrower than 700px. +When negative margins are applied to both sides of the widthless nested child, +the effect is to widen that child element in both directions, causing it to appear +wider than its parent! +
+ +
+Note that the outer element will typically be the body element in
+most production pages, so for this code example we'll give the outer div a
+
+
+id="bodydiv" as a substitute "body" element, and we'll call the
+outer element #expander, since its negative margins will be expanding
+its displayed width.
+
Here's some example markup upon which we'll apply the minimum-width effect, +via negative margins:
+ +<div id="bodydiv">
+ <div id="expander">
+ <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
+
+ </div>
+
+</div>
+Now we'll use those negative side margins to make #expander 700px
+wider than #bodydiv. This can be done all on one side of
+
+
+#expander, but to simplify centering we will split the total expansion
+and place half on each side of #expander. And so that we don't let
+those negative margins run the sides of #expander straight past the
+edges of the window, we'll apply the same 700px total as as left and
+right padding on #bodydiv. Here's the styles:
#bodydiv { padding: 0 350px 0 350px; }
+#expander { margin: 0 -350px 0 -350px; }Two divs, two styles. However, for IE to treat the negative margins properly, +several fixes must be applied:
+ +#expander must be position:relative,divs must be
+ zoom fixed to give IE hasLayout, and...div in between the pair, with a width of 100%.The first two problems are easily solved; the third is the more frustrating
+and confusing. But it seems that IE will not properly set the width of
+#expander to 700 pixels more than #bodydiv unless
+there's an in-between element with an explicit full width of 100%. So the final
+minimum-width code becomes:
<div id="bodydiv">
+
+ <div id="sizer"> <!-- new IE bugfixing div -->
+ <div id="expander">
+ <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
+
+ </div>
+
+ </div>
+
+</div>
+
+#bodydiv { padding: 0 350px 0 350px; }
+#sizer { width: 100%; }
+#expander { margin: 0 -350px 0 -350px; position: relative; }
+
+(in a separate IE-only stylesheet brought in from a conditional comment...)
+
+#bodydiv,
+#expander {
+ zoom: 1;
+ }
+
++The zoom fix shown above won't valicated because it's MS-proprietary +CSS, but inside a conditional comment only IE can ever read it, allowing validation. +
+ ++Safari will lose the negative side margins on #expander if the +Jello Mold is loaded into a window that is narrower than the sum of those margins, +so to fix this a simple min-width at that value is applied to #expander: +
+ +#expander { margin: 0 -350px 0 -350px; min-width: 700px; }+ +This just reinforces what Safari ought to be doing anyway, so it doesn't harm any +other browser, not even IE6, which ignores min-width anyway. +
+ +In the styles above, there's one very interesting number that just begs for
+attention. It's the 100% width on #sizer. If purely
+in the interest of science we should change that from 100% to 50%, what will happen?
That very change has been applied to this very page you are reading! Try re-sizing +your browser window by dragging it wider and narrower, and watch what happens to +the white content as compared to the side spaces.
+ +The content is showing a minimum width of 700 pixels (with a horizontal scrollbar
+at narrower window widths), and with the old #sizer width of 100%,
+the content would always fill the window at larger window sizes.
But what does the page do when #sizer is set to width:50%
+and the browser window is wider than 700 pixels?
May not sound like much, but check out the size of this at different widths:
+ +| Browser Width | Jello Width | Percentage | |
|---|---|---|---|
| 800px | (800 - 700) * 0.5 + 700 = | 750px | 94% |
| 1024px | (1024 - 700) * 0.5 + 700 = | 862px | 84% |
| 1280px | (1280 - 700) * 0.5 + 700 = | 990px | 77% |
| 1600px | (1600 - 700) * 0.5 + 700 = | 1150px | 72% |
| 2560px | (2560 - 700) * 0.5 + 700 = | 1630px | 64% |
At the page top you can see grey sides that are the 350px side body paddings,
+and between them is the green colored #sizer div, which is set to
+a width of 50%, making it stay at exactly half the width of the available space
+between the body paddings.
What's happening is that the percentage of the window occupied by the page
+content is large when the window is narrow, and that percentage shrinks as the
+window is widened. So not only is there a minimum width, but the page also expands
+horizontally at a slower rate than the window as a whole. You get to decide how
+quickly the percentage shrinks, simply by selecting different percentage widths
+on #sizer.
Normally a flexible layout such as this will need to be centered in the browser.
+This is done by applying side auto margins to #sizer.
+Here's the code:
<div id="bodydiv">
+ <div id="sizer">
+ <div id="expander">
+
+ <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
+ </div>
+
+ </div>
+</div>
+
+#bodydiv {
+ padding: 0 350px 0 350px;
+ text-align: center; /* centering hack for IE5.x/Win */
+ }
+#sizer {
+ width: 50%;
+ margin: 0 auto 0 auto; /* standard centering method */
+ text-align: left; /* resets centering hack to default */
+ }
+#expander {
+ margin: 0 -350px 0 -350px;
+ position: relative;
+ text-align: left;
+ }
+
+(in a separate IE-only stylesheet brought in from a conditional comment...)
+
+#bodydiv,
+#expander {
+ zoom: 1;
+ }
+
+
+The side auto margins on #sizer must always be equal, automatically
+centering #sizer in standards compliant browsers, including IE6.
+Previous IE/Win versions don't understand side auto margins, so we have to use
+a text-align hack on the outer element, which wrongly centers all content in those
+earlier IE's. Then that hack is reversed back to the default in #sizer
+
+so that we don't center all of the page's text.
As mentioned before, the body element will usually be the outer
+element, rather than a div like #bodydiv.
IE becomes confused with internal percentages. Often you
+will want percentage sized floated columns in your layout, as is the case in this
+page. Their widths are defined as a percentage of #expander, their
+direct parent element.
Unfortunately, for IE to get this correct it needs to have a parent element
+with an explicit width, not a weird one derived of negative margin
+wizardry. So in this page and the bare-bones demo, there's a fourth div
+nested inside #expander whose only purpose is to be width:100%.
+This inner wrapper fills #expander, and is itself width defined,
+so any internal columns will have a clean width reference to calculate against.
If no nested elements need percentage widths, this inner wrapper won't be necessary. +However, if coders who come after you don't understand this bug, it could get nasty +for them so you might want to have this div just in case. Also since it's a full +wrapper, you can always use it as a graphical hook.
+ +Screens will keep on getting bigger and users will keep on maximizing their browsers.
+At some point there does need to be a constraint put on content width. For most
+modern browsers, a maximum width may be declared using max-width.
+As with min-width, however, it is unsupported in IE.
However, IE does support a non-standard method by which any property's +value may be expressed as a snippet of Javascript. IE5/Mac didn't incorporate this, +so it gets left in the cold. But for everyone else, the following code imposes a maximum width +of 1000px on the white content area.
+ +#sizer {
+ width: 50%;
+ margin: 0 auto 0 auto;
+ max-width: 300px; /* 1000 - 700 = 300 */
+ width:expression(document.body.clientWidth > 1300 ? "300px" : "50%" );
+ }In the interests of validation, the expression and the zoom fix should be wrapped
+in a conditional comment.
+This hides it from better browsers, and from the validator. Unfortunately, IE5/Mac
+never implemented conditional comments, so there's no known way to impose a maximum
+width effect on IE5/mac without involving fully-fledged Javascript. Here's what it
+looks like with the comment:
<style type="text/css">
+
+#sizer {
+ width: 50%;
+ margin: 0 auto 0 auto;
+ max-width: 300px; /* 1000 - 700 = 300 */
+}
+</style>
+
+<!--[if IE]>
+ <style type="text/css">
+ #sizer {
+ width:expression(document.body.clientWidth > 1300 ? "300px" : "50%" );
+ }
+
+#bodydiv,
+#expander {
+ zoom: 1;
+ }
+
+ </style>
+
+<![endif]-->The expression gets the window width and checks it against the leading value of 1300px
+to see if the window is wider than that. If true, the first value after the question
+mark (300px) gets applied as the #sizer width, and if false, the
+second value (50%) is applied instead. The 300px value is found by subtracting the
+700px negative margin total from 1300px to get 600px, then multiplying by 50%,
+arriving at 300px for the "true" value.
The maximum width in this case has been used simply as a safeguard to protect the +readability of your site on very wide screens (in excess of 1300 pixels). Depending on +your design, you'll need to play with the minimum and maximum width controls that the +Jello technique offers. But that's the beauty of it-- you can!
+ + +A sample Jello Mold codeset, at its bare-bones minimum: here
+ +The exact 700px/50% combination on this page produces the widths shown +in the table above. But if you'd like a different set of values, the +Jello Generator can help you find the exact pair you want.
+ + +The Jello Mold all about control. You control your maximum and +minimum widths, you control exactly what width you're showing at +the resolutions in between. This opens up the door to flexible designs of +a sort that are simply not possible without such precision. No more +worrying if your floats break up on those very wide and very narrow +screens.
+ +Of course, this is a pretty new technique. We've been careful about +checking it out, but keep your eyes open for those scary bugs lurking +where no one has seen them yet. And if you do find something odd, let us +know!
+ +
+Return to Articles.
+Return to p.i.e.
+
+ +The Jello Mold wrapper concept is courtesy of Mike Purvis +
+ + + ++If you have done a few liquid and rigid CSS layouts, you will be all too aware +of their limitations. A rigid layout is great for maintaining text line lengths +and artistic appearance, but as resolutions keep growing larger these layouts +show embarrassing side spaces more and more. +
+ ++Liquid layouts have their own problems in the wide screens, stretching both text +lines and designs beyond belief in some cases. Besides the obvious, Explorer for Windows +can also have very nasty bugs in liquid layouts when rigid content that shares space +with floats happens to "lock up" the page width. When that happens, the bad old 3px bug +induces content dropping, and the only cure is to use min-width to stop the shrinkage +before lockup happens. +
+ ++Unfortunately, IE does not support min-width as well as it supports the 3px bug, +so a JavaScript is then needed to coerce compliance in IE. It's a big pain in the +you know where. +
+ ++IE7 now supports min-width and max-width and no longer has the +3px bug, woohoo! +
+ ++What if it were possible to create a layout that was not fully rigid, nor fully +liquid, but at some selectable point in between? Further, what if this method +also featured a "natural" min-width you could set, without need for scripting? +Is this too much to ask for? Nope, it is now reality, thanks to another of those +young geniuses, +Mike Purvis. +Trust us folks, minds don't get any more devious than Mike's. +
+ ++The +Jello Piefecta +has several interesting features that can be seen if you narrow and widen the window. +Yes the center is now liquid, but notice that the outer content edge seems to be +fluid, but if the window is narrow enough it will fill the viewport. If it is +made narrower it generates a horizontal scrollbar similar to a min-width on the +body element. +
+ ++But this effect works in IEwin, and there is no scripting! Now widen out the +window, and while the page also widens, the rate at which it widens is less +than the window. This rate, and the point where min-width stops the narrowing +are both fully controllable. +
+ ++What you are seeing is the Jello Mold, as described by Mike himself +here at PIE, and a superb +invention it is, too. We have taken a new liquid center col version of the Piefecta +and inserted it into the Jello Mold, with spectacular results. Three cols, +source ordered, any col longest, every area tilable, rigid side cols and liquid +center col, and with a nice balance between a rigid and a liquid outer wrapper. +To top it off, a max-width for those who insist that their text lines not be stretched +halfway to Alpha Centauri. +
+ +
+It works in all modern browsers, except that IEmac does not do +the max-width trick, since it does not support either the CSS rule or the +proprietary MS expression used to cover IEwin. (For a script-free layout, just +omit the max-width expression for IEwin). IE7 natively supports max-width +and does not need this expression. In fact the entire method could be dispensed with +if IE6 were not around, so when it's finally gone you can just use the min-max widths +and a percentage width on a single wrapper and be done with it. Won't that be nice? +
+ ++In IEwin, If any element preceeding the column group has text +(such as the header), and +narrowing the screen causes that text to wrap down to an extra line, it will bump +the col group down as well. This causes IEwin to somehow "forget" the negative +margining on the left column, causing it to cover the center col. +
+ ++Happily any further resizing or refreshing will restore the col margin. This means that +the bug can only be an issue if a user manually narrows the window to the exact critical +header wrap dimension, and not one pixel less. Since this is extremely unlikely, +it's really a non-issue. +
+ ++Safari has a strange issue with the negative margins on #expander, +the div that has large negative side margins. +In that browser, if the Jello Mold is loaded into a window that is already narrower +than the natural min-width, #expander is displayed as having no width at all, +resulting in a classic "train wreck". You don't want to know. The answer is +to assign a real min-width equalling the sum of the negative side margins on #expander, +to #expander. End of problem. Kudos to +Steven Luscher for +discovering the bug and helping to test out the fix. +
+ ++There is an IEmac bug in designs that use negative margined columns +that makes the left col links vanish on hover. This bug can be killed via +a:hover {position:relative;}, applied only on hover. The IEmac fix +is courtesy of +Emmanuel Delaborde. +
+ ++The right col 1px rounding errors are an inherent problem with Gecko (now totally suppressed +in Firefox 3, yay!), which is perhaps a bit too strict when calculating the +rendered dimensions of percentage defined elements. You can see the errors in the right col +and also on the right side of the center col, but only at some window widths. Other browsers +have rounding errors too, but not in this layout. +
+ ++Aditionally, it's possible for the bottom border on the wrapper to lose 1px of width, +altho this does not always happen. +See our Rounding Errors demo for more info. +
+ ++If you do not try to use visible elements that span the full width of this col or +touch the right edge of the center col, the errors will pass unnoticed, as with this paragraph. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 4, 2008
+Created July 18, 2005
+
+A Guest Article by Manfred Staudinger +
+ ++Most of the improvements in conditional comments talked about in this article +have now been incorporated into an easy-to-install set of IE standalone versions +available at +Tredosoft.com. We recommend +this install very highly, so enjoy! +
+ ++Multiple versions of Explorer for Windows on a single computer have revolutionized +CSS bug testing for websites, but sadly the different IE browser windows appear +identical to the eye, potentially leading to confusion and testing mistakes. Also, +Microsoft's proprietary Conditional Comments +don't operate properly on these standalones, making advanced usage of CC's a guessing game. +These problems have now been resolved! But first, a little background regarding the standalones. +
+ ++When Joe Maddalone first came up with + +Multiple Version of IE in Windows XP Pro in November 2003, this was a great +relief for web developers. Technically speaking, it was made possible by using a +system feature which may be functionally described as a process specific +subroutine library, for otherwise system wide shared .dll and .com modules. It is +supported by the system scheduler from Win98 SE onwards and is triggered by an +empty file with the name process.exe.local. +
+ ++For Windows to allow several Explorer versions running side by side on one machine, +this process specific subroutine library, in short + process library , +must contain the starting module +for the process (iexplore.exe), the trigger (iexplore.exe.local), +and any required process specific dll's. For more details, see Joe Maddalone's +consolidated info: Multiple +IEs in Windows. +
+ ++Get the conveniently prepared standalones themselves +here. +
+ ++Multiple Standalone Installer Now Availible! (Oct '06) +We no longer must manually install and modify the IE Standalones, because +Yousif Al Saif of tredosoft.com +has compiled IE3 thru IE6, along with all title markers and registry fixes, into +a single easy installer package. It even comes with special files to keep PNG +scripts working in IE6 for proper testing. Wow. Install IE7 from MS first, then go +here for instructions. +Way to go, Yousif!
+ ++One question bothers me: If Win98 SE (and the feature in question) was available +as early as April 1999, why did the feature I refer to as the + process library +took more than 4 years to surface? In my opinion, it's partially because the Windows OS +is lacking any concise description, and also because Microsoft seems to have obscured it +by using at least three different names to designate this feature: + +Isolated Components, + +DLL/COM Redirection, and + +Side-by-side approach for implementing private DLLs. +
+ ++The last one is to be found in The End of DLL Hell (Rick Anderson, +Microsoft, January 2000). Anderson also mentions "using a unique version number" for +implementing private DLLs, a different approach which was called later on + +Side-by-side Component Sharing, contributing still further to the confusion! +
+ ++Anyway, we now have standalones for each version of Explorer back to version 4, and that's +great, but they can be made even better. +
+ ++To enhance the usability of multiple IE's further, I would like to demonstrate 3 changes +for versions IE 5.01, IE 5.5, and IE 6: +
+ ++Although this is the simplest of the three modifications here, it took a long time to surface. +To the best of my knowledge it was M. Cain, who in May 2005 proposed +it for the first time and it was brought to my attention by David Wilson +only recently. It is done by adding a backlevel module to each + process library . +
+ ++First download the file 3725.exe from Microsoft. You will find the page easily by searching +for its FamilyID which is "6DEE32AB-B618-4FB3-9A45-CDD08162E167". The file +description denotes it as "Win32 Cabinet Self-Extractor", but it should not (and will not apply +anyway) be applied to your system. +
+ ++Instead use WinZip (or an equivalent tool) and it will show you 7 files which are contained in +3725.exe. From these choose Wininet.dll to be extracted and put it into the folders of your IE +standalones. This very same Wininet.dll (version 5.0.2614.3400, date April 14, 1999) applies +to all of the standalones. +
+ ++That's it - enjoy testing with cookies! +
+ +
+To achieve Modification #2 two things have to be done:
+1. checking and possibly changing a registry string, and
+2. adding a modified module to each process library
+
+If the registry string in question, Window Title, exists in your registry, +it will cause all your different Internet Explorer versions to display +the same character string on the title bar. This character string comes from the +Window Title string and its default value is, you guessed it, +"Microsoft Internet Explorer". For some background information you may want to read + +How to Change the Internet Explorer Window Title on the Microsoft site. +
+ ++In order to check for the Window Title string's existence, click the +Start button, click Run, and type in "regedit.exe". +This launches the registry editor, where you may then navigate to the Main +key. It will be found under HKCU\Software\Microsoft\Internet Explorer\ +where "HKCU" may be read as "HKEY_CURRENT_USER". +
+ ++Once in Main, look carefully for a string called Window +Title, and if there is one, right click it, and rename it to zWindow +Title. +
+ ++To enable the Version Labels for your IE 4.01 Standalone (for the +hint I wish to thank Derek Ahmedzai), the procedure is very similar. This time you start with +"HKLM", which means "HKEY_LOCAL_MACHINE", go for +HKLM\Software\Microsoft\Internet Explorer\Main and again look for +the Window Title string. +
+ ++If there is none, right click Main, select "New", choose "String Value" +for the data type, and rename the resulting "New Value #1" to Window Title. +
+ ++Now you have a Window Title string anyway, right click it, and select +"Modify". When the "Edit String" menue pops up, you can set the value data to "IE 4.01 +(Microsoft Internet Explorer)" and click "OK". That's all you need for IE 4.01 ! +
+ ++Follow these instructions exactly to the letter, as for sure, the Registry Database is not +designed for the "trial and error" approach. If you would like to change something on your +own, you should at least have read and understood the + +Description of the Microsoft Windows registry beforehand. +
+ ++To finally enable the Version Labels for your IE 5.01, IE 5.5, and IE 6.0 +Standalone, it is also necessary to add a specially modified module (BROWSELC.DLL) to the + process library . The modification consists +in replacing the string "Microsoft Internet Explorer" (which appears in the title bar) by "IE 5.01 +(Microsoft Internet Explorer)", "IE 5.5 (Microsoft Internet Explorer)" and "IE 6.0 (Microsoft +Internet Explorer)" respectively. Once those .DLL's are in place, the browser window top bar +will proudly announce what IE version it is, dispelling all confusion. +
+ ++The discussion assumes you have IE 7 as your primary or native browser and IE 6 is a +Standalone version. Should you have IE 6 as the primary Explorer browser, leave it +untouched, the lack of a version label in the title bar will indicate that it is IE 6 anyway. +
+ ++To download the .DLL's, right click the links below, select "Save target as", and save into the folder +that contains the IEXPLORE.EXE file for each of the standalones. +In other words, those .DLL's are each specific to either IE 5.01, IE 5.5 or IE 6.0, and each must +share the same folder with the primary .EXE file for each standalone browser version. All three +DLL's have the same name (BROWSELC.DLL), so don't put them in the same +folder at any time! +
+ + + ++For details on the subject, go straight to the source and read +About +Conditional Comments on the Microsoft site. Some say that using this proprietary feature is +a bad practice because CC's are non-standard, but basically it's just code that has been stuffed +within an HTML comment, a comment internally labeled so that various IE versions may reach into +that comment and pull out parsable code. If all browsers had something similar, bug fixing would +be a whole lot more feasable in Opera and Mozilla. +
+ ++Further, CC's do validate because to the validator and non-IE/Win browsers, a CC looks like a +normal HTML comment and thus is ignored. +
+ ++Most of the conditional comment behaviors may be restored to the standalones by performing +a simple one time edit to your registry. It consists only of renaming a particular key, +which currently says IE, so that it says zIE. +
+ ++To do this, click the Start button, click Run, and +type in "regedit.exe". This launches the registry editor, where you may then navigate to +the desired registry key. The target key, called IE, may be found under +HKLM\Software\Microsoft\Internet Explorer\Version Vector\. +In some Windows versions the "HKLM" may appear as "HKEY_LOCAL_MACHINE" +
+ ++Once in Version Vector, look for the key called IE, +right click it, and rename it to zIE. +
+ ++(If you are running a 64-bit version of Windows, I would like to get in touch with you, +to figure out the correct procedure for changing the key. A "registry reflector" copies +values forth and back between the above mentioned key and +HKLM\Software\Wow6432Node\Microsoft\Internet Explorer\Version Vector\, +which is used for 32-bit applications running on a 64-bit machine). +
+ ++The next time Internet Explorer is started, the missing IE key will +cause it to fetch needed information from other modules, where at least 4 slightly different +character strings (containing version, subversion, build etc.) are available. The information +found there will enable the standalones to function almost perfectly when presented with +Conditional Comments. If you want to restore your OS to the previous registry state and +browser behavior, simply rename the zIE key back to IE +and restart Internet Explorer. +
+ ++If you have never altered your registry before, be assured it is not dangerous, provided you +follow these instructions exactly to the letter!. But, should you allow temptation to take +control, and you rashly make other edits, Neither I nor Position Is Everything are responsible for +what might happen! +
+ ++With the four different Internet Explorers (IE 5.01, IE 5.5, IE 6 and IE 7.0) we have a total of 27 +different expressions (plus 22 negations) that may be used within a Conditional Comment, all of +which will work reliably after the registry modification. These "expressions" within the Conditional +Comments normally determine which Explorer versions will look inside the CC for parsable code. +It is this functionality you have just restored. +
+ ++To test your registry edit for correct behavior, run a test using +the Internet Explorer of your choice, and you will get either true or false for each of the 27 CC +expressions. The true/false patterns from +these tests (simplified screenshots) are what you will see on the live test page. +
+ +
+
+If you install IE 7, this is the pattern what you should see for it and also for all your
+IE Standalone browsers if you haven't applied the registry change. Thus to be able to
+tailor unique styles for all your IE versions, you have to make the registry
+change.
+
+
This
+shows the pattern from the test with IE 6: if you have installed IE 7, you will get
+this only after the registry change. - But in case you don't have IE 7, this will be the picture
+for all your IE versions, and again it is vital to edit the registry for applying unique styles
+to them.
+
+
+All of the results from the IE 5.5 Standalone are now correct, thanks to a valuable hint
+from Thierry Koblentz at TJKDesign:
+simply replace "IE 5.5" by "IE 5.5000" in the expressions and it works!
+
+
+The registry change restores the correct results from IE 5.01.
+
+When you start up an Internet Explorer 5+, it goes to the registry and reads all of the +Version Vector into an array to keep it in memory. This is done +only once at the time of initialisation. If IE later on encounters the characters +" <!--[if " while processing a +web-page, it recognizes a so-called downlevel-hidden CC (the +term "downlevel" was coined by MS in the times of the "browser wars" and denotes any +non-MS browser as well as IE 4 and earlier). It will take the character string +IE (or whatever you wrote instead) from the CC and search the +Version Vector array for a match (not case sensitive). For example, if you code: +
+ +
+<!--[if zIE]> ... <![endif]-->
+<!--[if zIE 6.0]> ... <![endif]-->
+
+the result will be "true" in both cases, independent from the version of IE you +run, if you followed the procedure above to the letter, "false" otherwise. But you +could easily have substituted your name rather than zIE to create a +personalized Conditional Comment! +
+ ++The point of changing the registry key IE to zIE is simply that if the Internet Explorer does +not find the IE key in the Version Vector, +then it creates such an entry in the version vector array by using version information from the +modules as a substitute, such enabling the use of CC's. +
+ ++Apart from the dowlevel-hidden CC's, which many people find awful anyway, MS also +invented the downlevel-revealed Conditional Comment: + <![if IE]> ... + <![endif]> . It does not only +look ugly, it doesn't even validate! I would not have mentioned it here, if not +John Lascurettes came up with a solution, +where he used a downlevel-revealed CC inside a downlevel-hidden one. +
+ ++This construct validates and enables us, to select certain combinations +of IE's for which there is no solution with a single downlevel-hidden CC (see "Selecting IE's" +below). But the solution is much more powerful, when considered in detail. Most importantly, +you can hide html from any or from a selection of IE's. For example +
+<!--[if IE]><![if gt IE 6]><![endif]-->
+ html
+<!--[if IE]><![endif]><![endif]-->
+The html here will be selected by any +browser except IE 6, IE 5.5 and IE 5.01. In this group you will find all +browsers (including IE 7 and IE 5.2) which are capable of processing advanced css selectors. +Furthermore, even the html is inside a +downlevel-revealed CC, it is truly html (so it may contain comments) and not just a funny +looking comment. In other words, the non-standard area is restricted to contain only the +selection mechanism for IE, but no html. +
+ ++For a working webpage we would like to complement the above by a more familiar +looking downlevel-hidden CC, selecting IE 6, IE 5.5 and IE 5.01 +
+<!--[if lte IE 6]> html <![endif]-->
+ ++If you want to apply a browser-side +transformation to insert CC's into your html , +then the first part of the example given above can be directly translated into XSLT: +
<xsl:comment><![CDATA[[if IE]><![if gt IE 6]><![endif]]]></xsl:comment>
+ html
+<xsl:comment><![CDATA[[if IE]><![endif]><![endif]]]></xsl:comment>
+Here html may be any valid +XSLT including literal result elements and even comments! Now the second part +can be constructed along the same lines, because XSLT supports the + system-property function. So we again +use a downlevel-revealed inside a downlevel-hidden CC, wrapped in a XSLT + if-clause . +
<xsl:if test="system-property('xsl:vendor') = 'Microsoft'">
+<xsl:comment><![CDATA[[if IE]><![if lte IE 6]><![endif]]]></xsl:comment>
+ html
+<xsl:comment><![CDATA[[if IE]><![endif]><![endif]]]></xsl:comment>
+</xsl:if>
+In case the CC's are inserted with server-side +XSLT, the first part remains unchanged. But the second part changes, because in +absence of the system-property function +we have to accept a html look alike or pseudo-html: +
<xsl:comment><![CDATA[[if lte IE 6]>
+ pseudo-html
+<![endif]]]></xsl:comment>
+Finaly we can select any of the 16 different combinations of the four Internet Explorers, +ranging from none to all. Some of the expressions are called less specific +here, because they will also select future browsers with versions greater than 7.0. +
+ ++The following terms are defined as: +
+ ++To specify which versions will read the CC, the following arrangements may be employed: +
+ +<!--[if IE]><![if !IE]><![endif]--> html <!--[if IE]><![endif]><![endif]-->
<!--[if IE 5.0]> html <![endif]-->
<!--[if !IE 5.0]> html <![endif]-->
<!--[if IE 5.5000]> html <![endif]-->
<!--[if !IE 5.5000]> html <![endif]-->
<!--[if IE 6]> html <![endif]-->
<!--[if !IE 6]> html <![endif]-->
<!--[if IE 7.0]> html <![endif]-->
<!--[if lte IE 6]> html <![endif]-->
<!--[if IE 5]> html <![endif]-->
<!--[if !IE 5]> html <![endif]-->
<!--[if lte IE 6]><![if !IE 5.5000]> html <![endif]><![endif]-->
<!--[if !IE 6]><![if !IE 5.5000]> html <![endif]><![endif]-->
<!--[if lte IE 6]><![if gte IE 5.5000]> html <![endif]><![endif]-->
<!--[if !IE 6]><![if gt IE 5.0]> html <![endif]><![endif]-->
<!--[if lte IE 7.0]> html <![endif]-->
+You may have noticed the symmetry between (2) and (3), and also between (6) and (7): +The expressions for the former are negated for the later. Even more redundancy can +be seen, because "gt xx" converts directly to "!lte xx", and "lt xx" converts directly +to "!gte xx". +
+ +
+
+Manfred Staudinger
+e-mail: Manfred.Staudinger@gmail.com
+Last updated: July 4, 2008
+Created Febuary 4, 2005
+
+and many other big sites.
+Return to Articles
+Return to p.i.e.
+
+We originally wrote this article for the +css-d wiki, +the repository of all things CSS that get hashed out on the +css-discuss list. + +
+ ++CSS bugs can be obscenely difficult to isolate, especially when they are located +amidst a large, complex page with many external style sheets. Compounding +this is the fact that few coders have enough experience to be sure that what +they're seeing really IS a bug, and not just incorrect coding. +
++Often people will, when facing the Mystery Bug, just thrash about almost blindly, +and only by pure luck will the answer be found. This need not be. +
++By following the proceedure below, a clear understanding of the problem may be +quickly obtained, freeing the coder to find a workaround or avoid the bug altogether. +
+ ++Too often this step is not performed, which is a shame because the majority of Mystery Bugs +are simply due to typos and basic code errors. Luckily, online validation tools +(html, css) +are available. +These engines will expose outright validation errors, and will also give validation warnings +about code that might possibly cause viewing problems due to conflicts with user stylesheets +and the like. But beware; they have been known on occasion to throw errors for seemingly +valid code. This is quite rare, though. +
+ ++If all the CSS for the page is contained within the source document, or if it is all within a single +external .css file, go on to the next step. Otherwise, it's best to embed the relevant CSS into a +single document. +
++Note: Make sure you have safe copies of all documents +before you start, not after it's too late. +
++After cutting each external link, save, and view the page. If a link is removed and the bug +disappears, paste that .css file in the link location. If the link is cut and the bug stays, move +on to the next link. In the case of a <link>, the newly embedded CSS must be enclosed with +<style></style> tags. Important: Each external .css file must be placed in the same location +as the link that called for it. +
++When there are no more external sheets, and the bug is still present, it's time for the real work to begin. +
+ ++The object here is to cut large sections of code, save the file, and check to see if the bug is gone +or not. If the bug is gone, paste that section back in, and cut the next section. Obviously, if the +bug is still there, do not paste back that section, but move on to the next. This method is applied +to both the CSS and the HTML. Which one gets done first is up to you. +
++An alternative method is to surround code sections with comment tags. This makes it easier +to recover if you somehow 'lose' the bug, but the source stays cluttered. It's also not as +fast as the first method. Still, some people prefer to comment out blocks of code in a source +to do tests, sources are often shot thru with comments and nesting comments is strictly forbidden! +If you don't know why, give it a try. However, CSS can be used to achieve the same effect +without running afoul of the comment nesting problem. +
+ ++If you want to temporarily remove a block of content and there happens to be a +convenient element wrapper for that block, just add style="display: none;" +to the start tag of that element. If there is no such surrounding element to use, +or if it happens to be a crucial strucural element, you can instead add your own +DIV that surrounds the content to be removed and use style="display: none;" +on that DIV. In effect such a DIV amounts to a "comment" that may harmlessly +enclose other real HTML comments without any difficulties. +
+ ++The DIV/comment idea is courtesy of +Francky. +Thanks Francky! +
+ ++Be aware of any CSS that is 'inline' within the HTML, and treat these the same as the +embedded CSS. If you cut an inline style rule, and the bug is affected, paste it into the +head within the appropriate rule, and after the other properties in that rule. This should +prevent any alteration of the cascade. Don't forget to view the page, just to be sure. +
++Remember, the goal here is to keep the bug present, while removing or hiding as much of the code +as possible. As you go along, the portions that can be removed will get smaller and smaller. +Switch back and forth between the HTML and CSS, and don't stop until there is not one +single bit of code that can be removed without losing the bug. +
+ ++At this point the bug page is called a 'minimal test case'. You may by now have worked out the +problem and gone bye bye, but if not, step back and take a good long look at the code, and the +page. Here's where code knowledge, analytical skills, and keen observation pay off. You could +'play' with the code, or go to a good knowledge base like the +W3C, or a bit of both. However +it's done, by the time it IS done you will have learned, guaranteed. +
++As a last resort, there's always the +css-discuss list. +Any bug that can survive this treatment +and keep laughing, will draw such as us like sharks to the chum. And not having to paw +thru a huge set of documents is really nice, take our word for it. +
+ ++Bugs sometimes come along in flurries, and deconstructing each one can be rather +time consuming. Once you have developed some skill in bug hunting you may +prefer to try your luck stalking bugs on a full-scale problem page. +
+ ++Certain techniques are well known. Putting backgrounds or borders on elements to +highlight where they are actually located, and zeroing margins and padding +to reveal the cause of strange gaps. Many issues arise over the incorrect usage of +heights on elements, and weird width issues can be even trickier +to detect. +
+ ++We can't explain such advanced methods in detail because every situation is +different. Just approach each bug with an open mind and don't assume that the most +obvious suspect is necessarily the cause of the bug. Very often your problem will +be the result of obscure parts of the code, working together behind the scenes to +throw up a nasty bug that seems to come from nowhere. These are the toughest bugs to +defeat, and the only possible way you can do so is to be smarter than they are. +As a last resort you may always resort to the minimal test case method, which +will usually expose even the worst deep-cover bugs with ease. +
+ + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: December 20, 2006
+Created Groundhog Day (Feb 2nd), 2003
+
A method for keeping columns (or more precisely, blocks of elements [note]) logically ordered in the source while still providing the designer the ability to display them in any order whatsoever without the need for any additional non-semantic markup.
+ + +
Browsers that do not make use of the CSS positioning information will present the content in the order that it is marked up. Consequently the ordering of content in the source code is important as far as accessibilty [note] and assistive technologies are concerned. [note]
+The overriding rationale behind CSS is the separation of content and style - the removal of non-semantic cruft and complete ordering flexibility theoretically allows for repurposing of content without the need for tweaking html.
+Although this might be less useful for an individual's site where markup can be altered to accomodate design changes, this is a huge win for systems based on templates where changing the html is either impossible or undesirable.
+Furthermore it promises even greater customisability of a site for individual users. For instance, side columns could be swapped over or even placed on the the same side (though whether this would be a good idea or not is debatable).
+Search engine spiders/robots read web pages like this - they start at the top left, read across, and then move down. Consequently the ordering of content on a page is important as far as search engine algorithms are concerned. [note]
+ +Through the magic of floats and (when necessary) negative margins. Each block is floated in the following way:
+margin-leftIf we want the column blocks of our layout to be the same width and ordered 2-1-3, the maths work out like this:
+ +| + | leftmost point | +rightmost point | +margin-left | +
|---|---|---|---|
| Block 1 | +33% | +N/A | +33 - 0 = 33% | +
| Block 2 | +0% | +67% (Block 1) | +0 - 67 = -67% | +
| Block 3 | +67% | +67% (Block 1) | +67 - 67 = 0% | +
So given this HTML markup...
+<div id="block_1"> + ... +</div> +<div id="block_2"> + ... +</div> +<div id="block_3"> + ... +</div>+ +
... we apply the following CSS:
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+
+Units can be percentages if the layout is liquid, ems or pixels if fixed width. [note] [note]
+ +Of course not. It never is, is it? This method runs head first into a peculiarity in the layout engine of IE Win (5 and 6) - if block 1 is not the first column, it requires its margin-left to be divided by 2.
+Investigating further, we find that the bug is triggered for any block n (where n is the position of the block within the source code) if:
+ +Under such circumstances element n will require its margin-left to be reduced - the overall number of columns appears to be irrelevant.
+Keen readers will have noticed and been chomping at the bit to point out that this is the dreaded IE Doubled Float-Margin Bug. Well spotted. The good news is that the usual fix works just fine.
+All that is required is display: inline targeted at IE for the element in question. It's only the first such block in the source ordering that needs this "hand holding" and once the fix is in, it magically sorts out any following elements which would otherwise need the fix.
So in the code example, block 1 is to appear as column 2 and triggers the bug, since its column position is equal to 2 times its source position [note]. Consequently we need to add the following CSS:
+* html #block_1
+ {
+ display: inline;
+ }
+Example of the basic Any Order technique (2-1-3 ordering) [note]
+So it's very nearly that simple. Or rather it is that simple. It's actually possible to simply set all the column elements to display: inline (as far as IE is concerned) without any unfortunate side effects and without any need to work out whether any of the column blocks need the hand-holding or not. [note]
As things stand in the example, there's no wrapper/container element holding the columns together. More often than not, you're going to want or probably even need one. Most likely, if you want to apply a faux-columns style background to the columns (or utilise the techniques developed later in this article), there's the not-so trivial matter of making sure that the container expands to fully contain the columns. And so the simple method sketched out so far becomes a little messier again.
+Over the years, several non-cruft-introducing methods have been invented to deal with this. Unfortunately though, the overflow: hidden method causes everything to just blow up. And a bug in Firefox/Mozilla means that you can't use the simple floated container method, if, but only if, the longest column has actually been negatively shifted. That's a pretty big if, though. Using display:table works fine for a pure any order solution, but I've not used it here because it runs into trouble later on.
Fortunately, the original (and still the best ;) EasyClearingTM works just fine, if somewhat more verbosely than the alternatives.
+Example of the Any Order technique with containing element (2-1-3 ordering)
+The method even holds up if you want to use direction: rtl. In that case you just switch right for left in the column float and margin declarations.
Example of the Any Order technique as a right-to-left layout
+This method is, being a float-based method, prone to the usual float method problems. Because IE (both Win and Mac) violates the specs and expands elements to be at least the width of the largest nested element, things can get funky. This means that unexpectedly wide images or long unbroken strings of text will cause havoc with the layout.
+NB. these problems are intrinsic to any float techniques in IE, and are not caused by the use of negativity itself, but because elements are being negatively shifted, an unexpected float wrap could cause some of those elements to be placed beyond the left edge of the viewport. Consequently, particular care should be taken with the following issues:
+Other likely IE problems can be found at Position Is Everything's Explorer exposed! and Windows Explorer vs. the Standards. See also On having layout, the extremely thorough dissection of IE's layout engine quirks.
+ + +IE Win 7 beta 2, IE Win 6, IE Win 5.5, IE Win 5.01, IE Mac 5, Operas 7, 8 and 9, Firefox 1.5 [note] and 1.0, Netscape 8, Safari 1.03 (and up), OmniWeb 5
+ +If the longest block has been negatively shifted under any circumstances (either directly or indirectly, so that it displays before any block that precedes it in the source order), its height is ignored. Instead Netscape treats as longest the longest block that has not been negatively shifted. This can cause any following elements to not be cleared correctly. Apart from that massive stumbling block, it works just great.
+This technique does not work in Opera 6 or Netscape 4. As is. That's right, it's possible to even make it work in those browsers if you really want to. That's so insane though, that I'm putting the details of how in this appendix.
+Opera 5 is another matter - the blocks never become columns, stretching to fill the width of the container and stacking up on top of each other just as if they were regular unfloated blocks. Except that the column background colours don't show up. Well, if you must support Opera 5...
+IE 4? I've got no idea. I can't get it to run on any of the Windows machines I've got access to. I don't imagine that it will behave very well though. Or in IEs 2 or 3. Or Netscape 2 or 3.
+ +The method is both robust and generic. It allows for proper logical source ordering with the flexibility to layout in pretty much any manner. [note]
+However, it is certainly true that the columns can shift a pixel or two when percentages are used. If you can guarantee the longest column, the Ordered Absolute method gives more precision for percent-specified layouts.
+And if you can bear a bit of javascript, Absolutely Positive, Shaun Inman's routine for "clearing" absolutely positioned elements, offers a potentially much more powerful method for achieving all this and more.
+Tom Wright's CSS Negative Margins Algebra is another CSS-plus-negatively- margined-float approach that's more than worth a look. While perhaps not being as generic as this method, it does allow you to completely remove any interdependence between the positional CSS and the underlying semantics.
+The original Source Ordered Columns [note] goes a long way towards satisfying the same issues that the Any Order technique does, but it requires a semantically unnecessary inner wrapping tag to group some of the columns together. This reliance on an inner wrapping tag also limits the number of possible column orderings. Removing the need for the inner wrapper allows all possible orderings to be achieved (though the inner wrapper can serve other purposes. See Appendix H for the theory of possible orderings.
+It would be criminal not to mention Ryan Brill's Creating Liquid Layouts with Negative Margins, Thierry Koblentz's neat riff on Ryan's original 3 columns fluid layout, Doug Livingstone's CSS Columns and Position is Everything's Piefecta
+All these methods provide a way for mixing pixel widths in liquid layouts. A variation on the basic Any Order technique which can achieve the same results can be found here.
+Because the web never sleeps...
+Eric Meyer had a brainwave in the middle of a workshop and came up with Multi-Unit Any-Order Columns which does exactly what it says on the tin.
+Matthew Levine went questing for a better way to mix pixel widths into liquid layouts in In Search of the Holy Grail.
+ + +Now that we have the freedom to put our columns in any old order, let's move on to that perennial CSS favourite, how to make them the same height.
+ + + + + + +float: right instead (simply switch right and left in the previous instructions). Moreover, left and right floats could be combined. This would have the advantage of ensuring that the left and rightmost floated elements line up with the edge of the wrapper div and also potentially reduce the number of elements requiring negative margins (depending, of course, on just how many columns are required and how they need to be ordered).column positions 1 to n-1 are occupied by blocks 1 to n-1 (in any order). The answer is that actually the "real" formula is
column positions 0 to n-1 are occupied by blocks 0 to n-1 (in any order) where ghost block 0 always fills ghost column slot 0. But that's a little confusing, isn't it?position: relative on #footer to prevent wayward painting of its background colour.display: inline to all the blocks and not having to bother thinking about any of this.When first working on the Any Order Columns method, I spent an entire evening barking up the wrong garden path trying to figure out a crack-fuelled formula that would cope with IE's margin shifting problems. However, as John Gallant pointed out to me, it was just the IE Doubled Float-Margin Bug. Without Big John pointing out what now seems hilariously obvious in hindsight, I would have abandoned the whole exercise since my hacked-up approximations would never have done for "real world" usage. He also, as always, provided much encouragement and useful advice.
+As noted in the course of the article, the Equal Height Columns method was actually invented by Mark Challoner and posted to [css-d] in November 2004. Strangely that announcement passed by with barely a murmur. Possibly it was because there were still some issues with the technique (though usually that spurs [css-d] into action). Mark and I continued to bash away at the technique until it was polished into pretty much the form you see here. Indeed, it was Mark's crucial insight that led me to embark on this whole mad crusade.
+Thanks also to Ingo Chao, Bob Easton, Zöe Gillenwater, Eric Meyer, Gunlaug Sørtun, Ryan Thrash and Philippe Wittenbergh for help and comments at various stages of this article's development.
+ +Massive thanks to the Mozilla team for fixing the negatively-margined float bug in record time and getting the fix into Firefox 1.5.
+Thanks also to: Andrey Petrov for reporting and suggesting fix for IE6 bug in basic demo; Donna Casey for reporting the crazy text scroll problem that Firefox 1.0 has with the Nested Rounded example and Ingo Chao for coming up with a simplified test case and fix for it; Andrew Soderberg for pointing out the printing problems in IE; Bill Wallace and Chris W Parker for suggesting moving #footer's clear:both into the core css and out of the ancillary css file; Rob Cochrane for spurring me on to add support for direction:rtl; Philippe Wittenbergh (again) for creating copious test cases and pointing out the Opera 9 overflow:hidden behaviour change was for passing the Acid 2 test; Ingo Chao (that man again) for half slaying the anchor problems in Geckos.
In chronological order, the following reported the problems with links to anchors with equal height columns: Leevi Graham, Bryan Buchs, Vitaly, Xavier Guilbert, Justin Watt, Micah Wylde, Thoreau Lovell, Trevor Creech, Neil Drumm, Sebastiaan van Achterbergh, Vince Bishop, joey3xRoadRunner, Michael Hickland, Jakub Wojtaszczyk, Eric Everman, Jennifer Hiller, Franck Bossy, Jörn Hofer, Keisuke Omi, Stefan Schlachter, Jesse Scott, Christopher M Kelly, Ischa Gast and Kevin White.
+ + + + ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +Philippe Wittenbergh suggested a possible workaround for the Gecko 1.8b2 bug - and what do you know, it's the basis for a whole new alternative way of doing any order columns. Up to a point.
+ +Each column is still floated, but we:
+position: relativeleft for margin-left. The value of left for block n is worked out so:
+The following CSS gives us our standard 2-1-3 ordering:
+#block_1
+ {
+ position: relative;
+ float: left;
+ width: 34%;
+ left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ position: relative;
+ float: left;
+ width: 33%;
+ left: -34%;
+ }
+#block_3
+ {
+ position: relative;
+ float: left;
+ width: 33%;
+ }
+
+Interactive example of the alternative Any Order technique
+ +This works fine in modern browsers with the equal height method, but because of the position: relative applied to the columns, it can never be souped up to be used as the underlying chassis for the vertical grid.
Of course, if you don't have any need for vertical grid-style positioning, then it will do just fine.
+ +Unfortunately it doesn't work in IE Win 5.01 or 5.5. And adding equal heights into the mix makes IE Win 6 lose the plot. Moreover IE Mac 5 pays no attention to the left declarations. And the same goes for Safari 1.03.
On the other hand it works in all Netscapes back to 6.1 (and gets round the longest column problem that occurs in some of them) and all versions of Opera back to 7.0. - feed the 'original' Any Order technique to all versions of IE and you've got the best of both worlds. Forgive me for leaving that for someone else to implement...
+ +| Browser | +Any Order | +Equal Heights | +
|---|---|---|
| IE Win 6 | +pass | +fail [note] | +
| IE Win 5.5 | +fail [note] | +fail [note] | +
| IE Win 5.01 | +fail [note] | +fail [note] | +
| IE Mac 5.2 | +fail [note] | +fail | +
| Firefox 1.5 | +pass | +pass | +
| Firefox 1.0 | +pass | +pass | +
| Netscape 8.0 | +pass | +pass | +
| Netscape 7.2, 7.1, 7.0 | +pass | +pass | +
| Netscape 6.2, 6.1 | +pass | +pass | +
| Netscape 6.0 | +fail [note] | +fail | +
| Netscape 4.7 | +fail [note] | +fail [note] | +
| Netscape 4.04 | +fail [note] | +fail | +
| Opera 8.0, 8.5 | +pass | +pass | +
| Opera 7.5, 7.2, 7.1, 7.0 | +pass | +pass | +
| Opera 6 | +pass | +fail [note] | +
| Opera 5 | +fail [note] | +fail | +
| Safari 2.0, 1.3 | +pass | +pass | +
| Safari 1.03 | +fail [note] | +fail [note] | +
| OmniWeb 5.0.1 | +pass | +pass | +
| iCab 3.0 beta | +pass | +pass | +
| IE Win 6.0 | +|
|---|---|
| Equal Heights | +
+ The |
+
| IE Win 5.5, 5.01 | +|
| Any Order | +
+ Shifted elements are incorrectly positioned + |
+
| Equal Heights | +
+ Given the problems with the any ordering, the results are not pretty + |
+
| IE Mac 5.2 | +|
| Any Order | +
+ The |
+
| Netscape 6.0 | +|
| Any Order | +
+ Columns simply stack up on top of each other and no background colour is painted + |
+
| Netscape 4.7 | +|
| Any Order | +
+ Background colours not painted but the positioning is preserved. +Float clearing would need additional markup cruft. + |
+
| Equal Heights | +
+ Columns vanish. + |
+
| Netscape 4.04 | +|
| Any Order | +
+ Background colours not painted and columns just stack. + |
+
| Opera 6 | +|
| Equal Heights | +
+ There's a rendering display problem (which is more sever in the Mac than the Win version) that causes the columns to be painted overlong. The "usual" fixes of clicking back and forward or switching to another app and back again don't work, but scrolling up and down make's everything magically ok! + |
+
| Opera 5 | +|
| Any Order | +
+ Background colours not painted and columns just stack. + |
+
| Safari 1.03 | +|
| Any Order | +
+ The |
+
| Equal Heights | +
+ The |
+
If you can guarantee the height of elements within a block, you can, within reason, reorder them vertically.
+ +The following example is far from definitive - not least because even the modern browsers can't begin to agree on how to behave. But just to give a flavoursome idea of what's possible and to remind me (or someone else) to properly investigate and see who's right and who's wrong [note], here goes...
+ +Semi-interactive example of vertically shifting blocks
+ +Now elements within the main content or changing lists of links would probably be too unpredictable to monkey around with in any case (as well as there being no sane reason why you would want to), but chunks like navigation and site identity have no business appearing in the source before the real content and, unless their height is that unpredictable, could easily be catered for.
+ +For instance, but much more realistically than the examples linked to, a theoretical element, say #site_identity, could be last in the source and still rise to the top:
body
+ {
+ margin-top: 4em;
+ }
+#site_identity
+ {
+ position: absolute:
+ top: 0;
+ height: 4em;
+ }
+
+There are other ways this kitty could be skinned, but if you don't do something along these lines in this day and age, you're committing a layout crime ;)
+ + + + ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +Several issues have been discovered since publication which, depending on your requirements, can cause severe problems when using the equal height technique.
+ +Linking to an anchor in any of the columns within the element that has been set to overflow: hidden causes the content of that column to shift upwards. In IE and Firefox, that is.
+Example of anchors in the equal height method
+ie. it's not the large padding that's casuing the problem (though obviously it is the trigger of the behaviour)
+ +IEs 6 and under are easy. Simply suppress the overflow: hidden on the containing wrapper element.
IE7b thought doesn't work since overflow:visible makes the overflow of the columns, well, visible. So we use an expression instead, making the columns the height of the column container.
However, there are dragons here...
+So if you don't like those dragons, you might prefer to force IE7 into Quirks mode. [note]
+ +...or rather, there appears to be no fix for Gecko-based agents. I had thought shifting the padding and negative margin to the top (like for the Opera 8 fix) would sort things out, but once Gecko knows that the box is larger than what's displayed the anchor shifting occurs.
+ +Half fix for anchor problem in Gecko
+ +Ingo Chao has come up with a solution that works as long as certain conditions are met - the trick is to apply position:absolute to the target.
For anchors of the form <a name="target"></a>, this presents no problems. If the target element can stand being absolutely positioned, everything will be ok. Obviously though, attempts to apply the same technique to an anchor which is actually an id on an element enveloping content will result in dismal failure. And for many off-the-peg blogs and CMSes, that's probably going to be the case.
Furthermore, the parent element of the target must not have position:relative applied to it, which also somewhat reduces the usefullness of the technique.
Weirdly, just to add spice to the whole over-egged pudding, when used in equal heights mode, Opera 9 doesn't shift. But with the following reduced test case, it does.
+ +Two distinct behaviours can be seen in the previous reduced testcase.
+The question is, are current Geckos, IE and Opera 9 correct in their handling of the above example? What do the specs say?
+ ++ +This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region.
+ +
So does that mean that the content can be scrolled (though no interface should be provided) which is what Firefox and IE are doing, or does it mean that no scrolling should occur? But how would the latter jive with scrolling the content via scripting (which is surely meant to be allowed)?
+ +Sorry. Not fair. It's a bogus question. In the words of the editor of the CSS specs, Ian Hickson, "The spec doesn't define what happens with anchors." So, let's play detective and figure out when (and hopefully why) the behaviour changed in Mozilla and Opera.
+ +For Opera, the answer is fairly easy to track down thanks to a note in the changes log, under the heading "Acid2 Fixes"...
+ ++ +Elements with
overflow:hidden;can scroll to anchors within them.
...which was done presumably (remember the specs say nothing about how an agent should handle anchors) because unless they scrolled to the anchor on the test page, nothing would show at all and so they would fail the test at the first hurdle.
+ +Safari has taken a different route to passing the test - by making the html element scrollable when overflow property is set to hidden, but not doing so for any other element.
+ +Of course there's nothing to say which of these paths (if either) is correct.
+There's nothing in the Acid2 guide reference that mentions testing for such behaviour and the only comment about the use of overflow:hidden; on the html element is:
/* page setup */
+ html { font: 12px sans-serif;
+ margin: 0; padding: 0; overflow: hidden;
+ /* hides scrollbars on viewport, see 11.1.1:3 */
+...which leads us back to that section of the CSS specs which, er, has nothing to say about the treatment of anchors.
+ +So how did the test get into Acid 2? What is its purpose? Fortunately a little bird was able to tell me that Ian Hickson was the lead in constructing the Acid2 test. So I asked him why it was set up that way, with the content hidden and being scrolled to, and whether this was an intentional part of the test, or it just happened that way because that's how Mozilla and IE handled it
+ +++ + +Hmm. I didn't think about how anchors interacted with the overflow:hidden +text and just assumed it would work. :-)
+The reason I used overflow:hidden at all was to test make one of the browsers implement overflow:hidden on the root element, because authors were complaining it wasn't supported (I don't remember which one any more, probably Opera). Also, I needed to have scrolling to test fixed positioning, but I didn't want to show the scrollbar.
+via personal correspondence
+
Incredibly dull downloading of many many copies of old versions, followed up by combing through the bug tracking system eventually gave up the point where Mozilla had begun to scroll overflow:hidden, which in turn pointed to bug 221140 which gets us towards the heart of the matter.
+ +++ +The basic problem here is that 'scroll' and 'auto' have never worked on table +cells, and the working group decided to make 'hidden' work like 'scroll' and +'auto', so now 'hidden' doesn't work either.
+Bug 221140 - 'overflow: hidden' on table cells broken, comment #4
+
Of course, the question of exactly what and where the working group had decided is moot. Let's have another look at our old friend 11.1.1, the overflow:hidden definition (remembering that it says nothing about how user agents should deal with anchors):
+ ++ +This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region.
+ +
Previously the same section had been:
+ ++ +This value indicates that the content is clipped and that no scrolling mechanism should be provided to view the content outside the clipping region; users will not have access to clipped content. The size and shape of the clipping region is specified by the 'clip' property.
+ +
Do these changes to 2.1 mean that Behaviour A is correct and were they introduced for exactly such a situation?
+Prodding Ian Hickson again, I got the following explanation:
+ + +++ + +It was changed in issue 1-16, around July-September 2003. But it was made +in response to an W3c-internal-only comment, so that won't help you...
+... I imagine the reasoning was "to make CSS compatible with the Web", which already behaved that way.
+... It was probably more "browsers won't change their behaviour to match the spec because doing so would break Web pages, so we'll change the spec to match the browsers instead". (This reasoning is the thinking behind much of the changes to CSS2.1. Pragmatism is an important factor in the development of the CSS2.1 and HTML5 specifications.)
+via personal correspondence
+
So to sum up, the situation is happenstance yet quasi-official. That's how IE did it, so the W3 working group and Mozilla followed suit. And Opera followed along later to pass a test that reflected that status quo.
+ +Consequently there's nothing to say that Safari's divergent behaviour (scroll on html element, no scroll on any other) isn't correct. Or what the behaviour should be if a box that overflow: hidden is applied to is tall enough to show all the content within it, but there is additional padding-bottom beneath it...
And Bug 259615 - 'overflow: hidden' elements shouldn't be scrollable by the user probably shouldn't really be a bug. But Bug 325942 shows that some of the Mozilla team think it should.
+ +Sorry, I don't have any recommendations. Really. It's up to you to decide what works for you, just like you should decide what browsers you should support. That said:
+If you can't guarantee the absence of anchors, then you're probably going to be better off going with faux columns or a javascript-based solution.
+Of course, if Mozilla supported multiple background images this would all be irrelevant... Or if Mozilla could apply position: absolute to generated content properly...
Drag to select content within the longest column and keep dragging downwards - if the bottom of column is above the bottom of the viewport there is no problem. If it's below the bottom of the viewport then it keeps scrolling, shunting the content of all the columns upwards and very rapidly at that so that in all likelihood it just vanishes. (It is possible to scroll it back if some of the content is still visible and selectable - but that's an academic point since in reality the average user is going to be just as foobarred as if all the content had dissapeared)
+Fixed as of Firefox 1.5 and Camino 1.0, so this is basically a non-issue.
+ +A less serious problem (unless you're being bitten by it) is that it can cause printing problems for IE. Depending on the exact values used for padding-bottom and margin-bottom, the content in the columns can shift upwards and even disappear entirely. The answer to this problem is to suppress the negative margin-bottom (and consequently the padding-bottom too) in a print style sheet. You shouldn't be printing the backgrounds in any case ;)
+ + +So, the end result may be that the actual usefulness of the equal heights technique is in exposing flaws in certain rendering engines (whether it's Safari and Opera or Explorer and Gecko that get it wrong I leave for others to decide).
+ +Fortunately for me, it's the technique that I'm least concerned about since there's always Faux Columns to fall back on. And even more fortunately I covered myself in the article by saying that Faux Columns would probably remain the weapon of choice ;)
+ + + + +| Browser | +Shifts on anchor trigger | +Scrolls on select drag | +
|---|---|---|
| Firefox 1.5 | +Yes | +No | +
| Firefox 1.07 +NS 7.2 |
+Yes | +Yes | +
| IE 6 | +Yes | +No | +
| IE 5.01 (+ 5.5 ?) | +Yes | +No | +
| Opera 9b | +Yes | +No | +
| Opera 8.5, 8.0, 7.54, 7.23, 7.1, 6.06, 5.11 | +No | +No | +
| Safari 2.0, 1.03 | +No | +No | +
| iCab 3.01 | +No | +No | +
| IE 5.23 (Mac) | +No | +No | +
| NS 7.1, 6.23, 6.1 | +No | +No | +
For browsers which exist for different platforms, the results are the same unless expliclty mentioned.
+ +| Browser | +Nested Rounded Corners | +Boxes | +Borders | +
|---|---|---|---|
| IE Win 7 beta2 | +Pass | +Pass | +Pass | +IE Win 6.0 | +Pass | +Pass | +Pass [note] | + +
| IE Win 5.5 | +Pass | +Pass | +Pass [note] | +
| IE Win 5.01 | +Fail (mild) [note] | +Fail (moderate) [note] | +Pass (?) [note] | +
| IE Mac 5.2 | +Fail [note] | +Fail (mild) [note] | +Fail (mild) [note] | +
| Firefox 1.5 | +Pass [note] | +Pass | +Pass | +
| Firefox 1.0 | +Pass [note] | +Pass [note] | +Pass | +
| Netscape 8.0 | +Pass | +Pass | +Pass | +
| Netscape 7.2, 7.1 | +Pass [note] | +Pass | +Pass | +
| Netscape 7.0 | +Fail (mild) [note] | +Fail (mild) [note] | +Pass | +
| Netscape 6.2 | +Fail [note] | +Fail (moderate) [note] | +Fail (severe) [note] | +
| Opera 9.0 (beta) | +Pass | +Fail (moderate) [note] | +Pass [note] | +
| Opera 8.5, 8.0 | +Pass | +Pass [note] | +Pass | +
| Opera 7.5 | +Pass | +Pass [note] | +Pass | +
| Opera 7.2 | +Fail (mild) [note] | +Pass [note] | +Fail (mild) [note] | +
| Opera 7.1 | +Fail (mild) [note] | +Pass [note] | +Fail (severe) [note] | +
| Opera 6.0 | +Fail (severe) [note] | +Fail (severe) [note] | +Fail (severe) [note] | +
| Safari 2, 1.3, 1.2 | +Pass | +Pass | +Pass | +
| Safari 1.0 | +Pass | +Pass | +Fail (mild) [note] | +
| iCab 3.0beta | +pass | +pass | +pass | +
| IE Win 6.0, 5.5 | +|
|---|---|
| Borders | +
+ Bizarrely needs adjustment to cater for slight but unexplained right-hand corner background shift + |
+
| IE Win 5.01 | +|
| Rounded | +
+ Fails to extend all the boxes to quite the absolute height required + |
+
| Boxes | +
+ Extends side borders to bottom of page and truncates #block_3d though not its contents. On scrolling, the extended borders vanish which means it's probably |
+
| Borders | +
+ Basic hacks allow nice degradation that maintains the decorative elements while forgoing the correct stretching of the bottom boxes. Without those hacks the columns simply vanish, presumably due to some |
+
| IE Mac 5.2 | +|
| Rounded | +
+ Since it can't really cope with the snaps or corners it degrades positionally well enough, apart from div 9 which wraps underneath - nothing to do with the wrapping container since giving it extra space does not help. + |
+
| Boxes | +
+ Degrades nicely and as expected. + |
+
| Borders | +
+ Degrades nicely and as expected though requiring same background shifting as IE Win 6.0 + |
+
| Firefox 1.5b1, Camino 1.0a1 | +|
| All | +
+ Float positioning when negative margins are around is bust in the beta versions and release candidate 1. + |
+
| Firefox 1.0 | +|
| All methods | +
+ Also tested and passes in Firefox 0.8 and Mozillas 1.4, 1.5 and 1.6 + |
+
| Rounded | +
+ The presence of a relatively positioned element within any of the blocks causes weird scrolling effects when trying to select text. This bug has been fixed in 1.5, but just so you know. Details in this [css-d] thread. + |
+
| Netscape 7.2, 7.1 | +|
| All methods | +
+ Strangely enough since I really would have expected these to fail + |
+
| Netscape 7.0 | +|
| Rounded | +
+ Bottom right corner and snap inset upwards and leftwards. +Mild failure, and probably hackable for working solutions. +Following a machine crash, I no longer have a copy of Netscape 7.0 and cannot track one down, so this might no longer be true - but who cares? + |
+
| Boxes | +
+ Extremely close, but bottom bg painting extends beyond the borders of the bottom-most boxes + |
+
| Netscape 6.2 | +|
| Rounded | +
+ Much the same as Netscape 7.0 + |
+
| Boxes | +
+ Much the same as Netscape 7.0 but not quite as close + |
+
| Borders | +
+ An utter mess + |
+
| Opera 9.0 (beta) | +|
| Boxes | +
+ Final boxes only painted as far as bottom of verticallt aligned elements leaving ghostly space above bottommost border for each column. + |
+
| Borders | +
+ To get Opera 9 and 8 to play together at the same time requires some mundane if verbally spectacular and verbose hackery. Of course, you could just drop support for Opera 8... + |
+
| Opera 8.5, 8.0 | +|
| Boxes | +
+ Weirdness going on when setting margin and padding, along with ems. Gets it basically right but the leftmost column is shunted rightwards and needs explicit surgery to rectify things - which causes reload side-effect oddness in IEs. + |
+
| Opera 7.54 | +|
| Boxes | +
+ As with Opera 8 + |
+
| Opera 7.23 | +|
| Rounded | +
+ Top left rounded corners dissappear + |
+
| Boxes | +
+ As with Opera 8 + |
+
| Borders | +
+ As with Opera 8 + |
+
| Opera 7.10 | +|
| Rounded | +
+ As with Opera 7.23 + |
+
| Boxes | +
+ Bizarre! No overlong scrolling page! + |
+
| Borders | +
+ Bottom boxes overly extended + |
+
| Opera 6.06 | +|
| Rounded | +
+ Block 1 disappears, most snaps vanish, bottom corners vanish or incorrectly placed + |
+
| Boxes | +
+ Block 3 covers the central column (Block 1), snaps and bottom borders all over the place + |
+
| Borders | +
+ Block 3 covers the central column (Block 1), snaps and borders not shifted to bottom. +Potentially hackable to degrade nicely à la IE Mac 5... + |
+
| Safari 1.0.3 | +|
| Borders | +
+ Top borders not drawn correctly + |
+
+ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +We should be able to take the Any Order Columns technique, apply the relevant amount of margin-left and right to the main block and then neg the side columns into position. Something like this:
#block_1
+ {
+ float: left;
+ margin-left: 15em;
+ margin-right: 200px;
+ }
+#block_2
+ {
+ float: left;
+ margin-left: -100%;
+ width: 15em;
+ }
+#block_3
+ {
+ float: left;
+ margin-left: -200px;
+ width: 200px;
+ }
+
+
+In theory that's great, but it only actually works in Safari. To make it work (after a fashion) in IE, Firefox and Opera requires expressions and other odd difficult to fathom kludges.
+ +The solution is a wrapping element. The nice thing though, is it only has to wrap the first block. The wrapping element is 100% wide and floated. Now we can apply those left and right margins on the first block to get it into place and the negging can proceed.
+ + + +Some of the different scenarios need slightly different handling - but it's still a very simple technique.
+ +How different? Well the quirks are:
+ +Explorer needs the central column shifted over by the width of the left column, otherwise it buts up flat on the very left. Fortunately setting position: relative and its left value to the width of the left column does the job.
#block_3 needs to be floated right (in all the other cases, all the floats are in the same direction so this is the closest there is to a gotcha) Explorer overdoes the -100% negging and just requires a negative margin that is the same as its width
+ + +IEs 5.01, 5.5, 6.0 on the PC, Firefox 1, Operas 8, 7 (.02 though .54), and the latest Safari.
+ +Netscape 7.2 fails to clear the footer properly.
+ +IE5 on the mac gets a horizontal scroll bar that extends to where the width of the page would be if the neg-floated elements had actually floated to the right of the main column. But it does work, so it's just an unfortunate side effect as far as I'm concerned.
+ +Opera 6 works, apart from 1-2-3 and its mirror 3-2-1. Not that it matters ;) However, it looks as if judicious Opera hacking could overcome this.
+ +Unsurprisingly, Opera 5 doesn't display the columns as columns at all.
+ +I presume that as with the non-fixed width ancillary columns, that this technique is a) nestable, b) possible with additional columns and c) amenable to the Equal Height Columns method.
+However, because I personally have no use for this type of layout, I have not tested these presumptions.
+ +Of course, another problem with not having a wrapper element around the first block, is that, since it is floated but has no explicit width, the block will only be as wide as its content makes it. If there's not enough content to expand the block to fill the available space, the margin-right will not reach the right hand edge of the viewport and the rest of the positioning will be out of wack.
Now we could assume that there will always be enough content to expand things just so, or we could do something like:
+ +
+#block_1:after
+ {
+ content: '.';
+ display: block;
+ float: left;
+ width: 100%;
+ height: 0;
+ overflow: hidden;
+ visibility: hidden;
+ }
+Nice try, but only Opera really gets it. Safari and Mozilla prefer something along these lines:
+
+#block_1:after
+ {
+ content: '. . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .';
+ display: block;
+ height: 0;
+ overflow: hidden;
+ visibility: hidden;
+ }
+
+But Opera hates it with a passion. A solution could be fashioned out of this material, but really, until browsers get their act together, the additional wrapper is just so much less of a drag...
+ + + +For browsers which exist for different platforms, the results are the same unless expliclty mentioned.
+ +| Browser | +Any Order | +Equal Heights | +Vertical Grid | +Combined | +
|---|---|---|---|---|
| IE Win 7 beta 2 | +pass | +pass | +fail (mild) [note] | +pass | +
| IE Win 6 | +pass | +pass | +pass | +pass | +
| IE Win 5.5 | +pass | +pass | +pass | +pass | +
| IE Win 5.01 | +pass | +pass | +pass | +pass | +
| IE Mac 5.2 | +pass | +fail (mild) [note] | +fail (mild) [note] | +fail (mild) [note] | +
| Firefox 1.5 | +pass | +pass | +pass | +pass | +
| Firefox 1.0 | +pass | +pass | +pass | +pass [note] | +
| Netscape 8.0 | +pass | +pass | +pass | +pass | +
| Netscape 7.2, 7.1, 7.0 | +pass [note] | +pass | +fail (mild) [note] | +pass | +
| Netscape 6.2, 6.1 | +pass [note] | +pass [note] | +fail (severe) [note] | +fail (severe) [note] | +
| Netscape 6.0 | +fail (total) [note] | +untested | +untested | +untested | +
| Netscape 4.7 | +fail (fixable) [note] | +untested | +untested | +untested | +
| Opera 9.0 (beta) | +Pass | +Pass | +Pass[note] | +Pass | +
| Opera 8.0, 8.5 | +pass | +pass | +pass | +pass | +
| Opera 7.5 | +pass | +pass | +pass | +pass | +
| Opera 7.2, 7.1, 7.0 | +pass | +fail (severe) [note] | +pass | +fail (severe) [note] | +
| Opera 6 | +fail (fixable) [note] | +fail [note] | +fail [note] | +fail [note] | +
| Opera 5 | +fail (total) [note] | +untested | +untested | +untested | +
| Safari 2.0, 1.3, 1.2, 1.03 | +pass | +pass | +pass | +pass | +
| OmniWeb 5.0.1 | +pass | +pass | +pass | +pass | +
| iCab 3.02beta | +pass | +pass | +pass | +pass | +
| iCab 3.01beta | +pass | +pass | +fail (total) [note] | +fail (total) [note] | +
| IE Win 7 beta 2 | +|
|---|---|
| Vertical Grid | +
+ Example as it stands fails +Solution is to force get |
+
| IE Mac 5.2 | +|
| Equal Heights | +
+ By not feeding IE Mac the padding- and margin-bottom values that are behind the equal height, we get an acceptable degradation - if IE Mac 5 really must be catered for, then it's nothing faux-columns suitably applied can't handle +On the other hand, if IE Mac 5 does get to see the padding- and margin-bottom values, the failure is catascrophic as it makes the page that height + |
+
| Vertical Grid | +
+ Snaps placed above wrapper div (despite being able to paint wrapper's background to the correct height) +Solution is to not give IE Mac 5 the absolutely positioning for snap and to just let it take its place in the flow + |
+
| Combined | +
+ Now the snaps vanish entirely +The fix is the same as the solution for snapped elements without equal columns + |
+
| Firefox 1.0 | +|
| Combined | +
+ A bug when #wrapper's However, by wrapping another div around #wrapper and moving It's annoying that this has to be done, but so far it's the only known fix + |
+
| Netscape 7.2, 7.1, 7.0 | +|
| Any Order | +
+ See article body for details + |
+
| Vertical Grid | +
+ Snaps placed correctly to the bottom of the wrapper div, however 1em additional bottom margin sneaked into the wrapper div and so the snaps are 1em below the bottom of the longest column. +But check the combined result... + |
+
| Netscape 6.2, 6.1 | +|
| Any Order | +
+ Same caveat as for NS7 + |
+
| Equal Heights | +
+ Some elements beneath the wrapper appear not to be able to receive clicks - the footer is ok so there you go + |
+
| Vertical Grid | +
+ Snaps vanish +... and where they gos, nobody knows + |
+
| Combined | +
+ Netscape 6.1 +Since the snaps fail, unsurprisingly the combination fails too - the equal height stuff still works just fine + |
+
| Netscape 6.0 | +|
| Any Order | +
+ Columns simply stack up on top of each other + |
+
| Netscape 4.7 | +|
| Any Order | +
+ See the appendix that deals with older browsers. + |
+
| Opera 9.0 (beta) | +|
| Vertical Grid | +
+ To get Opera 9 and 8 to play together at the same time requires some mundane if verbally spectacular and verbose hackery. Of course, you could just drop support for Opera 8... + |
+
| Opera 7.2, 7.1, 7.0 | +|
| Equal Heights | +
+ Percent works just fine. +Pixels and ems go haywire and extend the columns. + |
+
| Combined | +
+ Percent also stops working in just the same manner as the equal height failure. + |
+
| Opera 6 | +|
| Any Order | +
+ See the appendix that deals with older browsers. +Additionally, the em version makes the columns too narrow for some reason + |
+
| Equal Heights | +
+ There's a rendering display problem (which is probably the cause for Mark's extra content wrapper div) when the page is left and returned to (clicking back and forward, switching to another app and back again, but not reloading the page), everything is magically ok! + |
+
| Vertical Grid | +
+ Horribly messy +Each Snap extends from the bottom of its column to the bottom of the viewport (nice job on your positioning there Opera 6). + |
+
| Combined | +
+ The messiness of the snap placement, and the equal heights stop working. +But because of the overflow:hidden, the extended snaps are also subject to the magic of the equal height's "now you see it, now you don't" page revisit born againness + |
+
| Opera 5 | +|
| Any Order | +
+ Columns don't even begin to be treated as such - they just stack up vertically, ie. as usual + |
+
| iCab 3.0 beta | +|
| Vertical Grid | +
+ The vertically positioned elements don't show up at all. +Which is very odd since the examples work in iCab just fine. + |
+
| Combined | +
+ Still no sign of the vertically positioned elements. + |
+
Throughout this article and its assorted examples I use class names and ids such as #footer, #header, #block_1 and .verticalalignment. You shouldn't use identifiers like this in the real world.
Take for example #header. What's in it? If, I'm guessing here, it actually contains site identity stuff like logos, #site-identity (or whatever you prefer) would be better. Disclaimer legalese in the "footer"? Then use someting more descriptive like #site-legal or #legal-mumbo-jumbo. Because you might want to place you site identity at the bottom or doen the side, and then #header doesn't make any sense. It's the same reason really for not using class names like .red-bold-helvetica.
I'm using these names because this is an article with example code. In this case they really are properly descriptive. Unless you're writing a similar article, using simliar names will not be so for you.
+ +Throughout the article I use hacks to deal with IE Win - that's just the way I like to do things. It also makes the example code here simmpler and clearer. And to be clearer still about the intent of the code: it is example code. I do not recommend that you cut and paste it (see the remarks about class names and ids above), but rather that you write it yourself after understanding the principles behind the techniques.
+So, feel free to use conditional comments or plain voodoo if you prefer. But please don't bother telling me hacks are wrong etc...
+ +Throughout the article, the working examples linked to are percentage-based. Consequently those examples, surprise surprise, are not pixel perfect and small gaps will occasionally (or rather, frequently) appear between the columns. One fix for such a three column layout is to set just the backgrounds of the side columns and let the background of the wrapping element paint the central column.
+Personally I would avoid such layouts in a real life production situation, but I feel that it helps explain that the principles of the techniques better than using rigid pixel values. And others may not feel comfortable with grappling with the concept of scalable em-based layouts. So precentages, it is.
+ +Yes, I know. Some of the examples have incorrect wrapping in Internet Explorer. At some window sizes. It's caused by a rounding error, a known problem with Explorer. If you read the section Danger Alex Robinson on the Any Order Columns page you'll see it mentioned in passing.
+ +Try resizing your browser - you should see the column jump back and forth from its correct position to where you see it now. If you must use percentages, the solution is to feed Explorer a slightly smaller value for the problematic column, say 32.9% instead than 33%. I could have done that in the examples but frankly, what with the length of the article and wanting to concentrate on the bare minimum to demonstrate things, I chose to not include such refinements. If you go to the interactive demo, you'll see that there's a message advising about reducing values if wrapping occurs.
+ +For obvious reasons the problem doesn't occur at all with pixel-based designs. And much less frequently with em-based ones, especially since I always make the wrapper just that little bit wider than it needs to be.
+ +Of course, if you've found another problem with the layout, please make haste to let me know about it.
+ +There are plenty of things that could have been added to this article.
+At over 10000 words, though, it's already a bit of a monster and only issues that arise as a direct consequence of techniques discussed here are addressed. However I have tried to point the reader towards the most common problems that these techniques share with other approaches. If you think I've made any appalling omissions, tell me about it.
+ + + +Rather than position each float relative to the overall rightmost point has been cleared, if any element has a negative margin-left applied to it, NN4 (4.7, for sure) treats all positive margin-lefts as starting from 0.
So we just need to negatively shift one element (by the amount that would be expected from its desired position) and then set margin-left on the other elements as if they were absolutely positioned
| NN4 | Normal | |
|---|---|---|
| Block 1 | 25 | 25 |
| Block 2 | 75 | 25 |
| Block 3 | -100 | -100 |
| Block 4 | 50 | -50 |
Of course, NN4 doesn't understand the easy clearing method, so a non-semantic clearing element would need to introduced to force the wrapper element's height.
+Though this would work, NN4's application of colours and background images to floated and absolutely positionned elements is notoriously flaky, so maintaining the layout structure is the most you could seriously hope to achieve.
+ + +Suffers from something similar but different to NN4.
+Once the overall rightmost point has been cleared, it works from the preceding element's rightmost point.
+| Op 6 | Normal | |
|---|---|---|
| Block 1 | 25 | 25 |
| Block 2 | 25 | 25 |
| Block 3 | -100 | -100 |
| Block 4 | 25 | -50 |
However, if you are so foolhardy as to try and do something with this information, know this also - Opera 6 has problems when using ems and makes the columns too narrow for some reason.
+ + + +Since the Any Order technique does not rely on wrapping elements, the blocks can be arranged in all possible combinations. For n columns, since any block can be in the position of any column, that number is given by the simple formula n factorial or n!
+eg. for n = 5, the possible orderings = 1 x 2 x 3 x 4 x 5 = 120
+ +With the wrapping elements (as in the original Source Ordered Columns), things are more constrained. For each wrapping element we essentially end up with two sub columns - two sub-columns means two possible combinations, giving us the formula, 2n-1.
+eg. for n = 5, the possible orderings = 2 x 2 x 2 x 2 = 16
+ +As you can see, as the number of columns increases, the potential number of combinations increases far more rapidly for the Any Order technique.
+ +More practically, wrapping elements can be used to good effect to enable groups of blocks to be stacked vertically within, rather than as, columns, giving yet more potential layout flexibility.
+ +| Number of Columns | +Source Order Columns | +Any Order Columns | +
|---|---|---|
| 2 | +2 | +2 | +
| 3 | +4 | +6 | +
| 4 | +8 | +24 | +
| 5 | +16 | +120 | +
| 6 | +32 | +720 | +
| 7 | +64 | +5040 | +
| 8 | +128 | +40320 | +
Until enough browsers support multiple backgrounds on a single element, n-2 wrapping elements are required to hold the necessary background images to create the effect of n columns.
+Unless, of course, the layout is a fixed pixel-width one, in which case a single background image can be used for any number of columns.
+ + + + +direction:rtl (hat tip to Rob Cochrane).#footer { clear: both; } to the main inline CSS since that's where it should have been all along.First published.
+ + + +
Back in the introduction, I made a rash claim - that I could conjure up a layout that satisfied:
+Now comes the magic moment. We've seen how to solve each of these problems in isolation. What happens if we just stick them all together?
+ +Well, to cut to the chase, it works in all the browsers that the individual techniques work in. Except... and it almost makes me weep to say it. Except Firefox 1.0.
+ +Example of the One True Layoutâ„¢ (2-1-3 ordering)
+ +This time we've run into a delightful bug. If an element has position:relative and overflow:hidden but no explicit height, then nested elements positioned absolutely within it vanish completely in Firefox 1.0. And until this is fixed, there is no CSS workaround for it.
This bug has been fixed in Firefox 1.5. Indeed, it was fixed in the Gecko engine as of version 1.8b2.
+It's time for another markup fix. We can't dispense with either the position:relative or overflow:hidden, but we can remove the overflow from #wrapper and apply it to another element that we put around it:
<div id="wrapper_extra"> +<div id="wrapper"> +<div id="element_1"> + ... +<div class="verticalalign"><p>Snap 1</p></div> + +</div> +<div id="element_2"> + ... +<div class="verticalalign"><p>Snap 2</p></div> +</div> +<div id="element_3"> + ... + +<div class="verticalalign"><p>Snap 3</p></div> +</div> +</div> +</div>+ +
#wrapper_extra
+ {
+ position: relative;
+ }
+#wrapper
+ {
+ overflow: hidden;
+ position: relative;
+ }
+This placates the mysterious Firefox bug, but causes IE to lose the plot. No matter, that's easy to fix:
+* html #wrapper
+ {
+ position: relative;
+ }
+Example of the One True Layoutâ„¢ with a fix for Firefox (2-1-3 ordering)
+ +As previously noted, it works everywhere the individual techniques do. See Appendix B for all the gory details.
+ +Would sir care to peruse some more involved examples?
+ + + + +The Any Order and Vertical Grid techniques are fundamentally simple. More importantly, they will carry on working for as long as browsers support CSS2.1. All that will change is the dropping some of the hacks which are only needed to help the current crop of browsers (Safari notwithstanding - and Gecko once they get that regression bug fixed). That is, the techniques will improve over time. Why? Because these techniques do exactly what the specs say you can do.
+ +On the other hand, the Equal Height technique is a kludge - despite the fact that the basic concept is solid and that any future browsers that are properly conforming will support it (Or maybe not...). But it's only needed because display: table-cell doesn't allow for a) reordering the columns, or in today's mainstream browsers at any rate, b) absolute or relative positioning.
There was a whole lot of stuff that didn't really fit in the article and has been shunted into appendices. Of these, the most interesting is probably the one on creating any order columns with liquid center and fixed-width sides. Seeing as people like that kind of thing for some reason.
+ +The techniques described in this article were almost completely worked out around Christmas 2004. Unfortunately by the time I got round to actually publish them, the beta of Opera 8 had been released. It's only recently that I was able to spend the time to figure out a fix for that.
+ +And now the latest beta version of the Gecko engine is upon us and causing even more havoc. Well tough. This time I'm publishing. I refuse to be bowed once again by a browser's failing - especially where that failing is a reversal of previous correct CSS support.
+ +Opera 9 was released in beta the day before this article was first published. It fixes all the bugs mentioned throughout this article. And then the Mozilla team fixed the bug that screwed up the Any Order method and incorporated the fix at double quick time on 2 November 2005. All's well that ends well.
+ +All that's left to say, is "Rock on IE7"! [note]
+ +... actually IE7 (as of beta 2) seems to pretty much work, though when zooming, things can go a bit awry if percentages have been used. The only tweaks needed seem to be those instances where * html has been used to hide the forcing of hasLayout on IE and where IE7 still needs it - eg. the plain vanilla vertical grids.
Several problems have been found with this technique since publication. Those problems are discussed in Appendix J
+As an astute disciple of CSS, you are probably about to point out that there is a well-known tried and tested method for this (and as already mentioned earlier in this article), the one popularised in Dan Cederholm's Faux Columns. If so, just wait - we are returning to the scene of the crime...
+ +The real credit for this technique belongs to Mark Challoner who had the crucial insight - I have merely helped polish it to the point where you can see your boots in it.
+ +What it says on the tin - a method to make all columns appear to be the same height. But without the need for faux column style background images.
+ +
Because equal height columns are a perfectly reasonable design goal. And the even more astute disciple will be nodding sagely, ruminating over the problems that flow from faux columns. Namely:
+The most astute disciple is already one step ahead and is awaiting the pronouncement that Faux Columns are dead. I wouldn't go that far - in fact, they probably remain the weapon of choice. However, the method about to be described certainly provides an alternative that overcomes the problems above in some, if not all, circumstances.
+ +The basic method works like this:
+overflow: hidden to the container elementpadding-bottom: $big_value [note] to the column blocks, where $big_value is a large enough value to guarantee that it's equal to or larger than the tallest columnmargin-bottom: -$big_value to the column blocksWhat happens is that columns really become as tall as the content they contain plus $big_value thanks to the padding-bottom. The negative margin-bottom brings the flow of the document back to where the same point as where the padding-bottom began, and the overflow: hidden on the containing element chops off the overflow[note]. Consequently the columns' presence on the page only appears to be the height of the containing element and any background colour (or image for that matter) applied to the columns displays for that height. Most crucially, the height of the page reflects what appears to be on the page and does not dissappear into the scrolling distance.
Remarkably, IE Win doesn't actually need the overflow: hidden, but it causes no problems so there is no need to hide it.
Beware though, browsers don't let you throw arbitrarily large values at them. They have limits. Exceed that limit and the columns will expand to the padding-bottom value and you'll end up wiuth some pretty long pages. Fortunately, we know the number of that limit (which is actually provided by Safari which is the most conservative browser in this matter): 32767px. This should suffice for most cases (though feel free to use a smaller value) and yields us code like this:
#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ }
+#wrapper
+ {
+ overflow: hidden;
+ }
+
+Now if you wanted to actually achieve a 0.5em padding-bottom on the column, then you'd need code like this: [note]
+ +#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ padding-bottom: 1000em;
+ margin-bottom: -999.5em;
+ }
+
+There seems to be a consensus that pixel values are usually a better bet for this type of malarkey. So, unless you need to do something like the previous example, it's wisest to stick to pixel values - especially since an em-based value which might seem fine at one font setting can end up breaking the browser's actual limit when increased.
+ +Of course, it's only to be expected that things aren't quite that simple, and that we'll need to polish things up before this is production-ready.
+I'm not sure exactly which versions of Safari this effects, but the padding-bottom has a ghost effect that, though the columns are painted correctly, links and form elements that follow the columns and that by rights should be above it, are unclickable. (Fixed as of 4 November 2005)
+This problem can be overcome by setting position: relative on any of the necessary elements. However, An unintended side-effect is that it cause such elements to vanish in IE Wins, 5.01 and 5.5, so we need to prevent those browsers seeing the position: relative.
For example, if we had an element with the id "affected_element", we would add the following: [note]
+* > #affected_element
+ {
+ position: relative;
+ z-index: 1000;
+ }
+IE5 Mac gets the column heights right, but the height of the page ends up including the invisble padding. Whether or not you think this is acceptable is up to you, but a simple backslashed comment hack will prevent IE5 Mac from doing the whole equal heights expansion. Graceful degradation, baby...
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ }
+/* End Mac IE5 filter */
+Operas 7.0 through 7.2 don't actually chop off the extended columns at the right place. For sure they don't march off quite as far as the numbers would make you think they would, but that's little comfort when you've got huge columns obliterating all in their path.
+Adding display: inline-block to the container element would solve this, but it would cause other problems to pop out from under the Opera bug carpet which are possibly fixable, but life's just too short - the most robust solution is to add our old friend EasyClearing, and all's well again.
Apart from in IE Win 5.01, where the addition of the easy clearing causes the exact opposite to happen - ie. where before all was well, now the columns stretch off into the distance. Because of Opera, mind. Fortunately, we can just add a float: left; and 5.01 is happy again.
* html #wrapper
+ {
+ float: left;
+ }
+Example of the Equal Height Column technique (2-1-3 ordering)
+ +Opera 8 introduced a bit of a bug to its handling of overflow: hidden. So, even though the easy clearing is enough to sort out the lesser Operas (though note that 7.54 works just fine without any "help"), we are again faced with columns that wouldn't look out of place in The Towering Inferno.
Fortunately, once more there is a fix. The large padding-bottom/negative margin-bottom routine needs to removed from the columns themselves and applied to elements within them instead.
+The most obvious way to achieve this would be to set a class on the final element in each of the columns, but that would be bad since a) you need to add the class in, and b) the class is essentially playing the same role as a clearing break element - since the class is actually a structural aid rather than saying anything about what's actually within the element in question.
+Better is to use the :after pseudo element which we can rely on since we're targeting a modern browser. Rather than using padding-bottom, we use padding-top instead, since we can't rely on visibility: hidden to hide the generated content. Because otherwise the generated content doesn't actually increase the height of the column, somewhat defeating its purpose.
Of course, removing the padding-bottom from the columns causes all the other browsers to collapse the columns. We could hide the removal from IE Wins with a child descendant hack, but that wouldn't help Safari and Firefox. So we reach into our box of tricks and pull out the @media query hack [note].
Here's what the addional Opera 8 code looks like:
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ }
+/* End Mac IE5 filter */
+@media all and (min-width: 0px) {
+#block_1, *#block_2, #block_3
+ {
+ padding-bottom: 0;
+ margin-bottom: 0;
+ }
+#block_1:after, #block_2:after, #block_3:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px;
+ margin-bottom: -32767px;
+ height: 0;
+ }
+}
+
+Example of the Equal Height Column technique with a fix for Opera 8 (2-1-3 ordering)
+ +The good news is that the beta version of Opera 9 fixes the bug in Opera 8. Considering the relatively small proportion of Opera users and the likelihood of such users to upgrade often and early, it's probably OK to just leave out the Opera 8 fix.
+On the other hand, if you want to figure out how to distinguish Operas 8 and 9, I'm not going to stop you.
+ +Just in case you missed the bit at the top of the page, several problems have been found with this technique since publication. Those problems are discussed in Appendix J
+IE Win 7 beta 2, IE Win 6, IE Win 5.5, IE Win 5.01, Operas 7, 8 and 9, Firefox 1.5 and 1.0 [note], Netscape 8, Safari 1.03 (and up), (OmniWeb5.0?)
+ +The longest column must not have been negatively shifted under any circumstances otherwise we're in the same old boat of following elements not being cleared correctly as with the Any Order Columns method. But with an added twist. Since the containing element has been set to overflow: hidden, anything in the columns below the point that Netscape mistakenly believes is the endpoint of the columns is cut off and not displayed.
As mentioned previously, the method causes the page to expand to the "actual" height of the columns. The choice is yours whether to accept that or to forego the equal heights in this superannuated browser, currently tottering around the edges interweb waiting to be put out of its misery.
+ +Do not understand the method at all. It is left as an exercise to the reader to figure out the necessary hacks to cope with those browsers if required.
+ +This method is fairly robust, generic and nestable.
+It can get a little gnarly under certain circumstances - in Operas and IE Win 5.01 (see the expanded examples for details.)
+Faux Columns have already been discussed. Ingo Chao has a faux columnless two em-based columns with equal height.
+Modern browsers hold out the promise of being able to use display:table to achieve much the same effect. However once you have chosen that route you are stuck with a rigid table structure. There is no way you can reorder the column blocks. Moreover, browser support for positioning elements relatively or absolutely within a table cell, whether the cell actually a td, th or another element with display:table-cell) is non-existent except for some slight support in iCab 3.0. Apparently. Which puts you back to square one having to write markup that looks like a traditional table.
Now that we have our revised mechanism for making columns the same height, it's time to turn our attention to how to position elements vertically within those columns.
+ + + + + + + +$big_value is a variable name, standing in for the actual value.display: table is a no go for containing the floats. Safari just doen't get on well with the combination of display: table and overflow: hidden. The end result is that the overflowing stuff simply isn't hidden.padding-bottom and negative margin-bottom to that and just set the required padding-bottom on the outer element.z-index doesn't have to be 1000. Depending on your design and whether you're using z-index elsewhere, you might need to use a different value.+ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="wrapper"> +<div id="block_1"> + ... +</div> +<div id="block_2"> + ... +</div> +<div id="block_3"> + ... +</div> +</div> ++
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+#footer
+ {
+ clear: both;
+ }
+
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="block_1"> + ... +</div> +<div id="block_2"> + ... +</div> +<div id="block_3"> + ... +</div> ++
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+#footer
+ {
+ clear: both;
+ }
+* html body
+ {
+ margin: 0;
+ padding: 0;
+ }
+* html #footer
+ {
+ position: relative;
+ }
+
+24 September - 9 October 2005
+This two-week event encourages adults and children to appreciate home-grown British produce.
+ +
The Lost Decade
| Wednesday | +Thursday | +||
|---|---|---|---|
 |
+max 18°C | + |
+max 17°C | +
| min 10°C | +min 12°C | +||
Audio and video links may require you to download additional plug-ins
+Business News, E-commerce, Your Money...
+CBBC, CBBC Search, CBeebies...
+Collective, Comedy, Film...
+Healthy Living, Parenting, Relationships...
+Ancient History, Family History, Wars...
+Languages, Revision, Schools...
+Artist Profiles, Gigs & Concerts, Music News...
+Politics, UK News, World News...
+Animals, Human Body & Mind, Space...
+Arts, Disability, Religion & Ethics...
+Cricket, Football, Rugby Union...
+Try the A-Z Index
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+A copy of the page this is a makeover of can be viewed here
+This is just a demo of what's possible. It is not a fully stress-tested solution being proffered up. Consequently to keep that clear (and hopefully keep the BBC's lawyers off my back), only the main content has been reproduced and styled up. Plus, who'm I kidding, it's not like I'm getting paid to do this...
+All layout tables have been removed and the content reordered as a first pass at making it more appropriate for user agents without styling. However, one compromise has been made to maintain the original design. Personally, the explore search box would be grouped together with the browse categories and follow the highlighted feature, what's on today and the localised info, but that would make it impossible to make the explore and highlighted feature boxes line up vertically (unless we set a guesstimated em-based height for them - perfectly feasible but it wouldn't be a useful demonstration of the techinques involved).
+The layout is now completely em-based and so is scalable.
+li elements are spaced too far apart
+Resizing is ropey - bumping up the size causes the top "row" to shunt rightwards. Probably because in my haste I've actually got the numbers wrong, but have massaged it so it appears to work and now can't be bothered to figure out just what's up.
+A, er, fair amount of space before the main content kicks in. Plus the today bar isn't long enough. Don't know, don't care. Other than that it's as good as the other IE Wins.
+Doesn't get the equal height columns and degrades accordingly.
+Firefox 1.5 and 1.0 work. So does Netscape 8 and 7.2. And so does Firefox 1.5 beta (it doesn't have any columns after the negatively shifted one so no problems arise).
+NB. Weird scrolling effects occur in Firefox 1.0 when trying to select text. This bug has been fixed in 1.5 and since I'm not getting paid for this... Details in this [css-d] thread.
+Operas need a fair bit of hand holding, with Opera 9 beta being the easiest to knock into line. Opera 7 has the incorrect absolute positioning bug and so the "see full directory" and the date vanish. Plus a bizarre enormous amount of horizontal scrolling appears - no doubt related to the absolute positioning wackness...
+As for Opera 8, it's so bust because of the overflow: hidden bug that I've not even bothered to cater for it. The text displays - the columns are elongated far beyond what is needed though.
Close, but no cigar. Well, no that close at all. The "Where I live" content disappears (except for the map and the "change location" button) as does the childrens telly section. The plugins block shunts upwards to appear just below the "Today" bar. And the main images start doing some kind of hierarchical indentation dance. Things look much better when the equal heights business gets removed. Hack, anyone?
+ | | ||
| | ||
|
Explore bbc.co.uk+ + + |
+
|
+ + Browse+
+
+ Business & Money+Business News, E-commerce, Your Money...+ Children's+CBBC, CBBC Search, CBeebies...+ Entertainment+Collective, Comedy, Film...+ Health+Healthy Living, Parenting, Relationships...+ History+ Ancient History, Family History, Wars...+ Learning+Languages, Revision, Schools...+ Lifestyle+Food, Gardening, Holidays...+ Music+Artist Profiles, Gigs & Concerts, Music News...+ News+Politics, UK News, World News...+ Science & Nature+Animals, Human Body & Mind, Space...+ Society & Culture+Arts, Disability, Religion & Ethics...+ Sport+Cricket, Football, Rugby Union...+Can't find it? +Try the A-Z Index + + |
+Wednesday 28th September 2005 Today | ||||||||||||||||||||||||||||||||||||||||
+
|
+
+Where I Live+
Local weather:+
+ + Local information:++ What's on in London, Central:++ National information:+ + |
+||||||||||||||||||||||||||||||||||||||||
Audio and video links may require you to download additional plug-ins | |||||||||||||||||||||||||||||||||||||||||
+
| |||||||||||||||||||||||||||||||||||||||||
| + | |||||||||||||||||||||||||||||||||||||||||
Terms of Use | Privacy & Cookies Policy |
filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+ +Snap 1
This example forms part of the Position is Everything article, In Search of the One True Layout.
++<div id="wrapper_extra"> +<div id="wrapper"> +<div id="block_1"> +<div class="box_copy last"> + ... +<div class="verticalalign"> ... </div> +</div> +</div> +<div id="block_2"> +<div class="box_copy"> + ... +<div class="verticalalign"> ... </div> +</div> +<div class="box_copy"> + ... +<div class="verticalalign"> ... </div> +</div> +<div class="box_copy last"> + ... +<div class="verticalalign"> ... </div> +</div> +</div> +<div id="block_3"> +<div class="box_copy"> + ... +<div class="verticalalign"> ... </div> +</div> +<div class="box_copy"> + ... +<div class="verticalalign"> ... </div> +</div> +<div class="box_copy"> + ... +<div class="verticalalign"> ... </div> +</div> +<div class="box_copy last"> + ... +<div class="verticalalign"> ... </div> +</div> +</div> +</div> +</div> ++
Menezes' family call for justice
Reds & Chelsea share Euro spoils
CBBC
CBeebies
+#block_1
+ {
+ float: left;
+ width: 50%;
+ margin-left: 25%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 25%;
+ margin-left: -75%;
+ }
+#block_3
+ {
+ float: left;
+ width: 24.9%;
+ }
+#block_1, #block_2, #block_3
+ {
+ background-image: url(../images/backgrounds/sunken_tr.gif);
+ background-position: 100% 0;
+ background-repeat: no-repeat;
+ }
+.box_copy
+ {
+ border-top: solid 4px #ffffff;
+ background-image: url(../images/backgrounds/sunken_tl.gif);
+ overflow: hidden;
+ }
+.box_copy h2
+ {
+ padding: 12px 18px 10000px 18px;
+ padding: 12px 18px 3px 18px;
+ margin-bottom: -9997px;
+ margin-bottom: 0;
+ background-image: url(../images/backgrounds/sunken_tr.gif);
+ background-position: 100% 0px;
+ background-repeat: no-repeat;
+ }
+/* Don't understand why, but IEs of all hues require this shifting */
+* html .box_copy h2
+ {
+ background-position: 100% -4px;
+ }
+.box_copy p
+ {
+ padding: 6px 18px 0 18px;
+ }
+.verticalalign
+ {
+ background-image: url(../images/backgrounds/sunken_bl.gif);
+ background-position: 0 100%;
+ background-repeat: no-repeat;
+ }
+.verticalalign p
+ {
+ text-align: right;
+ padding-bottom: 18px;
+ background-image: url(../images/backgrounds/sunken_br.gif);
+ background-position: 100% 100%;
+ background-repeat: no-repeat;
+ }
+.last
+ {
+ /* p-b + m-b hacks for IE 5.01 */
+ padding-bottom/**/: 100em !important;
+ margin-bottom/**/: -97.5em !important;
+ }
+div#block_1, div#block_2, div#block_3
+ {
+ /* p-b + m-b hacks for IE 5.01 */
+ padding-bottom/**/: 30000px !important;
+ margin-bottom/**/: -30000px !important;
+ }
+@media all and (min-width: 0px) {
+body #block_1, body #block_2, body #block_3
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ }
+#block_1:before, #block_2:before, #block_3:before
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ margin-top: -5px;
+ padding-top: 32000px !important;
+ margin-bottom: -32000px !important;
+ height: 0;
+ }
+}
+.last .verticalalign
+ {
+ /* p-b + m-b hacks for IE 5.01 */
+ position/**/: absolute;
+ bottom/**/: 0;
+ }
+#block_1 .last .verticalalign
+ {
+ width: 50%;
+ }
+#block_2 .last .verticalalign
+ {
+ width: 25%;
+ }
+#block_3 .last .verticalalign
+ {
+ width: 24.9%;
+ }
+/* hack for Operas */
+@media all and (min-width: 0px){
+#wrapper .last div.verticalalign
+ {
+ width: 100%; /* Opera 7.5 and 8 */
+ }
+div[id^="wrapper"] #block_1 .last div.verticalalign
+ {
+ width: 50%;
+ }
+div[id^="wrapper"] #block_2 .last div.verticalalign
+ {
+ width: 25%;
+ }
+div[id^="wrapper"] #block_3 .last div.verticalalign
+ {
+ width: 24.9%;
+ }
+}
+/* hack for IEs of all hues */
+* html .verticalalign
+ {
+ width: 100% !important;
+ }
+#wrapper_extra
+ {
+ position: relative;
+ }
+* html #wrapper
+ {
+ position: relative;
+ }
+#wrapper
+ {
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ display: block; /* this time Operas 7 + 8 need block, not inline-block */
+ }
+/* but that makes IE go crazy */
+* html #wrapper
+ {
+ display: inline-block;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ overflow: hidden;
+ }
+/* end easy clearing */
+h2, p
+ {
+ margin: 0;
+ padding: 0;
+ }
+
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+filler
+ +Snap 1
This example forms part of the Position is Everything article, In Search of the One True Layout.
++<div id="wrapper_extra"> +<div id="wrapper"> +<div id="block_1"> +<div class="box_copy last"> + ... +<div class="snap"> ... </div> +</div> +</div> +<div id="block_2"> +<div class="box_copy"> + ... +<div class="snap"> ... </div> +</div> +<div class="box_copy"> + ... +<div class="snap"> ... </div> +</div> +<div class="box_copy last"> + ... +</div> +</div> +<div id="block_3"> +<div class="box_copy"> + ... +<div class="snap"> ... </div> +</div> +<div class="box_copy"> + ... +<div class="snap"> ... </div> +</div> +<div class="box_copy"> + ... +<div class="snap"> ... </div> +</div> +<div class="box_copy last"> + ... +<div class="snap"> ... </div> +</div> +</div> +</div> +</div> ++
+#block_1
+ {
+ float: left;
+ width: 20em;
+ margin-left: 10.5em;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 10em;
+ margin-left: -30.5em;
+ }
+/* weirdness with the IE posse - reload causes the
+bottom-aligned elements in the non-longest columns to
+shift upwards as if they were the second longest column
+was the longest
+this is totally due to the media query.
+And even more weirdly changing the font size makes things
+"normal" again. Resizing the viewport does not have any effect
+Of course, the media query hack is needed just because
+Opera can't position a crate of ale on a brewery palette
+*/
+@media all and (min-width: 0px) {
+#block_2
+ {
+ margin-left: -31em;
+ padding-left: 0.5em;
+ }
+}
+#block_3
+ {
+ float: left;
+ width: 10em;
+ margin-left: 0.5em;
+ }
+.box_copy
+ {
+ border: solid 0.25em #666666;
+ padding: 0.5em;
+ margin-top: 0.5em;
+ background: #889988;
+ }
+#block_1 .box_copy
+ {
+ background: #aabbaa;
+ }
+.snap p
+ {
+ margin: 0;
+ padding: 0;
+ text-align: right;
+ }
+.last .snap p
+ {
+ padding: 0 0.75em 0.5em 0;
+ }
+/* '* html' to filter only IE Win */
+/* Start Mac IE5 filter \*/
+#block_1 .last, #block_2 .last, #block_3 .last
+ {
+ padding-bottom: 1000em !important;
+ margin-bottom: -998em !important;
+ }
+* body #block_1, * body #block_2, * body #block_3
+ {
+ padding-bottom: 30000px !important;
+ margin-bottom: -30000px !important;
+ }
+.last .snap
+ {
+ position: absolute;
+ bottom: 0;
+ border-bottom: solid 0.25em #666666;
+ }
+* html .last .snap
+ {
+ bottom: -1px;
+ }
+#block_1 .last .snap
+ {
+ width: 20em;
+ left: 10.5em;
+ }
+#block_2 .last .snap
+ {
+ width: 10em;
+ left: 0;
+ }
+#block_3 .last .snap
+ {
+ width: 10em;
+ left: 31em;
+ }
+/* End Mac IE5 filter */
+#wrapper_extra
+ {
+ position: relative;
+ }
+* html #wrapper
+ {
+ /* bizarrely necessary for IE6 ! */
+ position/**/: relative;
+ }
+#wrapper
+ {
+ width: 41.5em;
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ display: inline-block; /* Fixes nasty Opera7 scrolling bug */
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+/* end easy clearing */
+h2, p
+ {
+ margin: 0;
+ padding: 0;
+ }
+
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Snap 1
Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Snap 2
Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +Snap 3
This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="wrapper"> +<div id="block_1"> + ... +<div class="verticalalign"><p>Snap 1</p></div> +</div> +<div id="block_2"> + ... +<div class="verticalalign"><p>Snap 2</p></div> +</div> +<div id="block_3"> + ... +<div class="verticalalign"><p>Snap 3</p></div> +</div> +</div> ++
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px !important;
+ margin-bottom: -32767px !important;
+ }
+@media all and (min-width: 0px) {
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ }
+#block_1:before, #block_2:before, #block_3:before
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px !important;
+ margin-bottom: -32767px !important;
+ height: 0;
+ }
+}
+/* End Mac IE5 filter */
+/* IE Win can be a bit out - you might need to adjust
+bottom value by -1px or as required */
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ }
+#block_1 .verticalalign
+ {
+ width: 34%;
+ }
+#block_2 .verticalalign
+ {
+ width: 33%;
+ }
+#block_3 .verticalalign
+ {
+ width: 33%;
+ }
+/* hack for Opera 7+ */
+@media all and (min-width: 0px){
+.verticalalign
+ {
+ width: 100% !important;
+ }
+/* But Opera 9 does it right, so CSS3 hax to the max */
+div[id^="wrapper"] #block_1 .verticalalign
+ {
+ width: 34% !important;
+ }
+div[id^="wrapper"] #block_2 .verticalalign
+ {
+ width: 33% !important;
+ }
+div[id^="wrapper"] #block_3 .verticalalign
+ {
+ width: 33% !important;
+ }
+}
+/* hack for IEs of all persuasions before IE7 */
+* html .verticalalign
+ {
+ width: 100% !important;
+ }
+.verticalalign p
+ {
+ position: absolute;
+ bottom: 0;
+ right: 0;
+ margin: 0;
+ padding: 0;
+ background: #996666;
+ }
+#wrapper
+ {
+ position: relative;
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+#footer
+ {
+ clear: both;
+ }
+/* Safari needs this - otherwise the ghost overflow, though painted
+correctly obscures links and form elements that by rights should be above it.
+An unintended side-effect is that it cause such elements to vanish in IE 5.01
+and 5.5, hence the child selector hack */
+* > #footer, * > form, * > #notes, * > .output
+ {
+ position: relative;
+ z-index: 1000;
+ }
+
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Snap 1
Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Snap 2
Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +Snap 3
This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="wrapper_extra"> +<div id="wrapper"> +<div id="block_1"> + ... +<div class="verticalalign"><p>Snap 1</p></div> +</div> +<div id="block_2"> + ... +<div class="verticalalign"><p>Snap 2</p></div> +</div> +<div id="block_3"> + ... +<div class="verticalalign"><p>Snap 3</p></div> +</div> +</div> +</div> ++
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px !important;
+ margin-bottom: -32767px !important;
+ }
+@media all and (min-width: 0px) {
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ }
+#block_1:before, #block_2:before, #block_3:before
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px !important;
+ margin-bottom: -32767px !important;
+ height: 0;
+ }
+}
+/* End Mac IE5 filter */
+/* IE Win can be a bit out - you might need to adjust
+bottom value by -1px or as required */
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ }
+#block_1 .verticalalign
+ {
+ width: 34%;
+ }
+#block_2 .verticalalign
+ {
+ width: 33%;
+ }
+#block_3 .verticalalign
+ {
+ width: 33%;
+ }
+/* hack for Opera 7+ */
+@media all and (min-width: 0px){
+.verticalalign
+ {
+ width: 100% !important;
+ }
+/* But Opera 9 does it right, so CSS3 hax to the max */
+div[id^="wrapper"] #block_1 .verticalalign
+ {
+ width: 34% !important;
+ }
+div[id^="wrapper"] #block_2 .verticalalign
+ {
+ width: 33% !important;
+ }
+div[id^="wrapper"] #block_3 .verticalalign
+ {
+ width: 33% !important;
+ }
+}
+/* hack for IEs of all persuasions before IE7 */
+* html .verticalalign
+ {
+ width: 100% !important;
+ }
+.verticalalign p
+ {
+ position: absolute;
+ bottom: 0;
+ right: 0;
+ margin: 0;
+ padding: 0;
+ background: #996666;
+ }
+#wrapper_extra
+ {
+ position: relative;
+ }
+* html #wrapper
+ {
+ position: relative;
+ }
+#wrapper
+ {
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ }
+/* we need this for IE 5.01 - otherwise the columns vanish */
+* html #wrapper_extra
+ {
+ float: left;
+ width: 100%;
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+#footer
+ {
+ clear: both;
+ }
+/* Safari needs this - otherwise the ghost overflow, though painted
+correctly obscures links and form elements that by rights should be above it.
+An unintended side-effect is that it cause such elements to vanish in IE 5.01
+and 5.5, hence the child selector hack */
+* > #footer, * > form, * > #notes, * > .output
+ {
+ position: relative;
+ z-index: 1000;
+ }
+
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="wrapper"> +<div id="block_1"> + ... +</div> +<div id="block_2"> + ... +</div> +<div id="block_3"> + ... +</div> +</div> ++
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px !important;
+ margin-bottom: -32767px !important;
+ }
+/* End Mac IE5 filter */
+#wrapper
+ {
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+#footer
+ {
+ clear: both;
+ }
+/* Safari needs this - otherwise the ghost overflow, though painted
+correctly obscures links and form elements that by rights should be above it.
+An unintended side-effect is that it cause such elements to vanish in IE 5.01
+and 5.5, hence the child selector hack */
+* > #footer, * > form, * > #notes, * > .output
+ {
+ position: relative;
+ z-index: 1000;
+ }
+
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+#target - Return to top
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+ + + + diff --git a/articles/onetruelayout/example/equalheightanchorsgeckofix.html b/articles/onetruelayout/example/equalheightanchorsgeckofix.html new file mode 100755 index 0000000..7ead5d6 --- /dev/null +++ b/articles/onetruelayout/example/equalheightanchorsgeckofix.html @@ -0,0 +1,287 @@ + + + + + + +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+#target - Return to top
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+
+:root #target
+ {
+ position: absolute;
+ }
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px !important;
+ margin-bottom: -32767px !important;
+ }
+@media all and (min-width: 0px) {
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ }
+#block_1:before, #block_2:before, #block_3:before
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px !important;
+ margin-bottom: -32767px !important;
+ height: 0;
+ }
+}
+/* End Mac IE5 filter */
+#wrapper
+ {
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+/* Safari needs this - otherwise the ghost overflow, though painted
+correctly obscures links and form elements that by rights should be above it.
+An unintended side-effect is that it cause such elements to vanish in IE 5.01
+and 5.5, hence the child selector hack */
+* > #footer, * > form, * > #notes, * > .output
+ {
+ position: relative;
+ z-index: 1000;
+ }
+
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+#target - Return to top
+ +Filler
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px !important;
+ margin-bottom: -32767px !important;
+ }
+@media all and (min-width: 0px) {
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ }
+#block_1:before, #block_2:before, #block_3:before
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px !important;
+ margin-bottom: -32767px !important;
+ height: 0;
+ }
+}
+/* End Mac IE5 filter */
+#wrapper
+ {
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+/* Safari needs this - otherwise the ghost overflow, though painted
+correctly obscures links and form elements that by rights should be above it.
+An unintended side-effect is that it cause such elements to vanish in IE 5.01
+and 5.5, hence the child selector hack */
+* > #footer, * > form, * > #notes, * > .output
+ {
+ position: relative;
+ z-index: 1000;
+ }
+
+<!--[if IE]>
+* html #wrapper
+ {
+ overflow: visible;
+ }
+<![endif]-->
+<!--[if gt IE 6]>
+html #wrapper
+ {
+ margin-bot\tom: -1px;
+ }
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ }
+#block_1
+ {
+ heigh\t: expression((document.getElementById('wrapper').offsetHeight
+ == document.getElementById('block_1').offsetHeight) ? '' :
+ (document.getElementById('wrapper').offsetHeight - 1) + "px");
+ }
+#block_2
+ {
+ heigh\t: expression((document.getElementById('wrapper').offsetHeight
+ == document.getElementById('block_2').offsetHeight) ? '' :
+ (document.getElementById('wrapper').offsetHeight - 1) + "px");
+ }
+#block_3
+ {
+ heigh\t: expression((document.getElementById('wrapper').offsetHeight
+ == document.getElementById('block_3').offsetHeight) ? '' :
+ (document.getElementById('wrapper').offsetHeight - 1) + "px");
+ }
+<![endif]-->
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="wrapper"> +<div id="block_1"> + ... +</div> +<div id="block_2"> + ... +</div> +<div id="block_3"> + ... +</div> +</div> ++
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px !important;
+ margin-bottom: -32767px !important;
+ }
+@media all and (min-width: 0px) {
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ }
+#block_1:before, #block_2:before, #block_3:before
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px !important;
+ margin-bottom: -32767px !important;
+ height: 0;
+ }
+}
+/* End Mac IE5 filter */
+#wrapper
+ {
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+#footer
+ {
+ clear: both;
+ }
+/* Safari needs this - otherwise the ghost overflow, though painted
+correctly obscures links and form elements that by rights should be above it.
+An unintended side-effect is that it cause such elements to vanish in IE 5.01
+and 5.5, hence the child selector hack */
+* > #footer, * > form, * > #notes, * > .output
+ {
+ position: relative;
+ z-index: 1000;
+ }
+
+This example forms part of the Position is Everything article, In Search of the One True Layout.
++<div id="container" class="wrapper_extra"> +<div class="wrapper"> +<div id="group_1-8"> +<div class="wrapper_extra"> +<div class="wrapper"> +<div id="group_1-5"> +<div id="group_1-3" class="wrapper_extra"> +<div class="wrapper"> +<div id="block_1"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_2"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_3"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div.wrapper --> +</div><!-- close div.wrapper_extra --> +<div id="group_4-5" class="wrapper_extra"> +<div class="wrapper"> +<div id="block_4"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_5"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div.wrapper --> +</div><!-- close div.wrapper_extra --> +</div><!-- close div#group_1-5 --> +<div id="block_6"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div.wrapper --> +</div><!-- close div.wrapper_extra --> +<div id="group_7-8" class="wrapper_extra"> +<div class="wrapper"> +<div id="block_7"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_8"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div.wrapper --> +</div><!-- close div.wrapper_extra --> +</div><!-- close div#group_1-8 --> +<div id="block_9"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div.wrapper --> +</div><!-- close div#container.wrapper_extra --> ++
+#container
+ {
+ width: 790px;
+ }
+#group_1-8
+ {
+ float: left;
+ width: 630px;
+ }
+#group_9
+ {
+ float: left;
+ width: 150px;
+ margin-left: 10px;
+ }
+#group_1-5
+ {
+ float: left;
+ width: 470px;
+ margin-left: 160px;
+ }
+* html #group_1-5
+ {
+ display: inline;
+ }
+#block_1
+ {
+ float: left;
+ width: 150px;
+ margin-left: 160px;
+ background-color: #ff0000;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 150px;
+ margin-left: -310px;
+ background-color: #00ff00;
+ }
+#block_3
+ {
+ float: left;
+ width: 150px;
+ margin-left: 10px;
+ background-color: #0000ff;
+ }
+#block_4
+ {
+ float: left;
+ width: 230px;
+ margin-left: 240px;
+ background-color: #999900;
+ }
+* html #block_4
+ {
+ display: inline;
+ }
+#block_5
+ {
+ float: left;
+ width: 230px;
+ margin-left: -470px;
+ background-color: #009999;
+ }
+#block_6
+ {
+ float: left;
+ width: 150px;
+ margin-left: -630px;
+ background-color: #990099;
+ }
+#block_7
+ {
+ float: left;
+ width: 310px;
+ margin-left: 320px;
+ background-color: #ffcc00;
+ }
+* html #block_7
+ {
+ display: inline;
+ }
+#block_8
+ {
+ float: left;
+ width: 310px;
+ margin-left: -630px;
+ background-color: #ff6600;
+ }
+#block_9
+ {
+ float: left;
+ width: 150px;
+ margin-left: 10px;
+ background-color: #660066;
+ }
+#group_4-5,
+ #group_7-8
+ {
+ margin-top: 10px;
+ }
+/* Start Mac IE5 filter \*//* */
+#block_1, #block_2, #block_3, #block_4, #block_5, #block_6,
+ #block_7, #block_8, #block_9
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ background-image: url(../images/backgrounds/rounded_TL.gif);
+ background-repeat: no-repeat;
+ }
+/* End Mac IE5 filter */
+@media all and (min-width: 0px) {
+#block_1, #block_2, #block_3, #block_4, #block_5, #block_6,
+ #block_7, #block_8, #block_9
+ {
+ padding-bottom: 0 !important;
+ margin-bottom: 0 !important;
+ /* mysterious 5 pixel shift - Opera I love you */
+ margin-top: -5px;
+ background-position: 0 5px;
+ }
+#block_1:before, #block_2:before, #block_3:before, #block_4:before, #block_5:before, #block_6:before,
+ #block_7:before, #block_8:before, #block_9:before
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px !important;
+ margin-bottom: -32767px !important;
+ height: 0;
+ }
+}
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ height: 20px;
+ background-image: url(../images/backgrounds/rounded_BL.gif);
+ background-position: 0 100%;
+ background-repeat: no-repeat;
+ }
+.wrapper .verticalalign
+ {
+ width: 150px;
+ }
+#block_4 .verticalalign, #block_5 .verticalalign
+ {
+ width: 230px;
+ }
+#block_7 .verticalalign, #block_8 .verticalalign
+ {
+ width: 310px;
+ }
+/* since we're using pixel widths we don't need to
+do the usual 100% fix for old Operas or IE */
+.verticalalign p
+ {
+ position: absolute;
+ bottom: 0;
+ right: 0;
+ margin: 0;
+ padding: 0;
+ background-image: url(../images/backgrounds/rounded_BR.gif);
+ background-position: 100% 100%;
+ background-repeat: no-repeat;
+ }
+/* IE Win shifts these snaps upwards - at some font-sizes (sigh) */
+* html #group_1-3 .verticalalign, * html #group_4-5 .verticalalign,
+* html #group_7-8 .verticalalign, * html #block_9 .verticalalign
+ {
+ bottom: -1px;
+ }
+/* IE Mac 5 makes a hash of the absolute positioning */
+* html>body .verticalalign
+ {
+ position: static;
+ width: 100% !important;
+ }
+* html>body .verticalalign p
+ {
+ position: static;
+ float: right;
+ }
+.wrapper_extra
+ {
+ position: relative;
+ }
+/* IE 5.01 doesn't like this */
+* html .wrapper
+ {
+ position/**/: relative;
+ }
+.wrapper
+ {
+ overflow: hidden; /* This hides the excess padding in non-IE browsers */
+ display: inline-block; /* Fixes nasty Opera7 scrolling bug */
+ }
+/* easy clearing */
+.wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+.wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+* html .wrapper
+ {
+/* only IE 5.01 should get this float value - otherwise 5.5 sometimes makes the width of wrapper too small */
+ float: left;
+ float/**/: none;
+ }
+.wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+.wrapper h2
+ {
+ z-index: 1000;
+ margin: 0;
+ padding: 10px;
+ background-image: url(../images/backgrounds/rounded_TR.gif);
+ background-position: 100% 0;
+ background-repeat: no-repeat;
+ }
+/* Firefox 1.0 doesn't like the pos:rel - cause text selection problems
+see http://archivist.incutio.com/viewlist/css-discuss/64928 for details */
+* html .wrapper h2
+ {
+ position: relative;
+ }
+.wrapper p
+ {
+ margin: 0;
+ padding: 0 10px 10px 10px;
+ }
+
+This example forms part of the Position is Everything article, In Search of the One True Layout.
++<div id="wrapper"> +<div id="group_1-8"> +<div id="group_1-6"> +<div id="group_1-5"> +<div id="group_1-3"> +<div id="block_1"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_2"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_3"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div#group_1-3 --> +<div id="group_4-5"> +<div id="block_4"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_5"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div#group_4-5 --> +</div><!-- close div#group_1-5 --> +<div id="block_6"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div#group_1-6 --> +<div id="group_7-8"> +<div id="block_7"> + ... +<div class="verticalalign"> ... </div> +</div> +<div id="block_8"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div#group_7-8 --> +</div><!-- close div#group_1-8 --> +<div id="block_9"> + ... +<div class="verticalalign"> ... </div> +</div> +</div><!-- close div#wrapper --> ++
+#wrapper
+ {
+ width: 790px;
+ }
+#block_1
+ {
+ float: left;
+ width: 150px;
+ margin-left: 160px;
+ background-color: #ff0000;
+ }
+#block_2
+ {
+ float: left;
+ width: 150px;
+ margin-left: -310px;
+ background-color: #00ff00;
+ }
+#block_3
+ {
+ float: left;
+ width: 150px;
+ margin-left: 10px;
+ background-color: #0000ff;
+ }
+#block_4
+ {
+ float: left;
+ width: 230px;
+ margin-left: 240px;
+ background-color: #999900;
+ }
+#block_5
+ {
+ float: left;
+ width: 230px;
+ margin-left: -470px;
+ background-color: #009999;
+ }
+#block_6
+ {
+ float: left;
+ width: 150px;
+ margin-left: -630px;
+ background-color: #990099;
+ }
+#block_7
+ {
+ float: left;
+ width: 310px;
+ margin-left: 320px;
+ background-color: #ffcc00;
+ }
+#block_8
+ {
+ float: left;
+ width: 310px;
+ margin-left: -630px;
+ background-color: #ff6600;
+ }
+#block_9
+ {
+ float: left;
+ width: 150px;
+ margin-left: 10px;
+ background-color: #660066;
+ }
+#group_4-5,
+ #group_7-8
+ {
+ margin-top: 10px;
+ }
+#group_1-8
+ {
+ float: left;
+ width: 630px;
+ }
+#group_1-5
+ {
+ float: left;
+ width: 470px;
+ margin-left: 160px;
+ }
+#wrapper, #group_1-3, #group_4-5, #group_1-5, #group_1-6, #group_7-8, #group_1-8
+ {
+ overflow: hidden;
+ position: relative;
+ }
+#block_1, #block_2, #block_3, #block_4, #block_5, #block_6,
+ #block_7, #block_8, #block_9
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ background-image: url(../images/backgrounds/rounded_TL.gif);
+ background-repeat: no-repeat;
+ }
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ width: 150px;
+ height: 20px;
+ background-image: url(../images/backgrounds/rounded_BL.gif);
+ background-position: 0 100%;
+ background-repeat: no-repeat;
+ }
+#group_4-5 .verticalalign
+ {
+ width: 230px;
+ }
+#group_7-8 .verticalalign
+ {
+ width: 310px;
+ }
+.verticalalign p
+ {
+ position: absolute;
+ bottom: 0;
+ right: 0;
+ margin: 0;
+ padding: 0;
+ background-image: url(../images/backgrounds/rounded_BR.gif);
+ background-position: 100% 100%;
+ background-repeat: no-repeat;
+ }
+#wrapper h2
+ {
+ margin: 0;
+ padding: 10px;
+ background-image: url(../images/backgrounds/rounded_TR.gif);
+ background-position: 100% 0;
+ background-repeat: no-repeat;
+ }
+#wrapper p
+ {
+ margin: 0;
+ padding: 0 10px 10px 10px;
+ }
+#footer
+ {
+ clear: both;
+ margin-top: 1em;
+ }
+
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="wrapper"> +<div id="block_1"> + ... +</div> +<div id="block_2"> + ... +</div> +<div id="block_3"> + ... +</div> +</div> ++
+body
+ {
+ direction: rtl;
+ }
+#block_1
+ {
+ float: right;
+ width: 34%;
+ margin-right: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: right;
+ width: 33%;
+ margin-right: -67%;
+ }
+#block_3
+ {
+ float: right;
+ width: 33%;
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+#footer
+ {
+ clear: both;
+ }
+
+This example forms part of the Position is Everything article, In Search of the One True Layout.
+Consider this design chunk, taken from a Tucows download page (NB. clicking on the link will prompt a download to begin).
+
+
+
+In situ, javascript is used to force the columns to be the same height. I understand why they've done it like this - by using a small rounded corner that paints white on the outside and leaves the "inside" transparent, the colour of the column frame can be changed by setting a different colour for the interior white element. This also has the advantage of allowing the heading to expand or contract if the font size is changed (not that it can in IE Win since the font size is set in pixels), rather than the heading text overflowing a fixed heading background.
+To create the inner curve, however, a background image using the same colour is needed which somewhat ruins the erstwhile "just change the value" benefit. If a user changes their font size the column heights will become incorrect. Granted the javascript could be enhanced to "listen" for such an eventuality, but it seems to be overkill for a possible but unlikely occurrence. Much more likely is that someone has javascript turned off.
+It's not such a terrible outcome, but frankly the javascript approach is unnecessary, since as we've seen CSS can do the job on its own.
+We shall leave the original markup as we found it and simply add new rules and override some already declared.
+
+
+
+.stepA .section3
+ {
+ background-color: #ffffff;
+ background-image: url(../images/tucows/tucows_background.gif) !important;
+ border-right: solid 8px #6bbd43 !important;
+ padding-right: 0;
+ width: 272px;
+ wid\th: 264px !important;
+ padding-top: 0;
+ margin-top: 0;
+ }
+.stepA div.sec3head
+ {
+ background: #6bbd43;
+ padding-top: 8px;
+ padding-bottom: 8px;
+ margin-top: 0;
+ margin-right: 0;
+ margin-bottom: 0;
+ }
+/* this is for IE Win < 6 */
+.stepA div.sec3int
+ {
+ margin-right: 0;
+ }
+This first step removes the burden of punching the white inside out of framed border from the interior element .sec3int. Though, at this point, since we've lost the bottom border we appear to be going backwards.
+
+
+.stepB
+ {
+ overflow: hidden;
+ }
+.stepB .section3
+ {
+ padding-bottom: 1000px;
+ margin-bottom: -1000px;
+ }
+Next we apply the Equal Height method.
+
+
+
+.stepC
+ {
+ position: relative;
+ }
+.stepC *
+ {
+ position: static !important;
+ }
+For the Vertical Grid method to work, we need to make sure that the rss buttons are positioned relative to the height of the entire row, not of each column.
+
+
+
+
+.stepD a.rss
+ {
+ position: absolute !important;
+ width: 270px;
+ bottom: 0;
+ margin-left: -16px;
+ padding-bottom: 8px;
+ border-bottom: solid 8px #6bbd43 !important;
+ }
+.stepD a.rss img
+ {
+ margin-left: 16px;
+ }
+We need to set position: absolute again because of our draconian position: static flush in the previous step. Then we create the column's bottom border by actually setting it on the RSS link. Safari and "good" Operas are now doing the business.
+
+
+html > body .wrapper
+ {
+ position: relative;
+ }
+html > body div.stepE
+ {
+ position: static !important;
+ }
+* html .stepE a.rss
+ {
+ bottom: -1px;
+ }
+IE Win, as per usual, gets things slightly out of register and needs shifting downwards. And because of Firefox 1.0's problems with overflow: hidden and position: relative combined on the same element, we surround the row with a wrapper div and shift the position to it. And we're done.
Works ok in IE Win 6, 5.5 and 5.01, Safari 1.03 and up, Firefox 1.0, Firefox 1.5, Opera 7, Opera 9 (beta) and iCab 3.0 (beta). Oh, and IE7 beta 2.
+It's no good in Netscape 7.2 (and presumably versions less than that). Hmmmm, and somewherew along the line it's stopped working in Netscape 8.
+Does not work in Opera 8 because of the overflow: hidden plus negative margin-bottom bug and I haven't been bothered to fix it.
IE Mac 5 doesn't work at all, but that's because the original doesn't - and I'm not getting into that kind of strife.
+Coping with these problems would, you know, be a lot simpler starting from a clean sheet, both HTML and CSS-wise. But that would have defeated the purpose of the exercise...
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Snap 1
Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Snap 2
Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ +Snap 3
This example forms part of the Position is Everything article, In Search of the One True Layout.
+Block 3 not showing up in the right place? Please read this first before sending a report.
++<div id="wrapper"> +<div id="block_1"> + ... +<div class="verticalalign"><p>Snap 1</p></div> +</div> +<div id="block_2"> + ... +<div class="verticalalign"><p>Snap 2</p></div> +</div> +<div id="block_3"> + ... +<div class="verticalalign"><p>Snap 3</p></div> +</div> +</div> ++
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+/* IE Win can be a bit out - you might need to adjust
+bottom value by -1px or as required */
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ }
+#block_1 .verticalalign
+ {
+ width: 34%;
+ }
+#block_2 .verticalalign
+ {
+ width: 33%;
+ }
+#block_3 .verticalalign
+ {
+ width: 33%;
+ }
+/* hack for Opera 7+ */
+@media all and (min-width: 0px){
+.verticalalign
+ {
+ width: 100% !important;
+ }
+/* But Opera 9 does it right, so CSS3 hax to the max */
+div[id^="wrapper"] #block_1 .verticalalign
+ {
+ width: 34% !important;
+ }
+div[id^="wrapper"] #block_2 .verticalalign
+ {
+ width: 33% !important;
+ }
+div[id^="wrapper"] #block_3 .verticalalign
+ {
+ width: 33% !important;
+ }
+}
+/* hack for IEs of all persuasions before IE7 */
+* html .verticalalign
+ {
+ width: 100% !important;
+ }
+.verticalalign p
+ {
+ position: absolute;
+ bottom: 0;
+ right: 0;
+ margin: 0;
+ padding: 0;
+ background: #996666;
+ }
+#wrapper
+ {
+ position: relative;
+ }
+/* we need this for IE 5.01 - otherwise the wrapper does not expand to the
+necessary height (unless fixed, this problem becomes even more acute
+weirdness as the method is enhanced */
+#wrapper
+ {
+/* Normally a Holly-style hack height: 1% would suffice but that causes
+IE 5.01 to completely collapse the wrapper - instead we float it */
+ float: left;
+/* NB. possibly only IE 5.01 needs to get this float value - otherwise 5.5 sometimes
+(I saw it happen many moons ago) makes the width of wrapper too small
+the float: none with the comment is ignored by 5.01,
+5.5 and above see it and carry on about their business
+It's probably fine to just remove it, but it's left here
+just in case that many moons ago problem rears its head again */
+ float/**/: none;
+ }
+/* easy clearing */
+#wrapper:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+#wrapper
+ {
+ display: inline-block;
+ }
+/*\*/
+#wrapper
+ {
+ display: block;
+ }
+/* end easy clearing */
+#footer
+ {
+ clear: both;
+ }
+
+Snap 1L
+Snap 1R
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+Filler
+ +Snap 2L
+Snap 2R
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+Filler
+ +Snap 3L
+Snap 3R
+Filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler filler
+Filler
+Filler
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +You'd probably feel cheated if I didn't roll out some more examples that give an idea of how these techniques could be put into action. So without further ado: [note]
+ +
Add columns! Switch the order around! Turn methods on or off! Toggle units! Support idiot browsers!
+You call the shots.
+ +
A pixel-based fixed width layout that shows just how crazy you can go repeatedly nesting the combined technique within itself.
+Not only is this a layout that would be impossible to achieve with a table-based layout [note], but the source ordering is a joy compared to how you'd have to do it [note]
+Of course, this version is somewhat overladen with hacks and additional markup. So, just to show how it could (nay, should and will) be, here's a slimmed down version that jettisons all the extraneous cruft. Of course, it only works in Safari... (and Firefox as of 1.5)
+ + +
A scalable em-based layout which is unremarkable other than the fact that it raises yet more questions about Opera's positional abilities, and that it would be nigh on impossible to achieve with Faux Columns.
+ +
A liquid percentage-based layout that is utterly unremarkable. Even Opera 8 doesn't require any particularly bizarre hacks.
+ +Results for these examples can be found in Appendix C.
+ +Unfortunately legal and intranet issues prevent me from showing you genuine working sites using these methods. Consequently I've brewed up a couple of quick makeovers that achieve much the same results as the orignals but using the now, all-too familar techniques.
+ +
A retrofit of an existing design pattern achieved without touching the underlying HTML.
+ +
Reimagined from the ground up as a scalable em-based layout without a table in sight.
+Yes, finally.
+ + + + + + + + + + +overflow: hidden bugs have been fixed, the hacks to make Opera 8 and under behave themselves trip Opera 9 up. Fortunately, ways and means exist to make things ok again, but it's probably just as sensible to ignore older versions of Opera.|
+ Block 6 Top +Source order = 1 +Colspan = 2 +Rowspan = 3 + |
+
+ Block 2 Top +Source order = 2 +Colspan = 2 + |
+
+ Block 1 Top +Source order = 3 +Colspan = 2 + |
+
+ Block 3 Top +Source order = 4 +Colspan = 2 + |
+
+ Block 9 Top +Source order = 5 +Colspan = 2 +Rowspan = 5 + |
+|||||
|
+ Block 2 Bottom +Source order = 6 +Colspan = 2 + |
+
+ Block 1 Bottom +Source order = 7 +Colspan = 2 + |
+
+ Block 3 Bottom +Source order = 8 +Colspan = 2 + |
+|||||||
|
+ Block 5 Top +Source order = 9 +Colspan = 3 + |
+
+ Block 4 Top +Source order = 10 +Colspan = 3 + |
+||||||||
|
+ Block 6 Bottom +Source order = 11 +Colspan = 2 + |
+
+ Block 5 Bottom +Source order = 12 +Colspan = 3 + |
+
+ Block 4 Bottom +Source order = 13 +Colspan = 3 + |
+|||||||
|
+ Block 8 Top +Source order = 14 +Colspan = 4 + |
+
+ Block 7 Top +Source order = 15 +Colspan = 4 + |
+||||||||
|
+ Block 8 Bottom +Source order = 16 +Colspan = 4 + |
+
+ Block 7 Bottom +Source order = 17 +Colspan = 4 + |
+
+ Block 9 Bottom +Source order = 18 +Colspan = 2 + |
+|||||||
Pure CSS-based layouts have come a long way but they still have shortcomings [note] that fail to address certain design goals without compromising the true separation of content and presentation.
+ +In short, the problematic design goals are these:
+ + +That is, the ability to order columns logically in the source while displaying them in any order desired. For any number of columns.
+ +Or more accurately, equal height columns without having to rely on faux columns.
+ +Designers face the choice of relying on elements being a particular height, resorting to tables or simply not bothering.
+ +This article shows how to achieve each of these goals, and then how to combine them, creating what could be called the One True Layoutâ„¢ [note].
+ +Several problems have been found with the Equal Heights method, detailed in Appendix J.
+Pure CSS-based layouts have come a long way but they still have shortcomings [note] that fail to address certain design goals without compromising the true separation of content and presentation.
+ +In short, the problematic design goals are these:
+ + +That is, the ability to order columns logically in the source while displaying them in any order desired. For any number of columns.
+ +Or more accurately, equal height columns without having to rely on faux columns.
+ +Designers face the choice of relying on elements being a particular height, resorting to tables or simply not bothering.
+ +This article shows how to achieve each of these goals, and then how to combine them, creating what could be called the One True Layoutâ„¢ [note].
+ +Several problems have been found with the Equal Heights method, detailed in Appendix J.
+A method for keeping columns (or more precisely, blocks of elements [note]) logically ordered in the source while still providing the designer the ability to display them in any order whatsoever without the need for any additional non-semantic markup.
+ + +Browsers that do not make use of the CSS positioning information will present the content in the order that it is marked up. Consequently the ordering of content in the source code is important as far as accessibilty [note] and assistive technologies are concerned. [note]
+The overriding rationale behind CSS is the separation of content and style - the removal of non-semantic cruft and complete ordering flexibility theoretically allows for repurposing of content without the need for tweaking html.
+Although this might be less useful for an individual's site where markup can be altered to accomodate design changes, this is a huge win for systems based on templates where changing the html is either impossible or undesirable.
+Furthermore it promises even greater customisability of a site for individual users. For instance, side columns could be swapped over or even placed on the the same side (though whether this would be a good idea or not is debatable).
+Search engine spiders/robots read web pages like this - they start at the top left, read across, and then move down. Consequently the ordering of content on a page is important as far as search engine algorithms are concerned. [note]
+ +Through the magic of floats and (when necessary) negative margins. Each block is floated in the following way:
+margin-leftIf we want the column blocks of our layout to be the same width and ordered 2-1-3, the maths work out like this:
+ +| + | leftmost point | +rightmost point | +margin-left | +
|---|---|---|---|
| Block 1 | +33% | +N/A | +33 - 0 = 33% | +
| Block 2 | +0% | +67% (Block 1) | +0 - 67 = -67% | +
| Block 3 | +67% | +67% (Block 1) | +67 - 67 = 0% | +
So given this HTML markup...
+<div id="block_1"> + ... +</div> +<div id="block_2"> + ... +</div> +<div id="block_3"> + ... +</div>+ +
... we apply the following CSS:
+#block_1
+ {
+ float: left;
+ width: 34%;
+ margin-left: 33%;
+ }
+#block_2
+ {
+ float: left;
+ width: 33%;
+ margin-left: -67%;
+ }
+#block_3
+ {
+ float: left;
+ width: 33%;
+ }
+
+Units can be percentages if the layout is liquid, ems or pixels if fixed width. [note] [note]
+ +Of course not. It never is, is it? This method runs head first into a peculiarity in the layout engine of IE Win (5 and 6) - if block 1 is not the first column, it requires its margin-left to be divided by 2.
+Investigating further, we find that the bug is triggered for any block n (where n is the position of the block within the source code) if:
+ +Under such circumstances element n will require its margin-left to be reduced - the overall number of columns appears to be irrelevant.
+Keen readers will have noticed and been chomping at the bit to point out that this is the dreaded IE Doubled Float-Margin Bug. Well spotted. The good news is that the usual fix works just fine.
+All that is required is display: inline targeted at IE for the element in question. It's only the first such block in the source ordering that needs this "hand holding" and once the fix is in, it magically sorts out any following elements which would otherwise need the fix.
So in the code example, block 1 is to appear as column 2 and triggers the bug, since its column position is equal to 2 times its source position [note]. Consequently we need to add the following CSS:
+* html #block_1
+ {
+ display: inline;
+ }
+Example of the basic Any Order technique (2-1-3 ordering) [note]
+So it's very nearly that simple. Or rather it is that simple. It's actually possible to simply set all the column elements to display: inline (as far as IE is concerned) without any unfortunate side effects and without any need to work out whether any of the column blocks need the hand-holding or not. [note]
As things stand in the example, there's no wrapper/container element holding the columns together. More often than not, you're going to want or probably even need one. Most likely, if you want to apply a faux-columns style background to the columns (or utilise the techniques developed later in this article), there's the not-so trivial matter of making sure that the container expands to fully contain the columns. And so the simple method sketched out so far becomes a little messier again.
+Over the years, several non-cruft-introducing methods have been invented to deal with this. Unfortunately though, the overflow: hidden method causes everything to just blow up. And a bug in Firefox/Mozilla means that you can't use the simple floated container method, if, but only if, the longest column has actually been negatively shifted. That's a pretty big if, though. Using display:table works fine for a pure any order solution, but I've not used it here because it runs into trouble later on.
Fortunately, the original (and still the best ;) EasyClearingTM works just fine, if somewhat more verbosely than the alternatives.
+Example of the Any Order technique with containing element (2-1-3 ordering)
+The method even holds up if you want to use direction: rtl. In that case you just switch right for left in the column float and margin declarations.
Example of the Any Order technique as a right-to-left layout
+This method is, being a float-based method, prone to the usual float method problems. Because IE (both Win and Mac) violates the specs and expands elements to be at least the width of the largest nested element, things can get funky. This means that unexpectedly wide images or long unbroken strings of text will cause havoc with the layout.
+NB. these problems are intrinsic to any float techniques in IE, and are not caused by the use of negativity itself, but because elements are being negatively shifted, an unexpected float wrap could cause some of those elements to be placed beyond the left edge of the viewport. Consequently, particular care should be taken with the following issues:
+Other likely IE problems can be found at Position Is Everything's Explorer exposed! and Windows Explorer vs. the Standards. See also On having layout, the extremely thorough dissection of IE's layout engine quirks.
+ + +IE Win 7 beta 2, IE Win 6, IE Win 5.5, IE Win 5.01, IE Mac 5, Operas 7, 8 and 9, Firefox 1.5 [note] and 1.0, Netscape 8, Safari 1.03 (and up), OmniWeb 5
+ +If the longest block has been negatively shifted under any circumstances (either directly or indirectly, so that it displays before any block that precedes it in the source order), its height is ignored. Instead Netscape treats as longest the longest block that has not been negatively shifted. This can cause any following elements to not be cleared correctly. Apart from that massive stumbling block, it works just great.
+This technique does not work in Opera 6 or Netscape 4. As is. That's right, it's possible to even make it work in those browsers if you really want to. That's so insane though, that I'm putting the details of how in this appendix.
+Opera 5 is another matter - the blocks never become columns, stretching to fill the width of the container and stacking up on top of each other just as if they were regular unfloated blocks. Except that the column background colours don't show up. Well, if you must support Opera 5...
+IE 4? I've got no idea. I can't get it to run on any of the Windows machines I've got access to. I don't imagine that it will behave very well though. Or in IEs 2 or 3. Or Netscape 2 or 3.
+ +The method is both robust and generic. It allows for proper logical source ordering with the flexibility to layout in pretty much any manner. [note]
+However, it is certainly true that the columns can shift a pixel or two when percentages are used. If you can guarantee the longest column, the Ordered Absolute method gives more precision for percent-specified layouts.
+And if you can bear a bit of javascript, Absolutely Positive, Shaun Inman's routine for "clearing" absolutely positioned elements, offers a potentially much more powerful method for achieving all this and more.
+Tom Wright's CSS Negative Margins Algebra is another CSS-plus-negatively- margined-float approach that's more than worth a look. While perhaps not being as generic as this method, it does allow you to completely remove any interdependence between the positional CSS and the underlying semantics.
+The original Source Ordered Columns [note] goes a long way towards satisfying the same issues that the Any Order technique does, but it requires a semantically unnecessary inner wrapping tag to group some of the columns together. This reliance on an inner wrapping tag also limits the number of possible column orderings. Removing the need for the inner wrapper allows all possible orderings to be achieved (though the inner wrapper can serve other purposes. See Appendix H for the theory of possible orderings.
+It would be criminal not to mention Ryan Brill's Creating Liquid Layouts with Negative Margins, Thierry Koblentz's neat riff on Ryan's original 3 columns fluid layout, Doug Livingstone's CSS Columns and Position is Everything's Piefecta
+All these methods provide a way for mixing pixel widths in liquid layouts. A variation on the basic Any Order technique which can achieve the same results can be found here.
+Because the web never sleeps...
+Eric Meyer had a brainwave in the middle of a workshop and came up with Multi-Unit Any-Order Columns which does exactly what it says on the tin.
+Matthew Levine went questing for a better way to mix pixel widths into liquid layouts in In Search of the Holy Grail.
+ + +Now that we have the freedom to put our columns in any old order, let's move on to that perennial CSS favourite, how to make them the same height.
+ + + +Several problems have been found with this technique since publication. Those problems are discussed in Appendix J
+As an astute disciple of CSS, you are probably about to point out that there is a well-known tried and tested method for this (and as already mentioned earlier in this article), the one popularised in Dan Cederholm's Faux Columns. If so, just wait - we are returning to the scene of the crime...
+ +The real credit for this technique belongs to Mark Challoner who had the crucial insight - I have merely helped polish it to the point where you can see your boots in it.
+ +What it says on the tin - a method to make all columns appear to be the same height. But without the need for faux column style background images.
+ +Because equal height columns are a perfectly reasonable design goal. And the even more astute disciple will be nodding sagely, ruminating over the problems that flow from faux columns. Namely:
+The most astute disciple is already one step ahead and is awaiting the pronouncement that Faux Columns are dead. I wouldn't go that far - in fact, they probably remain the weapon of choice. However, the method about to be described certainly provides an alternative that overcomes the problems above in some, if not all, circumstances.
+ +The basic method works like this:
+overflow: hidden to the container elementpadding-bottom: $big_value [note] to the column blocks, where $big_value is a large enough value to guarantee that it's equal to or larger than the tallest columnmargin-bottom: -$big_value to the column blocksWhat happens is that columns really become as tall as the content they contain plus $big_value thanks to the padding-bottom. The negative margin-bottom brings the flow of the document back to where the same point as where the padding-bottom began, and the overflow: hidden on the containing element chops off the overflow[note]. Consequently the columns' presence on the page only appears to be the height of the containing element and any background colour (or image for that matter) applied to the columns displays for that height. Most crucially, the height of the page reflects what appears to be on the page and does not dissappear into the scrolling distance.
Remarkably, IE Win doesn't actually need the overflow: hidden, but it causes no problems so there is no need to hide it.
Beware though, browsers don't let you throw arbitrarily large values at them. They have limits. Exceed that limit and the columns will expand to the padding-bottom value and you'll end up wiuth some pretty long pages. Fortunately, we know the number of that limit (which is actually provided by Safari which is the most conservative browser in this matter): 32767px. This should suffice for most cases (though feel free to use a smaller value) and yields us code like this:
#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ }
+#wrapper
+ {
+ overflow: hidden;
+ }
+
+Now if you wanted to actually achieve a 0.5em padding-bottom on the column, then you'd need code like this: [note]
+ +#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ padding-bottom: 1000em;
+ margin-bottom: -999.5em;
+ }
+
+There seems to be a consensus that pixel values are usually a better bet for this type of malarkey. So, unless you need to do something like the previous example, it's wisest to stick to pixel values - especially since an em-based value which might seem fine at one font setting can end up breaking the browser's actual limit when increased.
+ +Of course, it's only to be expected that things aren't quite that simple, and that we'll need to polish things up before this is production-ready.
+I'm not sure exactly which versions of Safari this effects, but the padding-bottom has a ghost effect that, though the columns are painted correctly, links and form elements that follow the columns and that by rights should be above it, are unclickable. (Fixed as of 4 November 2005)
+This problem can be overcome by setting position: relative on any of the necessary elements. However, An unintended side-effect is that it cause such elements to vanish in IE Wins, 5.01 and 5.5, so we need to prevent those browsers seeing the position: relative.
For example, if we had an element with the id "affected_element", we would add the following: [note]
+* > #affected_element
+ {
+ position: relative;
+ z-index: 1000;
+ }
+IE5 Mac gets the column heights right, but the height of the page ends up including the invisble padding. Whether or not you think this is acceptable is up to you, but a simple backslashed comment hack will prevent IE5 Mac from doing the whole equal heights expansion. Graceful degradation, baby...
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ }
+/* End Mac IE5 filter */
+Operas 7.0 through 7.2 don't actually chop off the extended columns at the right place. For sure they don't march off quite as far as the numbers would make you think they would, but that's little comfort when you've got huge columns obliterating all in their path.
+Adding display: inline-block to the container element would solve this, but it would cause other problems to pop out from under the Opera bug carpet which are possibly fixable, but life's just too short - the most robust solution is to add our old friend EasyClearing, and all's well again.
Apart from in IE Win 5.01, where the addition of the easy clearing causes the exact opposite to happen - ie. where before all was well, now the columns stretch off into the distance. Because of Opera, mind. Fortunately, we can just add a float: left; and 5.01 is happy again.
* html #wrapper
+ {
+ float: left;
+ }
+Example of the Equal Height Column technique (2-1-3 ordering)
+ +Opera 8 introduced a bit of a bug to its handling of overflow: hidden. So, even though the easy clearing is enough to sort out the lesser Operas (though note that 7.54 works just fine without any "help"), we are again faced with columns that wouldn't look out of place in The Towering Inferno.
Fortunately, once more there is a fix. The large padding-bottom/negative margin-bottom routine needs to removed from the columns themselves and applied to elements within them instead.
+The most obvious way to achieve this would be to set a class on the final element in each of the columns, but that would be bad since a) you need to add the class in, and b) the class is essentially playing the same role as a clearing break element - since the class is actually a structural aid rather than saying anything about what's actually within the element in question.
+Better is to use the :after pseudo element which we can rely on since we're targeting a modern browser. Rather than using padding-bottom, we use padding-top instead, since we can't rely on visibility: hidden to hide the generated content. Because otherwise the generated content doesn't actually increase the height of the column, somewhat defeating its purpose.
Of course, removing the padding-bottom from the columns causes all the other browsers to collapse the columns. We could hide the removal from IE Wins with a child descendant hack, but that wouldn't help Safari and Firefox. So we reach into our box of tricks and pull out the @media query hack [note].
Here's what the addional Opera 8 code looks like:
+/* Start Mac IE5 filter \*/
+#block_1, #block_2, #block_3
+ {
+ padding-bottom: 32767px;
+ margin-bottom: -32767px;
+ }
+/* End Mac IE5 filter */
+@media all and (min-width: 0px) {
+#block_1, *#block_2, #block_3
+ {
+ padding-bottom: 0;
+ margin-bottom: 0;
+ }
+#block_1:after, #block_2:after, #block_3:after
+ {
+ content: '[DO NOT LEAVE IT IS NOT REAL]';
+ display: block;
+ background: inherit;
+ padding-top: 32767px;
+ margin-bottom: -32767px;
+ height: 0;
+ }
+}
+
+Example of the Equal Height Column technique with a fix for Opera 8 (2-1-3 ordering)
+ +The good news is that the beta version of Opera 9 fixes the bug in Opera 8. Considering the relatively small proportion of Opera users and the likelihood of such users to upgrade often and early, it's probably OK to just leave out the Opera 8 fix.
+On the other hand, if you want to figure out how to distinguish Operas 8 and 9, I'm not going to stop you.
+ +Just in case you missed the bit at the top of the page, several problems have been found with this technique since publication. Those problems are discussed in Appendix J
+IE Win 7 beta 2, IE Win 6, IE Win 5.5, IE Win 5.01, Operas 7, 8 and 9, Firefox 1.5 and 1.0 [note], Netscape 8, Safari 1.03 (and up), (OmniWeb5.0?)
+ +The longest column must not have been negatively shifted under any circumstances otherwise we're in the same old boat of following elements not being cleared correctly as with the Any Order Columns method. But with an added twist. Since the containing element has been set to overflow: hidden, anything in the columns below the point that Netscape mistakenly believes is the endpoint of the columns is cut off and not displayed.
As mentioned previously, the method causes the page to expand to the "actual" height of the columns. The choice is yours whether to accept that or to forego the equal heights in this superannuated browser, currently tottering around the edges interweb waiting to be put out of its misery.
+ +Do not understand the method at all. It is left as an exercise to the reader to figure out the necessary hacks to cope with those browsers if required.
+ +This method is fairly robust, generic and nestable.
+It can get a little gnarly under certain circumstances - in Operas and IE Win 5.01 (see the expanded examples for details.)
+Faux Columns have already been discussed. Ingo Chao has a faux columnless two em-based columns with equal height.
+Modern browsers hold out the promise of being able to use display:table to achieve much the same effect. However once you have chosen that route you are stuck with a rigid table structure. There is no way you can reorder the column blocks. Moreover, browser support for positioning elements relatively or absolutely within a table cell, whether the cell actually a td, th or another element with display:table-cell) is non-existent except for some slight support in iCab 3.0. Apparently. Which puts you back to square one having to write markup that looks like a traditional table.
Now that we have our revised mechanism for making columns the same height, it's time to turn our attention to how to position elements vertically within those columns.
+ + + + +A method enabling the vertical positioning of elements across grids/columns
+ +
Because it's a perfectly reasonable demand that designers should be able to control the vertical as well as the horizontal axis.
+Some may argue that designers shouldn't even have control over the horizontal axis, but if you agree with that position what the hell are you doing reading this article?
+Still reading?
+The age old method for dealing with vertical positioning is to use tables. Stick what needs to be top aligned in cells in one row; what needs to be bottom-aligned goes in the row that follows.
+The good thing about the table-based way is that it works.
+The bad things about the table-based way is that it forces the designer to separate logically connected elements into an arbitrary source order dictated by the design alone. Which is bad from the semantic point of view but even worse from the practical one, since it leads inexorably to the creation of gnarly, nested, hard-to-maintain tag soup.
+It also means that bottom-aligned elements must appear below all the elements within the top-aligned block and not level with the last element within it as might be desired. Or middle-aligned.
+However, it does work and does so reliably which counts for a lot when it comes to web development. It doesn't stop it being utterly dirty though.
+No, not you. The elements within which I want to vertically align things.
+This is the other more modern approach - as long as you know the height of the column elements then you can just set position: relative on the column element and then any elements within it just need position: absolute.
To know the height, you have to know that your content will be that height (eg. the only content in the "flow" will be images which are the same height across the columns - over which you then position your text and any other images) or that your content will not make the element be higher than that and set the height attribute.
Which is fine so far as it goes, but as soon as you need any kind of vertical liquidity, then this approach breaks down. Which is why so many designers simply don't bother.
+ +The problem with the modern approach is that it's not possible to guarantee the height of the individual column blocks.
+However, we can rely on the height of the containing element by applying any of your favourite float clearing methods to ensure that the container element does indeed contain the columns. After that, it's just a matter of applying position: relative to the container element.
Now if we apply position: absolute to any element within the column blocks, it will be vertically positioned relative to the container element.
Which gives us the ability to snap things to the bottom or middle of the grid across all the columns.
+ +Of course, it also means that the element will be positioned relative to the container tag horizontally as well.
+ +This isn't a problem though if all we want to do is shift the element vertically. As long as we only set the element to appear at, say, bottom: 0 or top: 50%, then it will appear horizontally aligned with the column it's in. If we want to shift the element from the left edge of the column, all that's needed is a suitable amount of margin-left.
But what if we do want to offset the element from the column's right edge (which truth be told, is the most likely use for this)?
+The simplest, if not the easiest, solution is to set individual right values, where those values are equal to 100 - the value of the rightmost point of the column. [note]
Example of the Vertical Grid technique (simple version with 2-1-3 ordering)
+ +If you just looked at the previous example in Opera (7 or 8, forget about 6), you might have noticed that things are a little off.
+First off, it fails to get the vertical positioning right at all if percentages are used. That's why the "L" Snaps are at the very top of the containing tag and don't start in the middle as they ought to.
+Adding float: left and an explicit width: 100% almost solves things, but not well enough. Block 1's snap still floats to the top and none of the elements picks up on the height: 50%. It looks like Opera is a hopeless case, and the best that can be achieved if Opera must be catered for is aligning to the absolute top or bottom using pixels or ems.
Secondly, the horizontal shifting works sometimes. That is sometimes it doesn't, failing to apply background colours and shifting the element less than it actually requires. I can't figure out the cause of this monkey business at all (it doesn't appear to be the negative margins since it fails even more spectacularly when ordered 1-2-3) which means that there is no simple CSS fix. (And this is the case whether the layout is percentage-, em- or pixel-based.)
+Which means...
+We need a markup fix. If we wrap the element we want positioned on the right, that element can be made to be the width of the column and then absolutely positioned on the right within it.
+As if it's not bad enough that it's a markup fix (though since it's just an additonal wrapping tag, it's low down the scale of markup atrocities), we now run into the different models that browsers use to calculate the width of nested absolutely-positioned elements. To be blunt, Opera and IE Win make it easy, but get it wrong (according to the standards, that is, but that's the only game in town).
+So for Opera and IE Win all we need to do is:
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ width: 100%;
+ }
+.verticalalign p
+ {
+ position: absolute:
+ right: 0;
+ bottom: 0;
+ }
+
+NB. floating the inner element would probably do just as well in most situations
+ +But because, Safari and Mozilla get it right, that would make the element-to-be-aligned 100% of the wrapping element. The correct value for the width in those browsers is the actual width of their parent elements. So now we add:
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ width: 100%;
+ }
+#element_1 .verticalalign
+ {
+ width: 34%;
+ }
+#element_2 .verticalalign
+ {
+ width: 33%;
+ }
+#element_3 .verticalalign
+ {
+ width: 33%;
+ }
+Of course, .verticalalign is now too narrow in Opera and IE! So we plump them back up again with a media query hack for Opera (subject to the same caveats as before), and a star html hack for IE. Hey presto!
/* hack for Opera 7+ */
+@media all and (min-width: 0px){
+.verticalalign
+ {
+ width: 100% !important;
+ }
+}
+/* hack for IEs of all persuasions before IE7 */
+* html .verticalalign
+ {
+ width: 100% !important;
+ }
+
+As of the beta version of Opera 9, the position and dimensions of absolutely positioned and fixed position elements are treated correctly when they are nested inside each other (except for that vertical percentage thing mentioned above). So now the width: 100% gets applied as it should. Which screws things up big time.
As I said on the previous page, there is such a relatively small number of Opera users (who in all likelihood upgrade often and early), that it's probably OK to just leave out the Opera 8 fix.
+Mind you, if you do want to figure out how to distinguish Opera 9 from previous versions, I'm really not going to stop you. Well, actually I am. You see, I've already got one. CSS3 attribute selectors to the rescue!
+/* hack for Opera 7+ */
+@media all and (min-width: 0px){
+.verticalalign
+ {
+ width: 100% !important;
+ }
+/* But Opera 9 does it right, so CSS3 hax to the max */
+div[id^="wrapper"] #block_1 .verticalalign
+ {
+ width: 34% !important;
+ }
+div[id^="wrapper"] #block_2 .verticalalign
+ {
+ width: 33% !important;
+ }
+div[id^="wrapper"] #block_3 .verticalalign
+ {
+ width: 33% !important;
+ }
+}
+Example of the Vertical Grid technique (2-1-3 ordering)
+ +IE Win 7 beta 2, IE Win 6, IE Win 5.5, IE Win 5.01, Operas 7, 8 and 9, Firefox 1.5 and 1.0, Netscape 7 and 8, Safari 1.03 (and up)
+ +Pretty much works - but absolute positioning is flaky at the best of times in this tired old workhorse
+Do not understand the method at all. It is left as an exercise to the reader to figure out the necessary hacks to cope with those browsers if required.
+ +It's a bit finickity, but the technique is pretty sturdy unless you must support older browsers.
+You could instead reach for display:table but that results in, frankly, equivalent but less readable code than tables. And you can't then position elements absolutely within the table cells[note]. And even if the positioning was possible, you'd be stuck with the intial source ordering of the columns...
Of course, it should all be so much easier than this, as Eric Meyer laments in CSS Gridlock.
+ + +The individual pieces are in place - time to bring the holy bacon home.
+ + +Back in the introduction, I made a rash claim - that I could conjure up a layout that satisfied:
+Now comes the magic moment. We've seen how to solve each of these problems in isolation. What happens if we just stick them all together?
+ +Well, to cut to the chase, it works in all the browsers that the individual techniques work in. Except... and it almost makes me weep to say it. Except Firefox 1.0.
+ +Example of the One True Layoutâ„¢ (2-1-3 ordering)
+ +This time we've run into a delightful bug. If an element has position:relative and overflow:hidden but no explicit height, then nested elements positioned absolutely within it vanish completely in Firefox 1.0. And until this is fixed, there is no CSS workaround for it.
This bug has been fixed in Firefox 1.5. Indeed, it was fixed in the Gecko engine as of version 1.8b2.
+It's time for another markup fix. We can't dispense with either the position:relative or overflow:hidden, but we can remove the overflow from #wrapper and apply it to another element that we put around it:
<div id="wrapper_extra"> +<div id="wrapper"> +<div id="element_1"> + ... +<div class="verticalalign"><p>Snap 1</p></div> + +</div> +<div id="element_2"> + ... +<div class="verticalalign"><p>Snap 2</p></div> +</div> +<div id="element_3"> + ... + +<div class="verticalalign"><p>Snap 3</p></div> +</div> +</div> +</div>+ +
#wrapper_extra
+ {
+ position: relative;
+ }
+#wrapper
+ {
+ overflow: hidden;
+ position: relative;
+ }
+This placates the mysterious Firefox bug, but causes IE to lose the plot. No matter, that's easy to fix:
+* html #wrapper
+ {
+ position: relative;
+ }
+Example of the One True Layoutâ„¢ with a fix for Firefox (2-1-3 ordering)
+ +As previously noted, it works everywhere the individual techniques do. See Appendix B for all the gory details.
+ +Would sir care to peruse some more involved examples?
+You'd probably feel cheated if I didn't roll out some more examples that give an idea of how these techniques could be put into action. So without further ado: [note]
+ +Add columns! Switch the order around! Turn methods on or off! Toggle units! Support idiot browsers!
+You call the shots.
+ +A pixel-based fixed width layout that shows just how crazy you can go repeatedly nesting the combined technique within itself.
+Not only is this a layout that would be impossible to achieve with a table-based layout [note], but the source ordering is a joy compared to how you'd have to do it [note]
+Of course, this version is somewhat overladen with hacks and additional markup. So, just to show how it could (nay, should and will) be, here's a slimmed down version that jettisons all the extraneous cruft. Of course, it only works in Safari... (and Firefox as of 1.5)
+ + +A scalable em-based layout which is unremarkable other than the fact that it raises yet more questions about Opera's positional abilities, and that it would be nigh on impossible to achieve with Faux Columns.
+ +A liquid percentage-based layout that is utterly unremarkable. Even Opera 8 doesn't require any particularly bizarre hacks.
+ +Results for these examples can be found in Appendix C.
+ +Unfortunately legal and intranet issues prevent me from showing you genuine working sites using these methods. Consequently I've brewed up a couple of quick makeovers that achieve much the same results as the orignals but using the now, all-too familar techniques.
+ +A retrofit of an existing design pattern achieved without touching the underlying HTML.
+ +Reimagined from the ground up as a scalable em-based layout without a table in sight.
+Yes, finally.
+ + + + + + + +The Any Order and Vertical Grid techniques are fundamentally simple. More importantly, they will carry on working for as long as browsers support CSS2.1. All that will change is the dropping some of the hacks which are only needed to help the current crop of browsers (Safari notwithstanding - and Gecko once they get that regression bug fixed). That is, the techniques will improve over time. Why? Because these techniques do exactly what the specs say you can do.
+ +On the other hand, the Equal Height technique is a kludge - despite the fact that the basic concept is solid and that any future browsers that are properly conforming will support it (Or maybe not...). But it's only needed because display: table-cell doesn't allow for a) reordering the columns, or in today's mainstream browsers at any rate, b) absolute or relative positioning.
There was a whole lot of stuff that didn't really fit in the article and has been shunted into appendices. Of these, the most interesting is probably the one on creating any order columns with liquid center and fixed-width sides. Seeing as people like that kind of thing for some reason.
+ +The techniques described in this article were almost completely worked out around Christmas 2004. Unfortunately by the time I got round to actually publish them, the beta of Opera 8 had been released. It's only recently that I was able to spend the time to figure out a fix for that.
+ +And now the latest beta version of the Gecko engine is upon us and causing even more havoc. Well tough. This time I'm publishing. I refuse to be bowed once again by a browser's failing - especially where that failing is a reversal of previous correct CSS support.
+ +Opera 9 was released in beta the day before this article was first published. It fixes all the bugs mentioned throughout this article. And then the Mozilla team fixed the bug that screwed up the Any Order method and incorporated the fix at double quick time on 2 November 2005. All's well that ends well.
+ +All that's left to say, is "Rock on IE7"! [note]
+ +... actually IE7 (as of beta 2) seems to pretty much work, though when zooming, things can go a bit awry if percentages have been used. The only tweaks needed seem to be those instances where * html has been used to hide the forcing of hasLayout on IE and where IE7 still needs it - eg. the plain vanilla vertical grids.
When first working on the Any Order Columns method, I spent an entire evening barking up the wrong garden path trying to figure out a crack-fuelled formula that would cope with IE's margin shifting problems. However, as John Gallant pointed out to me, it was just the IE Doubled Float-Margin Bug. Without Big John pointing out what now seems hilariously obvious in hindsight, I would have abandoned the whole exercise since my hacked-up approximations would never have done for "real world" usage. He also, as always, provided much encouragement and useful advice.
+As noted in the course of the article, the Equal Height Columns method was actually invented by Mark Challoner and posted to [css-d] in November 2004. Strangely that announcement passed by with barely a murmur. Possibly it was because there were still some issues with the technique (though usually that spurs [css-d] into action). Mark and I continued to bash away at the technique until it was polished into pretty much the form you see here. Indeed, it was Mark's crucial insight that led me to embark on this whole mad crusade.
+Thanks also to Ingo Chao, Bob Easton, Zöe Gillenwater, Eric Meyer, Gunlaug Sørtun, Ryan Thrash and Philippe Wittenbergh for help and comments at various stages of this article's development.
+ +Massive thanks to the Mozilla team for fixing the negatively-margined float bug in record time and getting the fix into Firefox 1.5.
+Thanks also to: Andrey Petrov for reporting and suggesting fix for IE6 bug in basic demo; Donna Casey for reporting the crazy text scroll problem that Firefox 1.0 has with the Nested Rounded example and Ingo Chao for coming up with a simplified test case and fix for it; Andrew Soderberg for pointing out the printing problems in IE; Bill Wallace and Chris W Parker for suggesting moving #footer's clear:both into the core css and out of the ancillary css file; Rob Cochrane for spurring me on to add support for direction:rtl; Philippe Wittenbergh (again) for creating copious test cases and pointing out the Opera 9 overflow:hidden behaviour change was for passing the Acid 2 test; Ingo Chao (that man again) for half slaying the anchor problems in Geckos.
In chronological order, the following reported the problems with links to anchors with equal height columns: Leevi Graham, Bryan Buchs, Vitaly, Xavier Guilbert, Justin Watt, Micah Wylde, Thoreau Lovell, Trevor Creech, Neil Drumm, Sebastiaan van Achterbergh, Vince Bishop, joey3xRoadRunner, Michael Hickland, Jakub Wojtaszczyk, Eric Everman, Jennifer Hiller, Franck Bossy, Jörn Hofer, Keisuke Omi, Stefan Schlachter, Jesse Scott, Christopher M Kelly, Ischa Gast and Kevin White.
+ +For browsers which exist for different platforms, the results are the same unless expliclty mentioned.
+ +| Browser | +Any Order | +Equal Heights | +Vertical Grid | +Combined | +
|---|---|---|---|---|
| IE Win 7 beta 2 | +pass | +pass | +fail (mild) [note] | +pass | +
| IE Win 6 | +pass | +pass | +pass | +pass | +
| IE Win 5.5 | +pass | +pass | +pass | +pass | +
| IE Win 5.01 | +pass | +pass | +pass | +pass | +
| IE Mac 5.2 | +pass | +fail (mild) [note] | +fail (mild) [note] | +fail (mild) [note] | +
| Firefox 1.5 | +pass | +pass | +pass | +pass | +
| Firefox 1.0 | +pass | +pass | +pass | +pass [note] | +
| Netscape 8.0 | +pass | +pass | +pass | +pass | +
| Netscape 7.2, 7.1, 7.0 | +pass [note] | +pass | +fail (mild) [note] | +pass | +
| Netscape 6.2, 6.1 | +pass [note] | +pass [note] | +fail (severe) [note] | +fail (severe) [note] | +
| Netscape 6.0 | +fail (total) [note] | +untested | +untested | +untested | +
| Netscape 4.7 | +fail (fixable) [note] | +untested | +untested | +untested | +
| Opera 9.0 (beta) | +Pass | +Pass | +Pass[note] | +Pass | +
| Opera 8.0, 8.5 | +pass | +pass | +pass | +pass | +
| Opera 7.5 | +pass | +pass | +pass | +pass | +
| Opera 7.2, 7.1, 7.0 | +pass | +fail (severe) [note] | +pass | +fail (severe) [note] | +
| Opera 6 | +fail (fixable) [note] | +fail [note] | +fail [note] | +fail [note] | +
| Opera 5 | +fail (total) [note] | +untested | +untested | +untested | +
| Safari 2.0, 1.3, 1.2, 1.03 | +pass | +pass | +pass | +pass | +
| OmniWeb 5.0.1 | +pass | +pass | +pass | +pass | +
| iCab 3.02beta | +pass | +pass | +pass | +pass | +
| iCab 3.01beta | +pass | +pass | +fail (total) [note] | +fail (total) [note] | +
| IE Win 7 beta 2 | +|
|---|---|
| Vertical Grid | +
+ Example as it stands fails +Solution is to force get |
+
| IE Mac 5.2 | +|
| Equal Heights | +
+ By not feeding IE Mac the padding- and margin-bottom values that are behind the equal height, we get an acceptable degradation - if IE Mac 5 really must be catered for, then it's nothing faux-columns suitably applied can't handle +On the other hand, if IE Mac 5 does get to see the padding- and margin-bottom values, the failure is catascrophic as it makes the page that height + |
+
| Vertical Grid | +
+ Snaps placed above wrapper div (despite being able to paint wrapper's background to the correct height) +Solution is to not give IE Mac 5 the absolutely positioning for snap and to just let it take its place in the flow + |
+
| Combined | +
+ Now the snaps vanish entirely +The fix is the same as the solution for snapped elements without equal columns + |
+
| Firefox 1.0 | +|
| Combined | +
+ A bug when #wrapper's However, by wrapping another div around #wrapper and moving It's annoying that this has to be done, but so far it's the only known fix + |
+
| Netscape 7.2, 7.1, 7.0 | +|
| Any Order | +
+ See article body for details + |
+
| Vertical Grid | +
+ Snaps placed correctly to the bottom of the wrapper div, however 1em additional bottom margin sneaked into the wrapper div and so the snaps are 1em below the bottom of the longest column. +But check the combined result... + |
+
| Netscape 6.2, 6.1 | +|
| Any Order | +
+ Same caveat as for NS7 + |
+
| Equal Heights | +
+ Some elements beneath the wrapper appear not to be able to receive clicks - the footer is ok so there you go + |
+
| Vertical Grid | +
+ Snaps vanish +... and where they gos, nobody knows + |
+
| Combined | +
+ Netscape 6.1 +Since the snaps fail, unsurprisingly the combination fails too - the equal height stuff still works just fine + |
+
| Netscape 6.0 | +|
| Any Order | +
+ Columns simply stack up on top of each other + |
+
| Netscape 4.7 | +|
| Any Order | +
+ See the appendix that deals with older browsers. + |
+
| Opera 9.0 (beta) | +|
| Vertical Grid | +
+ To get Opera 9 and 8 to play together at the same time requires some mundane if verbally spectacular and verbose hackery. Of course, you could just drop support for Opera 8... + |
+
| Opera 7.2, 7.1, 7.0 | +|
| Equal Heights | +
+ Percent works just fine. +Pixels and ems go haywire and extend the columns. + |
+
| Combined | +
+ Percent also stops working in just the same manner as the equal height failure. + |
+
| Opera 6 | +|
| Any Order | +
+ See the appendix that deals with older browsers. +Additionally, the em version makes the columns too narrow for some reason + |
+
| Equal Heights | +
+ There's a rendering display problem (which is probably the cause for Mark's extra content wrapper div) when the page is left and returned to (clicking back and forward, switching to another app and back again, but not reloading the page), everything is magically ok! + |
+
| Vertical Grid | +
+ Horribly messy +Each Snap extends from the bottom of its column to the bottom of the viewport (nice job on your positioning there Opera 6). + |
+
| Combined | +
+ The messiness of the snap placement, and the equal heights stop working. +But because of the overflow:hidden, the extended snaps are also subject to the magic of the equal height's "now you see it, now you don't" page revisit born againness + |
+
| Opera 5 | +|
| Any Order | +
+ Columns don't even begin to be treated as such - they just stack up vertically, ie. as usual + |
+
| iCab 3.0 beta | +|
| Vertical Grid | +
+ The vertically positioned elements don't show up at all. +Which is very odd since the examples work in iCab just fine. + |
+
| Combined | +
+ Still no sign of the vertically positioned elements. + |
+
For browsers which exist for different platforms, the results are the same unless expliclty mentioned.
+ +| Browser | +Nested Rounded Corners | +Boxes | +Borders | +
|---|---|---|---|
| IE Win 7 beta2 | +Pass | +Pass | +Pass | +IE Win 6.0 | +Pass | +Pass | +Pass [note] | + +
| IE Win 5.5 | +Pass | +Pass | +Pass [note] | +
| IE Win 5.01 | +Fail (mild) [note] | +Fail (moderate) [note] | +Pass (?) [note] | +
| IE Mac 5.2 | +Fail [note] | +Fail (mild) [note] | +Fail (mild) [note] | +
| Firefox 1.5 | +Pass [note] | +Pass | +Pass | +
| Firefox 1.0 | +Pass [note] | +Pass [note] | +Pass | +
| Netscape 8.0 | +Pass | +Pass | +Pass | +
| Netscape 7.2, 7.1 | +Pass [note] | +Pass | +Pass | +
| Netscape 7.0 | +Fail (mild) [note] | +Fail (mild) [note] | +Pass | +
| Netscape 6.2 | +Fail [note] | +Fail (moderate) [note] | +Fail (severe) [note] | +
| Opera 9.0 (beta) | +Pass | +Fail (moderate) [note] | +Pass [note] | +
| Opera 8.5, 8.0 | +Pass | +Pass [note] | +Pass | +
| Opera 7.5 | +Pass | +Pass [note] | +Pass | +
| Opera 7.2 | +Fail (mild) [note] | +Pass [note] | +Fail (mild) [note] | +
| Opera 7.1 | +Fail (mild) [note] | +Pass [note] | +Fail (severe) [note] | +
| Opera 6.0 | +Fail (severe) [note] | +Fail (severe) [note] | +Fail (severe) [note] | +
| Safari 2, 1.3, 1.2 | +Pass | +Pass | +Pass | +
| Safari 1.0 | +Pass | +Pass | +Fail (mild) [note] | +
| iCab 3.0beta | +pass | +pass | +pass | +
| IE Win 6.0, 5.5 | +|
|---|---|
| Borders | +
+ Bizarrely needs adjustment to cater for slight but unexplained right-hand corner background shift + |
+
| IE Win 5.01 | +|
| Rounded | +
+ Fails to extend all the boxes to quite the absolute height required + |
+
| Boxes | +
+ Extends side borders to bottom of page and truncates #block_3d though not its contents. On scrolling, the extended borders vanish which means it's probably |
+
| Borders | +
+ Basic hacks allow nice degradation that maintains the decorative elements while forgoing the correct stretching of the bottom boxes. Without those hacks the columns simply vanish, presumably due to some |
+
| IE Mac 5.2 | +|
| Rounded | +
+ Since it can't really cope with the snaps or corners it degrades positionally well enough, apart from div 9 which wraps underneath - nothing to do with the wrapping container since giving it extra space does not help. + |
+
| Boxes | +
+ Degrades nicely and as expected. + |
+
| Borders | +
+ Degrades nicely and as expected though requiring same background shifting as IE Win 6.0 + |
+
| Firefox 1.5b1, Camino 1.0a1 | +|
| All | +
+ Float positioning when negative margins are around is bust in the beta versions and release candidate 1. + |
+
| Firefox 1.0 | +|
| All methods | +
+ Also tested and passes in Firefox 0.8 and Mozillas 1.4, 1.5 and 1.6 + |
+
| Rounded | +
+ The presence of a relatively positioned element within any of the blocks causes weird scrolling effects when trying to select text. This bug has been fixed in 1.5, but just so you know. Details in this [css-d] thread. + |
+
| Netscape 7.2, 7.1 | +|
| All methods | +
+ Strangely enough since I really would have expected these to fail + |
+
| Netscape 7.0 | +|
| Rounded | +
+ Bottom right corner and snap inset upwards and leftwards. +Mild failure, and probably hackable for working solutions. +Following a machine crash, I no longer have a copy of Netscape 7.0 and cannot track one down, so this might no longer be true - but who cares? + |
+
| Boxes | +
+ Extremely close, but bottom bg painting extends beyond the borders of the bottom-most boxes + |
+
| Netscape 6.2 | +|
| Rounded | +
+ Much the same as Netscape 7.0 + |
+
| Boxes | +
+ Much the same as Netscape 7.0 but not quite as close + |
+
| Borders | +
+ An utter mess + |
+
| Opera 9.0 (beta) | +|
| Boxes | +
+ Final boxes only painted as far as bottom of verticallt aligned elements leaving ghostly space above bottommost border for each column. + |
+
| Borders | +
+ To get Opera 9 and 8 to play together at the same time requires some mundane if verbally spectacular and verbose hackery. Of course, you could just drop support for Opera 8... + |
+
| Opera 8.5, 8.0 | +|
| Boxes | +
+ Weirdness going on when setting margin and padding, along with ems. Gets it basically right but the leftmost column is shunted rightwards and needs explicit surgery to rectify things - which causes reload side-effect oddness in IEs. + |
+
| Opera 7.54 | +|
| Boxes | +
+ As with Opera 8 + |
+
| Opera 7.23 | +|
| Rounded | +
+ Top left rounded corners dissappear + |
+
| Boxes | +
+ As with Opera 8 + |
+
| Borders | +
+ As with Opera 8 + |
+
| Opera 7.10 | +|
| Rounded | +
+ As with Opera 7.23 + |
+
| Boxes | +
+ Bizarre! No overlong scrolling page! + |
+
| Borders | +
+ Bottom boxes overly extended + |
+
| Opera 6.06 | +|
| Rounded | +
+ Block 1 disappears, most snaps vanish, bottom corners vanish or incorrectly placed + |
+
| Boxes | +
+ Block 3 covers the central column (Block 1), snaps and bottom borders all over the place + |
+
| Borders | +
+ Block 3 covers the central column (Block 1), snaps and borders not shifted to bottom. +Potentially hackable to degrade nicely à la IE Mac 5... + |
+
| Safari 1.0.3 | +|
| Borders | +
+ Top borders not drawn correctly + |
+
We should be able to take the Any Order Columns technique, apply the relevant amount of margin-left and right to the main block and then neg the side columns into position. Something like this:
#block_1
+ {
+ float: left;
+ margin-left: 15em;
+ margin-right: 200px;
+ }
+#block_2
+ {
+ float: left;
+ margin-left: -100%;
+ width: 15em;
+ }
+#block_3
+ {
+ float: left;
+ margin-left: -200px;
+ width: 200px;
+ }
+
+
+In theory that's great, but it only actually works in Safari. To make it work (after a fashion) in IE, Firefox and Opera requires expressions and other odd difficult to fathom kludges.
+ +The solution is a wrapping element. The nice thing though, is it only has to wrap the first block. The wrapping element is 100% wide and floated. Now we can apply those left and right margins on the first block to get it into place and the negging can proceed.
+ + + +Some of the different scenarios need slightly different handling - but it's still a very simple technique.
+ +How different? Well the quirks are:
+ +Explorer needs the central column shifted over by the width of the left column, otherwise it buts up flat on the very left. Fortunately setting position: relative and its left value to the width of the left column does the job.
#block_3 needs to be floated right (in all the other cases, all the floats are in the same direction so this is the closest there is to a gotcha) Explorer overdoes the -100% negging and just requires a negative margin that is the same as its width
+ + +IEs 5.01, 5.5, 6.0 on the PC, Firefox 1, Operas 8, 7 (.02 though .54), and the latest Safari.
+ +Netscape 7.2 fails to clear the footer properly.
+ +IE5 on the mac gets a horizontal scroll bar that extends to where the width of the page would be if the neg-floated elements had actually floated to the right of the main column. But it does work, so it's just an unfortunate side effect as far as I'm concerned.
+ +Opera 6 works, apart from 1-2-3 and its mirror 3-2-1. Not that it matters ;) However, it looks as if judicious Opera hacking could overcome this.
+ +Unsurprisingly, Opera 5 doesn't display the columns as columns at all.
+ +I presume that as with the non-fixed width ancillary columns, that this technique is a) nestable, b) possible with additional columns and c) amenable to the Equal Height Columns method.
+However, because I personally have no use for this type of layout, I have not tested these presumptions.
+ +Of course, another problem with not having a wrapper element around the first block, is that, since it is floated but has no explicit width, the block will only be as wide as its content makes it. If there's not enough content to expand the block to fill the available space, the margin-right will not reach the right hand edge of the viewport and the rest of the positioning will be out of wack.
Now we could assume that there will always be enough content to expand things just so, or we could do something like:
+ +
+#block_1:after
+ {
+ content: '.';
+ display: block;
+ float: left;
+ width: 100%;
+ height: 0;
+ overflow: hidden;
+ visibility: hidden;
+ }
+Nice try, but only Opera really gets it. Safari and Mozilla prefer something along these lines:
+
+#block_1:after
+ {
+ content: '. . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .
+ . . . . . . . . . . . . . . . . . . . . . . . . .';
+ display: block;
+ height: 0;
+ overflow: hidden;
+ visibility: hidden;
+ }
+
+But Opera hates it with a passion. A solution could be fashioned out of this material, but really, until browsers get their act together, the additional wrapper is just so much less of a drag...
+Philippe Wittenbergh suggested a possible workaround for the Gecko 1.8b2 bug - and what do you know, it's the basis for a whole new alternative way of doing any order columns. Up to a point.
+ +Each column is still floated, but we:
+position: relativeleft for margin-left. The value of left for block n is worked out so:
+The following CSS gives us our standard 2-1-3 ordering:
+#block_1
+ {
+ position: relative;
+ float: left;
+ width: 34%;
+ left: 33%;
+ }
+* html #block_1
+ {
+ display: inline;
+ }
+#block_2
+ {
+ position: relative;
+ float: left;
+ width: 33%;
+ left: -34%;
+ }
+#block_3
+ {
+ position: relative;
+ float: left;
+ width: 33%;
+ }
+
+Interactive example of the alternative Any Order technique
+ +This works fine in modern browsers with the equal height method, but because of the position: relative applied to the columns, it can never be souped up to be used as the underlying chassis for the vertical grid.
Of course, if you don't have any need for vertical grid-style positioning, then it will do just fine.
+ +Unfortunately it doesn't work in IE Win 5.01 or 5.5. And adding equal heights into the mix makes IE Win 6 lose the plot. Moreover IE Mac 5 pays no attention to the left declarations. And the same goes for Safari 1.03.
On the other hand it works in all Netscapes back to 6.1 (and gets round the longest column problem that occurs in some of them) and all versions of Opera back to 7.0. - feed the 'original' Any Order technique to all versions of IE and you've got the best of both worlds. Forgive me for leaving that for someone else to implement...
+ +| Browser | +Any Order | +Equal Heights | +
|---|---|---|
| IE Win 6 | +pass | +fail [note] | +
| IE Win 5.5 | +fail [note] | +fail [note] | +
| IE Win 5.01 | +fail [note] | +fail [note] | +
| IE Mac 5.2 | +fail [note] | +fail | +
| Firefox 1.5 | +pass | +pass | +
| Firefox 1.0 | +pass | +pass | +
| Netscape 8.0 | +pass | +pass | +
| Netscape 7.2, 7.1, 7.0 | +pass | +pass | +
| Netscape 6.2, 6.1 | +pass | +pass | +
| Netscape 6.0 | +fail [note] | +fail | +
| Netscape 4.7 | +fail [note] | +fail [note] | +
| Netscape 4.04 | +fail [note] | +fail | +
| Opera 8.0, 8.5 | +pass | +pass | +
| Opera 7.5, 7.2, 7.1, 7.0 | +pass | +pass | +
| Opera 6 | +pass | +fail [note] | +
| Opera 5 | +fail [note] | +fail | +
| Safari 2.0, 1.3 | +pass | +pass | +
| Safari 1.03 | +fail [note] | +fail [note] | +
| OmniWeb 5.0.1 | +pass | +pass | +
| iCab 3.0 beta | +pass | +pass | +
| IE Win 6.0 | +|
|---|---|
| Equal Heights | +
+ The |
+
| IE Win 5.5, 5.01 | +|
| Any Order | +
+ Shifted elements are incorrectly positioned + |
+
| Equal Heights | +
+ Given the problems with the any ordering, the results are not pretty + |
+
| IE Mac 5.2 | +|
| Any Order | +
+ The |
+
| Netscape 6.0 | +|
| Any Order | +
+ Columns simply stack up on top of each other and no background colour is painted + |
+
| Netscape 4.7 | +|
| Any Order | +
+ Background colours not painted but the positioning is preserved. +Float clearing would need additional markup cruft. + |
+
| Equal Heights | +
+ Columns vanish. + |
+
| Netscape 4.04 | +|
| Any Order | +
+ Background colours not painted and columns just stack. + |
+
| Opera 6 | +|
| Equal Heights | +
+ There's a rendering display problem (which is more sever in the Mac than the Win version) that causes the columns to be painted overlong. The "usual" fixes of clicking back and forward or switching to another app and back again don't work, but scrolling up and down make's everything magically ok! + |
+
| Opera 5 | +|
| Any Order | +
+ Background colours not painted and columns just stack. + |
+
| Safari 1.03 | +|
| Any Order | +
+ The |
+
| Equal Heights | +
+ The |
+
If you can guarantee the height of elements within a block, you can, within reason, reorder them vertically.
+ +The following example is far from definitive - not least because even the modern browsers can't begin to agree on how to behave. But just to give a flavoursome idea of what's possible and to remind me (or someone else) to properly investigate and see who's right and who's wrong [note], here goes...
+ +Semi-interactive example of vertically shifting blocks
+ +Now elements within the main content or changing lists of links would probably be too unpredictable to monkey around with in any case (as well as there being no sane reason why you would want to), but chunks like navigation and site identity have no business appearing in the source before the real content and, unless their height is that unpredictable, could easily be catered for.
+ +For instance, but much more realistically than the examples linked to, a theoretical element, say #site_identity, could be last in the source and still rise to the top:
body
+ {
+ margin-top: 4em;
+ }
+#site_identity
+ {
+ position: absolute:
+ top: 0;
+ height: 4em;
+ }
+
+There are other ways this kitty could be skinned, but if you don't do something along these lines in this day and age, you're committing a layout crime ;)
+ + +Rather than position each float relative to the overall rightmost point has been cleared, if any element has a negative margin-left applied to it, NN4 (4.7, for sure) treats all positive margin-lefts as starting from 0.
So we just need to negatively shift one element (by the amount that would be expected from its desired position) and then set margin-left on the other elements as if they were absolutely positioned
| NN4 | Normal | |
|---|---|---|
| Block 1 | 25 | 25 |
| Block 2 | 75 | 25 |
| Block 3 | -100 | -100 |
| Block 4 | 50 | -50 |
Of course, NN4 doesn't understand the easy clearing method, so a non-semantic clearing element would need to introduced to force the wrapper element's height.
+Though this would work, NN4's application of colours and background images to floated and absolutely positionned elements is notoriously flaky, so maintaining the layout structure is the most you could seriously hope to achieve.
+ + +Suffers from something similar but different to NN4.
+Once the overall rightmost point has been cleared, it works from the preceding element's rightmost point.
+| Op 6 | Normal | |
|---|---|---|
| Block 1 | 25 | 25 |
| Block 2 | 25 | 25 |
| Block 3 | -100 | -100 |
| Block 4 | 25 | -50 |
However, if you are so foolhardy as to try and do something with this information, know this also - Opera 6 has problems when using ems and makes the columns too narrow for some reason.
+Since the Any Order technique does not rely on wrapping elements, the blocks can be arranged in all possible combinations. For n columns, since any block can be in the position of any column, that number is given by the simple formula n factorial or n!
+eg. for n = 5, the possible orderings = 1 x 2 x 3 x 4 x 5 = 120
+ +With the wrapping elements (as in the original Source Ordered Columns), things are more constrained. For each wrapping element we essentially end up with two sub columns - two sub-columns means two possible combinations, giving us the formula, 2n-1.
+eg. for n = 5, the possible orderings = 2 x 2 x 2 x 2 = 16
+ +As you can see, as the number of columns increases, the potential number of combinations increases far more rapidly for the Any Order technique.
+ +More practically, wrapping elements can be used to good effect to enable groups of blocks to be stacked vertically within, rather than as, columns, giving yet more potential layout flexibility.
+ +| Number of Columns | +Source Order Columns | +Any Order Columns | +
|---|---|---|
| 2 | +2 | +2 | +
| 3 | +4 | +6 | +
| 4 | +8 | +24 | +
| 5 | +16 | +120 | +
| 6 | +32 | +720 | +
| 7 | +64 | +5040 | +
| 8 | +128 | +40320 | +
Until enough browsers support multiple backgrounds on a single element, n-2 wrapping elements are required to hold the necessary background images to create the effect of n columns.
+Unless, of course, the layout is a fixed pixel-width one, in which case a single background image can be used for any number of columns.
+ +Throughout this article and its assorted examples I use class names and ids such as #footer, #header, #block_1 and .verticalalignment. You shouldn't use identifiers like this in the real world.
Take for example #header. What's in it? If, I'm guessing here, it actually contains site identity stuff like logos, #site-identity (or whatever you prefer) would be better. Disclaimer legalese in the "footer"? Then use someting more descriptive like #site-legal or #legal-mumbo-jumbo. Because you might want to place you site identity at the bottom or doen the side, and then #header doesn't make any sense. It's the same reason really for not using class names like .red-bold-helvetica.
I'm using these names because this is an article with example code. In this case they really are properly descriptive. Unless you're writing a similar article, using simliar names will not be so for you.
+ +Throughout the article I use hacks to deal with IE Win - that's just the way I like to do things. It also makes the example code here simmpler and clearer. And to be clearer still about the intent of the code: it is example code. I do not recommend that you cut and paste it (see the remarks about class names and ids above), but rather that you write it yourself after understanding the principles behind the techniques.
+So, feel free to use conditional comments or plain voodoo if you prefer. But please don't bother telling me hacks are wrong etc...
+ +Throughout the article, the working examples linked to are percentage-based. Consequently those examples, surprise surprise, are not pixel perfect and small gaps will occasionally (or rather, frequently) appear between the columns. One fix for such a three column layout is to set just the backgrounds of the side columns and let the background of the wrapping element paint the central column.
+Personally I would avoid such layouts in a real life production situation, but I feel that it helps explain that the principles of the techniques better than using rigid pixel values. And others may not feel comfortable with grappling with the concept of scalable em-based layouts. So precentages, it is.
+ +Yes, I know. Some of the examples have incorrect wrapping in Internet Explorer. At some window sizes. It's caused by a rounding error, a known problem with Explorer. If you read the section Danger Alex Robinson on the Any Order Columns page you'll see it mentioned in passing.
+ +Try resizing your browser - you should see the column jump back and forth from its correct position to where you see it now. If you must use percentages, the solution is to feed Explorer a slightly smaller value for the problematic column, say 32.9% instead than 33%. I could have done that in the examples but frankly, what with the length of the article and wanting to concentrate on the bare minimum to demonstrate things, I chose to not include such refinements. If you go to the interactive demo, you'll see that there's a message advising about reducing values if wrapping occurs.
+ +For obvious reasons the problem doesn't occur at all with pixel-based designs. And much less frequently with em-based ones, especially since I always make the wrapper just that little bit wider than it needs to be.
+ +Of course, if you've found another problem with the layout, please make haste to let me know about it.
+ +There are plenty of things that could have been added to this article.
+At over 10000 words, though, it's already a bit of a monster and only issues that arise as a direct consequence of techniques discussed here are addressed. However I have tried to point the reader towards the most common problems that these techniques share with other approaches. If you think I've made any appalling omissions, tell me about it.
+Several issues have been discovered since publication which, depending on your requirements, can cause severe problems when using the equal height technique.
+ +Linking to an anchor in any of the columns within the element that has been set to overflow: hidden causes the content of that column to shift upwards. In IE and Firefox, that is.
+Example of anchors in the equal height method
+ie. it's not the large padding that's casuing the problem (though obviously it is the trigger of the behaviour)
+ +IEs 6 and under are easy. Simply suppress the overflow: hidden on the containing wrapper element.
IE7b thought doesn't work since overflow:visible makes the overflow of the columns, well, visible. So we use an expression instead, making the columns the height of the column container.
However, there are dragons here...
+So if you don't like those dragons, you might prefer to force IE7 into Quirks mode. [note]
+ +...or rather, there appears to be no fix for Gecko-based agents. I had thought shifting the padding and negative margin to the top (like for the Opera 8 fix) would sort things out, but once Gecko knows that the box is larger than what's displayed the anchor shifting occurs.
+ +Half fix for anchor problem in Gecko
+ +Ingo Chao has come up with a solution that works as long as certain conditions are met - the trick is to apply position:absolute to the target.
For anchors of the form <a name="target"></a>, this presents no problems. If the target element can stand being absolutely positioned, everything will be ok. Obviously though, attempts to apply the same technique to an anchor which is actually an id on an element enveloping content will result in dismal failure. And for many off-the-peg blogs and CMSes, that's probably going to be the case.
Furthermore, the parent element of the target must not have position:relative applied to it, which also somewhat reduces the usefullness of the technique.
Weirdly, just to add spice to the whole over-egged pudding, when used in equal heights mode, Opera 9 doesn't shift. But with the following reduced test case, it does.
+ +Two distinct behaviours can be seen in the previous reduced testcase.
+The question is, are current Geckos, IE and Opera 9 correct in their handling of the above example? What do the specs say?
+ ++ +This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region.
+ +
So does that mean that the content can be scrolled (though no interface should be provided) which is what Firefox and IE are doing, or does it mean that no scrolling should occur? But how would the latter jive with scrolling the content via scripting (which is surely meant to be allowed)?
+ +Sorry. Not fair. It's a bogus question. In the words of the editor of the CSS specs, Ian Hickson, "The spec doesn't define what happens with anchors." So, let's play detective and figure out when (and hopefully why) the behaviour changed in Mozilla and Opera.
+ +For Opera, the answer is fairly easy to track down thanks to a note in the changes log, under the heading "Acid2 Fixes"...
+ ++ +Elements with
overflow:hidden;can scroll to anchors within them.
...which was done presumably (remember the specs say nothing about how an agent should handle anchors) because unless they scrolled to the anchor on the test page, nothing would show at all and so they would fail the test at the first hurdle.
+ +Safari has taken a different route to passing the test - by making the html element scrollable when overflow property is set to hidden, but not doing so for any other element.
+ +Of course there's nothing to say which of these paths (if either) is correct.
+There's nothing in the Acid2 guide reference that mentions testing for such behaviour and the only comment about the use of overflow:hidden; on the html element is:
/* page setup */
+ html { font: 12px sans-serif;
+ margin: 0; padding: 0; overflow: hidden;
+ /* hides scrollbars on viewport, see 11.1.1:3 */
+...which leads us back to that section of the CSS specs which, er, has nothing to say about the treatment of anchors.
+ +So how did the test get into Acid 2? What is its purpose? Fortunately a little bird was able to tell me that Ian Hickson was the lead in constructing the Acid2 test. So I asked him why it was set up that way, with the content hidden and being scrolled to, and whether this was an intentional part of the test, or it just happened that way because that's how Mozilla and IE handled it
+ +++ + +Hmm. I didn't think about how anchors interacted with the overflow:hidden +text and just assumed it would work. :-)
+The reason I used overflow:hidden at all was to test make one of the browsers implement overflow:hidden on the root element, because authors were complaining it wasn't supported (I don't remember which one any more, probably Opera). Also, I needed to have scrolling to test fixed positioning, but I didn't want to show the scrollbar.
+via personal correspondence
+
Incredibly dull downloading of many many copies of old versions, followed up by combing through the bug tracking system eventually gave up the point where Mozilla had begun to scroll overflow:hidden, which in turn pointed to bug 221140 which gets us towards the heart of the matter.
+ +++ +The basic problem here is that 'scroll' and 'auto' have never worked on table +cells, and the working group decided to make 'hidden' work like 'scroll' and +'auto', so now 'hidden' doesn't work either.
+Bug 221140 - 'overflow: hidden' on table cells broken, comment #4
+
Of course, the question of exactly what and where the working group had decided is moot. Let's have another look at our old friend 11.1.1, the overflow:hidden definition (remembering that it says nothing about how user agents should deal with anchors):
+ ++ +This value indicates that the content is clipped and that no scrolling user interface should be provided to view the content outside the clipping region.
+ +
Previously the same section had been:
+ ++ +This value indicates that the content is clipped and that no scrolling mechanism should be provided to view the content outside the clipping region; users will not have access to clipped content. The size and shape of the clipping region is specified by the 'clip' property.
+ +
Do these changes to 2.1 mean that Behaviour A is correct and were they introduced for exactly such a situation?
+Prodding Ian Hickson again, I got the following explanation:
+ + +++ + +It was changed in issue 1-16, around July-September 2003. But it was made +in response to an W3c-internal-only comment, so that won't help you...
+... I imagine the reasoning was "to make CSS compatible with the Web", which already behaved that way.
+... It was probably more "browsers won't change their behaviour to match the spec because doing so would break Web pages, so we'll change the spec to match the browsers instead". (This reasoning is the thinking behind much of the changes to CSS2.1. Pragmatism is an important factor in the development of the CSS2.1 and HTML5 specifications.)
+via personal correspondence
+
So to sum up, the situation is happenstance yet quasi-official. That's how IE did it, so the W3 working group and Mozilla followed suit. And Opera followed along later to pass a test that reflected that status quo.
+ +Consequently there's nothing to say that Safari's divergent behaviour (scroll on html element, no scroll on any other) isn't correct. Or what the behaviour should be if a box that overflow: hidden is applied to is tall enough to show all the content within it, but there is additional padding-bottom beneath it...
And Bug 259615 - 'overflow: hidden' elements shouldn't be scrollable by the user probably shouldn't really be a bug. But Bug 325942 shows that some of the Mozilla team think it should.
+ +Sorry, I don't have any recommendations. Really. It's up to you to decide what works for you, just like you should decide what browsers you should support. That said:
+If you can't guarantee the absence of anchors, then you're probably going to be better off going with faux columns or a javascript-based solution.
+Of course, if Mozilla supported multiple background images this would all be irrelevant... Or if Mozilla could apply position: absolute to generated content properly...
Drag to select content within the longest column and keep dragging downwards - if the bottom of column is above the bottom of the viewport there is no problem. If it's below the bottom of the viewport then it keeps scrolling, shunting the content of all the columns upwards and very rapidly at that so that in all likelihood it just vanishes. (It is possible to scroll it back if some of the content is still visible and selectable - but that's an academic point since in reality the average user is going to be just as foobarred as if all the content had dissapeared)
+Fixed as of Firefox 1.5 and Camino 1.0, so this is basically a non-issue.
+ +A less serious problem (unless you're being bitten by it) is that it can cause printing problems for IE. Depending on the exact values used for padding-bottom and margin-bottom, the content in the columns can shift upwards and even disappear entirely. The answer to this problem is to suppress the negative margin-bottom (and consequently the padding-bottom too) in a print style sheet. You shouldn't be printing the backgrounds in any case ;)
+ + +So, the end result may be that the actual usefulness of the equal heights technique is in exposing flaws in certain rendering engines (whether it's Safari and Opera or Explorer and Gecko that get it wrong I leave for others to decide).
+ +Fortunately for me, it's the technique that I'm least concerned about since there's always Faux Columns to fall back on. And even more fortunately I covered myself in the article by saying that Faux Columns would probably remain the weapon of choice ;)
+ + + + +| Browser | +Shifts on anchor trigger | +Scrolls on select drag | +
|---|---|---|
| Firefox 1.5 | +Yes | +No | +
| Firefox 1.07 +NS 7.2 |
+Yes | +Yes | +
| IE 6 | +Yes | +No | +
| IE 5.01 (+ 5.5 ?) | +Yes | +No | +
| Opera 9b | +Yes | +No | +
| Opera 8.5, 8.0, 7.54, 7.23, 7.1, 6.06, 5.11 | +No | +No | +
| Safari 2.0, 1.03 | +No | +No | +
| iCab 3.01 | +No | +No | +
| IE 5.23 (Mac) | +No | +No | +
| NS 7.1, 6.23, 6.1 | +No | +No | +
float: right instead (simply switch right and left in the previous instructions). Moreover, left and right floats could be combined. This would have the advantage of ensuring that the left and rightmost floated elements line up with the edge of the wrapper div and also potentially reduce the number of elements requiring negative margins (depending, of course, on just how many columns are required and how they need to be ordered).column positions 1 to n-1 are occupied by blocks 1 to n-1 (in any order). The answer is that actually the "real" formula is
column positions 0 to n-1 are occupied by blocks 0 to n-1 (in any order) where ghost block 0 always fills ghost column slot 0. But that's a little confusing, isn't it?position: relative on #footer to prevent wayward painting of its background colour.display: inline to all the blocks and not having to bother thinking about any of this.$big_value is a variable name, standing in for the actual value.display: table is a no go for containing the floats. Safari just doen't get on well with the combination of display: table and overflow: hidden. The end result is that the overflowing stuff simply isn't hidden.padding-bottom and negative margin-bottom to that and just set the required padding-bottom on the outer element.z-index doesn't have to be 1000. Depending on your design and whether you're using z-index elsewhere, you might need to use a different value.position:relative applies to any element. CSS 2.1 notes however, that the behaviour is 'undefined for elements with display: table-*'. As Philippe Wittenbergh points out, with td {position: relative}, it does work... in iCab 3.0 alone.overflow: hidden bugs have been fixed, the hacks to make Opera 8 and under behave themselves trip Opera 9 up. Fortunately, ways and means exist to make things ok again, but it's probably just as sensible to ignore older versions of Opera.|
+ Block 6 Top +Source order = 1 +Colspan = 2 +Rowspan = 3 + |
+
+ Block 2 Top +Source order = 2 +Colspan = 2 + |
+
+ Block 1 Top +Source order = 3 +Colspan = 2 + |
+
+ Block 3 Top +Source order = 4 +Colspan = 2 + |
+
+ Block 9 Top +Source order = 5 +Colspan = 2 +Rowspan = 5 + |
+|||||
|
+ Block 2 Bottom +Source order = 6 +Colspan = 2 + |
+
+ Block 1 Bottom +Source order = 7 +Colspan = 2 + |
+
+ Block 3 Bottom +Source order = 8 +Colspan = 2 + |
+|||||||
|
+ Block 5 Top +Source order = 9 +Colspan = 3 + |
+
+ Block 4 Top +Source order = 10 +Colspan = 3 + |
+||||||||
|
+ Block 6 Bottom +Source order = 11 +Colspan = 2 + |
+
+ Block 5 Bottom +Source order = 12 +Colspan = 3 + |
+
+ Block 4 Bottom +Source order = 13 +Colspan = 3 + |
+|||||||
|
+ Block 8 Top +Source order = 14 +Colspan = 4 + |
+
+ Block 7 Top +Source order = 15 +Colspan = 4 + |
+||||||||
|
+ Block 8 Bottom +Source order = 16 +Colspan = 4 + |
+
+ Block 7 Bottom +Source order = 17 +Colspan = 4 + |
+
+ Block 9 Bottom +Source order = 18 +Colspan = 2 + |
+|||||||
A method enabling the vertical positioning of elements across grids/columns
+ +Because it's a perfectly reasonable demand that designers should be able to control the vertical as well as the horizontal axis.
+Some may argue that designers shouldn't even have control over the horizontal axis, but if you agree with that position what the hell are you doing reading this article?
+Still reading?
+The age old method for dealing with vertical positioning is to use tables. Stick what needs to be top aligned in cells in one row; what needs to be bottom-aligned goes in the row that follows.
+The good thing about the table-based way is that it works.
+The bad things about the table-based way is that it forces the designer to separate logically connected elements into an arbitrary source order dictated by the design alone. Which is bad from the semantic point of view but even worse from the practical one, since it leads inexorably to the creation of gnarly, nested, hard-to-maintain tag soup.
+It also means that bottom-aligned elements must appear below all the elements within the top-aligned block and not level with the last element within it as might be desired. Or middle-aligned.
+However, it does work and does so reliably which counts for a lot when it comes to web development. It doesn't stop it being utterly dirty though.
+No, not you. The elements within which I want to vertically align things.
+This is the other more modern approach - as long as you know the height of the column elements then you can just set position: relative on the column element and then any elements within it just need position: absolute.
To know the height, you have to know that your content will be that height (eg. the only content in the "flow" will be images which are the same height across the columns - over which you then position your text and any other images) or that your content will not make the element be higher than that and set the height attribute.
Which is fine so far as it goes, but as soon as you need any kind of vertical liquidity, then this approach breaks down. Which is why so many designers simply don't bother.
+ +The problem with the modern approach is that it's not possible to guarantee the height of the individual column blocks.
+However, we can rely on the height of the containing element by applying any of your favourite float clearing methods to ensure that the container element does indeed contain the columns. After that, it's just a matter of applying position: relative to the container element.
Now if we apply position: absolute to any element within the column blocks, it will be vertically positioned relative to the container element.
Which gives us the ability to snap things to the bottom or middle of the grid across all the columns.
+ +Of course, it also means that the element will be positioned relative to the container tag horizontally as well.
+ +This isn't a problem though if all we want to do is shift the element vertically. As long as we only set the element to appear at, say, bottom: 0 or top: 50%, then it will appear horizontally aligned with the column it's in. If we want to shift the element from the left edge of the column, all that's needed is a suitable amount of margin-left.
But what if we do want to offset the element from the column's right edge (which truth be told, is the most likely use for this)?
+The simplest, if not the easiest, solution is to set individual right values, where those values are equal to 100 - the value of the rightmost point of the column. [note]
Example of the Vertical Grid technique (simple version with 2-1-3 ordering)
+ +If you just looked at the previous example in Opera (7 or 8, forget about 6), you might have noticed that things are a little off.
+First off, it fails to get the vertical positioning right at all if percentages are used. That's why the "L" Snaps are at the very top of the containing tag and don't start in the middle as they ought to.
+Adding float: left and an explicit width: 100% almost solves things, but not well enough. Block 1's snap still floats to the top and none of the elements picks up on the height: 50%. It looks like Opera is a hopeless case, and the best that can be achieved if Opera must be catered for is aligning to the absolute top or bottom using pixels or ems.
Secondly, the horizontal shifting works sometimes. That is sometimes it doesn't, failing to apply background colours and shifting the element less than it actually requires. I can't figure out the cause of this monkey business at all (it doesn't appear to be the negative margins since it fails even more spectacularly when ordered 1-2-3) which means that there is no simple CSS fix. (And this is the case whether the layout is percentage-, em- or pixel-based.)
+Which means...
+We need a markup fix. If we wrap the element we want positioned on the right, that element can be made to be the width of the column and then absolutely positioned on the right within it.
+As if it's not bad enough that it's a markup fix (though since it's just an additonal wrapping tag, it's low down the scale of markup atrocities), we now run into the different models that browsers use to calculate the width of nested absolutely-positioned elements. To be blunt, Opera and IE Win make it easy, but get it wrong (according to the standards, that is, but that's the only game in town).
+So for Opera and IE Win all we need to do is:
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ width: 100%;
+ }
+.verticalalign p
+ {
+ position: absolute:
+ right: 0;
+ bottom: 0;
+ }
+
+NB. floating the inner element would probably do just as well in most situations
+ +But because, Safari and Mozilla get it right, that would make the element-to-be-aligned 100% of the wrapping element. The correct value for the width in those browsers is the actual width of their parent elements. So now we add:
+.verticalalign
+ {
+ position: absolute;
+ bottom: 0;
+ width: 100%;
+ }
+#element_1 .verticalalign
+ {
+ width: 34%;
+ }
+#element_2 .verticalalign
+ {
+ width: 33%;
+ }
+#element_3 .verticalalign
+ {
+ width: 33%;
+ }
+Of course, .verticalalign is now too narrow in Opera and IE! So we plump them back up again with a media query hack for Opera (subject to the same caveats as before), and a star html hack for IE. Hey presto!
/* hack for Opera 7+ */
+@media all and (min-width: 0px){
+.verticalalign
+ {
+ width: 100% !important;
+ }
+}
+/* hack for IEs of all persuasions before IE7 */
+* html .verticalalign
+ {
+ width: 100% !important;
+ }
+
+As of the beta version of Opera 9, the position and dimensions of absolutely positioned and fixed position elements are treated correctly when they are nested inside each other (except for that vertical percentage thing mentioned above). So now the width: 100% gets applied as it should. Which screws things up big time.
As I said on the previous page, there is such a relatively small number of Opera users (who in all likelihood upgrade often and early), that it's probably OK to just leave out the Opera 8 fix.
+Mind you, if you do want to figure out how to distinguish Opera 9 from previous versions, I'm really not going to stop you. Well, actually I am. You see, I've already got one. CSS3 attribute selectors to the rescue!
+/* hack for Opera 7+ */
+@media all and (min-width: 0px){
+.verticalalign
+ {
+ width: 100% !important;
+ }
+/* But Opera 9 does it right, so CSS3 hax to the max */
+div[id^="wrapper"] #block_1 .verticalalign
+ {
+ width: 34% !important;
+ }
+div[id^="wrapper"] #block_2 .verticalalign
+ {
+ width: 33% !important;
+ }
+div[id^="wrapper"] #block_3 .verticalalign
+ {
+ width: 33% !important;
+ }
+}
+Example of the Vertical Grid technique (2-1-3 ordering)
+ +IE Win 7 beta 2, IE Win 6, IE Win 5.5, IE Win 5.01, Operas 7, 8 and 9, Firefox 1.5 and 1.0, Netscape 7 and 8, Safari 1.03 (and up)
+ +Pretty much works - but absolute positioning is flaky at the best of times in this tired old workhorse
+Do not understand the method at all. It is left as an exercise to the reader to figure out the necessary hacks to cope with those browsers if required.
+ +It's a bit finickity, but the technique is pretty sturdy unless you must support older browsers.
+You could instead reach for display:table but that results in, frankly, equivalent but less readable code than tables. And you can't then position elements absolutely within the table cells[note]. And even if the positioning was possible, you'd be stuck with the intial source ordering of the columns...
Of course, it should all be so much easier than this, as Eric Meyer laments in CSS Gridlock.
+ + +The individual pieces are in place - time to bring the holy bacon home.
+ + + + + +position:relative applies to any element. CSS 2.1 notes however, that the behaviour is 'undefined for elements with display: table-*'. As Philippe Wittenbergh points out, with td {position: relative}, it does work... in iCab 3.0 alone.This project started because I had repeated requests to design 2 and 3 column page + layouts. I started to think around the basic concepts and found there were only + three variations: full page width, left aligned and centered. The most common request + was for a centered design that was under 800 pixels wide to allow viewing in 800x600 + screens.
+AND, they wanted it to Google well, by making it 'source ordered' (putting the content + first) in design. That was my goal, and here is how it came about ...
+Often I would be refered to an existing site. 'I want it like that, but full height, + so the footer is at the bottom of the page if the content is too short,' and 'I want + the columns all the same height, it looks odd only having columns as high as the content.' + Hangovers from the printed medium, like brochures, I suppose. However, the more I thought + about it, the more I could see the sense in this approach.
+They are very difficult to get right across browsers, especially when there are many + nested inside each other. Given the way the different browsers work margins, padding, + etc, this should be no surprise.
+So, I figured CSS must be the way forward. I quickly found two sites offering + designs that partly met my needs (Position is Everything (PIE) and + Paul O'Brien's Site). Paul O'B's + design was full width with a fluid width center column (he has since done one centered + and under 800 pixels) and the PIEfecta one by Big John didn't give full height, but has + the advantage of not using background images in the columns to make it work. Why is this + good? Because the next step in my design is to make it 3D using images in the background.
+And so came v1.0 of this tool. I took the PIE design, ironed out a few width and alignment + issues and made it possible to easily create a personalised version of the design without + the need to understand the (very) complex CSS code, made so by bugs in IE and the Gecko + engine (at the heart of the Mozilla-based browsers). The first version was simple, using + a form to enter parameters and lacked validation and error checking. More options were added, + together with hundreds of lines of coding to validate and error check. By now it was at v1.3.
+v2.0 was the first attempt to combine what I had made of PIE's model with Paul O'Brien's. + All went quite well, until it came to Mozilla. IE (quite sensibly, I believe) treats the + height style as a minimum, and will expand vertically if needed. This means it is possible + to define a design as 100% high and IE will fill the page, and expand further down if the + content dictates. Mozilla doesn't. It uses the CSS min-height instead. Enter the first set + of hacks to get around this. Worse was to come, Mozilla has a another bug. It can't inherit + min-height into child containers. And so in Mozilla, the resulting code looked very odd + when the content didn't fill the page.
+I have to say that Mozilla caused no end of problems, especially with the header and footer. + It took an age to find a combination of css and positioning within the page code to get IE + and Mozilla to render them the same, and a lot of hacks are in the code to achieve this. + The final hack to get Mozilla to display a full height page with minimal content involved + placing a dummy design behind the main design, and making areas of the main design transparent + so that this background could be seen and appear one with the main design. All these hacks + are then made invisible to IE with another hack!
+However, no matter how hard I tried, this design (v2.0) ended up using two images to get + it to work reliably. I used the php GD library to make these images on-the-fly. Not ideal + to use images, but I had to drop the dummy background code because it caused too many + problems.
+v2.5 used revised code from Big John (his piefecta design) and had tons of screenshot + help for the Mac browsers from Allan Smith at Telford Steam Railway (thanks Allan). It + was thoroughly tested on loads of browsers (IE Win 5.x/6, Mozilla, Opera, Safari and + IE Mac 5.x) and works! Although IE Mac 5.x would not go full height on minimal content + - sorry, no can do. It also featured Tooltips for the first time on the generator form.
+The php GD image generation was revised, quicker and checked if a suitable image already + existed. It corrected the http headers bug to give correct filenames in all browsers + from the save section of the generator form. Also, one of the images use to hack the + borders was no longer needed. Another bug affecting Mozilla was corrected, so that it + would automatically open the generator form.
+Tooltips were available for each form entry field. The cut and paste css now had copious + notes to show how it's done. Tons of bugs were fixed, too many to mention.
+However, the header and footer still couldn't be separated from the body and the left + column still couldn't be disabled (meaning that this tool couldn't be used to make a one + column layout - like this page). I may re-introduce this option on a later version. + Also, there was no option to set the left or top page margins - these are coded to 0. + I was sure the user could manually set the body side margins needed, but setting the + top or bottom ones would break the design
+v2.70 was essentially a series of bug fixes:
+And so went version 2.80 and now into v2.90.
+And for v3.00?
+If you let me know of bugs (or wish list items) that you find, contact me using + the details at the foot of this page.
+If you select a body background pattern, this php-based tool needs to be able to + generate images on-the-fly, so I have used the gd library to do this. These have + rather long names that decribe them exactly to the php tool. You need to save these + files from the display at the foot of the generator form (right mouse-click and + 'save as'). You will also have to edit the page code if you change the default + directory (assumes the same directory as the html).
+I can't say I'm overfond of fancy background images for pages, but the simple + patterned ones can look OK if the page alignment is centered (i.e. not + left-aligned). This code generator only allows a repeated image to be placed in the + background of the body tag, and only under certain circumstances (check the Tooltips + for further guidance). Note, only a few designs have been included, if you want me + to add more, contact me with details of where you have seen one you like. +
Each pattern is made using the background color of the page as a base. The bumps, + dents and 3d_crosses (looks like that punched steel plate walkways are made of in + factories) require that the page background color isn't too light, if it is the code + will darken the chosen color to permit the bumps code to make the pattern. I will + write the php code to make your chosen image, if I think it worthy of addition.
+This template comes from a basic demonstration of how to do non-float 3D boxes + without large images.
+The Tooltips on the generator form page are from Dan Allen at Freshmeat, albeit
+ with some mods. Take it from me, Dan's solution is the best freely available!
At this time, I'm not inviting contact via a form or by e-mail, as I am snowed under
+ with work. Instead, you can PM me at any number of forums, on which my username is
+ 'ClevaTreva' or 'Cleva Treva'. What forums?
+ (links open in a new window):
To name but a few.
+There is an old thread about this tool at the SitePoint Community Forums, here:
+ +There is also another old thread about this tool at the CSSCreator Forums, here:
+ +
+ 
';
+ }
+ closeLink.onclick = function() { domTT_deactivate(owner.id); };
+ closeLink.onmousedown = function(in_event) { if (typeof(in_event) == 'undefined') { in_event = event; } in_event.cancelBubble = true; };
+ }
+ var contentRow = tipLayoutTbody.appendChild(document.createElement('tr'));
+ var contentCell = contentRow.appendChild(document.createElement('td'));
+ contentCell.style.padding = '0px';
+ if (numCaptionCells)
+ {
+ if (domLib_isIE || domLib_isOpera)
+ {
+ contentCell.colSpan = numCaptionCells;
+ }
+ else
+ {
+ contentCell.setAttribute('colspan', numCaptionCells);
+ }
+ }
+ var content = contentCell.appendChild(document.createElement('div'));
+ if (domLib_isIE50)
+ {
+ content.style.height = '100%';
+ }
+ }
+ else
+ {
+ var content = tipObj.appendChild(document.createElement('div'));
+ }
+ content.className = in_options.get('classPrefix') + 'Content';
+ if (in_options.get('content').nodeType)
+ {
+ content.appendChild(in_options.get('content').cloneNode(1));
+ }
+ else
+ {
+ content.innerHTML = in_options.get('content');
+ }
+ if (in_options.has('width'))
+ {
+ tipObj.style.width = parseInt(in_options.get('width')) + 'px';
+ }
+ var maxWidth = domTT_maxWidth;
+ if (in_options.has('maxWidth'))
+ {
+ if ((maxWidth = in_options.get('maxWidth')) === false)
+ {
+ tipObj.style.maxWidth = domLib_styleNoMaxWidth;
+ }
+ else
+ {
+ maxWidth = parseInt(in_options.get('maxWidth'));
+ tipObj.style.maxWidth = maxWidth + 'px';
+ }
+ }
+ if (maxWidth !== false && (domLib_isIE || domLib_isKonq) && tipObj.offsetWidth > maxWidth)
+ {
+ tipObj.style.width = maxWidth + 'px';
+ }
+ if (in_options.get('position') == 'absolute' && !(in_options.has('x') && in_options.has('y')))
+ {
+ switch (in_options.get('direction'))
+ {
+ case 'northeast':
+ var offset_x = domTT_offsetX;
+ var offset_y = 0 - tipObj.offsetHeight - domTT_offsetY;
+ break;
+ case 'northwest':
+ var offset_x = 0 - tipObj.offsetWidth - domTT_offsetX;
+ var offset_y = 0 - tipObj.offsetHeight - domTT_offsetY;
+ break;
+ case 'southwest':
+ var offset_x = 0 - tipObj.offsetWidth - domTT_offsetX;
+ var offset_y = domTT_mouseHeight + domTT_offsetY;
+ break;
+ case 'southeast':
+ var offset_x = domTT_offsetX;
+ var offset_y = domTT_mouseHeight + domTT_offsetY;
+ break;
+ }
+ }
+ else
+ {
+ var offset_x = 0;
+ var offset_y = 0;
+ in_options.set('trail', false);
+ }
+ in_options.set('offsetX', offset_x);
+ in_options.set('offsetY', offset_y);
+ in_options.set('offsetWidth', tipObj.offsetWidth);
+ in_options.set('offsetHeight', tipObj.offsetHeight);
+ if (domLib_canFade && typeof(alphaAPI) == 'function')
+ {
+ if (in_options.get('fade') != 'neither')
+ {
+ var fadeHandler = new alphaAPI(tipObj, 50, 50, 100, 0, null, 10);
+ fadeHandler.setAlpha(0);
+ in_options.set('fadeHandler', fadeHandler);
+ }
+ }
+ else
+ {
+ in_options.set('fade', 'neither');
+ }
+ if (in_options.get('trail') && typeof(owner.onmousemove) != 'function')
+ {
+ owner.onmousemove = function(in_event) { domTT_mousemove(this, in_event); };
+ }
+
+ if (typeof(owner.onmouseout) != 'function')
+ {
+ owner.onmouseout = function(in_event) { domTT_mouseout(this, in_event); };
+ }
+ if (in_options.get('type') == 'sticky')
+ {
+ if (in_options.get('position') == 'absolute' && domTT_dragStickyTips)
+ {
+ if (domLib_isIE)
+ {
+ captionRow.onselectstart = function() { return false; };
+ }
+ captionRow.onmousedown = function(in_event) { domTT_dragStart(tipObj, in_event); };
+ captionRow.onmousemove = function(in_event) { domTT_dragUpdate(in_event); };
+ captionRow.onmouseup = function() { domTT_dragStop(); };
+ }
+ }
+ else if (in_options.get('type') == 'velcro')
+ {
+ tipObj.onmouseout = function(in_event) { if (typeof(in_event) == 'undefined') { in_event = event; } if (!domLib_isDescendantOf(in_event[domLib_eventTo], tipObj)) { domTT_deactivate(owner.id); }};
+ }
+ if (in_options.get('position') == 'relative')
+ {
+ tipObj.style.position = 'relative';
+ }
+ if (in_options.get('parent') != document.body)
+ {
+ in_options.get('parent').appendChild(tipObj);
+ }
+ in_options.set('node', tipObj);
+ in_options.set('status', 'inactive');
+}
+function domTT_show(in_ownerId, in_event)
+{
+ var tooltip = domTT_tooltips.get(in_ownerId);
+ var status = tooltip.get('status');
+ var tipObj = tooltip.get('node');
+ if (tooltip.get('position') == 'absolute')
+ {
+ if (tooltip.has('x') && tooltip.has('y'))
+ {
+ var mouse_x = tooltip.get('x');
+ var mouse_y = tooltip.get('y');
+ }
+ else if (!domTT_useGlobalMousePosition || status == 'active' || tooltip.get('delay') == 0)
+ {
+ var eventPosition = domLib_getEventPosition(in_event);
+ var mouse_x = eventPosition.get('x');
+ var mouse_y = eventPosition.get('y');
+ }
+ else
+ {
+ var mouse_x = domTT_mousePosition.get('x');
+ var mouse_y = domTT_mousePosition.get('y');
+ }
+ if (tooltip.get('grid'))
+ {
+ if (in_event.type != 'mousemove' || (status == 'active' && (Math.abs(tooltip.get('lastX') - mouse_x) > tooltip.get('grid') || Math.abs(tooltip.get('lastY') - mouse_y) > tooltip.get('grid'))))
+ {
+ tooltip.set('lastX', mouse_x);
+ tooltip.set('lastY', mouse_y);
+ }
+ else
+ {
+ return false;
+ }
+ }
+ var coordinates = {'x' : mouse_x + tooltip.get('offsetX'), 'y' : mouse_y + tooltip.get('offsetY')};
+ coordinates = domTT_correctEdgeBleed(tooltip.get('offsetWidth'), tooltip.get('offsetHeight'), coordinates.x, coordinates.y, domTT_offsetX, domTT_offsetY, tooltip.get('type'));
+ tipObj.style.left = coordinates.x + 'px';
+ tipObj.style.top = coordinates.y + 'px';
+ tipObj.style.zIndex = domLib_zIndex++;
+ }
+ if (status == 'pending')
+ {
+ tooltip.set('status', 'active');
+ tipObj.style.display = '';
+ tipObj.style.visibility = 'visible';
+ var fade = tooltip.get('fade');
+ if (fade != 'neither')
+ {
+ var fadeHandler = tooltip.get('fadeHandler');
+ if (fade == 'out' || fade == 'both')
+ {
+ fadeHandler.pause();
+ if (fade == 'out')
+ {
+ fadeHandler.reset();
+ }
+ }
+ if (fade == 'in' || fade == 'both')
+ {
+ fadeHandler.fadeIn();
+ }
+ }
+ if (tooltip.get('type') == 'greasy' && tooltip.get('lifetime') != 0)
+ {
+ tooltip.set('lifetimeTimeout', domLib_setTimeout(function(argv) { domTT_deactivate(argv[0]); }, tooltip.get('lifetime'), [in_ownerId]));
+ }
+ }
+ if (tooltip.get('position') == 'absolute')
+ {
+ domLib_detectCollisions(tipObj);
+ }
+}
+function domTT_deactivate(in_ownerId)
+{
+ var tooltip = domTT_tooltips.get(in_ownerId);
+ if (tooltip)
+ {
+ var status = tooltip.get('status');
+ if (status == 'pending')
+ {
+ domLib_clearTimeout(tooltip.get('activateTimeout'));
+ tooltip.set('status', 'inactive');
+ }
+ else if (status == 'active')
+ {
+ if (tooltip.get('lifetime'))
+ {
+ domLib_clearTimeout(tooltip.get('lifetimeTimeout'));
+ }
+ var tipObj = tooltip.get('node');
+ if (tooltip.get('closeAction') == 'hide')
+ {
+ var fade = tooltip.get('fade');
+ if (fade != 'neither')
+ {
+ var fadeHandler = tooltip.get('fadeHandler');
+ if (fade == 'out' || fade == 'both')
+ {
+ fadeHandler.pause();
+ fadeHandler.fadeOut();
+ }
+ else
+ {
+ fadeHandler.stop();
+ }
+ }
+ else
+ {
+ tipObj.style.display = 'none';
+ }
+ }
+ else
+ {
+ tooltip.get('parent').removeChild(tipObj);
+ domTT_tooltips.remove(in_ownerId);
+ }
+ tooltip.set('status', 'inactive');
+ domLib_detectCollisions(tipObj, true);
+ }
+ }
+}
+function domTT_mouseout(in_owner, in_event)
+{
+ if (!domLib_useLibrary) { return false; }
+
+ if (typeof(in_event) == 'undefined')
+ {
+ in_event = event;
+ }
+ var toChild = domLib_isDescendantOf(in_event[domLib_eventTo], in_owner);
+ var tooltip = domTT_tooltips.get(in_owner.id);
+ if (tooltip && (tooltip.get('type') == 'greasy' || tooltip.get('status') != 'active'))
+ {
+ if (!toChild)
+ {
+ domTT_deactivate(in_owner.id);
+ }
+ }
+ else if (!toChild)
+ {
+ try { window.status = window.defaultStatus; } catch(e) {}
+ }
+}
+function domTT_mousemove(in_owner, in_event)
+{
+ if (!domLib_useLibrary) { return false; }
+
+ if (typeof(in_event) == 'undefined')
+ {
+ in_event = event;
+ }
+
+ var tooltip = domTT_tooltips.get(in_owner.id);
+ if (tooltip && tooltip.get('trail') && tooltip.get('status') == 'active')
+ {
+ domTT_show(in_owner.id, in_event);
+ }
+}
+function domTT_addPredefined(in_id)
+{
+ var options = new Hash();
+ for (var i = 1; i < arguments.length; i += 2)
+ {
+ options.set(arguments[i], arguments[i + 1]);
+ }
+
+ domTT_predefined.set(in_id, options);
+}
+function domTT_correctEdgeBleed(in_width, in_height, in_x, in_y, in_offsetX, in_offsetY, in_type)
+{
+ var bleedRight;
+ var bleedBottom;
+ if (document.documentElement.clientHeight)
+ {
+ var pageHeight = document.documentElement.clientHeight;
+ var pageWidth = document.documentElement.clientWidth;
+ var pageYOffset = document.documentElement.scrollTop;
+ var pageXOffset = document.documentElement.scrollLeft;
+ }
+ else
+ {
+ var pageWidth = document.body.clientWidth;
+ var pageYOffset = window.pageYOffset;
+ var pageXOffset = window.pageXOffset;
+ if (domLib_isKonq)
+ {
+ var pageHeight = window.innerHeight;
+ }
+ else
+ {
+ var pageHeight = document.body.clientHeight;
+ }
+ }
+ if ((bleedRight = (in_x - pageXOffset) + in_width - (pageWidth - domTT_screenEdgePadding)) > 0)
+ {
+// TGN's another fix - for bleed problems
+// in_x -= bleedRight;
+ in_x -= (in_width + in_offsetX);
+ }
+
+ if ((in_x - pageXOffset) < domTT_screenEdgePadding)
+ {
+ in_x = domTT_screenEdgePadding + pageXOffset;
+ }
+ if ((bleedBottom = (in_y - pageYOffset) + in_height - (pageHeight - domTT_screenEdgePadding)) > 0) {
+ if (in_type == 'sticky') {
+ in_y -= bleedBottom;
+ }
+ else
+ {
+ in_y -= in_height + (2 * in_offsetY) + domTT_mouseHeight;
+ }
+ }
+ if ((in_y - pageYOffset) < domTT_screenEdgePadding)
+ {
+ if (in_type == 'sticky')
+ {
+ in_y = domTT_screenEdgePadding + pageYOffset;
+ }
+ else
+ {
+ in_y += in_height + (2 * in_offsetY) + domTT_mouseHeight;
+ }
+ }
+ return {'x' : in_x, 'y' : in_y};
+}
+function domTT_isActive(in_ownerId)
+{
+ var tooltip = domTT_tooltips.get(in_ownerId);
+ if (!tooltip || tooltip.get('status') != 'active')
+ {
+ return false;
+ }
+ else
+ {
+ return true;
+ }
+}
diff --git a/articles/pie-maker/java/domTTtext.js b/articles/pie-maker/java/domTTtext.js
new file mode 100755
index 0000000..7a42471
--- /dev/null
+++ b/articles/pie-maker/java/domTTtext.js
@@ -0,0 +1,86 @@
+var Title = new Array();
+var Body = new Array();
+Title[0]="Body Background Color";
+Body[0]="Default: #EEEEEE
The left column can intrude upwards into the Header Block by this many Sub- Headers.
Due to a problem with Gecko based browsers, if you want to have links and/or form controls inside this intrusion area, you mustn't set the Header to be separate from the Main Body and the intrusion must be into all the header rows.The right column can intrude upwards into the Header Block by this many Sub- Headers.Due to a problem with Gecko based browsers, if you want to have links and/or form controls inside this intrusion area, you mustn't set the Header to be separate from the Main Body and the intrusion must be into all the header rows.The left column can intrude downwards into the Footer Block by this many Sub- Footers.Due to a problem with Gecko based browsers, it is not possible to have links and/or form controls inside this footer row intrusion area.The right column can intrude downwards into the Footer Block by this many Sub- Footers.Due to a problem with Gecko based browsers, it is not possible to have links and/or form controls inside this footer row intrusion area.Good news! The Version History, Design Notes and Contact details have been moved off this page! Use the link to Version History to read these.
+After a long wait, a revised version of the full height pagemaker (once this version + is settled down, I will add a radio button to remove the full height hacks for those + of you who always fill their pages, even for 1600x1200 screens!). Big John persuaded + me to do some work after over a year of me getting my head down at a new job and + relegating this project to the bottom of the pile. Thanks for the push John - I've + really enjoyed getting my hands dirty again! My own server wasn't doing much for me, + so John offered to host this tool on his site, so Kudos to him.
+This one was really tidying up the bugs with Gecko based browsers (the big one was + the incorrect sizing of the left and right columns if they were not equal in width). + I have also made some changes to the way the CLEAR div works to force Gecko browsers + to behave with floated divs. Note that there is one just before the FOOTER div. This + is needed to make Safari behave. If it is not there, if you re-size the Safari window, + the footer stays where it is, rather than moving to the new bottom of the page position.
+This design does not use images to fill the background (unless you want to use one of my + repeating background images for the filler to either side of the main content). The + pagemaker no longer allows you to set horizontal borders on the various bits. Instead, it + sets a horizontal div at the pixel thickness of the border with a suitable background color. + The default layout gives you an example of how.
+Why? I hear you ask. Because most designers won't leave their page design to just this + skeleton of boxes, but will add 3D effects. Note how this page uses VERY minimal images to + give such an effect, WITHOUT the use of floats. Cool, huh?
+So, what do I need now? Folks with browsers I don't have (IE6 and Firefox 1.07 PC) to check + it out. If someone has the latest version of Opera, can you check it out with the window + in restored state and try to re-size it. Does Opera still fail to recalculate where + everything should be (it used to leave the footer in a weird place)? Does Safari work OK?
+I hope you benefit from using the tool (you may have to enable Javascript if you have it enabled, and Internet Explorer may warn you about Active-X, where you must allow content). Use the new link at the top of the page to load the Pagemaker Tool.
+
+ Except where owned by others © ClevaTreva Designs 2005
++Each of the 27 expressions for Conditional Comments give either +"true" +or +"false" +(for the latter, to be more precisely, their negations give +"true"): +
+ +| + IE + | ||||
| + lte IE 5 + | + IE 5 + | + gte IE 5 + | + gt IE 5 + | |
| + lte IE 5.0 + | + IE 5.0 + | + gte IE 5.0 + | + gt IE 5.0 + | |
| + lt IE 5.5000 + | + lte IE 5.5000 + | + IE 5.5000 + | + gte IE 5.5000 + | + gt IE 5.5000 + |
| + lt IE 6 + | + lte IE 6 + | + IE 6 + | + gte IE 6 + | + gt IE 6 + |
| + lt IE 7.0 + | + lte IE 7.0 + | + IE 7.0 + | + gte IE 7.0 + | |
| + lt IE 7 + | + lte IE 7 + | + IE 7 + | + gte IE 7 + |
+As you can see, all expressions work correctly. The test below checks for variations on +version numbers, most of which are supposed to be acceptable syntax according to Microsoft. +Problems occur in IE 5.5, so this table may give you some reasoning, why to avoid those +problematic version numbers in your CC's. +
+ +| + IE 5 + | + IE 5.0 + | + IE 5.00 + | + IE 5.000 + | + IE 5.0000 + | + IE 5.00000 + |
| + IE 5 + | + IE 5.5 + | + IE 5.50 + | + IE 5.500 + | + IE 5.5000 + | + IE 5.50000 + |
| + IE 6 + | + IE 6.0 + | + IE 6.00 + | + IE 6.000 + | + IE 6.0000 + | + IE 6.00000 + |
| + IE 7 + | + IE 7.0 + | + IE 7.00 + | + IE 7.000 + | + IE 7.0000 + | + IE 7.00000 + |
+
+Manfred Staudinger
+e-mail: Manfred.Staudinger@gmail.com
+Last updated: October 27, 2006
+Created Febuary 4, 2005
+
+
+
+
++ Pretty slick, eh? All of these elements use the same three .png's and + have the same DIV tag sets enclosing + them, along with specialized classes on div.outerpair1 + for positioning and extra styling. Notice how the .png shadows allow the + pattern and the other elements to show thru, and how when the shadows cross + over each other the shadow deepens, just as would be the case with real shadows. +
+ ++ This shadow trick even works on scrolling text boxes, assuming that they have + been given specific heights on div.innerbox. +
+ ++ IE6 and below cannot read the nested DIV rules because they contain "child" + combinators, and so browsers <IE7 see a plain set of unstyled nested DIV's. + Thus the appearance is the same except for the lack of the shadow backgrounds. +
+ ++Go ahead and hover the image to see the glow. Pretty good, eh? +Resize the text to make the image resize, proving the method works +on all content sizes. +
+ +
+ This browser is
IE/Win
This browser is
not IE/Win
This page uses conditional comments to detect versions of Internet Explorer and create a wrapper div in depending on the detected version. We use the ID of one of these divs to create CSS rules targeted at any version of IE.
+ + ++Grab ahold of the window edge and drag it back and forth. When it's narrowed down, +the center column shrinks until the wrapper reaches a set minimum width. Going the other +way, the center widens up to a set width and then locks. Pay special attention to +the side "margins" +while this is happening. Notice how the side spaces also grow while the center col +is widening? This is the Jello Mold effect in action, and you may easily customize +the ratio between the widening rates of the wrapper and the center col. +
+ ++The lower limit is reached when the side body paddings touch each other, in this case +at 680px window width. This means that no scripting is needed for the inclusion +of IEwin to the min-width effect! The upper limit is enforced by a max-width +on #sizer, and IEwin is included via an "expression" hidden in a +Conditional Comment in the head. While this is a script, the user cannot disable +this type of CSS expression when disabling JavaScript. +
+ ++Both these limits are easily customized, btw. The min-width effect the result only +of CSS padding, so it is "natural" and works in all modern browsers without problems, +including IEmac, which does not obey the max-width effect unfortunately. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 4, 2008
+Created July 18, 2005
+
+The side columns are exactly 200px wide, but that width can be modified by resetting +three indicated critical values in the stylesheet. The same goes for the borders between the +cols, which have their own critical value sets. +
+ +Click For Longer Column
+ ++Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh +euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad +minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut +aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in +vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis +at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril +delenit augue duis dolore te feugait nulla facilisi. +Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh +euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad +minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut +aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in +vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis +at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril +delenit augue duis dolore te feugait nulla facilisi. +Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh +euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad +minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut +aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in +vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis +at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril +delenit augue duis dolore te feugait nulla facilisi. +
+ ++This column has a problem at some window widths when viewed in Gecko browsers, +due to 1px rounding errors. Observe the links and heading closely while dragging the +window width in Gecko, and you will see those items jiggling back and forth by 1px. +
+ +Click For Longer Column
+ ++Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh +euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad +minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut +aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in +vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis +at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril +delenit augue duis dolore te feugait nulla facilisi. +Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh +euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad +minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut +aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in +vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis +at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril +delenit augue duis dolore te feugait nulla facilisi. +Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh +euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad +minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut +aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in +vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis +at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril +delenit augue duis dolore te feugait nulla facilisi. +
+ +Froggy Footer
+Return to Jello Mold Explanation
+ +Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Pellentesque quis dolor id risus congue rhoncus. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Nulla elementum urna in velit. Integer vel ipsum. Quisque eget tellus. Phasellus rhoncus, libero et tristique euismod, sem wisi imperdiet felis, vitae dignissim diam erat sed nisl. Nunc rutrum erat ut wisi. Ut neque purus, ullamcorper quis, placerat at, molestie id, sapien. Mauris in pede. Donec tincidunt fermentum turpis. Sed dapibus, nisl at aliquam dapibus, augue lorem varius lorem, nec egestas turpis urna in metus. Suspendisse vulputate. Sed sit amet lacus. Nulla sem tellus, sagittis sodales, gravida gravida, egestas fermentum, est.
+Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Praesent vel tellus. Aenean pede odio, condimentum ornare, convallis in, ornare non, dui. Sed diam. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Fusce faucibus leo ut lorem. Donec tempus. Donec at arcu eget eros luctus tempus. Proin porta consequat metus. Nunc faucibus lobortis odio. Ut tincidunt, arcu quis sollicitudin cursus, diam arcu eleifend nunc, id fringilla erat mi sed urna. Fusce porta sapien nec quam. Nam pede erat, aliquam sed, vestibulum sed, auctor in, enim.
+ +Maecenas ultrices augue id ante. Nulla hendrerit est non nulla. Vestibulum orci mauris, mattis sit amet, mollis eget, aliquam at, ipsum. Aliquam erat volutpat. Curabitur mauris. Pellentesque augue lorem, elementum eget, egestas ultrices, molestie a, odio. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Ut pede augue, euismod ac, sodales et, vulputate vitae, dolor. Fusce lorem. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut nonummy sapien sed lacus.
+This tool allows you to specify exactly how you would like your customized + Jello Mold to behave. You specify a maximum and minimum + width for your site, and then you can also specify the exact browser width at which + the maximum width is first reached.
+ +For example, if your design is flexible between 700px and 990px, you can show the full + 990px width immediately when the browser's width is 990px. Or, alternatively, you can + set it to not reach this width until the browser is something larger, like 1280px.
+ +Why would you want to do such a thing? Using this technique allows you + to keep very tight control of the width of your site, but still provide the experience + of a liquid layout to a wide range of screen resolutions. Rather than just the 800x600 and + 1024x768 users seeing a liquid layout, now the 1280x1024 ones will see something liquid as + well. It makes the user feel more in-control; it makes them feel like you're + properly utilizing their screen real-estate.
+ +Once you've got some values, submit it, and you can see the effect immendiately + in this very page's styles. When you see what you like, view the source of + this page and help yourself to your new customized code!
+ +You are providing the script with a set of values to use when calculating + the Jello Mold settings. The wrapper and window are equal at the minimum width, + making a ratio between them of 1. This ratio will gradually + change as window width is increased until it matches your maximum width point. + Beyond that width, the maximum-width rules prevent the site from becoming any + wider.
+The author of this tool and the inventor of the Jello Mold concept is + Mike Purvis, + a Canadian Engineering student who codes and writes when he can find the time.
+
+ +Open this page in each of your installed browsers, and then drag the window widths +narrower and wider. See those little flickering lines on the end of the blue boxes? +They are a form of 1px error that may occur in any browser, but the errors manifest +differently from browser to browser. +
+ +This blue box has a specified width of 700px and has side auto margins.
++ The grey boxes above and below are contained in a green-bordered DIV with no stated dimensions, + and a dark colored 700px background image is centered via background-positioning + inside the red bordered parent DIV. The blue child boxes are + given defined widths. The upper box has a width equal to the background image on the parent, + while the lower box width is one pixel less. They are both centered within the + green bordered parent via auto side margins. +
+ +This blue box has a specified width of 699px and has side auto margins.
+This blue box has a specified width of 699px and has side auto margins.
++ This test has a 699px background image, one pixel less wide than the 700px + background image in the previous test. The two blue test boxes are also reduced by 1px + in width from those in the previous test. This is done so that background images + of both odd and even widths are tested. The blue boxes also come in two widths to + provide odd/even testing for the auto margined block elements. +
+ +This blue box has a specified width of 698px and has side auto margins.
++The above tests are designed to show what can happen in various browsers when an +element has a centered, vertically repeating background image, and also a nested +block element within +that is centered via its own "auto" side margins. You would think that +centering is just centering, but you would be wrong. If the container (or body +element perhaps) is as wide as the window, the computed width of the container box +might be almost any number of pixels. That pixel width will sometimes be odd, and sometimes even. +
+ ++So when the browser is told to center a background image within that container, it +has to decide where the actual center lies. In the case of an odd total pixel width, +the browser must select one side or the other of the central odd pixel as the +"center" of the container. Then it has to find the center of the background +image, also fudging a bit if the BG's width is an odd number. +
+ ++Obviously there is already lots of scope for variance between browsers when handling +this issue, but then suppose there is a width sized block element placed into that +container. Centering that box involves giving it side margins, both set to auto, +which are supposed to center it within its parent container. +
+ ++So we have a background image, centered via the background-position property, +and the overlying box is centered via the margin property. In an +ideal world these two methods would behave the same regardless of the true width +of the container, but in fact they don't, and the ways they behave will vary in +each of the modern browsers. Each time you see one of those errors in the demos +(either as gaps or as box extensions beyond the BG to the left), it indicates that the centering +methods are not in sync with each other. +
+ ++A close examination of different browsers will show that each has a unique pattern to +their combined centering displays as the window width is varied. IEwin +is the one that has the problem when both the blue test box and the background image are the +same "even" pixel width, but if both are an "odd" width then it +is Firefox that gets it wrong! Opera only shows errors when the BG and test box are +opposite, one being even and the other odd. +
+ ++There is no combination +of odd/even widths on background images and test boxes that will behave identically in +all browsers. If you can discover a combination that does work the same in all browsers, +we want to know about it. +
+ ++Typically a coder will have a centered wrapper element holding all the page content, and +then assign a centered background image to the body showing fades or dropshadows +that are meant to be aligned behind wrapper. Unfortunately these unsuspecting coders +don't realize that their paired (but separate and different) centering alignments +will be misaligned for half of all possible window widths! +
+ ++If the cause is not understood, the BG will appear offset by 1px in 50% of all window displays. +And even if the coder happens to discover that dragging makes their BG do the "Cha-cha," +their ever more frantic attempts to achieve cross-browser compliance can easily +lead to a mental breakdown. +
+ ++There are two basic ways to solve this issue. One is to design the background image +so that the BG offset effect looks okay in either position. The other way is to +create a pair of nested wrappers, with the outer having a BG sized to exactly +match the width of the wrapper, and the inner wrapper serving as the "content" +wrapper. +
+ ++In this case the outer wrapper would be slightly wider than the content-holding +inner wrapper, so that the outer wrapper may hold a BG image that will be visible +around the edges of the inner wrapper. +
+ ++The outer wrapper is then itself centered via side auto margins, +while the inner wrapper is not centered at all. Instead, this +slightly narrower inner wrapper should be scooted over via a left pixel margin, +until it "appears" to be centered over the BG on the outer wrapper, +leaving just a little of that outer BG peeping around the edges of the inner wrapper. +
+ ++Since no centering is applied to this inner wrapper or to the BG on the outer wrapper, +the misalignment cannot occur. Both wrappers act as a unit, and if they jiggle, they +do so together. Ain't that nice? +
+ ++The width difference between the two wrappers is determined by how much background +image you wish to have show on either side of the inner wrapper. +
+ ++Obviously all this applies only to rigidly sized wrappers, since a background image +cannot be liquid. However, the double wrapper trick can be extended to a third wrapper +so that left and right side dropshadow BG's could be placed behind the liquid wrapper, +each in a separate liquid wrapper DIV, but we'll save that for a future tutorial, +If we ever find time. Anyway, you now know how to avoid getting the dreaded +"bi-polar page disorder", and do spread the word, okay? +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: December 28, 2005
+Created October 31, 2005
+
+
+This may not be very pretty, but you can see that the entire nav is usable. We are +waiting on some scripting that will allow a keypress to manually expand the nav +so that tabbing is easy, after which another keypress will collapse the nav again. +
+ ++A first attempt has been made at the keypress script, but it is not clean in all +modern browsers, so we will stay on the hunt for such a solution. +
+ + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: October 23, 2006
+Created April 6, 2005
+
+This demo uses red borders to outline the invisible divs that are the true popup +elements. The UL elements are just the visible "passengers", and are children of +the div popups. +
+ ++The tiny red boxes are special "mini-zones" used to fill in the corner where +users might tend to cut across while moving to the flyout. This mini-zone can +be customized to any size and shape, as can the larger hover zones. However, +considerable tweaking of margins and widths would be necessary in that case. +
+ ++Note how the zones of the highest flyout divs cover the top nav, and yet do +not prevent direct hovering of those top nav links. Used properly, z-index can do +wonderful things! +
+ + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: October 23, 2006
+Created April 6, 2005
+
+In case you haven't done so yet, go ahead and hover those blue links, okay? +
+ ++Pretty cool, eh? The same tricks employed for the +CSS Flyouts demo are used here, +but with a lot of obvious modifications. The same Jscript makes IE obey hover on +any element, and the "sticky hovering" method is applied here as well. +
+ ++Go to this demo page to see +the nav with red borders outlining the sticky hover zones. +
+ ++IE7 has arrived, and it does not read the star-html hack. Thus we +have modified the conditional comment containing the csshover.htc file call so that +only IE6 and lower will do so. Further we have added a new CC that feeds IE7 and +above the modern equivalent to the old Holly hack, using the MS proprietary +zoom property. +
+ ++IE7 also obeys dimensions without the old +Expanding Box effect, +so the zoom property is used instead to trigger hasLayout in IE7 and up. Since +zoom is not valid, we hide it inside the CC to let the page validate. +
+ ++Finally IE7 obeys hovering on any element, so the CC that contains the .htc file +call has been re-targeted to IE6 and lower, letting IE7 ignore that unneeded script +and operate faster. +
+ ++This method does not work in IEmac, but a hack feeds "dumb down" +css to that browser so that it shows the entire nav system on screen all at once. +Nothing is covered, as the expanded nav is made to "flow" at the same time it is +expanded. +
+ ++IEwin will also fail if security is set to "High", so to allow +for such users we have applied those same expansion rules in a +<noscript> block, that is itself within the conditional comment +we used to hide the behavior scripting call. These things are seen only by IEwin, +taking care of that browser while still allowing the page to validate. +
+ ++Go to this demo page +to see the fully expanded nav that would be shown in IEmac, and in IEwin with +scripting turned off. +
+ ++The entire nav is semantically just a set of nested lists, making for reasonable +accessibility. +
+ ++This nav works in IE5, IE5.5, IE6, Op7, Gecko, Konqueror, and Safari. +IEmac fails to support the hover method used, and so gets the expanded nav +instead. IEwin with scripting disables also gets the expanded nav. Nav 4 does not +support this method, or much else for that matter. +
+ ++If the sticky hovering zones protrude beyond the right viewport edge when they +appear, it can cause a momentary horizontal scroll to appear. It will happen +in this demo page if the window is set to a width of 800px. In a production page +it would be fairly easy to narrow the wrapper slightly or reduce the right +hover zone on the elements that are a problem. Just be aware it can happen so +that you can fix it before the boss notices. +
+ ++The Jscript that we're using to handle IE6 does +cause a great deal of recursion in the browser, which appears as a noticably lengthened load time +when viewed in slower systems, and also as actual slow functioning of the nav itself, primarily in +IE5/win. A less complex nav than the one above will significantly reduce the problem, and using ID +node names on your :hover +rules will help a lot too. Specifically div.parent:hover is +better than than div:hover or .parent:hover, +and div#parent:hover is faster still. +
+ ++When Service Pack 2 is installed on Windows, the Jscript in the +.htc file will only work in IE6 when correctly served with the mime type +text/x-component. Mime types are defined by the server +administrator, so if your server is incorrectly set, IE6 may fail to +show the popups. That's just the way it is, folks. +
+ ++A simpler script method for handling IE6 does exist, the +Suckerfish script. +Basically the script watches the links to be hovered, +and when the mouseover event is triggered on a link it gets a class name applied, but +only during the mouseover event. Then you write duplicate selectors for the +hover rules, but referencing the JS-applied class name. The resulting IE6 faux-hovering +is effective and doesn't need a specical served mime type (simple JS file), but at the cost +of having to modify the CSS hover rules just a bit. +
+ ++IE6 has a well known background image caching issue, which seems +to be partially active in this demo. Apparently when the nav is very large (as this +one is), and the processor is slow, the cursor will show a very short flash of the +"working in background" cursor as you pass from one link to the next. +
+ ++There is a transparent bgfix.gif background image on the divs +(a fix for an IE hover bug), which appears to be the root cause. As we say, with +a smaller nav the flicker may never actually appear with some navs, but if it +does it can be corrected only by making changes to the server itself. +
+ ++Well, there is always the option of not having sticky hovering, but that seems +rather extreme for a problem so minor that we overlooked it for several weeks. +
+ ++For instructions on fixing an IIS server go to this +Stop Image Flicker +tutorial, and for the Apache server, go to this +Fivesevensix.com +tutorial. A hat tip to +Bryce Fields +for pointing out the existing fixes for this issue. We keep forgetting this stuff... +
+ ++The source for this demo is fully commented, but we will not be writing a full +tutorial on the method here. Rather, a complete, in-depth tutorial series is available +at CommunityMX.com, (currently in production +under the series title "CSS Flyouts"), where you may view them after signing up +for a free ten day trial membership +(requires proof of ability to pay to receive the free trial). +
+ +
+This article is now available in Russian,
+thanks to the efforts of Patricia Clausnitzer.
Thanks Patricia! :-)
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: August 14, 2010
+Created April 6, 2005
+
+ +These two navs have identical HTML, other than classes for the brown arrows, and they +are driven entirely via CSS rules. +Scripting is not required, other than to make IE/win obey :hover +when applied to non-links. The navs are floated opposite, sometimes touching the +clearing element below. +
+ ++The elements above are floated and cleared in a way designed to expose any IE float bugs +that could occur, but they are all suppressed in this method. However, if the nav is at the +bottom of the screen content, IE6 does not enjoy having the flyouts go below the bottom +of the body element and will let the flyouts vanish when those low flyouts are hovered below +the flowed content. A large bottom padding on the body element would satisfy IE +in that rare case. +
+ ++IE/Mac does not support this method, but it has been hack-fed a set of dumbed down +rules to make the nav fully expand for accessibility. Additionally, there is a +<noscript> block that holds similar code for IE/Win when Javascript +is disabled, and the <noscript> block is inside a Conditional Comment, along +with the MS proprietary Jscript behavior call that makes it all work. +
+ ++The Jscript is the work of +Peter Nederlof, +and fine work it is, too. This script not only makes IE support all hovering, but +all :active events as well. Try clicking on the H1 element in IE/win +for a shocker! +
+ ++A simpler script method for handling IE6 does exist, the +Suckerfish script. +Basically the script watches the links to be hovered, +and when the mouseover event is triggered on a link it gets a class name applied, but +only during the mouseover event. Then you write duplicate selectors for the +hover rules, but referencing the JS-applied class name. The resulting IE6 faux-hovering +is effective and doesn't need a specical served mime type (simple JS file), but at the cost +of having to modify the CSS hover rules just a bit. +
+ ++In this page we've added a small JS file from +Son of Suckerfish +to enhance keyboard focussing. +
+ + ++When Service Pack 2 is installed on Windows, the proprietary +.htc file +will only work in IE6 when correctly served with the mime type +text/x-component. Mime types are defined by the server +administrator, so if your server is incorrectly set, IE6 will fail to +show the popups. That's just the way it is, folks. Hmmm, that Suckerfish is +looking better and better... +
+ ++Update (Feb 26, 2005): It now appears that setting IE6's image +cache away from "Automatically" +is the cause of both the arrow calls (known effect) and also the border bleed-thru +effect. It appears that the BG images themselves have something to do with the border +bug, so avoiding the arrows or rearranging the CSS might prevent this border bug. +However, very few users ever mess with the cache settings, and a server-side fix +exists here. +
+ ++Update (Feb 27, 2005): The method has been enhanced by the addition +of divs into the +nested list structure. The divs provide hoverable padding areas +around the flyouts, +which are more forgiving of shaky-handed users who may stray off the flyouts. The +flyout functioning is exactly the same, and the divs are semantically null so they +do not alter the list structure for screen readers and search engines. +
+ ++Structural classes have been eliminated, but reverse z-indexing is required and +cannot be applied via the stylesheet without the use of sibling selectors, which +IE/Win does not support. However, if the arrows are omitted and a database can +apply descending z-index styling to the list items as they are outputted, then +a dynamically generated navigation could be achieved with this method. +
+ ++Currently the demo is set to a pixel width, but we plan to try it out with an +EM width and are very confident it will work just as well that way. At least we hope so... +
+ ++Update (April 6, 2005):This method has been demoed as a combo dropdown +and flyout "flat" menu. Go to the +Deluxe CSS Dropdowns and Flyouts +page, to get a load of what CSS can really do. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 2, 2008
+Created February 25, 2005
+
+If you're here, the reason is either because your browser is scripting-disabled +or you don't have an email client set up. I'm planning on putting a contact page +here to cover this eventuality, but it takes time. My philosophy of coding requires +me to understand all code that appears on PIE, and as of yet I've not gotten +the dynamic side of the site running. When that finally happens you will see +a glorious contact page that would make a mother proud. Until then, I apologize +and offer an obfuscated text representation of my email addy: +
+ ++cssjunkie >at< frontiernet * net +
+ + + + + + \ No newline at end of file diff --git a/design/favicon.html b/design/favicon.html new file mode 100755 index 0000000..420e58a --- /dev/null +++ b/design/favicon.html @@ -0,0 +1,44 @@ + + + + ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +
+
+
+Do you need a highly experienced CSS consultant who can work with a team and prides
+himself on clean commented code that never says "No" to a client's desired compositions?
+Look no further, you've found him.
+I'm a middle-aged guy who took up web design in 1999 as a hobby and discovered my
+true life's work. I've concentrated on CSS but have also become familiar with Javascript,
+PHP, and particularly web graphics production.
+
+If you're a Big Wheel (or plan to be one) who requires the services of someone +who really understands HTML, +CSS, and (some) JS, and won't pretend to know more than he does, let's talk. +
++Skype Big John at: cssjunkie (Please message me first) +
+ ++Linkedin bio +
++IE6 is on the way out, but it's not dead yet. If you want to take advantage +of the capabilities that IE7 offers but can't ignore the IE6 crowd, I bring extensive +experience to the task of "dumbing down" IE6's display so it won't fail when you +employ advanced CSS and scripting. The methods may be customized to suit +any level of IE6 support you feel comfortable using. +
++Javascript can greatly enhance CSS layouts while degrading gracefully in non-scripting +browsers. Javascript can also help IE6 to behave more in line with modern standards. +I offer such Javascript enhancements and I stand behind their interoperability with +the rest of your scripting environment. +
++I can create most or all of the graphics images needed for a typical site design if desired. +
++In short, you get your CSS'er, JS'er, and graphics guru all together in one moderately +oversized guy. This can result in big savings of time and money on a complex project. +
+ ++Most web designers have a portfolio of sites they've designed for clients, +but in my case that portfolio is largely missing. That's because I primarily do +bug fixing and advanced CSS consulting on already-existing sites. However, +numerous past and present clients will attest to my abilities, so without +further ado, here's a few of the choicer ones! +
+ +
++"A new client asked me to fix some errors in their company website. Since I +inherited the design from another webmaster, I was just not able to fix the +CSS & HTML bugs that caused the site's navigation links to appear in the +wrong place in MSIE6. John were invaluable in fixing the 'bugs' for me and +pointing out a few other issues that improved the look and feel of the site. +Thanks for getting the job done quickly and cost-effectively ... I'll be back +again for more expert help in the future. I highly recommend John's services!" +
+ ++Scott Baer, Founder/CEO of Baercom.com +
+ +
++"Trust me, you can't go wrong with Big John. We stumbled across John +after Googling for fixes to several IE 6 & 7 bugs for Milo.com. He kept +coming up so we thought we'd give him a shot. He's great! Very fast and +responsive. Can fix any problem you're dealing with. He's also willing to +explain fixes to prevent you from running into similar issues in the future +which is very helpful." +
+ ++Jack Abraham, Founder/CEO of Milo.com +
+ +
++"I call Big John my CSS guru. He was a life saver when I was struggling to learn CSS layout. +When my code breaks, I call on him to know what's changed in the browser world and how +to fix it. Having him trouble-shoot my code saves me time and money! He's quick and easy +to work with." +
+ ++Mary Gabel, Owner of GabelGraphics.com +
+ +
++“John is the ultimate HTML / CSS Guru. I highly recommend him to help you +achieve leading edge look and feel. He can debug almost any issue very quickly, +prototype new things for you, and help you deal with nasty browser interoperability +issues. Try him. You'll like the results!” +
+ ++Kurt Robson, Owner of KR Global Development +
+ +
++“John is one of the best CSS programmers I have had the opportunity to work with. +His ability to translate visual design into cross-platform compatible HTML, PHP and +CSS pages is excellent. He has an uncanny ability to immediately trouble shoot a browser +issue and know exactly what is necessary to fix it. I highly recommend him.” +
+ ++Stefani Twyford, Owner of LegacyMultimedia.com +
+ +
++"Most of my users are elderly and still use IE6. I needed help with flyouts and floats. +John was quick to grasp my site’s problems and quicker to provide solutions. I decided +to have John go thru the whole site and clean it up. It now looks better and works in all +browsers. John was prompt to finish tasks and he emailed file updates with complete +instructions. I’ve recommended him to everyone I know." +
+ ++Daniel Keane, Owner of AlphabetSigns.com +
+ +
++"Big John is a valuable part of my programming team. He represents +accurately what he can and can't do and delivers on his promises. He is +willing to explain things to the lay person so they understand the choices +they are making in different coding choices. He also works well with other +programmers when a team effort is required. I recommend him and continue to +use his services." +
+ ++Karen Lile, Owner of KarenLile.com +
+ +
+
+
+Do you need a highly experienced CSS consultant who can work with a team and prides
+himself on clean commented code that never says "No" to a client's desired compositions?
+Look no further, you've found him.
+I'm a middle-aged guy who took up web design in 1999 as a hobby and discovered my
+true life's work. I've concentrated on CSS but have also become familiar with Javascript,
+PHP, and particularly web graphics production.
+
+If you're a Big Wheel (or plan to be one) who requires the services of someone +who really understands HTML, +CSS, and (some) JS, and won't pretend to know more than he does, let's talk. +
++Skype Big John at: cssjunkie (Please message me first) +
+ ++Linkedin bio +
++IE6 is on the way out, but it's not dead yet. If you want to take advantage +of the capabilities that IE7 offers but can't ignore the IE6 crowd, I bring extensive +experience to the task of "dumbing down" IE6's display so it won't fail when you +employ advanced CSS and scripting. The methods may be customized to suit +any level of IE6 support you feel comfortable using. +
++Javascript can greatly enhance CSS layouts while degrading gracefully in non-scripting +browsers. Javascript can also help IE6 to behave more in line with modern standards. +I offer such Javascript enhancements and I stand behind their interoperability with +the rest of your scripting environment. +
++I can create most or all of the graphics images needed for a typical site design if desired. +
++In short, you get your CSS'er, JS'er, and graphics guru all together in one moderately +oversized guy. This can result in big savings of time and money on a complex project. +
+ ++Most web designers have a portfolio of sites they've designed for clients, +but in my case that portfolio is largely missing. That's because I primarily do +bug fixing and advanced CSS consulting on already-existing sites. However, +numerous past and present clients will attest to my abilities, so without +further ado, here's a few of the choicer ones! +
+ +
++"A new client asked me to fix some errors in their company website. Since I +inherited the design from another webmaster, I was just not able to fix the +CSS & HTML bugs that caused the site's navigation links to appear in the +wrong place in MSIE6. John were invaluable in fixing the 'bugs' for me and +pointing out a few other issues that improved the look and feel of the site. +Thanks for getting the job done quickly and cost-effectively ... I'll be back +again for more expert help in the future. I highly recommend John's services!" +
+ ++Scott Baer, Founder/CEO of Baercom.com +
+ +
++"Trust me, you can't go wrong with Big John. We stumbled across John +after Googling for fixes to several IE 6 & 7 bugs for Milo.com. He kept +coming up so we thought we'd give him a shot. He's great! Very fast and +responsive. Can fix any problem you're dealing with. He's also willing to +explain fixes to prevent you from running into similar issues in the future +which is very helpful." +
+ ++Jack Abraham, Founder/CEO of Milo.com +
+ +
++"I call Big John my CSS guru. He was a life saver when I was struggling to learn CSS layout. +When my code breaks, I call on him to know what's changed in the browser world and how +to fix it. Having him trouble-shoot my code saves me time and money! He's quick and easy +to work with." +
+ ++Mary Gabel, Owner of GabelGraphics.com +
+ +
++“John is the ultimate HTML / CSS Guru. I highly recommend him to help you +achieve leading edge look and feel. He can debug almost any issue very quickly, +prototype new things for you, and help you deal with nasty browser interoperability +issues. Try him. You'll like the results!” +
+ ++Kurt Robson, Owner of KR Global Development +
+ +
++“John is one of the best CSS programmers I have had the opportunity to work with. +His ability to translate visual design into cross-platform compatible HTML, PHP and +CSS pages is excellent. He has an uncanny ability to immediately trouble shoot a browser +issue and know exactly what is necessary to fix it. I highly recommend him.” +
+ ++Stefani Twyford, Owner of LegacyMultimedia.com +
+ +
++"Most of my users are elderly and still use IE6. I needed help with flyouts and floats. +John was quick to grasp my site’s problems and quicker to provide solutions. I decided +to have John go thru the whole site and clean it up. It now looks better and works in all +browsers. John was prompt to finish tasks and he emailed file updates with complete +instructions. I’ve recommended him to everyone I know." +
+ ++Daniel Keane, Owner of AlphabetSigns.com +
+ +
++"Big John is a valuable part of my programming team. He represents +accurately what he can and can't do and delivers on his promises. He is +willing to explain things to the lay person so they understand the choices +they are making in different coding choices. He also works well with other +programmers when a team effort is required. I recommend him and continue to +use his services." +
+ ++Karen Lile, Owner of KarenLile.com +
+ +
+(This clearing technique was developed by Tony Aslett, of csscreator.com.
+The earliest known mention of the basic :after idea is found
+here.)
+
+Notice as of March 4th, 2008: The article you are reading is getting a bit old and much new information on the subject of clearing has appeared since it was written. +You may find this newer article very interesting. +
+ ++When a float is contained within a container box that has a visible border or background, that float does +not automatically force the container's bottom edge down as the float is made taller. Instead the float is +ignored by the container and will hang down out of the container bottom like a flag. Those familiar only +with Explorer for Windows may scratch their heads and say "That's not right!" True, IE/Win does enclose +a float within a container 'automatically', but only if the container element happens to possess the MS-only +quality called +hasLayout. +
+ ++This float-enclosing behavior in IE can also be 'toggled' off again just by hovering of links within the container, +if that hovering alters either the link background or one of several other CSS properties. Quite a mess, +and we'll cover it farther along in the article, in the "Toggle Trouble" section. +
+ ++The W3C suggests placing a "cleared" element last in the container box, which is then recognized by the +container height, forcing the container to enclose the float above that cleared element too. It's described +more fully our article Float: The Theory: +
+ ++“..let's say you give that following box the clear property, + {clear: both;} . +What this does is extend the margin on the top of the cleared box, pushing +it down until it "clears" the bottom of the float. In other words, the top +margin on the cleared box (no matter what it may have been set to), is increased +by the browser, to whatever length is necessary to keep +the cleared box below the float.” ++ +
+So in effect, such a cleared box cannot be at the same horizontal level +as a preceding float. It must appear just below that level. The image shows +how this might look, with a red border representing the container element: +
+ +
++The standard method of making an outer container appear to "enclose" +a nested float is to place a complete "cleared" element +last in the container, which has the effect of 'dragging' the lower edge of the containing box lower +than the float. Thus the float appears to be enclosed within the container even tho it really isn't. +The code for a cleared box usually looks something like this: +
+ ++<div> <!-- float container -->+ +
+ <div style="float:left; width:30%;"><p>Some content</p></div>
+ <p>Text not inside the float</p>
+<div style="clear:both;"></div>
+</div> +
+Since that div is not floated, the container must recognize it and enclose +it, and because of that top margin (added by the browser because of the +"clear" property), the div "pulls" the bottom edge of the container down +below the bottom edge of the float. +
+ ++First and foremost, this clearing method is not at all intuitive, requiring an extra element be added to the markup. +One of the major premises of CSS is that it helps reduce the bloated HTML markup found it the average site these days. +So having to re-bloat the markup just so floats can be kept within their containers is not an ideal arrangement. +
+ ++Besides that, some browsers can have trouble with certain kinds of clearing elements in some situations. +Mozilla is particularly sensitive to clearing problems. +
+ ++Up 'til now there was no other way to do this, but no more! Thanks to the efforts of Tony Aslett, +creator and operator of csscreator.com, we can now use advanced +CSS to "clear" a float container in non-IE browsers and just let IE keep wrongly clearing itself. The upshot is that we now have +the option to avoid adding that pesky clearing element to the HTML markup. Woohoo! +
+ ++In the new method, no clearing element is used. This does not affect IE/Win which simply keeps enclosing the +float as always (assuming the container has a stated dimension), but non-IE browsers will need a substitute for +that element. Here's how it's done. +
+ ++This CSS 2 property allows extra content to be +added at the end of an element via the CSS. That means no actual markup is needed in the HTML. The content is +specified from within the CSS stylesheet, and appears in the page as would a real HTML element that had been +inserted following all the normal content of the target element. Such :after generated content cannot receive some CSS properties, +including 'position', 'float', list properties, and table properties. However, the 'clear' property is allowed. +Do you see where we are going here? +
+ ++Imagine that we use :after to insert a simple character like a 'period', and then +give that generated element + {clear: both;} . That's all you really need to do the job, but no one wants +a line space messing up the end of their clean container box, so we also use + {height: 0;} and + {visibility: hidden;} to keep our period from showing. +
+ +
+.clearfix:after {
+ content: ".";
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+}
+
+
++Notice that {display: block;} is also applied to the :after +element, because if it isn't then that element defaults to "inline", and cannot receive the "clear" property. +Also, Tony's method originally used "overflow: hidden;" to hide the period, but sadly the latest FireFox versions +will display the period if this is done. +
+ ++Since IE7 does not support the :after pseudoclass yet, we must rely on the same"auto-clearing" effect used for IE6, +and that behavior happens when the float-containing element gets hasLayout applied to it. +A simple declaration of "zoom: 1;" will perform this trick in IE5.5 and up, but it's proprietary and needs to be +hidden in order to validate. +
+ ++As a side benefit, hasLayout on float-enclosing elements also prevents several other major +IE/Win float bugs. However, should this container box be placed following a previous external +float, the IE height fix will trigger Microsoft's proprietary and illegal +Float Model, so watch out for that, okay? +
+ ++It so happens that IE has, well, a little problem with this auto-enclosing behavior. You saw +that coming, didn't you. Yes, IE bugs come in big bunches. This one results when that container element +has links inside, following the float. When this happens and certain links are hovered, the auto-enclosing +behavior is toggled or "switched off", causing the lower edge of the container box to suddenly jump up +to the bottom of the non-floated content. Hovering other links restores the behavior. This interesting +effect is of course called the IE/Win Guillotine Bug +Those of you viewing in IE/Win may play around with the following live demos, and for a more complete explanation see the +IE/Win Guillotine Bug demo page . +
+ ++The toggling only occurs when a:hover is used to change the link background +or many other styling changes, such as padding, margin, or any +font styling on the link. Strangely, having the text color +change on hover does not toggle the bug. +
+ +
+The containers are grey with green borders, and the floats are dark brown with yellow borders.
+Notice how the third and fourth links ouside the floats toggle the Guillotine Bug, and the first two
+un-toggle it. This seems to be related to the actual text lines themselves, so any links after the first
+two lines will toggle the effect. Links in the float will all un-toggle
+the effect. Just more weird IE bug behaviors, folks, nothing "unusual".
+Screenshot
+
+The second demo has been "fixed" by placing those links in a paragraph, which then gets the zoom fix applied to it. +Any block element will do just as well here. Yes, this means another element is needed, but unlike a clearing div, +this paragraph is a "semantic" element. Text content really ought to be wrapped in semantic containers anyway, and +since we forward-thinking coders always have our content thusly contained, it's easy to apply the same .clearfix class +to one more element. +
+ ++Observant readers will have noticed that the above demos have "enclosed" floats, even in Opera 7 and Mozilla! +This is because the demos themselves are floats, and all modern browsers (including IE, luckily) always let floats +enclose other floats. Of course there has to be an outer float, and it still threatens to break out of its container... +
+ ++First, this code gets added to the CSS stylesheet: +
+ +
+<style type="text/css">
+
+ .clearfix:after {
+ content: ".";
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+
+</style><!-- main stylesheet ends, CC with new stylesheet below... -->
+
+<!--[if IE]>
+<style type="text/css">
+ .clearfix {
+ zoom: 1; /* triggers hasLayout */
+ } /* Only IE can see inside the conditional comment
+ and read this CSS rule. Don't ever use a normal HTML
+ comment inside the CC or it will close prematurely. */
+</style>
+<![endif]-->
+
+
++For the HTML, just add a class of .clearfix to any element containing a float needing to be cleared, +plus any Guillotine-Bug-fixing block elements within the container. +That's it! It's not perfect, but it's a whole lot better than adding an entire extra 'dummy' element. Check out this live demo of the +fix in action: +
+ +This float is not enclosed by the surrounding div container.
+This container lacks the fix.
+See how this float no longer protrudes out of the containing box, with no extra clearing element used in the container!
+This float container has a class attribute of "clearfix", which applies the :after fix, or the Holly hack, depending on the browser.
++All this is wonderful, but unfortunately IE for the Mac does not "auto-clear" floats, and also does not support +:after, and so is left out of the clearing party. What's to be done? +
+ ++You might callously abandon IE/Mac, but consider that many people who use older Macs can't run Safari, +or several other modern browsers. Thankfully this browser has been dropped by Microsoft, and at some +future time the numbers of such IE/Mac users will become miniscule. Remember that even if a float +appears to stick out of a container, no content will actually be obscured. It just won't look as pretty for +those few viewers, that's all. Each author will have to decide on this issue according to their specific needs. +
+ ++This page once described a Javascript method to force compliance in IE/Mac, but now thanks to +Mark Hadley and +Matt Keogh +it's now possible +to dispense with that ugly Javascript and go with a straight CSS fix. Woohoo! +
+ ++Basically the fix is just a matter of applying a display: inline-block; +to the .clearfix class, and hiding that property from all other +browsers. That's it! We can easily do this with our existing code, slightly modified. +
+ +
+<style type="text/css">
+
+ .clearfix:after {
+ content: ".";
+ display: block;
+ height: 0;
+ clear: both;
+ visibility: hidden;
+ }
+
+.clearfix {display: inline-block;} /* for IE/Mac */
+
+</style><!-- main stylesheet ends, CC with new stylesheet below... -->
+
+<!--[if IE]>
+<style type="text/css">
+ .clearfix {
+ zoom: 1; /* triggers hasLayout */
+ display: block; /* resets display for IE/Win */
+ } /* Only IE can see inside the conditional comment
+ and read this CSS rule. Don't ever use a normal HTML
+ comment inside the CC or it will close prematurely. */
+</style>
+<![endif]-->
+
++The .clearfix {display: inline-block;} is seen by all browsers, and fixes IE/Mac. +Then, inside the rule set that is hidden from IE/Mac, the display is reset to block. +That's all she wrote! Simply stick the above code into your CSS, and use .clearfix +on any box that has to contain a sizable float. Ain't that cool? Just watch out for previous external floats +triggering the IE Float Model, as mentioned earlier. +
+ ++Kudos to Alex Robinson +for finding that inline-block is superior to the older inline-table fix for IE/Mac. +
+ ++The W3C float specification requires that a cleared element shall stay below all previous floats. There are no +exceptions to this requirement! "Previous" in this case means any float that comes earlier in the source document. +
++Up until November of 2004, Firefox was still incorrectly clearing only the floats that were vertically above the clearing element, rather +than all previous floats. This meant that in those earlier Gecko browsers you could place a floated column down one side of the +screen, and inside another column (possibly another floated column) you could clear a smaller interior float, without that cleared +element dropping below the previous floated column. +Since only Gecko had this problem, it was obvious that something was wrong every time this happened to a page. Normally Gecko is +the good browser, but in this one case it was the culprit. See, IE is not always the bad guy! +
+ ++However, this easy clearing method has muddled the issue quite a bit, since now Explorer is not actually being cleared at all, +while Gecko browsers have finally been corrected so they do clear all previous floats. +
++...Oh no! Do you see what will now happen +in our hypothetical float page? IE, seeing no real clearing elements, will look great. Meanwhile, in newer +Gecko browsers and Opera 7, the CSS generated clearing element in the first easycleared box will drag the height of that box +waaaay down the page, until that invisible clearer is vertically below the bottom of the previous float column (assuming there +is a bottom!). This can "generate" a huge empty space inside that once-small easycleared box, depending on the actual +height of the neighboring float column. +
+ ++Of course Opera 7 has always correctly implimented the clearing specs just like IE does (aside from bugs), and the Mac browsers +are not involved either. If you are wondering how this issue can be fixed, well, it can't. Gecko and Opera are now both following +the float clearing specs correctly, and IE only fails because of the faked "clearing" we are forcing upon it. +
+ ++If you have the above described problem, one way to prevent the clearer from clearing the +adjacent float column is to make the container a float itself. Of course once you float the +container you no longer need easyclearing, sigh... +
+ ++Note that when all the main elements in a column setup are floats, the worst IE +float bugs simply do not happen. Thus using an all-float approach to column design +can actually be easier to accomplish, at least within a rigid-width layout. +
+ ++Thanks to Tony Aslett for showing us the way. +His site, csscreator.com +is a killer CSS forum where newbies and gurus alike hang out and exchange CSS know-how. Tony's original +demo page for this method can be found here, +and the relevant forum thread is +here. +
+ ++Kudos also to Doug for pointing out the "period problem" +in FireFox, and to Mark Hadley +for that elegant IE/Mac fix, and to +Matt Keogh +for showing how "inline-table" also fixes IE/Mac while using an already-approved +CSS property. Once more the CSS community comes thru for us all! :-)
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 2, 2008
+Created May 14, 2004
+
I've provided advanced CSS consulting for
+Milo
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ ++These CSS bugs are all found only in Internet Explorer, +versions 5 and higher. +To see the demos properly, they must be viewed in IE, of course. +
++I am always looking to improve these demos, so if you know of anything useful, +lay it on me. Please don't hold back; I have yet to write a demo that did not need +corrections, updates and whatever. This site is really a group effort. Be part of that group. :-) +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: April 27, 2009
+Created October 26, 2002
+
Written by Jonathan McLean
+ +This is an IE6-only bug that occurs when the following conditions are met:
+Perhaps not the most common situation — we don’t often use negative margins for consecutive flowed boxes — but IE renders all the + borders around the second box in odd locations (and seems to omit some entirely), which is just wrong. There is a + demo on another page. For those people without IE/Win, some screenshots follow.
+ + +The demo should be rendered like this (screenshot from Firefox 0.8):
+ +
This seems pretty simple — how hard can it be to draw a few lines? Unfortunately, IE 6.0/Win doesn't like it at all. It draws parts of the + surrounding borders all over the place, even eliminating bits here and there:
+ +
The code used in the demo is as follows:
+<div class="demo-outer"> + <div class="demo-inner"> + <div class="demo1"> + This is a <div> with a border and a positive top margin. + </div> + <div class="demo2"> + This is a <div> with a border and a negative top margin. + </div> + <div class="demo1"> + This is a <div> with a border and a positive top margin. + </div> + <div class="demo2"> + This is a <div> with a border and a negative top margin. + </div> + </div> + <p>This is a <p> that does <strong>not</strong> have a border.</p> +</div>+
.demo-outer {
+ border: 3px dashed black;
+ padding: 8px;
+}
+.demo-inner {
+ border: 3px solid black;
+ padding: 0 8px 8px 8px;
+}
+.demo1 {
+ border: 1px solid black;
+ margin-top: 8px;
+}
+.demo2 {
+ border: 1px solid blue;
+ margin-top: -1px;
+}
+.demo-outer p {
+ margin-bottom: 0;
+}
+ These boxes are also enclosed by div#global-wrapper, which has a two-pixel border. If you check the screenshot,
+ you will notice a pair of two-pixel horizontal lines going across the page — these are from div#global-wrapper.
So, what can we do about this? We don’t want our documents to look quite like that. I have found a few ways to avoid the problem:
+In some cases, it is possible to avoid the problem outright. In this instance, I could achieve the intended behavior quite easily through other + means — I could just remove the border from the first box and get rid of the negative margin. This is clear and simple, and doesn’t trigger + other pesky bugs.
+Setting position: relative; on the offending box or its ancestors solves the problem — but only for that box and its
+ descendants. Any ancestors with borders will still be messed up. In other words, if I were to put
+ position: relative; on .demo-outer (the one with the dashed border), then IE would render it like this:
So, while the borders on div.demo-outer and its descendants are rendered correctly, the border on div#global-wrapper
+ is still rendered in the same manner as before. Putting position: relative; on div#global-wrapper would get rid of the problem
+ utterly, but doing so on the demo page has the unfortunate side-effect of making the page header
+ disappear for some reason (sigh).
In this case, I could also get rid of the negative margin and use relative positioning to move the second box up by one pixel. This is not a + general-case solution since it leaves an gap underneath the second box.
+
+ This IE6 bug may be fixed by applying the Zoom Fix.
+ The difficulty is identifying exactly which boxes need the hack,
+ and I think it might vary depending on the context. I experimented
+ with the demo,
+ and I found that the bug may be fixed in this case by applying the
+ Zoom Fix to .demo2 and .demo-inner
+ (i.e., the negatively margined boxes and the box with a three-pixel, solid,
+ black border). BTW, applying the Zoom Fix to different combinations of boxes produces
+ interesting results.
+
There's not much to conclude here — it’s a bug and it’s potentially annoying, but it can be avoided or fixed. This isn’t IE6's most + spectacular bug, but it serves as yet another warning of the many problems found in IE. Authors beware.
+
+Return to Explorer Exposed
+Next IE demo
+
+This is an IE/5.5/6/Win only bug, triggered by nesting one block element inside another, +and giving the following styles to the outer element: +
+
+ div {
+ border-left: 1px solid red;
+ padding-bottom: 1px;
+ }
+
++Note: All that is required is a left border and a bottom padding. +The size and units don't matter. +
+
+Then repeat this set at least twice. The second and following sets trigger the bug.
+
+Screenshot
+
+When triggered, the bug pushes the text in the inner element +(but not the element itself) to the left +an amount equal to twice the width of the left border. +The outer divs in the first group have 1px +borders; the second group have 10px borders (short red lines). Each group is in its own static div. +Notice that with each repetition the error is added to the previous errors! +
++What the heck is going on here? +
++The column to the left contains several live demos. Each grey box is absolutely positioned so that the Creep +will not creep from one demo to the next, gaining size as it goes. The first group shows the minimal case to trigger the Creep. +The first three sets in the second group have no nested inner div, and so +do not show the 'creep'. Notice once again that the second static div +picks up where the first leaves off. (if not, reload) Also, when the creeping text runs out of left +padding (in the absolutely positioned grey container box) the letters outside the container get cut off. +
+
+The third group down below in the next grey container box is in a seperate absolute div,
+due to bug interactions between demo groups, and displays
+some of the effects a hovered link background can have on the creep. The yellow backgrounds
+on the inner divs seem to prevent the partial loss of the red border, but otherwise don't help.
+
+Reload to reset the effects.
+
+The fourth group at the bottom shows that this effect is not confined to the +left side only, but can also occur on the right, given a right border trigger. +It can even happen on both sides at the same time! Strangely, links +do not seem to have any effect on the right creep, as with left creep. We can live with that. +In fact, if there is any right creep, it seems to prevent hovered link action on the bug entirely. +Notice how with 'right creep' the wrapping point is what creeps. Right aligned text will also be affected +the same way. +
++We believe it's the anonymous 'line boxes' (all inline content generates them) that are getting larger +under the influence of the bug. +To prove it, we placed bordered <span>s on the text lines. Interesting. We also right-aligned the +last five sets, which clearly shows that both ends of the invisible line boxes are getting extended. +
++See Eric Meyer's +Inline Model Document +for more on the line box topic. +
+
+Fixes:
+Just avoid the bug trigger combo entirely.
+
+Or you may give those outer nested divs a bottom border, which kills the bug.
+Only a bottom border will do! Giving the inner divs bottom borders only cuts the creep
+in half. The other borders do nothing. Really weird.
+
+Update - July 7th 2008 +The Creeping Text bug is one of those from the IE6 float bug suite that fall to the +Zoom Fix. +Just apply the Zoom Fix to the outer of the two nested elements +(via an extra class in this case) and the bug suffers a quiet demise. +Below is another live demo, identical to the first one on the left, other +than having the Zoom Fix applied to each outer div in each set. +
+ ++The murky veil surrounding the need for a box dimension to prevent so many IE bugs has been partially +lifted, due to the discovery of a heretofore +obscure page +in the massive Microsoft website. There is no real explaination of this "hasLayout" property, but now there is at least some +structure to the madness that has been inflicted on us by Microsoft, for what it's worth. Apparently a box needs "Layout" or all +heck can break loose, bug-wise. MS does not state that specifically, but their browser behaviors leave no doubt whatsoever. +
+ + ++This bug can appear in a number of guises. and frankly it's just too variable to go into details. +You'll have to work out whatever problems arise, and with what you now know, it shouldn't be too hard. +(pardon us while we creep away) +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 7, 2008
+Created May 2, 2002
+
I've provided advanced CSS consulting for
+Milo
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ ++A coder innocently places a left float into a container box, and uses a left margin on the float to push +it away from the left side of the container. Seems pretty simple, right? Well it is until it's viewed in +IE6. In that browser the left float margin has mysteriously been doubled in length! +
+ ++Thankfully, IE7 does not show this bug. +
+ ++The graphic below shows a simple div (tan box) containing a left-floated div (green box) . The float +has a left margin of "100px", producing a 100px gap between the left edge of the container box and +the left edge of the float box. So far so good. +
+ +
+
+
+.floatbox {
+ float: left;
+ width: 150px;
+ height: 150px;
+ margin: 5px 0 5px 100px;
+ /*This last value applies the 100px left margin */
+ }
+
+
++That exact same code when viewed in IE/Win is displayed in a slightly different way. +The graphic below shows what IE/Win does to the arrangement. +
+ +
+
+
+Why is this happening? Don't ask such silly questions! This is IE6, remember? Conformance with the specs +is only to be hoped for, not expected. The simple fact is it does happen. +
+ ++This bug only occurs when the float margin goes in the same direction as the float and is trapped +directly between the float and the inside edge of the container box. Any other left-margined floats +that are displayed in the same row won't show the doubled margin. Only those floats that begin a new row +will suffer from the bug. Also, the doubled margin displays mirror-symmetry, working the same +way to the right as it does to the left. + +
+ ++Up 'til now (Jan '04) this bug was thought to be unfixable, and was generally controlled by replacing the faulty +margin with a left padding on a non-visible float, along with a nested inner box to serve as the visible box within +the invisible float, or by hacking a one-half margin value for IE/win only. It works, but is clunky and messes up +the clean source code. Well that's all over now. +
+ ++Steve Clason has discovered a fix, +outlined in his Guest Demo, +that fixes both this doubled margin bug and a weird text indent bug as well. +It's a classic type of IE bug fix, using one property to cure a bug that affects an unrelated property. +
+ ++Dig this. Simply placing {display: inline;} on the float is all that is needed! Yup. Sounds too easy, don't it? +Nevertheless it's true that a mere display declaration of "inline" is enough to do the job. +
+ ++Those who are familiar with the specs on floats are aware that floats automatically become "block" elements, +no matter what they were before becoming floats. As Steve points out from the W3C: +
+ + + + + + + + ++9.7 Relationships between 'display', 'position', and 'float'+ +
+"...if 'float' has a value other than 'none', the box is floated and 'display' is set according to the table below..."
+The table gives this information:
+Specified value = inline ..leads to.. +Computed value = block
+
+That means that {display: inline;} on a float should be no different than using {display: block;} (or no display value at all), +and indeed all browsers follow this specification, including IE. But, this does somehow trigger IE to stop doubling the +float's margin. Thus, this fix can be applied straight, without any fussy hiding methods. +
+ ++In fact, you could just apply the Inline Fix to all floats if you like, since +there are no known side-effects. That way the bug can never gain traction regardless of any +margins you might or might not use. Of course if you do this, the bug can't happen and you +get no chance to play the big CSS guru to your boss... +
+ ++Below are two live demos using the same code as previously, first displaying the IE bug as usual, +and next the same demo with the "inline" fix applied to the float. +
+ +
+
+.floatbox {
+ float: left;
+ width: 150px;
+ height: 150px;
+ margin: 5px 0 5px 100px;
+ display: inline;
+ }
+
+
++You may notice that this bug fix idea is duplicated at the bottom of Steve's demo page. Y'see, at the beginning +of this episode Steve noticed the IE text indent bug and found the "inline" fix for it. +He brought it to our attention and since this was a cool bug with a fix, we then asked Steve to +write it up as a "Guest Demo" for PIE. During the course of preparing the demo, Steve discovered that the fix +also works to cure the Doubled Margin Bug, a much more common problem. Steve is a busy guy, so he asked +me to write this "in depth" demo page to cover the fix while explaining the bug itself more completely. +
+ ++We started our Guest Demo "program" primarily for encouraging others to focus their attentions on the various +CSS display difficulties (and to avoid so much hard work ourselves). +
+ ++Well! Apparently it's working accordin' to plan. Way to go, Steve! :-) +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: June 3, 2009
+Created January 19, 2004
+
I've provided advanced CSS consulting for
+Milo
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ ++This bug occurs only in IE6 and has been fixed in IE7 +
+ ++Internet Explorer 6 has a puzzling bug involving multiple floated elements; text characters +from the last of the floated elements are sometimes duplicated below the last float. This bug +is a real headbanger because there seems to be nothing triggering it. However, by now everyone +should know that IE needs no excuse to misbehave. +
+ ++The direct cause is nothing more than ordinary HTML comments, such as, +<!-- end left column -->, +sandwiched between floats that come in sequence. Apparently, the comments are hard for IE to +digest when they occupy those positions, resulting in a kind of "screen diarrhea". HTML +comments inside the floats do not cause the bug, nor do comments before or after the float +series. Only comments residing between floats cause the bug. +
+ ++The effect seen is that some of the last characters from the last floated element of the series +are repeated outside and below that floated element. The first sandwiched comment does nothing +unusual, but two comments cause the last two characters in that last float to repeat. Each +additional comment makes two more characters join the party. It doesn't matter which pair of +floats straddle the comments. In fact the two triggering comments may follow +different floats as long as they have floats both before and after them. +
+ +
+Second float
+
+
+In IE6 some of this text is replicated in a "mystery block element" that starts directly below
+the float. This light brown float has a 2px bottom margin which also duplicates into the mystery
+element, getting added to the bottom of the text if it is wrapped in a span as it has been
+here.
+
+Test link
+
+
+
+
+This live demo's construction starts with a 250px wide container +(green border), holding first a 200px wide float (gray), and a second (light brown) float, which is +given a width of 250px, the same as the container's width. Inside that second float is a red bordered +paragraph containing spanned text, and an image just for fun. The span is not required for the bug to +occur, but is used here to help illustrate the bug. Finally there is a simple "cleared" block element (green). +Additionally, there is a 2px bottom margin on the lower float to push the duplicated text down and make +the demo slightly less confusing. +
+ ++If you look at the source of this page, you will see 50 ordinary HTML comments in between the +two floats. The first one is "free," but each of the remaining comments will trigger the replication +of two characters from the last float into the area just below it. The bug considers the image to be +worth two characters when duplication is occuring. The length of the text in the comment does not +matter. We know that no one is likely to be putting 50 comments in between floats, but in this case, +they sure make the demo more dramatic! +
+ ++Below is a simplified version of the code used to make this live demo: +
+ ++<div class="demobox" > + +<div class="firstfloat">First float</div> + +<!-- comment --> <!-- comment --> <!-- comment --> +<!-- comment --> <!-- comment --> <!-- comment --> + etc, etc, etc... (50 in all) + +<div class="secondfloat"> +<p> +Second float + +<span> + +In IE6 some of this text is replicated in a +"mystery block element" that starts directly +below the float. This tan colored float has a +2px bottom margin which also duplicates into +the mystery element, getting added to the +bottom of the text if it is wrapped in a span, +as it has been here. + +<a href="#">Test link</a> +<img src="images/pinecone3.jpg" alt="" /> + +</span> +</p> +</div> <!-- End of second float --> + +<div style="clear: both;">Cleared element</div> + +</div> <!-- End of .demobox --> ++ +
+Important: These extra comments trigger the bug only +when the final float fills the container to the right edge, or to within less than 3px away from it. +This is because IE6/win seems to have a weird 3px "bumper" margin on the right side of that last left +float. Since the float in this demo is exactly as wide as the container, the bumper has no empty space +to occupy, and apparently it is this that completes the bug trigger. The effect also shows +symmetry, working the same way in a mirror version of this coding. +
+ ++Note that if the floats were horizontally next to each other and their widths when added together +equaled the container width, the bug would still be triggered. Also remember that when many floats are +involved, it doesn't matter which floats the comments fall between, as long as they are between any +floats in the set. The comment bug triggers accumulate! +
+ ++Update! July 5, 2004 +— It turns out that this duplicating characters bug can be triggered +by other things than just HTML comments. +Phil Baines points out that any +elements given the style {display: none} will also induce the bug. In fact, +even hidden inputs can do it, and presumably any other elements that don't actually +display for some reason. Apparently the act of hiding a source element is the +critical trigger for this bug. +
+ ++Nice catch, Phil! +
+ ++Notice what happens when the duplicated link is hovered, causing a background change. +Both the real link and its clone show the hover effect, and hovering makes some of the +duplicate text show the padding from the donor float's paragraph! Most kinds of hover +changes on the link will do this, but not all. Every IE bug that involves hover changes +seem to be triggered by the same style alterations. Changing the font doesn't do it, +but applying a background on hover does. +
+ ++Check out what happens to the image! Oh dear. Say, what about the red border showing up around the +duplicate text? Is the paragraph itself being cloned as well? Are you getting dizzy yet? +
+ ++Another thing to notice is the text in the green clearing element. The text actually says +"Cleared element", but it is partly lost on the left side! The length of missing text is +exactly the same as the width of the left padding on the donor float paragraph. Arrrgh! You +may not want to hear this, but upon hovering either link, the bottom margin on the float is +replicated below the cleared element... +
+ ++Okay, we'll stop now. +
+ ++One easy fix is to put a -3px right margin on the last left float. The +opposite can be done for layouts with right floats. This seems to be a harmless fix that works +every time. Another fix is to give the container element 3px of extra width, so that it is 3px +larger than the last float. Sometimes applying +hasLayout +on the cleared element will stop the text +duplication, but not the "Reverse padding bug" in the cleared element. +
+ ++Or, you could just remove the bug triggering comments, but that would be cheating, wouldn't it? +
+ ++Update! April 25, 2006 One of our +more deviously-minded readers, +Victor Welling, +has discovered that +Conditional Comments +may be used in place of normal HTML comments without triggering this bug! +It works because CC's allow the use of the naught sign (!), so you can specifically +tell IE/Win to ignore the CC, while other user agents simply treat the CC as a +normal comment as usual. Here's an example: +
+ ++<!--[if !IE]>Put your commentary in here...<![endif]--> +
+ ++The critical part is that "..if !IE.." bit. That tells IE to not look into the +CC, as it would otherwise do without the naught sign. +
+ ++Okay, this is very weird. Presumably IE sees elements that it is supposed to hide +such as hidden inputs and normal comments, and when they appear in certain locations +it somehow triggers the duplication bug. And this CC does make IE hide what is +inside, just like all other browsers. So what makes IE treat this comment differently than +normal comments? Don't ask such silly questions! It's IE, remember? Oh +well, as long as it validates and gets the job done, right? +
+ ++This method allows Victor (and you too) the ability of retaining all buggy comments +right where they are, with no compromise and just a bit more code. Thanks Victor! +
+ ++Update! September 7, 2006 +Brett Merkey +points out that the +Doubled Float Margin Bug Fix +may be used to stop this duplicate characters bug! Who knew? As always, that fix +is used on floats and does not affect floats, according to the W3C. However, just +like the doubling bug it fixes this duplicating bug when it is applied to the float +that comes before the triggering comments. Thanks Brett! +
+ ++The fix itself is simple, just add display: inline; to the +float that preceeds the comments, or you can just globally apply it to all +floats. So far there have been no apparent side effects when doing this. If all +floats are given the fix at all times, several known IE bugs will be prevented while +no other known effects occur. If you do this and ever notice any odd side-effects, +please contact us, okay? +
+ ++This problem can appear in different ways, but it usually involves text duplicated out of the +last float in a float series, and two or more HTML comments between the float elements. +
+ ++For masochists, check out yet another version +of the duplication effect, discovered by Jennifer Niederst. Is there no end...? +
+ + + + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: May 12, 2010
+Created February 18, 2004
+
+Below is a div box with margins (10% on left and 40% on right) and 2px black borders. Inside are a number of left floated +divs dimensioned as 50px squares. Following the floats is a "cleared" div to make +the container div enclose the floats +
++In Opera and Mozilla it looks fine, but check it out in IE/win for a suprise. +
++In Explorer for Windows there are two display errors. One, the container is only containing +the last line of floats , and the floats are also running off to the right, all the way to the +right screen edge! Take it from me, folks, that is not kosher. +
+ ++Just to pour salt in the wound, this bug also causes a horizontal scrollbar at many screen sizes. +Try playing with the window width and see how when the last float line protrudes from the container, +the length of the protrusion translates into the size of the scrollbar. Interesting. +
+ +
+Screenshot in IE6
+Screenshot in IE7
+
+IE7 fixed most of the IE float bugs, but not this ugly customer! MS specifically stated that it would not +be fixed due to some kind of "technical reasons." Must be pretty ba-ad... +
+ ++This CSS train wreck in IE/win is due to the lack of +hasLayout +on the black bordered container (div.floatholder). On many sites div.floatholder +would have a stated width, and that too will trigger hasLayout so the author never +sees this bug. Widths are not always desirable however, so it's a good thing we have the +Zoom Fix +To use instead. +
+ ++Below is the same demo as above, except for the addition of the +Zoom Fix to div.floatholder: +
+ ++The Zoom Fix can be used to correct a number of IE/win float bugs besides this one, +mostly in IE6. With IE7, MS has managed to supress most float bugs and won't +need the Zoom Fix, but it won't be harmed either, so no worries there. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 7, 2008
+Created December 3, 2003
+
+A Guest Demo, courtesy of BlissfulWebDesign +
+ ++It's an unfortunate fact that Internet Explorer 6 will always +incorrectly expand any dimensionally restricted +block element so that oversize content is unable to overflow, as the specs +require that content to do. IE7 has fixed this issue +and does not wrongly expand boxes such boxes, instead allowing the overflow property +to operate as intended by the W3C. +
+ ++I will be comparing IE6's +way with the correct behavior as seen in Firefox. +The W3C says a rigidly sized block box should allow oversize +content to protrude or overflow beyond the edges of the sized box. +
+ ++There is no real "fix" for IE6's incorrect behavior, except to work around or avoid it. +Several possible workarounds will be detailed as I discuss the issue. +
+ +Have you ever tried to do a two-column float layout like in the graphic below?
+
And after some content changes, it turns out like this when viewed in IE6?
+
+ Screen shot in IE6
It's a "float drop", and it's caused by having oversized content in a +fixed-width floated div that must fit into a particular spot in the layout. +In this case, the oversized content is the URL string in the green float.
+To understand what is happening, first consider our HTML structure:
+<div id="wrap">
+ <div id="masthead">My header</div>
+
+ <div id="leftnav">Typical Left Nav</div>
+ <div id="main">My main text here...</div>
+ <div id="footer">My footer</div>
+</div>
This is a common two-column structure, where we have a +<div id="masthead"> (colored blue), followed by +two floated columns: <div id="leftnav"> +(colored green) and <div id="main"> +(colored red). The two columns are made to sit side-by-side because they +both get the CSS float: left;. +
+ +
+ #masthead {background-color: #006699;}
+ #leftnav {background-color: #99CC00;
+ float: left;
+ width: 50px; }
+ #main { background-color: #D54500;
+
+ float: left;
+ width: 340px; }
+ #footer {
+ background-color: #CCCCCC;
+ clear: both;}
Finally we have the <div id="footer"> + +(colored dark gray) where we clear the float — forcing the +footer to clear itself to a position below the earlier floated columns.
+ +All the page elements are enclosed in a wrapper div: +<div id="wrap">. This wrapper is set to a width +of 390px, enforcing a rigid pixel with on the layout.
+ +#wrap {
+
+ width: 390px;
+}
+
+
We want our green left column to take up exactly 50px of the +available wrapper width, and the main column will occupy the remaining +340px, so we have specifically set these widths +in the CSS:
+#leftnav {background-color: #99CC00;
+ float: left;
+
+ width: 50px; }
+#main { background-color: #D54500;
+ float: left;
+
+ width: 340px; }
+
And if you look at the code in both Firefox and IE6, things looks as expected.
+ + +
+ Screen shot in Firefox and IE6
+So far so good, but real web pages are messy, and sometimes they receive content +that the designer did not test in advance. When that happens, suprising things can +happen. +
+ +One common cause of box expansion in IE6 is when you have oversized content +such as a long "unbreakable" URL, with no spaces where word wrapping may take place. +What if our <div id="leftnav"> consists of this content:
+ +<div id="leftnav">
+ http://AnUnbreakableURL.com
+ Left Nav
+ </div>
+
view live code
+
+ View live demo in IE6 to see incorrect behavior.
+ View in Firefox for correct behavior.
The graphic below shows what you will see if you view it in IE6:
+ +
+ Screen shot in IE
Note how IE6 has expanded the width of div#leftnav +(green box) to accommodate the unbreakable URL string. div#leftnav + +is no longer 50px wide, as specified by its given CSS width value. After this expansion, +div#main (red box) does not have room to fit +inside our fixed-width layout next to div#leftnav, +and is forced to go below. Since we did not specify an +overflow +property value for div#leftnav, its overflow property +value defaults to visible. The expansion of +div#leftnav is a clear violation of the +W3C specification + +for the overflow property, which covers the default value +"visible" this way: +
+ ++Visible (the default or "initial" value for the +overflow property +)+ +
+"This value indicates that content is not clipped, i.e.,
+ +it may be rendered outside the block box". +
+Note that it does not say that the box should be enlarged when content is too big to fit. +IE6 should respect the assigned width, and should not expand the div. +The URL should be allowed to overflow outside the green box.
+ ++Notice how the text "Left" and "Nav" are on separate lines? Why don't they just +appear on one single line, since the green box is clearly wide enough to hold them? +That is because IE6 seems to not know when it has expanded a box! +
+ +I will demonstrate with an oversized image followed by a paragraph, both inside +the green #leftnav box:
+ + <div id="masthead">My header</div>
+<div id="leftnav">
+ <img src="masthead.jpg" width="267" height="50">
+
+ <p>An image followed by a paragraph of text</p>
+</div>
+<div id="main">My main text here. ... </div>
+<div id="footer">My footer</div>
+ Screen shot in IE6
The paragraph following the image is colored a darker shade of green so that +you can see what is going on.
+ +Note how the image has expanded the lighter green #leftnav div in IE6. +However, nested block elements (such as our paragraph) do not expand to fill the +newly available area in the expanded container div! You would think that the dark green +paragraph would fill the entire width of its light green container as usual, but it +doesn't. Apparently the paragraph does not "know" that the light green container +has been expanded by the large image in the same container, so the paragraph +below stays the same width and doesn't expand to fill the available space. +
+ ++This effect can cause coders to think the problem is in the paragraph, when really +it's the image and container that are causing the IE6 problem. Suspicious right +side spaces like this should be a warning that expansion has occured somewhere. +
+ +Now let's look at that "long URL" layout code in Firefox.
+ +view live code
+ View in Firefox (shown below) to see correct behavior. View in IE6 for incorrect behavior.
+ Screen shot in Firefox
Firefox respects the specified width on the paragraph, but what has happened +to the text? Is it clipped, +in violation of the specs? Not to worry, the text actually does overflow correctly. +We just cannot see it because the red background on the adjacent red float is covering +it up. Let's remove the background from div#main and see if it's +hiding back there.
+#main {
+ float: left;
+ width: 340px;
+ /* background removed */
+}
+ Screen shot in Firefox showing correct overflow
Clearly Firefox does exactly what the specification requires, letting the long +URL go beyond the edge of the surrounding green box. +This does cause that URL to go behind the text in the red box, but at least the +floated layout structure is not damaged. Float dropping in such cases is a lot +more harmful to a web page than text overlapping, in the opinion of most people.
+ ++ Let's examine some workarounds that might keep IE6 from wrecking our layout.
+ +Try adding the word-wrap property with the value break-word.
+#leftnav {
+ background-color: #99CC00;
+
+ float: left;
+ width: 50px;
+
+ word-wrap: break-word;
+}
+ Screen shot in IE6
Although this has no effect on Firefox, it does force IE6 to break up +"unbreakable" text so that it no longer expands the width of the box +containing the text.
+ ++Be aware that word-wrap is a proprietary Microsoft CSS rule. +It is not part of the W3C specification at this time, and will invalidate the +page unless that code is hidden inside a +Conditional Comment, +like this: +
+ +
+
+<!--[if IE]>
+ <style type="text/css">
+ body {word-wrap: break-word;}
+ </style>
+<![endif]-->
+
+That style block is contained in the CC, which can go in the head section of the web +page. Only IE6 will look inside the CC, while all other browsers and the W3C validator see +only an ordinary HTML comment, and ignore everything inside. It's not a pure solution, but it does +work safely on potientially damaging long text strings, and does validate too. +Notice that this rule inherits to +all page elements from the body element, providing page-wide protection. +
+ +According to the spec, +another possible value for the overflow property is hidden. +Let's see what happens when we apply it. +
+ +#leftnav {
+ background-color: #99CC00;
+ float: left;
+
+ width: 50px;
+ overflow: hidden;
+}
+ Screen shot in Firefox and IE6
The overflowed text is hidden, or clipped. By doing so, IE6 no longer "needs" +to expand the column width. That's good, but some content can never be seen now, and some +browsers have been known to show odd bugs when overflow is changed from the +default value "visible" for complex CSS layouts, so this fix is less than ideal.
+ ++Another drawback of the "hidden" method is that IE6 demands that the boxes +having this overflow fix must have widths applied to them. So for example, +consider a nested paragraph in one of those floated columns above. The floats do have +widths but the nested paragraph will normally be left widthless. If the +overflow: hidden; trick is used on the paragraph, it will +fail in IE6. But, if it's used on the surrounding float it will then work properly, +because the element with the overflow rule also has a width applied to it. +
+ +Keep in mind that oversized content does not only mean very long URLs. You might +also have an image that is too big for the width allowed for it in the container. +Below is a demo graphic +showing an image that's just a bit too wide to let the red box fit next to it:
+ +
Or a user might enlarge the browser text size, making a normal word too wide to +fit, just like the long URL:
+ +
+Word-wrap only works on text, not on images, but both these +problems can be handled by overflow: hidden as you can see here.
+ +
+So overflow: hidden can protect against oversize text, images, +and even oversize tables, but may clip off some content. Using word-wrap +preserves the text but doesn't affect oversize images or tables. As always, web +design means making hard choices. +
+ +Just as IE6 can incorrectly expand an element's width, it can also incorrectly expand an element's height. +Take the following example where we have <div id="cornerbox"> +inside <div id="masthead">.
+ +view live code + ++HTML:
+ +
+<div id="masthead">
+ <div id="cornerbox">
+ Lorem ipsum dolor ...
+ </div>
+</div>
+CSS:
+ +#cornerbox {
+ width: 150px;
+ height: 50px;
+ background-color: #99CC00;
+}
We now specify the height of the green div#cornerbox to be 50px. +Since our text is too tall to be accomodated within this height, the text should +overflow the green box. The correct behavior looks like the following graphic, +as shown in Firefox. Similarly, all other modern non-IE6 browsers such as + +Opera and Safari will behave in the same manner.
+ +
However, when we take a look at this same code in IE6, it looks like the following:
+ +
+IE6 has incorrectly expanded the height of the green div#cornerbox to accommodate +the excess text, and that in turn has expanded the height of the blue div#masthead! +Neither div remains at the 50px height specified on #cornerbox after IE6 gets +a look at that tall text. Both expansions are incorrect behavior, and are violations of the +overflow specification.
+ ++Unlike IE6, the IE/mac browser will not +expand the green corner div (good), but it will for +some reason incorrectly expand the blue masthead anyway! (not good) +
+ ++This kind of inconsistency can play havoc with height controlled layouts. +Suppose that you have a background image attached to your masthead and the image +is only 50px high. After expansion you won't have enough image to fill the expanded +masthead.
+ +
Non-IE6 browsers will overlap some content, yes, but having two +different apparent problems is very hard on newbies when trying to debug a design +across browsers. +
+ +
+view live code
+
+View in IE6 (shown above) to see incorrect behavior. View in Firefox for correct behavior.
+
HTML:
+<div id="masthead">
+
+ <div id="cornerbox">
+ Lorem ipsum dolor ...
+
+ </div>
+</div>
+
+<div id="bodytext">
+ This is the main content of my web page.
+
+</div>
CSS:
+body { margin: 0; padding: 0; }
+
+#masthead {
+ background-color: #006699;
+
+ background-image: url(masthead.jpg);
+ background-position: 150px 0px;
+
+ background-repeat: no-repeat;
+
+ }
+ #cornerbox {
+
+ width: 150px;
+ height: 50px;
+ background-color: #99CC00;
+ }
Using word-wrap: break-word won't help us here. However, we +can set the overflow property to hidden to put our +layout back in place.
+ +#cornerbox {
+ width: 150px;
+
+ height: 50px;
+ background-color: #99CC00;
+ overflow: hidden;
+}
+
+ Screen shot in IE6 and Firefox
Now IE6 no longer expands the element. And best of all, it behaves +consistently between both IE6 and Firefox. +
+ ++Clearly there are options available, but the best and most common option employed +for web pages is to not use height at all. Letting height be the default auto +will let content determine the height and avoid the IE box expansion problem. Unless +the content's displayed height can be rigidly controlled, applying a height to the container +box will only cause trouble. +
+ +In summary, both word-wrap: break-word and +overflow: hidden are possible workarounds that will make +Internet Explorer respect our specified dimensions. The method of +overflow: hidden works in more situations -- such as oversized +images and vertical expansions, but at the cost of possibly clipped content. +The word-wrap: break-word; method won't clip content, +but is useless on anything but text. Now that you have seen the effects of both, +their possible employment will depend on specific situations and preferences.
+ +Article courtesy of artcoder at +BlissfulWebDesign with big help from + Big John at + PositionIsEverything.net
+ ++artcoder says: "I call myself artcoder because I like turning +art into code. Trained +with a master's degree in computer science, I started out my career as a +programmer working for large corporations, small companies, and +dot-com's. After years of manipulating lines and lines of abstract +code, I found beauty in art and web design. Re-tooling myself in the +skills of Photoshop, Fireworks, XHTML, CSS, and color theory, I make my +attempts at web design. Now I would like to say that I lead a balanced +life with one foot in the world of art and another foot in the world of +code." +
+ + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 7, 2008
+Created June 25, 2007
+
+Return to Explorer Exposed
+Next IE demo
+
+This bug was fixed in IE6, but the demo is being kept online for historical reasons. +
+ ++So you have a block element, and another block element +inside it. The inner element has a bit of text, and has been given position: relative +plus letter-spacing: xxx. Then you view it in IE5.5/win. What's this? +The first letter of the text is nowhere to be seen! Interestingly, there is a space +left open for it. This peculiar bug is usually seen in headers, for reasons that will become obvious. +
+ ++In the demo above, the outer div has a grey background, +and the inner div has a red border. +Notice that the text string seems to be in the proper place. It's the inner div itself that appears +contracted, by the width of one letter. I have found that when content is somehow displaced +outside of a 'relative' container (in IE) it's usually invisible, as in this case. +
++Fixes: It turns out that this is a rather sickly bug, easily squashed by design +or happenstance. One way is to have a top border, not on the inner div like you would think, +(the one with positioning and letter-spacing), but rather on the outer div. (?) The following test has a top +border (purple) on the outer div. +
+ ++The next fix is exactly the same except that instead of a top border, this time it's a +top padding. +Either padding or borders on any other side, or on the inner div, do not fix the bug. +
+ ++Now we move on to 'width'. If you give the inner red bordered div a width (or a 'height'), +the missing letter is indeed visible. (width="60%") +
++The width-fix mentioned above is now understood (July 2008) to be triggering something called +hasLayout. +Many IE bugs are fixed by applying hasLayout via a +Zoom Fix to certain critical boxes, +in this case the inner red box. +
++ But now look a the next demo. The letters are too far apart! Or.. are they...? +
+ ++Comparison with Opera and Mozilla reveals that the test above is in fact the only one +of all the tests that +gets it right, when viewed in IE5.5/6. The other tests show about half of the called-for space. +In fact, if the unit for 'letter-spacing' is given in pixels rather than EMs, even this test will show the +reduced spacing. +
++Yes folks, two IE bugs for the price of one! Gettem while they're hot. +
++BTW, Opera/Mozilla/Win and IE5.2.1/OSX all display all the test demos properly. +
++The next test has the same width, but applied to the outer grey div instead. +
+ ++It turns out that the spacing bug is dependent on which element is given the 'font-size'. +In other words, if the big 2.5em font-size is on the 'body' element, all the tests would +have the correct spacing. So if the bug fixing width is on the outer element but the enlarged +font-size is on the inner element (like the above demo), the spacing bug will not be fixed. Confused yet? +
+ ++Finally, the most likely-to-occur bug killer of all, a wrapped text line. +This is why the first letter bug is restricted to headers and the like. +
+ ++As an after-thought I made the inner div into a span. +
+ ++Amazing! The inner span is still pushed over a letter width as in the first test demo, +but now the text has been shoved +over to match. There's something really strange going on here... +
+
+Screenshots:
+IE5,
+IE5.5,
+IE6
+
+Moz, Op6 and IE5.2/Mac (displays are similar)
+
+Thanks +to Edwardson Tan + for the screenshots and the motivation, +Peter Bowyer for finding the bug, and its +'letter-spacing' trigger, and Stephanie Sullivan +for the Mac info, all members of the +css-discuss list. +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 7, 2008
+Created September 20, 2002
+
+Return to Explorer Exposed
+Return to Guest Demos
+Next Explorer demo
+
+ Internet Explorer's problems rendering floats have been thoroughly analyzed, + thanks in large part to Big John's efforts characterizing and publicizing + them. We do still stumble onto undocumented oddities, though, and + this demo presents one that hasn't been isolated yet—or we + haven't heard about it if it has—and as a delightful by-product, + suggests a simpler work-around (or maybe a hack) than we have been + using for + a bothersome rendering issue that's been around a while. +
++ The bug demonstrated here causes in-line elements (images, text) + adjacent to a floated div to appear to be indented from their expected + location. The indentation is caused by IE6's weird handling + of margins on floated elements. + The happy by-product is a cleaner way to defeat the + doubled-margin bug.
++ (Note: If you're looking at this in some browser other than Internet Explorer 6 on Windows, + you're likely to wonder what the heck I'm talking about. All other browsers I have tested + render the examples below properly and ignore the work-arounds—you have to use + IE6 to really see what's going on, but I've included screenshots in case you just can't + bring yourself to open IE) +
++ Most of the CSS sits in a style block in the header of this page, but + where I alter the styles to demonstrate the bug I've put the changes + in-line so they'll be easy to find, and there are obvious comments + in the + source + at the beginning of each example to make it even easier. +
++ The relevant style declarations in the header are: +
+
+body{
+ font-size: 100%;
+ background-color: #ccddcc;
+ color: #000;
+ font-family: arial, helvetica, geneva, sans-serif;
+ margin: 0 15%;
+}
+
+.box{
+ clear: both;
+ width: 80%;
+ background: #fff url(images/75pxWide.png) no-repeat;
+ color: #000;
+ padding: 1em;
+ border: 2px solid #EFCE8C;
+}
+
+.sidebar{
+ float: right;
+ width: 15em;
+ font-size: 80%;
+ border: 2px dotted #000;
+ padding: 1em;
+ margin-left: 75px;
+ background-color: #f8eece;
+ color: #000;
+}
+
+ + The in-line styles used in each demo are documented below those demos. +
++ Each example uses the same basic mark-up: +
++<div class="box"> + <div class="sidebar"> a floated box with some content + </div> + some content +</div> ++
+ Changes in mark-up will also be documented when they're used. +
++ Not all of us can visualize a 75 pixel width, or know when we're looking at one, + so to help out I've included a blue, 75-pixel-wide image in all of the examples. + It's easy to spot because it's blue and says "This is 75 px wide." In all cases this + image is applied as a background to the div holding the example and so takes + up no space. It's there just to make it easier to see when a false margin is being + applied. +
++ First a review—the infamous IE6 margin-doubling bug could be one of the + most pervasive problems ever to come out of the IE browser. + When an element with a left-margin is floated left, IE6 will double the + left margin of the floated element. (See a full + treatment of the double-margin bug.) Here's a simple example: +
+ ++ Mark-up looks like this— +
++<div class="box"> + <div class="sidebar" style="float: left">content + </div> + content +</div> ++
+ ...and here's a screen shot (IE6/WinXP):
+ 
+
+ The standard work around for the bug is to wrap an additional div around the floated div, + apply the float to the wrapper and remove the float on the interior div, like so— +
++<div class="box"> + <div style="float: left> + <div class="sidebar" style="float: none">content + </div> + </div> + content +</div> ++
+ Now the floated element has no margin, and the element with the margin isn't floated, with this result—
+
+ Screen Shot:
+ 
+
+ Which is what we would see without the wrapper div except for the bug, and what we do see in other browsers. +
++ That double-margin effect is plenty peculiar itself, but under some other conditions IE6 + gets even weirder, applying the margin of a floated element, in full, at two different places + on the page. Look at the following example: +
+ +
+ Screen shot:
+ 
+
+ You can see that he first line of the text is indented 75 pixels right. That 75 pixels + comes from the 75 pixel left-margin of the sidebar div. I'll prove it to you. +
++ If I change the mark-up to this— +
++<div class="box"> + <div class="sidebar" style="margin-left: 0">content + </div> + content +</div> ++
+ —removing the offending 75 pixel margin, IE delivers this: +
+ +
+ Screen shot:
+ 
+
+ Miraculous! No indent. And just to see if the bug is symmetrical, we can swap the direction of the floats: +
++<div class="box" style="background-position: top right"> + <div class="sidebar" style="float: left; margin-right: 75px; + margin-left: 0;">content + </div> + content +</div> ++ +
+ Screen shot:
+ 
+
+ And one more time, with a different kind of in-line element getting the fake indent, in this case a string of images: +
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Example 6
+
+
+ Screen shot:
+ 
+
+ Well, there's nothing scientific going on here—this is a simple case of an IE6 rendering error. + If you look at this page in a standards-compliant browser (yes, I know they're recommendations, + not standards) none of the margins are borked—not on the examples where IE6 messes them up, + and not on the examples where work-arounds are applied. +
+It's important to notice that IE6 applies this "indentation" only to + in-line elements. If the text in the examples were surrounded by <p> + tags, or <div> tags, which is much more common than having bare text, + the IE bug would not show up.
++ The work around for this bug is preposterously simple, counter-intuitive and utterly in + violation of the W3C recommendations—simply change the style of the + floated element to "display: inline" and the problem disappears. +
++ So do this— +
++<div class="box"> + <div class="sidebar" style="display: inline">content + </div> + content +</div> ++
+ and get this— +
+ +
+ Screen shot:
+ 
+
+ and this— +
+ +
+ Screen shot:
+ 
+
+ and this— +
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Example 9
+
+
+ Screen shot:
+ 
+
+ The W3C specifications are very clear on the subject of the display function relative to floats: +
++ 9.5.1 Positioning the float: the 'float' property +
++ "This property specifies whether a box should float to the left, right, or not at all. + It may be set for elements that generate boxes that are not absolutely positioned. + The values of this property have the following meanings: +
++ According to the highlighted section of the spec, changing the display type, unless you + change it to "none", should have no effect. Lucky for us IE ignored this part of the spec, + allowing a simple, relatively harmless fix for their rendering bug. +
++ Changing the display property of the floated element to display: inline + is a clean, simple way to fix fake indentation, but as an added treat, the + same fix works for the double margin bug. +
++ Here's a copy of Example 1 above demonstrating the double-margin bug. +
+ +
+ Screen shot:
+
+
+ And now the same example, except with the float styled "display: inline". +
+
+ Screen shot:
+ 
+
+<div class="box"> + <div class="sidebar" style="float: left; display: inline">content + </div> + content +</div> ++
+ And there you have it! With a little CSS declaration and without changing the + mark-up at all, we can now fix on of the most common IE6 rendering bug around. +
+ +
+I'd like to thank Big John for generously sharing his expertise while I constructed this demo and for his
+encouragement to see it through.
+Steve Clason
+www.topdogstrategy.com
+Last updated July 7th, 2008
+
+Okay, here is a simple test concerning how static elements interact with floats. According to the W3C specifications, +when a floated element is directly followed by a static element (one that is normally flowed), then first, +the float will be displayed against the left edge of the containing element (in this case the 'body' element), +and then the static element will also display against that same edge, and at the same vertical height as +the float. +
++The float should overlay the static element, unless the static element has a left margin that +moves it out to the right, and out from behind the float. The static element might also be 'cleared' +(clear:left or clear:both), which would put it below the level of the float. +
++The green bordered box (div#left) is floated left in the 'body', and is followed by div#static (purple box). +If div#static had no width, then all modern browsers would display correctly, with the purple box +overlaid by the green bordered box. +
++But, because div#static is width defined, browser variance is fully evident. +That 'width' declaration makes Internet Explorer put div#static +alongside the float as tho the float were part of the left body edge. The latest Win versions +of Firefox, Opera, Safari and all the +Mac-based browsers other than IE5/Mac do it according to the specs, with both boxes +firmly pinned to the left body edge. +
++Making sophisticated use of float layouts sometimes requires stating the 'widths' on some boxes, but +doing so to a static box that follows a float makes IE display differently than any browser that dares +to adhere to the standards. So differently in fact, as to make the situation impossible to ignore. +
++A big problem with this issue occurs when one attempts to use the +Zoom Fix +on that static float-following box. This is because just like width, the Zoom Fix triggers +hasLayout +on a box, so you get the same improper float model in IE. But if there are float bugs going on +inside the box you will have to make some kind of compromise or maybe redesign the layout entirely +to get satisfactory results. +
++So the choice is to code only for IE, knowing the minority browsers will break, or avoid using any of the +hasLayout triggering properties, putting many types of layouts 'off limits'. Some choice. +
++The demo you see here is fully pixel defined, but usually a layout has the widths in percentages, at least for the +elements following the float. When div#static is given a percentage width, IE5.5 looks at the available horizontal space +alongside the float and says "That is now defined as 100% of the width". So if div#static gets 'width: 50%;', that div is +half as wide as the space next to the float and starts next to the float as mentioned. +
++However, IE6 is different. Yes IE6 does start the div next to the float, but it does not take the float +into consideration when figuring the width of div#static. Rather it uses the entire container as the 100% width +refrence, just as the specs require. Yet it does start the div alongside the float! So the problem is only +half-fixed in IE6, creating one more headache for us poor coders. +
++What does this mean? Well, if the div is given a width of 100%, it is as wide as the body element, and being placed +next to the float it forces the right edge of the body element sideways by the width of the float, causing a scrollbar. +But only in IE6! As if this mess weren't already bad enough. Oy. +
+ ++It was hoped that IE7 would eliminate the bad old IE float model, but instead MS just +complicated the issue. Check out this +IE7 article for more information on the subject, oy... +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 7, 2008
+Created January 28, 2003
+
The Guillotine is a bug that chops off the bottom part of floated elements when certain links are hovered over.
+ +The effect is very much similar to that of the +IE/Win Unscrollable Content Bug, +but this one is easier to setup with less content and more dynamic in its, er, execution.
+ +Here's a quick example to illustrate what we are talking about.
+ + + +IE Users: Let's hover over those links to the right to witness some really interesting phenomena.
+This is a floated div. You may use this link to fix things once you've +done the butchering.
+ +The content in the bottom of the float, such as this paragraph, is vulnerable to the Guillotine.
++Update July 2007: IE7 is showing a new version of this supposedly fixed bug, demoed at +css-class.com. +
+ +Now that we've got a glimpse of the Guillotine, let's examine what we should have at hand to set one up.
+ +The main ingredients for a "properly working" Guillotine are:
+ +The non-floated content may or may not be wrapped in a block element, such as p or div.
+ +The a:hover style rules of the Guillotine invoking links could be anything which changes, among other things:
+ ++<!-- Example Layout for a Guillotine Invoking Situation --> + +<div id="container"> + <div id="floated"> + This is the floated content. + It is vulnerable to the Guillotine. + </div> + + This is the non floated content inside the container. + Guillotine invoking links should be in this content. +</div> ++ +
+/* Example Style Rules for a Guillotine Invoking Link */
+
+a:hover {
+
+ background: none #FFFFCC scroll repeat 0% 0%;
+
+ /* and/or */
+
+ padding: 5px;
+
+ /* and/or */
+
+ text-style: italic;
+
+ /* and/or */
+
+ border-bottom: #0000FF 1px solid;
+
+}
+
+
+An exception is changing the text colour, which does not invoke the bug.
+ +As you can see, it's pretty easy to find yourself trapped in a Guillotine. Armed with the above prerequisites, +let's move on to the scary stuff: Guillotine in action.
+ +If the container has a dimension specified, IE will automatically enclose all floats inside the container. +This is in gross violation of the specs, but as we have come to know rather painfully, it is something to be +expected from this browser. Thus, in IE, the container will stretch down to contain a float that has exceeded +the height of non-floated content.
+ +Live example | IE6 Screenshot
+ + + +This is a float. It is 200px wide, has a blue border and yellow background. It should not be contained in the container div.
+Because the container is assigned a width, IE encloses the float in the container.
+This is the container. It is 400px wide, has a red border and grey background.
+(If you look closely enough, you'll see that the + +IE 3px text jog +is also in action. Let's leave that to its own demo and focus on the current nuisance.)
+ +A Guillotine invoking link can switch off this auto-enclosing behaviour. When such a link is given a hover, +the bottom border of the container jumps up to enclose only the non-floated content, which is the correct way +to layout the elements. However, when the container shrinks, the part of the floated box which falls below the +non-floated content gets hidden, and only the part that is appearing above the bottom border of the container +remains visible.
+ +
In the live demo which follows, notice how the links in the first two lines in the non-floated content do not +invoke the bug, and actually reset the Guillotine when given a hover. All other links in the non-floated content +will invoke the bug.
+ +Any link in the floated div will also reset the Guillotine.
+ +Live Example | + +Screenshot Before Execution | +Screenshot After Execution
+ + + +This is the floated div.
+ +Any link in this div will reset the Guillotine.
+Content
+More Content
+And More Content
+Even More Content
+ +Until the float is taller than the non-floated content
+It might seem that not specifying a dimension to the container, although not practical always, would prevent the bug, +since the float will not be auto-enclosed in the first place. But IE being IE, even when the float is not auto enclosed a +Guillotine invoking link will chop off the bottom part of the float under certain conditions.
+ +For the Guillotine to occur in this context, the float should not be cleared by any element in the page. In this +variation of the bug, the float is chopped not by the container but by the body itself.
+ + + +Live Example | +Screenshot Before Execution | +Screenshot After Execution
+ +This is not very elegant, but the only thing that works at the moment is to have an empty div to clear everything, +outside and after the container.
+ +Live Example
+ + + +This is the floated div.
+Any link in this div will reset the Guillotine.
+ +Content
+More Content
+And More Content
+Even More Content
+Until the float is taller than the non-floated content
+This is a paragraph that comes after the container
+ ++<!-- Example Layout to Fix the Guillotine with Markup --> + +<div id="container"> + <div id="floated"> + This is the floated content. + It is vulnerable to the Guillotine. + </div> + + This is the non floated content inside the container. + Guillotine invoking links should be in this content. +</div> +<div style="clear: both"></div> ++ +
The float should be cleared inside the container for it to be enclosed. Using an empty clearing div was the preferred +way to do it before the method of +Clearing Floats without Structural Markup + +was introduced. If the float is cleared the old fashioned way using a div, the Guilotine will not be invoked.
+ +The clearing div should appear inside the container div, after the actual content.
+ +Live Example
+ + + +This is the floated div.
+Any link in this div will reset the Guillotine.
+Content
+ +More Content
+And More Content
+Even More Content
+Until the float is taller than the non-floated content
++<!-- Example Layout to Fix the Guillotine with Markup --> + +<div id="container"> + <div id="floated"> + This is the floated content. + It is vulnerable to the Guillotine. + </div> + + This is the non floated content inside the container. + Guillotine invoking links should be in this content. + <div style="clear: both"></div> +</div> ++ +
But using structural markup without semantics is not very appealing; after all, it's the reason why this clearing method +was introduced. It relies on the :after pseudo-class for standard compliant browsers (Mozilla & Co.), and specifying a +height to the container for, ahem, the sub-standard browser IE which does not support :after. But a dimension +specified container is exactly the thing needed to trigger the IE Guillotine, so this "generated clearing element" method on its own cannot +solve the problem.
+ +What we need is a way to use the :after method and still get things working. Fortunately, the +Holly Hack +comes to our rescue.
+ +First we should contain the non-floated content inside a block level element such as p or div if it is not already. +Wrapping text this way is semantically correct, so the standards advocating folks need not be upset. Then we give +a height to this block element using the Holly hack, so that only IE sees the dimension. Lo and behold, the bug vanishes.
+ +Live Example
+ + + +This is the floated div.
+Any link in this div will reset the Guillotine.
+Content
+ +More Content
+And More Content
+Even More Content
+Until the float is taller than the non-floated content
++<!-- Example Layout with the Holly Hack applied --> + +<div id="container"> + <div id="floated"> + This is the floated content. + It is vulnerable to the Guillotine. + </div> + + <p class="hollyhacked"> + This is the non floated content inside + the container. Guillotine invoking links + should be in this content.</p> +</div> ++ +
+/* Example style rules for the above fix */
+
+#container {
+
+ /* Set margins, padding, borders, colours etc. */
+
+}
+
+
+/* Contain the floats using the :after method */
+#container:after {
+ content: ".";
+ display: block;
+ height: 0;
+ clear: both;
+ visibility:hidden;
+}
+
+/* \*/
+* html #container {
+ height: 1%;
+}
+/* */
+
+/* End float containing rules */
+
+
+#floated {
+
+ /* Set margins, padding, borders, colours etc. */
+
+ float: left; /* float the block */
+
+}
+
+
+/* Apply Holly Hack to the non-floated content */
+
+/* \*/
+* html .hollyhacked {
+ height: 1%;
+}
+/* */
+
+
+
+
+
+It would have been great if this was the end, but IE is the kind of fat lady who never leaves the stage. Using the Holly hack to give a dimension to the non-floated content block, while getting rid of the Guillotine, triggers the IE's flawed float model plus it's own set of complications.
+ +However, the effect of the Guillotine is noticeable only when the float is taller than the non-floated content that follows it. Therefore, the non-floated content will rarely continue below the float in such a situation. This gives us some chance of safely applying the Holly hack without ruining the layout.
+ +As you can see, there's no perfect fix for the Guillotine bug. The designer should pick the solution according to the context and be willing to compromise. It's difficult, but what isn't with IE?
+ + + + + + + \ No newline at end of file diff --git a/explorer/ie-listbug.html b/explorer/ie-listbug.html new file mode 100755 index 0000000..b6279c3 --- /dev/null +++ b/explorer/ie-listbug.html @@ -0,0 +1,256 @@ + + + + + + + + + + ++ It’s another IE bug which is caused by placing a list with a background + set within a floated <div> that has been relatively positioned. (IE doesn't mind if you set a background + image, a color, or even both; they'll all disappear.) When these conditions are in place + IE will display the background incorrectly. With me so far? Here are a couple of screen + shots which should make it clearer: +
+ + +
+ 
+ This is how IE renders a <dl> with a background set on the
+ <dt>. None too impressive huh? I know, but what do you expect;
+ this is IE we’re dealing with here!
+
+
+ div {
+ float: left;
+ position: relative;
+ width: 150px;
+ background: #fffdd5;
+ border: 1px solid #000; }
+
+ dt {
+ background: red; }
+
+
+
+
+ 
+ This is how IE renders a <ul> with a background
+ set on the <li>. On the first <ul> no backgrounds
+ show, but on the second <ul> they do display.
+ The same thing happens with ordered lists.
+
+
+ div {
+ float: left;
+ position: relative;
+ width: 150px;
+ background: #fffdd5;
+ border: 1px solid #000; }
+
+ li {
+ background: red; }
+
+
+
++ Just in case those screen shots weren't enough for you, here's an actual + working example of this heinous bug side by side with a list displayed the + way the W3C intended! +
+ ++ This is the bug in action. Notice that while the second <dt> has a background, the first has no background. +
+ ++ Here is the same code with a fix applied. All backgrounds present and correct! (read on for the fix) +
+ ++ Now obviously this bug is fairly uncommon, it’s not often you float a <div> and relatively + position it. But saying that there are times when doing so comes in useful, mainly when absolutely positioning elements + and for fixing other IE bugs... Okay, maybe it is common after all! +
+ ++ This bug gets even stranger than in the examples above, much stranger! For instance; the order the lists + are placed and what type of lists they are affect the way the backgrounds display. Place a <dl> after + a <ul> and it's backgrounds will display, but when placed before; only the first <dt> will + display. If a background is set on <dd> then they will always be displayed, go figure. +
+ ++ Some other strange effects this bug produces are scroll and window painting. This is where the act + of scrolling or moving a window over a color background will "paint" it. I've made a simple + scroll/window painting example for you to peruse. + (I used a little JavaScript to open up an alert box, so if you have that disabled just open up a new window yourself and use that). +
+ ++ Note that either a background image or a background color can be "painted" by window dragging, so this is + consistent with the list background problem. +
+ ++ The good news is that this little bug is a cinch to eradicate. Just place + the following code in your stylesheet and you'll never have to suffer through + the indignity of disappearing list backgrounds again! +
+ +
+
+ ul, ol, dl {
+ position: relative; }
+
+
+
+ + Another way is to wrap the effected lists in a relatively positioned <div>, + but as this adds extra, un semantic mark-up, it's best to just use the + first method, which I've patented as the "1 point Smith manoeuvre". +
+ ++ Some other less than perfect ways to defeat this bug, listed mainly for informational purposes: +
+ +display: inline; on the list. (Works on <dl>s)+ This is a really strange and annoying bug to deal with. It took me a + while to figure out just what the heck was going on and how to solve + it. The biggest problem with this bug is just how variable it can be. The + order in which the lists and other elements are placed have small but + noticeable effects on the way they're displayed. +
+ +
+ But despite this bug's variability, it's easily remedied, just declare
+ position: relative;
+ on all effected lists and you're good to go!
+
+Matt Smith
+silenus *at* rock dot com
+Last updated: July 9, 2008
+Created July 30, 2004
+
+ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++The contents of a <noscript> element should only be displayed when there is no script +engine or running of scripts is switched off. The <noscript> tag originated in those olden +days when some browsers didn't have JavaScript on board. Nowadays the tag has lost much +of its value, as all browsers have script support for decades, and only a very limited number +of users switches off JavaScript in daily practice. Nevertheless, the <noscript> tag isn't +deprecated, and remains valuable in these limited situations. +
+ ++In Internet Explorer 8's default view, the <noscript> element can experience a wonderous +transformation. This will happen when you style the <noscript> element to have a +background-color or a border, so as to have it clearly +show up in the unfortunate case there is no script support. +
+ ++Below is a graphic of what would be seen in such a scriptless browser: +
+ +
+Now, with Internet Explorer 8, heralded to finally be in support of the standards, and with its +script engine running at full swing, a strange 'ghost' of the <noscript> element appears. + See it yourself, by viewing this page in IE8. +
+ + + + ++This paragraph is preceeded by a noscript element with left floating, borders and a background, +along with the script warning text. +If you view the page in IE8 you will see a ghost of the floated noscript element complete with +borders, padding and background, but with no text content. IE8 apparently forgets +that the <noscript> element, should only be displayed when, well... when there is no script. +
+ ++Below is a screenshot showing what IE8 renders with scripting enabled. +
+ +
+The ghost can vary in appearance depending on its display property value. If it's made "block" +it will always show in IE8, but if it's "inline" then the ghost will disappear when "compatibility mode" +is enabled, probably because of the way IE7 handled inline elements in general. +
+ ++Web-developers across the world were so happy IE8 was finally going to relieve them of the burden of +'fixing the site for IE', but as it appears, Internet Explorer continues to cause extra work, +preventing web-developers from working efficiently... +
+ +Updated last: April 20th, 2009. + +
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+ The bug may be encountered in real life in a situation as shown top right (actually, this was how I ran in to it). There is a set of tabbed pages. Each tabbed page keeps its content in a separate container <div>. If tab 1 is selected, container <div 1> is shown (hence, the other container <div>s are hidden), if tab 2 is selected, container <div 2> is shown, etc.
+
+Initially tab 1 is selected. Hence, tab's 2 container <div> is hidden (display='none'). Now for the problem: inside tab's 2 container <div> happens to be a stack of images. Some of these images should be initially hidden. In this example it's a series of images of a model, supposedly at different ages. Initially, all images but the '10 year old'-one are hidden, so when you switch to Tab 2 for the first time, you should only see the '10 year old' picture.
+
+This is were IE's bug shows up: as container <div 2> was set to display= 'none', the images contained within this <div> were 'immune' for the property 'display= none' imposed on them, and didn't disappear. Hence, all images of the stack will be seen when tab 2 is chosen...
+
+One may 'break the IE spell' by clicking the (+) button seven times. Basically, this resets all the 'immunized' images to 'display= block' (Work-around nr 1 mentioned below). Thereafter, the hiding of the images will work correctly again.
+
Internet Explorer on Windows has a wide variety of rendering bugs. +Many of these bugs can be worked around by giving affected elements +the IE-specific "hasLayout" property and an extensive +analysis of how and when this works is available. This article +describes the opposite situation: an IE rendering bug that is +triggered by elements having layout for which the workaround is to +remove the hasLayout property.
+ +The bug is that certain form input elements whose containing box +has layout inherit the sum of the margins of all of their containing +boxes. Unlike the the well known IE +doubled float-margin bug, this one does not involve floats. There +is a workaround but, so far, no magic-bullet CSS-only +solution.
+ +Consider this sample code:
+ +.has-margins {
+ background-color: gray;
+ margin-left: 5em;
+ padding: 1em;
+}
+.has-layout {
+ background-color: tan;
+ width: 30em;
+}
+
+<form action="ignore">
+<div class="has-margins">
+ <div class="has-layout">
+ INPUT tag, type=text:<br>
+ <input type="text"><br>
+ INPUT tag, type=checkbox:<br>
+ <input type="checkbox">
+ </div>
+</div>
+</form>
+
+
+The outer has-margins box is gray and the full width of the page +except for a left margin of 5em. The inner has-layout box is tan, +30ems wide, and contains four lines of content: two of text and two +form elements. All four lines of content should be flush against the +left edge of the tan box.
+ +Here is how it actually displays:
+ + + ++For all CSS-enabled versions of IE/Win, including IE7, the +left edge of the text input field (the second line) is pushed +to the left. It incorrectly inherits the left margin of its +parent box because the parent has a width value, giving it +hasLayout.
+ +Consider another example which wraps a second has-margins box +around the inner has-layout box:
+ +<form action="ignore">
+<div class="has-margins">
+ <div class="has-margins">
+ <div class="has-layout">
+ INPUT tag, type=text:<br>
+ <input type="text"><br>
+ INPUT tag, type=checkbox:<br>
+ <input type="checkbox">
+ </div>
+ </div>
+</div>
+</form>
+
+
+
+
+The left edge of the has-layout box is correctly pushed twice as +far to the left (since both enclosing has-margins boxes have a left +margin). However, the affected input is now also pushed twice as far +to the left; compare its location to the text field in the previous +example. The form element actually inherits the the sum of +the left margins of all of its ancestors. Interestingly, it does not +inherit the top or bottom margins.
+ +The bug seems to occur for all INPUT types except checkbox, radio, +and image as well as TEXTAREA elements but not for SELECT +elements.
+ +The problem only seems to occur when the direct parent of the INPUT +element has hasLayout and any ancestor has margins. This leads to +several possible workarounds:
+ +<form action="ignore">
+<div class="has-margins">
+ <div class="has-layout">
+ INPUT tag, type=text, preceeded by inline text:<br>
+ Text: <input type="text"><br>
+ </div>
+</div>
+</form>
+
+
+
+<form action="ignore">
+<div class="has-margins">
+ <div class="has-layout">
+ INPUT tag, type=text, wrapped in an unstyled SPAN:<br>
+ <span><input type="text"></span><br>
+ </div>
+</div>
+</form>
+
+
+
+If anyone knows a better solution, or other situations under which +the bug occurs, please let me +know.
+ + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: September 9th, 2008
+Created December 11, 2006
+
+ + + + + diff --git a/explorer/inlinelist.html b/explorer/inlinelist.html new file mode 100755 index 0000000..691678a --- /dev/null +++ b/explorer/inlinelist.html @@ -0,0 +1,243 @@ + + + + + + + + +
+This red bordered div (#wrapper) should be 480px wide. +The black arrow above indicates the true right 'content edge' of #wrapper. +The unordered list below contains seven list items given 'display: inline' and +'white-space: nowrap', making them a non-wrappable line. +
+ + + ++See that textless line of 'ghost' list items above the 'true' list item line? +That is where the line should (and does) appear in Mozilla and Opera. But IE does not like +to let nested elements protrude beyond their containers, even when those containers are given +specified rigid dimensions. In IE the right edge of #wrapper is pushed over to accomodate +that rigid line of list items, violating the +W3C standard. +(see 'overflow:visible') +
++I could replace the list items by 'nowrap' spans, or even just one span, and the bug would still appear. +
++
+If #wrapper were not 'extended' in this manner, all browsers but IE5/win would match. However, when +it is extended, and a float is involved, it seems to induce the bug you see here. The line is dropped down +below the float, leaving those 'ghost' backgrounds behind. A truly bizarre bug. +
++Notes: IE5/win does not have the bug because it does not recognize 'white-space' as a valid property, thus +the container is not 'extended', and the bug is not triggered. IE6/win doesn't show the phantom +boxes, but still drops the line below the float. +
++Either a left or a right float will trigger the bug. +
++Opera 7.1 is strangely displaying as IE6 does, but without extending the container. +Maybe that's next on the agenda. Opera has recently exibited a flirtation with 'Explorer love' as documented in +this page. +
++Look close and you'll see that it is NOT the 'ghost' line that is extending #wrapper, +despite its being longer (due to the presence of the float). +Rather it is the 'true' line below the float that controls the right edge of #wrapper. +I've made the third <li> longer than the others to illustrate this point. +
++I do not know what is going on inside IE's rendering engine, but I'll bet it ain't pretty! +
++Partial Fix: It's possible to eliminate the ghost li's by applying the +Zoom Fix +to either the list or the list items. Note that this only removes the ghost line, making +all IE/Win versions look like IE6. The incorrect placement of the list itself remains the same. +
++The murky veil surrounding the need for a box dimension to prevent so many IE bugs has been partially +lifted, due to the discovery of a heretofore +obscure page +in the massive Microsoft website. There is no real explaination of this "hasLayout" property, but now there is at least some +structure to the madness that has been inflicted on us by Microsoft, for what it's worth. Apparently a box needs "Layout" or all +heck can break loose, bug-wise. MS does not state that specifically, but their browser behaviors leave no doubt whatsoever. +
++Screenshot thanks to Gary Bland, +and Fabrice Pascal, +of the css-dicuss list. +
++Kudos to Chris Hester +for tipping me off to the Op7.1 non-compliance. +
+ + + + +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: September 9th, 2008
+Created August 31, 2002
+
+
+
+
+
+
\ No newline at end of file
diff --git a/explorer/italicbug-ie.html b/explorer/italicbug-ie.html
new file mode 100755
index 0000000..eabff3c
--- /dev/null
+++ b/explorer/italicbug-ie.html
@@ -0,0 +1,506 @@
+
+
+
+
+
+
+
+
+In this page a problem that IE6 and below have with italic text is described, with some (partial) fixes.
+
Note that IE7 does not show the bug.
In short IE6 and lower have problems in computing/honoring the width of block elements that contain italic text. In its simplest form the problem can be seen here (to make it more evident a big font size and fixed pixel measurements have been chosen.) The two following boxes have a declared width of 200px. The first one honors it while the second one, which contains italic text, doesn't. It is about 9px wider. (Please note that there is nothing that prevents the two words to be broken in two different lines, and this actually happens with slightly changed values for width, font-size, ....)
+ +lorem ipsum
+lorem ipsum
+ +Here is a screen shot, in case you are not viewing in IE6:
+
The effect of the problem is always that a block element (the innermost container of the italics) is wider than it should be. +It is not necessary for the element to have an assigned width, also elements with "auto" width are affected. Depending on the +page this effect may either be unnoticeable or totally break a layout.
+ +The problem affects any IE5 and IE6. The exact conditions that trigger it are not known, so the problem seems rather random. +A (probably not exhaustive) list of findings:
+ +Here is a separate page with italic and justified text. No fixed font-size, so you can resize it, +and see the varying effect of the bug.
+ +It is normal that some letters (like 'j', 'f', especially in their italic form) protrude from their container box (if no padding is present.) +See the following example, or better this separate page, in IE6 and in Mozilla (or Opera.)
+ +jj m m off three six.
+jj m m off three six.
+ +The following are screen shots of the rendering in IE6 (left), and in Mozilla (right.) Op7 renders the same as Mozilla.
+
+
It seems that:
+ +These overflowing/cropping effects are rarely noticed because normally text is surrounded by padding which mask them.
+But the IE6 box enlarging effect is much more noticeable. And it occurs even if there is enough padding to mask any overflow of the
+text, i.e. it cannot be fixed with the simple addition of padding.
Looking at the examples with several IE versions (6, 5.5, 5.0), it appears that the problem is worse in IE5.0: the box
+enlargement seems always the same, but the text sometimes takes up more space, i.e. it comes nearer to the box edges.
+And a further weird bug sometimes appears in IE5.0 with justified italic text: a word touching the end
+of a line is entirely repeated at the beginning of the next line!
To show another manifestation of the problem we just need a page containing a single paragraph, with 'auto' or '100%' width, and italics. +Please open the example in a new window and slowly change its horizontal dimension. In IE6 +you will see an horizontal scrollbar that comes and goes. The horizontal scrollbar appears when IE renders the paragraph wider than +it should. The amount of the problem is a few pixels, and (as already mentioned) is dependent on the font.
+ +This case also shows that the problem has further variance depending on IE version (6, 5.x) and, for IE6, mode (quirks, standards.)
+ +This is a slightly more complex example to show how this bug can weirdly mix with other IE6 misbehaviors. Let's assume we have:
+ +The relevant markup is something like:
+ ++<div id="side">some side content</div> +<div id="main">some <em>main content</em></div> +<div style="clear:both;"></div> ++ +
And the relevant css:
+ +
+#side {
+ float: left;
+ width: 160px;
+ background-color: #ccf;
+}
+#main {
+ margin-left: 170px;
+ background-color: #cfc;
+}
+
+
+
+
+Better seen in a separate page.
+ +The effect of the bug on such example is a horizontal scrollbar appearing at some window sizes, as in the second example, +because the main div takes up more than the available space.
+ +Now let's add a small thing that is commonly used to avoid many other IE bugs, i.e. the +Zoom Fix, applied to the main div +In our specific example this will cure the 3px jog. Note that the zoom fix is proprietary and won't +validate unless it's hidden as described in the Zoom Fix page. +Also be aware that IE7 does not need these fixes, so they are hidden in the example below via use of the star-html filter, +which prevents IE7 and above from reading the rules. You may prefer just to use targeted conditional comments +to achieve the same thing.
+ +
+* html #main { margin-left: 0; height: 1%; }
+* html #side { margin-right: 7px; }
+
+
+
+
+
+Better seen in a separate page.
+ +Now when the browser window is horizontally resized a much more interesting effect appears. The green main div that should +stay at the right of the float jumps below the float and then again beside it, depending on the window width.
+ +So what happens? Only IE6 really knows, I can only say that:
+Of course this combined jumping problem may occur in more complex situations and be not so easy to spot, in pages where +there are many other elements which wrap or are wrapped by the ones that trigger the problem. The essential factors for it to appear +seem to be:
+ +Neither rearrangements of margins of the float and of the main div, nor addition of wrapping elements, seem to avoid the problem.
+ +Here is a simple example showing the other mentioned IE problem. There is a left floated image (an image and not a +div, to avoid mixing with the 3px jog problem), followed by a green div with fixed width and a margin-left to push it at the right of the +image, all inside a container. If the browser window is narrowed enough, so that the "liquid" container should become insufficient to +contain the green div (with its margin left), then the green div drops below the float, even if no more room is available there then +beside the float (it simply moves vertically.) Moreover the liquid container stops to shrink (or better: IE enlarges it to enclose the green div.) +More standard compliant browsers simply allow the fixed width green div to overflow the container and doesn't move it.
+ + +
+ Better seen in a separate page.
+ + +Some examples shown at the beginning of this page suggest that the problem may somehow be related to an incorrect +management of content that should overflow its container. Indeed the fix involves the use of the "overflow" property.
+ +Credit goes to Eric Tribou who +(in a message on css-discuss) +described a problem of this type that he had on a page, and how he fixed it. Eric also sent me some useful comments while he was working +with this bug on his layout pages.
+ +The fix (for IE5.5 and IE6) is simple, it requires the following two actions:
+The overflow declaration should have no effect since "visible" is the default value of the "overflow" property, +however it seems to change something in the IE5.5+/Win rendering, so that the enlarging of the element no more happens.
+ +These are the same examples of the beginning of this page, with the fix. Now all the boxes honor the stated width.
+ +lorem ipsum
+lorem ipsum
+ +jj m m off three six.
+jj m m off three six.
+ +Please note that, as result of the fix, the letters that should overflow the boxes, are really cropped. Fortunately these are rather +extreme cases. Normally there is padding around the text, so the crop doesn't happen, and all is well.
+ +This fix doesn't have any effect in IE5.0, it works only in IE5.5+. A fix for IE5.0 is:
+This restores the correct width for the box containing the italics. However (as we noted) IE5.0 really needs more space, +so the fix may (more frequently than in IE5.5 and IE6) cause the text to be cropped. Care should be taken that sufficient padding +is present to avoid this. It seems that a padding of 0.4em is always enough, while the half (0.2em) is sufficient for IE5.5 and IE6.
+ +The same examples as before, now with overflow: hidden. The last example is repeated with some padding, to avoid the letters cut off +(and the other bug, in IE5.0 only, of the repeated word.)
+ +lorem ipsum
+ + +jj m m off three six.
+ +jj m m off three six.
+ +It should also be noted that for IE5.5 and IE6, both overflow:visible and overflow:hidden, produce the same effect. Obviously +the former is preferable, unless the box contains just text, to prevent other undesired cropping.
+ +This is the same "jumping" page presented in the third example, with the added fix (overflow:visible for IE6, +overflow:hidden for IE5.) No more jumping of the content beside/below the float.
+ + +Better seen in a separate page. This is the whole fix, hidden from IE7 and all non-IE/Win browsers):
+
+* html #main {
+ overflow: hidden;
+ o\verflow: visible;
+ width: 100%;
+ w\idth: auto;
+ zoom: 1;
+}
+
+
+Note: The use of width:100% in this page is possible thanks to another IE5 "peculiarity": it doesn't mean 100% of +the parent box (which would not be appropriate), but 100% of the "available" space, i.e. the space that remains at the right +of the float, see the IE float model.
+ +If one wants to avoid the overflow:hidden solution for IE5.0, another way to solve the problem is to set the width of +the affected element to a value slightly less than the desired, to absorb the enlargement without breaking the layout. For +example if the wanted width is 100%, then use 95% instead, if it is 17em, then use 16.6em. In other words: instead of forcing +(with overflow:hidden) the box width to the desired value, simply assign a smaller width to the box, so that its enlargement +doesn't break the layout. This is not really a fix, but rather an obvious workaround, however it helps, sometimes. +The following example is again the "jumping" case, now solved feeding IE5 with width:95% for the "second column" div.
+ + +Better seen in a separate page.
+ + +There are probably other things to discover about this problem and maybe methods to avoid it.
+ +I found explicit mentions of it just in a few messages on css-discuss and +in the Simon Willison 's weblog. +If anyone has further findings, or disagrees on something stated in this page, then I would like to +hear.
+ +Many thanks to all css-d members (from whom I learned a lot about css and browsers problems) and especially to +Big John.
+ +
+Created March 2004 by Bruno Fassino.
+Last updated: September 9th, 2008
+
Written by Jeroen Mulder
+ ++ Return to Guest Demos + Return to Explorer Exposed + Next IE demo +
+ +IE/Win continues to amaze us. This demo will describe a bug where the line-height + is incorrectly rendered if the line contains a replaced element. Very simply, if + the default line-height is changed to a larger value, the line spacing above and + below any text line that contains a replaced element, such as a small emoticon, + will be half of the spacing seen elsewhere in the text.
+ ++ Note that IE7 does not show this bug. +
+ +
+
+ + The graphic shows Internet Explorer 6’s inconsistent rendering of the line-height. + The line-height is made exceptionally large to exaggerate the effect of the bug, + so that the problem is obvious.
+The HTML needed to trigger this bug is nothing more than plain text, with a + normal inline replaced element, such as an image, within that text. + The 100px line-height value is applied to the body element, which should + separate the text lines by almost 100px.
+ +body {
+ line-height: 100px;
+}
Strangely enough, this bug is triggered just by the simple presence of any replaced element:
+ IMG, INPUT, TEXTAREA, SELECT and OBJECT.
Further investigation shows that IE6 apparently thinks it has a very good reason for this behaviour. It might seem random at first, but it is not.
+ +As specified by the W3C CSS-2.1 recommendations, + the difference between the line-height and font-size is called leading — half of it is called half-leading. + A user agent should add half-leading on the top and bottom.
+For example, a if a font-size of 12 pixels is defined with a line-height of 20 pixels, then 8 pixels (leading) of space should be added — 4 pixels (half-leading) on the top and bottom.
+ +
+ 
+
+ When IE6 encounters a line containing a replaced element, it collapses the half-leading of that line with the half-leading of the preceding and following line.
+ +Currently there does not seem to be a proper fix for this IE6 bug. The bug itself is awkward and very straight-forward, to say the least.
+Once the element is taken out of flow, either by positioning it absolutely or by floating it, the bug does not occur. + Considering none of us really has an idea how IE calculates the line height and the fact that the situation can’t get any more basic, + it seems as if the bug cannot be fixed at the source. However, in certain situations you can get it right.
+ + +By carefully applying a top and bottom margin to the replaced element one can force the line-height to be about the same as intended. + Unfortunately, this solution isn’t very universal and relies on a couple of simple requirements:
+By applying the following CSS on our demo page we get this new + demo, + which puts everything back into place.
+/* Holly Hack: Hide From IE5/Mac \*/
+* html img {
+ margin: 45px 0;
+ vertical-align: middle;
+}
+
+* html input {
+ margin: 39px 0;
+ vertical-align: middle;
+}
+/* Holly Hack: End Hide From IE5/Mac */
The top and bottom margin simulate the needed half-leading for IE/Win. Their values are calculated by subtracting the element’s height from the line-height and dividing it by two.
+ The vertical-align property is needed to position it correctly.
Finally, we use the hiding hack from the Holly Hack to prevent IE/Mac from applying it as well.
+ ++Notice: As of 2008, newer methods are now available to achieve the same results. +
+ +Use of such a ridiculously large line-height can be rare. However, this bug is still noticeable—albeit less—when using a more common font-size, line-height and small inline, replaced elements (emoticons, for example).
+Throughout the demo pixels are used to define font-size and line-height and measure the distances for the sake of simplicity. It does not matter what type of unit is used to define the line-height. Nor does it matter if a font-size is defined.
+ +Another bug and a strange one at that. Thankfully, the bug doesn’t affect the layout in a terrible way—it’s just annoying if you are a perfectionist. + I would have loved to conclude this demo with a real fix. Perhaps some day—until then it remains an issue.
+ + + +
+ Return to Explorer Exposed
+ Next IE demo
+
+A liquid box has a float inside, and content that appears along side that float. +All is well, until it's viewed in IE6. "Wah? Where's my content?!" You reload +the page, and nothing. When you scroll down, or perhaps switch to another window, +upon returning to the 'scene of the crime' there it all is, fat 'n sassy! +
++Note: This long standing bug has been suppressed in IE7 +(released in late 2006), so the Peekaboo Bug is finally on the way out. IE6 will still +exist however, and as long as it does we'll need to fix it. +
++div#floatholder (dotted border) is dimensioned horizontally by margins, and vertically +by content. div#float (thick brown border) is floated left, and contains a test link. +Following that are several lines of bare text, alternating with divs containing more text, +plus test links. Next is a cleared div (purple border), then another div for good measure. +
+ + + + +
+To reset bug, reload page.
+Screenshot
+
+
+This effect may turn up in a number of different contexts. We would try to list them here, +but the page would become very long, and make our heads hurt. +
+
+Try clicking the links. This will reveal the missing content, same as scrolling.
+If the float is a linked image, same deal. But only links within div#floatholder,
+and before the clearing div will expose the missing content.
+But check out the last link in the content area. Weird!
+
+Multiple repetitions of the content div containing the triggers can behave very strangely. +As argued on css-d, it appears to be triggered by the clearing div. When it is forced to +clear a float, the previous content after the float gets covered somehow, perhaps by the + background on div#floatholder. (dotted border) +
+
+Finally, this bug will be triggered even if div#float preceeds div#floatholder, provided that
+this external float actually touches the clearing div within div#floatholder!
+
+There are three ways we know to prevent this bug. +
++We suggest using a conditional comment to feed a hasLayout fix to IE6 and below only. +Further details helpful to this method may be found in the Zoom Fix page. +
+ ++Thanks to +Simon Willison +for the timely screenshot. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: September 9th, 2008
+Created July 7, 2002
+
/* Written for PIE in Dec 2004 *//* Updated: Feb 2005 */+As of 2008, IE7 shows some improvement for the problems described below, but many inconsistencies still remain. +
+ +In August 2004, Roger Johansson sent a test case to the css-discuss mailing list, stating that he could not find any mention of this odd IE/Win problem.
+<!--simplified markup--><body><div id="container"><div id="nav"><a href="#link">The link</a></div><div id="main">The text ...</div></div></body> #nav{ /* link */float: left;width: 20%;}#nav a:hover{background-color: #ff0;}#main{ /* text */float: left;width: 40%;margin-left: 2%;}#container{width: 400px;}
+
+Although I couldn't understand the reason for this jump on hover, I posted some more test cases on the discussion thread. It was Bruno Fassino who had the idea that the wrongly computed margins are obtained by applying the percentage not to the container width, but to the body width. At first I thought (as is usual, you need to be careful when dealing with floats in IE) the problem should have been already known and therefore easy solution, such as giving it a "hasLayout"-dimension, should resolve it. Far from it.
+ +The code lines provide information about the relevant structure and allow to build an example skeleton (XHTML strict) step by step. Sequences B and H are showing bits and pieces with percentage paddings, margins, and nested dimensioned wrappers and are of course not seriously meant. As of this writing, Opera suffers from floating problems and Geckos may have some rounding errors.
+
+A page's rendering has a time dimension. Position and measurements of elements are computed in the page flow.
+In IE6, a length will be expanded on demand, this does not correspond to the specification of min-height or height, neither min-width nor width. Regarding siblings, the first will cause the offset for the second. Two siblings at block-level side by side, where the lengths exceed the overall width of the parent: IE will just expand the parent (compare C7 in a standards compliant browser). Measurements of an element are not known until after all child elements have been processed, since at runtime it is still not determined as to whether it has to be expanded or not. They are computed out of themselves, height and width refer to 'intrinsic height' and 'intrinsic width', and these are indetermined during page flow.
The percentage is calculated with respect to the width of the generated box's containing block. ...
(CSS2.1: 10.2). An example: a margin of an element shall come to 5% of it's parent's width. So, this is simple ... but no, IE does not know at render time about the final width of it's containing block. So what now?
It is impossible to compute a percentage from the unknown (and how easy it would be just to take the width specified by the designer, but alas no). We can see and worry about the logical flaw in IE6's formatting model that is revealed by percentages.
+... If the containing block's width depends on this element's width, then the resulting layout is undefined in CSS 2.1
– this would read clearly: The resulting layout using percentage values is undefined in IE6.
<div class="ancestor square"> <div class="parent dimensioned"><a href="#link" class="child margin_5 no1"><img src="images/block10px10px.gif" alt="no1: maroon" /></a><!--etc...--></div></div> <!--reflowbutton and ancestor are siblings--><a href="#link" class="child reflowbutton"><img src="images/block10px10px.gif" alt="reflow" /></a>.ancestor{position: relative;float: left; margin:0 0 3em 1em;background: gray;border: 2px solid silver;}.square{width:200px;height:200px;}.parent{display: block;margin:49px 0 0 49px;background-color: silver;}.dimensioned{width:100px;height:100px;border: 1px solid black;}.child{ width: 10px;height: 10px;font-size:5px;line-height:5px; }.margin_5{margin:0 0 0 5%;}a:hover img{background-color: yellow;color: black;}* html a:hover{/* to insist on a redraw */background-position: 1%;}.no1 img{background-color: maroon;}.reflowbutton img{background-color: red;}img{ width: 10px;height: 10px;border:none;margin:0;padding:0; }.reflowbutton{position: relative;margin-left:-16px;float: left;width: 10px;height:10px;background: #f2f2f2;padding: 0 0 2px 2px;border-top: 2px solid #f2f2f2;border-right:2px solid #f2f2f2;border-bottom: 2px solid silver;border-left: 2px solid silver;}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+At first sight, IE6 seems to take the width of the containing block (silver 'parent') as indetermined. Well, regarding the CSS specification, this relative value should be calculated referring to the width of the nearest dimensioned ancestor element (grey 'ancestor')– as if there wasn't any dimensions set for the parent. I wonder why this ancestor value suddenly becomes a 'determined' one and not an 'indetermined' for IE, due to the fact it could balloon too, but then this would make any percentage completely useless in the cascade.
+While page flow, percentages on margins skip one generation in IE. +Children respect their grandparents.
+<div class="ancestor square"> <div class="parent intrinsic"><a href="#link" class="child margin_5 no1"><img src="images/block10px10px.gif" alt="no1: maroon" /></a><!--etc...--></div></div><a href="#link" class="child reflowbutton"><img src="images/block10px10px.gif" alt="reflow" /></a>.intrinsic{/* without dimensions */border: 1px dashed black;}In this sequence, the percentages refer to the partly liquid white sheet of this page ("parent" has no dimension, "ancestor" has, but is skipped due to the bug in question, the sequence "D"-element is undimensioned, so, at least, the white sheet is the "next dimensioned ancestor"). The initial miscalculation changes with the size of the viewport.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+To make it worse, this is not static. As said above, page flow follows a time dimension. In time, intrinsic lengths become determined when the containing block is rendered.
+ + +Assume the page flow is done, all the elements are processed. If a part of the construct has to be redrawn – this is necessary in a hover-transition with a background's change – with this at least a determined length is used. Now (now!), a percentage calculation follows the specification: ... with respect to the width of the generated box's containing block
, but not until the page rendering is complete. There is a state pre- and post-page-flow.
Compare this situation with an element relatively positioned: The box's position is calculated according to the normal flow ... Then the box is offset relative to its normal position
(CSS2.1: 9.3.1). Then -- the normal flow is processed, therefore, percentages for relative offsets are correct, as are margins in hover-transitions.
Hovering induces a reflow in the neighborhood of an element. Combined with percentages, it is just too awful for words. User agents are not required to reflow a currently displayed document due to pseudo-class transitions
(CSS2.1: 5.11.3). Yes, but please, they shouldn't really do this unless they know what they are doing.
What exactly is happening while a reflow occurs? I do not really know. At the moment, I think the nearest ancestor block which has a dimension is dissolved. Its dimensions, though known, are set to indetermined. All descendants are redrawn, as are all following siblings. For inline-level-elements, only the preceding line-box is redrawn with the element, that absurdly results in a last lines' indent, even if it's in the preceding paragraph (F1).
+ +That's all the magic in the flip-flop circuit of the red reflowbutton in the example sequences: Though the absolute lengths are all known – the page is currently displayed – the sequence is reflowed, making the same old wrong assumptions about indetermined dimensions as discussed again: back to start.
+ +It is the consequence of this 'quirky' model: the hover-transition could have forced an element to blow up, so the neighborhood is affected and so loses its 'determined dimensions state'.
+ + +Both IE6 in quirks mode and IE5 do not have such problems with percentages. Is it the miserable failure in implementation of a standards compliant box model in IE6? So, they corrected IE's box model problem in IE6, but was it the right time?
+ +Besides the wrong positioning, and the consecutive jumping on hover, the percentage sequences offer various awful unintended effects:
+ +The last point is unmasking: when you focus a link with the tab key, the grey dotted box (aka selection rectangle, focusing ring) outlines the content area and the left margin area of inline-level elements. This outline width area of the left margin is correct (!), but there is an offset to the content area (tab to C4/5 – see screenshot C5a – and watch the outline's position while the bugs are jumping and what happens on reflow, or gently move the pointer between the outline and the content from above and from below).
+ +The bug is the incorrect relation during page flow, whereas the jump and the other aspects are consequences.
+ + +The client calls saying your on-deadlines' work doesn't work, and you can't reproduce it on your environment: when it provides some obvious jumping in the menu (E1, E2), you are lucky, but mostly this bug will show only a rat's tail: perhaps in the form of a little gap due to a wrapping of a misplaced selection-box, maybe in form of some volatile additional content.
+<!--E1--><div class="ancestor rect"><div class="parent_menu" ><a href="#link" class="menulink block floatflow margin_3 no1">A</a><!--etc.--></div></div> <a href="#link" class="child reflowbutton"><img src="images/block10px10px.gif" alt="reflow" /></a><!--E2--><!--<a href="#link" class="menulink margin_3 no1">--> .rect{width:400px;height:100px; }.parent_menu{ display: block;margin:10px 0 0 100px;background-color: silver;width:200px;height:50px; border: 1px solid black;}.menulink{position: relative;top:-1px;width:1em;padding: 0 7px;font-size: 8px;text-align: center;vertical-align:top;color: white;border-top:none;border-right:1px solid black;border-bottom: 1px solid black;border-left: 1px solid black;text-decoration: none;}a:hover.menulink{background-color: yellow;color: black;}.block{display: block;}.floatflow{float: left;}.margin_3{margin: 0 0 0 3%;}.parent_menu .no1{background: maroon;}
+
+
+
+The percentage bugs on paddings and on margins are quite similar - on the surface. It depends on whether the element's Microsoft-proprietary "hasLayout" property is set to true or false:
+ +<div class="ancestor square"> <div class="parent dimensioned"><p class="loremipsum padding_10"><p>Lorem ipsum ... elit.</p></p><a href="#link" class="child margin_0 no2"><img src="images/block10px10px.gif" alt="no2: green" /></a><p class="loremipsum padding_10"><p><span>Lorem ipsum ... amet,<a href="#link" class="child margin_0 no3"><img src="images/block10px10px.gif" alt="no3: olive" /></a>... elit.</span></p></p></div></div> <a href="#link" class="child reflowbutton"><img src="images/block10px10px.gif" alt="reflow" /></a>.loremipsum{margin:0;font-size: 9px;color: gray; }.loremipsum span{/*line box outline*/border: 1px solid gray;display: inline;}.padding_10{padding:0 0 0 10%;}<p>Lorem ipsum dolor sit amet, consectetuer adipiscing +elit.</p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+elit.</p>
+
+
+<p>Lorem ipsum dolor sit amet, consectetuer adipiscing +elit.</p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+elit.</p>
+
+<p>Lorem ipsum dolor sit amet, consectetuer adipiscing +elit.</p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+elit.</p>
+
+
+<p>Lorem ipsum dolor sit amet, consectetuer adipiscing +elit.</p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+elit.</p>
+
+
+<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+ elit. </p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+ elit.</p>
+
+
+<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+ elit. </p>
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
+ elit.</p>
+
+The dilemma is, that the application of hasLayout via the Zoom Fix (or any other method) leads to another problem. +We jump out of the frying pan into the fire (F5). And doubled wrapping, another possible workaround, fails too: A second containing block with the same dimensions +as the parent is of no use when the element's padding is referring to the element's width (F6). So you'll have to omit hover-transitions when dimensions are set.
+ +Ironically both alternatives of "hasLayout" reveal a relational skip: to the ancestor or to itself, but not to the parent where the reference belongs.
+ +You knew it, this is the section for bad news.
+display: inline-block where appropriate.
+ Does work on paddings only (F2, F3) and you'll have to omit changing backgrounds on hover.margin-left: expression(this.parentNode.offsetWidth / 10 + 'px'); is equivalent to margin-left: 10%;. This seems to be a (desperate) cure. The relation is fixed by explicitly referring to the parent.In all the examples, the links are positioned, some are block level, as image replaced elements, or flowed – this is in order to make the problem visible and reproducible. But if you'd simply join two text links side by side, give them a percentage margin, with a :hover-effect, nothing obscure would happen ... really?
+The nonfloatet, nonpositioned, nonreplaced pure normal-flow inline characters example. I hope it is reproducible on your monospaced font settings.
<div class="ancestor square"> <div class="parent dimensioned mono"><a href="#link" class="inlinelink margin_3">X</a><a href="#link" class="inlinelink margin_3">X</a><a href="#link" class="inlinelink margin_3">X</a><a href="#link" class="inlinelink margin_3">X</a><a href="#link" class="inlinelink margin_3">X</a>a b c d e</div></div><a href="#link" class="child reflowbutton"><img src="images/block10px10px.gif" alt="reflow" /></a>a.inlinelink{color: blue !important;text-decoration: underline;}.mono{font: 15px monospace;}
+
+
+
+
+
+Well, in G1, the links do not jump, but the following string will be affected by duplicating chars in the next line box. Or in G2, which is quite similar, only the margin is a little bit wider, the links are jumping, the parent is ballooning – but: the alphabet's wrapping in the next line boxes are not affected. So, the consequences depend on the amount of the percentage error. In G1, the error can not be seen on the links, but indirectly: the actual line box is well, but there was something causing a wrapping of the first line box' content into the second one as if the percentage bug has occurred on the links and hasn't sufficiently covered up its tracks, leaving duplicate characters.
+ + +While working on the examples, I often saw something I named "multiple phantom background boxes". I stand corrected, I had used subsets of "class" values, but IE6 doesn't support this well.
+ +The rule was intended to match elements whose "class" attribute has been assigned a list of values that includes "menulink" and "no1" (see sequence E). But in IE, .menulink.no1 degrades to .no1, matching any occurance of it. So the background color in C, D was applied to the link and to the transparent image inside of it.
Anyway – this does not explain why the background boxes are repeated. A domino effect in redrawing the preceding line-box? Let's hope this one does not show up in the real world, but if so, display: inline-block fixes the phantoms (and avoids losing backgrounds), but not the miscalculation.
<a href="#link" class="child margin_10 no1"><img src="images/block10px10px.gif" alt="no1: maroon" /> </a> .child{width: 10px;height: 10px;font-size: 5px;line-height: 5px; }.margin_10{margin: 0 0 0 10%;}.no1 img, /* intended effect */.menulink.no1{ /* error in IE: degrades */background: maroon;}img{width: 10px; height: 10px;border: none; margin: 0;padding: 0;}
+
+
I'd love to hear from your experiences and solutions, friends.
+Sometimes I think that there is a self-organizing structure in the complex dynamics of bugs. Every set seems to have its fractal geometry referring to the whole thing.
+
+
+For their help in reviewing this article, I would like to thank Bruno Fassino, Roger Johansson, David Batty, and Big John.
+ +Ingo Chao
+ www.satzansatz.de +Bio: Ingo Chao, 1967, is a freelance editor (editing books of medical/psychological/sociological themes), living with his wife in Bremen/Germany.
+
+ If the browser window is narrowed enough, so that the "liquid" container should become insufficient
+to contain the green div (with its margin left), then the green div drops below the float,
+even if no more room is available there then beside the float (it simply moves vertically.)
+Moreover the liquid container stops to shrink (or better: IE enlarges it to enclose the green div.)
+In other words, when the browser window is narrowed so that the grey (width:80%) container should have a width
+less than 500px (margin-left + width of the green div) then IE/Win does two wrong things:
More standard compliant browsers simply allow the fixed width green div to overflow the container and doesn'n move it. +
+ + + + + + + + diff --git a/explorer/sidepages/IEt_fi5.html b/explorer/sidepages/IEt_fi5.html new file mode 100755 index 0000000..3bff982 --- /dev/null +++ b/explorer/sidepages/IEt_fi5.html @@ -0,0 +1,67 @@ + + + + + + + + ++ A simple paragraph with italic text and width:100%. In IE5+/Win there is an horizontal scrollbar that comes and goes, depending on window width. + Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. + Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. +
+ + + + + + + diff --git a/explorer/sidepages/IEt_fps.html b/explorer/sidepages/IEt_fps.html new file mode 100755 index 0000000..89d4d26 --- /dev/null +++ b/explorer/sidepages/IEt_fps.html @@ -0,0 +1,41 @@ + + + + + + ++ A simple paragraph with italic text. In IE6/Win there is an horizontal scrollbar that comes and goes, depending on window width. + Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. + Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi. +
+ + + + + + + diff --git a/explorer/sidepages/IEt_ij.html b/explorer/sidepages/IEt_ij.html new file mode 100755 index 0000000..01f56a7 --- /dev/null +++ b/explorer/sidepages/IEt_ij.html @@ -0,0 +1,62 @@ + + + + + + +one two three four.
+one two three four.
+one two three four.
+one two three four.
+one two three four.
+one two three four.
+ + + + + diff --git a/explorer/sidepages/IEt_ij2.html b/explorer/sidepages/IEt_ij2.html new file mode 100755 index 0000000..c0dbdf1 --- /dev/null +++ b/explorer/sidepages/IEt_ij2.html @@ -0,0 +1,83 @@ + + + + + + +jj m m off three six.
+jj m m off three six.
+ +jj m m off three six.
+jj m m off three six.
+ +jj m m off three six.
+jj m m off three six.
+ +jj m m off three six.
+jj m m off three six.
+ +jj m m off three six.
+jj m m off three six.
+ +jj m m off three six.
+jj m m off three six.
+ + + + + diff --git a/explorer/sidepages/border-chaos-demo.html b/explorer/sidepages/border-chaos-demo.html new file mode 100755 index 0000000..2a75cf0 --- /dev/null +++ b/explorer/sidepages/border-chaos-demo.html @@ -0,0 +1,128 @@ + + + + + +This is a <p> that does not have a border.
+ +
An image followed by a paragraph of text
+This is the floated div.
+Any link in this div will reset the Guillotine.
+Content
+More Content
+And More Content
+Even More Content
+Until the float is taller than the non-floated content
+This is a paragraph that comes after the container
+ + + + diff --git a/explorer/sidepages/favicon.ico b/explorer/sidepages/favicon.ico new file mode 100755 index 0000000..e799dc7 Binary files /dev/null and b/explorer/sidepages/favicon.ico differ diff --git a/explorer/sidepages/masthead.jpg b/explorer/sidepages/masthead.jpg new file mode 100755 index 0000000..2d38cbe Binary files /dev/null and b/explorer/sidepages/masthead.jpg differ diff --git a/explorer/sidepages/msie-lineheight-replaced-element-demo-01-hack.html b/explorer/sidepages/msie-lineheight-replaced-element-demo-01-hack.html new file mode 100755 index 0000000..81fbb3c --- /dev/null +++ b/explorer/sidepages/msie-lineheight-replaced-element-demo-01-hack.html @@ -0,0 +1,44 @@ + + + + + + + + + +Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
+Quisque ultrices dapibus tortor. Vestibulum non dolor nec ipsum tempus pulvinar. Nam bibendum, justo a euismod aliquet,
+ligula orci nonummy velit, eget porttitor ligula pede et dui. Maecenas odio nulla, pharetra sit amet, vehicula in, mattis in, mauris.
+Maecenas blandit gravida dolor. Nullam a ante. Praesent vestibulum metus sed orci. Praesent luctus wisi rutrum mauris.
+Nunc purus. Morbi convallis justo a velit. Fusce posuere, eros vel malesuada venenatis, dolor orci posuere lectus,
+quis auctor nibh nunc a risus. Curabitur neque lacus, ultricies tincidunt, ultrices sit amet, egestas at, wisi.
+Pellentesque viverra ullamcorper risus. 
+
+Quisque id lorem eu dui egestas interdum. In ultricies, ipsum vel nonummy lacinia,
+tortor elit consectetuer mauris, et convallis odio felis ut urna. In nulla. Donec bibendum magna nec mi.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
+Quisque ultrices dapibus tortor. Vestibulum non dolor nec ipsum tempus pulvinar. Nam bibendum, justo a euismod aliquet,
+ligula orci nonummy velit, eget porttitor ligula pede et dui. Maecenas odio nulla, pharetra sit amet, vehicula in, mattis in, mauris.
+Maecenas blandit gravida dolor. Nullam a ante. Praesent vestibulum metus sed orci. Praesent luctus wisi rutrum mauris.
+Nunc purus. Morbi convallis justo a velit. Fusce posuere, eros vel malesuada venenatis, dolor orci posuere lectus,
+quis auctor nibh nunc a risus. Curabitur neque lacus, ultricies tincidunt, ultrices sit amet, egestas at, wisi.
+Pellentesque viverra ullamcorper risus.
+
+Quisque id lorem eu dui egestas interdum. In ultricies, ipsum vel nonummy lacinia,
+tortor elit consectetuer mauris, et convallis odio felis ut urna. In nulla. Donec bibendum magna nec mi.
You need to be viewing this with IE/Win for it to work. The first list's items have a background color, and the second +set of list items have a background image.
+ +I've provided advanced CSS consulting for
+Milo
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ +
+
+
++Please look closely at the test box to the left. Observe how the text at the top does not quite +touch the blue bordered float on the left. The text should touch the float, but instead it seems to +have a 3px padding, keeping it away from the float. +
++Now see how in the black bordered paragraph the 3px space is still there. The left edge of the +paragraph is way over on the left edge of the test box (behind the float), +but the space is still evident. This implies that +the space is connected to something in the <p>, not the <p> itself. +
++Only text, which also means 'line boxes'; invisible 'anonymous' boxes that +contain inline text, images, and anything else that is declared 'inline'. +
++So apparently IE is adding 3px of space to the end of the line boxes in this demo if they touch the float. Now cast your +eyes down to the bottom of the test box. Observe how the 3px space is evident even tho the red bordered +box (#jog-box) is left margined far enough to separate it from the float. This means that the added 'space' +is applied to the line boxes that are adjacent to a float, not just to ones that are touching the float. +
++Be aware that the paragraphs' left margin extends behind the float, reaching all the way +to the left side of the brown container box, just as with the black bordered paragraph in the demo. +To make that gap between the float and the red paragraph, the left paragraph margin must be larger +than the width of the float. +
++Observe how the 3px space abruptly ends at the same vertical height that the float also ends. (!) +It's now clear that the float is causing the 3px space to be added to the line boxes. In fact, if the blue box +were floated to the right, the space would be appended to the right end of the line boxes. +
++The close-up image at the lower left shows the 'text-jog' that results when the float is passed by. + It is this 'jog' that is the main problem, causing a small but irritating +blemish on otherwise flawless layouts. +
+
+Another problem may occur in tightly fitting layouts when the 3px space is added. Say you have a float
+followed by a div holding a large image. Both the float and the div are in a container, and the width of
+the div combined with the side margin on the div equals the container width.
+
+When the adjacent float induces the 3px space on the one big line box inside the div (the one holding that image), the
+div can no longer fit in the container! That's because there is 3px of new width on the div, but IE has already determined
+box widths, and refuses to go back and redo it. So what
+happens is that the div does not display until it is below the vertical level of the float. There, the
+3px does not get applied, and the now properly sized div fits just fine, especially with no float to sit next to the div.
+
+Without knowledge of the 3px space, solving this misalignment can be nearly impossible.
+
+Up until late 2003 coders who noticed the jog had serious difficulties dealing with it. Eventually it became +clear that applying a dimension to the paragraph, either 'width' or 'height', prevents IE/win from adding +the 3px space. +
++Unfortunately, this dimension also throws IE into its proprietary +float model. In effect, when the dimension is applied +the paragraph seems to act much like a float, displaying next to the real float, rather than +letting the float drape across it as the specs require. +
++Normally this behavior must be avoided to keep all the browsers in agreement, but thru it +can actually be employed to kill the 3px jog while not leading to variance. +
+ + + ++Remember, only IE/win is allowed to see this, and in addition, IE is prevented from applying the left margin on the +paragraph. That left paragraph margin is normally allowed to run behind the float (as it should), but +the paragraph box itself is kept from doing the same (in IE) just because it has that dimension (very wrong). +As if that were not enough, the paragraph margin seems to get 3px added to it by IE, so if the margin is as wide +or wider than the float, this 3px variance will make IE have a wider gap between the float and the +paragraph. +
+ ++Special Note: This fix should be used on a wrapper element enclosing all content +following the float, not on individual elements. By applying the fix on just one big element the hack +stays simple and possible problems are avoided. +
+ ++Rather than deal with this madness, just apply desired horizontal space between the two elements +by using a right margin on the float instead of the left margin on the paragraph. Here's how it might +look in code: +
+
+#floatbox {
+ float: left;
+ width: 100px;
+ }
+
+p {
+ margin-left: 110px;
+ }
+
+/* Hide from IE5-mac. Only IE-win sees this. \*/
+
+* html #floatbox {
+ margin-right: 10px;
+ }
+
+* html p {
+ height: 1%;
+ margin-left: 0;
+ }
+
+/* End hide from IE5/mac */
+
++Two more things. When the IE float model is invoked, the float suddenly has a 3px margin on the +paragraph side, which at least can be killed within the Tan hack either by a negative 3px margin, or +by reducing the existing float margin by 3px. +
++Additionally, as mentioned before, IE5/mac must be kept from seeing the hacks, +so the hacks are wrapped in the Mac-hack (uses comments). See this +live demo for a working example +of this method, and check out the source for tips. +
++Special Note: If the float is an image (or presumably, other generated content), +then the 3px line box space is NOT applied by IE. Sadly, IE5.x/win does not leave it at that, but in the event +of a floated image, a proprietary 3px margin is applied to both the left and right sides of the image. Since IE6 +does not do this, we have yet another cross-Explorer variation. Just what we need. +
++Unlike the 3px line box space, these unfortunate margins can be hacked away by use of the Tan hack, thus: +
+
+* html #floated-image {
+margin: 0 -3px; ma\rgin: 0;
+}
+
++Using '* html' before the target element keeps all but IE from recognizing it as a real selector. +IE thinks there is a wrapper element surrounding 'html' and so does obey all rules within this block. +The second 'ma\rgin' is ignored by IE5.x/win, so IE6 and IE5/mac get the non-hacked margin values. +For more on the Tan hack see +this page. +
++IE is still a big headache, but I personally thought this problem would never be solved. +Glad to see that not all is lost. +
+ ++New info (mid 2004) has been discovered relating to the use of dimensions on a box. Go to +this page +for the dirty low-down. +
+ ++Thanks to +Ellen Herzfeld +for timely testing of various Explorer versions. +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: May 13, 2007
+Created January 18, 2003
+
+This text is wrapped in a paragraph (black border), and see, the space is still there, deep inside the <p>! +
+ +
++Screenshot in IE6 +
++ Another IE bug, where an AP-Box + may not force a scrollbar even if the content is long enough to require one, resulting in + hidden content. +
+ ++ The page content is contained within a box that is positioned relatively and has no assigned + dimensions. Nested in this box are one (or more) absolutely positioned boxes. + Take a quick look at this graphic showing how it should work. +
+ +
+
+ 
+ The Absolute Box should appear to start from inside the relative box, meaning
+ the top of the AP box
+ is calculated from the top of the relative box, not from the top of the document.
+ But the relative box will not truly "contain" the absolute box because
+ absolute boxes are not "inside" other elements. Instead, the AP box is on a higher z-index level
+ (closer to the viewer), so the AP "child" box is free to become larger than its relative "parent" box.
+ In the graphic to the right, the small red box
+ is the relative box. The Absolute Box (blue) starts from the relative
+ box, but is not "contained" by it. The scrollbar must be shown, so that
+ the user can scroll down to the entire absolute box even though it occupies no
+ real "space" in other elements.
+
+ 
+ Internet Explorer does not think so. IE thinks the relative
+ box really does contain the absolute
+ box.
+
+ IE tries to make the relative "parent" element as big as the AP-Box that is "inside" it. But + somehow IE can only make it as tall as the viewport. What happens then + is that IE seems to "forget" what goes below the viewport and because of + this, IE will limit the scrollbar. Sometimes the + scrollbar will not appear at all. With the scrollbar limited, the user + will be unable to scroll to the bottom of the AP-Box, resulting + in hidden content. +
++ This bug affects IE5, 5.5 and 6 for Windows. IE6 is buggy even when + it is in "Standards Mode". While a dimension on the relative box will prevent the bug, + a dimension on the nested absolute box will not fix the bug. +
++ + Sometimes it's bad for the layout when there is a dimension on the Relative box, + but don't panic! We have a quick and working fix for this, that won't hurt the layout at all. +
+
+ The good (and not so old) Holly Hack
+
+ can help you get rid of it. Just apply a height:1% to the
+ "relatively" positioned box and your content will scroll fine, as if nothing was
+ wrong. Read This article
+
+ for details on the Holly hack.
+
+ Here is the code used to fix the bug in this demo:
+
+
+ /* Start hide from IE-Mac \*/
+
+ * html #wrapper
+
+ {
+ height: 1%;
+ }
+
+ /* End Hide from IE-Mac */
+
+ If you want to see what happens when the fix is not applied + to such a page, you can do it right here. This page is constructed with a "relative" box + that encloses an AP box, which then encloses all the other page elements. + The relative div#wrapper has been "fixed" as described above, and clicking this + unfix + + button will remove the fix from the page via a simple JavaScript. To restore + the missing content and reapply the fix, + just reload the page. Remember that JavaScript is used to + unfix the page, but it has nothing to do with the bug. +
+
+ May 25 2004, Altieres Rohr.
+ Updated 19/April/2010.
+
+Okay, here is a simple test concerning how static elements interact with floats. According to the W3C specifications, +when a floated element is directly followed by a static element (one that is normally flowed), then first, +the float will be displayed against the left edge of the containing element (in this case the 'body' element), +and then the static element will also display against that same edge, and at the same vertical height as +the float. +
++The float should overlay the static element, unless the static element has a left margin that +moves it out to the right, and out from behind the float. The static element might also be 'cleared' +(clear:left or clear:both), which would put it below the level of the float. +
++The green bordered box (div#left) is floated left in the 'body', and is followed by div#static (purple box). +If div#static had no width, then all modern browsers would display correctly, with the purple box +overlaid by the green bordered box. +
++But, because div#static is width defined, browser variance is fully evident. +That 'width' declaration makes Internet Explorer put div#static +alongside the float as tho the float were part of the left body edge. +Moz/N7 and Op6/7.1 do it according +to the specs, with both boxes firmly pinned to the left body edge. +
++Making sophisticated use of float layouts sometimes requires stating the 'widths' on some boxes, but +doing so to a static box that follows a float makes IE display differently than any browser that dares +to adhere to the standards. So differently in fact, as to make the situation impossible to ignore. (unless one +happens to be *you know who*) +
++So the choice is to code only for IE, knowing the minority browsers will break, or avoid using the 'width' +declaration in many cases, putting many types of layouts 'off limits'. Some choice. +
++The demo you see here is fully pixel defined, but usually a layout has the widths in percentages, at least for the +elements following the float. When div#static is given a percentage width, IE5.5 looks at the available horizontal space +alongside the float and says "That is now defined as 100% of the width". So if div#static gets 'width: 50%;', that div is +half as wide as the space next to the float and starts next to the float as mentioned. +
++However, IE6 is different. Yes IE6 does start the div next to the float, but it does not take the float +into consideration when figuring the width of div#static. Rather it uses the entire container as the 100% width +refrence, just as the specs require. Yet it does start the div alongside the float! So the problem is only +half-fixed in IE6, creating one more headache for us poor coders. +
++What does this mean? Well, if the div is given a width of 100%, it is as wide as the body element, and being placed +next to the float it forces the right edge of the body element sideways by the width of the float, causing a scrollbar. +But only in IE6! As if this mess weren't already bad enough. Oy. +
++There was recently a disturbing turn of events. Opera7, (released Jan-2003) +was doing just what IE does; +putting div#static next to the float, rather than having div#static ignore the +float and start at the left viewport edge, as was done in Op6. +
++This seemed to be a 'cave-in' on the part of the Opera decision makers, to take the 'easy path', rather +than stick to the specifications. Microsoft is indeed very influential, and apparently the float +specifications were fast becoming a dead letter. +
++Happily Opera 7.1 (released April-2003) properly obeys the float specification. Whew! +
++
++I am no purist, and could happily live with a specification designed by Microsoft, but to have MS +publicly support the specs while silently flouting them really burns my toast. Is this how the future is made? +
++It's past time that these issues were aired out. Gentle reader, if you know any way of 'getting to' the +movers and shakers at Microsoft, won't you please try and shake loose some kind of information +regarding future plans? I dread having to tell the next newbie that the simple, straightfoward +CSS standards can't simply be used 'as is', because the majority browser maker refuses to +conform as it supposedly has agreed to do. This situation has got to end sometime; why can't it be now? +
+
+Holly 'n John
+ e-mail
+©positioniseverything
+Last updated: January 18, 2004
+Created January 28, 2003
+
I've provided advanced CSS consulting for
+Milo
+and many other big sites.
+Hire me to help you too.
Let Big John (yours truly) teach you +about CSS in a setting where you can +actually ask questions. Will wonders never cease? Learn about the cascade +and its arcane mysteries, or dive into the cesspool of IE6 with Big John as your lifeguard. +
+ ++Besides upcoming webinar dates, you can also download recorded versions +of previous webinars +(some free, some for sale). +
+ ++These CSS bugs are all exclusive to +Gecko based browsers. +To see the demos properly, they must be viewed in Mozilla, or one of the many browsers +based on that Open Source rendering engine. +Download the browser? +
++You may notice that there are very few Mozbugs here. Mozilla is under constant revision and updating +by numerous volunteer programers, so what bugs do appear seldom survive for long. Kinda different +from Micro$oft, ain't it? +
++I am always looking to improve these demos, so if you know of anything useful, +lay it on me. Please don't hold back; I have yet to write a demo that did not need +corrections, updates and whatever. This site is really a group effort. Be part of that group. :-) +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: June23, 2003
+Created June 23, 2003
+
+The two colored boxes above are left and right floated boxes. Left comes first in the source, +right second, and both are followed by a flowed header ("The Setup") that has 'clear: right' applied to it. +The floats have a fixed pixel width. That's basically all there is to it. The body is margined a bit, and the +main header is absolute, so it is not involved with this demo in any important way. +
+ ++So you're asking "what's the big deal?". Well, when opposing floats like this cannot both fit side by side in a +container, the second one is forced below the first. In this case the green right float would go below the +red left float (but still remain floated to the right). Since the h2 element above ("The Setup") is cleared for right floats, it should +appear below the right float. +
+ ++In Geckos previous to Firefox 1.0, that does not happen. Instead, if the window is narrowed enough to cause a float wrap, +the header (and the following flowed elements) begin up alongside the left float! +In fact, the content is broken into two sections. +
+ ++So go ahead, narrow that window! +
+ ++Below are screenshots, first in Mozilla (Gecko based browsers), and next in a non-Gecko browser. +Remember that this bug is fixed, starting from Firefox 1.0. +
+ +
++Gecko +
+
++Explorer +
+ ++Sure is. Below is the same demo, except that the source order of the two floats is reversed, +and the following header is cleared for left floats. +
+ ++This Mozbug does not occur if the following cleared element has 'clear: both'. Only if the trailing +float is followed by an element that is cleared in the same direction as that float, will the Mozbug +occur. I'll grant you that this situation is slightly unlikely, but gosh darn it, I want full float control! +Mozilla is such a fine CSS browser that even this slight flaw takes on horrendous proportions. +
+ ++Opera has no problem with this feat. Amazingly, even Internet Explorer does well, altho +the container (#content) must have an assigned dimension like height or width to avoid major buggyness in both IE5.5 +and IE6 for windows. Pretty typical for IE. +
+ ++Uh, yah. Well, moving right along... +
+ ++Seriously, There is no way to correct the problem from the coding side. However... +
+ ++Flash! +It now appears (June 2004) that the latest Mozilla build does not have this bug. Woohoo! +It took a while, but as a bonus they also fixed the problem where a cleared element not directly +below a float fails to clear that float, which caused great difficulty when laying out the +Piefecta demo. +Hmmm, could there possibly be a connection? +
+ ++To see how a Mozbug gets fixed, take a look at the +bugzilla page on this issue. +The fix, while now in the Mozilla builds, has been slow to be applied to the Firefox "branch". There does seem +to be some action going on for Firefox, so eventually the fix will become universal. +
+ ++Flash! It's November 10th of 2004, and Firefox 1.0 +has just been released. A few days ago the fix was not in Firefox RC2, the final beta version, but the first official Firefox release +does contain the fix! Wow. This incorrect Gecko behavior was first noticed over 30 months ago, and we never dreamed +it would be this close a shave, but all's well that ends well. Woohoo again! Open Source really rocks. Bill Gates, are you taking notes? +
+ ++So, this means that while the problems are still around, it's just a matter of a year or two until they become +very minor and can be ignored. Now if only IE bugs would go away that fast... +
+ ++Special Thanks to +Douglas Livingstone for +discovering this Mozbug and pointing it out to me, and +Frank Wein for +pointing out the first instance of a fixed Moz build. + +
+ +
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: December 28, 2005
+Created June 22, 2003
+
+This is a Gecko bug (Mozilla, Firefox, N7, etc), which occurs +when a wrapper div is given a specified 'line-height' value using a +percentage unit with a value other than 100%. +Inside this container are a +number of identical block level elements. The 'line-height', 'font-size', and vertical +padding on these elements will all affect the bug as well. +
++The result, small gaps (or overlaps) between some of the block elements, +when viewed in Mozilla. +The gap demo is the blue group in the upper left, the overlaps are the green group below. +
++Here's the cool part: Try changing the critical values commented in +the embedded styles. The gaps/overlaps shift around, and have different +but still regular patterns. Sometimes they go away entirely. +
++Fix: Avoid using the property "line-height' on boxes that will hold vertically +stacked block boxes. This includes inheriting 'line-height' from the parent element. +
++Incoming: +Philippe Wittenbergh pointed +out back in early 2002 that this bug has all the markings of a 'rounding error'. +We (and others) have since learned a lot more about this interesting css effect. +Check out PIE's simple +rounding error demo +to see how vulnerable your browser really is, and for a heavy duty treatment of +this topic, go to Ingo Chao's +Overlaps and Gaps +article. +
+ ++Flash! +It now appears (Sep 17, 2005) that the latest builds of Firefox +and Mozilla +do not have the vertical gaps or overlaps! At all text sizes they are +rock solid, and we applaud the Gecko volunteers for a job well done. Even tho +the rounding error page does still show some gap activity, it is greatly reduced +and is now comparable to the other browsers. Woohoo! +
+ ++Kudos to Frank Fridlund for pointing it out. Frank opines that +perhaps the new SVG support has something to do with it, but who knows? +
+ ++Gecko can fool you: +Below are some screenshots of the demos, taken in Firefox 1.06, showing the gaps and overlaps. +If you do not see them, just increase the text size in the browser and you will. The overlaps +can be particularly easy to overlook so we have supplied a detailed look at one spot where +a button has overlapped the button above by 1px. +
+
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: September 24, 2005
+Created June 15, 2002
+
+
++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +
+and many other big sites. +These CSS bug demos were created by our coding friends. +If you think you have what it takes to do this stuff, we want to talk to you, friend. +See this page for details. +
++As of July 3, 2004, these demos have been moved into the folders of the browser they refer to, so +their absolute paths have changed. Designing a well-working site structure is not as easy as it had first appeared... +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: April 27, 2009
+Created April 24, 2003
+
+#leftbox {
+ position: absolute;
+ left: 0px;
+ width: 215px;
+ }
+
+
+ This fixed width sidebar, #leftbox, is absolutely + positioned with a left position given but no top positioning. This is so + it will automatically position itself based on the size of the + #header div.
+ +This box gets its background color from the background + color set in the <body> tag. This way it + will appear to run the full height of the page.
+ +
+#header {
+background-image:
+ url("images/waterlilies6.jpg");
+background-position: 0 0;
+background-repeat: no-repeat;
+height: 100px;
+}
+
+
+ The #header div at the top of the page spans the width + of the viewport. It has a background image applied and is given a height so + that the following absolutely positioned divs are placed properly on + initial load of the page.
+ +Many thanks are extended to + Jonas Erlandsson whose original + request for help spawned this demo idea, to + Philippe Wittenbergh for Mac testing and very excellent + advice, and to Big John for inspiration and + support, and for "bugging" me to make this demo.
+ +
+#rightbox {
+ position: absolute;
+ right: 0;
+ margin-right: 0;
+ width: 138px;
+ }
+
+
+ This absolutely positioned #rightbox has a fixed + width and right positioning set. Again, no top positioning is + given so this div will adjust its height to what comes before it.
+ +The background-color on this div is made by a + repeating .gif placed on the #container + div.
+ +Because this div, and the #leftbox div are + both absolutely positioned and have fixed widths, care must be taken + with content that may not wrap, such as long URIs or + <pre> tags. IE will expand the divs to contain + the content, which violates the specs, and other browsers will let + too wide content spill outside of the div.
+ +IE5/Mac presents an additional challenge with this + right positioned AP div. See source for more information and the hack + used to overcome the problem.
+ +Following #leftbox, a + #container div is opened which will hold the rest of + the page. This div is given a left margin equal to the width of the + absolutely positioned (AP) div preceding it. In this case, + #container has a left border and a repeating background + image on the right that provides the background color for the + #rightbox column.
+ +
+#container {
+ margin-left: 215px;
+ background-image: url("rightbg.gif");
+ background-position: 100% 0;
+ background-repeat: repeat-y;
+ }
+
+
+ Inside #container, a static div,
+ #navmenu, holds nav links. The links are marked up
+ as a horizontal unordered list.
+ 
+#navmenu ul {
+ display: block;
+ list-style: none;
+ text-align: center;
+ }
+#navmenu ul li {
+ display: block;
+ float: left;
+ width: 10em;
+ }
+
+
+ Inside the <ul>, the <li>s + are floated left and given a width and both the <ul> + and the <li> are given a display property of + {display: block}. Following the floats is a + <span> that clears them. This menu will wrap nicely + if the browser window is made narrow enough or the text is made large + enough to cause that.
+ +
+#wrapper {
+ margin-right: 138px;
+ }
+
+
+ A #wrapper div is opened to hold a couple + of floats. Since it is within the #container, + it needs only a right margin to clear the AP + #rightbox.
+ +IE5.5 will need a width on this + #wrapper to prevent a horizontal scrollbar, + but IE6 must not have a width. See source for the hack.
+ +
+.left {
+ float: left;
+ width: 43%;
+ }
+.right {
+ float: right;
+ width: 43%;
+ }
+
+
+ Inside the #wrapper are + two float containers, one floated left and one floated right. + Nothing extraordinary about either of these.
+ +Since these divs are both floated, there will be no + + 3px text-jog in IE if one div is + longer than the other.
+ +IE doubles the margins of the floats on the + side they contact their container, #wrapper in + this case, and so the correct margin width for each float must + be hacked for other browsers. See source.
+ +
+.clear {
+ clear: both;
+ margin: 0;
+ padding: 0;
+ }
+
+
+ Following the floats is a clearing div with + {clear: both}.
+ +IE5/Mac needs the margin + and padding of this div set to 0 (zero). Because of this, + if it was desired to put text in this clearing div, or put a + border on it, it would need to extend the full width of the + #wrapper. In this demo, it just holds a + space.
+ +
+#contents {
+ margin-right: 149px;
+ margin-left: 10px;
+ }
+
+
+ Another div contains the rest of the + content of the page. This div, #contents, needs a + right margin to clear the right AP div. Further margin width can be + given to left and right if the background of #container + is desired as a frame for #contents (as is done here). +
+ +Note: Due to the formatting of the + text of this demo, which includes <pre> tags, this + particular page will look rather messy if the browser window is + narrowed significantly or if very large font sizes are used. If you + would like to try resizing the browser or increasing the text size, + please see + this example page, which is made without + <pre> tags. More layout tips and + known problems can also be found on + the same page.
+ +Known Problems
+ +Many thanks are extended to + Jonas Erlandsson whose original + request for help spawned this demo idea, to Philippe Wittenbergh for Mac + testing and very excellent advice, and to + Big John for inspiration and + support, and for "bugging" me to make this demo. + +
Frog image on + this page courtesy of Bob Easton. The original is a 4"x6" + pen and ink drawing done by him.
+ +Known Problems
+ +
I hope you enjoy your time here. Test things out, change + text sizes, change the browser width, get a feel for how everything + works. Below is a little information about what you'll find here.
+ +At the top of the page, the #header has a + background image (and I'm rather fond of it, too). The links below + it are an unordered list that will wrap nicely if needed.
+ +To your left and right, you will find absolutely positioned sidebars. + Each uses a different technique for its background color. There is a + little summary in each sidebar about its attributes.
+ +All of the content on this page except the #leftbox + and the #header falls within a div called + #container. This pad, er, box I'm in is here mostly + so I have somewhere to sit and talk. Below you will find the rest of + the layout, two floated columns and another div that all fit nicely + between the sidebars.
+ + + +Known Problems
+ +Good Things
+ +The footer for this page is currently within the + #container div. Although this layout doesn't have one, + a full width footer can be added. Just put another div after the close + of the #container div and style it however you + choose!
+ +You'll find the technical details of this + layout on the previous page. All + the CSS is in the head of + each document, where you will hopefully find some helpful comments + as well.
+ +So folks, that's about all. I hope you have + enjoyed your visit and that the information and techniques you + found here are useful to you.
+ +Ribbet!
+ +
+and many other big sites. +All browsers have CSS bugs, and IE leads the pack in this area, but that is not the end of the story. +Microsoft has seen fit to engineer their browser to deliberately violate the standards in several +critical ways. It might just be a mis-guided attempt to "make it simple" for newbie coders, or it might be +a cynical ploy to crush the competition, but in any case it creates huge headaches for those of us who +desire to employ CSS positioning on our pages. +
+ ++Some of these articles were written for publication at +Communitymx.com. +The CMX partner agreement prevents us from publishing them +here, so those CMX articles are linked from this page. +
+ ++Community MX is a subscription site with a mix of free and for-pay articles, but +it is not necessary to subscribe in order to read all these articles. +
+ ++That's right, CMX offers a +free 10 day trial, +during which time you may read all of the +CMX published articles without paying a cent, and no strings +attached. But beware! CMX has been known to be +extremely habit forming! It is entirely possible that you will find yourself +unable to live without CMX, once you see all it has to offer +a web developer. We're sneaky that way. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: October 26, 2005
+Created May 1, 2004
+
+I'm Big John, and here I attempt to describe and demonstrate some of the bugs found in web browsers, and to +show advanced CSS methods that work across all browsers. +
+ +Big John does webinars on CSS!
++ +Big John on CSS: Explaining the Cascade
+Do you know...
+If you answered "No" to most of these questions, then this webinar is for you.
+ ++ +Big John on CSS: Dealing with IE6 - Parts 1 and 2
+Yes, Big John finally vents his spleen all over IE6, and you are the beneficiary. +There's so much to cover that it's in two parts, oy...
++Do you want to know why our simple CSS positioning system ends up becoming so very frustrating +to so many unsuspecting coders? Go to this collection of articles and demos +showing some of the major problems and ways to get around them. +Warning: Barf Alert! +
+ ++A number of in-depth articles, with the emphasis on readability. +We have tried hard to make complex subjects clear, and we hope you agree. +
+ ++Contrary to widespread belief, I can't do it all! Here, other coders try their hand +at demoization. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: 31 May, 2011
+Created May 5, 2002
+
+
+
++The source code for each demo usually has all the relevant CSS embedded in the head section. +Please feel free to take, use, and if need be, abuse all code found on this site. +
+ ++Mike Papageorge, of Masadelante.com, a volunteer sponsor +of this bug site (and a really cool biker dude too). Diseño Web España +(Web Design of Spain) offers full hosting and web design services for those +who want the best. (for English, click button in upper right) They have +hosted PIE for lo these many years without flaw. Nice going guys! +
+ +
+Also check out Mike's
+personal and excellent web design resource blog, fiftyfoureleven.com
+
+For custom web applications employing php/mysql coding, I highly recommend:
www.vision.to
+
+Want to see what I do to cure burnout? +Wanderlucky +is the repository for my personal hiking and kayaking trip reports, complete with +photos. Come see the evolution of the next Steinway.. or is it Hemmingbeck...? +
+ + +
+
+
+
+
+
+
+
diff --git a/index-3.html b/index-3.html
new file mode 100755
index 0000000..a5e55f2
--- /dev/null
+++ b/index-3.html
@@ -0,0 +1,44 @@
+
+
+
+
++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++I'm Big John, and here I attempt to describe and demonstrate some of the bugs found in web browsers, and to +show advanced CSS methods that work across all browsers. +
+ +Big John does webinars on CSS!
++ +Big John on CSS: Explaining the Cascade
+Do you know...
+If you answered "No" to most of these questions, then this webinar is for you.
+ ++ +Big John on CSS: Dealing with IE6 - Parts 1 and 2
+Yes, Big John finally vents his spleen all over IE6, and you are the beneficiary. +There's so much to cover that it's in two parts, oy...
++Do you want to know why our simple CSS positioning system ends up becoming so very frustrating +to so many unsuspecting coders? Go to this collection of articles and demos +showing some of the major problems and ways to get around them. +Warning: Barf Alert! +
+ ++A number of in-depth articles, with the emphasis on readability. +We have tried hard to make complex subjects clear, and we hope you agree. +
+ ++Contrary to widespread belief, I can't do it all! Here, other coders try their hand +at demoization. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: 31 May, 2011
+Created May 5, 2002
+
+
+
++The source code for each demo usually has all the relevant CSS embedded in the head section. +Please feel free to take, use, and if need be, abuse all code found on this site. +
+ ++Mike Papageorge, of Masadelante.com, a volunteer sponsor +of this bug site (and a really cool biker dude too). Diseño Web España +(Web Design of Spain) offers full hosting and web design services for those +who want the best. (for English, click button in upper right) They have +hosted PIE for lo these many years without flaw. Nice going guys! +
+ +
+Also check out Mike's
+personal and excellent web design resource blog, fiftyfoureleven.com
+
+For custom web applications employing php/mysql coding, I highly recommend:
www.vision.to
+
+Want to see what I do to cure burnout? +Wanderlucky +is the repository for my personal hiking and kayaking trip reports, complete with +photos. Come see the evolution of the next Steinway.. or is it Hemmingbeck...? +
+ + +
+
+
+
+
+
+
+
diff --git a/op-omnibus.html b/op-omnibus.html
new file mode 100755
index 0000000..0c7b542
--- /dev/null
+++ b/op-omnibus.html
@@ -0,0 +1,112 @@
+
+
+
+
+
+
+
+
++These CSS bugs are all exclusive to Opera. +To see the demos properly, they must be viewed in Opera, naturally. +Download the browser? +
++The bugs are only or mostly in Opera 6 and earlier versions. Opera 7 (released Jan '03) +has fixed most of these bugs, and is a much better browser than before. +
++I am always looking to improve these demos, so if you know of anything useful, +lay it on me. Please don't hold back; I have yet to write a demo that did not need +corrections, updates and whatever. This site is really a group effort. Be part of that group. :-) +
+ ++Special Note: Back in September of 2002, + Al Sparber suggested on the +css-discuss + list that maybe I was concentrating on IE bugs too much. +
++I admit to being a bit miffed at the +time, but upon further reflection I have come to realize he's right. The browser engineers +can't fix bugs if those bugs remain unknown. This Opera bug collection is the direct result. +
++Thanks for that kick in the pants, Al. +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: May11, 2003
+Created October 16, 2002
+
+Return to Opera Omnibus
+Next Opera demo
+
+First, using Op6 scroll down and look at the very bottom of the page. +(bet you saw that coming) +
+
+About that purple bar;
It is the background color on the html
+element.
+The red groove is the bottom border of that same element.
+This big gold bordered box is
+div#mask, which encloses all of the page contents.
+
+However, div#mask has no bottom margin, +nor does "html', or even 'body'. (!) +
++So where exactly is that apparent margin at the bottom of 'html' coming from? Good question. +
++The answer is: From the 'Bottomgap Bug' header at the top of the page! +
++Would I lie? Certainly not. At least not in print. +
+
+The setup
+The gold box, div#mask, is the only child of 'body'.
+This div is static, and encloses six absolute elements.
+The four columns, the title header div, and
+the Omnibus links in the upper right corner. BTW, that link element, being first,
+fixes another Op6 margining bug. (see the code for details)
+
+div#mask, being non-positioned, has no effect on the AP divs. I just placed them within +div#mask to reinforce the point of the demo. +
+
+So how does it work?
+This grabby bug likes to steal a bottom margin from the absolutely positioned
+element having the highest 'z-index', which is the last AP element in the document tree (unless overriden
+by using 'z-index'),
+and apply it to the bottom of that tree's root element. (html)
+
+I kid you not. +
+
+But there's more...
+Should the 'highest' AP element contain other elements, even static ones, Opera apparently
+considers them 'higher' than their AP parent. The bug will then ignore the AP 'wrapper' and go for the
+last child within that wrapper. If that last nested element has it's own children, the bug continues inward,
+looking for that 'highest' element.
+
+But, only if the intended victim posesses a bottom margin, will the snatch occur. +
++div#header, appears last in the code. (ain't I tricky?) +
++By the way, Opera 7 does not show this bug. Very nice. +
++Fixes: Just be aware of the bug behavior, and withhold any yummy margin +snacks from the bug's 'preferred victim'. Or place a dummy AP element (no bottom margin) +and give it the highest z-index on the page. +
++That red html bottom border proves 'absolutely' that it is the root element itself that is aquiring +the wandering margin. Thanks to John Lewis +of the css-discuss list, +who clued me in on this. + +
+
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: February 26, 2003
+Created October 16, 2002
+
+Return to Opera Omnibus
+Next Opera demo
+Return to PIE
+
+Here is a real weirdie. This Opera bug (seen in all 7.x versions, except 7.0) +involves a container (positioned, floated or whatever), given a fixed 'height' +(either pixels or EM's). Inside it is nested a second box that has a percentage based +height. The specs say this box should base its height on the content area of its +parent container, But Op7 isn't doing that. +
++Take a look at the demos below. Each demo container box (green BG) has 50px 'height' and 'width', and each has a +nested inner box. The only differences are in the amount of borders or padding on the outer boxes. +Note: The inner boxes are specified to have 'heights' of 100%, and have blue +backgrounds. +
+ + ++Close inspection reveals that Op7 is painting the borders and padding around the outside +of the container's stated dimensions, as required in the specs, but seems to be calculating +the inner box height as tho the old IE5.x box model were in effect! In other words, the +100% height of the inner box is squeezed down more and more as borders and padding +are added to the outer box. This, while correctly keeping the outer box according to the +specs. Hoo boy. +
++Screenshots: +Op7.1, +Op6, +Op7.0, Mozilla1 and IE6 +
+ ++I find it interesting that while Op6 handles this demo badly, Op7.0 did not show the bug, looking +just like Mozilla and IE6. Even IE5.5/win gets it close, except for the box model problem. +I'm assuming IE5/mac also gets it right. +It's been a while since this bug appeared, and as of Opera 7.54 the bug still has not been fixed. +
++If the inner box is given 'overflow: hidden' the text content that extends below the blue area disappears, +proving it is the box itself, and not just the BG that is affected. Also, the horizontal direction seems not to +be involved, only the heights. +
++If the outer box is given no 'height' (or a % height) it is correct and agrees with Moz. +The demos below have no specified height on the outer boxes. (this set badly breaks Op6) +
+ + ++The Nested Box Bug had a pretty long run, but Opera has finally vanquished it in +the official release of Opera 8.0, and considering that the bug still existed in +the Op8 beta version, there must have been some interesting action over there! +
+ ++Kudos once more to Thomas (AKA "Tomcat76" on the Opera Support Forums), +who makes a point of informing us when Opera fixes a bug we have demoed here on PIE. +Opera seems to be about as fast at bug fixing as Mozilla, which goes to show that +a private company can keep up with Open Source if they really want to. Are you +listening, Bill? +
+ ++For those who need to support Op7, a solution to this issue is now available, +courtesy of Simon Carney: +
+ + +The fix is quite simple really. No hacks or extra containers to tie everything together, just a +different way of specifying how a browser can calculate the height of a given container. We'll be using +the height sub-properties min-height and max-height on the container +box, and we'll set the height of the nested box to implicitly inherit the height of its parent.
The first step is to fix the height of the nested box. Since height: 100% is +causing the inner box to shrink as the margins and padding increase, we need an absolute height value +rather than a relative one. Setting the height with height: inherit fixes this +somewhat, but the same bug now causes the nested box to inherit the total height of its parent, including +unfortunately the margins and padding. Mozilla on the other hand, correctly inherits only the true +height, and looks fine.
+ + +This is where the min-height and max-height properties come in. By changing the container's height +property to min-height we can specify a minimum height for the container, meaning it could get taller +if needed. We also set the nested box's height with min-height: inherit. This +allows both it and the container to expand as content fills it. Take a look:
+ + +If we need to constrain the height of the container for any reason we simply include a max-height +property to compliment the min-height on the container and add a max-height: inherit +property to the nested box. For Opera 7.1+ this should now should be equivalent to a simple height property. +While the height property induces the bug, the combination of equal min-height and max-height does not. +Go figure.
+ + +Notice how constraining the box height like this causes Opera and Mozilla to overflow the excess +text in the second demo box above. IE/Win wrongly enlarges the box to keep the content enclosed, so +always keep this fact in mind.
Finally, we need to keep this fix as cross browser compatible as possible. Since IE5.x/Win +and IE5/Mac do not support the min-height and max-height properties, we still need to +keep the original height rules in the CSS for them to use. By serving our new min/max-height rules +to Opera with child selectors that Explorer does not recognize and wrapping all this in the Mac hiding +hack, we keep our original CSS intact and override only those properties that Opera is rendering +incorrectly. While we're feeding non-IE browsers the new properties, we also need to reset the height +value on the container to "auto", since min-height does not replace height.
+
+/* hides from IE-Mac \*/
+*>.minimum-height-fix {
+ min-height: 50px;
+ height: auto;
+}
+/* End IE-Mac hide */
+
+.minmax-height {
+ min-height: 50px;
+ max-height: 50px;
+}
+
+
+The upper and lower comments keep IE/Mac from looking inbetween and obeying those rules within, and +the child hack in front of the selector, "*>.minimum-height-fix", prevents IE/Win from seeing the rule +as well. The second rule does the same thing as a mere 50px height, but does not trigger the Opera bug.
+Simon Carney
November 11, 2004
+Thanks Simon! :-) +
+ +
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: May 7, 2005
+Created May 11, 2003
+
+
It’s a sad day. Finding a bug in your favourite +browser, Opera. But, on the other hand, I did run into IE and Mozilla +bugs on the quest for a fix, so Opera is not alone. It looks like this +bug currently only affects Opera 7.1 and 7.11, the last two versions, and will probably be fixed by 7.12, but anyway: On to the bugs!
+ +
+
+Take a look at the box on the left called "Opera 7.11 +Screen Shot". You can see two different demonstrations: the one on the +left, which is buggy in Opera, has a gap between .outer (white with a black border) and .footer (light brown). The second, on the right, is exactly the same, except with no gap. (Go to final Fix) Below that is an HTML version, showing you how your browser renders the same code.
+ +.inner {
+ margin: 12px;
+}
+
+.outer {
+ padding: 0px;
+ border: 1px solid #000;
+}
+
+
+<div class="outer"> + <div class="inner"></div> +</div> +<div class="footer"></div>+ +
You should notice that the gap between .footer and .outer in Opera is the same as the margin between .inner and .outer. It turns out that the separation between .footer and .outer is the largest of these values: the margin-top of .footer, the margin-bottom of .outer and the margin-bottom of .inner.
+This bug only occurs if .outer +has a border-bottom, so naturally removing that will "fix" the problem. +A second solution is to replace the margin with the more reliable +property: padding. See the first fix for an example.
+.inner represents the last "position: relative" child of .outer, previous children, absolute or relative, have no effect. Using this knowledge, we get fix number two. We can add a last child.
+Remember here that as a logical result of the above, if there was a box inside .inner with a margin-bottom, it will affect the margin-bottom of .inner, which in turn will affect the margin-bottom of .outer, finally affecting the position of .footer!
+This can show itself in a list for example:
+ +
+
+<ul> +<li>One</li> +<li>Two</li> +</ul> +<div>Text</div>+ +
ul {
+ border: 1px solid black;
+ margin: 0;
+ padding: 0;
+}
+
+li { margin: 1em 0em 1em 2em; }
+
+div { margin: 0; padding: 0; }
+
+Our first fix is the most obvious: +remove the margin causing the bug. Easily said, easily done provided +you can target the last child, here: .inner.
+ /* old margin-bottom: 12px; */
+.inner { margin-bottom: 0px; }
+ /* old padding-bottom: 0px; */
+.outer { padding-bottom: 12px; }
+
+My first though on a fix for this bug without having to target the last child was the following code:
+.outer:after {
+ content: ' ';
+ line-height: 0px;
+ font-size: 0px;
+ }
+ Looks +good. Fully CSS, not dependant on other CSS in the web page, and: it +works. In Opera. Mozilla will render as “ ”, but no +problem: the line-height and font-size hide it anyway. Just, don’t +resize the window. Then, Mozilla 1.1 decides to reflow the page, and +effectively make the margin-bottom of .inner +0px. Oops. It might work in other versions, but, who knows anyway? It +isn't reliable enough, it could have similar problems in other +browsers, so taking the same general idea (add a child) we get version +B.
++ If you don’t mind polluting your HTML, you could always do this:
+.inner {
+ margin: 12px;
+}
+
+.outer {
+ padding: 0px;
+ border: 1px solid #000;
+}
+
+.flatrichard {
+ height: 0px;
+ margin: 0px;
+ padding: 0px;
+}
+
+ <div class="outer"> + <div class="inner"></div> +</div> +<div class="flatrichard"></div> +<div class="footer"></div>+ +
The last fix I’m going to give you is what I like to call an embracive fix. I said that the separation between .outer and .footer was "the largest of these values: the margin-top of .footer, the margin-bottom of .outer and the margin-bottom of .inner." This means that we can simulate the bug in other browsers by adding a margin-bottom to .outer, and then remove it using a negative margin-top on .footer. The biggest benifit of this, is that we do not have to target the last child, we only have to know its margin-bottom.
+So, we can standardise the display with:
+.outer {
+ margin-bottom: 12px;
+}
+And then fix it in all of them with:
+.footer {
+ margin-top: -12px;
+}
+
+This is a good fix for our list box example:
+<ul> +<li>One</li> +<li>One</li> +</ul> +<div>Text</div>+ +
ul {
+ border: 1px solid black;
+ margin-bottom: 1em;
+ padding: 0px;
+}
+
+li { margin: 1em; }
+
+div {
+ margin: 0;
+ padding: 0;
+ margin-top: -1em;
+}
+
+This can be a bit of a ghostly bug, but it is +easy to fix. This page is tested in Opera 7.11, Mozilla 1.1 and IE6 +(quirks and standards modes). If you test more, have comments, want to +buy me a yacht etc, feel free to email me. I’m sure you could come up with other fixes if you need them in any given situation. Good luck!
+ ++Update: The bug seems to be fixed in +Opera 7.5, making this a dead bug, the best kind! +
+ +
+© By Douglas Livingstone. email www
last updated: July 3, 2004
created: June 26, 2003
+ 
++This is a page to show a curious background bug in Opera7. It appears that if a background image +is placed in the body element, and positioned at the bottom of that element either with 'bottom' +or '100%', and the body is longer than the viewport, the BG image is pushed below the bottom +edge of the viewport. This demo page is optimized for a screen at 800x600 pixels, in a 'free' +version of Op7/win2k. Above is an <img> version of the complete image. The html element +has a border to show the bug more clearly. +
++Because the content is slightly longer than the viewport (800x600), the red BG image is partially +below the html element. Were the content longer, the BG image would be far below. +There is also some partial image repeating evident, apparently caused by scrolling. +Reloading cleans the image up, but does not correct the faulty position. +Op6 does not have this difficulty. +
++This bug can be fixed by wrapping the content in a div, and applying the BG image to that +div, rather than the body element. +
++Update: +Yet another bug that has been fixed in Opera 7.5, calling a for a "Woohoo!". +
+ +
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: July 3, 2004
+Created June 21, 2003
+
+(Right Float) +
++Note: Mozilla 1 displays exactly as the specs require. +Opera 7 behaves like Mozilla if the float directions are reversed. +IE would behave like Mozilla if #floatholder (orange box) were given any 'width'. +
+
+Return to Opera Omnibus
+Next Opera demo
+
+This demo shows what happens in Op6 +and Op7 when a long series of floats are forced to wrap against an opposing float. +
++The grey boxes (div.leftfloat) are all left floated, and the green box (div.rightfloat) is right floated. +The orange container (div.floatholder) is a static element, with no specified 'width'. That's really +all there is to it. +
++In Op6, when the advancing line of left floats reaches the green right float, the next line +waits until the right float will no longer interfere, before rendering. +Op7 is better, allowing two lines of floats to properly render before its bug forces the +rest below the green float. +
++If the float directions are reversed, the demo behaves identically in Op6, but Op7 +strangely starts behaving correctly. Weird. +
++Only Opera has this bug. +Mozilla renders +correctly, and even IE will get it right if the container has a specified 'width'. +
+
+"But you said this demo had no width!"
+That's right. So if you choose to view this
+in IE, don't say I didn't warn you.
+
+Update, March 29, 2005: Opera 8.b3 appears +to have finally vanquished +this long lived bug. The demo now appears exactly as does Gecko in that beta Opera +version. Woohoo! +
+ ++Kudos to Thomas (AKA "Tomcat76" on the Opera Support Forums) +for the timely heads up. +
+
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: March 29, 2005
+Created October 16, 2002
+
+Return to Opera Omnibus
+Next Opera demo
+
+I know what you're thinking. "What the heck IS that mess?!" +
++Allow me to explain. All the boxes are flowed elements. +First comes the Upper +green box, which has +been given position: relative, then offset downward, and a bit left. +Next is the blue Container box, +a simple non-shifted element. +Nested within is the yellow box, +also 'relative' and offset upwards and a bit more to the left. +Finally comes the Lower red box, +which follows the blue box, and is likewise offset up, and to the right. +
++This has been done to make all the boxes intersect each other. Why? Well, it's to display +the way Opera 6 handles element components, like borders, backgrounds, and content. +Go ahead, take another look, I dare you. +
++Note: Opera 7 is almost entirely cured of these behaviors, and only has +trouble with the upper green box. (see screenshot) +
++Screenshots: (all Win), +Op6 1st demo, +Op6 2nd demo, +Op6 3rd demo, +Op7 1st demo, +Moz, +IE5.5. Note: IE5.5 displays an odd +bug, triggered by use of negative margining on the second demo. This margin is only for convenient demo +positioning, and does not affect the Opera problem. +
+
+The breakdown--First demo
+Close examination reveals that there are two seperate groups here. At the bottom of the stack is the
+green box, including only the border and background, but not the content.
+Then above it the blue box, the yellow nested box, and the red box, all without their contents.
+
+Above that group is the 'content' group. (hang in there, folks)
+The stacking arrangement is exactly the same as the first group! Specifically,
+(from bottom to top)
+green, blue, yellow, and red. This, by the way, is the default 'z-index' ordering one would expect
+for positioned elements.
+
+Note: The empty space in the blue box is the 'static' position of the yellow +nested box, before the yellow box gets +offset away from that space. This accords with the standards. +
++The second demo is the same, except that the red box has been floated. You can see +how this causes the red border/background to be 'raised' up to the red content. In Op6, floating +appears to be more significant than mere positioning. (?) +
++By the way, Moz and IE correctly stack the boxes, and their contents are not +seperate from those boxes, as in Op6 (aside from some positioning variances). +I've made a few margin alterations to get the demo and the text column to arrange nicely. +These margins have no effect on the demo proper, but in browsers other than Opera, they produce some +minor changes in the layout. Since this demo is meant only for Opera, no further attempt was made to +cater for other browsers. +
++The third demo is also the same as the first, except that the upper and lower elements +have been removed, and the blue container element has been floated. +
+
+"What the.. "
+Have you spotted it yet? If not, look real close at the third demo. What a funny thing!
+When the container is floated, the nested element still keeps its content on top, but its
+border/background actually slips between the border and the background
+of its parent container. What a perversion! Even more interesting, the same effect occurs if the blue
+box is made 'absolute' rather than 'floated'. (hmmmm...)
+
+Conclusions
+I could easily pontificate for hours over this Op6 oddity, but perhaps it's better left to the imagination.
+Besides, Opera7 has eliminated all the problems, except for the upper green box, which is relatively
+offset down over the static blue box. maybe Op8 will be the charm...
+
+Thanks to +Edwardson Tan +and Stephanie Sullivan, +of the css-discuss list, for +editing assistance. +
+
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: February 26, 2003
+Created October 31, 2002
+
+h1 /* Green box */
+{
+ position: relative;
+ top: 3em;
+ left: -1.8em;
+ margin-bottom: 10px;
+}
+
++In this demo: +When the 'relative' element (block or inline), has any bottom margin, and no 'flowed elements' follow +in the code, and no bottom border exists on the grey box, the relative shift bug may (or may +not) occur. +
++The bug can also occur with an absolute container, and who knows, maybe lots of other ways too. +
++This text is not part of the static grey column, but is an external, absolutely positioned +div instead. Any flowed elements following the demo would kill the bug. +
+
+Return to Opera Omnibus
+Next Opera demo
+
+This is a 'scrollable bug', so grab ahold of those scrollbars, (Horizontal too), and
+play around with them.
+Hit refresh/reload to reset the effect. Go ahead; I'll wait.
(may require initial reload to see the bug)
+
+
+Fascinating, ain't it? The green block would normally be near the top of the grey column,
+but it has been given position: relative, then shifted down 3em, and 1.8em to the left.
+
+In any modern browser other than Op6, you see the block in the shifted position. In this demo tho,
+Op6 shows the 'preshifted' block, and most of the 'postshifted' block as well.
+Hmmm...
+
+This bug seems to be timing dependent, because a local copy of it will not show the bug +(except upon screen re-size). +That fact makes this bug most difficult to track down, or even notice at all. It also may be intermittent, +for unknown but possibly timing related reasons. Note: because of the timing +dependency, this bug is very slippery, and may or may not be affected by various +'triggers' or 'fixes'. Frankly, it's confusing as heck. +
++In addition to scrolling, switching to a different window and back +will also 'complete' the shift. Mouse-dragging will reveal the shifted text, but won't clear the 'ghost'. +
++Fixes: Removing the bottom margin from the shifted element sometimes does it, or +placing a bottom border on the container element might do it. A good way is to +place a static or relative element anywhere after it in the code. Any 'flowed' element will do, +even raw text. +
++Because of this, the bug usually inhabits footers. (duh!) +
++I'm sorry I can't be more specific, but this bug is highly variable and difficult to pin down. However, +you will now recognize it when it appears, and a little experimenting will find the way. +
++Note: Opera 7 has corrected this bug. Yay! +
+
+Thanks
+to Edwardson Tan,
+of the css-discuss list, for
+major collaboration in analyzing this bug.
+(first isolated on Tan's 'CSS Hub' page)
+
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: February 26, 2003
+Created October 16, 2002
+
+I am sorry, but this demo uses 'fixed' positioning, and because you are viewing it in Internet Explorer +for windows, you will be unable to see the demo properly, to put it mildly. In other words, move along folks, +nothing to see here. To avoid embarassment I have hidden the demo proper from your browser, +but please come back and view it in a more capable browser, won't you? +Again, I apologize for Micro$oft, altho I don't know why... +
++The tall boxes to the sides are given 'position: fixed;' to make them stay fixed in +relation to the viewport. When the page is scrolled, the colored +positioned divs nested in the fixed boxes +blink out, one by one, from the top down. (use keys or scrollbar to see +the full effect) +
+ ++An element is given 'position: fixed', and inside are some block level elements that are positioned, either +'relative' (brown boxes in left demos), or 'absolute' (blue boxes in right demos). The 'relative' block +elements have 'z-index' values, but the fixed containers do not. Any z-index number on the +inner relative element will trigger the bug, including 'z-index: 0', or even a negative index! +The bug is triggered with the absolute block elements regardless of whether z-index is applied to them +or not. As long as these conditions are met, the bug will occur. +
+ ++The two demos on the left are identical except for differing vertical positions. The two demos on the right +are identical as well, at least as far as the Windowshade Bug is concerned. +
+ ++This long lived (but very obscure) Opera 7-8 bug appears to be similar to the +Op6 Windowshade Bug (see in this site), but is in fact +quite different. True, that bug involves 'fixed' positioning and scrolling, but is triggered by +'overflow: hidden' plus negative margining. In addition, the Op6 Windowshade effect starts on the +bottom of the fixed box and goes up, while this Op7 bug prefers to go down. Finally, this bug seems +to individually delete boxes nested in the fixed box, while the Op6 bug smoothly zips up the height +of the fixed box itself. +
+ ++We have placed colored borders on <html> and <body> to show that there's no funny stuff going +on with those elements. + +
+ ++Another odd bug occurs when the inner boxes are 'absolute' (the right side demos). +In that case, the AP boxes are inititally shown shifted upward, so they appear to +protrude out the top of the fixed container, unless that container +is kept at the top of <body>. If the fixed container instead gets 'top: (some value)', +then its AP children are offset upwards from their correct positions, by double +the distance that the top property pushed down the fixed parent container! +
+ ++This offset will not occur if a given AP child element is given 'top: auto' +(the default), or if the AP element is nested in an additional 'relative' box +which is then nested in the fixed container (demo on the inner right). The bug does +not seem to happen horizontally under any circumstances. +
+ ++However, This offset bug appears to be unrelated to the windowshade effect, because +when "z-index' is added to the fixed boxes the disappearing +act ceases, but the top offset remains. Also, Op6 has a serious +problem with the right hand demo, in that the AP boxes scroll while +the containing box does not. Good thing no one uses Op6 anymore! (we hope) +
+ ++Special Note: +If the 'z-index' is instead removed from that red AP box on the right, the Reverse Windowshade bug +is not fixed as it is with the left (relative) boxes, so with a fixed element that contains AP elements, the +z-index is not actually required to trigger the bug, but it does require that there not be +a z-index on the fixed container. +
+ ++ +For the Reverse Windowshade, just avoid the z-index trigger combo when 'relative' +child elements are concerned by adding a z-index to the fixed parent, or by not having one on the +nested children. When 'absolute' elements are involved, you must set a z-index to the fixed parent. +The Fixed-AP Vertical Offset currently +has no known fix, other than using 'top: auto' or adding an additional 'relative' container. +
+ ++This bug and its primary triggers were discovered by +Holly Bergevin, whilst volunteering time to fix bugs on an advanced css page. +These bugs can't hide if you keep your eyes peeled. :-) +
+ +
+Kudos to Thomas (AKA "Tomcat76" on the Opera Support Forums)
+for helping to update this demo page. Thanks Thomas!
+
+
+Holly 'n John
+
+
+Contact Holly
+Contact John
+©positioniseverything
+Last updated: May 7, 2005
+Created June 9, 2003
+
{
+position:fixed;
+overflow:hidden; /* THE CULPRIT */
+}+This is a div inside the fixed div. This has a negative margin-left which makes +part of it go outside the fixed div. The padding-left is the same positive amount +just so you can read this text. +
+ +{margin-left:-20px; padding-left:20px;}
+
+
+Return to Opera Omnibus
+Return to Guest Demos
+Next Opera demo
+
+This page demonstrates the Opera Windowshade Bug. It occurs with Opera 6 +(not Opera 7), and is caused by the following combination: +
+ +To see the effect, scroll down: the bottom border of the pink block zips up like a window shade!
+ +Note also that Opera does not correctly display the border on the fixed div; + also because of the overflow:hidden property.
+ +
+This demo is the work of
+Tarquin
+email: tarquin (at) planetunreal.com
+Last updated: April 24, 2003
+Created April 24, 2003
+
+Note from Big John:
+Some may notice that the extended blue-bordered box is 'cut off' in Moz and Op7.
+This is because that portion of the box 'overflows' the container! See? a good browser
+watches everything. BTW, IE5.5/6/win breaks this demo, perhaps because the fixed div isn't given
+a specified 'width', poor baby.
+
+
+Notice that Moz cuts of off at the container padding, while Op7 cuts off at the outside border edge!
+However, Op7.1 ends at the padding edge just like Moz. Nice going guys. Notice that Opera
+does not stand still like a certain major browser...
+
+scrolling
content
scrolling
content
scrolling
content
+scrolling
content
scrolling
content
scrolling
content
+scrolling
content
scrolling
content
scrolling
content
+scrolling
content
scrolling
content
scrolling
content
+
+Important new information as of July 2008: +IE bugs discussed in this obsolete document have been found to be associated with +hasLayout. +Knowledge of this MS concept is essential if you want to make IE behave well +with advanced CSS using floats. +Also see this basic method for specific ways to +combat the IE bugs on your pages. +
+ ++So you want a three column layout, and the footer must stay +below the cols no matter which one is longest. Not too tuff, just have a static col, +and two cols floated left and right, then 'clear' the footer. The longest col will always +keep the footer pinned to its bottom edge. +
++However, since the floated cols must precede the static col, the middle static col is always last +in the source code. This is undesirable because if the css is not used (text browsers, etc.), then +the cols don't appear in the correct order. A more accessible way would be to place the cols in the +preferred source order, and then force them into the desired screen order. But how? +
+
+It turns out that with a small amount of extra float trickery we can do just that.
+See those colored columns below?
+
+One One One One One One One One One One One One One One One One One One One
+One One One One One One One One One
+
+Test link
+
+Two Two Two Two Two Two Two
+
+Test link
+
+Three Three Three Three Three Three Three Three Three Three Three
+
+Test link
+
+One One One One One One One One One One
+
+Test link
+
+Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two
+Two Two Two Two Two Two Two Two Two Two Two
+
+Test link
+
+Three Three Three Three Three Three Three Three Three Three Three
+
+Test link
+
+One One One One One One One One
+
+Test link
+
+Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two Two
+
+Test link
+
+Three Three Three Three Three Three Three Three Three Three Three Three Three Three
+Three Three Three Three Three Three Three Three Three Three Three Three Three Three
+
+Test link
+
+If you sneak a peek at the source, you will see that the cols are in the same order as they are on screen. +That is, the left col is first and the right col is last. The three column-groups are identical except +for differing amounts of text. Observe how the footers always stay pegged on the bottom of the +longest col. +
++The ordering is achieved by wrapping a left-floated box around the first and second cols in the source. +(blue and green), and left-floating the first col (blue) within that invisible floating wrapper. +
++Get it? The wrapper is floated, so in the source it comes first, (as a float must), +and inside it the floated first col +also comes first, becoming the first col to appear in the source. The other col in the wrapper +(green center col) is next, and the right col (red) following the wrapper, comes last. +
++There's no reason the first col must be floated left, or the wrapper for that matter. +By making the float direction on the first col 'right' instead of 'left' (along with its associated margin value +on .second-col), +we can put .first-col into the center position, with .second-col on its left and .third-col on the right, +something highly desirable I'm told. +
+ +
+One One One One One One One One One One One One One One One One One One One One
+Test link
+
+Two Two Two Two Two Two Two
+Test link
+
+Three Three Three Three Three Three
+Test link
+
+ Minimal HTML for the '2 1 3' demo above:
+
+<h2>Header</h2>
+
+ <div class="float-wrapper">
+
+ <div class="first-col">
+ <p>One One One One One One One One One</p>
+ </div>
+
+ <div class="second-col">
+ <p>Two Two Two Two Two Two</p>
+ </div>
+
+ </div>
+
+ <div class="third-col">
+<p>Three Three Three Three Three</p>
+ </div>
+
+<p class="clearfooter">Clearing Footer</p>
+
+
+ The CSS:
+
+.float-wrapper {float: left; width: 66%;}
+ /*** This can be floated left or right ***/
+
+.first-col {float: right; width: 50%;}
+ /*** This can be floated left or right ***/
+
+.second-col {margin-right: 50%;}
+ /*** This gets margined the same direction
+ as div.first-col gets floated ***/
+
+.third-col {margin-left: 66%;}
+ /*** This gets margined the same direction
+ as div.float-wrapper gets floated ***/
+
+.clearfooter {clear: both;}
+
+ p {padding: 10px;}
+
+
++By selecting the direction to float .first-col, you can choose either the first or second +column to place in the center screen position. Further, if .float-wrapper is reversed as well, +the column screen order can be 3, 2, 1, or 3, 1, 2. +
++If you want to vary the 'widths' +of the cols, remember that the non-floated 2nd and 3rd cols get margins with a length equal +to the width on the associated float. (see code above) +
++The paragraphs are not there just to be accessible. It's also because using margin, borders, or padding +on the column elements themselves is 'difficult'. Don't let me stop you tho, knock yerself out. +But, know that doing so will lead into a morass of browser variances, bugs, and to top it all, +the IE box model. +I'm talking Hack City, folks. Go there only with eyes wide open. Otherwise, use nested +<p>'s (or whatever) to hold and style the col contents. +
++Padding, borders, and horizontal margins may be safely placed on the <p>'s, but vertical +margins will show some variance +between browsers, and will require hacking in order to be (semi)consistent. Op6 is the only major +Windows browser that gets these vertical margins completely correct. Op7/beta does not. +
++IE6 will display very buggily if these demos are given backgrounds (green BG's), unless +'position: relative' is applied to certain elements. See the source for details on these hacks. +Also, Mozilla and N6/7 will sometimes show a 1px gap between the 2nd and 3rd cols in the +first two demos, due to 'rounding errors'. The width/margin values on these cols have been tweaked +to eliminate the gaps at the main resolutions, but will still show at intermediate screen widths. +For more detail, check out this demo. +
++This layout involves floats, and oversize floats will 'wrap' underneath, shattering the layout. +Should there be content in a col that is too wide to fit, the results are 'unpleasant', to say the least. +Opera, and 'Gecko' based browsers (N6/7, etc.) will just make the wide content overlap whatever +is to the right. Not so in IE. (It figures) +
+ ++IE/win has the unhappy habit of 'enlarging' any container that has such oversize content. Normally +that behavior is just irritating, but in this case, enlarging the cols can result in float wrapping, +wreaking havoc on what used to be a 3-col layout. IE5/mac also breaks, in a different yet strangely +similar manner. Be very careful about including +content other than text. Long web addresses often cause this sort of problem, because they +don't have spaces that allow text wrapping. +
++If you implement this layout, you may notice (in IE) a strange little flaw in the left-justification +of text in one or two spots. As the left edge of the text block runs down the col, it will suddenly +'jog' to the left slightly, producing an unsightly "disturbance in the font". I have a demo prepared that +explains this in more detail. +In essence, a non-floated element following a float may show the jog. +
++This jog may be easily squelched by applying 'width: 100%' to the 2nd and 3rd cols (but with no margins). +IE makes these static cols fill the available space next to their respective floats, but without +the jog. +
+
+Unfortunately,
+this behavior totally violates the W3C specifications concerning float behavior, so using this method
+will totally break any other browser that tries to parse it. I have yet another demo
+explaining said IE misbehavior.
+
(This IE stuff is getting really tiresome)
+
+Heck no! +Luckily there is a way to prevent these proprietary IE behaviors. Simply make all the cols into floats. +Boy, that was easy! Okay okay, so it isn't that easy, but it is doable. +
++Since floats induce the 3px jog, but don't themselves show the jog, an all-float column layout avoids +the whole problem. The idea is to float the 1st and 2nd cols opposite each other, keeping them + in the floated wrapper, and also floating the 3rd col opposite the wrapper. If all the elements +are floated, there are no 'static' cols that must come last, so any col may appear in any screen +position. Total control. +
++This control comes at a price, however. Floats must have 'widths', unlike the static cols. +If the elements are all given percentage widths, as in the +demos above, some browsers may wrap anyway, even tho they shouldn't. +The above mentioned rendering error +associated with percentages (and EM's), may make an element 1px too wide, causing a wrap. +
+ ++So the col widths must be fudged downwards (to prevent wrapping), which causes smallish gaps +between the cols. If the cols have no backgrounds, the gaps won't be noticable and the 3px jog will +be gone. Could be a keeper. +
++Note: I also added side borders and margins to this demo (.demo-allfloat), +just because I could (but see note below for IE5.5 caution with borders and margins). +
+
+One One One One One One One One One One
+One One One One One One One One One One One One One One
+Test link
+
+Two Two Two Two Two Two
+Test link
+
+Three Three Three Three Three
+Test link
+
+ Minimal HTML for the 'all-float' demo above:
+
+<h2>Header</h2>
+
+ <div class="float-wrapper">
+
+ <div class="first-float">
+ <p>One One One One One One One One One</p>
+ </div>
+
+ <div class="second-float">
+ <p>Two Two Two Two Two Two</p>
+ </div>
+
+ </div>
+
+ <div class="third-float">
+<p>Three Three Three Three Three</p>
+ </div>
+
+<p class="clearfooter">Clearing Footer</p>
+
+
+ The CSS:
+
+.float-wrapper {float: left; width: 66%;}
+ /*** This can be floated left or right ***/
+
+.first-float {float: right; width: 49%;}
+ /*** This must be floated opposite
+ to .second-float ***/
+
+.second-float {float: left; width: 49%;}
+ /*** This must be floated opposite
+ to .first-float ***/
+
+.third-float {float: right; width: 33%;}
+ /*** This must be floated opposite
+ to .float-wrap ***/
+
+.clearfooter {clear: both;}
+
+ p {padding: 10px;}
+
+
++If you happen to want the 3rd col in the center screen position, just make the wrapper enclose +the 2nd and 3rd cols, rather than the 1st and 2nd. Then the proper float directions will +easily center the 3rd col. +
++This all-float layout requires two bug fixes to cater for IE. First, in order not to be buggy, +IE6/win needs 'position: relative' applied to the demo. This induces more buggyness +that must be fixed by giving 'position: relative' +to both the wrapper, and to the third floated col as well. (see source) +
++The second is that IE5.x/win will break, due to its +habit of considering a default width of 'auto' to mean "the viewport width". It is fixed by applying +'width: 100%' to the demo, but beware! IE6 will break upon seeing this, so the '100%' must only +be seen by IE5.x/win. This is done by use of a hack (see source). If the side borders and margins +are avoided, then this hack is not needed. +
+ ++Since the layout uses bi-directional nested floats, caution should be taken when adding further +floats or positioned elements, lest you summon up some hideous Überbug. Test, test, and test again. +
++Well alright then! The fact is that making this layout 'rigid' eliminates the small gaps seen in the +last example. Also, I have altered the column 'width' values in the layout, again just because I could. +Take a look. +
+
+One One One One One One One One One One One One One
+One One One One One One One One One One One One
+One One One One One One One One One One One One
+
+Test link
+
+Two Two Two Two Two
+
+Test link
+
+Three Three Three Three Three Three Three Three Three Three
+Three Three Three Three Three Three Three Three Three Three
+Three
+
+Test link
+
+Minimal HTML for the 'rigid-all-float' demo above:
+
+ <div class="rigid">
+
+<h2>Header</h2>
+
+ <div class="float-wrapper-rigid">
+
+ <div class="first-float-rigid">
+ <p>One One One One One One One One One</p>
+ </div>
+
+ <div class="second-float-rigid">
+ <p>Two Two Two Two Two Two</p>
+ </div>
+
+ </div>
+
+ <div class="third-float-rigid">
+<p>Three Three Three Three Three</p>
+ </div>
+
+<p class="clearfooter>Clearing Footer</p>
+
+ </div>
+
+
+ The CSS:
+
+.rigid {width: 600px; margin: 0 auto;}
+
+.float-wrapper-rigid {float: left; width: 450px;}
+ /*** This can be floated left or right ***/
+
+.first-float-rigid {float: right; width: 300px;}
+ /*** This must be floated opposite
+ to .second-float ***/
+
+.second-float-rigid {float: left; width: 150px;}
+ /*** This must be floated opposite
+ to .first-float ***/
+
+.third-float-rigid {float: right; width: 150px;}
+ /*** This must be floated opposite
+ to .float-wrap ***/
+
+.clearfooter {clear: both;}
+
+ p {padding: 10px;}
+
+
++IE5.5 and IE6 can be buggy with the above 'width-defined' layout, if the cleared footer is given +a background. Even 'transparent' or 'inherit' applied to the cleared element background will induce this bug. +It's fixed by providing a 'line box' after the 3rd col and just before the clearing div. A <p> +will do this, as will a div containing at least one inline element. +
++However, this rigid layout does NOT suffer from the IE 'demo background' bug mentioned before, +so you can have a BG on this layout without hacking for IE6, thanks to the 'width' on the demo. +
+
+The 'auto' side margins on div.rigid will center the demo in 'standards compliant' browsers,
+but IE5.x/win does not obey these, so I have employed a 'text-align' hack to force that
+browser to center the demo. That same browser has the infamous 'box model problem',
+so the decorative side borders I placed on the demo would have caused a col-wrap (in IE5.x/win),
+were in not for the box model hack I used to prevent this.
+(see the source for details on these hacks)
+
+ +Are you getting as tired of 'that browser' as I am? It's the new 'Nav4', people. +
++I suppose some will wonder if these 3-col methods will work in Nav4. The answer +is 'more or less'. I have prepared a +separate demo +that does work in +Nav4, as long as one doesn't expect too much. +
++I tried hard to make Nav4 work acceptably, but failed. A percentage sized layout will indeed 'work', +but there are puzzling horizontal openings between the cols that appear at semi-random screen sizes. +I believe Nav4 can only render the 'width' of percentage based floats in large 'steps'. That is, when the screen size is +incrementally reduced, the gap(s) get smaller and smaller, 'til contact triggers a jump to the next smaller +box size. More than one box is involved, so both inter-col areas can show gaps. +
++Naturally, attempting to size cols under these conditions is dicey at best. The cols are indeed in the correct +order, and at roughly the same height, but the 'gaps' can only be eliminated at a selected screen size, +or two if you're lucky. +
++A pixel sized layout has its own re-sizing problems, because when the screen is reduced, a scrollbar +is not created; rather it's the third col that is 'squeezed' until it's down to one 'word' wide, when finally +a horizontal scrollbar makes its appearance, a little too late. +
+ ++If you must cater to Nav4, use the percentage method, and live with the variable gaps. Remember +that the values that work in Nav4 will not work in other browsers, and will require hacking to +achieve similar results. +
++Many site designers would like to have three source ordered columns, and have the two side cols +be of a fixed width while allowing the center col to fluidly fill the remaining screen space. Sadly, +this just isn't possible. +
++The problem is that the center col must be a float (as well as the float wrapper), and floats must +have a stated "width". The only length unit that is not fixed is "percentage", but if the center col is +given a certain percentage width, then whatever space is left in that float's container must also be a +percentage. It's currently impossible to mix two boxes with percentage and fixed widths in a single container. +At least it's not if you need to fill the screen cleanly at all resolutions. +
++Perhaps someday it will be possible to give a float a width that is 100% of its container, minus a +fixed amount, but today is not that day. If you must have these fixed side cols and fluid center col, +you must stick with simple left and right floated side cols and live with the lack of an ordered source. +
+
+This demo has the honor of moving into obsolescence even before being released! (I'm so proud)
+There are already some code variations on the ordered cols theme over at
+Alex Robinson's Site.
+Now go over there, and try to poke holes in his layouts. Alex would want you to. (I'm on my way...)
+
+If you write a cool new version of this layout concept (like Alex), and feel it should also be linked here, +please contact me, okay? :-) +
++Please be aware that the layouts detailed on this page are fairly new, and have not been extensively +tested with the many variations that could be applied within them. I'm quite certain that +problems will arise when this happens, and would caution a 'go slow' approach. Start with +the basic layout and add stuff to it, watching for bugs as you go. +
+
+Don't be suprised if you just take
+an existing 3-col layout, transfer it to this one, and get hit with a
+Mystery Bug.
+(notice I didn't say ".. an IE Mystery Bug", 'cause I just can't be sure...)
+
+The Ordered Cols method may be extended to more than three columns, +by adding a second floated wrapper, and wrapping the 3rd and 4th cols inside it. +So it would appear thus: [{1 2} {3 4}], +or some similar arrangement. Have fun! +
++The source ordered three column techniques detailed here seem to be robust in standards +compliant browsers, and as soon +as lesser browsers are consigned to the porcelain bowl of history I expect these methods to be +widely adopted across the Web. +
++I know what you're thinking: "That Big John is sooo talented!" Well, that is true, but this page +is largely the hard work (freely given) of many other people from the +css-discuss list, +including (but not limited to) +Scott Sauyet, +Douglas Livingstone, +Victor Caston, +Alex Robinson, +Mike Papageorge, +and Holly Bergevin. There's some wicked synergy in that e-list. +
+
+Special thanks to
+Holly Bergevin,
+who convinced me to take time to create this demo, collaborated mightly on it, and displays a
+talent for bug squashing, too. : )
+
+Important new information as of July 2008: +IE bugs discussed in this obsolete document have been found to be associated with +hasLayout. +Knowledge of this MS concept is essential if you want to make IE behave well +with advanced CSS using floats. +Also see this basic method for specific ways to +combat the IE bugs on your pages. +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 3, 2008
+Created Groundhog Day (Feb 2nd), 2003
+
+ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ ++Piefecta +Return to p.i.e. +
++Important new information as of July 2008: +IE bugs discussed in this obsolete document have been found to be associated with +hasLayout. +Knowledge of this MS concept is essential if you want to make IE behave well +with advanced CSS using floats. +Also see this basic method for specific ways to +combat the IE bugs on your pages. +
+ ++This column is first in the source, being a right float within a left-floated wrapper. The second col +is floated left in that same wrapper, and following the wrapper is the left floated right col. +
+ ++The headings and italicized paragraphs are "widthless" and have 1px red borders to show any width problems +in the columns. +
+ +
+
++Mucho thanks to +Douglas Livingstone, +who developed the brilliant +Negative margined floats +method at the heart of this design. Thanks, Douglas! Next step is to add a "sticky footer" as shown by +Paul O'Brian. +
+ ++The Master of the Mac, Philippe Wittenbergh, +came thru with crucial Mac fixes, as usual, along with +Tedd Sperling on cleanup detail. +Bruno Fassino's work on the text fixes for IE +came along at just the right time. This layout is +truly the result of the efforts of many coders over a long period. Thanks people. +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 4, 2008
+Created Feburary 19, 2004
+
+This column is floated and also negatively margined to the left, so it is "pulled" out of its +container except for a single pixel that is kept within the container. +
+ ++Italics can be justified as long as the paragraph gets the proper IE bug fixing, as described in the center col. +This rigid layout makes such pixel control easy. +
+ ++Tweaking the cols can be very confusing due the interlocked nature of the layout, but colored backgrounds +on all divs can greatly help this process. Using borders to mark the divs will make them wider and cause float dropping. +
+ ++This column is floated, and then negatively margined to the right, pulling it nearly outside its container just like the left column. +
+ ++Italics can be justified as long as the paragraph gets the proper IE bug fixing, as described in the center col. +This rigid layout makes such pixel control easy. +
+ + + +Ribbet!
+ ++Here is an "absolute" box, which stays at the col bottom. +
++AP again. The side cols have bottom padding to avoid these boxes. +
++Piefecta +Return to p.i.e. +
++Important new information as of July 2008: +IE bugs discussed in this obsolete document have been found to be associated with +hasLayout. +Knowledge of this MS concept is essential if you want to make IE behave well +with advanced CSS using floats. +Also see this basic method for specific ways to +combat the IE bugs on your pages. +
+ ++This column is first in the source, being a right float within a left-floated wrapper. The second col +is floated left in that same wrapper, and following the wrapper is the left floated right col. +
+ ++The headings and italicized paragraphs are "widthless" and have 1px red borders to show any width problems +in the columns. +
+ +
+
++Mucho thanks to +Douglas Livingstone, +who developed the brilliant +Negative margined floats +method at the heart of this design. Thanks, Douglas! Next step is to add a "sticky footer" as shown by +Paul O'Brian. +
+ ++The Master of the Mac, Philippe Wittenbergh, +came thru with crucial Mac fixes, as usual, along with +Tedd Sperling on cleanup detail. +Bruno Fassino's work on the text fixes for IE +came along at just the right time. This layout is +truly the result of the efforts of many coders over a long period. Thanks people. +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 4, 2008
+Created Feburary 19, 2004
+
+This column is floated and also negatively margined to the left, so it is "pulled" out of its +container except for a single pixel that is kept within the container. +
+ ++Italics can be justified as long as the paragraph gets the proper IE bug fixing, as described in the center col. +This rigid layout makes such pixel control easy. +
+ + + ++This column is floated, and then negatively margined to the right, pulling it nearly outside its container just like the left column. +
+ ++Italics can be justified as long as the paragraph gets the proper IE bug fixing, as described in the center col. +This rigid layout makes such pixel control easy. +
+ ++The source contains a great deal of commentary on the code used in this layout. It's not for the squeamish, but +even semi-skilled CSS coders will be able to wrangle this design to meet most site requirements. +
+ ++This layout is known to work in: IE5/Win and up, Opera 6-7, Mozilla for both Win and Mac, IE/Mac, Safari, and Omniweb 5. +
+ +Ribbet!
+ ++Here is an "absolute" box, which stays at the col bottom. +
++AP again. The side cols have bottom padding to avoid these boxes. +
++Piefecta +Return to p.i.e. +
++Important new information as of July 2008: +IE bugs discussed in this obsolete document have been found to be associated with +hasLayout. +Knowledge of this MS concept is essential if you want to make IE behave well +with advanced CSS using floats. +Also see this basic method for specific ways to +combat the IE bugs on your pages. +
+ + ++This column is first in the source, being a right float within a left-floated wrapper. The second col +is floated left in that same wrapper, and following the wrapper is the left floated right col. (confusing, ain't it?) +
+ ++The headings and italicized paragraphs are "widthless" and have 1px red borders to show any width problems +in the columns. +
+ +
+
++Any col may be longest without problems, thanks to the fact that all the cols are +floated and "within" a single container. The notorious problems that IE has with +floats are negated because all the cols are floats, leaving no normal elements to +interact with them and induce IE bugs. Woohoo! +
+ ++A number of bug fixes have been used to make this design work well in different browsers, +particularly IE/Win. Most of these can be applied in the stylesheet and forgotten, but several +involve tiny dimensional differences and need to be changed when alterations are desired +for the layout. Detailed instructions on this subject are to be found in the source stylesheet. +
+ ++Italics can be used in this design, but when text is "justified" as well, it seems to make IE pre-calculate +box widths and then calculate the width of the italics after that, forcing the box bigger than the stated +width. In a float layout like this, such stupidity leads to display flaws and even destructive float dropping, +so if these two properties are used in the same paragraph a couple of precautions must be used to avoid +IE text buggery. +
+ ++First, using the Holly hack to exclude all but IE/Win, apply to the paragraph a fairly large negative right margin. +The value can be too small, but apparently can never be too big to cause harm. This layout uses -30px right margin. +Then pixel size the width of the paragraph or other element to the widest width you can without float +dropping at the largest text size in IE. You can determine this width by trial and error in a few minutes. +Study the source to see exactly how it's done. +Remember, if both text properties are used on even one word it may cause trouble unless the fix is used. +
+ ++This design employs a proprietary IE property that forces a spaceless url or word to break +before it cause IE to enlarge the floated box and break the layout. If the CSS must validate, +place the "word-wrap" rule in a "conditional comment" (as in this demo). It's also proprietary, but validatible. +
+ ++Note for IE5/Win: This fix fails in IE5/Win, alas. Also note that use of "word-wrap" in conjunction with justified +text prevents IE5.5 and 6 from lining up the text on the right edge. That property has been set to "normal" +in the italics test boxes to keep the text justified on the right. +
+ ++The W3C has decided to adopt the word-wrap CSS property into the CSS 3 specification. +(the W3C was going to change MS's syntax at first, but someone gave them all "dope-slaps" and they +came to their senses, thankfully) Word-wrap is already supported by Safari 3/Win, +Opera 9, and of course IE. Only Firefox 3 +does not yet support this vital CSS tool. C'mon guys, get with it! +
+ ++Since the W3C has endorsed word-wrap, we are free to use it, even tho it may not +pass the validator for a while. +
+ +
+
++Mucho thanks to +Douglas Livingstone, +who developed the brilliant +Negative margined floats +method at the heart of this design. Thanks, Douglas! Next step is to add a "sticky footer" as shown by +Paul O'Brian. +
+ ++The Master of the Mac, Philippe Wittenbergh, +came thru with crucial Mac fixes, as usual, along with +Tedd Sperling on cleanup detail. +Bruno Fassino's work on the text fixes for IE +came along at just the right time. This layout is +truly the result of the efforts of many coders over a long period. Thanks people. +
+ ++Now, thanks to the hard work of Trevor, aka 'ClevaTreva', you may easily have a +coded version of the Piefecta +layout prepared for you, automagically! This unsung script/css genius has crunched the +incredibly complex rules of this design down into a tool so cool that all primary layout mods are +a "no-brainer". Woohoo! +
+ +
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: September 24, 2009
+Created Feburary 19, 2004
+
+This column is floated and also negatively margined to the left, so it is "pulled" out of its +container except for a single pixel that is kept within the container. +
+ ++Check out these +variant layouts of the Piefecta added Sep/09, +courtesy of John Harrington. +Thanks John! +
+ ++Tweaking the cols can be very confusing due the interlocked nature of the layout, but colored backgrounds +on all divs can greatly help this process. Using borders to mark the divs will make them wider and cause float dropping. +
+ + + ++This column is floated, and then negatively margined to the right, pulling it nearly outside its container just like the left column. +
+ ++Italics can be justified as long as the paragraph gets the proper IE bug fixing, as described in the center col. +This rigid layout makes such pixel control easy. +
+ ++The source contains a great deal of commentary on the code used in this layout. It's not for the squeamish, but +even semi-skilled CSS coders will be able to wrangle this design to meet most site requirements. +
+ ++This layout is known to work in: IE5/Win and up, Opera 6-7, Mozilla for both Win and Mac, IE/Mac, Safari, and Omniweb 5. +
+ + + +Ribbet!
+ ++Here is an "absolute" box, which stays at the col bottom. +
++AP again. The side cols have bottom padding to avoid these boxes. +
++ + + The requested URL was not found on this server. + + + + The link on the + referring + page seems to be wrong or outdated. Please inform the author of + that page + about the error. + + + +
+ +
+
+
+
+
+
+
+
++This one is based entirely on absolute positioning. div#container +(thick brown border) is positioned using 'left' and 'top', and has equal width and height (80px). +It contains two absolute boxes, (black and green borders) and a static div to show the +content area, (grey box) and thus the padding area as well (light blue around grey box). +Note: Without the fixed dimensions on div#container, browser behavior +would vary wildly. See Absolutely Buggy II to view this behavior. +
++The green and black bordered boxes are positioned to opposite corners by applying '0px' +on top/left and bottom/right respectively. They each enclose a small box positioned +the same way. All boxes are dimensioned as squares, and Tan hack (for the IE5.x incorrect box model, +see source) is applied to all the boxes. +
++Below are screenshots of this demo. +
++It is assumed that earlier browsers will have 'difficulties' with this demo. +
++The mighty Gecko engine (Moz, N6/7) renders flawlessly. +IE5/Mac appears identical to Moz. Opera 7 is also correct. +
++IE/Win is close, considering it's IE. But notice those vertically stretched small boxes? +It appears that IE will not allow the 'height' of these absolute boxes to be less than the 'line-height'. +However, this applies only to the big and little boxes. The middle sized boxes will strangely +honor 'height:0px'. +
++However, such a bug will only rarely affect a page. Not so with Opera 6. +
++Please note that in Op6 the black and green bordered +boxes are (as one unit) +exactly the same size as the grey content area. (!) It would seem that Opera is rendering the demo +by first placing the container without any padding or borders. Then the contained absolute boxes +are placed accordingly. Finally, the specified padding and borders are applied to the container box, +which stretches it down and right without affecting those contained boxes. +The same goes for the little boxes. +
++This is a big problem (if you care about Op6). Don't assume you'll correct it with a wrapper div either, +because the bug will infect that div as well. +
++Don't use borders or padding on such a container. If you must, +an absolutely positioned div may be positioned over (or under) the container, +so as to provide 'substitute' borders and padding. +
++Happily, Opera 7 has fixed this problem, and now plays nice with absolute positioning. +Bow thrice in the direction of Norway, please. +
++Those using Op7.1 may notice that the demo is missing its grey content area, supplied by a nested div BG. +This was pointed out to me by +Chris Hester. +See this page for details on a brand new Opera bug! +
++According to reports, the more recent Omniweb versions correctly +display the demo on this page. Way to go, guys! +
++All the modern browsers now handle this demo properly, and IE7 has corrected IE's +"no box shorter than the lineboxes" problem as well, so it too exactly matches the others. +Well, that's one battle won... +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: July 4, 2008
+Created June 2, 2002
+
+When boxes are rendered, and the dimensions of those boxes are defined in 'relative' units +such as percentages or EM's, then the browser must work out how many screen pixels +to assign to the box dimensions. The problem is that these relative units do not always exactly +correspond to a given number of pixels, but all rendered boxes must be sized to an exact +number of pixels. It's clear that a perfect solution is not possible. +
++Still, a solution must be found, so the browsers sometimes 'round off' the internal calculations +in order to arrive at a simple pixel value for box dimensions. However, for complex reasons the +rounding off might occur in the 'wrong' direction and can result in a visible 1 pixel gap (or sometimes a +1 pixel overlap) next to those boxes. In certain situations the effect can occur with a single box as well. +
++The demo above illustrates this effect, having a five-by-five matrix of absolutely positioned, +percentage-sized black boxes, which should join together into a seamless large black box. +If rounding errors occur, they will appear as +thin gaps running horizontally and vertically thru the big box. Because the boxes are sized with +percentages, the window size strongly affects if and where the gaps may appear. +
++If you resize a browser window, you will see different arrangements of gaps in the demo. +Try dragging the window edges to resize the window, so you can see +the horizontal and vertical gaps come and go in real time. Kinda cool. +
++Firefox 3 was released in June of 2008, and it doesn't show +any rounding errors, whatsoever! This is an impressive achievement. +Internet Explorer 8 (released March of 2009) also shows +a clear test field, free of errors. Not too shabby, you guys! +
++IE7 shows the errors at some window widths. Opera 9.64 +and Safari 4/Win both show plenty of errors too. +
++There was a fascinating discussion within the Mozilla engineering group concerning this problem, which you can +tune in to on this page. +I do not claim to understand these guys, but wish I could. +
+
+Big John Design
+
+Contact Us
+©positioniseverything.net
+Last updated: June 20, 2009
+Created March 7, 2003
+
+One One One One One One One One One One
+One One One One One One One One One One One One One One
+Test link
+
+Two Two Two Two Two Two
+Test link
+
+Three Three Three Three Three
+Test link
+
+ Minimal HTML for the 'all-float' demo above:
+
+<h2>Header</h2>
+
+ <div class="float-wrapper">
+
+ <div class="first-float">
+ <p>One One One One One One One One One</p>
+ </div>
+
+ <div class="second-float">
+ <p>Two Two Two Two Two Two</p>
+ </div>
+
+ </div>
+
+ <div class="third-float">
+<p>Three Three Three Three Three</p>
+ </div>
+
+<p class="clearfooter">Clearing Footer</p>
+
+
+ The CSS:
+
+.float-wrapper {float: left; width: 66%;}
+ /*** This can be floated left or right ***/
+
+.first-float {float: right; width: 49%;}
+ /*** This must be floated opposite
+ to .second-float ***/
+
+.second-float {float: left; width: 49%;}
+ /*** This must be floated opposite
+ to .first-float ***/
+
+.third-float {float: right; width: 33%;}
+ /*** This must be floated opposite
+ to .float-wrap ***/
+
+.clearfooter {clear: both;}
+
+ p {padding: 10px;}
+
+
+
+Holly 'n John
+ e-mail
+©positioniseverything
+Last updated: Febuary 3, 2003
+Created Groundhog Day (Feb 2nd), 2003
+
+One One One One One One One One One One One One One One One One One One One One
+Test link
+
+Two Two Two Two Two Two Two
+Test link
+
+Three Three Three Three Three Three
+Test link
+
+ Minimal HTML for the '2 1 3' demo above:
+
+<h2>Header</h2>
+
+ <div class="float-wrapper">
+
+ <div class="first-col">
+ <p>One One One One One One One One One</p>
+ </div>
+
+ <div class="second-col">
+ <p>Two Two Two Two Two Two</p>
+ </div>
+
+ </div>
+
+ <div class="third-col">
+<p>Three Three Three Three Three</p>
+ </div>
+
+<p class="clearfooter">Clearing Footer</p>
+
+
+ The CSS:
+
+.float-wrapper {float: left; width: 66%;}
+ /*** This can be floated left or right ***/
+
+.first-col {float: right; width: 50%;}
+ /*** This can be floated left or right ***/
+
+.second-col {margin-right: 50%;}
+ /*** This gets margined the same direction
+ as div.first-col gets floated ***/
+
+.third-col {margin-left: 66%;}
+ /*** This gets margined the same direction
+ as div.float-wrap gets floated ***/
+
+.clearfooter {clear: both;}
+
+ p {padding: 10px;}
+
+
+
+Holly 'n John
+ e-mail
+©positioniseverything
+Last updated: Febuary 3, 2003
+Created Groundhog Day (Feb 2nd), 2003
+