Once upon a time every website layout was defined via the Table element. Your side bar would be a cell spanning multiple rows, and inside the sidebar you’d have another nested table that defined more layout. The shift to table-less divs came almost as a massive over-correction to the abuse of nested tables.

We are in similar egregious territory now days with how we’re doing styled components directly in the javascript and totally forgoing some of the principles of CSS (we are effectively in-lining styles , for everything). That’s alright, we go through this upending in frontend every 3 years anyway.

It's a bit worse than that, even. Instead of the abuse of semantic elements, you don't have semantic elements at all. It's a giant mess of div tags. We've 100% given up on accessibility on the web. We've also thrown in the towel on device-agnostic HTML as well. For all of the grand plans of the '90s and W3C, they all failed. Every. Single. One. This includes CSS, which is an abomination.

If that weren't bad enough, let's discuss the fundamental core of the web: links.

Links are dead. They are buried under a mountain of SPA walled garden jank, teased at (but never granted) on Pinterest or Quora or LinkedIn or Facebook, or out there scamming users with shortened URL services. Corporate users are subjected to annual security training lessons where they are taught never to trust links (email, text message, or otherwise) because the alternative, training users to understand domain names, is just so impractical that we have all given up. Google gave up, with Chrome. They don't even want to show a domain. It's that bad and awful.

To give you an example of how shit it all really is, I recently had to look up an issue related to a Microsoft product. A quick Google search lead me to a number of Stackoverflow and blog posts on the issue. I found a number of links, pointing to Microsoft's bug tracker (links from just a year or two ago). And here's the kicker: all the links 404. The bug tracker is simply not there anymore. This is Microsoft we're talking about. They have given up on links. They have so given up on links that they can't even be bothered to let the user know what happened to those links.

Things are significantly worse on the mobile web. I would estimate that a good 90% of the web doesn't work on mobile in any sort of way that would delight a user. It's more that users just deal with this massive pile of shit. Watch someone use a mobile web browser sometime. Watch the nonsense they have to deal with. The janky-ass scroll popup sluggish ad-infested dumpster fire. All of it.

> Watch someone use a mobile web browser sometime. Watch the nonsense they have to deal with. The janky-ass scroll popup sluggish ad-infested dumpster fire. All of it.

Hence each website tries to create their own app. Users are drawing in apps that track every move they make and batteries do not keep their charge even to make an emergency call.

NetObjects Fusion allowed you to create pixel-perfect HTML layouts before CSS using just nested tables. It was both amazing and frightening.

https://en.wikipedia.org/wiki/NetObjects_Fusion

