12 ms·

Why is it not okay to use tables for styling purposes? Why is it okay to use multiple nested divs, but not the table/tr/td tags? Are there any practical reasons

by jakobe 13y ago

Why is it not okay to use tables for styling purposes? Why is it okay to use multiple nested divs, but not the table/tr/td tags? Are there any practical reasons, besides the goal of making the markup more 'semantic'? Are there any screen readers that can't handle table tags? Or do some crawlers choke on tables? 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.

mattvot 13y ago
see http://stackoverflow.com/questions/83073/why-not-use-tables-for-layout-in-html http://stackoverflow.com/questions/83073/why-not-use-tables-...
- rhizome 13y ago
  Thanks for this, but of course the question got closed.
  - taejo 13y ago
    I don't see the problem: there's a question, there's a good answer, so it's closed. Not everything has to be an on-going debate.
    - desas 13y ago
      That's not what happened. There's a question, it isn't the sort of question the stack overflow wants to have, so it's closed. For a change it's actually a close decision that was a good one.
sopooneo 13y ago
I used to hear that dogma too. And then all of a sudden I'm reading everywhere that I should check out bootstrap.css, which flies straight in the face of semantic markup by requiring you to use class names that are descriptive of their layout effect. I don't know if there is overlap between the evangalizers of semantic markup and bootstrap.css, but if so, it would seem contradictory.
- ricardobeat 13y ago
  Classes and IDs have no semantic purpose in HTML[1]. Bootstrap's approach is bad from a developer's perspective, but is not bad as long as you use the right elements. [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
- woah 13y ago
  I used to be against class names that are descriptive of their layout effect, but honestly, it's the simplest way a lot of the time. You can't always think up the exact right name for a random element somewhere on a site, and getting into the habit of using sane oocss can save a bunch of time.
ricardobeat 13y ago
Being "semantic" (your quotes) is not an abstract concept or dogma. This discussion has been exhausted as far back as 2005. A more practical explanation: 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.
- wwweston 13y ago
  If using tables for layout broke non-screen user agents (like screen readers and Google), then the web must have been more or less unusable by them until at least 2005. We know that's not true for Google, at least, and by 1999, Lynx actually had some capability for dealing with them. 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.
  - 13y ago
joshuak 13y ago
I have the exact same issue. I find it much less semantic as well as less readable and maintainable to use abstract markup (i.e. div) everywhere. <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>
- ricardobeat 13y ago
  It's not the exact same issue, it's the exact opposite. Using meaningful markup (not div) where it shouldn't exist is more harmful than the contrary. Not using tables for layout doesn't mean you can't use tables at all - use tables for tabular data. 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.
  - joshuak 13y ago
    I think we are agreeing, and I don't mean to spin up the same debates. I'm just saying that as it is html presumes that the important content is the text and throws everything else over the fence. It implies that you are done with translating for all displays if you just follow proper html best practices, when in fact you should consider targeting your content for specific displays in many cases. 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.
keeperofdakeys 13y ago
The CSS "display: table" and "display: table-cell" are designed to act exactly like their html counterparts. 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.
aethr 13y ago
Just a small example, as I didn't see it mentioned in other replies. 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.

by jakobe 13y ago

mattvot 13y ago

see http://stackoverflow.com/questions/83073/why-not-use-tables-for-layout-in-html http://stackoverflow.com/questions/83073/why-not-use-tables-...

rhizome 13y ago
Thanks for this, but of course the question got closed.
- taejo 13y ago
  I don't see the problem: there's a question, there's a good answer, so it's closed. Not everything has to be an on-going debate.
  - desas 13y ago
    That's not what happened. There's a question, it isn't the sort of question the stack overflow wants to have, so it's closed. For a change it's actually a close decision that was a good one.

sopooneo 13y ago

I used to hear that dogma too. And then all of a sudden I'm reading everywhere that I should check out bootstrap.css, which flies straight in the face of semantic markup by requiring you to use class names that are descriptive of their layout effect. I don't know if there is overlap between the evangalizers of semantic markup and bootstrap.css, but if so, it would seem contradictory.

ricardobeat 13y ago
Classes and IDs have no semantic purpose in HTML[1]. Bootstrap's approach is bad from a developer's perspective, but is not bad as long as you use the right elements. [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
woah 13y ago
I used to be against class names that are descriptive of their layout effect, but honestly, it's the simplest way a lot of the time. You can't always think up the exact right name for a random element somewhere on a site, and getting into the habit of using sane oocss can save a bunch of time.

ricardobeat 13y ago

Being "semantic" (your quotes) is not an abstract concept or dogma. This discussion has been exhausted as far back as 2005. A more practical explanation: 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.

wwweston 13y ago
If using tables for layout broke non-screen user agents (like screen readers and Google), then the web must have been more or less unusable by them until at least 2005. We know that's not true for Google, at least, and by 1999, Lynx actually had some capability for dealing with them. 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.
- 13y ago

joshuak 13y ago

I have the exact same issue. I find it much less semantic as well as less readable and maintainable to use abstract markup (i.e. div) everywhere. <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>

ricardobeat 13y ago
It's not the exact same issue, it's the exact opposite. Using meaningful markup (not div) where it shouldn't exist is more harmful than the contrary. Not using tables for layout doesn't mean you can't use tables at all - use tables for tabular data. 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.
- joshuak 13y ago
  I think we are agreeing, and I don't mean to spin up the same debates. I'm just saying that as it is html presumes that the important content is the text and throws everything else over the fence. It implies that you are done with translating for all displays if you just follow proper html best practices, when in fact you should consider targeting your content for specific displays in many cases. 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.

keeperofdakeys 13y ago

The CSS "display: table" and "display: table-cell" are designed to act exactly like their html counterparts. 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.

aethr 13y ago

Just a small example, as I didn't see it mentioned in other replies. 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.