[HN Gopher] Introducing command And commandfor In HTML
___________________________________________________________________
Introducing command And commandfor In HTML
Author : Kerrick
Score : 408 points
Date : 2025-03-07 17:24 UTC (1 days ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| alterom wrote:
| Is that a proprietary HTML extension?
|
| Are we back to the IE-era mess then?
|
| If so, let's bring <marquee> back.
| Frederation wrote:
| Man, that brought back memories.
| finnthehuman wrote:
| >Is that a proprietary HTML extension?
|
| No, of course not. Web standards are whatever google decides
| they are.
| shermantanktop wrote:
| 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.
| jdiff wrote:
| 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.
| anamexis wrote:
| TFA links to the spec -
| https://html.spec.whatwg.org/multipage/form-elements.html#at...
|
| It's in Firefox and Safari
| hennell wrote:
| Marquee still works, we just don't tell marketing.
|
| https://caniuse.com/mdn-html_elements_marquee
| slt2021 wrote:
| 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)
| ykrishnan wrote:
| Is there an RFC for this?
| teh_klev wrote:
| Start here I think:
|
| https://github.com/WebKit/standards-positions/issues/264
| jt2190 wrote:
| 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...
| msub2 wrote:
| 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...
| Kerrick wrote:
| WebKit has taken a "support" position.
| https://github.com/WebKit/standards-positions/issues/264
| QuadmasterXLII wrote:
| 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
| alterom wrote:
| _> hopefully this leads to a surge in polite programming_
|
| But not _too_ polite. The compiler wouldn 't like that.
| SAI_Peregrinus wrote:
| Of course not. Sycophantic code is quite grating.
| fuzztester wrote:
| what's the download site for the _psycho_ - _fan_ tic
| language? gimme! puhleeze.
| esafak wrote:
| _Demure_ is the fashion these days, I 'm told.
| mock-possum wrote:
| Very.
| BobbyTables2 wrote:
| Spoken like a bussin' sigma that eats - no cap.
| krapp wrote:
| Word to your mother.
| fuzztester wrote:
| Well, at least the Boo compiler would not.
|
| https://en.m.wikipedia.org/wiki/Boo_(programming_language)
| DonHopkins wrote:
| Not to mention reversible computing's "gofrom" and "cometo".
| toomim wrote:
| comehither
| edoceo wrote:
| FromYonder
| yellowapple wrote:
| whence
| fuzztester wrote:
| > _reversible_ computing 's "go _from_ " and " _come_ to".
|
| _wow_ za, _oop_ s, i mean, _wow_ , sir.
|
| you in _spire_ d me to re _spire_ more _deep_ ly.
|
| _from_ which _come_ s an ir _reversible_ desire to _learn_ ,
| _deep_ ly, about _deep learning_.
| mindcrime wrote:
| My new language is going to include _thataway_ , _overyonder_
| and _uptown_ constructs.
| DonHopkins wrote:
| 2 the !!boogie, say(^jump the boogie)
| vonunov wrote:
| for (let i = 1; i <= 4; i++) {
| woman.getOn(floor); try {
| getDown(); } catch (e) { if (e
| instanceof NotUpError) { getUp();
| getDown(); } } }
| chrismorgan wrote:
| Given that "come to" means "regain consciousness", this pair
| sounds like it should be about thread sleep control.
| jayd16 wrote:
| 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.
| gmueckl wrote:
| 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.
| Voultapher wrote:
| So I tracked down this programming manual for intercal
| https://3e8.org/pub/intercal.pdf and can't locate any
| mention to comefrom.
| mannykannot wrote:
| 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/do
| cs/...
| eyelidlessness wrote:
| 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.)
| bunderbunder wrote:
| 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.
| stonogo wrote:
| Perl has supported comefrom for decades!
| https://metacpan.org/pod/Acme::ComeFrom
| fuzztester wrote:
| 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
| chuckadams wrote:
| 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.
| shakna wrote:
| 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.
| fuzztester wrote:
| 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_numb
| er_...
|
| 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?
| chrismorgan wrote:
| 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.
| fuzztester wrote:
| _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.
| fc417fc802 wrote:
| > 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?
| fuzztester wrote:
| I stopped understanding continuations before I even
| started.
| fc417fc802 wrote:
| 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.
| bryanrasmussen wrote:
| 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.
| cyco130 wrote:
| 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.
| fc417fc802 wrote:
| 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.
| zaphirplane wrote:
| That's funny i read it as a dead pan joke Til
| ncr100 wrote:
| Yeah, agreed. It is dripping heavily with nerd.
| harrison_clarke wrote:
| 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
| weeksie wrote:
| This is beautiful.
| Thorrez wrote:
| 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.
| btown wrote:
| 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/
| darth_avocado wrote:
| My dyslexic self got excited for command and conquer in HTML
| netghost wrote:
| 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.
| k6hkUZtLUM wrote:
| Me too. I was reading about buttons ... and wondering where was
| the game?
|
| Although, the buttons are very interesting.
| DeathRay2K wrote:
| Just today I discovered there's a Red Alert port to Three.js in
| the works: https://github.com/chongdashu/CnC_Red_Alert-ThreeJs
| TIPSIO wrote:
| 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
| error9348 wrote:
| Would make interaction easier for ai agents on the web.
| badc0ffee wrote:
| And screen readers.
| vFunct wrote:
| 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..
| ericyd wrote:
| 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.
| Someone1234 wrote:
| 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.
| PokestarFan wrote:
| 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() { /* ... */ }`
| rafram wrote:
| Given that this is meant to be a safe alternative to inline
| JS, executing arbitrary JS would be counterproductive.
| gatinsama wrote:
| It's good they are improving and extending HTML, but still a long
| way to go. The HTMX guys have a few good ideas.
| rsync wrote:
| 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 ...
| wruza wrote:
| 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.
| wmanley wrote:
| > We could have ten different open-source web browsers
|
| To what end?
| mirkodrummer wrote:
| 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
| johnfernow wrote:
| 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.
| hoc wrote:
| 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.
| dartos wrote:
| It's not that the idea is brand new, just that it's now
| implemented in chrome and in the web specs.
| wruza wrote:
| 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.
| 9dev wrote:
| What would have been something useful?
| Starlord2048 wrote:
| 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?
| SamBam wrote:
| > 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.
| fitsumbelay wrote:
| agreed, my sense is that frameworks will update to take
| advantage as they've done in the past
| toomim wrote:
| > 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.
| satvikpendem wrote:
| CSS is now getting functions as well [0].
|
| [0] https://news.ycombinator.com/item?id=43236126
| toomim wrote:
| 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.
| xg15 wrote:
| Everything will be _even more_ complicated and confused.
| someothherguyy wrote:
| The sky isn't falling, and nearly everything is trending
| better, not worse. You can use whatever features of
| browsers that you want.
| metadat wrote:
| 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.
| porridgeraisin wrote:
| The entrenched are the ones deciding the features. This
| is their goal
| agosz wrote:
| 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.
| shiomiru wrote:
| 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.
| mirekrusin wrote:
| Is there DOOM in CSS already?
| panstromek wrote:
| There's a Wolfenstein https://css-tricks.com/hacking-css-
| animation-state-and-playb...
| AlienRobot wrote:
| 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.
| G_o_D wrote:
| 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
| pphysch wrote:
| 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.
| jauntywundrkind wrote:
| 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
| xg15 wrote:
| My prediction: In a few iterations this will have turned into
| an inferior reinvention of HTMX.
| arcanemachiner wrote:
| I believe the stated goal of HTMX's developer was to
| integrate the functionality of HTMX into HTML.
| wraptile wrote:
| 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.
| fmxsh wrote:
| 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.)
| lelanthran wrote:
| >> 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.
| tomrod wrote:
| 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.
| freeone3000 wrote:
| 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...
| chuckadams wrote:
| 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
| brap wrote:
| 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.
| cratermoon wrote:
| I'd gladly give up this if I could get ublock origin and other
| pre v3 extensions back
| ulrischa wrote:
| HTML seems to incubate some htmx things
| lelandfe wrote:
| 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
|
| [0]
| https://html.spec.whatwg.org/multipage/popover.html#popover-...
| Izkata wrote:
| I think "light" is used as in "light touch" (soft touch),
| something that includes brushing against a surface by accident.
| efortis wrote:
| I'd guess it stands for highlight. For example a modal is
| often highlighted by dimming and blurring the background.
| david422 wrote:
| 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.
| dylan-m wrote:
| 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.
| jazzyjackson wrote:
| 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.
| victorbjorklund wrote:
| Most of the times that would be better solved with not using
| a modal.
| bartkappenburg wrote:
| 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.
| hatthew wrote:
| Anecdotally, when I read the first two lines of your comment I
| immediately thought "that probably means you can click
| elsewhere to close it"
| prmph wrote:
| 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
| skydhash wrote:
| Flash? Silverlight? Swing?
| prmph wrote:
| 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.
| nullpoint420 wrote:
| +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.
| satvikpendem wrote:
| 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)
| prmph wrote:
| 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.
| satvikpendem wrote:
| Have you tried Flutter? It works well although web
| performance leaves some to be desired.
| mappu wrote:
| Joey Hess had this suggestion recently -
| https://news.ycombinator.com/item?id=43202773
| SoftTalker wrote:
| It's been some years since I coded any front-end HTML. Sure looks
| like it's gotten messy.
| flowerthoughts wrote:
| 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.
| _betty_ wrote:
| interesting, they could finally deprecate the form attribute on
| buttons...
| fitsumbelay wrote:
| more builtin behavior, less JS to ship. pretty dope
| fngjdflmdflg wrote:
| >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/
| werdnapk wrote:
| The popover API is not a replacement for <dialog>. It's an
| alternative to some dialog like functionality if the use case
| is right.
| Zardoz84 wrote:
| A popover and <dialog> are totally different things. Also, no
| body replaced or deprecated <dialog>
| slt2021 wrote:
| 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
| naikrovek wrote:
| 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.
| slt2021 wrote:
| 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
| Tarucho wrote:
| 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.
| karol wrote:
| 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.
| kflgkans wrote:
| > That looks like more XSS vectors.
|
| Could you elaborate on that? I don't understand how this leads
| to more XSS vectors.
| karol wrote:
| 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.
| Keithamus wrote:
| 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).
| nikeee wrote:
| > 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.
| mubou wrote:
| 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.
| pavlov wrote:
| 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.
| gear54rus wrote:
| > 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.
| pavlov wrote:
| Mobile absolutely uses "shit from 1994".
|
| The UI framework in iOS is a direct descendant of the NeXT
| one I'm talking about.
| mattl wrote:
| 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)
| deergomoo wrote:
| 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.
| ChrisClark wrote:
| >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
| diegof79 wrote:
| 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.
| withinboredom wrote:
| 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.
| hombre_fatal wrote:
| > 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.
| thesz wrote:
| > The React/JS code is far simpler and less clunky than the
| Objective-C equivalent.
|
| How does it compare to Tcl/Tk? Especially canvas with tags
| over elements, with tags having their own bindings.
| DannyBee wrote:
| "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 :)
| deergomoo wrote:
| 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.
| bunderbunder wrote:
| 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.
| AlienRobot wrote:
| 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.
| dgfitz wrote:
| 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.
| AlienRobot wrote:
| 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.
| int_19h wrote:
| 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...
| mpalmer wrote:
| 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.
| gavinray wrote:
| > 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)
| pfg_ wrote:
| contenteditable is incredibly painful to use, not
| standardized and different across browsers, and buggy in
| firefox
| gavinray wrote:
| 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.
| sangnoir wrote:
| > 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.
| naasking wrote:
| > 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.
| roon_shady wrote:
| am I the only one annoyed by the fact that they do not have
| syntax highlighting on most of their code examples?
| garganzol wrote:
| I do not understand why they did it now when JavaScript already
| does it. The thing just adds entropy without a clear value.
| webnoob wrote:
| I'm curious, as a noob in web programming. That first example
| does document.addEventListener('click', ...
|
| Instead of someButton.addEventListener('click',
| ...
|
| And in fact, all the framework example show button onClick not
| document onClick
|
| 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?
| zerocrates wrote:
| 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.
| irjoe wrote:
| 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.
| lelandfe wrote:
| > 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
| luismedel wrote:
| One more case of Fire and Motion[0] in the industry.
|
| [0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
| jandrese wrote:
| > 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?
| jameshart wrote:
| 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'.
| crabmusket wrote:
| 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?
| jameshart wrote:
| 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.
| jandrese wrote:
| Is it common that the HTML gets injected but inline scripts
| can not be injected at the same time?
| mpalmer wrote:
| 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.
| hdjrudni wrote:
| 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.
| mpalmer wrote:
| 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.
| conartist6 wrote:
| I know what you mean
| qwery wrote:
| 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'.
| ximm wrote:
| I agree, but at least it is consistent. This is also how `for`,
| `list`, `aria-labelledby`, `aria-describedby`, and probably
| many other attributes work.
| CodeCompost wrote:
| This is basically HTMX. Why don't they just integrate it natively
| into the browser?
| jl6 wrote:
| Since it's all about buttons, it's a shame they missed the
| opportunity to call it butfor.
| smitelli wrote:
| Sigh. Fine, I'll do it.
|
| What's a butfor?
| adamredwoods wrote:
| >> 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.
| stevenpetryk wrote:
| I'd much prefer el['show-popover']()
| cariaso wrote:
| everyone is crediting intercal but
|
| https://en.wikipedia.org/wiki/Comefrom
|
| speaks to the history and rightly credits larry clark
| layer8 wrote:
| 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.
| jongjong wrote:
| > 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?
| chuckadams wrote:
| > 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.
| e12e wrote:
| 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.
| jongjong wrote:
| 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.
| Inviz wrote:
| Oh, it's coming back!
|
| Called for it: https://news.ycombinator.com/item?id=40888664
| jongjong wrote:
| 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.
| DonHopkins wrote:
| HTML needs a <button type="revolt"/> to counteract the <button
| type="submit"/>.
| jes5199 wrote:
| 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
| tln wrote:
| <dialog>
|
| Chrome 37, Aug 2014 Safari 15.4, Mar 2022
|
| popover attribute
|
| Chrome 114, May 2023 Safari 17, Sep 2023
| Zardoz84 wrote:
| 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
| qwery wrote:
| > 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.
| afavour wrote:
| 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.
| porridgeraisin wrote:
| 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
| afavour wrote:
| To me that feels like a technicality. It's the same
| experience you'd get with a button + JS except with more
| latency.
| furyofantares wrote:
| 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.
| pmontra wrote:
| 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.
| xg15 wrote:
| > _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.
| neuroelectron wrote:
| GET requests always change state on the server because we
| have logs. Furthermore logs are often parsed by
| XMLparsers which are often error prone.
| xg15 wrote:
| 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)
| social_quotient wrote:
| 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.
| xg15 wrote:
| 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)
| lelanthran wrote:
| > 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.
| smac__ wrote:
| 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.
| spoaceman7777 wrote:
| 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.
| skobes wrote:
| 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.
| vivzkestrel wrote:
| 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
| flakiness wrote:
| 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.
| Keithamus wrote:
| 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!
| transfire wrote:
| 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:
| #my-popover { display:= none; } #my-button:click {
| |> #my-popover { display:= block; }
| }
|
| Where `|>` retargets and the `=` indicates the property can
| undergo state changes. (Maybe the syntax could be better, but you
| get the idea.)
| MacGyver101 wrote:
| Browsers: We are not happy that only Tailwind will pollute HTML.
| We want our part of cake too.
| mirkodrummer wrote:
| 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?
| garganzol wrote:
| 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.
| mirkodrummer wrote:
| 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
| micromodel wrote:
| 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.
| RobMurray wrote:
| 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.
| TaurenHunter wrote:
| I've misread this excitedly as "Command and Conquer" for HTML
| thinking it had to do with the recently released source code.
| tinodb wrote:
| 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.
| neuroelectron wrote:
| Someone was just telling me that Google doesn't have significant
| influence on web standards.
| G_o_D wrote:
| <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
| 77 wrote:
| 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.
| tarjei_huse wrote:
| 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?
| ksec wrote:
| I am waiting for the author of HTMX's opinion on it. They dont
| seems to have commented here yet.
| gred wrote:
| 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.
___________________________________________________________________
(page generated 2025-03-08 23:01 UTC)