3 ms·
When CSS reached a certain point, using tables for layout suddenly became evil. CSS was like some strange measure of your salt as a frontend dev. Very Emperor's
by unclebucknasty 13y ago
When CSS reached a certain point, using tables for layout suddenly became evil. CSS was like some strange measure of your salt as a frontend dev. Very Emperor's New Clothes type stuff.
But, I can remember trying projects with tableless design at that point, and absolutely beating my head against a brick wall attempting things in CSS that required almost zero thought with tables. Then, I'd finally get it right in one browser only to find that it looked like garbage in another.
It was like having a toolbox with a hammer that I couldn't use, instead being forced to nail everything with a screwdriver. And it wasn't just that I was accustomed to tables. They were easier and more natural. When you think about it, layout is nearly always grid-like.
So, I confess that there were times when I said screw it and reverted to tables. I'd solve problems that weren't working after hours of trying with CSS in literally minutes.
And the challenge with CSS is still apparent. Here we are all of these years later, still trying to do something as simple and frequently necessary as center things vertically which, BTW, doesn't work in my stock Android browser.
CSS is a bloated, convoluted mess and just too much work for simple things. That's why I have always found it somewhat draconian that people insisted on CSS as if it didn't have its own significant issues. If there were a tag that operated just like tables, but indicated layout or, as I think someone else suggested, a simple attribute to mark a table as layout vs row/column data, most of the semantic/SEO problems could be solved.
For that matter, I am not convinced that we should be so bent on having html pull double duty as the source for semantic data and the source for a presentation engine's rendering. Maybe a different approach altogether could be more liberating and efficient on both fronts.
- pedalpete 13y agoThough I agree in some respects, I've been a convert of CSS since the beginning. My reason, floats for wrapping elements depending on screen size. You can't do that with a table.
- unclebucknasty 13y ago>floats for wrapping elements depending on screen size Not sure exactly what you mean here. Are you talking about floating divs to wrap elements to the next visual "row" for smaller screen sizes, as in responsive design? Because I don't find this necessary very often in practice, and certainly not nearly as often as the tons of other general layout that's required. Not to mention, of course, that you can still use divs where "needed". BTW, on a side note, the jury is still out on responsive design for me. Or, at least as I have frequently seen it practiced today. For instance, many times a site with sidebars (including nav) will wrap the sidebars on smaller displays such that content, nav, etc. are all lined up in one vertical column. Not very appealing or usable IMO. I really believe that how we treat designing to different formats will change and this responsive wave will pass. And, while I know there are other reasons to wrap elements, I do think responsive design is responsible for a good bit of it.
- Daniel_Newby 13y agoPeople still use floats to make the sidebars stack up on narrow browsers? I thought they mostly went back to tables years ago.
- unclebucknasty 13y agoI think it's still very common. In fact, tableless design is still very much the mantra from what I see. But, you're right: tables can be used for the same. Not something I've done much either way. I just don't think its a nice effect. Guess it's just a style preference.