I keep hearing this dogma, don't use tables for layout, but nobody has ever explained to me why it is a problem in practice.
HTML is meant to be parsed and interpreted by machines too, with no visual representation. Tags are meta-data about their content. A 'table' element says "I contain tabular data", and user agents will make lots of assumptions based on that. One of the consequences of this is you'll be giving bad data to search engine bots, that's why it's bad for SEO.
HTML is also meant to be used by non-visual interpreters, like screen readers. Assistive technology is not only for the legally blind; visual impairment affects 20-30% of the world's population. We don't see high user %s because they just most won't bother, it's too hard, sites' HTML is broken, it is easier to have somebody look it up for you.
Going on a little more over semantics, there are rules for what elements can contain each other, so that a structure can be inferred based on headings and hierarchy. By not following the rules you are wreaking havoc on this, and preventing aforementioned bots and screen readers from providing meaningful navigation and context for your page.
We were supposed to have a semantic web by now, where every piece of information was annotated with meaningful meta-data, allowing for context-aware applications (add this commenter on facebook; where can I buy this product?; add this event to my calendar). Turns out it's damn hard to get everyone to use markup correctly, or even agree to common formats.
Even if layout tables did present a problem, an easy incremental fix convention (say, `<table class="layout">`) might have been a nice addition to user agents for situations where people either hadn't invested in semantic markup + CSS yet ... or for the layouts beyond CSS capabilities.
That isn't to say that I think everybody should be using tables for layout or CSS completely sucks or we'd all be better off if we were doing layout like the Java/C#/Flash/Python library of your choice does it.
I'm just not sure the "tables break things" argument is particularly strong.
I also think that it could've been done pretty reliably by heuristics. A table that mostly has data cells that contain lots of images or block-level markup as descendants is quite likely a markup table. A table that has mostly text or inline-marked cells and has a full summary attribute or <caption> is all but certainly semantic.
I guess with IE 6&7 all but dead, though, it's sortof irrelevant now -- you can mostly count on `display: table-cell` to help you out of a jam.
<table role="presentation">
Have you experienced this personally, or do you have this on first-hand account, or are you repeating the common wisdom?
Because like I said, Lynx had a way of doing this circa 1999. It mostly ignored tables except a few that met some criteria for likely semantics. So you generally got a cell-ordered page, which worked surprisingly well for most sites. Heck, if you've got a copy of Lynx at hand, fire it up right now and browse HN (which is layed out via table, ridiculous though it is for a site with such a simple layout).
If Lynx can do it, I have trouble believing that deliberately assistive software wouldn't be able to. This matches most of the (admittedly limited) discussion I've had with people who use/write it (an aside: I've also heard that, believe it or not frames were sometimes a big boost to assisted usability).
If you've got personal experience or first-hand accounts, though, I'm interested to hear it.
Lynx is a text-mode browser, not a screen reader; it's still visual. Assistive tech has a whole lot more going on. They have a slew of navigation modes and need cues from content to prevent the user from getting lost, you can't just scroll or look back up to where you where. I recommend looking at the resources below, and trying to use an iPhone or mac with voiceover and screen curtain enabled to really experience what it is like.
http://alistairduggin.co.uk/blog/screenreader-resources/ (collection of videos & articles)
http://www.youtube.com/watch?v=izrC4R7SsH4
http://www.youtube.com/watch?v=S4QBqpU1jj8
http://www.youtube.com/watch?v=AmUPhEVWu_E
http://www.youtube.com/watch?v=vK1tlLOavvM (linked by PavlovsCat below)
Sure. The point isn't that Lynx is an assistive UA, the point is that it's at least one UA that figured out how to throw away layout-purposed table markup (which, like some assistive UAs, doesn't make any sense in its rendering context) and still render (some) markup that represented tabular data.
Is it really the only one?
> Assistive tech has a whole lot more going on. They have a slew of navigation modes and need cues from content to prevent the user from getting lost, you can't just scroll or look back up to where you where
Right, but is that really tied up with non-semantic table use? I'd think it's the presence or absence of things like access keys, title/alt text, and I guess at this point aria attributes that makes the difference, not table markup.
You are underestimating the damage bad markup does, and how deeply assistive software relies on semantics/metadata/structure. As I said, just fire up voiceover and try to browser HN. Actually, I'll quickly do that for you:
I'm comparing table-based HN to one of it's alternative interfaces, not ideal but much better. It's a very shallow example, and I'm using only basic navigation commands - experienced users can use more complicated navigation schemes to discover content, out of necessity - but you get the idea. Lots of noise (row x of x, column xxx..), blank cells are "read", etc. Remember HN is a very simple and spartan website, now imagine what a slightly more complex nested table layout looks like.
Also, see WebAIM surveys for actual assistive tech usage data: http://webaim.org/projects/
It is, however, apparently smarter about the use-semantics of table markup than most screen readers, if I'm to take your example as the norm.
> imagine what a slightly more complex nested table layout looks like.
Having spent more time than I care to remember inside the code of complex nested table layouts, I unfortunately don't really have to work too hard to imagine. :/
> You are underestimating the damage bad markup does, and how deeply assistive software relies on semantics/metadata/structure.
I can see/hear from your example that the table markup is a challenge for voiceover.
I'm not sure I was underestimating the damage repurposed markup does more than I was overestimating the ambitions of assistive UI devs. I'm just astounded that voiceover wouldn't haven't implemented at least a mode for making likely distinctions between table markup that's being used for tabular data and table markup that's being used for layout, when making such a distinction is not only clearly possible but has been done.
Then again, I'm astounded that it's 2013 and Adobe still can't install onto case-sensitive volumes, so there's that.
Some examples from an earlier post:
Hacker News itself: http://stylebot.me/styles/2945 Buzzfeed was particularly fun: https://plus.google.com/104092656004159577193/posts/G6pzJBLK.... NY Times and Edge Perspectives: https://plus.google.com/104092656004159577193/posts/NUMQuQUh.... Basically: if it moves, is fixed, is an interstitial, or is just plain annoying, I kill the hell out of it. And with Stylebot, the easy stuff is just point, click, and "Hide". Then it's gone. Bring it on.
No it really wasn't. A small group of people managed to make it orthodoxy and in the intervening years very few of the supposed benefits have materialised.
In the meantime the same arguments that it is pie-in-the-sky have persisted and events have supported them.
The argument isn't even internally consistent as in the real world people are debating one kind of tag soup vs another. If the only way to create a particular appearance is either using several wrapper divs or a table then you're splitting hairs.
<div><div><div></div></div></div> vs <table><tr><td></td></tr></table>
Is that a semantic difference worth fighting for?
The real gains in the semantic web have come from small targeted blocks of metadata and natural language processing. Not waiting around for everyone to figure out <section> vs <article> correctly.
<clarification> I'm not arguing against the benefits of semantic markup - just that a lot of the hand-wavey "this is semantic and this isn't" advice that gets thrown around is either nonsense or adds such a microscopic amount of semantic information that it's not actually providing any benefit to anyone. The real test is to list actual benefits for actual user agents.</clarification>
Practically, the way it's ended up, the semantics of a div is "some stuff". It's evolved into the go-to method to hide a multitude of styling sins. I don't think there's anything hugely hypocritical in limiting any ugly semanticless hacks to a single generic container like divs.
Put as much as you can into semantic markup, and then anything else you really can't fit into that, favour using div soup over breaking the semantics of another tag.
HTML lacks extensibility. If you want to move beyond classical typography you have to make heinous compromises, and there is no reason <table> should be specially exempt.
<div id="rant"> Presumably the goal is to create a strong separation between layout/design and content as HTML is want to do. However, I don't agree with the premise that design is not content even in the context of translating 'content' to different display systems including for the visually impaired. A movie cannot be automatically retargeted to a blind person by just playing the audio, you must actually do the work translating it to a different form such as a novel, or scene descriptions read aloud. Sometimes as with say a Woody Allen film, you wouldn't miss much if you could only hear it, but something like 2001 wouldn't work so well. Like it or not the internet works exactly the same way, all 'content' does.
Layout and design is content. </div>
Ask a blind person how they feel about you not agreeing that they should have access to the same web you do. They actually do 'watch' movies and TV by audio only. A lot of information is lost, but it's better than nothing. And with a web page using correct markup, a good screen reader interface, and some practice, they can navigate and consume information much faster than we can visually.
I absolutely did not say that a blind person should not have access to the web I said the opposite, a designer should be mindful of their various audiences and design for them purposefully and not expect that a file format can do that for them.
I wish there where layout oriented and data oriented table tags, but there isn't so table gets used for both if you want anyone looking at the code to to get what you're doing. I also wish you could designate where the 'content' actually is sometimes its the text sometimes its the imagery sometimes its the layout. Then at least you'd be clear on where manual translation is required.
It's a hard issue, but the goal of assistive technology is to include people with disability, not segregate. If you want to create a specialized version for them, by all means go ahead, but HTML and ARIA were designed with this goal in mind. I don't think there is a better tool for this.
> I wish there where layout oriented and data oriented table tags [...] I also wish you could designate where the 'content' actually is
That's where `display: table` comes in. New elements in HTML5 allow you to designate content, supporting text, images, navigation areas: main, article, nav, figure, aside, etc. This could already be done with ARIA "role" attributes in HTML4/XHTML.
http://www.youtube.com/watch?v=vK1tlLOavvM <-- Léonie Watson, "Design like you give a damn: Practical accessibility for Web Pros" = very good talk, crucial crash course, and includes a great demonstration of the bit of your post I quoted :D
Great talk!
Slight left turn on the topic, but I think people can lose some elasticity in their thinking when they try to be politically correct. Accessibility implies impairment, but that can give you a mental model of "blind people are people too so we should be careful not to exclude them". But that's bottom up thinking you should be thinking what is possible, or top down thinking.
The mental model is completely different if you take political correctness out of the equation. What if we are talking about a person driving a car using a web interface? Now the user can't see because of a situational limitation not a physical one. There is no need for the implication of sympathy.
It's inspiring to me to design for any IO method I can think of. Aiding accessibility is useful to everyone, but I call that user experience and usability. This is why I get bent on some of the thinking behind HTML. Design, to me, isn't a second class citizen when communicating with your user/audience. New devices show the same information but did we just use the same html and css no we reformatted for the devices. What about when we are all using google glass and web enabled watches?
Granted many web pages that where redesigned for 'mobile' would have done better to leave well enough alone, but that's just bad design.
[icon] item name item date [command] [command 2]
[icon] item name item date [command] [command 2]
1) Why is it called "unordered" when there is still an order? Bad naming ...
2) More importantly, how is the above not tabular data? Who becomes the arbiter of what is tabular, then, if the above is not tabular?
Napkins 21-07-2011 14:52 Change Remove
Pitchforks 21-07-2011 14:52 Change Remove
+-----------------------+
| Napkins (21/07) |
| |
| +--------+ +--------+ |
| | Change | | Delete | |
| +--------+ +--------+ |
+ ----------------------+
Unordered lists mean the order they have is not meaningful. It's physically impossible for something not to have an order...
The whole concept of tabular data is a concession to people who insist that they have to use tables.
[1] search/indexing bots do look at classes to try to make sense of a page, but only because of tag soup and the lack of structural elements before html5
If you are trying to provide a layout for both mobile and the desktop, putting tables in your html will definitely make it harder. If they are in the CSS, you can use two different CSS styles for mobile and desktop.
Often when I write stylesheets for a site, I like to have a default table style. Type, possibly border/spacing, padding, etc, depending on the site. Even if there are multiple visual "types" of tables to display, typically they will all have a common set of margin/padding at the least.
If you wanted to use a table for layout in a site with default table styles, you would have to have a whole set of style resets to get it back to zero layout, before adding your custom layout stuff. This is ugly, and a pain.
One point of using a div for layout style is that it is always "zeroed", and you can assume when styling one that there's nothing that needs to be overriden.
For a change it's actually a close decision that was a good one.