I remember a tool a lot like this in my teenage days (late 90's). Even then, I knew the things it was doing were horrendous...

And for what it's worth, NetObjects still exists - http://netobjects.com/

Because assistive technologies (like screen readers) won’t interpret it as a table, but the browser will, giving you the ease of table-based layouts without the accessibility hang-ups.

At least VoiceOver on Safari uses the `display` CSS property to decide how to describe an element unless you explicitly give an element a different ARIA role in the HTML, so this isn’t 100% correct in practice (although it obviously should be!). [0]

[0] https://bugs.webkit.org/show_bug.cgi?id=197786

The right way to fix that would have been to add a simple annotation that the purpose of the table was for styling, not semantics, something like:

  <table type=for-display-only ...>

Why do you consider that better? If I understand your suggestion "type=for-display-only" would semantically turn the <table> into a <div>. Why not just use a div in the first place?

Because it's DRY. With the top-level annotation, the rest of the table spec remains unchanged, so if you change your mind and decide that you really want a display table to be a semantic one or vice-versa you only have to change on thing whereas if you used DIVs you now have to change not only the top level but also every row and cell.

You don't decide on a lark if you want some content to have table semantics or not! Tags are selected to indicate the semantics of the content. Content don't change semantics unless you rewrite it to actually be something different.

In any case, you might just as well decide the table was a list item or headline then, right? So you would need

   <table what-i-actually-mean="ol">...

So two things...

First, one of the reasons HTML has been as successful and widespread as it has been is that mere mortals are able to use it, not just trained software engineers and designers. Mere mortals may not make such decisions on a lark, but they might make the decision incorrectly and have to go back and change it for that reason. Why make more work for yourself than necessary?

Second, making changes is not the only reason to make code DRY. Re-using TR and TD tags is analogous to operator overloading. If you want to add two numbers you want to be able to write x+y and have the compiler figure out whether that means an integer add, a floating point add, etc. You don't want to have to write (say) x II+ y if you want to add two integers, x FF+ y to add two floats, x LL+ y to add two longs, etc. It's the same for table rows and cells. The mental distance between tables-for-layout and tables-for-structure is smaller than the mental distance between integers and floats. It's just annoying to have to keep telling the computer over and over and over again "this is for layout" or "this is for structure" particularly in a case where the number of repetitions can be very, very large. There is no value add in forcing someone to do substantially more typing when the thing being typed contains no additional information that the system does not already have.

> It's just annoying to have to keep telling the computer over and over and over again "this is for layout" or "this is for structure" particularly in a case where the number of repetitions can be very, very large.

I have a hard time understanding this scenario. What kind of content are you working with?

What difference does that make?

I'm trying to understand the scenario you describe in the context of HTML.

If I am inside the context of a <table-for-structure> tag and I want to create a new row then the only kind of row I can create is a <table-row-for-structure>. It makes no sense to put a <table-row-for-display> inside a <table-for-structure> so requiring the programmer to specify <table-row-for-structure> rather than just <table-row> or <tr> is making her do a lot of extra typing for no value add. A <tr> inside a <table-for-structure> is necessarily a <table-row-for-structure> and a <tr> inside a <table-for-display> is necessarily a <table-row-for-display> just as a + operator operating on two integer values is an integer addition and a + operator operating on two floats is a floating point addition. There is no need to force the programmer to do extra typing to specify what is meant by + in a particular context. Likewise there is no need to force the programmer to do extra typing (or thinking) to specify what <tr> means inside a particular context.

But...you do only need to type <tr>. The problem you describe only becomes an issue if you use <table>s for layout in the first place, so just don't do that. If you want to display something (which isn't semantically a table) in a grid-like layout, you use display:table or display:grid in CSS, you don't change the markup. And vice-versa if you have <table> which you don't want to display in rows and columns, you can override the default presentation in CSS without changing the markup.

The hypothetical <table-for-layout> element is just not needed in any scenario. It would have been useful back in the day before IE supported display:table, but that is at least a decade ago.

> The problem you describe only becomes an issue if you use <table>s for layout in the first place, so just don't do that.

I could just as easily say that the "problem of overloaded operators" only becomes a problem if you try to use + to add anything other than two ints. So don't do that.

But OK, assuming I accept the premise, what should I do instead? The CSS community has been dithering about the answer for years. Only very recently has there been anything even remotely approaching an acceptable solution i.e. a solution that actually reproduces table layouts without having to pile on a ton of hacks. In the intervening years, a lot of legacy code was produced that used <table> for layout because it was the only thing that actually worked.

There also the fact that <display-table><tr><td> or something like that just looks a lot cleaner and is easier to read than <div class=table-for-display><div class=table-row-for-display><div class=table-cell-for-display>. When you make complex table layout you end up with a lot of TR and TD tags, so it makes sense to keep those short to avoid cluttering things up.

If you genuinely want a layout exactly like a html table you use display:table. You probably don't, but it is there if you want.

You don't really need repeated class=table-row-for-display etc, this can be achieved by CSS contextual selectors.

But in reality html tables was not designed as an all-round layout tool in the first place and the layout algorithm was never specified in detail. Flexbox and flexgrid are typically more appropriate and powerful as layout tools.

> display:table

I tried that once many years ago. It didn't work. It might work today but I no longer care.

> this can be achieved by CSS contextual selectors

That would be true if display:table worked, but it doesn't (or at least it didn't) and so it doesn't.

And you still need some markup for the contextual selectors to work on. The obvious choice is <table><tr><td>, or, if it existed, <display-table><tr><td>. Maybe <grid><gr><gd> but that's not going to happen.

> That would be true if display:table worked, but it doesn't (or at least it didn't) and so it doesn't.

Can you describe the problem you are having?

No. That last time I tried it was many years ago. Maybe it works now. I neither know nor care.

So you are basically just trolling at this point.

You can do this already with ARIA attributes:

<table role="presentation" ...>

[edit] See https://www.w3.org/TR/wai-aria-practices-1.1/#presentation_r... for details

You have it the wrong way round, it's a benefit that it makes it more accessible.

