On 17 March 2011 17:32, Christian Ziebarth <[email protected]> wrote: > Several years back I suggested a GRID element that could be used for > presentational, layout purposes to obviate the need for hijacking the TABLE > element for something it wasn't made for. It was on this very list but was > considered to be an HTML subject, not a CSS one, so I was asked not to > discuss it here anymore.
I appreciate these things are incredibly difficult to talk about as distinct (arguing about CSS in a vacuum, without its necessary implication of HTML to work with, is apparently a job exclusively reserved for the CSS working group ;). Personally, I'm often dismayed at how little the emerging specs consider real use-cases. The tragedy with table presentation — even as faked via CSS display properties — is that the tabular format of a pre-definite X by Y grid is often completely besides the point of what people want when they employ table-based layout: the properties that people crave are incidental aspects of table-cells that have nothing to do with tabular data requirements and could easily be applied without those, namely: • Wrapping contents (achieved with the non-spec zoom in IE and the hacky .clearfix:after in other browsers) • Sequence of elements filling the width of their parent (stubbornella's OOCSS grids.css) • Vertical alignment control (impossible without scripting as far as I've seen) None of these things are achievable with concise built-for-purpose valid CSS in cross-browser methods without tables, and yet none of them are particular requirements of tabular data, or are necessarily tied to the inherent properties of an X by Y grid — but layout rendering logic available to even the most basic graphical browsers can easily compute these requirements if and only if table structure is invoked. It's a bit pathetic we still can't get there without scripting. > The "tables for layout" issue has caused untold grief in 13 years of web > development for me. I didn't even start out using tables to lay out the > websites I created but when I got my first professional job in the field I > was told I should use them. So I did. Then I began transitioning to using > CSS for layout but continued to use tables for their proper purpose: > presenting tabular data. But then I encountered prospective employers who > had heard the mantra "don't use tables for layout" but misheard it as "don't > use tables for /anything/" who told me they couldn't hire me because they > found TABLE elements in my markup in sites in my portfolio. Now the HTML > Working Group says, "Yeah, go ahead and use tables for presentational > purposes." Ugh. Can't win for losing. I've been there. Personally I sympathise with the 'tables for layout != death' camp and many of the myth-busting statements in the working group email chime with me: tables don't break screen reader navigation, don't drive hypothetical user agents into some hypothetical 'cannot compute semantics' meltdown, etc, etc. Just a shame that collectively the CSS and HTML specifications see the solution as being a lowering of targets. Mediocrity (ie nobody) wins — except for the GMail team and people who haven't updated their sites since the early 90s, who will now get to put shiny HTML5 stickers on their sites. > Christian Z. > > P.S. We shouldn't complain about Google throwing their weight around when we > as a society have erroneously acted like theirs is the only search engine > that could ever yield legitimate results. …Although I can forgive people for not realising the eventual scope of their influence! ______________________________________________________________________ css-discuss [[email protected]] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
