5 ms·

Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. O

Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with tables. Not only that, the resulting table-based design HTML was an intuitive read. The reason was as you say: Grids are key. How many people would now honestly say that we are better off for CSS-layout vs. tables? But, it's amazing how an entire industry lurched in one direction so quickly, based on ideology. The pressure to use the "right" approach was immense. The whole thing had a very "Emperor's New Clothes" feel to it. Everybody seemed to agree that CSS layout was completely awesome, while I beat my head against the wall trying to make it work. Now, we all see that so many were actually suffering in silence. >the separation of concerns in HTML into content/style/controller is very useful This is a belief that I question to some extent and I've wondered whether it's a core assumption that sounds great and thus goes unchallenged, but fails to make the cut in the practical world. In particular, how much do we really need to separate content from layout? Styling is one thing, but layout tends to be intrinsically tied to the content. You can change the appearance of content without modifying its meaning, but changing its organization or layout can render it absolute nonsense. Thus, if CSS were all about colors, fonts, etc., it would actually be a somewhat reasonable approach to separating reasonably separable concerns. But, as most now agree, it's CSS's horrible attempt at managing layout that makes it so painfully bad. And, I really wonder if the core problem is just that there's no real benefit to trying to separate layout (vs simply style) from content in the first place. What we're really saying in attempting to do so is that we want to be able to create a document wherein we have a bunch of unstructured content that we want to insert in an essentially random fashion, then create a second document that rearranges the content. It's an unnecessary abstraction that seldom provides an ROI. How often do we later want the content to stay exactly the same, but simply want to change where it appears on the page? And, if we do, is it really easier to change the layout in an external document (CSS or otherwise) than it is to modify the document? I have yet to hear a proposal that makes more sense than the old-table based design. The purists said that tables are strictly for presenting tabular data. Fine. So, let's create a new tag called "grid" for layout and give it the same layout flexibility as the tables of old.

grey-area 12y ago
Styling is one thing, but layout tends to be intrinsically tied to the content. This is an interesting distinction - thanks. As you say there are issues with separating layout and content, because the two can be hard to separate effectively. I think it is worth the effort though, and sometimes pays off (for example reflowing content for a mobile device). An interesting thought though that we should separate style and content, not layout and content. As to tables, I think there were two issues mixed up in that religious war - the nasty markup of table/tr/rd, sliced images etc polluting every website when it was intended for data, and grid layouts (which it made easier). Unfortunately grid layouts were thrown on to the auto-de-fé along with sliced images and table markup, and then promptly reinvented (with much pain) by entire frameworks designed to make up for the shortcomings of CSS. There have been very recent attempts to add grids to CSS, and hopefully they'll come to something (see link above from buovjaga) - I do think they're far more intuitive and most importantly impose a sensible structure on people attempting to lay out information.
- dsego 12y ago
  Untying styling from layout is what OOCSS does. All styling is written only with classes. This makes it easy to reuse styles. All other selectors, especially nested, are avoided, since they rely on a certain layout and can't be reused. http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/ http://www.smashingmagazine.com/2011/12/12/an-introduction-t...
- unclebucknasty 12y ago
  Good points. I think that responsive design is probably one of the biggest use cases for CSS layouts these days, though I don't know that it was a driving force or even a consideration when The Great Tableless War began. In any case, I'm not quite a believer in responsive design either. The short is that, as commonly practiced, responsive design fails to acknowledge the relationship between content and layout. I posted a lengthy comment on this thread with more on that, so I'll spare HN's bandwidth the duplication. Image slicing was indeed nasty and I don't think it was as much a function of table-based layout as an implementation choice. Some tools were particularly nasty with this, but they were less famously also capable of outputting equally nasty CSS/div based code. So, good handcoding is really required to achieve any semblance of maintainable design, whether CSS or table-based. But, I think you nailed the history. And, it just happened that table capabilities were remarkably useful for laying out a page. Had this been intentional vs a byproduct of that tag's function, the outcome may have been different. One could literally rename "table" to "grid", "tr" to "row", and "td" to "col" and be most of the way there. Would a separate tag of this ilk that could be additionally styled with CSS have silenced the tableless zealots? We may never know. But, if so, it's amazing to think that all of this upheaval, pain, and lost hours was the result of such simple puritanical ideology. Such an HTML tag vs. pure CSS construct would have also pointed to the already blurred lines between HTML's suggested role as merely a data container vs. its unavoidable role in presentation. The theory that HTML represents only data still manages to sell itself when we are talking say, paragraph and list elements. This is so, in spite of the fact that, like "real" tables, even those elements are themselves completely loaded with implicit layout information. We need to embrace the fact that a paragraph tag implies that this element will need to be offset and, yes, the details can be found in the CSS. But, when reading/writing the code, the order and structure are intuitive. We don't randomly spit out a group of paragraphs, then impose the ordering via a stylesheet. Instead, we expect the order to be as it exists in the document. Same with lists and other elements. Likewise, the fact that the structure of the document has implications on its layout even leaks through when using CSS. For instance, assigning a value of absolute to the position attribute of an element, positions it relative to its ancestor in the document structure. But, it's when "pure" layout is involved that things become murkier. We suddenly want to disavow that the natural layout clues are already there and instead force this unnatural separation into CSS. The problem is that much like with tabular data or a series of paragraphs, all content on a page has a relationship to other content that is best expressed in a natural grid like structure. It's not just visual, but actually semantic. So, it is natural to express this relationship in the markup and leave the styling details to CSS. Perhaps more importantly, it is unnatural to spit a bunch of related content into a document in a completely unstructured fashion, then impose structure in a separate document. So, let's not repeat the ideological mistakes of the last Great War. Ask your Congressperson to keep the grid element out of CSS (except for styling) and add it to HTML where it belongs! :)

