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.
Yes, it is very different - CSS tables work the same way HTML tables do (which is what you'd expect since the default for <table> is display:table, the default for <tr> is display:table-row and the default for <td> is display:table-cell) and so the two example codes I mentioned are identical in how they work except in IE7 and earlier except that one is using tags that semantically identify the content as tabular data and the other uses semantically neutral div tags so that it implies nothing whatever about the content.
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.
does the presentational css look bloated to anyone else but me?
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...
That code was a response to the suggestion about introducing a <presentation-table> tag as I was simply pointing out that one already exists.
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.
people who use tables for layout would question what those issues are
i hasten to add that i do not include myself among them, but also that i don't really see any serious issues either
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).
"Must not" is actually a prohibition of the use, whereas "should not" is a strong suggestion not to use 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.
The CSS version is stil shorter - plus it can be applied just to specific media.
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.
<div class="table"><div class="tr"><div class="td">
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).
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".
A web reader speaks the content of the web page instead of displaying it. So imagine that your screen is turned off and your computer speakers are the way you interact with the web page. The we b reader converts the web page into something your speakers can output but with a layout table the cells will almost certainly be read in the wrong order.
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.
Yes I was intending to show just the concept. Actually rewriting the HTML to work like that is no better than having the tables there in the first place (yes seeing it in production would and should drive people to drink). It does however demonstrate that where table like layout is required for a part of a web page that the appropriate CSS display values can be used to achieve it without needing to add a table into the HTML.
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.)
Of course, using child selectors would mean you'd only need class="table" and not classes for the rows or cells.
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.
Sadly, that's true - but no great surprise given the gems of wisdom that are foisted on us on a regular basis.
next page →