7 ms·
Do you know that there is an HTML tables API?
- dtagames 11mo agoTables died (thankfully) to make room for flex and grid. I can't see any use case for them at all anymore.
- begoon 11mo agoI personally disagree. When data is semantically a table, not just a “table-looking” layout, I would rather use the table tag.
- the__alchemist 11mo agoI think this is the gist of it. Tables were abused as general spaced 1D, and 2D styling components. Introducing proper general spacial styling components means we don't need to extend tables beyond their original purpose, but doesn't mean we shouldn't use them for that purpose!
- zetanor 11mo agoThe use case for a table is to present data.
- SahAssar 11mo agoTabular data? Tables have a purpose, it's just that people misused them for layout purposes.
- loloquwowndueo 11mo agoTo be fair, we did that when there wasn’t much choice for laying out web pages other than using tables. I was there!
- cogman10 11mo agoEspecially in ways that worked cross browser. Young folk don't understand just how wildly different IE5 was to the Netscape or the Mozilla browser. Or just how bad Javascript was when it started to be used on the internet. I've lived through and seen the evolution. For all the shit the JS community takes for constantly revving frameworks, it's 1000x easier to make a website that looks the same regardless of browser due to a lot of these frameworks and browsers themselves evolving.
- dvratil 11mo agoIt's not that long ago that tables were the only reliable layout tool for HTML emails (mostly due to Outlook supporting only very limited subset of CSS).
- embedding-shape 11mo agoHow about displaying data in rows and columns in a accessible and easily styled way, without having to rely on JS and your own CSS to replicate a table? How exactly would you do that with HTML and CSS without using tables? Using flex and grid for those purposes don't make much sense unless you care about design above all else. <table> just gives you so many good defaults (semantic structure, accessibility, column styling, column alignment, keyboard navigation) for free compared to using CSS to create your own table, that I'm not sure why you wouldn't use <table> for tabular data. Of course, if you need masonry, card grids and so on it makes sense, do actual layouting with layouting tools. But thankfully <table> hasn't died just yet, it's still better than CSS for many use cases.
- dtagames 11mo agoNothing about flex or grids requires JS. That's entirely CSS.
- andai 11mo agoThis implies that you were considering -- for a split second -- making a 90s style table based website layout, using the Tables API? ;) I might have to try that now...
- pikuseru 11mo agoThey’re probably still quite useful for displaying tabular data - there’s also semantics involved, it’s not primarily just a layout mechanism.
- theandrewbailey 11mo agoHow about displaying data in rows and columns, like records in a database? Or have you forgotten SQL, because you retrieve JSON from your 1000 NoSQL microservices?
- dtagames 11mo agoRows and columns are exactly what grid was added to CSS for.
- theandrewbailey 11mo agoUsing only CSS for tabular row and column data is just as wrong as using tables for layout. There are legit reasons for using <table> today that can't be replicated by CSS. Namely, CSS doesn't confer the same semantic meaning into markup that <table> does. Compare https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/table https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... with https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_la...
- joquarky 11mo agoI'd hate to hear that on a screen reader.
- nophunphil 11mo agoI agree with many other replies here, specifically about accessibility. Once I learned how to use a screen reader, it was eye-opening. So many web applications are utterly broken for users with assistive technologies. Tables built with flex and grid absolutely can be made accessible with WAI-ARIA, but native table elements are harder to mess up.
- thatwasunusual 11mo ago> That way they’d finally get the status as data structures and not a hack to layout content on the web. I remember doing this 25 years ago, but I assume (and hope) it's a huge minority who do this today?
- embedding-shape 11mo agocough view-source:https://news.ycombinator.com/item?id=45781293 https://news.ycombinator.com/item?id=45781293 cough
- bstsb 11mo agointermittent loading errors (503 Service Unavailable) https://archive.ph/APbi8 https://archive.ph/APbi8
- zX41ZdbW 11mo agoI was using it just half a year ago, after either reading MDN or reading what AI suggested. Which means, this API is not obscure and not forgotten. Using `rows` and `cells` is very convenient for keyboard navigation across table cells. https://github.com/ClickHouse/ClickHouse/blob/master/programs/server/play.html#L1587 https://github.com/ClickHouse/ClickHouse/blob/master/program...
- conception 11mo agoThe worst thing on the modern web is people using divs for table data. What do you mean this table isn’t sortable? M365 Admin is the worst offender I’ve come across on this. Just terrible table implementations on almost every page.
- mr_toad 11mo agoIs there a term for the opposite of cargo culting? Where everyone avoids something, but no one remembers why? Because that’s basically where HTML tables have ended up.
- embedding-shape 11mo agoI think this is something like a "delayed cargo culting", or "cargo culting based on outdated facts". I think it's basically the same as the hypothesis from the "Monkey Ladder Experiment", where monkeys got punished when trying to get a banana, and eventually all the monkeys were replaced with monkeys that didn't realize why the banana was off-limits, yet persisted in trying to "help" other monkeys trying to prevent them from getting the banana. I'm not sure if I read that that specific experiment was debunked or not, but it certainly sounds familiar to how some developer trends get propagated even though the ground truth as changed.
- paradox460 11mo agoIt's still cargo culting
- joquarky 11mo ago
- skerit 11mo agoInteresting, but the JavaScript examples hurt: let table = [ ['one','two','three'], ['four','five','six'] ]; let b = document.body; let t = document.createElement('table'); b.appendChild(t); table.forEach((row,ri) => { let r = t.insertRow(ri); row.forEach((l,i) => { let c = r.insertCell(i); c.innerText = l; }) }); Use full words for variable names!
- niek_pas 11mo agoI was just about to comment the same. I’m sure people have a good reason for it (or at leafy _a_ reason), but single-letter variable names always struck me as optimizing for the wrong thing. As someone who likes to program in Haskell, I feel this pain very strongly. :)
- bottd 11mo agoDo you always feel this is the case? To me the go to single letter variables are very readable. Used so widely my eyes parse them like other symbols: =, &, +, etc.
- alentred 11mo agoMy rule of thumb: only using single letter variables in one-liners (and never if it spills to another line), or for something that is conventionally represented as such. So for example: ```python bar = [foo(e) for e in elements] ``` or, using `x`, `n`, `s` and similar when they represent just that, a generic variable with a number, string, etc. I think there is a Code Complete chapter about it.
- jazzypants 11mo agoYeah, I'm not GP, but my exceptions to this rule are `i` for "iterator" in `for` loops and `e` for "event" in event listeners.
- 11mo ago
- Mystery-Machine 11mo agoThe variable naming convention used here could be improved for clarity. I prefer appending `El` to variables that hold DOM elements, as it makes identifiers like `tableEl` clearer and helps avoid ambiguity between variables such as `table` and `row`. Also, the variable named `table` does _not_ actually represent a table element; it would be more accurate to name it `data` or `tableData` to better reflect its purpose.
- embedding-shape 11mo agoProbably because I first learned programming with JavaScript and very early started using jQuery, but I've always used prefixed `$` to indicate "This is a DOM element" (started doing this once jQuery stopped being so popular). So the example would be something like this for me: let table = [ ['one','two','three'], ['four','five','six'] ]; let $body = document.body; let $table = document.createElement('table'); $body.appendChild($table); Always felt it worked out short and sweet, and as long as you're not refactoring a jQuery codebase, seems to work out well in practice.
- pspeter3 11mo agoI’m curious what changes the author would like to see to the API
- stared 11mo agoIt is similar as with buttons (https://news.ycombinator.com/item?id=45774182 https://news.ycombinator.com/item?id=45774182). Not sure when it was (10-15 years ago), but at some point everything became <div>s. So, instead of semantic markup, HTML became a UI toolbox.
- macintux 11mo agoI think it was inevitable. Most of the funded content on the web is marketing/sales-driven, and companies paying for marketing content want it to be displayed in a specific way. It’d be interesting to have a parallel DocBook web for technical content, where consumers of that content could apply their own styles to render it in a way that’s best for them.
- jazzypants 11mo agoI mean, you can just remove all the user agent styles and then <button> is just as stylable as <div>.
- macintux 11mo agoWhy 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.)
- withinboredom 11mo agoBecause 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.
- macintux 11mo agoIt seems evident to me that semantics are more challenging to define than visuals; it's not the CSS that's the problem.
- Insanity 11mo agoPhew, 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
- dmd 11mo agoSame. I use this all the time, have for decades. Had no idea other people didn’t.
- zkmon 11mo agoJust a catchy title. Not abandoned etc. This is the only API available to manipulate HTML table tags.
- jazzypants 11mo agoMost 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.
- moritzwarhier 11mo agoDeclarative frameworks build on the imperative DOM API.
- jazzypants 11mo agoAnd, not a single one of the declarative frameworks use the HTMLTableElement API!
- zkmon 11mo agoSo 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?
- zkmon 11mo agoAbandoned? When? I still use this pretty much everywhere to create HTML tables. Do people use something else now?
- jckahn 11mo agoYes, React
- iammrpayments 11mo agoWhy would anyone use this outdated code over useInsertRow() and useTableColumnEffect()?
- NetMageSCW 11mo agoWhat are those and where are they in standard Javascript / DOM API?
- zkmon 11mo agoAnd what does that use internally to manage tables? Just because there is layer between you and the API, it doesn't mean API is abandoned.
- __jonas 11mo agoAre you implying that when doing DOM reconciliation, React uses these table-specific insertRow/insertCell APIs for adding and removing elements in tables instead of the regular DOM element APIs it would use for all other elements? I would be surprised if that's the case.
- mpeg 11mo agoThe funny thing is the insertRow/insertCell API just call into DOM manipulation functions like appendChild internally, they just provide some syntactic sugar around things like managing the rows/cells array. It's all the same https://github.com/WebKit/WebKit/blob/28fa568972a4d34d867948618adb4f4cc5532061/Source/WebCore/html/HTMLTableRowElement.cpp#L117-L134 https://github.com/WebKit/WebKit/blob/28fa568972a4d34d867948...
- smusamashah 11mo agoI used this for a small tool I was making to see stable Diffusion images in a table to compare images on different set of parameters, had lots of rows and columns. I needed to regenerate tables quickly, I vaguely remember this API being much slower than making rows/cells via strings. The reason I found was that each call using this API updates DOM and with string it's all in one go (or something similar).
- est 11mo agoplease rediscover html form API
- xg15 11mo ago> Without having to re-render the whole table on each change. That's nice, but isn't that what the standard DOM methods are already doing? Or does that API have any additional abilities? Nevertheless, that's really cool and potentially saves a lot of tedious and error-prone DOM navigation.
- righthand 11mo agoWill Google remove this API then if it’s abandoned? Topic is reminiscent of a submission from yesterday about XSLT: https://news.ycombinator.com/item?id=45779261 https://news.ycombinator.com/item?id=45779261
- simonw 11mo agoXSLT requires hundreds of thousands (maybe millions?) of lines of security-sensitive code. That's why it's proposed for removal. I doubt that's true for .insertCell() and .insertRow().
- righthand 11mo agoBut the precedent isn’t fix the security sensitive insertCell() API, it is to remove it due to low usage. The number of lines is irrelevant IMO. The Google deprecation notice fails to address why a gigantic company with nearly unlimited resources couldn’t implement this feature themselves instead of forcing a breaking change.
- runarberg 11mo agoI feel like IndexedDB is becoming this abandonware as well. There are so many ways where this (IMO rather badly designed) API can be improved but the standards committee seems completely uninterested. Even things like adding BigInt as primative is unimplemented. I fear this will be even worse now that we have the origin File System API and people can bring their own database engines (like web-assambled SQLite). But for those of us that are striving towards smaller download sizes this is a disaster.
- indolering 11mo agoWhat has stalled with IndexedDB and BigInt?
- runarberg 11mo agoLack of interest from standards committee and browser vendors seems to be the only thing stalling: https://github.com/w3c/IndexedDB/issues/230 https://github.com/w3c/IndexedDB/issues/230 I personally think that this stall is simply a symptom of the larger issue that the IndexedDB standard was bad to begin with, and that lead to lax adoption from developers, which deprioritized vendors from fixing the standard, leading to a vicious cycle where even a seemingly trivial issue like adding BigInt support goes unimplemented. I personally think that IndexedDB is salvageable, and not only that, it has the potential to be an amazing web API. But the way things are progressing with the standards committee, I very much doubt it will be any better in the foreseeable future.
- deleted 11mo ago[deleted]
- indolering 11mo agoYeah, they definitely stopped investing in the APIs themselves. If someone can make a polyfill to shoe-horn in the functionality, then they don't really see a need. Which is sad, as we have outsourced our future to TypeScript, React, etc.
- psadri 11mo agoThe 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.
- qzzi 11mo agoCompared to what? What gives you all that, and what prevents you from having it with tables?
- kgwxd 11mo agocountless plugins for use in countless frameworks. We should have all that built-in by now. like we finally have a functioning date picker.
- mcintyre1994 11mo agoJavascript arrays have functions for all of that, so if you use something like React and renders your table from data arrays then it's all pretty trivial. I guess the point is that if you have to use JS to do those manipulations, then at some point it's going to be easier to just the React(/Vue/Svelte/etc) approach than manipulating the table yourself using the API described in the article.
- joquarky 11mo agoFrameworks that make development easy are inherently inefficient. If performance is priority, then you better sort it yourself.
- StrauXX 11mo ago> Without having to re-render the whole table on each change. Not quite sure what the author means by that. Re-rendering pnly happens when the current task queue elemt has been processed. Never while JS is running (aside from webworker and the like). I would honestly be surprised if this API had much (if any) performance benefits over createElement.
- mpeg 11mo agoI quickly looked into the webkit code and there's probably absolutely no performance benefit, the same logic should be running behind the scenes
- _the_inflator 11mo agoSure! And there is way more to it. This kind of code was common and also the starting point of every modern language innovation we have today in JavaScript - even TypeScript, and maybe any modern web development on the server as well. Tables were the only way to create browser independent layouts dynamically. Or put another way: adding interactivity to websites. And simply because hacking is fun and browsers were experimenting with APIs accessible by JavaScript. CSS was still bleeding from ACID tests, Netscape was forgotten, Mozilla build Phoenix out of the ashes of the bursting bubble and called their effort Firefox. In Germany there was and still is the infamous selfHTML project. I remember vividly reading and testing Stefans Münz tutorials on this topic. The content is untouched, only the layout changed, so go back in time for more table fun: https://wiki.selfhtml.org/wiki/Beispiel:JS-Anwendung-Tabellen-dynamisch.html https://wiki.selfhtml.org/wiki/Beispiel:JS-Anwendung-Tabelle... https://wiki.selfhtml.org/wiki/JavaScript/Tutorials/Tabellen_dynamisch_sortieren https://wiki.selfhtml.org/wiki/JavaScript/Tutorials/Tabellen... It was pretty common to have large one file websites: php and html with css and javascript mixed. There was no git, no VisualStudio Code, Claude Sonnet - no, Notepad and later Notepad++ (Even the DOOM guys had no version control system in the early stages.) For me John Resig shines out here. Epic genius behind jQuery. The source code was pure magic, and his book "Secrets of the JavaScript Ninja" is for me the all time climax in programming excellence. If you never utilised the prototype property, you will never understand any of the most basic structures and inner workings JavaScript has to this day and why Classes are "syntactical sugar" for functions and nothing else. Function.toString in combination with New Function made me enter 10 matrices in parallel at the time. What a revelation. :D Nicholas Zakas comes close with his seminal Web Development book, in which he featured every Browser API available at the time with examples on roughly 1000 pages. To this day, exercising most of it and understanding the DOM and Windows object was the best investment ever, because and this fact 15 years later paved the way for the success of a financial SaaS platform. Lost wisdom, not covered by any modern framework like Angular or ReacJS.
- tokioyoyo 11mo agoWoah, it’s always weird to see how there’s modern web engineers that didn’t grow up during the era where entire layouts were built on tables. Not saying that it was good or bad, but just interesting.
- wombatpm 11mo agoI remember doing image maps, splitting large images up into pieces, placing them in table cells and adding links to each cell as a poor man's GUI
- joquarky 11mo agoI did this with OCR text. The OCR software output bounding boxes which I converted into client side image maps. The company wanted to patent it.
- The_President 11mo agoThe 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.
- chrismorgan 11mo agoA lot of people here are clearly not reading the article. It’s not about the <table> 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 <tbody> 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);
- joquarky 11mo agoI feel like frameworks have taken over and so few people know the foundations anymore. Thank you. I still remember reading a news article on C|net about the addition of the <table> element. Yeah, I'm old.
- BobbyTables2 11mo agoThe author didn’t know the <TABLE> tag existed ???
- bane 11mo agoThis is a great reminder that the Eternal September still exists and perhaps mercifully appears to be affecting those with at least some technical exposure. https://en.wikipedia.org/wiki/Eternal_September https://en.wikipedia.org/wiki/Eternal_September
- joquarky 11mo agoAnd the release of the iPhone created another, larger wave.
- louissan 11mo agoHey Chris :-)