I’ve been building sites since around 2000 and I’ve used HTML tables a lot (including for page layouts, remember those days?). There was a time when I thought I was fluent enough to not have to look up HTML or CSS docs for most things. But I don’t think I’ve ever actively used the DOM API that this article mentions so I learned something new today.

Surprised, as we used this a lot around 2005, when IE6 was still dominant.

If was much simpler to build tables in javascript with this rather than using document.createElement.

Perhaps this was one of those things that you just had to know about, or be working on data heavy web apps.

Thank you for confirming I am not... crazy, just old then. I was staring at the code for minutes, trying to spot something unusual that I missed. So, this really just about the `<table>` element, or do I actually not see something?

It's about the insertRow() and insertCell() methods and rows[] and cells[] fields on the table element, not the table itself.

I figured that was the normal way to interact with tables, what would people do otherwise?

Using the standard DOM APIs or - if they don't care about anything - innerHTML, I suppose.

Sorry I - also - am one of those old timers who don't understand this because the shown code is all I've ever used for creating table. So, what is this "standard DOM API" if I may ask? Could you post a code example?

You can use document.createElement and document.appendChild to create every last <th>, <tr>, and <td> if you want. Those functions are not specific to tables, unlike the one mentioned in the blog post. They can be used to create any elements and place them in the DOM. But if you know what you are doing you can get a perfectly fine table out of that. (Not that you should.)

Yeah, that was what I was thinking of. I knew those as the essential APIs to modify the DOM without a full re-parse. And you can use them on table/th/tr/td nodes just like on any other node.

createElement(‘tr’) and table.appendChild(row)

It’s not about the table element, it’s about the API to construct and manipulate that element with a columns and rows interface which is largely superseded by general DOM manipulation.

Exactly like how `getElementById` replaced the direct use of the id as a JavaScript identifier.

I remember there being posts that explicitly discouraged using IDs directly, but I'm not sure of tge reasons anymore. Maybe browser incompatibilities or unclear scoping and confusion with other variables?

It was either Mozilla (Netscape, I think) or IE that it didn’t work on for the longest time.

I think that was a native IE API that Mozilla had to add support for, as well as document.all (Netscape used document.layers).

It works everywhere (it’s now specified in https://html.spec.whatwg.org/multipage/nav-history-apis.html...), but it’s brittle. It can break by adding colliding properties to window deliberately or by accidental global leak (… including things like setting in dev tools), by browser defining new globals, by some 'name' attribute conflict.

Yep, didn’t realize this was unknown by enough web developers to warrant an article.

I see new frontend developers using <div> for building buttons, and I've even seen people using <div> for doing titles! Us greybeards don't know how much apparent knowledge we're sitting on, it seems.

In 2004 I was at a company that dedicated a team of people to rebuilding a bunch of tables (lots of financial data) in to styled divs because... "tables are depreciated". The fact that they couldn't pronounce or understand the word "deprecated" should have been enough of a clue to ignore this person, but they were the 'lead' on the web team, and... had been there longer than other people. Obviously they must know what they're talking about. Weeks later after having converted dozens of spreadsheets to divs (instead of just using tables) they were 'done', but it was a tremendous waste of time that ignored all the semantics of tables. I was asked to 'help out' on that project to meet the deadline and refused, citing that it was not just stupid, but a big waste of time and against web semantics.

"table" was never deprecated in HTML at all, but was discouraged for general layout (we were aware of this even in the early 2000s). But for representing tabular data - like... data in rows/columns from spreadsheets (with column headers and such)... HTML tables were absolutely the right (only?) way to present this.

I was at that company less than a year...

And spans for creating links…

I recently discovered our frontend widget library draws an SVG to implement Radio instead of using <input type="radio">. I was looking at it because they forgot to add a "disabled" attribute.

Best case I'm hoping it's because they were required to get an exact design, but they really should have pushed back on that one if so.

Sounds like they either don't care about accessibility or like wasting money comprehensively reinventing things.

Thereby forgetting that some people like to open links in a new tab.

And for the ones that remember to implement middle-mouse click to open new tabs, forgets that one can also do CTRL+click to open in new tab, or vice-versa.

Just use <a> please :)

Or just right-click -> open in new tab

Is that bad?

Seems to me that we have redundant mechanisms for specifying semantics: tags and attributes (and classes as a specific attribute). Seems to me that tags are really just syntactic sugar for things like roles. Tables in particular are easily abused.

Of course I use the tag names, because they're idiomatic. But I feel like a newbie who identifies divs as the only true structure builder has a proper developer's intuition for separating presentation from content.

> Is that bad?

As long as you think about semantics and accessibility and does the extra work to add those things, then not really.

But why add those extra things when we already get those for free by doing <h1> and then customizing the style? Everything you'd need to manually add, automatically works fine then, so seems like a no-brainer to avoid putting more work on your table.

div-as-button/link leaves a lot of default interaction behaviour on the table. You'll need to handle all the keyboard interactions yourself, all the accessibility markup, etc.

I knew it existed but I figured it was only really useful for extremely data-table centric applications so I've never used it.

Same. I use this all the time, have for decades. Had no idea other people didn’t.

Just a catchy title. Not abandoned etc. This is the only API available to manipulate HTML table tags.

Most people use declarative frameworks to build tables, and you could just use `innerHTML` or `append` or any other imperative DOM API to work with tables.

Declarative frameworks build on the imperative DOM API.

They don't use .insertRow() and .insertCell(). Try searching the React codebase for those.

