Do you know that there is an HTML tables API?

Post by joquarky » Sat, Nov 01, 2025, 10:39 PM UTC

nonethewiser wrote: post #159

stared wrote: post #23

It is similar as with buttons ( https://news.ycombinator.com/item?id=45774182 ). Not sure when it was (10-15 years ago), but at some point everything became s. So, instead of semantic markup, HTML became a UI toolbox.

That's because the DOM is mostly used as a render target instead of a semantic document. I think semantic HTML is a great idea but it's kind of jaded to expect it at this point. It also doesn't help that semantic elements have styling. That right there gives people good reason to use a neutral container as a baseline. In fact I would go as far as to say that having both div and span is a bad design decision. They are…

Post by joquarky » Sat, Nov 01, 2025, 11:03 PM UTC

Izkata wrote: post #140

withinboredom wrote: post #94

Earlier quoted context omitted.

And spans for creating links…

I recently discovered our frontend widget library draws an SVG to implement Radio instead of using . 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.

Post by joquarky » Sat, Nov 01, 2025, 11:07 PM UTC

xg15 wrote: post #104

phkahler wrote: post #97

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.

Post by joquarky » Sat, Nov 01, 2025, 11:16 PM UTC

bane wrote: post #144

This 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

Post by ninjin » Sun, Nov 02, 2025, 2:42 AM UTC

jonathrg wrote: post #60

ninjin wrote: post #19

Earlier quoted context omitted.

Really? The variable name lengths? Not that the code is clearer as: const te = document.createElement('table'); document.body.appendChild(te); [ ['one', 'two', 'three'], ['four', 'five', 'six' ], ].forEach((r, i) => { const re = te.insertRow(i); r.forEach((c, j) => { re.insertCell(j).innerText = c; }) }); My personal stance on short variable names is that they are fine as long as their scope is very limited, which is…

This is not an improvement. Having named variables for things is good actually. They will need to be declared again immediately once you want to modify the code. insertCell(i).innerText = c is a nonsense statement, it should be 2 lines for the 2 operations

    const $t = document.createElement('table');
    for (const r of
            [
                ['one',  'two',  'three'],
                ['four', 'five', 'six'  ],
            ]) {
        const $r = $t.insertRow();
        for (const e of r)
            $r.insertCell().innerText = e;
    };
    document.body.append($t);