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…
Do you know that there is an HTML tables API?
121–130 of 206 posts
Re: Do you know that there is an HTML tables API?
#122Earlier 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.
Re: Do you know that there is an HTML tables API?
#123Earlier 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.
Re: Do you know that there is an HTML tables API?
#124Re: Do you know that there is an HTML tables API?
#125The 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.
Re: Do you know that there is an HTML tables API?
#126Earlier 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.
Re: Do you know that there is an HTML tables API?
#127Re: Do you know that there is an HTML tables API?
#128It’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?
#129Phew, 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.
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....