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.

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

For what it's worth, the author mentioned that CSS Flexbox would also work, but the market share of IE 9 was too high at the time for him to use. That was 2014, and now the market share of IE (especially IE 9) is drastically lower.

https://www.w3counter.com/trends

http://caniuse.com/#feat=flexbox

depending on your audience, most of the time you still can't use flexbox today due to ie9/10.

it's really something that after all these years, in 2017, microsoft browsers still find a way to hold back web features.

What audience is that? Who are these people relevant to? Microsoft isn't holding back anything, they can't force these people to update their software. If everyone keeps supporting them, they never will have a reason to update.

Government is one such audience. The K-12 system is another.

Is that really true? You'd think that the government has security provisions that requires software updates.

As for K-12, is that really a requirement in some places, or is it just the case that some clients just happen to not be updated?

IE9 gets security updates on Vista SP2.

More generally IE9 and IE10 are both still supported by Microsoft (for Vista SP2, Server 2008 SP, Server 2008 IA64; and for Server 2012, and Embedded 8 Standard), so it seems entirely plausible Microsoft would sell security updates for other OSes to clients willing to pay for them; they definitely do that for some clients (some still get security updates for XP!).

These outdated OSes have a tiny market share, and more importantly, an organization that prevents sw installation doesn't use outdated OSes. Others can install Firefox even on XP. Old Androids and IPhones are a bigger issue.

There's a polyfill that works well enough.

The anti-table hysteria has vexed me for years. From a purely practical POV tables were simply the only way to achieve things in a broad browser base until only the last few years.

But what really drove me nuts was when that hysteria extended to things that were clearly tabular. I remember trying to copy paste a list of transactions from the Morgan Stanley site and it just didn't work. Confused why I looked at the source and the "table" was in fact just a series of divs with a lot of CSS to make it look like a table. A table could be copied and pasted into a Google spreadsheet trivially. Instead I had to manually reenter the data.

I feel like a lot of this could have been prevent d had we simply created HTML elements called <grid> years ago.

The only problem with display:table is that it still requires additional markup to organize elements in tables. Consider this definition list:

   <dl>
      <dt>Term1</dt> 
         <dd>Term1 defintion</dd>
      <dt>Term2</dt> 
         <dd>Term2 defintion</dd>
   </dl>

and the task of organizing it into two columns table: dt's in first column and dd's in second. Impossible either with display:table & co. or with display flex.

At the same time in Sciter[1] I can define that layout as

   dl { 
      flow: row(dt,dd); 
   } 

- replace dt/dd pairs in table rows. The table will have two columns. Pure styling without changes of markup semantic and structure.

[1] CSS: Flow property and Flex units in Sciter: https://sciter.com/docs/flex-flow/flex-layout.htm

CSS only needs additional elements in case you need to apply structures which is not already present in the HTML. To layout something as a grid you need two levels of grouping: what delimits a cell and what delimits a row. Free-from dt/dd sequences does not contain this information, since there may be multiple dt per dd and vice versa. If dt/dd could only appear in pairs (like in your example) you could say there is an implicit structure, but this is not necessarily the case.

> you need two levels of grouping

Not necessarily.

I can define

   form { flow:row(label, input select textarea); }

to have typical form's two columns layout with all <label>s go to first column and input, select and textarea go to second. All non-matching elements are replaced as if they span full rows (like <caption> in tables).

People at trying to simulate these things by using float and clear. Ugly, non-reliable, etc.

It's already a good idea to add elements where logical, even when unnecessary, to aid styling, scripts, coder comprehension, and sometimes automated comprehension, and to reduce likelihood it must be edited later. One could argue that rows always form logical units - certainly in the above example - and thus should always be wrapped. WHATWG does permit wrapping dt-dd groups in divs.

That "good idea" has a name "tag soup".

But even you can add some non-semantic DOM elements...

What if you have

    <ol>
      <li>first</li>
      <li>second</li>
      <li>third</li>
    </ol>

