Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML Can Do That

chrisburnell.com

Post reply on HN
Print view View original

201–210 of 249 posts

Re: HTML Can Do That

#201

Post by hollowturtle »

doodlesdev wrote: post #181
hollowturtle wrote: post #69

Earlier quoted context omitted.

You confuse marketing websites with productivity apps, google docs, figma and many more already render on a canvas using webassembly or not. It's a matter of exposing the right tools

There's friction to doing it this way right now, though. You lose out quickly on accessibility, SEO, performance and developer experience (you need developers that are more experienced). Unfortunately, thinking about it in terms of game theory [0], I believe this is a good thing: I don't want most websites migrating to canvas-like APIs for rendering. My web browser is my agent and I'd like it to mostly render DOM-ren…

You can have programmatic apis for accessibility, SEO pages can be dom based, performance of figma is better than if implemented via the dom api, developer experience? you just get the best and stop pretending you have capable people that spend a day on discussing effects in react.

> My web browser is my agent

It's very likely not anymore, otherwise Chrome wouldn't have pushed for manifest v3

> I wish Figma and Google Docs were just offline-usable desktop applications.

I wish this too, but since we have decided app distribution to be web based, we need serious tools for making serious apps

Re: HTML Can Do That

#202

Post by meerita »

dajonker wrote: post #89

Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed. The only hard thing is still to position a popover near the element that triggers it, such as…

I believe CSS anchor is now widely supported.

Re: HTML Can Do That

#203

Post by bjackman »

dajonker wrote: post #89

Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed. The only hard thing is still to position a popover near the element that triggers it, such as…

> LLMs are also terrible at these new standards.

This seems like a common enough issue that it would be worthwhile publishing a "Markdown library" of "stuff HTML can do" that you can "call" from your AGENTS.md.

Edit: lol, a sibling commenter shows I am not the first to have this idea! https://developer.chrome.com/docs/modern-web-guidance/get-st...

(They made it a skill, which brings me to another thing I've had on my mind lately: that's annoying if you know when you start the harness that you will want it to read the skill. It's a roundtrip through the model to activate it. But maybe there's a way to fix that?)

(Edit2: Claude says if you activate the skill via /skill-name in the initial prompt, you get what I want)

Re: HTML Can Do That

#204

Post by marcomezzavilla »

This article is very close to the idea behind a small website I’ve been maintaining mostly as a reference for myself, but which others might find useful too: https://htmlcat.net

It’s a collection of short "post-it" notes about useful native HTML, CSS, and JavaScript features. It seemed directly relevant to the thread.

Corrections and suggestions are very welcome!

Re: HTML Can Do That

#207

Post by impulsivepuppet »

phyzix5761 wrote: post #38
gunalx wrote: post #33

Earlier quoted context omitted.

Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.

Once backend and frontend became two separate teams frontend people didn't want to keep asking backend to make logic changes for state, so frontend took things into their own hands. The mistake was making it two separate teams.

the frontend team can write a BFF to make all pages render server-side. there is an advocacy group for keeping oauth2 clients out of browsers which gives this idea some _political_ merit. in ways more than one, SPA is not the only solution when a dedicated _frontend team_ is employed.

Re: HTML Can Do That

#208

Post by account42 »

tyre wrote: post #52
gunalx wrote: post #33

Earlier quoted context omitted.

Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.

This is possible and, in my experience building them, the norm. SPAs have routers and update navigation state, including history for browser Back/Forward

It's the norm to try to re-implement browser functionality in JS but it is very far from the norm for the re-implementation to work as well and as reliably as the native browser functionality.

Re: HTML Can Do That

#209

Post by donatj »

hk__2 wrote: post #116
jwr wrote: post #103

Earlier quoted context omitted.

This is… not obvious. It's only easy if you want the simplistic approach of sorting lexicographically or numerically. But in more complex tables, you will often encounter cases where the data representation for sorting is different from data representation for display. Of course most JavaScript-based tables get this wrong, too.

You could have a `sortkey` attribute, a bit like that has a `value` attribute in case the value you want is different from the value you display.

Even then how does it interact with rowspans and colspans...

Re: HTML Can Do That

#210

Post by account42 »

evenhash wrote: post #96
jamescun wrote: post #5

I'm that minutia in your statistics that is still rocking NoScript in 2026, enabling JavaScript on a site-by-site basis, but this is increasingly difficult with the modern web. Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances. I don't often have to write frontend code, but when I do, there is very little in terms of…

One thing you notice running NoScript is how prevalent Google is. Even if a site doesn’t monetize with Google Ads, there’s a decent chance it’s pulling a script from ajax.googleapis.com, and Google still knows that you visited the site from the Referer of the script download.

And lucky for Google, browser vendors (including Google) even decided that caches shouldn't work cross origin so this request needs to be made for every site even if you already visited another site that used the same resource.
Post reply on HN