Except anyone with accessibility requirements, no? As far as I know tables are horrible for anyone with a screen reader. Can you annotate tables somehow to work for accessibility purposes?

The problem with screen readers is summarized "Screen readers assume the content inside a table is tabular". Are divs better just because they are undefined? It seems to me that the problem would more easily be solved by adding some attributes to skip tabular treatment or to add captions, rather than ditching tables altogether. Table elements like <caption> could even be used to identify and access parts of the UI pages.

> Screen readers assume the content inside a table is tabular

I'm curious to hear from screen reader users. I recall that the gap between "what web developers think screen readers do" and "what screen readers do" has always been sizable.

Windows based screen readers (more sophisticated than Mac's VoiceOver), let the users treat only data tables as tables and ignore layout tables. Also users can adjust announcement of only column headers, only row headers, both or none while navigating through the data table.

Using tables for layout is so commonplace, I think most screenreader makers basically gave up and don't treat a table as a table unless it includes headers (<th>). Of course people who choose to use tables for layout also skip using more semantic elements, have a lot less flexibility to make layout changes (because their choices are expressed in HTML instead of CSS), and have a lot more trouble making their designs responsive.

It looks like you can just mark it as being for presentation:

<table role="presentation">

Although the screen readers seem to do a decent job of doing this automatically.

The "screen readers" argument is cargo cult in 2017.

Is it really?

Number of unhappy front-end developers : 1 ( me, so far ).

Hope nobody will have to modify your stylesheets.

Because they're much simpler than the usual div-based layouts, and so the frontend dev will get bored out of their brains?

Tables are meant to be used for ... tables. Not layout. The downsides are enormous.

From hard-to-find bugs through SEO-penalty to code-maintainance [1].

I lived the time when there was no CSS at all. Back then we used tables for everything. I'm happy those times are over.

1: http://stackoverflow.com/questions/83073/why-not-use-tables-...

Most of the raised in the accepted answer to that SO question can in fact be applied equally well to div/css layouts as they're practiced in the wild. CSS Zen Garden is awesome and all, but I'm yet to see a fronted professional who does things that way.

For instance, arguments about ease of change (single place to modify) are irrelevant, because in both cases the single place to modify is the code that renders the layout.

Also, personally I'm not buying the whole separation of layout from content thing. It's an implicitly understood fact people seem reluctant to admit out loud: form is a part of content too! These are not orthogonal things.

You won't get penalised for using tables as layout in regards to SEO.

How many of them use your sites from mobile phones?

How do you do column based layout with tables?

I want to add a column to a table via ajax, how do I do it? I can't cleanly, I have to modify each tr.

I do to, sometimes. I wonder if there is any thought given to making tables responsive rather than reinventing the wheel here.

The (theoretical) issue here is that a "table" has a certain semantic meaning ("a container for tabular data"), and that using a table for something outside that semantic meaning can introduce confusion, be it for fellow programmers (including your future self!) or for those who are interpreting your page in weird ways (robots, people using screen readers, etc.).

In the few times I actually bother with frontend "design", my goal is usually for my actual HTML to contain as few hints about how said HTML should be displayed as possible, and to let CSS handle the display specifics. This usually means that I don't touch `div` and I don't touch `class` unless absolutely necessary. CSS provides more than enough selectors for "absolutely necessary" to be false in the vast majority of cases.

Of course, this ain't for everyone. Some people stick with tables. Some people use div/class for everything. Some people just treat Javascript like the new Postscript and generate pages on the fly. You do you. However, these tend to have their share of downsides, among them being a tendency to deviate strongly from the semantics of HyperText documents.

Tables ought to be responsive anyway, though, even if that just means "add a horizontal scrollbar if the screen is below a certain size". I'm pretty sure that's already possible through CSS, but it involves overriding a lot of the work the browser does for you, and unless the data encapsulated by that table is indeed meant to be tabular, you're probably better off with divs (or better yet, with more specific HTML elements).

OK, so tables have semantics of tabular data. But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the "usual" style of doing layouts is somehow better? It's much larger, much less readable, much less obvious, and breaks the "separation of content and layout" rule even stronger than tables. So again, why is this better?

And yes, I've been in this space for years, and this is one of the better example why I feel most of the webdev world is cargo-cult advice that's internally inconsistent if you look at it carefully.

Using an element that lacks semantics (<div>) is always better than mis-using an element that has semantics (<tr>, <td>). Why would you need to use more divs than table elements to achieve the same visual layout? I feel like you're not comparing apples to apples. What's so readable and obvious about tables nested 3-4 levels deep?

Anyone who really thinks about how CSS can be used is also going to be against div-itis but it's still less-bad than tables for layout. They're also going to be against excessive use of classes and class names that connote style (class="red") rather than purpose (class="alert").

"But the shit ton of semantically meaningless divs that are sprinkled around the structure to provide hooks for CSS declarations in the 'usual' style of doing layouts is somehow better?"

No, it's not, as I thought I made plainly clear in my comment. HTML5 introduced a smorgasbord of new tags to avoid that.

You're right that a lot of modern web development fashion is silly, but there are alternatives besides just sticking to tables for everything.

The divs are sprinkled just to say "this is a block, it can be moved or arranged however wished", and styling within the block is done separately.

It’s not intended to do anything more or less.

I feel like this is the reason behind HTML5's semantic elements (e.g. article, nav, etc).

I have 30,000 unique visitors to my website every day. The number who care whether HTML tags are being outside their semantic purity is zero.

Great! If it ain't broke, don't fix it. If you don't have users with screen readers and don't have any issues with search engines parsing your web page, then you do you.

Screen readers and search engines haven't been confused by tables since last century.

According to other comments to the linked article, the former at the very least ain't universally true.

A. How would you know what they care about?

B. Maybe if you cared, you'd have 30,300 unique visitors, or more. I don't know, I don't know how bad your site's code is.

w.r.t. avoiding div and class, how do you make sense of the element <-> rule mapping? There's definitely enough specificity to make such a mapping, but I just end up with a big bowl of spaghetti.

EDIT: I guess I'm mostly talking about class, HTML5 semantic elements takes over much of the utility of divs in this usecase.

I usually just base it on whether or not an element is a direct child of some other element. For example, the header of the page itself will usually have a different style than the header of an article or aside or something, so I can use CSS' child selectors for that.

This often does indeed result in a bowl of spaghetti, but said bowl is in CSS rather than HTML. Things like SASS/SCSS help tremendously.

I remember when I switched away from tables, it was due to a performance issue(back in 2008). I could have the div based layout render about 700ms faster. I never went back to full table layout, but I never ditched tables for layout purposes entirely.

Of course this is anecdotal, but I wonder wether it'd be just easier for browsers to just improve table performance.

Do you mean literal <table> markup, or tables in CSS such as display: table

Using CSS surely can improve the screen reader experience by the markup not being actual tables.

Screen readers haven't been confused by tables since about 1998.

There was a particularly extreme trend back then (well - probably more during the 90s) where websites were mainly big Photoshop images sliced up into a lot of nested tables of dizzying complexity. Screen readers off course struggled with that as it was rather hard to determine the order of the content. I'm not sure how much trouble they have with more minimal use of tables for presentation.

> where websites were mainly big Photoshop images sliced up into a lot of nested tables of dizzying complexity

Replace "nested tables" with "nested divs", and this is exactly how web development today still looks, at least if your company employs a designer. Slicing is still a thing.

Then fire your designer and hire one who is competent for the job.

Sliced images were an ugly hack for the shortcomings of early CSS (or no CSS if you go back further still).

There's been no excuse for a very long time now.

After using Bootstrap I found myself in a nested div situation. Row + Column + Content/Cell.