I disagree. Tables are still the most reliable way to display content under nearly all circumstances (maybe less so on mobiles, but definitely on the desktop). They've been stable for years and years. I went through the hardcore standards phase where I thought it would be the death of my soul if I ever went back to using tables for layout, but then I read a great article (wish I had the link) that struck a chord with me. It said you don't have to avoid tables for certain small situations where it can save you a ton of time and a few headaches. I would never suggest doing a whole layout in tables, but I think the comments on HN are a good example of something that would have been a pain in the ass to get right across all browsers. Just use tables for layout if it actually makes sense and even then, ever so sparingly.
Yeah this could quickly devolve into a flame about divs vs tables. But divs I always saw as a step backwards in one aspect: programmer ease of use. In divs you have to spend time thinking about "float drop", doing math in your head, and getting all the columns to have the same height - things which "just work" in tables. It still surprises me sometimes how quickly they were adopted.
But divs I always saw as a step backwards in one aspect: programmer ease of use.
It's always a lot easier at first to overlook structure in your app/code/whatever. It's when you or others come to work with your code or extend it in some way (with Greasemonkey, say) that all the extra work comes along.
If you have to "spend time thinking about" writing tests, it takes longer to build the prototype of your software but.. that's not a particularly good rationale for not using tests (though it is still a rationale, of course). Same goes for semantic markup in my book.
>. It said you don't have to avoid tables for certain small situations where it can save you a ton of time and a few headaches.
I am not a front end developer, but I agree to the philosophy to an extent in terms of generic software development.
As software developers, our job is not to thrive for the perfect solution, but writing maintainable, code that we ship. I understand that many people (probably not HN users) take "real artists ship", as an excuse to put ugly unmanageable "hack", which I am not supporting either (infact I think I would be one of the last guys to compromise of code quality), but truth of the matter is, we live in an non-ideal-finite-time-full-of-deadline world, and as every thing has a cost-to-benefit ratio (short and long term). I think as software developers, its a part of out job to judge that cost-to-benefit ratio and if the cost starts to become much for the benefit offered, its time to rethink about software puritanism.
I didn't say that I would, actually. I was defending the decision made by the author of this site. I've been defending practicality over spending a lot of one's time trying to get certain kinds of layout elements working in all browsers across the board. If you cannot appreciate that then let's just agree to disagree.
