Floating PointsPublished 18 years, 10 months past
It seems I was a little unclear in my recent post about floats, and compounded the problem with the post title. A number of responses said, basically, “maybe they’re bad for layout but what else is available?” I didn’t mean to suggest that nobody should use floats for layout, or that using them in that manner is somehow wrong; my apologies if I did so. There aren’t too many alternatives; in fact, there are precisely three general standards-based layout options.
Each of these options has its benefits and drawbacks. All I was trying to say is that Andrei was dead on in his feeling that layout floats feel like something that have been bent to a purpose for which they weren’t intended. That’s true. Floats are simple, and were meant to do a very limited thing. Push them hard enough into other roles, and they become a touch balky. If nothing else, their source-order dependencies make them less flexible than one might like, and variances in browser handling of floats (many of those variances having to do with how one should deal with floats in their intended role) just makes the situation more frustrating.
One could argue that all three options are non-layout technologies that have been bent to layout purposes, but positioning at least was intended to be a layout mechanism from its inception. It suffers from enough glaring flaws and browser bugs that it can’t be considered any better an option than the others, though.
In a move that may help matters, Shaun Inman (he of the Inman Flash Replacement technique) has just published the article Clearing Absolutes Again, which further develops his attempts to give positioned elements a
clear-like capability. This is a very welcome development. The IPC (Inman Position Clearing) technique may not be perfect— I haven’t had time to dig into it, so I don’t know— but it’s a fifty-foot neon arrow pointing in the direction things need to go. Since we can’t expect this sort of capability to be added to CSS in the near future, let alone have enough browsers support it in the next few years, scripting our own fixes is the only reasonable solution I can see. For another great big neon arrow of this kind, see Dean Edwards’ IE7.
And yes, I said “tables” back there. If you can avoid using tables for layout, then by all means do, but it isn’t always possible. In such cases, as long as the tables use as little markup as possible, and the markup validates, then I don’t see the problem. Never have, really. My whole objection to tables-for-layout has been, and continues to be, that most table-based designs use way too much markup. Often you see markup-to-content ratios in the vicinity of 3:1. That’s just icky. I much prefer to see the inverse of that ratio, or at least something below 1:1. CSS helps immensely in getting there.
Update: see Shaun’s new new post on the topic, “Absolute Clearance“, for another step in the evolution of his technique. Ever forward!
Position important text logically using CSS » SEO News, Articles & Opinion
[…] positioning Mimicking Magazine Layouts in CSS Lessons learned: CSS: What’s the difference Floating Points
Related PostsGoogle VS Yahoo on SERP rele […]
If you’re looking for context for this entry please see my previous post and its comments Everything must go Man, the internet is a tough crowd. Seriously, who uses the back button? Hehe, a broken back button was not one…
I second your statement on tables – Not so long ago, so-called CSS purists went berzerk over a post on Dave Shea’s site just by suggesting that there are times when it may still be better to use tables to hold pieces of layout instead of pure CSS-based positioning. You know, it’s always exciting when you can pull out a page that can look gorgeous on a browser and practical on a PDA, and validates at the same time, but for better or worse, it is often more important to get the site on time and be paid by the client ASAP – specially when there’s no room for experimentation. Testing time for browser bugs due to uneven CSS support often takes longer than we think, and few if any development timeline/budget projections ever take this into consideration.
However efforts and research like that of Shaun’s definitely are on the way to make these burdens less of an issue, and that can only be a good thing.
I don’t understand why you don’t see “display:table;” as an option. Could you elaborate?
As far as I know, “display:table” doesn’t work properly in IE.
i’ve long been using css for text and dhtml menus. but a few months ago started delving into more and more css based designs, as it seemed like it had gained enough support by the browsers to warrant being able to do it. but it’s post like yours that help cut thru the signal:noise ratio about CSS and Standards-based web design. i’ve been looking for a CSS ‘way’ to layout my forms – so that the text and form elements line up and look neat, orderly and easy-to-read. i’ve tried tricks like right aligning elements in the form tag and what not, but have not been having the kind of results that i expected (especially between mozilla and ie for instance)… now i konw it’s ‘safe’ to go back and use tables in these instances. thanks.
On the question above about alligning form elements, I believe the standard is asking us to move to using “labels” with forms, and though Ive always used tables, my first early experiences with labels is fairly good. You have to pack in some margins and padding in your style sheet to make your text sit properly to the side or above your forms, but yes, its less markup and better design than tables, and can be done.
Second, Eric, thanks for all the hard work helping the world move in this direction. After allot of blood, sweat and tears, Im finally moving our web shop (www.aztecsystems.com) to the standard, though with Microsoft’s messy Visual Studio, ASP.NET, and developers locked into old-fashioned table design, its a bit hard to make the argument (and thus the move) that the added effort and hours learning this technology is worth it, especially with all the bugs in the browsers.
But on the issue of positioning versus floats, sorry, but the fact that absolute elements are taken out of the document flow, AND with the issues with IE, I have been forced me to abandon positioning in all my web layouts. No matter how illogical floats may be, they still give us the power to place things on the page without tables, and with some hope that it will work in all browsers. In order to pull off that magic trick in 99% of the agents out there, I have been forced to apply quite a few hacks in my code….dont know about you. Thats not good and my chief worry. But positioning, as wonderful as it seems and so easy a concept to grasp as it seems to be, is still a huge huge mess, with LOTS of limitations in what it can do. I picture a world in about ten years from now, where the newest gui’s and web building tools allow you to open a page and drag and drop designs and content blocks onto an artboard and boom, they are positioned pixel by pixel along grids using CSS and positioning…..that world I believe will come eventually. I think positioning is the future …but not today. The w3c spec is lacking and the browsers will be lacking for some time. So, my vote, if you are taking one, is go with the floats! You content is all contained relative to each other, and its a very fluid and flexible solution with allot of potential. Go with that!
Here are sample of that thought in action:
a test, hopefully it won’t appear, sorry if it does