Some interesting developments on use of tables for presentation at the W3 HTML working Group.
The proposal for tables.
The Objection Poll.
The proposal against tables.
Hmm, seems like a storm in a teacup to me. "Must not" vs "should not" seems pretty trivial. It's like saying that a hammer is for hitting nails and therefore *must not* be used for something else. It can be used for all sorts of things, even if it's not the ideal tool for those activities. There are many reasons why tables shouldn't be used for presentation, but the world isn't going to end if someone does use them for that purpose. And anyone who has to create HTML emails realizes that some media are just not ready for non-table layouts … sad as that is.
I agree, that there should be a push for disallowing tables for presentation. However the sword is two sided. The role="presentation" might work, that is if the end user has the most up to date software, which we shouldn't assume. I discussed the reason why we can't in another thread the other day. On the other hand, people who are using tables for layout probably wouldn't know about or implement the role. So, it would go unused. Another reason layout tables may still be used is if you are in a very limited lab type setting, where something like IE6 has to be used for security reasons.
Actually, while typing this, I would advocate that the name of the value of the attribute should be changed to presentation-table, or presentationTable. I find that a number of attributes overlap, renaming it would make it more clear.
Why should tables not be used for presentation. With IE6 and IE7 dying off we are getting close to the point where it will be perfectly practical to use the CSS table commands and have them work correctly for presentation.
Of course that's another argument against using the HTML table tags for that purpose.
So once IE7 and earlier are dead we do have presentation tables available.
So for a data table we have:
and for a presentation table we have:
<div class="table"><div class="tr"><div class="td">
All of the links Vic referred to is regarding the table tag in HTML. Nothing I saw referred to CSS alternatives. I think using divs to make a layout table is fine from an accessibility point of view. I would love to see how nasty the code would be to build a layout in a CSS table format. Then have a discussion on how a CSS table layout is so different than floating blocks, etc using CSS.
Switching from using HTML tables incorrectly for presentation to using the CSS equivalent would be as simple as substituting the divs with the appropriate classes for the table tags. The only limitation is that it only supports the latest two versions of IE and not IE7 or earlier.
i mean, try explaining to a noob why the table tags are perfectly okay to put data into, but all of a sudden are bad for presentation whereas that other div crap, which bends over backwards to work like a table without actually being a table, is more acceptable...
I agree with you that it not only looks bloated, it actually is. I was simply pointing out that it is possible to do a direct substitution like that so as to convert from using tags in HTML that have a semantic meaning for something where that meaning doesn't apply to using tags that don't have a specific semantic meaning that achieve exactly the same result and so the suggestion of a <presentation-table> tag is unnecessary.
That also makes the proposal to change the meaning of the table tag so as to allow its use for presentation meaningless since such tags for that purpose already exist (even if they are bloated).
I never said it was a good idea to use tables (either HTML or CSS) to do the entire layout of a web page. Even when using CSS tables their use for laying out an entire page would be inappropriate as that would just reporduce most of the same issues that exist if you use HTML tables for layout.
Of course those who still believe in using tables for layout will never really realise how wrong that they are until they have a web site of several thousand pages where the layout of all of the pages is to be altered and it ends up taking them months tomake the change instead of minutes.
One of the biggest reasons for not using tables for a layout is you can't easily "break out" of them if you wanted.
For example, if I have three division elements (let's say A, B, and C) each of which essentially form a row. If I had a table equivalent (so A, B, and C formed a single-column table), there isn't really any problem with tables, divs, or whatnot.
However, if you one day decide that you want to change the layout of A, B, and C so you have A on the left and B, C on the right. That's a fairly quick and easy change with CSS on divs. However, that'd be very difficult and ugly to do with tables, and maybe impossible to get cross-platform.
I don't use them purely on the semantic basis (and will probably skip CSS tables because I'm not a fan of grid-based layouts because you either have to shift everything to fit your grid, or make your grid of 1000 columns to get everything on them).
These terms are actually defined here RFC 2119 - Key words for use in RFCs to Indicate Requirement Lev (RFC2119)
At first, I was a bit annoyed by this news, but thinking about it - it is positive.
It's not like they've said you should use them, they are still recommending against it. So we've gone from a situation where they said you must not do it, and many people ignore them and do it anyway, to one where they say you should not do it, and people will ignore them anyway.
Anyone opposed to tables for layout will continue with css, and vice versa. It will make no difference in general to who uses what, but it does add the ability to assign the presentation role to the table to flag to the browser that it isn't tabular data, a positive.
I still disagree with the practice, but this decision seems sensible to me.
Stephen I suggested the value to be changed from presentation to presentation-table. I didn't mean a new tag to be made. One things ARIA is kind of frowned upon is there area lot of roles that overlap, and a few of them make you stop and debate which to use. So clearly demarking it as a presentation-table makes it that much clearer. Presentation may lead to people think it is for putting it on a wall like a PowerPoint.
A presentation table makes no sense whatsoever when someone is using a web reader. There the order that the page ought to be read out in is unlikely to match the order that a table would require it to be in regardless of how the table is generated (except if the table contains tabular data where the headings and content can be connected).
What is a web reader? I am missing your point of the post.
That makes be shiver. I think you just meant to show the concept, but if I ever saw that exactly in production HTML I would need a drink (I've seem similar though it was a acceptable edge case).HTML Code:
<div class="table"><div class="tr"><div class="td">
As of late the w3 just seems like to stir the pot. Must not to should not… w/e like either side gives a damn. The problem will always lie with defining what a "presentational table" is from a technical stand point. Is it a table with images in it, blank cells, etc? – there are just to many possibilities. In the end any restraints from a technical stand-point would restrict an legitimate edge case resulting in a hack or none semantic HTML for cases that do have "legitimate" purposes but fall under the definition of a "presentational table".
There are a significant number of web users who are blind and therefore rely on what their web reader tells them is the content of the page. There are even several blind people using web readers to interact with this forum but it is impossible to tell who they are because they can use the internet just as well as sighted people can just as long as the web page doesn't content the really scramble.
To0 properly experience the web via a web reader you should blindfold yourself and rely on the pips on the home keys of your keyboard to work out what you are typing as well.
Any proposal to "allow" presentation tables in HTML now is like getting a locksmith in to fix the lock on your front door after the rest of the house has collapsed. The last possible eason for misusing tables in HTML will die when IE7 does and that doesn't appear to be too far off now as the percentage of people using such antiquated versions of IE is now falling so rapidly that the need to support that browser hasn't got long to go.
Seems another backwards step to me and will more likely encourage the use of nested tables that we have just about managed to clear up over many many years.
It will have the same detrimental effect on quality code that html5 is starting to show us now in the forums. The quality of code has dropped and people are being careless again.
e.g. "I can nest anchors around block elements in html5 so its ok to nest spans around block elements - it still works!" (answer ....no it doesn't it often breaks.)
I don't see display:table; being a viable layout option. One of the principal strategies for using layout tables is colspan/rowspan, which is very easy to do with <table> elements ... not sure that it would be so easy with mock-tables.
What we need is a working 'visual' layout method in CSS if we're going to wean the remaining layout-table-ites onto better coding practices. Using display:table; is the worst of both worlds - it embeds and ingrains bad coding and layout practice but loses a lot of the flexibility that tables innately have.
hotkeys to navigate tables, which is great if you are in a data table, but not in a layout table. Since you can identify <th scope="col"> or using <td headers=""> the table will be read slightly differently. Juicy Studio: Complex Table Inspector. I simply am advocating that the value of the role attribute should be more descriptive.
CSS2 - The display declaration. I haven't found a good row/col-span example yet.
Not sure why oddz is shivering...
doesn't look too different fromCode:
other than tags :shrug:Code:
I never could, never will touch-type. Luckily I can have the reader read out the letters I type if I'm typing on screen. But that's so hideously slow... so I stare at my keyboard instead, lawlz. And I'm on a laptop so I can sudo vbetool dpms off... not that that always works *frustration*Quote:
yourself and rely on the pips on the home keys of your keyboard to work out what you are typing as well.
I wondered if this was someone's idea of making layout tables somehow better for AT.
JAWS will (or at least the older versions did) try to guess if a table is a real table or a layout table, based on td widths (and some other things). This means it won't always get it right... whereas, maybe the idea was that if the author were to put the role in manually, that the reader would get it correct more often.
But, as someone already pointed out, people who use tables for layout don't use roles. This won't affect any pages with layout tables until CMSes start automatically adding role attributes to stuff (I'm waiting for it... dreading it too).
Not sure why oddz is shivering...
is an abomination unto teh Lawd compared to this:Code:
Which is, I assume, what oddz was thinking.Code:
Well since it's the last of the list on the pageQuote:
I simply am advocating that the value of the role attribute should be more descriptive.
The Roles Model | Accessible Rich Internet Applications (WAI-ARIA) 1.0
I don't see anyone making different versions of the role for each of those (and truthfully I don't understand the img example).
LAWLZ <div class="clear" role="presentation"></div>
I don't get that one at all, since empty elements for "clearing" (ack) or CSS hooks aren't posing a problem today anyway.
Basically a role for crappy markup should be called what it is:
Well my example was a simple table. I didn't want to make multiple rows/cols.
I don't get what you are getting at. Take a glance at WAI-ARIA Taxonomy, wouldn't you say having an explicit presentationTable branch would be nice.
Well yeah, if "hello" is a paragraph than using a paragraph tag would be appropriate. However, if "hello" has of a collection within a data grid than a table would be much more proper than hacking one except when dealing with rare edge cases.