> 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.

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)).

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.

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.

> 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.

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.

You mean a table with many columns, don't you?

Ah! Yes, indeed! Thank you.

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.

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).

But what's the current day scenario when you have to support old IEs? Security updates are only being provided for IE 11, which hopefully makes it default to the corporate sphere.

Other elements besides div just have a different default style. These default can be overridden in CSS. If you would like to start with a "blank slate" where all elements have the same defaults, you can use a CSS reset. There is really no good reason to not use the semantic elements when appropriate.

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.

>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`

Yeah but why not just use HTML tables? It simpler and easier and more correct.

Because HTML table elements are treated differently by assistive technologies.

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.

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.

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.

MDN is nice, but the W3C standards for HTML and CSS are actually pretty easy to read.

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...

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.

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.

My experience has been quite opposite. In fact, most of the HTML I've worked on was written by developers whose primary focus is server-side Java.