I mean, it is semantic, if you want a table. One of the most baffling things to me is people trying to use not-tables when they're literally trying to display tabular data.

I laughed when I had to make a minor change to an old web application, and found our tabular, scientific data was being displayed in a series of DIV and SPAN elements, with the CSS table styles applied to them.

I changed it to a real TABLE, since that's far more accessible -- most users can cut and paste into their spreadsheet, and a screen reader might give options to avoid reading out all the data.

Another time, a web developer changed all my <i>Homo sapiens</i> to <em>Homo sapiens</em>.

To be perfectly semantically correct (which he was no doubt attempting, as I is a purely visual/appearance tag, and EM connotes some meaning), he should have used

<span lang="la">

<i> is the correct element, so <i lang="la"> if you wish. A taxonomic designation is the first example given in the specification:

"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts."

https://www.w3.org/TR/html5/text-level-semantics.html#the-i-...

For the purposes of screen readers, it is suggested to use <em> over <i>. What bugs me is the recent usage of <i> as an icon holder.

See the specification for <i>, a taxonomic designation is the first example of its use.

https://www.w3.org/TR/html5/text-level-semantics.html#the-i-...

Well, I should specify I meant that in most cases using <em> is preferred over <i> in terms of the traditional sense of what <i> was used for in the past. These days both have their specific uses, but in most cases one would more likely to use <em>.

For example, further down the page:

"Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term."

As an element it used to be the way to italicize text, to emphasize that text, before CSS. These days it has had a semantic reason for its existence applied which is a slight variation of its original purpose under the HTML4 spec.

Sometimes it's worth it. A real pain with tables is that you can't have it be positioned relatively. So if you want to display an absolutely positioned tooltip next to a row it becomes a gigantic pain and i'd argue impossible — or extremely hacky — without using JS.

Most divsoup-layouts are not semantic at all, either.

Those are not semantic because divs have no inherent semantic meaning, while using tables for layouts is not semantic because tables have an inherent semantic meaning that's incorrectly applied to a layout.

Not to mention that tables sized using % are as responsive as 90% of their css counterparts, whatever they are.

Good luck transforming a desktop 3 columns layout in a mobile 2 or single column one. Or viceversa.

90%

Exactly this. How are DIVs more semantic than TABLE? And who is reading the source? Your developers and a web spider. The web spider doesn't care (I wrote one and getting it to parse DIV content and TABLE content wasn't much effort)

As far as I am aware no spider is looking at the DIV and gathering semantic information from it. Sure, it may look at the TABLE and initially assume it has tabular data in it, but a tiny bit of logic fixes that.

> And who is reading the source? Your developers and a web spider.

Or blind people using a screenreader?

DIVs aren't entirely semantic, but table is semantically wrong for how it's being used. It'd be like if I asked you to "get me the pencil off that thingie" and pointed at a chair with a pencil on it. As opposed to "get me the pencil off that table" while pointing at the same chair with a pencil on it.

Which tiny bit of logic can distinguish between tabular and non-tabular tables?

DIVs are not actively anti-semantic. They are just a-semantic. So they're not particularly right, they're just not actively wrong.

Screen readers and spiders do look at tables as semantic content though. Tables are simply the wrong idea.

That said, CSS layout should have been based on tables/grids from the get go, ie. specify a set of blocks as rows and cells, with colspan and rowspan. It took way too long to get to this point.

Not flexible?

ungrid.css [0]

  @media (min-width: 30em) {
    .row { width: 100%;     display: table; table-  layout: fixed; }
    .col { display: table-cell; }
  }

[0] http://chrisnager.github.io/ungrid/