Live data from Hacker News

Do you know that there is an HTML tables API?

christianheilmann.com

121–130 of 206 posts

Re: Do you know that there is an HTML tables API?

#121
post #92

Earlier quoted context omitted.

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

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 develope…

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.

Re: Do you know that there is an HTML tables API?

#122
post #104

Earlier quoted context omitted.

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.

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

Re: Do you know that there is an HTML tables API?

#123

Earlier quoted context omitted.

Why would marketing want to pay for the extra (and to their mind entirely pointless) work required to capture semantics? (I’m not saying I like the world we live in, but I don’t see a likely alternative.)

Because not everyone has useful eyeballs. Some people are blind. The amount of extra work you have to do to make a div faithfully act like a button is far more than simply resetting some styles.

It seems evident to me that semantics are more challenging to define than visuals; it's not the CSS that's the problem.

Re: Do you know that there is an HTML tables API?

#124
The depreciation of marquee and blink wasn't necessary; it's web developer's choice whether to use these and the visitor's choice whether to be repulsed. Marquee should have been improved for use as ticker elements for specialized application. The depreciation of nobr misses the point - the alternative is more complex. Hope the standard continues to keep the legacy elements: small, i, em, hr... etc.

Re: Do you know that there is an HTML tables API?

#125
post #101

The trouble is not populating it. The trouble is that tables, even though structured semantically, give you absolutely no functionality. There are no search, filter, sort, or selection features that you get.

Compared to what? What gives you all that, and what prevents you from having it with tables?

Re: Do you know that there is an HTML tables API?

#126
post #73

Earlier quoted context omitted.

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

Re: Do you know that there is an HTML tables API?

#128
A lot of people here are clearly not reading the article.

It’s not about the element itself—we hope everyone knows about tables—but rather about the table-specific DOM interface, including things like HTMLTableElement.prototype.insertRow() and HTMLTableRowElement.prototype.insertCell() as alternatives to the generic DOM techniques like Document.prototype.createElement() and Node.prototype.appendChild().

These are handy if you’re hand-writing your DOM interactions, but libraries that construct and maintain DOM trees (e.g. React, Svelte, Vue) will never use them, and that’s the direction everything has headed, so in practice they’ve fallen into near-complete disuse.

They match HTML syntax in another important way: HTML tables have thead/tbody/tfoot section elements, but you can mostly skip writing them in HTML syntax because it’ll imply open and close tags. Likewise in this interface, if you have a thead/tbody/tfoot element you can call .insertRow() on it, but you can also call .insertRow() on the table, and it’ll put it in the last tbody, creating one if necessary. Meanwhile, I presume in React/Svelte/Vue/whatever you must write out your tbody manually.

I’ve definitely used at least .insertRow, .insertCell, .createTHead, .rows and .cells in the last five years in no-library throwaway/demo scripts where I was generating tables.

—⁂—

Concerning the specific example given, here’s what I find a clearer code style, using for instead of forEach, using better variable names, and omitting the index argument to insertRow/insertCell which was quite unnecessary and only confused matters (the author doesn’t seem to have realised it’s optional):

  let data = [
      ['one','two','three'],
      ['four','five','six']
  ];
  let table = document.createElement('table');
  for (const row of data) {
      let tr = table.insertRow();
      for (const value of row) {
          tr.insertCell().innerText = value;
      }
  }
  document.body.append(table);

Re: Do you know that there is an HTML tables API?

#129

Phew, this post single handedly made me feel old this morning. I started dabbling with the web just over 20 years ago but have mainly been working on the backend the past 10-15 years. I had no clue that nowadays programmers don’t know about this, so I assume it’s supplanted by modern frameworks or modern JS/CSS

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.

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 ’s or ’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....

Post reply on HN