6 ms·

[3] http://en.wikipedia.org/wiki/Stockholm_syndrome http://en.wikipedia.org/wiki/Stockholm_syndrome

by ericb 16y ago

lwhi 16y ago
But I honestly believe sometimes a bad workman blames his tools. I took the time to learn how to use it, so maybe I'm biased - but it's really not that bad.
- 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 ago
    Maybe 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 ago
    lwhi - 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 ago
      Tables 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 ago
        Some 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 ago
        If 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.

[3] http://en.wikipedia.org/wiki/Stockholm_syndrome http://en.wikipedia.org/wiki/Stockholm_syndrome

by ericb 16y ago

[3] http://en.wikipedia.org/wiki/Stockholm_syndrome http://en.wikipedia.org/wiki/Stockholm_syndrome

lwhi 16y ago

But I honestly believe sometimes a bad workman blames his tools. I took the time to learn how to use it, so maybe I'm biased - but it's really not that bad.

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 ago
  Maybe 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 ago
  lwhi - 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 ago
    Tables 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 ago
      Some 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 ago
        If 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.