Hacker News Reader

Comment by mbleigh | Hacker News Reader

This article is missing the point...it is merely talking about when it is CONVENIENT to use tables for layout, not when one SHOULD use tables for layout. In a modern web world it is extremely inappropriate to use tables for non-tabular data. Yes, this means that oftentimes there will be messy CSS hacks to bring Internet Explorer into submission, but any designer/developer worth his/her salt is old hat at such tricks by now.

The proper time to use tables for layout is when one is laying out out a table. If you aren't, then you are simply performing a cop-out maneuver to save yourself time in website development. If that's what you want to do, do it, but don't call it something it's not. Just because it's easier doesn't mean it's better.

View on HN

> In a modern web world it is extremely inappropriate to use tables for non-tabular data.

Someone once said (in an admittedly totally different context) that '"Inappropriate" is the null criticism. It's merely the adjective form of "I don't like it."'

If tables were good enough for Viaweb in 1995, then they're good enough for the rest of us in 108.

Pretty lame "argument", especially considering how much goes on in 13 years in the computing world. Let's see: If Windows 95 was good enough for most people in 1995, then it's good enough for the rest of us in 2008.

I read that message as sarcastic, for just that reason.

That's 19108 to you, mister!

it is extremely inappropriate to use tables for non-tabular data

Oh no, you mean everything I've read here in the last 482 days has been displayed in "extremely inappropriate" mode?

Amen. This is one of those pedantries that has outlived its justification.

Look: can tables be misused? Yes. Have they been? Yes. Does a static HTML file filled with tables for layout obscure the semantics for things like screen-readers? Sure.

Does any of that have anything to do with whether or not a table should be used for layout? Not that I can see. Two or three lines of jQuery will pack those divs into your table by class.

The weirdest part of all of this is the idea that CSS is "just as good" for typical layout tasks. Not only is it not as good, it's a near-disaster. Nothing works right, ever. It's never possible to just say "line these elements up and put these others to their side" without jumping through awful hoops. Seriously: look at the "layout" CSS for any serious site and it's almost unreadable.

GUI developers have understood this for two decades now, and universally settled on the table as the appropriate layout mechanism. Why the web should somehow be different just baffles me.

Again, I find myself agreeing with you :-) People seem to think that if you create CSS based layouts, that they can be repositioned and re-done using only CSS. This is simply incorrect, and anyone with sufficient html experience knows this.

If you want to change the layout of any site, you need access to both the html and the CSS, so trying to separate the two is just overkill. Sure, you'll want to use CSS for colors and fonts, but for page flow, CSS isn't powerful enough by itself.

You should tell that to the guys over at CSSZenGarden... they'll get a good chuckle.

The CSSZenGarden is - as mentioned in the article - a special case because the content never changes. This means that some of the flexibility issues with CSS is not a problem. You can design everything with fixed sizes and positioning. Every single paragraph is assigned a unique id which you can address.

This approach will never work on "real" web site, because content on a real web site changes.

Whether or not the content is static or dynamic is kind of a moot point, all things considered. <div style="define-my-location"><?php ?></div>

No. That is the main point of the article. Pure-CSS layout is only fine if you know the exact dimensions of the text when creating the layout. If the textual content change later you run into problems.

That is why tables fare better in "the real world" even if proof-of-concepts like zen-garden seem to demonstrate that CSS is powerful enough.

In the case of your example, if you truly have a label that resides beside an input box that could hypothetically be as long as a sentence... then you've done more wrong in your content structuring, than you have with your code. :)

As far as your column example is concerned, you made two content areas dependent on each other when that relationship may change overtime too, however with tables... you must recode the entire site structure to adapt to that.

I disagree with you... and I'd like to think I have "sufficient" HTML experience but as you didn't define what that is, I could be wrong.

A couple of years ago, I ran a styleswitcher on my blog giving the visitor about 5 layouts to choose from. Each one visually different from the rest, not one of them needing any changes to the HTML. The content changed on a daily basis (every time I wrote an entry) and yet it still managed to fulfil its purpose.

