Very vague article, indeed, looks like they're mainly trying to stir some hype for their book. Praising css tables as "the next big thing" is just backwards. Matt Wilcox has a good article about that misconception: http://mattwilcox.net/archive/entry/id/1030/
The take-home is that css tables are really not much more than the old table tag in disguise - with all the same ties between markup and presentation. If that's what rocks your boat then you don't have to wait - the table tag is here for you to use, today.
Well, all of CSS is the HTML layout model in disguise.
The lack of IE support for display:table has lead to a number of myths, one beeing that the CSS layout model is somehow different from the defacto HTML layout model. It is not. The CSS layout model was from the beginning modelled as close as possible after the de-facto layout model of presentational HTML. For example, floats are not an CSS invention, they are just a reverse-engeneering of the good old align="left" attribute which Netscape invented.
The difference is just that CSS gives more fine-grained control, and that CSS allows better abstration and seperation between markup and presentation. This is obviously good in itself, so clearly display:table is an improvement over HTML tables - but not in its layout capabilities.
What improvement over HTML tables does display:table provide?
I see none. It requires the identical nested markup, except that all your tr's and td's are called div now. Really, why would anyone even consider using display:table instead of a plain old <table>?
- Seperation of content and presentation. The benefit should be obvious if you remember having to use FONT-tags rater than CSS to style your content.
- You don't have to give a degraded user experience to disabled users. I know many don't consider this a big deal, but all things being equal, wouldn't you prefer not to annoy disabled users?
BTW. It does not require identical amount of markup as tables, due to the concept of anonymous table elements (http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes) which allows you to use only the minimal amout of markup necessary to delimit the elements you want to style.
I think your first point is invalid. Using either kind of table marks up your content with presentation details. There is no difference between <table><tr><td></td></tr></table> and <div><div><div></div></div></div> here. The nesting exists solely to represent the tabular structure.
About the second point: I don't know. Do the old <table>s degrade worse than the new fangled stuff? I'd think that the related tools (screenreaders and such) would have better support for something old than for something new, but frankly I'll give you this as I have no idea.
And wrt anonymous tables: How does that help?
It's nice that we can omit parts of the boilerplate markup but that doesn't change the fact that we're mixing presentation details into the content.
It's not really a case of TABLE-elements versus DIV-element. It's a case of semantic markup or not. If something is semantically a table (i.e. data which is not just liniear but structured along two axes) then use table-markup.
A good rule of thumb is to decide if a structure is semantically a table, is to consider if it would make sense with headers (TH-elements) in the first row and the first column.
If something is not semantically a table - e.g. you have a linear list of items - then you don't use either DIV's or TABLE's, but rather the appropriate markup which is UL og LI elements. DIVs are semantically neutral, so you shouldn't really need them often. Mostly they are used precisely to overcome limitations in the CSS implementations in current browsers. DIVs are useful though when there is some structure which dosn't have an appropriate element defined in HTML, eg. there is no "footnote" or "header"-elements in HTML, so you use DIV to mark these elements.
With proper semantic markup you can use CSS to control if your list of items should be displayed as a bulleted list (display:list-item) or as cells in a grid (display:table-cell) or whatever - without changing the markup. This is a pretty nice seperation. Again, it doesn't give you any new layout power but it allows you to structure your code in a more maintainable way and produce better markup.
Regarding screenreaders the issue has nothing to do with degrading. The issue is that a screenreader which understands table semantics may allow the reader to navigate in two dimensions, explain the headers in both dimensions associated with a cell and so on. But if table markup is used both for 2D data sets and for all kinds of layout purposes like positioning an image or whatever, then this feature becomes useless or at least annoyning.
The review is pretty vague, but presumably the book is about the display: table CSS property, which IE8 will support as the first IE browser.
The review says "the techniques that will be available to us very, very soon." Actually the techniques have been available for years in the other browsers, but obviously couldn't be used widely since IE didnt support it. The release of IE8 will not change that because IE7 (and even IE 6) will be around for many years to come.
But of course it is a step in the right direction.
No, its about the new display: table property, which really will make life easier. However, IE 6 and IE 7 don't support it, so in about 5-10 years this book will be relevant.
