3 ms·

We'll the author says intent was to prove it is possible. I believe him.

by braindead_in 18y ago

Jem 18y ago
Her.
- braindead_in 18y ago
  oops. my bad.
  - Jem 18y ago
    Don't worry, you're not the only one that made that assumption. Apparently only men should be allowed near code ;)
    - braindead_in 18y ago
      :). It was just a careless mistake. And we really love it when someone can figure out CSS better than us ;).
    - ars 18y ago
      "He" can mean male, but in English it's also the gender neutral. BTW you have 4 w's in the url in your profile on HN.
      - Jem 18y ago
        Thanks for the heads up.
discojesus 18y ago
> We'll the author says intent was to prove it is possible. Which is a straw man - nobody's arguing that it's impossible. The argument generally centers around valid, web-tested, academic-approved CSS layouts being practical for use in the real world. I worked with someone who did freelance web design on the side and who said "I program for Opera and only test in Opera." Does anyone really need to wonder why he didn't have any repeat business? I also worked in a slicing sweatshop, and using CSS to do layouts instead of tables tripled the amount of time it took to slice a PSD mockup. Department-wide adoption of the YUI CSS framework brought this down to maybe double, although YUI still has some of the basic layout issues that CSS itself does (eg the lead engineer on YUI CSS told me himself that the only way they know of to solve the equal-height column issue with YUI is using Javascript, and there is no equal-height column CSS hack that's anywhere near to understand or cross-browser compatible as table-tr-td-td-td). The greatest time sinkhole by FAR was CSS layout debugging. It was not infrequent to have someone's whole day go down the drain struggling with some god-awful cross-browser issue that would be relatively easy using tables for layout. So I've been there, to the point where I know that the only CSS books that aren't nearly completely worthless are _CSS Mastery_, _Bulletproof Web Design_, and maybe O'Reilly's Definitive Guide. Doing a layout in perfect, valid CSS separating presentation from content (as much as possible, because I've never seen them successfully completely separated in a non-trivial project) is sort of like writing a book and having a sticker on the cover that says "This book has been validated 100% grammatically correct." Swell, but it really doesn't have anything to do with the price of spinach. Just like how the fact that many people have a beef with using CSS for layouts doesn't negate the fact that for everything else it eliminates redundancies and is generally the cat's pajamas, the fact that tables look ugly doesn't negate the fact that in many cases they Just Work faster and are easier to understand than CSS for standard layouts like three equal-height columns.
- Jem 18y ago
  > The argument generally centers around valid, web-tested, academic-approved CSS layouts being practical for use in the real world. Your argument, perhaps, but that's not what the post was about.
  - discojesus 18y ago
    > Your argument, perhaps, but that's not what the post was about. But while your post was correct, it was a straw man - nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS, especially when you only have to make it work in Firefox 3 on Linux and don't have to deal with equal-height column issues. The argument that apparently half of HN is discussing now is "which is more pragmatically effective for client-acceptable layout: CSS or tables?" The post doesn't address this, because a layout that's only been tested in Firefox 3 for Linux would be completely unacceptable to any client I've ever done business with.
    - Jem 18y ago
      > nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS The first post I quoted did exactly that. The OP argued that if you changed the order of a 3-column layout, it 'destroys' the presentation. Both my first and amended examples proved this wrong. I work in web development. I specialise in PHP but I do front-end work on a day to day basis. I too struggle with the frustrations that half-arsed browsers such as IE present. Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about.
      - discojesus 18y ago
        > The first post I quoted did exactly that. Not exactly; he took a "canonical" example of such a layout from an authority on the matter and showed that even with such an idealized example from such an ideal source, changing the order of the content breaks the output. Also, your counterexample uses different CSS for the "in order" and "out of order" proofs-of-concept, which defeats the purpose - the point is that the CSS needs to stay exactly the same with the presentation not changing upon changes in markup order. > Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about. I never said you didn't get it. I said you didn't address the relevant argument in your article. Your article is correct and well thought-out, but it doesn't address the argument that is dividing the HN community, pitting brother against brother.

We'll the author says intent was to prove it is possible. I believe him.

Jem 18y ago

Her.

braindead_in 18y ago
oops. my bad.
- Jem 18y ago
  Don't worry, you're not the only one that made that assumption. Apparently only men should be allowed near code ;)
  - braindead_in 18y ago
    :). It was just a careless mistake. And we really love it when someone can figure out CSS better than us ;).
  - ars 18y ago
    "He" can mean male, but in English it's also the gender neutral. BTW you have 4 w's in the url in your profile on HN.
    - Jem 18y ago
      Thanks for the heads up.