Abled people benefit from a system where their browser considers that div as "table-like" in the way content flows through it. Likewise, disabled people benefit from the fact that their screen-readers consider the div as a simple container without imparting any sort of tabular semantics ie expecting some data organized in rows and columns.

I think they mean to say that sometimes you might want the visual structure of a table but you don't necessarily want it announced as a table via screen readers since it isn't data that's being represented.

This is straight out of the CSS renaissance: There used to be a world, where the only sensible way to get something look a certain way on the web was using tables. But since using the actual table element, for anyone who cared about html semantics and accessibility, was a no go, assigning "display: table" to a non-semantic element was the next best option (or rather the least bad).

It will not surprise you to learn that this concept was not exactly well understood (to be fair, most things were not well understood, including js) and people started building all sorts of actual data tables out of divs with "display: table" applied, because apparently that's how you were supposed to do it.

Nowadays this is obsolete, of course, mostly thanks to flexbox but also grid.

This makes me cringe. I may have been 12 but I was making websites in 1998. And they were decent--I mean, it was a lot of right click > view source copying. But I fell in love with the Web Standards movement. I was probably the only 13 year old whose book shelf included books on perl, css, xml, and the like.

I feel the same way. It's probably because I'm 90s kid and nostalgia, but I wish web standards were taken seriously.

Ah yes. I saw this happen in the mid-2000s during the backlash against tables. You see, some visionaries had realised that the table element in html was being abused to create layout. The tools to do layout were added to css instead and the advice was to stop using tables for layout. Simple enough. But during these times there are always people who don't get the original message, or don't understand it, and just start blindly following some derivative of the original advice. That advice was "use divs". So they did. They would look at an html source and if they saw "table" they would turn their nose up but if they saw "div" they would rejoice.

The irony is it was completely against the original intention which is to use html to give semantic meaning to elements. Tabular data doesn't just have a visual layout, it is rows and columns. Most people still don't understand this today although with things like markdown people are doing it even if they don't realise (unless they start embedding html/css, of course).

There were a lot of grid base frameworks which did this. Foundation 5 was unique in that it still used these rows, but you uses scss to assign those attributes to your elements. Your pre-compiled CSS looked clean and your HTML looked clean and your final CSS was a minified blob of crap you tried not to thing about.

Really CSS Grid does the same thing; there's just more in CSS now and it's a whole lot cleaner.

Aside from what people said about screen readers (which at least makes it a bit better than tables) this is still a bad layout.

Here[1] is a revised edition of a book I read in 2006 about this topic how people often just replace all table elements with div elements and call it a day instead of using all the options CSS provides. Another topic was using all the tools the browsers with the best standard support gave you while still providing a more limited, but at least usable, version for browsers which hadn't implemented some features (yet). Even back then you could make pages which read well if CSS wasn't available and were visually appealing with CSS applied and today almost any browser has all these tools available.

[1] https://stuffandnonsense.co.uk/transcending-css-revisited - there's a free online version available

Depends - if the content isn't semantically a table (data points with a two-dimensional relationship) but you just want a table-like presentation and you want to conform to accessibility guidelines, this might be totally fine.

Sure it might be more elegant to do it with a stylesheet, but for a one-off situation it is not that bad.

There is a persistent attitude that presentational information in the markup is Bad and Evil. This is only partially true.

Misusing semantic html elements (like using <table> for purely layout purposes) is bad because it hurts accessibility for other people. But putting CSS directly in the HTML does not hurt anybody but yourself. If you do it all over the place it becomes a mess to maintain, but in particular cases it might be the simplest solution.

Probably to avoid the dumb limitations on having forms within a table? Still an awful and ugly way to do it

I am convinced that people who recommend things like that have no idea where we are or how we got here.

Something about accessibility and screen readers that people virtue signal about, but never actually test for.

CSS Zen Garden seemed to have a message that you don’t need tables for everything, but it was astonishing how few of the featured designs ever handled responsive layout properly. Getting text to fit into a rectangle by cheating was very common and you’d see bleed everywhere at a different resolution.

Until flexbox, there was no way to fix this without resorting to table cell behavior. It ultimately soured me on the Garden. And thankfully I got to use CSS3 shortly after.

