This argument is over. Tables lost...like 3 or 4 years ago.
Ask HN: CSS vs table based layouts
41–50 of 52 posts
Re: Ask HN: CSS vs table based layouts
#42HTML is flawed at every level:
It's design is flawed- rather than having a minimal set of tags they have a tag for everything and most people use only a fraction of total tags.
It's implementation is flawed- no two browsers render HTML the same way.
The way people learn HTML is flawed- some people learn to use inline styles, some people use br's to delineate paragraphs, some people build pages without head tags.
In conclusion, fuck it, use tables.
Re: Ask HN: CSS vs table based layouts
#43Tables won't show up until the entire table has loaded but if that's not an issue then use whatever you find easier (and don't feel guilty--if it works, it works).
If it's tabular data ALWAYS use tables.
Re: Ask HN: CSS vs table based layouts
#44Cheat. Use Blueprint, from Blue Flavor, which gives you semi-semantic layout in table style using DIVs and spans. Blueprint actually gives you more layout control than tables do --- your stuff will look better --- but gets rid of almost all the CSS headaches. Standards zealots get all up in Blueprint's face because it's fundamentally non-semantic (you end up putting presentation details in your markup). But now you'r…
Or you can use compass with sass and get to use blueprint together with semantic names for classes...
Re: Ask HN: CSS vs table based layouts
#45I spent much time researching why the tables are bad camp exists, and this is the result of my research: The beginning Initially tables were the only way to layout a web page, and so much abuse occured - this was before CSS and the only way to make a layout was to use 'spacer' gifs. spacer gifs were one pixel gifs that you had to put in td elements so they would retain there shape. As you can imagine this was a mess.…
For point 1) on Div negatives: you could set a min-width on 'body' or the host container if it's flexible to ensure the width never gets small enough for the divs to clear.
Is that available in all browsers?
Re: Ask HN: CSS vs table based layouts
#46You don't have to pick just one. On one of my sites I have tables for the navigation elements and CSS for the content elements. Use what works for you.
Re: Ask HN: CSS vs table based layouts
#47Cheat. Use Blueprint, from Blue Flavor, which gives you semi-semantic layout in table style using DIVs and spans. Blueprint actually gives you more layout control than tables do --- your stuff will look better --- but gets rid of almost all the CSS headaches. Standards zealots get all up in Blueprint's face because it's fundamentally non-semantic (you end up putting presentation details in your markup). But now you'r…
Ah yes, web standards zealots. These are the guys who run blogs debating the use of vs on a monthly basis. The funny thing is that I jumped on the CSS bandwagon early (Netscape 4 era) because of the obvious benefits. Now I find myself disgusted at what the community has become.
They live in their inbred web standards blog world where they have a very polished view of what is "semantic" and what it means to separate content and presentation. All the while completely oblivious to the ecosystem in which web standards live and the constant tradeoffs that must be made in any software system.
Ignoring what should be obvious: there's precious little semantic information in an HTML document. The standardized tags are all but completely presentational. Naming CSS classes strictly according to some pedantic definition of "semantic" meaning "not presentational" is deluded. First, because we add classes to things because need a hook for presentational purposes. Second, because 99% of the time, the actual goals of writing HTML/CSS are presentation, concision, maintainability, and maybe SEO. It turns out you should name your classes descriptively, which may align with a semanticist's notion of best practice 80% of the time. But then the remaining 20% of the time they'll rip you new one for use class="red" instead of using a half-dozen "semantically pure" names like class="slightly_more_important_block", class="second_heading_in_a_row", class="something_i_just_want_to_be_different", class="sometimes_i_just_want_to_be_different", class="why_web_design_sucks_in_96" and class="i_love_you_man"
Re: Ask HN: CSS vs table based layouts
#48I seriously find it difficult to believe that this is still a debate on YC. Once you attempt to build a site of a reasonably level of complexity and/or learn how to build a site using clean, valid, semantic markup, you'll never go back - unless horribly messy code and hack piled upon hack are your thing.
This isn't about being a web standards zealot. It's about learning to do your job. Look to any of the industry leaders in frontend development - it is simply no longer an issue. Table-based implementations of layouts (and all non-tabular data) are the GOTOs of modern markup.
Re: Ask HN: CSS vs table based layouts
#49Here's the deal: CSS was designed to have all the styling and layout power of presentational HTML, and more. Even universally hated features like "blink" were supported, so nobody would have to use presenational HTML ever again.
So what whent wrong with tables? The culprit is that the CSS equivalent of tables, the display:table CSS property (defined in CSS 2) has not been implemented in Internet Explorer yet, even though the standard is 12 years old (IE8 will reportedly support it, though).
So there is no direct CSS equivalent to the layout properties of tables which works in IE. You can emulate some of the properties using floats, absolute positioning and so on, but be aware that this approach is not the "correct" CSS way. Rather it is a workaround around limitations in IE's implementation of CSS. Using tables for layout is a alternative workaround for the same problem. The approaches have different tradeoffs.
The main tradeoff is that HTML-tables are bad for accessibility, while CSS alternatives are often convoluted and hard to maintain. So the choice is basically if you want to cause pain for yourself or for disabled people. Its not hard to understand how this debate turns into more of a moral than a technical discussion.
Note that it is not all uses of tables which require workarounds to implement in table-less CSS. Before CSS, tables were used for a wide array of layout tasks like spacing, margins, positioning and so on, which is generally better handled by CSS today. The limitations are specifically when tables are used as dynamically adjusting grids. I wrote a small article to point out the concrete issues: http://olav.dk/articles/tables.html
BTW - it's a myth that tables render the same across browsers. Table rendering has about the same amount of inconsistencies and browser differences as CSS. The difference is that there is no "right way" to render tables, since table rendering is not specified anywhere. It's all just a chain of reverse-engeneering leading back to the first haphazard table implemtation in Netscape 1.1. With CSS there is at least a spec, and the hope that browsers implentations move incrementally closer to the spec.
Re: Ask HN: CSS vs table based layouts
#50Earlier quoted context omitted.
Since when is it hard to do a three column layout with CSS? It is in fact quite easy, and always has been. What has been hard is three columns with a liquid center column that works in Internet Explorer without hacks . That's a Microsoft problem, not a CSS problem.
Sorry but that is an understatement. Creating a three column layout is surprisingly hard and completely counter-intuitive and it gets only harder when you want liquid columns. IE is part of the problem but many of the other browsers also had their own quierks until recently. Creating a n-column layout in CSS, in a sane way, has literally turned into a pseudo-science over the years. That wouldn't be the case if it had…
It really isn't complicated. Float three columns left with a combined width less than that of the container and you have a three column layout.