5 ms·

It is fascinating how a perfectly sensible rule-of-thumb "you shouldn't use html tables for something which is not semantically a table" gradually morphed into

by olavk 10y ago

It is fascinating how a perfectly sensible rule-of-thumb "you shouldn't use html tables for something which is not semantically a table" gradually morphed into various superstitions like "you shouldn't use html tables" or "you shouldn't use tables for layout" or even "you shouldn't use tables". I don't think people have a hard time understanding that you shouldn't use the <blockquote>-element for something which is not a quote. But html tables had a more troubled history because for a long time html tables were the only way to achieve certain layout effects, which was not supported by pure CSS in mainstream browsers, because they didn't implement "display:table". This article is well-intentioned but I think it also contains some language which muddies a pretty simple concept. Eg. it states CSS Table has a key differentiation over HTML Table. It can choose not to be a table by just adjusting its CSS properties. Something that HTML Table is incapable of. The sentence seem to confuse semantics with presentation, which is what got us into this mess in the first place.

beaconstudios 10y ago
it seems to imply that semantics somehow matter when it comes to CSS - where the whole point of CSS is to extract the non-semantic styling into a separate document so that the structure of your HTML can have meaning.
achairapart 10y ago
On the other hand, there are cases where HTML Tables put great challanges to user experience. First to come to mind: A table with many rows displayed on a tiny mobile screen. The most common solution is to let the table overflow horizontally. There are other complex solutions, most of them fall in the CSS-Hack category. In this case, to have a CSS table that can be something else on a tiny screen (via media queries) may lead to a successful UX solution.
- Gorgor 10y ago
  You mean a table with many columns, don't you?
  - achairapart 10y ago
    Ah! Yes, indeed! Thank you.
- throwanem 10y ago
  This makes sense to me. In the MySQL monitor, you can terminate a statement with ; for tabular view, or with \G for a linear view that represents each row as a key-value list. This is super useful for reading wide rows in narrow terminals. I can very easily see the appeal of doing the same for wide tables on narrow displays.
- olavk 10y ago
  But you don't choose between HTML tables and CSS tables - they are independent concerns, HTML is semantics, CSS is presentation. HTML table elements just have display:table as the default style (in the default browser style sheet). You can override this in a style sheet as with any other style. And conversely, you can apply display:table to any element regardless of HTML semantics. It is true older browsers had partially hardcoded presentation so you couldn't always override the default CSS of certain elements (table elments and form controls were especially notorious for hardcoded presentation). But I believe this is not an issue in modern browsers.
  - gsnedders 10y ago
    > But I believe this is not an issue in modern browsers. I think the last browser that saw widespread use in any market with that issue was NN4. In some markets, Opera [some version; 7?] with the same issue will have been a problem much later than NN4. Really, this is to say: this hasn't been a concern for well over a decade at this point even with fairly generous browser support matrices.
codedokode 10y ago
That is because people who do HTML markup are usually not developers. They are either wannabe developers or just incompetent people hired to reduce costs. They would never waste their time on reading something complicated as W3C standards and understanding concepts like semantic markup.
- tangue 10y ago
  I'm curious about who read w3c standards, even on HN. I don't. Even MDN (which I consider as fork of w3c for humans) can be quite confusing so let's not judge people on this.
  - toxican 10y ago
    I don't think I've ever actually read the standards and I've been doing this 12 or so years now. I just kind of picked up on what was considered kosher and what wasn't over time. And then when having a "XHTML STRICT" badge in your footer was all the rage, I learned a bit more by having to tweak my code to earn it. imo, there are a lot of different paths to being a good developer. Personally I find scouring over the standards or some dry reference site to be about the most painful way.
    - codedokode 10y ago
      It is interesting that when XHTML was popular most people actually made and served HTML pages (with content type text/html) even if they had a XHTML doctype. That is why this standard was dead from the beginning. Though personally I like the idea of not displaying the page if there is any error in the code.
  - olavk 10y ago
    MDN is nice, but the W3C standards for HTML and CSS are actually pretty easy to read.
  - codedokode 10y ago
    I did when I was a beginner developer and wanted to understand CSS better. MDN doesn't help much if you want to understand for example how element dimensions are calculated, and W3C has a detailed description [1]. I haven't seen a better explanation yet. [1] https://www.w3.org/TR/CSS2/visudet.html#Computing_widths_and_margins https://www.w3.org/TR/CSS2/visudet.html#Computing_widths_and...
