4 ms·
And sometimes tools are just bad. Yes, a bad workman blames his tools, but that doesn't mean all tools are as good as they can be. Sometimes a good workman bl
by Travis 16y ago
And sometimes tools are just bad. Yes, a bad workman blames his tools, but that doesn't mean all tools are as good as they can be. Sometimes a good workman blames his bad tools; when there aren't better alternatives, what can he do?
Let me put my CSS thoughts in context: I self-assess to be about as competent in CSS as I am in PHP. Now, I know PHP isn't great. But when I'm smash-my-head-against-the-wall frustrated, it's usually because of CSS issues. >75% of the time.
In general, I expect frontend layout work to be less frustrating than backend work. It's less complex, IMO. And, actually, it can be -- just by using tables for layouts. So it's not inherent complexity that causes the frustration, it's the CSS issue (tables remove that frustration for me).
In short, I've returned to table based layouts because that tool fits my needs much much better than CSS. I use CSS for my styling, but layout goes into tables.
- lwhi 16y agoMaybe you should concentrate on back-end development? I can sympathise, but I really don't think reverting to table-based layouts is a good solution. EDIT: Reverting to table-based layouts _ISN'T_ a good solution.
- Travis 16y agolwhi - sure, I'm more comfortable doing back end dev work (and try to focus on it). But that doesn't change my opinion that CSS is a half assed solution that doesn't solve my problems. Tables do. And the counter-arguments against using a table based structure all tap into situations that haven't affected my specific context. So tell me again why I should use CSS based layouts? For me, they frustrate me and prohibit me from accomplishing my tasks. Tables don't do this. And all the downside to using tables? Not particularly relevant for my goals.
- lwhi 16y agoTables usually prevent incremental rendering. Tables are usually more bytes of markup (have a lot of nested <tr><tbody> elements) Tables may require you to chop single, logical images into multiple ones. Tables may require you to use a 'spacer' image (!) We're not living in 1998 (!!) Tables make life hell for those using screen readers. Tables lock you into the current design and make redesigns much harder than semantic HTML+CSS. Tables prevent reuse of content on multiple device formats (mobile / desktop / tablet). Tables prevent content from being easily scraped or translated into other formats (via a screen-reader or XSLT). Tables usually prevent JS from being used to dynamically move and reposition specific content. Tables make dynamic width / liquid layouts difficult (if not impossible).
- ericb 16y agoSome objections, even though I don't use tables regularly personally: Tables are usually more bytes of markup (have a lot of nested <tr><tbody> elements) If you are concerned with size, you are gzipping or deflating and these tags should compress well Tables may require you to use a 'spacer' image (!) Div's require clear:both and other silliness We're not living in 1998 (!!) not really much of an argument--tcp/ip is older than that and we still use it Tables lock you into the current design and make redesigns much harder than semantic HTML+CSS. Perhaps a bit yes on your first point, but worrying about cross browser rendering issues twice will kill your time savings from "fast redesigns." If your table is object code, produced by a helper of some sort, this is not necessarily true either. Tables prevent reuse of content on multiple device formats (mobile / desktop / tablet). Not sure I follow. The current format for all these devices is just a standard browser + scrolling Tables prevent content from being easily scraped or translated into other formats (via a screen-reader or XSLT). Table headers and cells with classes and id's are plenty scrapable
- lwhi 16y agoIf a person really can't see the disadvantages / advantages - I don't mind. But it depresses me to think that some clients (who aren't knowledgeable enough to know any better) are being provided with sites that make use of something that was introduced as a stopgap solution 15 years ago. The main reason people use tables is because they don't understand how to provide the alternative. That's not a good reason. People who do use tables should educate themselves - or pass the work onto a front-end developer.
- Travis 16y agoI can see the advantages and disadvantages. I spent several years trying to force myself to use CSS for layout, because I thought that the abstract benefits of CSS were worth it. Abstract = "easier redesign" or "more accessible" type stuff. Things that had never affected me, yet. And I spent so much time, so much frustration, trying to cram myself into the CSS semantic world. Then I realized, for my startup, that I needed to just BUILD things. I see CSS as providing generally abstract benefits, with very concrete disadvantages. In short, CSS zealots sound to me a lot like this: "Well, if you could understand what you were doing, it would work right." That entire attitude puts me off. Also, I believe it's a false dichotomy to say "no tables", or "only css". I put hacks in my code when it is beneficial for my situation. Tables are one of those hacks that I keep in my toolbox, right next to the duct tape. Frankly, I find it obnoxious that you said, "People who do use tables should educate themselves - or pass the work onto a front-end developer." No. I understand my situation, my context, and my application. I made the decision to use tables, because it was more expedient, and I was insulated from the negative consequences. For you to imply that I'm doing something wrong on my code, well, that's just flat out obnoxious.