grey-area 12y ago

Styling is one thing, but layout tends to be intrinsically tied to the content. This is an interesting distinction - thanks. As you say there are issues with separating layout and content, because the two can be hard to separate effectively. I think it is worth the effort though, and sometimes pays off (for example reflowing content for a mobile device). An interesting thought though that we should separate style and content, not layout and content. As to tables, I think there were two issues mixed up in that religious war - the nasty markup of table/tr/rd, sliced images etc polluting every website when it was intended for data, and grid layouts (which it made easier). Unfortunately grid layouts were thrown on to the auto-de-fé along with sliced images and table markup, and then promptly reinvented (with much pain) by entire frameworks designed to make up for the shortcomings of CSS. There have been very recent attempts to add grids to CSS, and hopefully they'll come to something (see link above from buovjaga) - I do think they're far more intuitive and most importantly impose a sensible structure on people attempting to lay out information.

dsego 12y ago
Untying styling from layout is what OOCSS does. All styling is written only with classes. This makes it easy to reuse styles. All other selectors, especially nested, are avoided, since they rely on a certain layout and can't be reused. http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/ http://www.smashingmagazine.com/2011/12/12/an-introduction-t...
unclebucknasty 12y ago
Good points. I think that responsive design is probably one of the biggest use cases for CSS layouts these days, though I don't know that it was a driving force or even a consideration when The Great Tableless War began. In any case, I'm not quite a believer in responsive design either. The short is that, as commonly practiced, responsive design fails to acknowledge the relationship between content and layout. I posted a lengthy comment on this thread with more on that, so I'll spare HN's bandwidth the duplication. Image slicing was indeed nasty and I don't think it was as much a function of table-based layout as an implementation choice. Some tools were particularly nasty with this, but they were less famously also capable of outputting equally nasty CSS/div based code. So, good handcoding is really required to achieve any semblance of maintainable design, whether CSS or table-based. But, I think you nailed the history. And, it just happened that table capabilities were remarkably useful for laying out a page. Had this been intentional vs a byproduct of that tag's function, the outcome may have been different. One could literally rename "table" to "grid", "tr" to "row", and "td" to "col" and be most of the way there. Would a separate tag of this ilk that could be additionally styled with CSS have silenced the tableless zealots? We may never know. But, if so, it's amazing to think that all of this upheaval, pain, and lost hours was the result of such simple puritanical ideology. Such an HTML tag vs. pure CSS construct would have also pointed to the already blurred lines between HTML's suggested role as merely a data container vs. its unavoidable role in presentation. The theory that HTML represents only data still manages to sell itself when we are talking say, paragraph and list elements. This is so, in spite of the fact that, like "real" tables, even those elements are themselves completely loaded with implicit layout information. We need to embrace the fact that a paragraph tag implies that this element will need to be offset and, yes, the details can be found in the CSS. But, when reading/writing the code, the order and structure are intuitive. We don't randomly spit out a group of paragraphs, then impose the ordering via a stylesheet. Instead, we expect the order to be as it exists in the document. Same with lists and other elements. Likewise, the fact that the structure of the document has implications on its layout even leaks through when using CSS. For instance, assigning a value of absolute to the position attribute of an element, positions it relative to its ancestor in the document structure. But, it's when "pure" layout is involved that things become murkier. We suddenly want to disavow that the natural layout clues are already there and instead force this unnatural separation into CSS. The problem is that much like with tabular data or a series of paragraphs, all content on a page has a relationship to other content that is best expressed in a natural grid like structure. It's not just visual, but actually semantic. So, it is natural to express this relationship in the markup and leave the styling details to CSS. Perhaps more importantly, it is unnatural to spit a bunch of related content into a document in a completely unstructured fashion, then impose structure in a separate document. So, let's not repeat the ideological mistakes of the last Great War. Ask your Congressperson to keep the grid element out of CSS (except for styling) and add it to HTML where it belongs! :)