Waterluvian 10y ago
Largely because I'm relatively new to all of this and probably don't know better, but I've found success just using divs for all layout and doing it myself. Which is a smell to me, but I just can't help but find that every time I have consistent results and expected behaviour. Div and flexbox for everything. It actually reminds me of another smell I have with django: write my own serializers and views rather than using any of the magical ones. I tried so hard to use the freebies but the moment you want something that isn't exactly as prescribed, it becomes a disaster. That's been my experience with CSS and HTML layouts.
- toxican 10y ago
  In terms of results, responsiveness, and flexibility, doing it with a div (or some other block-level element) and flexbox is the best way to do it. In terms of standards and tabular data, doing it with a table is probably more correct, but I think the benefits of flexbox outweighs any concerns about that.
  - SippinLean 10y ago
    >In terms of standards and tabular data, doing it with a table is probably more correct I haven't tested it, but I assume you could fake the semantic part of a "CSS table" with something like `role=grid`
    - olavk 10y ago
      Yeah but why not just use HTML tables? It simpler and easier and more correct.
      - spdustin 10y ago
        Because HTML table elements are treated differently by assistive technologies.
- allover 10y ago
  You're very lucky to be new to this! If you have success with div and flexbox for everything, then I'm guessing you're not supporting old IEs. You're lucky to have skipped the years of pain in which flexbox simply wasn't an option (for many devs that have to support IE it's still not).
luhn 10y ago
> It is fascinating how a perfectly sensible rule-of-thumb "you shouldn't use html tables for something which is not semantically a table" gradually morphed into various superstitions like "you shouldn't use html tables" or "you shouldn't use tables for layout" or even "you shouldn't use tables". It's always bugged me to see the great lengths people will go to to avoid using an HTML table to create things like a calendar. A calendar is a table! Save yourself the effort and use <table>. It's not only easier, it's semantically correct as well.
- olavk 10y ago
  I think many people is confused by "semantically a table" because they think of a table as a certain visual representation of data, which also how the word is often used. The semantic definition of table in HTML is a bit more subtle - it is a set of data structured in two dimensions. (Like how the days in a monthly calendar is grouped by week (horizontally) and by day-of-week (vertically)).

by olavk 10y ago

beaconstudios 10y ago

it seems to imply that semantics somehow matter when it comes to CSS - where the whole point of CSS is to extract the non-semantic styling into a separate document so that the structure of your HTML can have meaning.

achairapart 10y ago

On the other hand, there are cases where HTML Tables put great challanges to user experience. First to come to mind: A table with many rows displayed on a tiny mobile screen. The most common solution is to let the table overflow horizontally. There are other complex solutions, most of them fall in the CSS-Hack category. In this case, to have a CSS table that can be something else on a tiny screen (via media queries) may lead to a successful UX solution.

Gorgor 10y ago
You mean a table with many columns, don't you?
- achairapart 10y ago
  Ah! Yes, indeed! Thank you.
throwanem 10y ago
This makes sense to me. In the MySQL monitor, you can terminate a statement with ; for tabular view, or with \G for a linear view that represents each row as a key-value list. This is super useful for reading wide rows in narrow terminals. I can very easily see the appeal of doing the same for wide tables on narrow displays.
olavk 10y ago
But you don't choose between HTML tables and CSS tables - they are independent concerns, HTML is semantics, CSS is presentation. HTML table elements just have display:table as the default style (in the default browser style sheet). You can override this in a style sheet as with any other style. And conversely, you can apply display:table to any element regardless of HTML semantics. It is true older browsers had partially hardcoded presentation so you couldn't always override the default CSS of certain elements (table elments and form controls were especially notorious for hardcoded presentation). But I believe this is not an issue in modern browsers.
- gsnedders 10y ago
  > But I believe this is not an issue in modern browsers. I think the last browser that saw widespread use in any market with that issue was NN4. In some markets, Opera [some version; 7?] with the same issue will have been a problem much later than NN4. Really, this is to say: this hasn't been a concern for well over a decade at this point even with fairly generous browser support matrices.

