Live data from Hacker News

HTML Can Do That

chrisburnell.com

121–130 of 249 posts

Re: HTML Can Do That

#121
js is web remote code execution. we need to return to an html only browser world.

theres no reason for a browser to be an OS/compiler/abi, for remote code.

this is the dumbest shit in the history of computers. why didnt everyone have they torches and pitchforks, when web2.0 became a thing?

Re: HTML Can Do That

#122
post #110

Earlier quoted context omitted.

That's understandable, because almost no one actually works with HTML directly anymore, but it's true. HTML contains tags like for headers, for paragraphs, for line breaks for prerendered text, and for ordered and unordered lists, for tables as well as , , , , , , , and to both explicitly and implicitly describe the layout of an HTML document. In fact, "HTML" itself is an acronym (HyperText Markup Language) in which…

HTML describes the structure of a document, not really the layout. If HTML had or tags, sure. But CSS determines the layout via display/position properties.

is inline

is block

, and are your grid, row and column.

CSS improves on describing layout with positioning but HTML was still doing that before CSS even came along.

Re: HTML Can Do That

#123
post #118
post #26

Earlier quoted context omitted.

That's what javascript is supposed to be for. All of this is what javascript is supposed to be for. HTML describes layout, CSS describes style, JS adds interactivity. Want sortable tables? Get a jquery plugin and spend five minutes, done. This was all solved a decade or more ago.

> Want sortable tables? Get a jquery plugin and spend five minutes, done. I want sortable tables without having to rely on a third-party plugin to a third-party library. HTML describes content, not just layout. It would be a `sortable` attribute on the table, just like you already have attributes that have nothing to do with layout such as `autocomplete` or `aria-*`.

Everyone already complains that browsers are too bloated and now you want to have every browser support sortable tables when a single, simple JS file would work?

Re: HTML Can Do That

#124
post #59

Earlier quoted context omitted.

Input fields are dynamic elements. Textareas can be resized. Pages can be scrolled. Why implement everything anew in custom code if it can be implemented once per browser engine in native code, native UI, and expected/homogenous UX?

I mean the action and target attributes don’t seem to appear anywhere else but the popover api. I’m in favor of HTML dialogs, I just don’t see the point in the trend of making everything into this declarative nightmare it’s becoming when we have onclick=dialog.show() without even quotes.

Script attributes are very often disabled for security reasons.

The declarative actions API is currently only used for popover, but it's been discussed for over a decade to allow SSR of rich content that's interactive before script loading. See also https://developer.chrome.com/blog/command-and-commandfor

For a long time I also pushed back on these interactive APIs because script is a better primitive and every site seems to have quirky requirements. I've come around on it though because there's huge demand for SSR again and businesses are seeing the value in very fast TTI.

I do still think the date picker API is a disaster. Everyone actually needs something much richer than the system date picker. Travel websites want ranges. People want to put dots and day highlights. I wish they'd fix that next.

Re: HTML Can Do That

#125

is still not animatable?

You can animate it now. There's no default though which is a bit annoying. I wish we had made it animate open/closed smoothly.

https://austingil.com/animating-details-element-with-only-cs...

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...

Re: HTML Can Do That

#126
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…

I got frustrated with sites that should just be documents bolting on a pile of javascript libraries, third-party requests etc so I made a standard for sites that are just documents, and wrote a checker for document-only pages. For SSL, the thing that actually changed the web was browsers flagging non-SSL - probably similar is needed here. https://certifiedweb10.org/ if you're interested.

Re: HTML Can Do That

#127
post #102
post #57

Earlier quoted context omitted.

I mildly disagree. You still have to validate what the browser gives you. The user could have edited the "strong contract" using browser dev tools. So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly rob…

GP was addressing the client-side UX, not backend validation, which is an orthogonal concern.

[deleted]

Re: HTML Can Do That

#129

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…

> often think they're not baseline yet

I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?

Re: HTML Can Do That

#130

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…

> often think they're not baseline yet I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?

Support is pretty good in general for these. Click any of the element links in the article and you get taken to the support grid.
Post reply on HN