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?
121–130 of 249 posts
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?
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 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.
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-*`.
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.
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.
is still not animatable?
https://austingil.com/animating-details-element-with-only-cs...
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...
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…
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.
is still not animatable?
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'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?
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?