And you want to replace them in two,three,etc. aligned columns (depending on view size), like these:

   @media handheld {
      ul { flow:vertical; }
   } 

   @media ... {
      ul { flow:row(li,li); } // two columns
   } 

   @media ... {
      ul { flow:row(li,li,li); } // three columns
   }

Not that I diagree with your premise, but in this particular example the WHATWG HTML Living Standard now allows containing divs around dt/dd pairings[1] and browers support this fine.

[1] https://html.spec.whatwg.org/multipage/semantics.html#the-dl...

That requires change of existing markup and somehow its semantic changes too, right?

Yet this is not "resolution friendly".

Semantics is defined by the specification, so in this case no. But yes, a change of the markup.

What if space allows and I will want to have four columns table:

    dl { flow: row(dt,dd,dt,dd); } 

Changing markup structure is not a good idea if to consider that the same markup shall be used on different medias.

table-layout is another CSS property that I think too often goes unmentioned when talking about table based layouts; the default value (auto) is essentially "do something the spec isn't even going to try and define because implementations be crazy because they're essentially reverse-engineered copies of IE6's behaviour which is itself a reverse-engineered copy of NN4's behaviour".

The other value the property can take, fixed, makes table layout way more predictable: with no width properties defined, an n column table will result in each column having an equal width. If you define a width on some columns, it will split the remaining space between the remaining columns. This is far more often what you actually want when laying out non-tabular data using display: table as a make-shift grid layout system.

I never understood why people think the "holy grail layout" is a sticky footer. Do they really have pages with so little content that it's an issue?

I have decided for me at least that a fixed footer and header is what I consider my "holy grail layout" with just a center with no columns. Lately I've been trying to play with css grid to port over my previous layouts, but without much luck so far.

The point of a footer is that it is at the bottom of the canvas regardless of the size of other content. If it is not at the bottom of the canvas, then you get something else at the bottom - like a colored box of unknown dimensions. Which means the footer is not the footer anymore.

I'm still waiting for "display:div" to roll out.

It's called `display: block` - in sake of consistency :)

`display:block` does not define layout model of element content so I suspect it is not an intent of the author.

This

   div { display:block }
   div > * { display:block; }

is closer but still far from ideal: e.g. it will force all tables to lose their display:table; or lists to lose display:list-item;

As far as I understand author is looking for

   div { flow:vertical; }

But that's available only in Sciter.

I'm not sure I understand what you are trying to achieve differently from regular display:block?

Consider following markup:

   <div>
     some text
     <foo>first</foo><bar>second</bar>
   </div>

There is no way in CSS at the moment to define content flow of the div above. The only possible way is to define `display` on its children.

Say, you want that div to replace content vertically as if all children are blocks and text runs are wrapped into anonymous paragraphs:

   <div>
     <p.anonymous>some text</p>
     <block.foo>first</block>
     <block.bar>second</block>
   </div>

That's impossible in modern CSS without redefining `display` in children. But usually you cannot blindly say

   div > * { display:block;} 

What if some child uses `display:flex` ?

Problem is that `display` defines how element is replaced among its siblings. But not how its children are laid out.

At some point it was a proposal to add `display-model` css property. So you can have

   div { display: block; display-model:flex | table | etc }

Without it we have ugly semi-solution of combinatorial explosion:

   div { display: flex; }
   div { display: inline-flex; }
   div { display: table }
   div { display: inline-table; }
   div { display: grid; }
   div { display: inline-grid; }
   ...

Ah OK, I agree this would be useful. I think a newer CSS proposal factors the display property into separate values to declare element flow and element content flow independently.

"a newer CSS proposal"

This is of 2002: http://www.w3.org/TR/2002/WD-css3-box-20021024/#L706

15 years ago, Carl!

Yeah, that draft was abandoned though, but some of the ideas have been incorporated in the CSS3 display model.

Hmm, I usually only want "display: table" for... tables.

You missed the point. The CSS table display was created to decouple this particular layout behaviour from the <table> element. The reasons for that are clearly laid out in the examples. All of this was impossible to accomplish before flexbox.

Yes, this is why "table { display:table }" is the suggested default CSS for browsers. If you don't have fancy layout you should not need to override this.