"They're both wrong. You can order your content how your like. You are restricted only by your knowledge of CSS and not its ability as a styling language to render your documents. It took me about 30 minutes to knock up a demonstration, which you can see for yourself: columns in order and columns out of order."
I think the fact that it took you (a CSS pro) 30 minutes to come up with a simple 3 column example that's hard for me to understand, reflects poorly on CSS. Just because something is possible doesn't make it a good technology automatically.
I might be able to make a Turing machine out of my blender, some rubber bands, and chewing gum (note: haven't actually tried this). It might be Turing complete, but I'm not going to be able to program anything useful with it (an admittedly extreme example)
This article, while well intentioned, misses the point it was trying to prove. The article gives an example of a three column layout with two different orderings of the <div>'s in HTML to prove "ordering doesn't matter". The problem is the CSS in the examples changes along with the re-ordering of divs. This is exactly the point it was trying to disprove.
Though the coupling between CSS and HTML is loose it's not quite loose enough to allow HTML to be arbitrarily reordered and maintain the same presentation without also modifying the CSS.
Although for the record, I dislike the technique used to achieve the results. As the person above you said - just because it's possible it doesn't mean it's any good!
jemjabella was nickname given to me about 10 years ago, and the tagline is intended as humour.
I use it as a measure of whether or not people should read my site... i.e. if you find it funny, or are able to ignore the blatant egotism, then you would probably be OK reading my site. If it winds you up or gets to you, then you won't like the content and you should read at your own risk. :)
I also think it's funny that the simple 3-column example that took you 30 minutes to put together has exactly the same shortcomings that are discussed in the original article (for instance, try setting the background color of one of the sidebars or swapping their order in the markup without changing the CSS).
It's true that you can order the markup however you want and write the CSS to make it look right, but the key point is recognizing that (unless you position everything absolutely) there is still no true separation between the markup and the CSS (at least where layout is concerned). If they were truly independent, then it wouldn't matter what order the elements appeared in the markup... the CSS would lead them to render the same way on the screen every time.
It's worth pointing out that there is true independence between the markup and CSS where styling is concerned (and this is where CSS shines). If you style the background, font, opacity, whatever of a particular element and then move that element to a different location within the markup, the element will still look exactly the same (unless the new position in the DOM subjects it to other CSS rules that override the old ones).
I'm rambling a bit here, but all I'm really trying to say is that CSS has its place in the web development toolbox, but old-school tables often have the edge when looking for a layout that just works.
Did you test it in IE before you made that comment?
I ask because I'm now at work, and have access to a windows box with IE6 installed. Lo and behold, my examples work EXACTLY the same as they did in FF3.
Not to mention, the "in order" example he gave doesn't scale with the width of the browser and only works for fixed width.
There is only one way in CSS (without js) to do a layout where there are two fixed width side bars on either side and one center content area that grows/shrinks with the width of the browser window and that is the "out of order" way (two floats, one non-floating div with margin-left, margin-right equal to left,right sidebars' widths), which coincidentally, he also screws up via the use of relative positioning and 3 floats.
It's "she", if you don't mind; and nobody asked for a fluid layout. You're trying to point out flaws in an example designed to prove a totally different point.
I apologize. While I understand the point you are making in the article, I disagree with this statement:
"You can order your content how your like. You are restricted only by your knowledge of CSS and not its ability as a styling language to render your documents. "
I will retract what I've said if you can demonstrate a fluid 3 column layout using only those 3 divs (left, right, center) where the center column expands with the browser, the sides remain constant width, and the order is preserved. This is trivial using tables.
Css tends to show its rough edges when you use it outside of a fixed width or absolutely positioned environment.
Before anyone adds new requirements, consider these ones: it has to be emailed and in the printout, the columns should look like tabs above the midle area.
In all seriousness, sometimes requirements are inane, pointless and unreasonable and you just have to push back and say it can't be done.
I think CSS detractors tend to obsess over specific points that tables can handle normally, but often leave out real life situations where obsessive alignment is not necessarily the biggest of the problems. Bias (in this case towards css vs tables, as opposed to web dev in general) is an interesting phenomenon.
I'm working on an unfamiliar system, with unfamiliar tools, and doing several things at once - all whilst dribbling snot over my keyboard - but I'll be sure to narrow it down to 10 mins next time. :)
I like tables because I know how to use them, and they work in all browsers. Plus valign and align work. The lack of valign in CSS as well as the documentation of it appearing to be: "this but that unless this or that and then that, but you cant do that unless this, duh, know CSS," makes me want to RAAAAAGE.
I always thought CSS worked well for decorating stuff, and not for layout. But, anyway, I almost always use CSS. The exception being: I need some quick layout where floats are screwed up and I don't feel like spending a whole day figuring out why (see above statement about its documentation).
Regardless, one thing that bothers me is when people claim that it's entirely your fault if you can't use something, because you didn't bother to learn enough about it. This is always true, but surely we all can agree that things have different levels of inherent difficulties. Adding, for example, is much easier than differentiating, though they both require you to learn it before you can use it. So when people complain about how CSS is not as simple as it could be, or that all the little nuances and exceptions are ridiculous, this is due to some mixture of ignorance and inherent complexity in CSS, and is not entirely the person not knowing CSS. This also applies to situations where rather than taking a criticism in stride, the answer is: "Don't like it? GET OUT."
I guess, in short, the attitude of "that's the way it works, deal with it" as being a valid argument for "you shouldn't be complaining" really pisses me off.
Ah, the thing I just realized that I know more about divs and CSS and yet I can still use tables better. Having only worked with table a dozen times, I still know exactly what a table will look like when I create it. I know that I won't know, exactly. what div/CSS is going to look like when I'm done.
And mod-up "Regardless, one thing that bothers me is when people claim that it's entirely your fault if you can't use something, because you didn't bother to learn enough about it." A good language, a good system, a good process "makes easy things easy and difficult things possible". As far as I can see, CSS fails with both. And, today was the tipping point for me personally. I would have endorsed CSS yesterday.
Well, I know CSS is great if I want arbitrary rectangles place on the page.
When I was like 13 and CSS was just getting started, I was so excited that I could add decorative styles to things. I mean, I thought it was ridiculous that instead of <b></b> I had to look up some arbitrary thing like "font-weight:bold" and I still to this day have trouble remember how to do italics.. I just looked it up, it's "font-style:italic" and same goes for underline... "text-decoration:underline". Who comes up with these names?
Anyway, I agree... today I no longer fear using tables... and, fuck it, I'm bringing back <b> <u> and <i>.
The original example had a top and bottom spanning all three columns, making the problem fundamentally different than you describe. I would be more interested if you could take that original example in the original post and show how CSS does not run into the problem that is described in the original post.
Further, you test it in Firefox 3. The problem that I see is that in the Real World (TM), I must make sure that the website works on Internet Explorer 6. Most of the problems I encounter with CSS layout involves cross-browser inconsistency.
I do not pretend to be a specialist in front end work; frankly, it is my least favorite part of development. However, I've made an effort to learn CSS layout systems only to go back to tables in projects that someone else isn't doing the work.
The original example in the original post complained about not being able to swap the center and side columns, I didn't feel that the header was relevant. However, I could create additional examples if necessary.
The thing I think a lot of people are missing is that I don't care whose fault it is.
As a designer, I just need my sites to work in the real world (where 1/3 of my traffic is IE6). I'm not placing any blame, but if it doesn't work in IE6 then it doesn't work for me.
This is not exactly a very convincing article. For one the two examples do not display the same in FF3 (there's different amounts of white space between the three columns in the different versions), and of course, the examples looks completely different in IE 6 which is about 90% of the problem to begin with.
The articles I'm disagreeing with state that it's not possible, neither restrict that statement as purely an IE6 problem. The demonstration is to prove that it is possible, which it clearly is. I could tweak the positioning of the columns by one or two pixels but it wouldn't make any difference to my point, would it?
We Tablists* only have to point out one hole at a time to continue being right. Not restricting the statement just makes it harder to refute, since you have to cover all the ways in which CSS-for-layout is deficient, rather than just a single way.
* Table-for-layout-ists is just too long, don't you agree? ;)
You're actually proving the point those articles are agreeing on. Your CSS changed to make that possible. The point is when you change the ordering of DIVs your CSS often also has to change. So they are not as loosely coupled as one would hope a Model-View relationship might be.
> It took me about 30 minutes to knock up a demonstration
Really?
>Both are visually identical in appearance, both use CSS to control the positioning of the columns, but one is in "correct" logical order in the document (left, center, right) and the other out of order (center, left, right).
> We'll the author says intent was to prove it is possible.
Which is a straw man - nobody's arguing that it's impossible. The argument generally centers around valid, web-tested, academic-approved CSS layouts being practical for use in the real world. I worked with someone who did freelance web design on the side and who said "I program for Opera and only test in Opera." Does anyone really need to wonder why he didn't have any repeat business?
I also worked in a slicing sweatshop, and using CSS to do layouts instead of tables tripled the amount of time it took to slice a PSD mockup. Department-wide adoption of the YUI CSS framework brought this down to maybe double, although YUI still has some of the basic layout issues that CSS itself does (eg the lead engineer on YUI CSS told me himself that the only way they know of to solve the equal-height column issue with YUI is using Javascript, and there is no equal-height column CSS hack that's anywhere near to understand or cross-browser compatible as table-tr-td-td-td). The greatest time sinkhole by FAR was CSS layout debugging. It was not infrequent to have someone's whole day go down the drain struggling with some god-awful cross-browser issue that would be relatively easy using tables for layout. So I've been there, to the point where I know that the only CSS books that aren't nearly completely worthless are _CSS Mastery_, _Bulletproof Web Design_, and maybe O'Reilly's Definitive Guide.
Doing a layout in perfect, valid CSS separating presentation from content (as much as possible, because I've never seen them successfully completely separated in a non-trivial project) is sort of like writing a book and having a sticker on the cover that says "This book has been validated 100% grammatically correct." Swell, but it really doesn't have anything to do with the price of spinach.
Just like how the fact that many people have a beef with using CSS for layouts doesn't negate the fact that for everything else it eliminates redundancies and is generally the cat's pajamas, the fact that tables look ugly doesn't negate the fact that in many cases they Just Work faster and are easier to understand than CSS for standard layouts like three equal-height columns.
Dude! I have spent ages in debugging IE shit as much as you have. And have lost much of my hair! But I dont think what everybody's discussing here is cross browser compatibility. When you start with CSS you know are very much aware that some browsers dont support it. Each and every tutorial, all those books, point it out. So why go back and complain CSS sucks.
My condolences - I too know the pain of IE debugging. But it seems you're making the same error that the linked article is. The relevant question is not "is it theoretically possible to do layouts in CSS?", it is "CSS-based layouts vs. table-based layouts: which is better for Just Getting Shit Done in the Real World?"
And in my experience, for reasonable client-acceptable cross-browser compatibility (ie IE6/IE7/FF/Safari), CSS based layouts often cause more headaches than they're worth.
No. In my experience a mix of CSS and table based layouts work out fine. There are cases when floats and clears are overkill. But so is a complete table based layout.
I appreciate your enthusiasm, but I'm sorry to say your assertive "No" doesn't negate the fact that my experience is that CSS-based layouts are very often not cost-effective compared to table-based.
We had 15 people doing slicing all day, every day, 50-60+ hours a week. We weren't all morons. You better believe we figured out what works and what doesn't, and as I said, the switch to CSS-based layouts tripled the time it took to get a site to a client. If you want to believe that everyone in the shop just happened to simultaneously become mentally retarded at the exact time the switch was made, you're free to do so. Personally, I think Occam's razor suggests otherwise.
I respect your experience. And I dont want to drag this. If CSS hasnt worked out for you, and you are using tables, its fine. Nobody's saying that its wrong.
The point is, choose whats best for you. For me CSS has worked!
> Your argument, perhaps, but that's not what the post was about.
But while your post was correct, it was a straw man - nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS, especially when you only have to make it work in Firefox 3 on Linux and don't have to deal with equal-height column issues.
The argument that apparently half of HN is discussing now is "which is more pragmatically effective for client-acceptable layout: CSS or tables?" The post doesn't address this, because a layout that's only been tested in Firefox 3 for Linux would be completely unacceptable to any client I've ever done business with.
> nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS
The first post I quoted did exactly that. The OP argued that if you changed the order of a 3-column layout, it 'destroys' the presentation. Both my first and amended examples proved this wrong.
I work in web development. I specialise in PHP but I do front-end work on a day to day basis. I too struggle with the frustrations that half-arsed browsers such as IE present. Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about.
Not exactly; he took a "canonical" example of such a layout from an authority on the matter and showed that even with such an idealized example from such an ideal source, changing the order of the content breaks the output.
Also, your counterexample uses different CSS for the "in order" and "out of order" proofs-of-concept, which defeats the purpose - the point is that the CSS needs to stay exactly the same with the presentation not changing upon changes in markup order.
> Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about.
I never said you didn't get it. I said you didn't address the relevant argument in your article. Your article is correct and well thought-out, but it doesn't address the argument that is dividing the HN community, pitting brother against brother.
> Also, your counterexample uses different CSS for the "in order" and "out of order" proofs-of-concept, which defeats the purpose - the point is that the CSS needs to stay exactly the same with the presentation not changing upon changes in markup order.
I already addressed that; see the new URLs in a comment above.
I think it's one downside to the only-vote-up story system; once a debate spills outside the comments of one article, you end up with half a dozen submissions reflecting various viewpoints.
FYI, I found your blog's color scheme -- blue-on-blue with blue links -- and small text hard to read. Design tips that are hard to read are somewhat self-nullifying.
Design and coding are two totally separate arenas. I am useless at design. Nonetheless, I'll bear your criticism in mind. (Although you can resize the text yourself, it's %-driven.)
Given that the point of the entry is to show off the position independent examples rather than insult any one individual's abilities, something like "Order-Independent CSS Layout Examples" would probably be more appropriate.
I assume I could change it myself (the edit link is there)...
Ay, there's the rub, /
For what in that tests of compatibility for bugs may come /
When we have shuffled aroud this horrible mess of browser code /
Must give us pause.
Say... I decide to write a word processor in ASM (think... ultra fast etc...). I manage to waste 3 months in the process and get nothing useful. At the end of this ordeal, should I
1) Blame ASM and use something more convenient like python, or
2) Blame my incompetence and soldier on?
Now replace ASM with CSS, python with tables, and word processor with complex webpage.
I think the fact that it took you (a CSS pro) 30 minutes to come up with a simple 3 column example that's hard for me to understand, reflects poorly on CSS. Just because something is possible doesn't make it a good technology automatically.
I might be able to make a Turing machine out of my blender, some rubber bands, and chewing gum (note: haven't actually tried this). It might be Turing complete, but I'm not going to be able to program anything useful with it (an admittedly extreme example)