discojesus 18y ago

> We'll the author says intent was to prove it is possible. Which is a straw man - nobody's arguing that it's impossible. The argument generally centers around valid, web-tested, academic-approved CSS layouts being practical for use in the real world. I worked with someone who did freelance web design on the side and who said "I program for Opera and only test in Opera." Does anyone really need to wonder why he didn't have any repeat business? I also worked in a slicing sweatshop, and using CSS to do layouts instead of tables tripled the amount of time it took to slice a PSD mockup. Department-wide adoption of the YUI CSS framework brought this down to maybe double, although YUI still has some of the basic layout issues that CSS itself does (eg the lead engineer on YUI CSS told me himself that the only way they know of to solve the equal-height column issue with YUI is using Javascript, and there is no equal-height column CSS hack that's anywhere near to understand or cross-browser compatible as table-tr-td-td-td). The greatest time sinkhole by FAR was CSS layout debugging. It was not infrequent to have someone's whole day go down the drain struggling with some god-awful cross-browser issue that would be relatively easy using tables for layout. So I've been there, to the point where I know that the only CSS books that aren't nearly completely worthless are _CSS Mastery_, _Bulletproof Web Design_, and maybe O'Reilly's Definitive Guide. Doing a layout in perfect, valid CSS separating presentation from content (as much as possible, because I've never seen them successfully completely separated in a non-trivial project) is sort of like writing a book and having a sticker on the cover that says "This book has been validated 100% grammatically correct." Swell, but it really doesn't have anything to do with the price of spinach. Just like how the fact that many people have a beef with using CSS for layouts doesn't negate the fact that for everything else it eliminates redundancies and is generally the cat's pajamas, the fact that tables look ugly doesn't negate the fact that in many cases they Just Work faster and are easier to understand than CSS for standard layouts like three equal-height columns.

Jem 18y ago
> The argument generally centers around valid, web-tested, academic-approved CSS layouts being practical for use in the real world. Your argument, perhaps, but that's not what the post was about.
- discojesus 18y ago
  > Your argument, perhaps, but that's not what the post was about. But while your post was correct, it was a straw man - nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS, especially when you only have to make it work in Firefox 3 on Linux and don't have to deal with equal-height column issues. The argument that apparently half of HN is discussing now is "which is more pragmatically effective for client-acceptable layout: CSS or tables?" The post doesn't address this, because a layout that's only been tested in Firefox 3 for Linux would be completely unacceptable to any client I've ever done business with.
  - Jem 18y ago
    > nobody makes the argument that it's impossible to do a markup-order-independent, three-column layout in CSS The first post I quoted did exactly that. The OP argued that if you changed the order of a 3-column layout, it 'destroys' the presentation. Both my first and amended examples proved this wrong. I work in web development. I specialise in PHP but I do front-end work on a day to day basis. I too struggle with the frustrations that half-arsed browsers such as IE present. Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about.
    - discojesus 18y ago
      > The first post I quoted did exactly that. Not exactly; he took a "canonical" example of such a layout from an authority on the matter and showed that even with such an idealized example from such an ideal source, changing the order of the content breaks the output. Also, your counterexample uses different CSS for the "in order" and "out of order" proofs-of-concept, which defeats the purpose - the point is that the CSS needs to stay exactly the same with the presentation not changing upon changes in markup order. > Please do not assume that because I chose the side of CSS on this occasion to demonstrate its capabilities, that I do not 'get' what the css vs. table / developing for IE arguments are about. I never said you didn't get it. I said you didn't address the relevant argument in your article. Your article is correct and well thought-out, but it doesn't address the argument that is dividing the HN community, pitting brother against brother.