Yea, but that's pretty much irrelevant as long as the effect is exactly the same. Which brings us back to the point of the article: seeing this and feeling inspired to imagine interface extensions that go beyond syntax sugar.

I was replying to the wrong comment, because I was responding to this:

> I still use this pretty much everywhere to create HTML tables. Do people use something else now?

Regarding React: what would be the benefit for using this old syntax sugar in its vDOM implementation?

Page reflow is not an issue for vDOM as it batches such updates anyway?

And using syntax sugar without benefits in the DOM reconciliation would be pointless.

React also doesn't locate form input elements using document.forms.[name]?.[name] because... why should they?

Just because they can...

Regarding the creation of tables, the most common way to do it would be... parsing initial document's HTML?!

What do they use?

appendChild() and the like.

And, not a single one of the declarative frameworks use the HTMLTableElement API!

Which is completely fine as long as it makes zero difference.

It's not that long ago when people were fighting here about React, Vue etc being too complex and comparing bundle sizes.

Using this right now would increase bundle size for no good reason whatsoever.

So how they do they talk to the browser to add a row to the table? Do you know of any API other than DOM used for this?

They use createElement instead of the table-specific API.

appendChild, replaceChildren, etc work fine with tables?

HTML tables are cognitively if not officially deprecated these days. I made my 1996 resume in HTML using a table for layout and it was indistinguishable from the Word version when printed. Made by editing the HTML by hand too!

Tables are great. I don't doubt that CSS stuff is more capable, but the old ones are still useful.

I think the problem was that tables were always supposed to be for things that look like actual tables in the output - for that purpose they are not deprecated.

What is discouraged is using tables as invisible layout grids - and that was their primary de-facto usecase before CSS and grid layouts. But that had always been a hack, even though a necessary one.

Tables are probably still useful for layout in HTML emails (for advertising). I haven't had to work with HTML emails in probably 20 years, but I doubt much has changed about what is and isn't allowed in HTML emails.

> What is discouraged is using tables as invisible layout grids - and that was their primary de-facto usecase before CSS and grid layouts.

After too.

I've seen enough "Introduction to CSS"s filled with caveats and hemming & hawing to know that it's all to be avoided when+if possible. I know, I know, there's a whole wide wonderful world out there full of aligns and borders and containers and insets and margins and masks and offsets and paddings and positions oh my. Bleccch..

How was it a hack?

Hack implies brittleness. Using tables for layout was just fine for all but the most ideologically pure pedants.

Yep. Tables for tabular data are still on the menu.

Back in the early to mid 2000's, making your site "table free" while still working on IE6 was seen as a badge of masochistic pride.

Doing table-free multi-column layouts involved doing crazy “float: left/right + padding + margin” with an heavy sprinkle of IE6 clearfix hacks to work right. I mean eventually people dialed in the correct incantations to make table-free designs work for IE6 but it was never quite as straightforward or reliable as a good old fashioned table. Many megajoules of energy were wasted on webform drama between the pragmatic "fuck you, tables just work and I have shit to ship" webdev and the more academic "tables break the semantic web and aren't needed, use CSS." crew.

Like most things, the "tables are evil" mantra was taken too far and people started to use floated divs (or <li/>’s or <span/>’s or whatever) for shit that actually was tablular data! (I was guilty of this!).

And like most things, a lot of the drama went away when IE6 finally went away. People who weren't around back then simply cannot understand exactly how much IE6 held back modern web design. You could almost count on half your time being spent making shit work for IE6, despite the ever decreasing amount of traffic it got. I'm pretty sure I almost cried the day Google slapped a "IE6 will no longer be supported" on it's site.... the second they did that, my site got the exact same banner. Fuck IE6. The amount of costs that absolute pile of shit browser caused the industry exceeded the GDP of entire nations.

Anyway.... back to adding weird activex shit in my CSS so IE6 can support alpha-blended PNGs....

I remember those days. It was simpler to use tables for layout than to use early CSS for quite a while.

> HTML tables are cognitively if not officially deprecated these days.

According to who?

> Phew, this post single handedly made me feel old this morning.

I hear you!

For me though, it made me feel old for a different reason

I had first developed webapps in the late 90s (96 onwards) using cgi-bin, perl, etc. My first webapp, done for money, was something similar to MRTG.

At some point in the last almost-30-years) I had actually used this API! I have, however, forgotten all about it and was only reminded of it with this post.

So, yeah, I feel old because I can legitimately say to many modern web-devs that "I've forgotten more about web dev than you you currently know" :-)

It's worth checking who the author is... Cristian's not exactly new to the game. I think he's being humble he doesn't know something despite his experience.

I feel like I used this when I built a red-light, green-light dashboard for Windows servers at a bank for my first job out of college (in 2009).

I’ve been doing ssr for so long I can’t fathom why you’d build a table using JS.

I've been working on a little SPA that manipulates tabular data and allows the user to insert rows. This is exactly the API I've been using. Like a lot of other commenters it never occurred to me that people wouldn't know this API exists.

Aside: I started with Perl CGI scripts, then ColdFusion, and finally Classic ASP back in the 90s. I had a chuckle a couple years ago dealing with a younger developer who was shocked that and oldster like me was up on new-fangled SSR patterns.

You knew about the .insertRow() and .insertCell() methods?

I made my first CRUD UI that didn't do full page refreshes with those methods.

I think most of us did the ol `$el.appendChild(document.createElement('tr'))` dance rather than using those, at least I did during the 00s for sure.