Did some brand-name-search-product-ing (you know I was going to write Googling, but that would be a violation of trademark law!) this morning because I was curious to know if the lack of "colspan" in CSS had been dealt with lately, and I came across a thread where people repeated a rather tired and dubious claim about the wisdom of using tables to lay out a webpage.
OK, so here's the deal. Back when people created documents in wordprocessors rather than HTML, the issue of "How do I do something that requires some complex formatting" would come up periodically. For older systems, you'd use tabs and margins to layout text, but that would have its own problems, not least that the wordprocessor's ability to automatically lay out text (for example, overflow text onto new lines) would be compromised. When tables were implemented, they became the de-facto way to style complex layouts. By creating a grid, and merging cells, and moving the boundaries around, you could get pretty much anything you want that didn't involve overlapping text.
And the same is true of HTML. Early HTML users jumped on tables as soon as they became available and used them for laying out text.
The problem here is that HTML is a "mark-up" language. It's supposed to contain content, with tags describing the context and meaning of the content. And thus the very serious people who define web standards expressed their displeasure at HTML's tables being used like this. Why? Well, because a table is supposed to be... a table. It's a list of related items, using columns or rows to delineate attributes of common entities. And that's just not what you're doing when you use a table to, say, put a menu on the left hand side of the document, a "related links" section on the right, and whatever the user is reading in the center, because none of those relate to one another, and therefore, this is bad practice.
The very serious people came up with "CSS" and stylesheets as a way to solve the layout issues. Used properly, you'd only ever use HTML tables to relate content; page layout would be defined by using CSS to move things around.
So far, so good, and when people tell you "Tables bad", they're usually referring to the above principle. Now, that said, (almost) everyone agrees that the logic that table layouts use happens to be a very good way to lay out content. In some circumstances, it's extremely difficult not to achieve a particular effect using tables.
Even the very serious people agree with this, which is why CSS also has tables. I don't mean allows you to style HTML tables, I mean CSS lets you say "When you see these elements, style them as a table." You do this using the "display" attribute, which can be "table", "inline-table" (handy!), "table-row" and "table-cell".
So, the point I'm trying to make here is that if someone tells you "It's bad practice to use tables" when you propose them to solve a layout problem, you need to slap them and say "No, it's bad practice to mark up layout using the HTML table tag. It's perfectly fine to style something as a table if you need to lay out content according to some kind of grid."
Unfortunately, this brings us back to our original point. There's no colspan equivalent in CSS. As I've said before, I wouldn't have designed CSS the way it's designed, but... the nearest thing there is to a workaround is that for one instance - where you need a single colspan=entire-row, you can style the element in that row as "display: table-caption", but it's kinda ugly and only works for a limited set of circumstances.
Which is a shame, because colspans (and rowspans) are part of what makes table layout logic a great way to lay out content.
No comments:
Post a Comment