4 ms·

Above average, sure, but still misinformed and one-sided. It is correct that some layouts are easier created using tables rather than CSS. However, there is al

by olavk 18y ago

Above average, sure, but still misinformed and one-sided. It is correct that some layouts are easier created using tables rather than CSS. However, there is also many types of layouts which cannot be created with tables, but require CSS. A serious article (rather than a rant) would explain the limitations of both approaches, given the limitations of current browsers.

ambition 18y ago
I for one would be interested in an HN submission that fleshes out the suggestions you're making here.
- olavk 18y ago
  I have an article which explains when to use tables: http://olav.dk/articles/tables.html http://olav.dk/articles/tables.html But now that the pendumlum seem to have swung from never use tables for layout to always use tables for layout, I suppose it should be extended with an explanation of when not to use tables :-)
- KrisJordan 18y ago
  An HN submission that tries to be more even handed: http://news.ycombinator.com/item?id=464342 http://news.ycombinator.com/item?id=464342 http://www.newmediacampaigns.com/page/why-css-should-be-used-for-layout http://www.newmediacampaigns.com/page/why-css-should-be-used...
mattmcknight 18y ago
Obviously, neither option is ideal, or this discussion wouldn't keep happening. However, I think it's much easier to prove a purist wrong than to prove a pragmatist wrong. The pragmatists just change their position. Separating layout and content for purity's sake doesn't make sense, because the ordering of the divs in the html affects the layout. If you want to separate content and presentation, use XML and XSL. That should cure any ambitions along those lines. HTML is a presentation language, not a content definition language. I was on the tables side, but some of the new grid layout CSS things like Blueprint are almost as easy. However, Blueprint makes it easy by putting the presentation back into the HTML page- you don't have semantic markup, you have styles that define the height and width of your element. So, it gives us the simplest thing (mixed content and presentation) but in a way that looks like it complies with the "no tables for layout" dictum sent down from CSS heaven.
- GHFigs 18y ago
  > because the ordering of the divs in the html affects the layout I don't understand why people keep trumpeting this like it's a big revelation. The layout of everything depends on the order whether you use CSS or not. Floats were not intended to change this, and complaining that they don't just because tables do is apples to oranges. If you look at the specs, the example use case for floats is floating an image element inside a paragraph. For that and many other cases, floats work exactly as intended and expected. It's only when you use floats to emulate a table-based layout without using display:table that a problem like this comes up.
  - gcv 18y ago
    I don't understand why people keep trumpeting this like it's a big revelation. Because the dependency on entry order makes the div's class semantically meaningless. Yes, the order in tables makes a difference, but in a table, that makes sense. With CSS, however, if I add a div with a class name like "center_column", then I expect to be able to put it anywhere in its enclosing context, and it should render in the center of that context. CSS as an abstraction leaks, and it leaks blood. It seems that CSS-supporting designers (on this thread and elsewhere) accept this far more readily than hackers. A table is a table is a table: you expect its order to matter, so no one blinks when this turns out to be the case. CSS looks superficially like it provides a higher level of abstraction, but it (1) does not, and (2) requires considerably more effort to get right.
    - olavk 18y ago
      By putting presentational info into a class name, you break the abstraction.
    - GHFigs 18y ago
      You don't know what you're talking about. "center_column" illustrates that. You're still pretending that floats are tables, which they are not and never were intended to be. That's my point, and it went way over your head.
deleted 18y ago
[deleted]

by olavk 18y ago

ambition 18y ago

I for one would be interested in an HN submission that fleshes out the suggestions you're making here.

olavk 18y ago
I have an article which explains when to use tables: http://olav.dk/articles/tables.html http://olav.dk/articles/tables.html But now that the pendumlum seem to have swung from never use tables for layout to always use tables for layout, I suppose it should be extended with an explanation of when not to use tables :-)
KrisJordan 18y ago
An HN submission that tries to be more even handed: http://news.ycombinator.com/item?id=464342 http://news.ycombinator.com/item?id=464342 http://www.newmediacampaigns.com/page/why-css-should-be-used-for-layout http://www.newmediacampaigns.com/page/why-css-should-be-used...

mattmcknight 18y ago

Obviously, neither option is ideal, or this discussion wouldn't keep happening. However, I think it's much easier to prove a purist wrong than to prove a pragmatist wrong. The pragmatists just change their position. Separating layout and content for purity's sake doesn't make sense, because the ordering of the divs in the html affects the layout. If you want to separate content and presentation, use XML and XSL. That should cure any ambitions along those lines. HTML is a presentation language, not a content definition language. I was on the tables side, but some of the new grid layout CSS things like Blueprint are almost as easy. However, Blueprint makes it easy by putting the presentation back into the HTML page- you don't have semantic markup, you have styles that define the height and width of your element. So, it gives us the simplest thing (mixed content and presentation) but in a way that looks like it complies with the "no tables for layout" dictum sent down from CSS heaven.

GHFigs 18y ago
> because the ordering of the divs in the html affects the layout I don't understand why people keep trumpeting this like it's a big revelation. The layout of everything depends on the order whether you use CSS or not. Floats were not intended to change this, and complaining that they don't just because tables do is apples to oranges. If you look at the specs, the example use case for floats is floating an image element inside a paragraph. For that and many other cases, floats work exactly as intended and expected. It's only when you use floats to emulate a table-based layout without using display:table that a problem like this comes up.
- gcv 18y ago
  I don't understand why people keep trumpeting this like it's a big revelation. Because the dependency on entry order makes the div's class semantically meaningless. Yes, the order in tables makes a difference, but in a table, that makes sense. With CSS, however, if I add a div with a class name like "center_column", then I expect to be able to put it anywhere in its enclosing context, and it should render in the center of that context. CSS as an abstraction leaks, and it leaks blood. It seems that CSS-supporting designers (on this thread and elsewhere) accept this far more readily than hackers. A table is a table is a table: you expect its order to matter, so no one blinks when this turns out to be the case. CSS looks superficially like it provides a higher level of abstraction, but it (1) does not, and (2) requires considerably more effort to get right.
  - olavk 18y ago
    By putting presentational info into a class name, you break the abstraction.
  - GHFigs 18y ago
    You don't know what you're talking about. "center_column" illustrates that. You're still pretending that floats are tables, which they are not and never were intended to be. That's my point, and it went way over your head.

deleted 18y ago

[deleted]