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.

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

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.

they make it cumbersome to use by hand, but not impossible

But not too polite. The compiler wouldn't like that.

https://en.m.wikipedia.org/wiki/Boo_(programming_language)

Of course, COMEFROM's grown up (and very real) sibling is ALTER GOTO in COBOL.

- 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.)

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.

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

But still, so long as it’s a script in Unicode, it should all work fine.

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.

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.

Leave I follow, but doesn't "return from" rightly describe a continuation as opposed to "come from" which is a nonlocal goto?

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?

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.

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.)

[0] https://news.ycombinator.com/item?id=43236126

Browsers will have to implement support for three PL runtimes. Everything will be complicated and confused.

JavaScript Style Sheets (JSSS) alternative to CSS, a "Programmable CSS"

Never got spotlight because stubborn people werent ready to let go of css

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.

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

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.

https://caniuse.com/mdn-api_commandevent

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...

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.

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.

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.

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'.

If it's Turing-complete, non-opinionated and doesn't use templates, I can put away the Epipen.

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() { /* ... */ }`

Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.

Although, the buttons are very interesting.

Still appreciate the new features though.

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 ...

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

[0] https://news.ycombinator.com/item?id=34612696

[1] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... (actual doc to read)

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.

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 as views or layers.

We've learned a lot about security, DX, and UX since those times. A new platform can apply all those.

What's a butfor?

[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

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

    document.addEventListener('click', ...

    someButton.addEventListener('click', ...

I 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?

  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');
      }
    });
  });

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.

At first I was worried because they just added the popover API recently, which itself replaced

https://en.wikipedia.org/wiki/Comefrom

speaks to the history and rightly credits larry clark

Called for it: https://news.ycombinator.com/item?id=40888664

Also what do I do if I want to fire analytics even and open the modal. Correct, use onClick.

Could you elaborate on that? I don't understand how this leads to more XSS vectors.

What is to prevent command and commandfor from being included in future CSP rules for the same reason onClick is?

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’.

I'm surprised they're still keeping this convention of kabob-to-camelCase function name transcribing. I've never been a fan.

Less javascript the better, plus it allows to impute dynamic behavior from HTML tags, without parsing JS code

https://github.com/WebKit/standards-positions/issues/264

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?

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.

    // popovers have light dismiss which influences our state

> "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 `` 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-...

reply

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.

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.

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 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.

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.

I can't imagine this would be that complicated in vanilla js. Maybe just make a web component and use it in React.

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)

_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.

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.

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

- 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)

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 :)

  > The React/JS code is far simpler and less clunky than the Objective-C equivalent.

Are we back to the IE-era mess then?

If so, let's bring back.

reply

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.

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.

No, of course not. Web standards are whatever google decides they are.

It's in Firefox and Safari

https://caniuse.com/mdn-html_elements_marquee

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.