While programming language theorists have been speculating about “goto”’s more powerful cousin “comefrom” since the 80s, it was only implemented in intercal. Intercal, while clearly superior in safety, performance, and ergonomics to languages like C, has struggled to break into the commercial market (likely because worse is better). It’s exciting to see javascript integrate this feature from intercal- hopefully this leads to a surge in polite programming, analogous to how javascript’s embrace of closure based objects has driven functiOOPnal programming into the mainstream
Haha, I had completely forgotten about intercal and "comefrom".
Such genius. It anticipates and neatly summarizes the problems I've had maintaining and supporting code written using reactive programming design patterns by a good 40 years.
Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine. You want to pose a challenge, maybe try something like Rongorongo or Klingon. Me, I want to write my code in actual hieroglyphics.
you are talking to an Indian who lives in India, and who knows Hindi (a language derived from Sanskrit) fluently (and has been complimented multiple times for his Hindi speaking ability by native Hindi speakers), and who has studied Sanskrit for 3 years in high school and then 2 years in college, and Hindi for 4 years in high school, including grammar, vocabulary and literature (both poetry and prose) in both languages), and also essay-writing in Hindi. and got a high score in class in both those languages, over all the years that he studied them.
and who has spoken Hindi for much of his adult life.
both those languages are written in Devanagari.
>Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine.
whether the (programming) language can grok Unicode, has nothing to do with the number of people who use either Sanskrit or Devanagari, so your statement lacks logic, overall.
you said:
>Sanskrit is written in Devanagari script which is used by nearly a billion people
that statement shows ignorance of actual facts.
here is why:
I had an idea about these points informally, already, being an Indian who lives in India, but I still did a few quick googles, to verify:
List of languages by number of native speakers in India:
>Today, the Devanagari script is used to write three major languages: Hindi (over 520 million speakers), Marathi (over 83 million speakers) and Nepali (over 14 million speakers).
even if you add the number of people in the Indian diaspora, such as in Fiji, the Caribbean, etc., you will not come to nearly a billion.
you made a wrong assumption:
> You want to pose a challenge, maybe try something like Rongorongo or Klingon.
you assumed that I was posing a challenge. I was not.
you seem to have not recognised that my comment was made in jest:
Maybe I'm lost about the greater theory here. As a non-js dev it looks like they're just adding some OO sugar to events. I hesitate to call it sugar because it seems a lot more verbose than "my-menu.show-popover()" but its better than a global listeners I suppose.
It's also foundational in Threaded INTERCAL, where "multiple COME FROM statements with the same label cause the program to fork separate threads at each COME FROM":
That’s a reasonable analogy, but I think the more novel and interesting thing about this is that it’s:
- A declarative mechanism to relate one element to another
- With a range of semantics for declaring interactivity invoked through their relationship
- At a high level, with explicit guarantees of consistent accessibility and UX
In a lot of ways, this looks a lot like what people describe when they wish for more HTML and less JS. (Except for the extreme-minimalist version of that which rejects web interactivity altogether.)
After y'all've had such great success with the Stacked Contractions movement starting in 2017 -- which I would like to take credit for independently spearheading on the Neopets forums in the mid-2000s, but I'dn't've been able to do it all myself of course -- I'd like to propose our next campaign.
Let's bring back pronominal adverbs! You may already be familiar with such classics as "therefore" or "whereas". Why not revive all of them? No longer are "hereunder" and "thereinafter" the sole domain of lawyers. That alone would be an epic meme indeed, but we must go therebeyond. It is difficult to believe that anyone ever actually used words like "therethroughout" or "wherewithin", but we can make sure someone does.
You can even make up your own!
Just take any demonstrative (this/that/these/those), interrogative (what/which/who/where), or third-person personal pronoun, and turn it into the corresponding locative adverb, depending on whether you want to indicate being at, coming from, or going to something:
This -> Here/Hence/Hither;
That -> There/Thence/Thither;
What/who/which -> Where/Whence/Whither;
Him/Her/Them -> There/Thence/Thither; etc.
Makes sense? No questions? Great!
Now pick your favorite preposition and stick it on the end. Don't forget to experiment with some archaic prepositions like "anighst", "overthwart", and -- here's a really good one -- "withinside". That one means "within / inside" and I'm sure you can already see the potential.
"What place should I go into?" Nope! "Whitherwithinside should I go?" Now we're talking.
cough I hereby propose two new language constructs and corresponding keywords, which can be applied (sounds more functional than implemented,) widely across many languages, at least procedural / imperative ones:
goto and comefrom
with optional synonyms:
leave to and return from
the above can be shortened to as little as two letters each:
I can't quite tell if you're serious. Continuations are fun, so I'll post this on the off chance it helps someone.
They are perplexing until they aren't. Model stack frames as independent state. When you return from a function the stack frame can stick around. Now later, place your stack pointer back in the frame that you returned from earlier.
Add a convention for passing arguments when you update the stack pointer as above. Now you have continuations.
so you can place your stack pointer back in the frame that you returned from earlier? that's probably the point at which they stopped understanding continuations before even starting.
I was explaining the joke? Since the person I was replying to seemed to wonder if it was really a joke, whereas for me, structurally it was obviously a joke.
> Buttons ... provide the foundation of interactivity on the web.
This is a very neat way to sum up the difference between the 'old' and 'new' web. Because, of course, it's the hyperlink that provides the foundation of interactivity on the web.
Hyperlinks aren’t interactive. They’re bookmarks. When I click on a link have I interacted with the page? In a sense I have. But have I changed its state? No. I’ve just moved from one static place to another static place.
Ah, sorry. No, I just left out sorting for brevity. Sorting the result of a query is a pure function of its parameters and the existing server state, so it would be perfectly valid to do server-side in a GET request.
But changing the "default" sort order of a resource (either by physically shuffling the rows on disk or by setting some server-side global variable) would not.
I think it's the difference between making a sorted copy of a list (while leaving the original list untouched) and inline-sorting the list.
Same applies to filtering.
Even storing the processed results in a cache does not validate idempotency, because from a client's POV, the behavior of the next request would be the same, whether the server calculates the result fresh or pulls it from the cache.
(Edit: Realized, I mixed up "idempotent" and "safe" methods there. I was talking about "safe" methods - but those are what applies to GET requests and what can be represented by a hyperlink)
This is why idempotency is defined through visible state on the server. What happens on the server doesn't matter, but a GET request should not change the results of any subsequent future requests, as visible to the clients. E.g. adding or modifying a post or a blog entry via a GET request would break the rules.
(Nothing stops you in practice from ignoring that requirement, but it can lead to ugly surprises, such as a crawler triggering a mass deletion because it crawled the /delete links)
> Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course)
No server processing needed: the page returned can be identical with an onload function that grabs the GET parameters and does the processing on the client to, for example, reorder the rows of a table.
Yeah but that was also implemented as a button, right? input type="submit" would display a button in 1993 AFAIK. No javascript and acted like a hyperlink - but still a button.
The most noticeable difference back then (before JS and before CSS) was that browsers displayed very visibly the destination of links, while input buttons were totally opaque. We created buttons with images inside an a href tag to make styled (in photoshop) buttons that behaved like links and generated a GET request. We could add a query string. The only way to make a POST request was a button inside a form.
The author probably mean hypermedias. Buttons and links are just means, but no interactivity even happens without the user clicking or moving their mouse.
Now we can of course talk about client-only interactivity (as in thick clients like paint apps) but that's not the topic.
those are just extra features that let hyperlinks behave like buttons though. Of course, this is under the strict definition that a "hyperlink" is a link between two web pages.
I am not sure if the author actually put any thought into the foundation of interactivity on the web, or if they just asked the AI to write a nice-sounding introduction to their article about new button capabilities.
> Is this just shifting complexity from JS to HTML?
Very well said. This is the problem.
There's an old adage that every "scripting" language starts out small, but then ultimately needs all the features of a full programming language. If we start putting programming features into HTML, we'll eventually turn it into a full turing-complete programming language, with loops, conditionals, variables, and function calls. We'll have recreated javascript, outside of javascript.
>> Is this just shifting complexity from JS to HTML?
> Very well said. This is the problem.
It is a problem. Counterintuitively, it is also a solution.
Lifting some complexity out of JS and into HTML solves some problems. Lifting all complexity out of JS and into HTML creates new problems.
For example, I have a custom web-component `<remote-fragment remote-src='...'>`. This "shifts" the complexity of client side includes from "needing a whole build-step with a JS framework" into directly writing a plain html file in notepad that can have client-side includes for headers, footers, etc.
This results in less overall complexity in the page as a whole.
Shifting the "for" loop and "if" conditionals from JS to HTML, OTOH, results in more overall complexity in the page as a whole.
Horrible. We're going to end up with three separate languages: CSS, HTML, and Javascript, which will each be turing-complete programming languages with completely-overlapping featuresets, and there will be no clear reason to use one over the other.
Browsers will have to implement support for three PL runtimes. Everything will be complicated and confused.
There are tradeoffs. Further increasing the barrier to entry for new web browsers benefits the entrenched players and hurts end users by yielding fewer alternatives.
Developers can use whatever features they want, but users can only watch as their computer uses up more and more energy because it suddenly has to perform yet another build step that previously was done on the server.
That's what people say of C++ too. Too many features makes it harder to learn a language and ramp up on codebases; they'll have different standards on what they use.
Nah that's good. JS is way too powerful and 99% of pages don't need bloat like webrtc, navigator api or thousands of other points that are almost never used for good but for evil.
Html should be powerful enough on its own to provide basic web page functionality to majority of use cases and only then the user should give explicit permission for the server to rum unrestricted code.
It's not just shifting complexity. It improves locality of behavior (LoB). You can look at a <button> element and immediately know what it does (within the limited domain of "command"s). This is a dramatic improvement to readability.
My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there. Behavior of the page can be made visible! There's so much allure to me to hypermedia that's able to declare itself well.
This could radically enhance user agency, if users/extensions can rewire the page on the fly, without having to delve into the (bundled, minified) JS layers.
There's also a chance the just-merged (!) moveBefore() capability means that frameworks will recreate HTML elements less, which is a modern regression that has severely hampered extensions/user agency. https://github.com/whatwg/dom/pull/1307
> My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there.
I would love this. As a Tailwind user the last few years, it’s really been refreshing to have my styles both readable and inline on the elements instead of filed away in SCSS I’ll never see again. Even with scoped styles, some components get large enough that it feels unwieldy
That's why I rather keep HTML limited than embracing something like Svelt (which I haven't heard of before). Looking at it's inline syntax in the example, it is yet another something to learn. Yet another thing with peculiarities to keep track of, solving one kind of problem but introducing more complexity by spreading logic out (taking logic from one place and putting in another creates an additional relationship which is a relationship with that from which the logic was taken: Svelt and JS has to coexist and may for example overlap).
My favorite experience of shifting logic is writing a template engine in PHP. PHP is a template engine. I soon discovered I tried to replicate more and more PHP feestures, like control flow etc. I realize PHP did a way better job being a template engine. (This does not disqualify all use of said things, just that all seemingly good use cases aren't motivated, and may not turn out as expected.)
> Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist?
The same way React or other frameworks can hook into things like CSS animations. If CSS animations didn't exist, the JS framework would have to write all the code themselves. With them existing, they can just set the properties and have it work.
Even if you're writing a basic menu popup directly in React, having these properties to use directly in your JSX means less code and less room for error.
Then if you need to do something special, you may need to do it by hand and not use these properties, just like if you needed a special animation you might have to do it without using the CSS animation properties.
I'm not a web dev, so I apologize if my questions are naive. Does this mean its a chrome-only thing or does it become a web standard? I ask because I would like to imagine the future isn't tied to Google's whims, graveyard of initiatives, and requirements.
That would be really nice, but, that’s been the way of it for the last few features too… it might not get adopted, but if enough people start using it…
My experience with anything declarative is that features are gradually bolted on until it eventually just becomes imperative (and ugly). For example HCL.
I believe declarative should stay purely declarative to describe data/documents in a static state (e.g. HTML, JSON) and an imperative “layer” can be used to generate or regenerate it, if needed.
Is this really the action/messaging pattern that Next, Be and then Apple and probably others used about 30 years ago, or did I miss something here.
It was useful in a way but basically evolved into interface-based controller patterns due to the needed complexities and the whish to keep the basic underlying design pattern. So I'd expect to see lots of enhanvement requests once that box was opened :)
There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.
You thought web was 15 years behind, but it quickly catches up to 30 years old tech!
News like this make me feel sick. I thought it could become something usable in my lifetime, but I’m knee osteoarthritis years old and it still reinvents poor man’s target-action. Sad clownage.
> the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.
Didn't these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions/attributes?
Sometimes things like these make me wonder if the people in charge are conscious about that everything they are putting in will stay there forever. You can't just release an update and remove stuff you ("you" as in: the web devs at your company that happen to be in the same company that builds a browser) don't need any more.
I thought that was odd, too. It would have made more sense if they'd implemented this for media controls first, and then consolidated the popover attributes into it later. This feels like a record for fastest deprecation of a web feature ever.
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
2033:
> While HTML offers command and commandfor handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
I don't know if it's the way my brain works, or just an aesthetic thing, but I am completely allergic to programming with strings. Totally get the reasoning behind this, especially the accessibility wins, but I'm not particularly excited about using element IDs for yet another layer of web app behavior.
Stringy code is my go-to example of a code smell. You can do it, it works and yes, as long as you write it correctly it will work correctly, but you're just kicking the can down the road, at best.
HTML elements are naturally stringy and that makes sense -- when the HTML describes a document. But in the context of complex applications it leaves a lot to be desired.
It's a hack.
This isn't to say the feature being discussed is a bad thing. It's obviously a hack. On such an established platform, there's suprisingly little room between 'throw it all out' and 'just one more patch'.
I agree, but at least it is consistent. This is also how `for`, `list`, `aria-labelledby`, `aria-describedby`, and probably many other attributes work.
Seems like they shouldn’t have implemented this without a full API. Instead the 5 or so commands, it looks like it’s possible to implement ALL JavaScript functionality through HTML, including high level APIs. That could be thousands of commands..
I don't see how it should be too hard to implement, you could abstractly have a system where the command string is translated as such:
1. Split the string by dashes into an array
2. Make the first character of the first array item lowercase, make the first character of the rest uppercase
3. Concatenate the pieces together
4. Do `document.getElementById(element.commandfor)[concatenated]()`
Obviously this doesn't have the myriad number of checks to make sure that the element exists, the method exists, the method takes no parameters, etc.
This would also allow custom commands easily, since you could do `document.getElementById(element.commandfor).myCustomMethod = function() { /* ... */ }`
The real power is custom commands and a standard way to implement them. The built-in commands will always be just conveniences that many convert to a custom version as complexity increases.
Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.
This is my thought too, I'm having trouble envisioning a case where a reasonably complex UI wouldn't still need JS. I guess it provides a roadmap to incremental adoption.
No, it is terrible that "they" continue to extend and "improve" HTML.
This is the reason it seems impossible for an independent web browser to be created and maintained: because what should be a simple and predictable spec over the last twenty years is a rapidly moving target that takes significant resources just to track.
We could have ten different open-source web browsers (like Konqueror) if we weren't cramming the HTML spec full of bloat that nobody wants and that we all install extensions to disable anyway ...
I’m pretty sure this is the only goal. Everyone with a neuron or two can see that the internet doesn’t use web tech and abstracts it away as soon as possible. These people just grow their corporate security by adding nonsensical bullshit that makes zero difference irl.
Sane competition, developers and end users would benefit from competition. This is just corporate lock-in. When a user is required to install Chrome for using a web app we're failing him as a platform, and the open web goes off the rail
Having a browser written entirely (or mostly) in a memory safe language.
LadyBird is now using some Swift, but most of the code is still C++. The browser, while extremely impressive (and I’m very thankful it exists), has a ways to go before it’s a true replacement for Chromium/Blink, Firefox/Gecko or Safari/WebKit, and rewriting all the existing code in Swift would be a massive undertaking.
Chromium and Firefox also use some Rust, but re-writing those browsers entirely in it would be an even larger undertaking.
In contrast, a simpler browser spec would make it far easier to create a brand new browser in a memory safe language. Not only would this massively improve security on all operating systems as the browser is a huge vector for exploits, it’d also allow for the creation of new, more secure operating systems. Currently, arguably the biggest blocker for using something like RedoxOS (an OS written in Rust) is that it doesn’t have a web browser that can actually work for a lot of the web. But if the web browser spec were simpler, it’d be much easier to create one and then use that OS.
Obviously we can’t go back in time and make a simpler web-spec, and removing features is a terrible idea as it’d break existing websites. I do think, though, that it’s fair to think very hard before adding new features. I think a complete feature freeze would be overkill — some new features could legitimately make web development simpler and cleaner for many webdevs. I do think there needs to be some thought as to what the end-goal for web browsers is. Is there one? Or will we forever continue to add new features at the current pace? If so, the hopes of building a new, more secure browser are dim. And personally I’d prefer a more secure browser to one with more features.
As a comparison, C++ has been adding plenty of new features, but nearly no devs are aware of the full feature set, and despite the goal of making things simpler, I think many devs are as lost as ever with it, as they still have to interface with code written in old and different manners. On the web dev side, some JS and CSS features do legitimately simplify development and make things easier, but I think it’s fair to say that’s not the case for all new features added.
Between this and other changes I worry they are just throwing more and more stuff at the wall to widen their browser moat.
Is command and commandfor actually a good idea? I understand the point of it, but it seems like yet another layer of cognitive load.
Instead why not just apply the same principle to CSS? If I could make a CSS selector for one element but have the result target other elements, then one could achieve the same results and more. It would require only a few more pseudo-selectors. And while it probably isn’t necessary, I think it might be prudent to mark the properties that undergo state changes. Something like:
I'm wondering if these new html features will eventually get traction, anyone knows how's the usage of latest popover and dialog elements? I'm asking because I always wondered who would ever use them as JavaScript based dialogs are so ubiquitous and they can't easily be content blocked vs querySelectorAll("dialog") and disable them. For the sake of being semantic? But who really would write a semantic web anymore? Maybe for AI Agents? Why keep bloating the web platform?
I don't know who else is doing it but my team and I always use semantic HTML, including dialog elements
It is, unfortunately, the least I can do to respect the user, since I have no control over the decision to load horrible tracking scripts onto their browser.
I really wish everyone would use semantic HTML wherever possible. The gains for accessibility are huge.
Take a JS dialog or pop-up menu, for example. You would think it would be easy for everyone to use, but a screen reader user might not even be aware that it’s there in the first place. Even when they do, they still need to find it in a linear and possibly very cluttered representation of the page. It could be right next to the "open menu" button, at the bottom of the page, or somewhere else entirely. The menu/dialog could also disappear as soon as they move the focus in an attempt to find it!
These are all things I put up with regularly.
I think anything that makes accessibility easier for developers is a good thing, especially if it just works without having to think about accessibility.
Google being Google, they may do it just for the sake of squeezing revenue from less likely blockable ad popups.
This explains why they decided to work on HTML dialogs out of the blue. In their mind, dialog is popup, and an ad popup that you cannot block equals more money for them.
Probably they are creating an area in specification for them to exploit in the future. In a twisted way of course, via extension manifest V4 or something like that.
I think you're confusing some stuff. A native dialog element as a popup is easier to block, for example, you just have to select all dialog elements by tag name and convert them to div inlined elements or something like that. Can't do the same reliably when the dialog is created by a javascript library using a div that uses a random id or generated class name
Oh, this seems like a nice generalization of the popover specific attributes. Could replace <button type="submit"> with <button command="submit"> and default commandfor to the ancestor form.
We need a proper rich UI application execution environment, and if HTML, being a primarily document oriented platform can’t be retrofitted to provide that, then we need a new one
Ian Hickson, who authored the HTML5 spec and leads Flutter, has written about exactly this, Towards a Modern Web Stack [0][1], to create a new stack that can handle modern web applications. Flutter is a part of it but he talks about a more general (and generalizable) stack. He's on the HN thread as well expanding on the rationale behind it. Interestingly, it seems like specific people on HN don't exactly like it, a bit funny to witness their crash outs.
I have gone through Hickson's proposal, interesting.
I notice though that he is proposing to address the problem from the opposite direction to mine, though I think his approach is also viable. I dream of an HTML-like platform built to support rich UI apps, with much higher-level configurable primitives that eliminate the need for massive amounts of scripting and dependencies. He talks about providing properly configurable low-level primitives.
Both approaches can work if built properly to support what developers actually want to do. One thing that put me off WASM was the dependence on JS to bootstrap it. I just did not want to have JS in pipeline again whatsoever if I was taking that approach. The advantage of high-lvel primitives is that there will be much more of what developers want to build that is already built into the platform.
+1. The Web Platform is this interesting blend between declarative and imperative, but with the benefits of neither.
IMO, the web platform needs a retained mode UI model like Qt Widgets, AppKit, or UIKit. Then desktop-like applications like Figma wouldn't need to compile to WASM and render WebGL for their UI. They could just treat <divs> as views or layers.
Using document.addEventListener means it will work even if the DOM is updated without having to add new event listeners. If I'm not expecting the DOM to change I would be more inclined to do something like:
document.querySelectorAll('.menu-wrapper')).forEach(menuWrapper => {
const button = menuWrapper.querySelector('.menu-opener');
const content = menuWrapper.querySelector('.menu-content');
if (!content || !button) {
return;
}
button.addEventListener(() => {
button.setAttribute('aria-expanded', 'true');
menu.showPopover();
});
content.addEventListener('toggle', e => {
// reset back to aria-expanded=false on close
if (e.newState == 'closed') {
button.setAttribute('aria-expanded', 'false');
}
});
});
The React example seems a little odd as well, if the "open" callback actually called "showPopover()" instead of only calling "setIsOpen" then the "useEffect" could be entirely redundant. The resulting code would be a lot clearer imo.
> it will work even if the DOM is updated without having to add new event listeners
Nailed it.
And the sibling comment got at it but the "magic phrase" to Google for this technique is "event delegation." Two more phrases: delegation relies on "event bubbling," bubbling can be interrupted with "event capturing." (You will rarely want to capture events, it's JS's `!important` equivalent)
Generally you do it the "document" way (often called a "delegated" listener) when you have lots of elements you want to listen to, or particularly elements that will be dynamically added and removed.
If you listen directly to every target element, you have to find the elements and loop through them all, they have to exist at the time you set the listener, and you have to make sure to add the listener every time you add a new element that has the same behavior. If you listen at the document (or some appropriate parent element) and then check if the element that fired the event matches what you're trying to handle, you can have one listener that will apply to all the matching children regardless of where/when/how they're added.
It is a common pattern on the web indeed, and it's called "event delegation" if you want to search more about it! As others said, allows binding an event handler once, so it can just sit there and wait to be triggered regardless of how much the actual page content changes due to user interactions (rather than a new event handler being bound every time a new button or interactable element is created).
This hack has terrible accessibility. For one, the <label> is not focusable by default, so keyboard users won't be able to toggle the popup at all. And I don't think it's possible to dynamically set ARIA attributes without JS.
I was just working on an app where this exact pattern would have been useful. The app mixes serverside html with some sprinkles of React for a checkout flow. Command and commandfor would have made the linking of the two much nicer. Apps following the islands pattern will also benefit from this feature.
Sidenote: I think the web's biggest problem in the future will be how hard it is to deprecate functionality.
Maybe we need Html6 to be about removing/simplifying features from the browsers?
>the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.
At first I was worried because they just added the popover API recently, which itself replaced <dialog>, but this is still using the same API, just calling it from HTML differently. Still, I'm not fully clear on what the long term goal here is? Replacing UI toolkits? Simplifying state frameworks by removing js from certain functions? For example, the play/pause functionality.[0] For a simple website, you don't need to add any such functionality because browsers have built in video players that allow you to play, pause, mute etc. So this isn't necessary for simple websites. But then for websites that are more complex, you would already be using js presumably?
I do mostly like what is written here about the project in general, which seems to answer the above question:
>But another 15 years have gone by since the last major revision to form and UI interfaces. Most complex web projects today need far more than what HTML5 form and UI controls provide. And so, all-too-often today’s web developers turn to heavy JavaScript frameworks to build the user interfaces their designers are asking for. These custom interfaces are rarely fully accessible. They slow down the page, consume power, open security vulnerabilities and exclude people.
>Additionally, today’s projects often reject existing built-in form and UI controls because they require more agency over the look and feel of the interface. Web designers demand the ability to express their project’s branding across every element on the page, including all user interfaces. Current form and website-level UI controls do not allow for this.[1]
So the goal is to remove JS from UI components for UIs that already exist natively in HTML. Still, at least for the above video example, some sites want different behavior when the user taps on the screen. Some will bring up the video playback bar and settings, others will immediately pause, others will pause if the playback bar is hidden and remove the bar if visible, etc. I don't see how you can do that without JS, at which point el.playing = false seems much better than using a button command attribute. Or is this just a bad example?
Interestingly the examples don’t show interaction with <form>. In the deletion confirm example, can I put this inside a form and have it continue to POST when confirmed and cancelled when cancel is hit in the popover?
If I still need js to then submit the form it feels like this falls quite a bit short.
The author is not affiliated with Google. Is this from "external" contributors?
If such a thing called open-source is still happening here, I would send all of my respect to you the people who do it for the Web.
Author here. I am not affiliated with Google. My current employer is GitHub, and this was incubated in the OpenUI working group. Open source & the open Web are still very much alive!
It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).
The reason onclick is disallowed is because it permits full JavaScript execution. An onlick attribute is ‘eval’d on click. If you can inject one into a page you get JavaScript execution. Hence, content security blocking - a rule served up on the page saying ‘nothing in this page is supposed to have onclick attributes. If you see one ignore it’.
These command attributes are not arbitrary JavaScript hooks. They tell inbuilt components to do inbuilt things. It doesn’t make sense for a content security policy to say ‘nothing on this page has commands, if you see something that does ignore it’, any more than it would make sense for a content security policy to say ‘nothing in this page is in bold, if you see something that says it wants to be displayed in bold ignore it’.
This makes sense, but it feels like the case is overstated... Is it really common for sites to disable their own onclick attributes? Is it just the case that the CSP rule disables onclick in the HTML, but first party scripts can then attach event handlers separately?
If you’re dynamically generating the HTML it’s safest to set the CSP to disable all inline scripts; you can permit only static scripts served from known good locations with valid sub resource integrity hashes.
web devs will get ahold of this and demand that they have the ability to change the size, the animations of appearance and disappearance, specify a sound that plays when the menu is opened or closed, etc. I'm saying that this, like all other web things, will be bastardized and mutilated until it is just as complex and unworkable as the existing solutions which this is intended to replace.
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
WTF. Is this for real? This attribute has been around for decades. It used to be the only way to handle events. Can't believe what I'm reading here. All frameworks use a similar construct. What is the actual problem with onclick attribute?
> What is the actual problem with onclick attribute?
It's a string, so it's basically eval(), and eval gets disabled for all kinds of legit reasons. It often gets disabled along with inline script tags, which shuts down a whole class of XSS attacks -- which maybe your code isn't vulnerable to, but who knows what some random third party markdown renderer might enable?
The alternative to on* attributes is addEventListener, which has also been a thing for decades.
Thank you for highlighting the difference between onClick and addEventListener - my frontend skills are rusty and I'd forgotten how prevalent the equivalent of eval(some_string) is.
Wow. This is just silly. The issue is executing untrusted JavaScript... Why would the developer put untrusted Javascript inside the onclick handler? If writing vanilla JS, this would basically never happen. The use of onclick is ridiculously widespread too and it's very rarely misused.
With that kind of logic, why not disable fetch() calls and all other calls to any backend service? You know, the backend might respond with some untrusted user input which might end up executed as a script (e.g. in a template or something, some frameworks use eval or a dynamic Function)... We need to protect the developer from that risk... All webpages should be static web pages; no untrusted remote data!
I mean these arguments don't quite make sense. You can't remove useful functionality which could potentially be misused under the pretext of adding security. By the time you remove all such features, there will be no features left to use at all! You will end up with a very secure brick which does nothing.
If you can get over your sputtering moral outrage, you might try looking up things like XSS attacks and how Content-Security-Policy can mitigate it. XSS can have vectors that are more subtle than just raw-echoing back an input field, and CSP is a set of guard rails that can mitigate any potential damage it can do.
Well I guess it can serve some corporate use cases were most people don't have the skills to identify issues and prefer to have a policy to just blanket ban all.
It's a habit in certain large companies to just ban any tool which might potentially be misused.
I see the utility but it's disappointing. I hope they don't force it on everyone because the risk vs solution tradeoff is not relevant to most entities who use it.
The direction of web standards is problematic. Getting overengineered. CSP is retarded. Trying to prevent all possible security vulnerabilities by removing functionality is just dumb and an impossible task. It's just converting a simple vulnerability into a complex vulnerability. Things are headed in a bad direction. Throwing the baby out with the bathwater... To remove all possible vulnerabilities means removing all possible features. Web programming will become a useless bureaucratic mess if we continue down this path.
when are you guys at chrome planning to add a virtual scroller or virtual list or virtual table. pretty sure every infinite scrolling pattern out there could use a component like this
Random aside. Their code snippet has this comment:
// popovers have light dismiss which influences our state
And I hadn't heard of that phrase before! Turns out it means "clicking elsewhere closes the thing:"
> "Light dismiss" means that clicking outside of a popover whose `popover` attribute is in the auto state will close the popover.[0]
Like what, say, a `<select>` does when open.
Strikes this dev as a pretty unintuitive way to phrase that. At first I thought it was "light" as in "light DOM," but I guess it's "light" as an antonym of "explicit?" Looks like there was some back and forth on this, and it was even proposed as an attribute: https://github.com/openui/open-ui/issues/834
Also random aside. I dislike this pattern for modal dialogs. Often times I will need to gather information from somewhere else, and in the process of attempting to get focus back to the dialog I've touched/tapped/clicked on something that dismisses the dialog. Very annoying.
I'm okay with modal dialogs working that way as long as people get the message: dialogs are supposed to be ephemeral. If closing the dialog loses important state, or you need information from something under the dialog in order to use the dialog, what you have shouldn't be a modal dialog. And you can tell, because in most UI frameworks that widget is just begging to be closed. Unfortunately, a lot of teams don't get the message.
Just noticed this bug in Simplifi expense tracking web app. The drop down to update the category of a transaction has multiple levels (e.g. Business:Travel:Lodging) and as soon as I hover over a nested drop down the whole thing disappears.
Light is the opposite of hard (ie hard close). It makes more sense (to me!) to use explicit vs implicit close? Clicking outside the popover means an implicit close.
It’s just like the target / selector pattern from NeXT AppKit over thirty years ago… Except that the syntax is clunkier and less type-safe than what they did using 1994 Objective-C.
It’s not exaggeration to say that the web has set UIs back by decades.
The other day I was trying to make editable table cells in a leading “enterprise-grade” React component framework. It required several screenfuls of obscure and brittle code. The same operation used to require implementing a single delegate method in 1990s AppKit.
I find it remarkable that despite the massive improvements to CSS and JS in the last 15-ish years, additions to HTML are glacial. I mean we only just got popovers for christ's sake.
It's like JS and CSS are fully on board with being an app platform and HTML is digging its heels in insisting that everything be a document. There is maybe something to be said for that argument, but if I'm gonna have to interact with web apps I'd rather the list of stuff every developer needs to hand-roll in varying-quality JS be a lot smaller than it currently is.
I think that the root of the problem here is that, just like the acronym says, HTML really is, at its core, just a markup language for writing hypertext documents.
Using it as a domain specific language for user interface layout is a horrible kludge that only continues to exist because natural selection doesn't give a damn about sensible design.
What's mindboggling to me is that when HTML5 came out people were swearing Flash (and Java applets) would be obsolete. Years later the replacement has been the most horrid spaghetti imaginable because no matter what framework or engine you use, it's going to become HTML+JS!
They should just start supporting Java in the browser again. Java. Javascript. Nobody is even going to notice.
I always thought it would be neat if python had been used instead of JavaScript.
I have written web apps in c++ (wt framework) and it’s really neat to be able to leverage c/c++ libs we already had, which was what tipped the scales in choosing it.
No it’s not the bees knees, but I can be productive, and new folks can jump on board and also be productive, very quickly.
I love python, but I don't think Python is the solution to Javascript. I mean, Python is much better than Javascript, but Python's type hints are much worse than Typescript. A modern language needs to be something like Java, but with null types.
What actually needs to happen is for wasm to get good enough that everything else is just implemented on top of it. Not that it'll save us from the flame wars over which language is better to compile to wasm, but at least you could actually pick your poison then...
I think it's good that HTML serves a narrow purpose. What's problematic is that we want every other purpose to be served by just one or two things (CSS, JS). It shouldn't be a struggle to differentiate between "script that makes buttons work" and "script that browses cat videos and downloads them to your hard drive". We can call it "minJS" and "maxJS" or something, and make it so users can disable "maxJS" without disabling "minJS". Or wait, why even mandate JS at that point? The biggest problem with the Web is not particular design decisions (although of course they have many problems), but the fact that we won't change them fundamentally and instead just keep piling things on.
My sense is that JS and CSS have an easier time with building gracefully degraded experiences than HTML might. On top of that, changes to HTML either have to be isolated (no accompanying changes to JS in the browser), or they have to be coordinated with the updates to JS.
> It’s not exaggeration to say that the web has set UIs back by decades.
The trade-offs for the UI setback are unbeatable cross-platform compatibility, ease of distribution and a decent security model with sandboxing. MacOS only introduced desktop app sandboxing in the last 10 years, most desktop run software with user permissions which is not great.
Sure, though the question was about "making a table cell editable" requiring pages of obscure code.
_Technically_, it requires a single HTML attribute.
If you want to build some sort of reactive, spreadsheet-like experience with cells and calculations, then yeah there's some inherent complexity in that.
> It’s not exaggeration to say that the web has set UIs back by decades.
These claims always seem to break down once you ask for concrete examples.
1. The React/JS code is far simpler and less clunky than the Objective-C equivalent.
2. The HTML commandfor/command is declarative and simple unlike Objective-C target/selector
Paste the HTML commandfor snippet from TFA and ask an LLM what the Objective-C equivalent. If you think it's less clunky, go ahead and paste it here for us to judge. ;)
> It required several screenfuls of obscure and brittle code.
Yet still better than the brittle, obscure horrors of the procedural Objective-C Cocoa apps I used to have to work on.
"1.1. The React/JS code is far simpler and less clunky than the Objective-C equivalent.
Hard disagree - in objective C, I never had to worry about making sure I (and every library I use) calls hooks in the exact same order on every single render, for example.
It does this for 'brittle" reasons - it associates state with the order of hooks.
(For any react folks - this isn't meant as judgement as much as an explanation :P)
Since i'm semi-retired, and only do this for fun, i spent a a week last month chasing down react hook usage bugs in libraries my app depended on and sending patches. I think i got up to 23. Because the ecosystem in javascript is so deep on dependencies, you often depend on an amazing amount of people getting everything correct. This was much less true in Obj-C as well.
Some of them had also made 'the error go away' by moving code to useCallback's inside setTimeouts so they wouldn't be noticed by the hook checker (but this in turn has no guarantee of ordering wrt to react effects, of course), leading to even more subtle bugs.
I won't even get into things like async in react vs objective-C (though to be fair, bad integration with async afflicts a lot of popular JS frameworks)
In the end:
React is fine once you learn it.
Obj-C is fine once you learn it.
But acting like react is not clunky or brittle is, and obj-c is, is definitely a stretch.
All of the things here are clunky and brittle, just in different ways :)
>stupid me thinking because it's a superior solution.
You think your snarky sarcasm fits, but it really doesn't. "Oh, everyone uses it, so it must not actually be bad?" That's not a good argument at all. :D
The main feature of the web is ubiquity. Doing a native app requires installation, update handling, etc.
That’s why the “web won.” But, when it comes to UIs, it is not technically superior.
The most popular technology is usually not exceptional in every aspect but is the most convenient for popular use cases. For example, LISP predates C by decades. Technically, C is inferior in abstraction, but ATT used it for Unix, quickly becoming the de facto standard for systems programming. That makes C a better option than LISP, only because you’ll need to go into extra layers of complexity to do a system call designed for C.
For the web, you can only use HTML/CSS/JS (even with WASM).
“Mobile doesn’t use shit from 1994”… well all the iOS apps are based on Next frameworks created in the 80s.
You probably have never used a native UI framework or tried to create an accessible component library for the web, to say something like that. Try to create an accessible select component that shows an icon in its options using a native framework and HTML, and you’ll quickly see what I mean.
Please don't be creating select components. The native one is just fine and works 100% of the time. For those of us using translation tools and trying to navigate the shit designers came up with because they want to make it "pretty" is just ... annoying and full of grief. Just say no.
The web is the best application distribution mechanism the world has ever seen. Even though things have improved enormously in the last decade and a half, the ceiling is still miles below native (though the floor is far more accessible). None of that matters though, because all someone needs to do to get your app in front of their eyeballs is type a URL.
Have you been following how HTML has evolved over the past 20 years? Your comment suggests not.
It’s not entirely a standards-driven process. It’s common for browser vendors to just build stuff. That’s been a mixed blessing but it has definitely been faster than some W3C consortium debating “ergonomics” for years.
Successful additions get backported into the spec, slowly.
Chrome is the new IE. Whatever google decides will become a standard (both defacto due to them controlling the market and just shipping new version just in time and de-jure due to them financing W3C consortium and other standard bodies)
Next thing we’ll get DOM events beforecommand and aftercommand. /s
In principle this declarative approach goes in the right direction, but without an overarching concept and vision of the web UI of the future, this feels like adding just another wrinkle to the stack.
While programming language theorists have been speculating about “goto”’s more powerful cousin “comefrom” since the 80s, it was only implemented in intercal. Intercal, while clearly superior in safety, performance, and ergonomics to languages like C, has struggled to break into the commercial market (likely because worse is better). It’s exciting to see javascript integrate this feature from intercal- hopefully this leads to a surge in polite programming, analogous to how javascript’s embrace of closure based objects has driven functiOOPnal programming into the mainstream
C# has COMEFROM, too: https://github.com/dotnet/roslyn/blob/main/docs/features/int...
they make it cumbersome to use by hand, but not impossible
Haha, I had completely forgotten about intercal and "comefrom".
Such genius. It anticipates and neatly summarizes the problems I've had maintaining and supporting code written using reactive programming design patterns by a good 40 years.
>hopefully this leads to a surge in polite programming
But not too polite. The compiler wouldn't like that.
Demure is the fashion these days, I'm told.
Spoken like a bussin’ sigma that eats - no cap.
Word to your mother.
Very.
Well, at least the Boo compiler would not.
https://en.m.wikipedia.org/wiki/Boo_(programming_language)
Of course not. Sycophantic code is quite grating.
what's the download site for the psycho-fantic language? gimme! puhleeze.
How are command and commandfor similar to comefrom?
They seem similar to goto to me. With goto, the trigger specifies what to do. That's what command and commandfor do.
With comefrom, what to do specifies the trigger. That seems similar to the existing document.addEventListener() in Javascript.
I don't see either. It's not even similar to goto. It's nothing more than method invocation, which is nothing like goto.
Python implementation (not mine) for comefrom and goto, so old it predates a pypy package - and very much for good reason! https://entrian.com/goto/
Perl has supported comefrom for decades! https://metacpan.org/pod/Acme::ComeFrom
b-b-but ... does Perl support Sanskrit? if not, I hope at least Raku does.
with its grammar feature, it well might, or might as well.
https://en.m.wikipedia.org/wiki/Raku_(programming_language)
https://en.m.wikipedia.org/wiki/Sanskrit
Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine. You want to pose a challenge, maybe try something like Rongorongo or Klingon. Me, I want to write my code in actual hieroglyphics.
Sanskrit can be written in the Devanagari script (and these days most commonly is). But it does not have an attested native script <https://en.wikipedia.org/wiki/Sanskrit#Writing_system>.
But still, so long as it’s a script in Unicode, it should all work fine.
TeX will allow you to rewrite the parser (ala TeXInfo), and using a unicode engine will allow you to use UTF.
TeX will also allow you to embed and force fonts.
Final step: Use something like Lyx, that will let you write and see the embedded font.
>Me, I want to write my code in actual hieroglyphics.
snarky / slimy, discriminatory comment, much? not to mention highly ignorant, as I said in my sibling comment.
I took a look at your comment history.
seems to prove what I said about your attitude.
creeped out by it.
wow. what a number of errors in your comment:
intro:
you are talking to an Indian who lives in India, and who knows Hindi (a language derived from Sanskrit) fluently (and has been complimented multiple times for his Hindi speaking ability by native Hindi speakers), and who has studied Sanskrit for 3 years in high school and then 2 years in college, and Hindi for 4 years in high school, including grammar, vocabulary and literature (both poetry and prose) in both languages), and also essay-writing in Hindi. and got a high score in class in both those languages, over all the years that he studied them.
and who has spoken Hindi for much of his adult life.
both those languages are written in Devanagari.
>Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine.
whether the (programming) language can grok Unicode, has nothing to do with the number of people who use either Sanskrit or Devanagari, so your statement lacks logic, overall.
you said:
>Sanskrit is written in Devanagari script which is used by nearly a billion people
that statement shows ignorance of actual facts.
here is why:
I had an idea about these points informally, already, being an Indian who lives in India, but I still did a few quick googles, to verify:
List of languages by number of native speakers in India:
https://en.m.wikipedia.org/wiki/List_of_languages_by_number_...
Demographics of India:
https://en.m.wikipedia.org/wiki/Demographics_of_India
https://www.google.com/search?q=number+of+people+who+use+dev...
top paragraph of the results of the above search:
>Today, the Devanagari script is used to write three major languages: Hindi (over 520 million speakers), Marathi (over 83 million speakers) and Nepali (over 14 million speakers).
even if you add the number of people in the Indian diaspora, such as in Fiji, the Caribbean, etc., you will not come to nearly a billion.
you made a wrong assumption:
> You want to pose a challenge, maybe try something like Rongorongo or Klingon.
you assumed that I was posing a challenge. I was not.
you seem to have not recognised that my comment was made in jest:
>b-b-but ... does Perl support Sanskrit?
Dude, I don't think you're capable of jest. Get some therapy.
Maybe I'm lost about the greater theory here. As a non-js dev it looks like they're just adding some OO sugar to events. I hesitate to call it sugar because it seems a lot more verbose than "my-menu.show-popover()" but its better than a global listeners I suppose.
COMEFROM is one of the many great jokes that form the Intercal language. I recommend reading the language specification.
Of course, COMEFROM's grown up (and very real) sibling is ALTER GOTO in COBOL.
So I tracked down this programming manual for intercal https://3e8.org/pub/intercal.pdf and can't locate any mention to comefrom.
It is from a dialect called C-INTERCAL and is written with a space: 'COME FROM'
https://www.cs.virginia.edu/~asb/teaching/cs415-fall05/docs/...
It's also foundational in Threaded INTERCAL, where "multiple COME FROM statements with the same label cause the program to fork separate threads at each COME FROM":
https://esolangs.org/wiki/Threaded_INTERCAL
Thanks for that correction! I had memorized COME FROM as part of the original Intercal. My mistake.
That’s a reasonable analogy, but I think the more novel and interesting thing about this is that it’s:
- A declarative mechanism to relate one element to another
- With a range of semantics for declaring interactivity invoked through their relationship
- At a high level, with explicit guarantees of consistent accessibility and UX
In a lot of ways, this looks a lot like what people describe when they wish for more HTML and less JS. (Except for the extreme-minimalist version of that which rejects web interactivity altogether.)
Not to mention reversible computing's "gofrom" and "cometo".
My new language is going to include thataway, overyonder and uptown constructs.
2 the !!boogie, say(^jump the boogie)
Given that “come to” means “regain consciousness”, this pair sounds like it should be about thread sleep control.
comehither
FromYonder
whence
After y'all've had such great success with the Stacked Contractions movement starting in 2017 -- which I would like to take credit for independently spearheading on the Neopets forums in the mid-2000s, but I'dn't've been able to do it all myself of course -- I'd like to propose our next campaign.
Let's bring back pronominal adverbs! You may already be familiar with such classics as "therefore" or "whereas". Why not revive all of them? No longer are "hereunder" and "thereinafter" the sole domain of lawyers. That alone would be an epic meme indeed, but we must go therebeyond. It is difficult to believe that anyone ever actually used words like "therethroughout" or "wherewithin", but we can make sure someone does.
You can even make up your own!
Just take any demonstrative (this/that/these/those), interrogative (what/which/who/where), or third-person personal pronoun, and turn it into the corresponding locative adverb, depending on whether you want to indicate being at, coming from, or going to something:
This -> Here/Hence/Hither;
That -> There/Thence/Thither;
What/who/which -> Where/Whence/Whither;
Him/Her/Them -> There/Thence/Thither; etc.
Makes sense? No questions? Great!
Now pick your favorite preposition and stick it on the end. Don't forget to experiment with some archaic prepositions like "anighst", "overthwart", and -- here's a really good one -- "withinside". That one means "within / inside" and I'm sure you can already see the potential.
"What place should I go into?" Nope! "Whitherwithinside should I go?" Now we're talking.
>reversible computing's "gofrom" and "cometo".
wowza, oops, i mean, wow, sir.
you inspired me to respire more deeply.
from which comes an irreversible desire to learn, deeply, about deep learning.
That’s funny i read it as a dead pan joke Til
Yeah, agreed. It is dripping heavily with nerd.
This is beautiful.
cough I hereby propose two new language constructs and corresponding keywords, which can be applied (sounds more functional than implemented,) widely across many languages, at least procedural / imperative ones:
goto and comefrom
with optional synonyms:
leave to and return from
the above can be shortened to as little as two letters each:
go and co
le and re
for fans of succinctness / conciseness.
PRs are open.
> with optional synonyms
Leave I follow, but doesn't "return from" rightly describe a continuation as opposed to "come from" which is a nonlocal goto?
I stopped understanding continuations before I even started.
I can't quite tell if you're serious. Continuations are fun, so I'll post this on the off chance it helps someone.
They are perplexing until they aren't. Model stack frames as independent state. When you return from a function the stack frame can stick around. Now later, place your stack pointer back in the frame that you returned from earlier.
Add a convention for passing arguments when you update the stack pointer as above. Now you have continuations.
so you can place your stack pointer back in the frame that you returned from earlier? that's probably the point at which they stopped understanding continuations before even starting.
That’s the tricky part. There’s no stack anymore. Activation records of functions are heap-allocated and can stick around as long as necessary.
I was explaining the joke? Since the person I was replying to seemed to wonder if it was really a joke, whereas for me, structurally it was obviously a joke.
To be fair it's still a stack (the data structure). It just isn't contiguous in memory anymore.
Of course modern LLVM already breaks it up into chunks anyway (given certain flags at least) so it likely isn't contiguous regardless.
> Buttons ... provide the foundation of interactivity on the web.
This is a very neat way to sum up the difference between the 'old' and 'new' web. Because, of course, it's the hyperlink that provides the foundation of interactivity on the web.
I like that but I’m not so sure.
Hyperlinks aren’t interactive. They’re bookmarks. When I click on a link have I interacted with the page? In a sense I have. But have I changed its state? No. I’ve just moved from one static place to another static place.
Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course)
For example, sorting a table could be achieved by having the column headers be a link to the same url with ?sort_by={colname}
And then the server sees that and sorts and returns.
Same with "dynamic" number of input fields. When the add field link is clicked you reload with ?num_fields=2
> Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course)
Not if you want to be pedantic. At least, if you want to follow the rules, GET requests should never change visible state on the server.
So the interactivity would be limited to searching/filtering existing content, but you wouldn't be able to add new content.
For that, you'd need POST requests, i.e. buttons.
Cool comment, got me thinking a bit and I’d like clarity if you don’t mind.
Sorting in a GET request param doesn't alter the server's state. It only changes the data representation, not the underlying resources.
This fits "safe" method def (RFC 9110) https://www.rfc-editor.org/rfc/rfc9110.html#safe.methods
But I agree sorting feels like it’s doing “something”… which is where I got stuck thinking about this.
But are you saying that the client view state (example of the sorted data) should not be handled by the server via GET?
If that’s what your are thinking, I’d like to learn more on this rule.
Ah, sorry. No, I just left out sorting for brevity. Sorting the result of a query is a pure function of its parameters and the existing server state, so it would be perfectly valid to do server-side in a GET request.
But changing the "default" sort order of a resource (either by physically shuffling the rows on disk or by setting some server-side global variable) would not.
I think it's the difference between making a sorted copy of a list (while leaving the original list untouched) and inline-sorting the list.
Same applies to filtering.
Even storing the processed results in a cache does not validate idempotency, because from a client's POV, the behavior of the next request would be the same, whether the server calculates the result fresh or pulls it from the cache.
(Edit: Realized, I mixed up "idempotent" and "safe" methods there. I was talking about "safe" methods - but those are what applies to GET requests and what can be represented by a hyperlink)
GET requests always change state on the server because we have logs. Furthermore logs are often parsed by XMLparsers which are often error prone.
This is why idempotency is defined through visible state on the server. What happens on the server doesn't matter, but a GET request should not change the results of any subsequent future requests, as visible to the clients. E.g. adding or modifying a post or a blog entry via a GET request would break the rules.
(Nothing stops you in practice from ignoring that requirement, but it can lead to ugly surprises, such as a crawler triggering a mass deletion because it crawled the /delete links)
To me that feels like a technicality. It’s the same experience you’d get with a button + JS except with more latency.
> Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course)
No server processing needed: the page returned can be identical with an onload function that grabs the GET parameters and does the processing on the client to, for example, reorder the rows of a table.
Yeah but that was also implemented as a button, right? input type="submit" would display a button in 1993 AFAIK. No javascript and acted like a hyperlink - but still a button.
The most noticeable difference back then (before JS and before CSS) was that browsers displayed very visibly the destination of links, while input buttons were totally opaque. We created buttons with images inside an a href tag to make styled (in photoshop) buttons that behaved like links and generated a GET request. We could add a query string. The only way to make a POST request was a button inside a form.
The author probably mean hypermedias. Buttons and links are just means, but no interactivity even happens without the user clicking or moving their mouse.
Now we can of course talk about client-only interactivity (as in thick clients like paint apps) but that's not the topic.
Two exceptions could be: - url hash links and the css :target pseudo class. - Links that target iframes
Not suggesting to use these patterns liberally, but they do work for light interactivity.
those are just extra features that let hyperlinks behave like buttons though. Of course, this is under the strict definition that a "hyperlink" is a link between two web pages.
I am not sure if the author actually put any thought into the foundation of interactivity on the web, or if they just asked the AI to write a nice-sounding introduction to their article about new button capabilities.
Thanks for sharing
The idea of declarative UI actions without JS is appealing
The good:
* Killing boilerplate for popovers/modals (no more aria-expanded juggling).
* Built-in commands like show-modal bake accessibility into markup.
* Custom commands (e.g., --rotate-landscape) let components expose APIs via HTML.
My doubts:
* Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist?
* Shadow DOM friction: Needing JS to set .commandForElement across shadow roots feels like a half-solved problem.
* Future-proofing: If OpenUI adds 20+ commands (e.g., show-picker, toggle-details), will this bloat the platform with niche syntax?
> Is this just shifting complexity from JS to HTML?
Very well said. This is the problem.
There's an old adage that every "scripting" language starts out small, but then ultimately needs all the features of a full programming language. If we start putting programming features into HTML, we'll eventually turn it into a full turing-complete programming language, with loops, conditionals, variables, and function calls. We'll have recreated javascript, outside of javascript.
>> Is this just shifting complexity from JS to HTML?
> Very well said. This is the problem.
It is a problem. Counterintuitively, it is also a solution.
Lifting some complexity out of JS and into HTML solves some problems. Lifting all complexity out of JS and into HTML creates new problems.
For example, I have a custom web-component `<remote-fragment remote-src='...'>`. This "shifts" the complexity of client side includes from "needing a whole build-step with a JS framework" into directly writing a plain html file in notepad that can have client-side includes for headers, footers, etc.
This results in less overall complexity in the page as a whole.
Shifting the "for" loop and "if" conditionals from JS to HTML, OTOH, results in more overall complexity in the page as a whole.
CSS is now getting functions as well [0].
[0] https://news.ycombinator.com/item?id=43236126
Horrible. We're going to end up with three separate languages: CSS, HTML, and Javascript, which will each be turing-complete programming languages with completely-overlapping featuresets, and there will be no clear reason to use one over the other.
Browsers will have to implement support for three PL runtimes. Everything will be complicated and confused.
The sky isn't falling, and nearly everything is trending better, not worse. You can use whatever features of browsers that you want.
There are tradeoffs. Further increasing the barrier to entry for new web browsers benefits the entrenched players and hurts end users by yielding fewer alternatives.
The entrenched are the ones deciding the features. This is their goal
Developers can use whatever features they want, but users can only watch as their computer uses up more and more energy because it suddenly has to perform yet another build step that previously was done on the server.
That's what people say of C++ too. Too many features makes it harder to learn a language and ramp up on codebases; they'll have different standards on what they use.
Everything will be even more complicated and confused.
Is there DOOM in CSS already?
There's a Wolfenstein https://css-tricks.com/hacking-css-animation-state-and-playb...
Already a thing of past http://www.w3.org/Submission/1996/1/WD-jsss-960822 Netscape Communicator 4
JavaScript Style Sheets (JSSS) alternative to CSS, a "Programmable CSS"
Never got spotlight because stubborn people werent ready to let go of css
Maybe in ten years they will finally add enough languages to each one of these 3 languages to make them good enough to compete against Delphi.
Nah that's good. JS is way too powerful and 99% of pages don't need bloat like webrtc, navigator api or thousands of other points that are almost never used for good but for evil.
Html should be powerful enough on its own to provide basic web page functionality to majority of use cases and only then the user should give explicit permission for the server to rum unrestricted code.
It's not just shifting complexity. It improves locality of behavior (LoB). You can look at a <button> element and immediately know what it does (within the limited domain of "command"s). This is a dramatic improvement to readability.
My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there. Behavior of the page can be made visible! There's so much allure to me to hypermedia that's able to declare itself well.
This could radically enhance user agency, if users/extensions can rewire the page on the fly, without having to delve into the (bundled, minified) JS layers.
There's also a chance the just-merged (!) moveBefore() capability means that frameworks will recreate HTML elements less, which is a modern regression that has severely hampered extensions/user agency. https://github.com/whatwg/dom/pull/1307
> My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there.
I would love this. As a Tailwind user the last few years, it’s really been refreshing to have my styles both readable and inline on the elements instead of filed away in SCSS I’ll never see again. Even with scoped styles, some components get large enough that it feels unwieldy
That's why I rather keep HTML limited than embracing something like Svelt (which I haven't heard of before). Looking at it's inline syntax in the example, it is yet another something to learn. Yet another thing with peculiarities to keep track of, solving one kind of problem but introducing more complexity by spreading logic out (taking logic from one place and putting in another creates an additional relationship which is a relationship with that from which the logic was taken: Svelt and JS has to coexist and may for example overlap).
My favorite experience of shifting logic is writing a template engine in PHP. PHP is a template engine. I soon discovered I tried to replicate more and more PHP feestures, like control flow etc. I realize PHP did a way better job being a template engine. (This does not disqualify all use of said things, just that all seemingly good use cases aren't motivated, and may not turn out as expected.)
My prediction: In a few iterations this will have turned into an inferior reinvention of HTMX.
I believe the stated goal of HTMX's developer was to integrate the functionality of HTMX into HTML.
> Abstraction vs. magic: Is this just shifting complexity from JS to HTML? Frameworks already abstract state—how does this coexist?
The same way React or other frameworks can hook into things like CSS animations. If CSS animations didn't exist, the JS framework would have to write all the code themselves. With them existing, they can just set the properties and have it work.
Even if you're writing a basic menu popup directly in React, having these properties to use directly in your JSX means less code and less room for error.
Then if you need to do something special, you may need to do it by hand and not use these properties, just like if you needed a special animation you might have to do it without using the CSS animation properties.
agreed, my sense is that frameworks will update to take advantage as they've done in the past
I'm not a web dev, so I apologize if my questions are naive. Does this mean its a chrome-only thing or does it become a web standard? I ask because I would like to imagine the future isn't tied to Google's whims, graveyard of initiatives, and requirements.
It's already implemented in bleeding edge builds of Firefox and Safari, just behind a feature flag (as it also is in chrome)
https://caniuse.com/mdn-api_commandevent
That would be really nice, but, that’s been the way of it for the last few features too… it might not get adopted, but if enough people start using it…
My experience with anything declarative is that features are gradually bolted on until it eventually just becomes imperative (and ugly). For example HCL.
I believe declarative should stay purely declarative to describe data/documents in a static state (e.g. HTML, JSON) and an imperative “layer” can be used to generate or regenerate it, if needed.
Invokers are not just a Chrome thing for those wondering, it's already in Firefox nightly as well https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonE...
WebKit has taken a "support" position. https://github.com/WebKit/standards-positions/issues/264
The specifications
button element, commandfor armttribute: https://html.spec.whatwg.org/multipage/form-elements.html#at...
button element, command attribute: https://html.spec.whatwg.org/multipage/form-elements.html#at...
Is this really the action/messaging pattern that Next, Be and then Apple and probably others used about 30 years ago, or did I miss something here.
It was useful in a way but basically evolved into interface-based controller patterns due to the needed complexities and the whish to keep the basic underlying design pattern. So I'd expect to see lots of enhanvement requests once that box was opened :)
There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.
You thought web was 15 years behind, but it quickly catches up to 30 years old tech!
News like this make me feel sick. I thought it could become something usable in my lifetime, but I’m knee osteoarthritis years old and it still reinvents poor man’s target-action. Sad clownage.
What would have been something useful?
It’s not that the idea is brand new, just that it’s now implemented in chrome and in the web specs.
> the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.
Didn't these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions/attributes? Sometimes things like these make me wonder if the people in charge are conscious about that everything they are putting in will stay there forever. You can't just release an update and remove stuff you ("you" as in: the web devs at your company that happen to be in the same company that builds a browser) don't need any more.
I thought that was odd, too. It would have made more sense if they'd implemented this for media controls first, and then consolidated the popover attributes into it later. This feels like a record for fastest deprecation of a web feature ever.
2025:
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
2033:
> While HTML offers command and commandfor handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
I don't know if it's the way my brain works, or just an aesthetic thing, but I am completely allergic to programming with strings. Totally get the reasoning behind this, especially the accessibility wins, but I'm not particularly excited about using element IDs for yet another layer of web app behavior.
Stringy code is my go-to example of a code smell. You can do it, it works and yes, as long as you write it correctly it will work correctly, but you're just kicking the can down the road, at best.
HTML elements are naturally stringy and that makes sense -- when the HTML describes a document. But in the context of complex applications it leaves a lot to be desired. It's a hack.
This isn't to say the feature being discussed is a bad thing. It's obviously a hack. On such an established platform, there's suprisingly little room between 'throw it all out' and 'just one more patch'.
I agree, but at least it is consistent. This is also how `for`, `list`, `aria-labelledby`, `aria-describedby`, and probably many other attributes work.
I don't like it either, but at least we can pave over it with a framework, unless you're allergic to those. It makes a good building block.
True, and don't get me wrong, I think events are great and this will be a decent simplification, even with existing frameworks.
If it's Turing-complete, non-opinionated and doesn't use templates, I can put away the Epipen.
I know what you mean
My dyslexic self got excited for command and conquer in HTML
Just today I discovered there’s a Red Alert port to Three.js in the works: https://github.com/chongdashu/CnC_Red_Alert-ThreeJs
Me too. I was reading about buttons ... and wondering where was the game?
Although, the buttons are very interesting.
I definitely read about buttons waiting to see how this would unlock the ability to transpile Command and Conquer in some novel way.
Still appreciate the new features though.
Seems like they shouldn’t have implemented this without a full API. Instead the 5 or so commands, it looks like it’s possible to implement ALL JavaScript functionality through HTML, including high level APIs. That could be thousands of commands..
I don't see how it should be too hard to implement, you could abstractly have a system where the command string is translated as such:
1. Split the string by dashes into an array
2. Make the first character of the first array item lowercase, make the first character of the rest uppercase
3. Concatenate the pieces together
4. Do `document.getElementById(element.commandfor)[concatenated]()`
Obviously this doesn't have the myriad number of checks to make sure that the element exists, the method exists, the method takes no parameters, etc.
This would also allow custom commands easily, since you could do `document.getElementById(element.commandfor).myCustomMethod = function() { /* ... */ }`
Given that this is meant to be a safe alternative to inline JS, executing arbitrary JS would be counterproductive.
The real power is custom commands and a standard way to implement them. The built-in commands will always be just conveniences that many convert to a custom version as complexity increases.
Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.
This is my thought too, I'm having trouble envisioning a case where a reasonably complex UI wouldn't still need JS. I guess it provides a roadmap to incremental adoption.
It's good they are improving and extending HTML, but still a long way to go. The HTMX guys have a few good ideas.
No, it is terrible that "they" continue to extend and "improve" HTML.
This is the reason it seems impossible for an independent web browser to be created and maintained: because what should be a simple and predictable spec over the last twenty years is a rapidly moving target that takes significant resources just to track.
We could have ten different open-source web browsers (like Konqueror) if we weren't cramming the HTML spec full of bloat that nobody wants and that we all install extensions to disable anyway ...
I’m pretty sure this is the only goal. Everyone with a neuron or two can see that the internet doesn’t use web tech and abstracts it away as soon as possible. These people just grow their corporate security by adding nonsensical bullshit that makes zero difference irl.
> We could have ten different open-source web browsers
To what end?
Sane competition, developers and end users would benefit from competition. This is just corporate lock-in. When a user is required to install Chrome for using a web app we're failing him as a platform, and the open web goes off the rail
Having a browser written entirely (or mostly) in a memory safe language.
LadyBird is now using some Swift, but most of the code is still C++. The browser, while extremely impressive (and I’m very thankful it exists), has a ways to go before it’s a true replacement for Chromium/Blink, Firefox/Gecko or Safari/WebKit, and rewriting all the existing code in Swift would be a massive undertaking.
Chromium and Firefox also use some Rust, but re-writing those browsers entirely in it would be an even larger undertaking.
In contrast, a simpler browser spec would make it far easier to create a brand new browser in a memory safe language. Not only would this massively improve security on all operating systems as the browser is a huge vector for exploits, it’d also allow for the creation of new, more secure operating systems. Currently, arguably the biggest blocker for using something like RedoxOS (an OS written in Rust) is that it doesn’t have a web browser that can actually work for a lot of the web. But if the web browser spec were simpler, it’d be much easier to create one and then use that OS.
Obviously we can’t go back in time and make a simpler web-spec, and removing features is a terrible idea as it’d break existing websites. I do think, though, that it’s fair to think very hard before adding new features. I think a complete feature freeze would be overkill — some new features could legitimately make web development simpler and cleaner for many webdevs. I do think there needs to be some thought as to what the end-goal for web browsers is. Is there one? Or will we forever continue to add new features at the current pace? If so, the hopes of building a new, more secure browser are dim. And personally I’d prefer a more secure browser to one with more features.
As a comparison, C++ has been adding plenty of new features, but nearly no devs are aware of the full feature set, and despite the goal of making things simpler, I think many devs are as lost as ever with it, as they still have to interface with code written in old and different manners. On the web dev side, some JS and CSS features do legitimately simplify development and make things easier, but I think it’s fair to say that’s not the case for all new features added.
So basic click events without JS.
Seems to only work with popups?
Maybe a push for Google Ads on that super tiny bit of ad market who don't use JS
Between this and other changes I worry they are just throwing more and more stuff at the wall to widen their browser moat.
Is command and commandfor actually a good idea? I understand the point of it, but it seems like yet another layer of cognitive load.
Instead why not just apply the same principle to CSS? If I could make a CSS selector for one element but have the result target other elements, then one could achieve the same results and more. It would require only a few more pseudo-selectors. And while it probably isn’t necessary, I think it might be prudent to mark the properties that undergo state changes. Something like:
Where `|>` retargets and the `=` indicates the property can undergo state changes. (Maybe the syntax could be better, but you get the idea.)I do not understand why they did it now when JavaScript already does it. The thing just adds entropy without a clear value.
I'm wondering if these new html features will eventually get traction, anyone knows how's the usage of latest popover and dialog elements? I'm asking because I always wondered who would ever use them as JavaScript based dialogs are so ubiquitous and they can't easily be content blocked vs querySelectorAll("dialog") and disable them. For the sake of being semantic? But who really would write a semantic web anymore? Maybe for AI Agents? Why keep bloating the web platform?
I don't know who else is doing it but my team and I always use semantic HTML, including dialog elements
It is, unfortunately, the least I can do to respect the user, since I have no control over the decision to load horrible tracking scripts onto their browser.
I really wish everyone would use semantic HTML wherever possible. The gains for accessibility are huge.
Take a JS dialog or pop-up menu, for example. You would think it would be easy for everyone to use, but a screen reader user might not even be aware that it’s there in the first place. Even when they do, they still need to find it in a linear and possibly very cluttered representation of the page. It could be right next to the "open menu" button, at the bottom of the page, or somewhere else entirely. The menu/dialog could also disappear as soon as they move the focus in an attempt to find it!
These are all things I put up with regularly.
I think anything that makes accessibility easier for developers is a good thing, especially if it just works without having to think about accessibility.
Google being Google, they may do it just for the sake of squeezing revenue from less likely blockable ad popups.
This explains why they decided to work on HTML dialogs out of the blue. In their mind, dialog is popup, and an ad popup that you cannot block equals more money for them.
Probably they are creating an area in specification for them to exploit in the future. In a twisted way of course, via extension manifest V4 or something like that.
I think you're confusing some stuff. A native dialog element as a popup is easier to block, for example, you just have to select all dialog elements by tag name and convert them to div inlined elements or something like that. Can't do the same reliably when the dialog is created by a javascript library using a div that uses a random id or generated class name
One more case of Fire and Motion[0] in the industry.
[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Oh, this seems like a nice generalization of the popover specific attributes. Could replace <button type="submit"> with <button command="submit"> and default commandfor to the ancestor form.
interesting, they could finally deprecate the form attribute on buttons...
Oh, it's coming back!
Called for it: https://news.ycombinator.com/item?id=40888664
We need a proper rich UI application execution environment, and if HTML, being a primarily document oriented platform can’t be retrofitted to provide that, then we need a new one
Ian Hickson, who authored the HTML5 spec and leads Flutter, has written about exactly this, Towards a Modern Web Stack [0][1], to create a new stack that can handle modern web applications. Flutter is a part of it but he talks about a more general (and generalizable) stack. He's on the HN thread as well expanding on the rationale behind it. Interestingly, it seems like specific people on HN don't exactly like it, a bit funny to witness their crash outs.
[0] https://news.ycombinator.com/item?id=34612696
[1] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... (actual doc to read)
I have gone through Hickson's proposal, interesting.
I notice though that he is proposing to address the problem from the opposite direction to mine, though I think his approach is also viable. I dream of an HTML-like platform built to support rich UI apps, with much higher-level configurable primitives that eliminate the need for massive amounts of scripting and dependencies. He talks about providing properly configurable low-level primitives.
Both approaches can work if built properly to support what developers actually want to do. One thing that put me off WASM was the dependence on JS to bootstrap it. I just did not want to have JS in pipeline again whatsoever if I was taking that approach. The advantage of high-lvel primitives is that there will be much more of what developers want to build that is already built into the platform.
Have you tried Flutter? It works well although web performance leaves some to be desired.
+1. The Web Platform is this interesting blend between declarative and imperative, but with the benefits of neither.
IMO, the web platform needs a retained mode UI model like Qt Widgets, AppKit, or UIKit. Then desktop-like applications like Figma wouldn't need to compile to WASM and render WebGL for their UI. They could just treat <divs> as views or layers.
Flash? Silverlight? Swing?
I see you are skeptical, but the failure of those technologies does not mean a new HTML-like platform cannot succeed.
We've learned a lot about security, DX, and UX since those times. A new platform can apply all those.
Joey Hess had this suggestion recently - https://news.ycombinator.com/item?id=43202773
I'm curious, as a noob in web programming. That first example does
Instead of And in fact, all the framework example show button onClick not document onClickI know some situations where adding the event listener to the document is correct but I've never seen it in this button type situation.
Is that pattern for buttons common? What does it solve?
Using document.addEventListener means it will work even if the DOM is updated without having to add new event listeners. If I'm not expecting the DOM to change I would be more inclined to do something like:
The React example seems a little odd as well, if the "open" callback actually called "showPopover()" instead of only calling "setIsOpen" then the "useEffect" could be entirely redundant. The resulting code would be a lot clearer imo.> it will work even if the DOM is updated without having to add new event listeners
Nailed it.
And the sibling comment got at it but the "magic phrase" to Google for this technique is "event delegation." Two more phrases: delegation relies on "event bubbling," bubbling can be interrupted with "event capturing." (You will rarely want to capture events, it's JS's `!important` equivalent)
One decent overview: https://javascript.info/bubbling-and-capturing
Generally you do it the "document" way (often called a "delegated" listener) when you have lots of elements you want to listen to, or particularly elements that will be dynamically added and removed.
If you listen directly to every target element, you have to find the elements and loop through them all, they have to exist at the time you set the listener, and you have to make sure to add the listener every time you add a new element that has the same behavior. If you listen at the document (or some appropriate parent element) and then check if the element that fired the event matches what you're trying to handle, you can have one listener that will apply to all the matching children regardless of where/when/how they're added.
It is a common pattern on the web indeed, and it's called "event delegation" if you want to search more about it! As others said, allows binding an event handler once, so it can just sit there and wait to be triggered regardless of how much the actual page content changes due to user interactions (rather than a new event handler being bound every time a new button or interactable element is created).
This is basically HTMX. Why don't they just integrate it natively into the browser?
<style> #my-popover { display: none; border: 1px solid black; padding: 10px; margin-top: 10px; } #toggle:checked + #my-popover { display: block; } </style> <body>
<label for="toggle" id="my-button">Toggle Popover</label> <input type="checkbox" id="toggle" style="display: none;"> <div id="my-popover">My content!</div>
</body> Wont this work a toggle popup with html+css only no js yet interactive with label
This hack has terrible accessibility. For one, the <label> is not focusable by default, so keyboard users won't be able to toggle the popup at all. And I don't think it's possible to dynamically set ARIA attributes without JS.
Since it's all about buttons, it's a shame they missed the opportunity to call it butfor.
Sigh. Fine, I'll do it.
What's a butfor?
This will be great!
I was just working on an app where this exact pattern would have been useful. The app mixes serverside html with some sprinkles of React for a checkout flow. Command and commandfor would have made the linking of the two much nicer. Apps following the islands pattern will also benefit from this feature.
Sidenote: I think the web's biggest problem in the future will be how hard it is to deprecate functionality.
Maybe we need Html6 to be about removing/simplifying features from the browsers?
I've misread this excitedly as "Command and Conquer" for HTML thinking it had to do with the recently released source code.
>the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.
At first I was worried because they just added the popover API recently, which itself replaced <dialog>, but this is still using the same API, just calling it from HTML differently. Still, I'm not fully clear on what the long term goal here is? Replacing UI toolkits? Simplifying state frameworks by removing js from certain functions? For example, the play/pause functionality.[0] For a simple website, you don't need to add any such functionality because browsers have built in video players that allow you to play, pause, mute etc. So this isn't necessary for simple websites. But then for websites that are more complex, you would already be using js presumably?
I do mostly like what is written here about the project in general, which seems to answer the above question:
>But another 15 years have gone by since the last major revision to form and UI interfaces. Most complex web projects today need far more than what HTML5 form and UI controls provide. And so, all-too-often today’s web developers turn to heavy JavaScript frameworks to build the user interfaces their designers are asking for. These custom interfaces are rarely fully accessible. They slow down the page, consume power, open security vulnerabilities and exclude people.
>Additionally, today’s projects often reject existing built-in form and UI controls because they require more agency over the look and feel of the interface. Web designers demand the ability to express their project’s branding across every element on the page, including all user interfaces. Current form and website-level UI controls do not allow for this.[1]
So the goal is to remove JS from UI components for UIs that already exist natively in HTML. Still, at least for the above video example, some sites want different behavior when the user taps on the screen. Some will bring up the video playback bar and settings, others will immediately pause, others will pause if the playback bar is hidden and remove the bar if visible, etc. I don't see how you can do that without JS, at which point el.playing = false seems much better than using a button command attribute. Or is this just a bad example?
[0] linked in the article: https://open-ui.org/components/future-invokers.explainer/
[1] https://open-ui.org/charter/
The popover API is not a replacement for <dialog>. It's an alternative to some dialog like functionality if the use case is right.
A popover and <dialog> are totally different things. Also, no body replaced or deprecated <dialog>
I am waiting for the author of HTMX's opinion on it. They dont seems to have commented here yet.
Interestingly the examples don’t show interaction with <form>. In the deletion confirm example, can I put this inside a form and have it continue to POST when confirmed and cancelled when cancel is hit in the popover?
If I still need js to then submit the form it feels like this falls quite a bit short.
Someone was just telling me that Google doesn't have significant influence on web standards.
Would make interaction easier for ai agents on the web.
And screen readers.
HTML needs a <button type="revolt"/> to counteract the <button type="submit"/>.
The author is not affiliated with Google. Is this from "external" contributors? If such a thing called open-source is still happening here, I would send all of my respect to you the people who do it for the Web.
Author here. I am not affiliated with Google. My current employer is GitHub, and this was incubated in the OpenUI working group. Open source & the open Web are still very much alive!
That looks like more XSS vectors.
Also what do I do if I want to fire analytics even and open the modal. Correct, use onClick.
> That looks like more XSS vectors.
Could you elaborate on that? I don't understand how this leads to more XSS vectors.
If these are proposals to use bindings between html attributes and calling JS methods, then it's enough to inject HTML, not JS, to start executing JS.
It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).
HTML seems to incubate some htmx things
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
What is to prevent command and commandfor from being included in future CSP rules for the same reason onClick is?
The reason onclick is disallowed is because it permits full JavaScript execution. An onlick attribute is ‘eval’d on click. If you can inject one into a page you get JavaScript execution. Hence, content security blocking - a rule served up on the page saying ‘nothing in this page is supposed to have onclick attributes. If you see one ignore it’.
These command attributes are not arbitrary JavaScript hooks. They tell inbuilt components to do inbuilt things. It doesn’t make sense for a content security policy to say ‘nothing on this page has commands, if you see something that does ignore it’, any more than it would make sense for a content security policy to say ‘nothing in this page is in bold, if you see something that says it wants to be displayed in bold ignore it’.
This makes sense, but it feels like the case is overstated... Is it really common for sites to disable their own onclick attributes? Is it just the case that the CSP rule disables onclick in the HTML, but first party scripts can then attach event handlers separately?
If you’re dynamically generating the HTML it’s safest to set the CSP to disable all inline scripts; you can permit only static scripts served from known good locations with valid sub resource integrity hashes.
Is it common that the HTML gets injected but inline scripts can not be injected at the same time?
wait, when did we get “dialog” and “popover” tags? these are wholly unfamiliar to me
also I sort of expected this feature to interact with CSS somehow, you could implement a lot of behavior by just adding and removing styles
<dialog>
Chrome 37, Aug 2014 Safari 15.4, Mar 2022
popover attribute
Chrome 114, May 2023 Safari 17, Sep 2023
Don't forget Firefox... There are some people that keeps trying to support anything that isn't f* controlled by Google or Apple.
Dialog in Firefox 98 , 2022-03-08 Also, using a poly fill works even on IE 12
popover in Firefox 125, 2024-04-16
everyone is crediting intercal but
https://en.wikipedia.org/wiki/Comefrom
speaks to the history and rightly credits larry clark
Very good innovation - to eliminate all standard boilerplate javascript and code it into the HTML in declarative manner.
Less javascript the better, plus it allows to impute dynamic behavior from HTML tags, without parsing JS code
it looks clean, now.
web devs will get ahold of this and demand that they have the ability to change the size, the animations of appearance and disappearance, specify a sound that plays when the menu is opened or closed, etc. I'm saying that this, like all other web things, will be bastardized and mutilated until it is just as complex and unworkable as the existing solutions which this is intended to replace.
I am fine if structural stuff can be coded in HTML, while animations and bells and whistles will still have to be JS/CSS based
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
WTF. Is this for real? This attribute has been around for decades. It used to be the only way to handle events. Can't believe what I'm reading here. All frameworks use a similar construct. What is the actual problem with onclick attribute?
> What is the actual problem with onclick attribute?
It's a string, so it's basically eval(), and eval gets disabled for all kinds of legit reasons. It often gets disabled along with inline script tags, which shuts down a whole class of XSS attacks -- which maybe your code isn't vulnerable to, but who knows what some random third party markdown renderer might enable?
The alternative to on* attributes is addEventListener, which has also been a thing for decades.
Thank you for highlighting the difference between onClick and addEventListener - my frontend skills are rusty and I'd forgotten how prevalent the equivalent of eval(some_string) is.
Wow. This is just silly. The issue is executing untrusted JavaScript... Why would the developer put untrusted Javascript inside the onclick handler? If writing vanilla JS, this would basically never happen. The use of onclick is ridiculously widespread too and it's very rarely misused.
With that kind of logic, why not disable fetch() calls and all other calls to any backend service? You know, the backend might respond with some untrusted user input which might end up executed as a script (e.g. in a template or something, some frameworks use eval or a dynamic Function)... We need to protect the developer from that risk... All webpages should be static web pages; no untrusted remote data!
I mean these arguments don't quite make sense. You can't remove useful functionality which could potentially be misused under the pretext of adding security. By the time you remove all such features, there will be no features left to use at all! You will end up with a very secure brick which does nothing.
If you can get over your sputtering moral outrage, you might try looking up things like XSS attacks and how Content-Security-Policy can mitigate it. XSS can have vectors that are more subtle than just raw-echoing back an input field, and CSP is a set of guard rails that can mitigate any potential damage it can do.
Well I guess it can serve some corporate use cases were most people don't have the skills to identify issues and prefer to have a policy to just blanket ban all.
It's a habit in certain large companies to just ban any tool which might potentially be misused.
I see the utility but it's disappointing. I hope they don't force it on everyone because the risk vs solution tradeoff is not relevant to most entities who use it.
>> show-popover: Maps to el.showPopover().
I'm surprised they're still keeping this convention of kabob-to-camelCase function name transcribing. I've never been a fan.
I’d much prefer el[‘show-popover’]()
Is there an RFC for this?
Start here I think:
https://github.com/WebKit/standards-positions/issues/264
The direction of web standards is problematic. Getting overengineered. CSP is retarded. Trying to prevent all possible security vulnerabilities by removing functionality is just dumb and an impossible task. It's just converting a simple vulnerability into a complex vulnerability. Things are headed in a bad direction. Throwing the baby out with the bathwater... To remove all possible vulnerabilities means removing all possible features. Web programming will become a useless bureaucratic mess if we continue down this path.
more builtin behavior, less JS to ship. pretty dope
I like how they present it as a novel idea, when this is as old as it gets. This is not new of course but it seems it won´t stop. Ever.
Browsers: We are not happy that only Tailwind will pollute HTML. We want our part of cake too.
when are you guys at chrome planning to add a virtual scroller or virtual list or virtual table. pretty sure every infinite scrolling pattern out there could use a component like this
am I the only one annoyed by the fact that they do not have syntax highlighting on most of their code examples?
It's been some years since I coded any front-end HTML. Sure looks like it's gotten messy.
I'd gladly give up this if I could get ublock origin and other pre v3 extensions back
Random aside. Their code snippet has this comment:
And I hadn't heard of that phrase before! Turns out it means "clicking elsewhere closes the thing:"> "Light dismiss" means that clicking outside of a popover whose `popover` attribute is in the auto state will close the popover.[0]
Like what, say, a `<select>` does when open.
Strikes this dev as a pretty unintuitive way to phrase that. At first I thought it was "light" as in "light DOM," but I guess it's "light" as an antonym of "explicit?" Looks like there was some back and forth on this, and it was even proposed as an attribute: https://github.com/openui/open-ui/issues/834
[0] https://html.spec.whatwg.org/multipage/popover.html#popover-...
I think "light" is used as in "light touch" (soft touch), something that includes brushing against a surface by accident.
I’d guess it stands for highlight. For example a modal is often highlighted by dimming and blurring the background.
Also random aside. I dislike this pattern for modal dialogs. Often times I will need to gather information from somewhere else, and in the process of attempting to get focus back to the dialog I've touched/tapped/clicked on something that dismisses the dialog. Very annoying.
I'm okay with modal dialogs working that way as long as people get the message: dialogs are supposed to be ephemeral. If closing the dialog loses important state, or you need information from something under the dialog in order to use the dialog, what you have shouldn't be a modal dialog. And you can tell, because in most UI frameworks that widget is just begging to be closed. Unfortunately, a lot of teams don't get the message.
Just noticed this bug in Simplifi expense tracking web app. The drop down to update the category of a transaction has multiple levels (e.g. Business:Travel:Lodging) and as soon as I hover over a nested drop down the whole thing disappears.
Most of the times that would be better solved with not using a modal.
Light is the opposite of hard (ie hard close). It makes more sense (to me!) to use explicit vs implicit close? Clicking outside the popover means an implicit close.
Anecdotally, when I read the first two lines of your comment I immediately thought "that probably means you can click elsewhere to close it"
It’s just like the target / selector pattern from NeXT AppKit over thirty years ago… Except that the syntax is clunkier and less type-safe than what they did using 1994 Objective-C.
It’s not exaggeration to say that the web has set UIs back by decades.
The other day I was trying to make editable table cells in a leading “enterprise-grade” React component framework. It required several screenfuls of obscure and brittle code. The same operation used to require implementing a single delegate method in 1990s AppKit.
I find it remarkable that despite the massive improvements to CSS and JS in the last 15-ish years, additions to HTML are glacial. I mean we only just got popovers for christ's sake.
It's like JS and CSS are fully on board with being an app platform and HTML is digging its heels in insisting that everything be a document. There is maybe something to be said for that argument, but if I'm gonna have to interact with web apps I'd rather the list of stuff every developer needs to hand-roll in varying-quality JS be a lot smaller than it currently is.
I think that the root of the problem here is that, just like the acronym says, HTML really is, at its core, just a markup language for writing hypertext documents.
Using it as a domain specific language for user interface layout is a horrible kludge that only continues to exist because natural selection doesn't give a damn about sensible design.
Absolutely.
What's mindboggling to me is that when HTML5 came out people were swearing Flash (and Java applets) would be obsolete. Years later the replacement has been the most horrid spaghetti imaginable because no matter what framework or engine you use, it's going to become HTML+JS!
They should just start supporting Java in the browser again. Java. Javascript. Nobody is even going to notice.
I always thought it would be neat if python had been used instead of JavaScript.
I have written web apps in c++ (wt framework) and it’s really neat to be able to leverage c/c++ libs we already had, which was what tipped the scales in choosing it.
No it’s not the bees knees, but I can be productive, and new folks can jump on board and also be productive, very quickly.
I love python, but I don't think Python is the solution to Javascript. I mean, Python is much better than Javascript, but Python's type hints are much worse than Typescript. A modern language needs to be something like Java, but with null types.
What actually needs to happen is for wasm to get good enough that everything else is just implemented on top of it. Not that it'll save us from the flame wars over which language is better to compile to wasm, but at least you could actually pick your poison then...
I think it's good that HTML serves a narrow purpose. What's problematic is that we want every other purpose to be served by just one or two things (CSS, JS). It shouldn't be a struggle to differentiate between "script that makes buttons work" and "script that browses cat videos and downloads them to your hard drive". We can call it "minJS" and "maxJS" or something, and make it so users can disable "maxJS" without disabling "minJS". Or wait, why even mandate JS at that point? The biggest problem with the Web is not particular design decisions (although of course they have many problems), but the fact that we won't change them fundamentally and instead just keep piling things on.
My sense is that JS and CSS have an easier time with building gracefully degraded experiences than HTML might. On top of that, changes to HTML either have to be isolated (no accompanying changes to JS in the browser), or they have to be coordinated with the updates to JS.
> It’s not exaggeration to say that the web has set UIs back by decades.
The trade-offs for the UI setback are unbeatable cross-platform compatibility, ease of distribution and a decent security model with sandboxing. MacOS only introduced desktop app sandboxing in the last 10 years, most desktop run software with user permissions which is not great.
> It required several screenfuls of obscure and brittle code
I can't imagine this would be that complicated in vanilla js. Maybe just make a web component and use it in React.
> The same operation used to require implementing a single delegate method in 1990s AppKit.
I find that hard to believe.
And not to "uhm, ackshually" you, but what you're describing is possible via the native HTML "contenteditable" property.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
(Actually doing something useful with edits is another story, but that's not what the comment is about)
contenteditable is incredibly painful to use, not standardized and different across browsers, and buggy in firefox
Sure, though the question was about "making a table cell editable" requiring pages of obscure code.
_Technically_, it requires a single HTML attribute.
If you want to build some sort of reactive, spreadsheet-like experience with cells and calculations, then yeah there's some inherent complexity in that.
> It’s not exaggeration to say that the web has set UIs back by decades.
These claims always seem to break down once you ask for concrete examples.
1. The React/JS code is far simpler and less clunky than the Objective-C equivalent.
2. The HTML commandfor/command is declarative and simple unlike Objective-C target/selector
Paste the HTML commandfor snippet from TFA and ask an LLM what the Objective-C equivalent. If you think it's less clunky, go ahead and paste it here for us to judge. ;)
> It required several screenfuls of obscure and brittle code.
Yet still better than the brittle, obscure horrors of the procedural Objective-C Cocoa apps I used to have to work on.
"1.1. The React/JS code is far simpler and less clunky than the Objective-C equivalent.
Hard disagree - in objective C, I never had to worry about making sure I (and every library I use) calls hooks in the exact same order on every single render, for example. It does this for 'brittle" reasons - it associates state with the order of hooks.
(For any react folks - this isn't meant as judgement as much as an explanation :P)
Since i'm semi-retired, and only do this for fun, i spent a a week last month chasing down react hook usage bugs in libraries my app depended on and sending patches. I think i got up to 23. Because the ecosystem in javascript is so deep on dependencies, you often depend on an amazing amount of people getting everything correct. This was much less true in Obj-C as well.
Some of them had also made 'the error go away' by moving code to useCallback's inside setTimeouts so they wouldn't be noticed by the hook checker (but this in turn has no guarantee of ordering wrt to react effects, of course), leading to even more subtle bugs.
I won't even get into things like async in react vs objective-C (though to be fair, bad integration with async afflicts a lot of popular JS frameworks)
In the end: React is fine once you learn it. Obj-C is fine once you learn it.
But acting like react is not clunky or brittle is, and obj-c is, is definitely a stretch.
All of the things here are clunky and brittle, just in different ways :)
> set UIs back
Oh that's why 90% of online interactions are now on the web now ... stupid me thinking because it's a superior solution.
And before you say '90% are actually on mobile', well mobile doesn't use shit from 1994 also. Wonder why.
>stupid me thinking because it's a superior solution.
You think your snarky sarcasm fits, but it really doesn't. "Oh, everyone uses it, so it must not actually be bad?" That's not a good argument at all. :D
The main feature of the web is ubiquity. Doing a native app requires installation, update handling, etc.
That’s why the “web won.” But, when it comes to UIs, it is not technically superior.
The most popular technology is usually not exceptional in every aspect but is the most convenient for popular use cases. For example, LISP predates C by decades. Technically, C is inferior in abstraction, but ATT used it for Unix, quickly becoming the de facto standard for systems programming. That makes C a better option than LISP, only because you’ll need to go into extra layers of complexity to do a system call designed for C. For the web, you can only use HTML/CSS/JS (even with WASM).
“Mobile doesn’t use shit from 1994”… well all the iOS apps are based on Next frameworks created in the 80s.
You probably have never used a native UI framework or tried to create an accessible component library for the web, to say something like that. Try to create an accessible select component that shows an icon in its options using a native framework and HTML, and you’ll quickly see what I mean.
Please don't be creating select components. The native one is just fine and works 100% of the time. For those of us using translation tools and trying to navigate the shit designers came up with because they want to make it "pretty" is just ... annoying and full of grief. Just say no.
The web is the best application distribution mechanism the world has ever seen. Even though things have improved enormously in the last decade and a half, the ceiling is still miles below native (though the floor is far more accessible). None of that matters though, because all someone needs to do to get your app in front of their eyeballs is type a URL.
Mobile absolutely uses “shit from 1994”.
The UI framework in iOS is a direct descendant of the NeXT one I’m talking about.
Yep. All of the main 5 operating systems for consumers are from the late 80s and early 90s.
- Windows 11 is Windows NT
- macOS is NeXTSTEP/OPENSTEP
- Linux is a free Unix like from the era where that was a new thing with both BSD and GNU working on it
- Android is Linux + Java (inspired by OpenStep)
- iOS/iPadOS is NeXTSTEP/OPENSTEP for phones.
(OPENSTEP is an OS. OpenStep is a framework)
Is that a proprietary HTML extension?
Are we back to the IE-era mess then?
If so, let's bring <marquee> back.
Doesn't appear to be.
https://github.com/whatwg/html/pull/9841
https://github.com/whatwg/html/issues/9625
Seems to have been in the works since 2023, out in the open, with support from all major browser engines.
>Is that a proprietary HTML extension?
No, of course not. Web standards are whatever google decides they are.
TFA links to the spec - https://html.spec.whatwg.org/multipage/form-elements.html#at...
It's in Firefox and Safari
Have you been following how HTML has evolved over the past 20 years? Your comment suggests not.
It’s not entirely a standards-driven process. It’s common for browser vendors to just build stuff. That’s been a mixed blessing but it has definitely been faster than some W3C consortium debating “ergonomics” for years.
Successful additions get backported into the spec, slowly.
Marquee still works, we just don't tell marketing.
https://caniuse.com/mdn-html_elements_marquee
Chrome is the new IE. Whatever google decides will become a standard (both defacto due to them controlling the market and just shipping new version just in time and de-jure due to them financing W3C consortium and other standard bodies)
Man, that brought back memories.
Next thing we’ll get DOM events beforecommand and aftercommand. /s
In principle this declarative approach goes in the right direction, but without an overarching concept and vision of the web UI of the future, this feels like adding just another wrinkle to the stack.
[dead]
[dead]