Keep in mind Zen Garden was written WAAAAAAAAY before mobile layouts were a thing. Back then, you had mobile sites .. for people with PalmOS, BlackBerry or flip phones with tiny browsers. I think my edition of this book came out before the first iPhone (I remember owning it when the girl behind me at work got the original iPhone EDGE), so responsive design wasn't a thing (I don't think media queries even existed in the CSS standard, or if they were, few were using them yet).

Heck, when the Zen Garden was first released, you couldn't even browse the web on a Blackberry. 1024x768 monitors were a luxury. 760px wide was all you could count on for a browser window once you accounted for window edges and scrollbars on the average user's 800x600 monitor (a few years later as 1024px monitors became more common, a 960px site width became the standard); and I had co-workers who were still getting by with 640x480.

I was fighting my coworkers with 1440 monitors to make sure we still worked on 768 width (plenty for 800px + scrollbar, or portrait on the brand new iPad). UI people like to maximize negative space in their mockups and it's not uncommon for them to use extremely short example text to emphasize that effect. Like how your living room looked so big until you put all of your crap into it.

And the thing is, even if you had a 16XX monitor, who wants to maximize a tool that you might be transcribing data in or out of? I might actually need two windows side by side to facilitate that work.

I was pitching responsive (or at least, fluid) design by 2011, and I was not blazing trails. I started using the iPad as an example but tiny laptops were an issue, and in a business setting, most production projectors were only 1024 pixels, hardly anyone had the 1280s, and the cheap ones were 800x600 native with terrible interpolation.

Wikipedia has this timeline:

> Cameron Adams created a demonstration in 2004 that is still online.[46] By 2008, a number of related terms such as "flexible", "liquid",[47] "fluid", and "elastic" were being used to describe layouts. CSS3 media queries were almost ready for prime time in late 2008/early 2009.[48] Ethan Marcotte coined the term responsive web design[49] (RWD)—and defined it to mean fluid grid/ flexible images/ media queries—in a May 2010 article in A List Apart.[2] He described the theory and practice of responsive web design in his brief 2011 book titled Responsive Web Design. Responsive design was listed as #2 in Top Web Design Trends for 2012 by .net magazine after progressive enhancement at #1.

And while the Garden was indeed around long before that, IMO it didn’t get properly cool until maybe ‘07. And once fluid and responsive came in it wasn’t keeping up.

The point, I thought, was to be able to send people there to learn, and I was afraid of having to fix that kind of smoke and mirrors in our production code so I stopped telling people about it, other than other seasoned UI people fora particular design, and half the time it was to laugh at one, not learn from it.

> IMO it didn’t get properly cool until maybe ‘07

Wikipedia says the book came out in 2005, which if I remember correctly had plenty of colour pics inside. You don't get that kind of tech book unless you're already properly cool.

Responsive design was absolutely a thing, because the web was responsive from the start. It was CSS that made it non-responsive; sites that used tables for layout reflowed properly on PDAs or phones, and still do.

Virtually every CSS Zengarden site was filled with exact pixel counts and page offsets. As an art project it was neat, but practically speaking it was a disaster.

When I was first learning CSS I was trying to replicate a very easy 3 column layout where the middle column would grow and shrink with the screen and consist of multiple variable sized elements arranged neatly in a column. What should have been one of the most basic layout styles turned out to be quite a challenge to achieve with CSS. I wasn't even trying to have anything fancy like columns that disappear on super narrow screens. Just the most basic three column layout that didn't leave wasted space on the page. In my struggle to get it to work I went to sites like CSS Zengarden to figure out how they did it and was extremely disappointed to discover that they hadn't found the solution either. My thought was it couldn't be difficult because it was so easy to do with tables and literally everybody online was telling me that tables for layout were completely surpassed by CSS. Plus I was working with CSS 2, so any glaring deficiencies like this from CSS 1 would have definitely been fixed by then. I mean this was the point of CSS right? To do layout?

Ah, the three column layout with equal heights, the holy grail.*

*https://en.wikipedia.org/wiki/Holy_grail_(web_design)

One of my big coups was fixing the reflow on our multicolumn layout. The page I fixed it on was survivable as it was, but a whole third of our UI would not have worked at all without it.

The first time I got to use flexbox in production (different project) I was happy as a pig in shit.

Even with "display: table" or flexbox you couldn't do something as simple as colspan.

Oh man, I had blotted that out. There’s a somewhat arcane set of table styles that will give you proportional layout of blocks that is more powerful than colspan. I found that it was often worth the trouble of reaching for the more sophisticated solution.