codedokode 10y ago

That is because people who do HTML markup are usually not developers. They are either wannabe developers or just incompetent people hired to reduce costs. They would never waste their time on reading something complicated as W3C standards and understanding concepts like semantic markup.

tangue 10y ago
I'm curious about who read w3c standards, even on HN. I don't. Even MDN (which I consider as fork of w3c for humans) can be quite confusing so let's not judge people on this.
- toxican 10y ago
  I don't think I've ever actually read the standards and I've been doing this 12 or so years now. I just kind of picked up on what was considered kosher and what wasn't over time. And then when having a "XHTML STRICT" badge in your footer was all the rage, I learned a bit more by having to tweak my code to earn it. imo, there are a lot of different paths to being a good developer. Personally I find scouring over the standards or some dry reference site to be about the most painful way.
  - codedokode 10y ago
    It is interesting that when XHTML was popular most people actually made and served HTML pages (with content type text/html) even if they had a XHTML doctype. That is why this standard was dead from the beginning. Though personally I like the idea of not displaying the page if there is any error in the code.
- olavk 10y ago
  MDN is nice, but the W3C standards for HTML and CSS are actually pretty easy to read.
- codedokode 10y ago
  I did when I was a beginner developer and wanted to understand CSS better. MDN doesn't help much if you want to understand for example how element dimensions are calculated, and W3C has a detailed description [1]. I haven't seen a better explanation yet. [1] https://www.w3.org/TR/CSS2/visudet.html#Computing_widths_and_margins https://www.w3.org/TR/CSS2/visudet.html#Computing_widths_and...

Waterluvian 10y ago

Largely because I'm relatively new to all of this and probably don't know better, but I've found success just using divs for all layout and doing it myself. Which is a smell to me, but I just can't help but find that every time I have consistent results and expected behaviour. Div and flexbox for everything. It actually reminds me of another smell I have with django: write my own serializers and views rather than using any of the magical ones. I tried so hard to use the freebies but the moment you want something that isn't exactly as prescribed, it becomes a disaster. That's been my experience with CSS and HTML layouts.

toxican 10y ago
In terms of results, responsiveness, and flexibility, doing it with a div (or some other block-level element) and flexbox is the best way to do it. In terms of standards and tabular data, doing it with a table is probably more correct, but I think the benefits of flexbox outweighs any concerns about that.
- SippinLean 10y ago
  >In terms of standards and tabular data, doing it with a table is probably more correct I haven't tested it, but I assume you could fake the semantic part of a "CSS table" with something like `role=grid`
  - olavk 10y ago
    Yeah but why not just use HTML tables? It simpler and easier and more correct.
    - spdustin 10y ago
      Because HTML table elements are treated differently by assistive technologies.
allover 10y ago
You're very lucky to be new to this! If you have success with div and flexbox for everything, then I'm guessing you're not supporting old IEs. You're lucky to have skipped the years of pain in which flexbox simply wasn't an option (for many devs that have to support IE it's still not).

luhn 10y ago

> It is fascinating how a perfectly sensible rule-of-thumb "you shouldn't use html tables for something which is not semantically a table" gradually morphed into various superstitions like "you shouldn't use html tables" or "you shouldn't use tables for layout" or even "you shouldn't use tables". It's always bugged me to see the great lengths people will go to to avoid using an HTML table to create things like a calendar. A calendar is a table! Save yourself the effort and use <table>. It's not only easier, it's semantically correct as well.

olavk 10y ago
I think many people is confused by "semantically a table" because they think of a table as a certain visual representation of data, which also how the word is often used. The semantic definition of table in HTML is a bit more subtle - it is a set of data structured in two dimensions. (Like how the days in a monthly calendar is grouped by week (horizontally) and by day-of-week (vertically)).