Sure, it was only a blog and not a commercial website, but it still shows that CSS is capable of changing the layout by itself. Perhaps sufficient CSS experience is the key?

I absolutely love Flex's layout system and it's not table based.

> In a modern web world it is extremely inappropriate to use tables for non-tabular data [even when convenient]

Why?

Fair question. Semantically the <table> tag is created for just that, tabular data. If you use it for layout there are a number of problems. First, it is harder for screen-readers and other accessibility-based tools to decipher a website laid out with tables than one properly laid out using standards-based development. Second, you are adding needless bloat and confusion to your markup, as you will have completely unnecessary tags littered throughout your HTML. Third, you will be going against standards-based development, which is a worthy goal in and of itself.

CSS exists to separate markup from style information, that's its entire purpose. To use tables to lay out a page is to explicitly include style information in a place designated only for semantic markup.

Perhaps the solution is to make a better screen reader, one that can extract semantic data from non-semantic markup.

Yeah, screen readers seem pretty useless if they cant handle a web page with tables-for-layout, since these are quite common whether we like it or not.

A sensible heuristic would be to treat tables without TH or THEAD elements as layout-tables, ie. just read them serially, while treating tables which contain at least one TH-element as a true semantic table. I'll bet this is the correct interpretation 9/10 times.

Heh. It's ironic that XML was designed to represent text documents, but is now mostly used to hold data. Maybe if they had named it eXtensible Table Language, they would have enticed people to put text into it like they do with the <table> element.

The <table> tag may have been designed to be used for table, but this is not what it is used for in practice. Hence screen readers should adapt.

Bate taken. Because it violates the semantics of what a table should be. i.e. a data matrix.

I don't care what a table "should" be very much. How is that even determined? By what some committee says? I care what, in fact, it does. How browsers and others use it.

Yes by a committee... and it's the lack of following W3C standards in the late 90's and early 00's that has created such a headache for web developers today. For example if IE5/IE6 played nice, we could spend more time building out sweet functionality and less time bug-fixing.

It's ok to be a conformist in this regard.

Of course you can always do what ever you want/what ever works. But the reality is moving away from tables for your layout will make your site more malleable and easy to maintain the future. It doesn't always mean crazy i.e. only clauses in your css either. see: http://news.ycombinator.com/item?id=219809

but didn't the article give an example or two where tables made your site more maintainable?

Tables give you abritary grids, a very important design tool. CSS doesn't do as well. People turn to CSS frameworks to make it happen.

No, that was not my interpretation of this article at all. It sounds to me like you've never built a large CSS/XHTML valid website, or you'd understand why the web is driving toward standards.

I was like you ~3-4 years ago as I grew up using tables. Believe me, just move on... 99% of the job postings I see require an understanding of XHTML/CSS. And this trend will continue as standards are solidified...

Catch up or be left behind.

The point of the article is to show how table-based layouts in some specific circumstances are more maintainable than pure-CSS layout. If you disagree with this, it would be interesting to hear your counterpoints.

It's called a table, not a grid. And as information and the internet enlarge (hence the continuous drive for better search), semantics are a very important aspect of the equation. As such, so is using proper markup to define the content of the page.

Your post does not constitute more "maintainable" code at all, and contradicts the years of community contributions to CSSZenGarden. I'd recommend you establish a personal CSS "framework" for tackling common layouts/frustrations.

How would you specifically solve the form-in-a-grid layout problem described in the article?

sounds to me like you've never built a sizable web application.

I've been in the business since the late 90's my friend, and for a significant portion of that time on the side of front-end design and production. I didn't mean anything negative by calling out his inexperience with XHTML/CSS, but after reading through his rebuttal it was the only logical conclusion.

Unlike you, I clicked on your profile and read a vast majority of your comments. You should go back to lurking, and spew your negativity and snide remarks elsewhere...

oh i didn't mean anything negative either. it was just ... the logical conclusion.

unlike you, i have no interest in your profile.

Reply on news.ycombinator.com