Have you been following how HTML has evolved over the past 20 years? Your comment suggests not.
It’s not entirely a standards-driven process. It’s common for browser vendors to just build stuff. That’s been a mixed blessing but it has definitely been faster than some W3C consortium debating “ergonomics” for years.
Successful additions get backported into the spec, slowly.
Chrome is the new IE. Whatever google decides will become a standard (both defacto due to them controlling the market and just shipping new version just in time and de-jure due to them financing W3C consortium and other standard bodies)
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
After y'all've had such great success with the Stacked Contractions movement starting in 2017 -- which I would like to take credit for independently spearheading on the Neopets forums in the mid-2000s, but I'dn't've been able to do it all myself of course -- I'd like to propose our next campaign.
Let's bring back pronominal adverbs! You may already be familiar with such classics as "therefore" or "whereas". Why not revive all of them? No longer are "hereunder" and "thereinafter" the sole domain of lawyers. That alone would be an epic meme indeed, but we must go therebeyond. It is difficult to believe that anyone ever actually used words like "therethroughout" or "wherewithin", but we can make sure someone does.
You can even make up your own!
Just take any demonstrative (this/that/these/those), interrogative (what/which/who/where), or third-person personal pronoun, and turn it into the corresponding locative adverb, depending on whether you want to indicate being at, coming from, or going to something:
This -> Here/Hence/Hither;
That -> There/Thence/Thither;
What/who/which -> Where/Whence/Whither;
Him/Her/Them -> There/Thence/Thither; etc.
Makes sense? No questions? Great!
Now pick your favorite preposition and stick it on the end. Don't forget to experiment with some archaic prepositions like "anighst", "overthwart", and -- here's a really good one -- "withinside". That one means "within / inside" and I'm sure you can already see the potential.
"What place should I go into?" Nope! "Whitherwithinside should I go?" Now we're talking.
Maybe I'm lost about the greater theory here. As a non-js dev it looks like they're just adding some OO sugar to events. I hesitate to call it sugar because it seems a lot more verbose than "my-menu.show-popover()" but its better than a global listeners I suppose.
It's also foundational in Threaded INTERCAL, where "multiple COME FROM statements with the same label cause the program to fork separate threads at each COME FROM":
That’s a reasonable analogy, but I think the more novel and interesting thing about this is that it’s:
- A declarative mechanism to relate one element to another
- With a range of semantics for declaring interactivity invoked through their relationship
- At a high level, with explicit guarantees of consistent accessibility and UX
In a lot of ways, this looks a lot like what people describe when they wish for more HTML and less JS. (Except for the extreme-minimalist version of that which rejects web interactivity altogether.)
Haha, I had completely forgotten about intercal and "comefrom".
Such genius. It anticipates and neatly summarizes the problems I've had maintaining and supporting code written using reactive programming design patterns by a good 40 years.
Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine. You want to pose a challenge, maybe try something like Rongorongo or Klingon. Me, I want to write my code in actual hieroglyphics.
you are talking to an Indian who lives in India, and who knows Hindi (a language derived from Sanskrit) fluently (and has been complimented multiple times for his Hindi speaking ability by native Hindi speakers), and who has studied Sanskrit for 3 years in high school and then 2 years in college, and Hindi for 4 years in high school, including grammar, vocabulary and literature (both poetry and prose) in both languages), and also essay-writing in Hindi. and got a high score in class in both those languages, over all the years that he studied them.
and who has spoken Hindi for much of his adult life.
both those languages are written in Devanagari.
>Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine.
whether the (programming) language can grok Unicode, has nothing to do with the number of people who use either Sanskrit or Devanagari, so your statement lacks logic, overall.
you said:
>Sanskrit is written in Devanagari script which is used by nearly a billion people
that statement shows ignorance of actual facts.
here is why:
I had an idea about these points informally, already, being an Indian who lives in India, but I still did a few quick googles, to verify:
List of languages by number of native speakers in India:
>Today, the Devanagari script is used to write three major languages: Hindi (over 520 million speakers), Marathi (over 83 million speakers) and Nepali (over 14 million speakers).
even if you add the number of people in the Indian diaspora, such as in Fiji, the Caribbean, etc., you will not come to nearly a billion.
you made a wrong assumption:
> You want to pose a challenge, maybe try something like Rongorongo or Klingon.
you assumed that I was posing a challenge. I was not.
you seem to have not recognised that my comment was made in jest:
Double dude, your pathetically weak thinking, and even more, your obviously inferiority-complex-ridden nature, which is evidenced by your trying (unsuccessfully) to strike out viciously at others who make knowledgeable, reasonable and innocuous comments (see mine above, to which you replied in your ugly way), show, overall, your utter sickness and poverty, mental, physical and emotional.
first of all, I am posting again one of my earlier comments in reply to you:
let the whole world see it, and know you for the kind of guy you are, chuckadams, you creep, fake, ignoramus and liar.
acting (faux) scholarly and trying to tell me things (which are totally wrong) about my own country and culture, you jackass. you are laughable.
fool. everyone here noticed that you "cleverly" avoided replying to any of my above points, and instead tried to divert the topic by trying to insult me, you fuckhead and fucktard:
>I don't think you're capable of jest. Get some therapy.
hee hee hee.
not just me, no sane or decent person is interested in the opinions of a retard like you, except other retards like you, of which I know there are many, so some are sure to downvote my comment, but who the bloody fuck cares for votes or opinions of others, except losers like you and your friends, who I am sure you will encourage to waste their unvaluable time in downvoting, because laid off and no work and little money left, right? There are tons of recent posts on HN about all the people feeling the pain of no jobs and no money, which situation is partly if not largely due to the brain-dead shenanigans of jokers like you, who kept on demanding unsustainable raises, for years (which is why your jobs went to India and Ukraine and Mexico and ...), and job hopping for the same, which has now finally ended in so many of you guys being kicked out of your comfy, highly overpaid jobs, so that now you are on the street, scrabbling to make ends meet.
you are not capable of anything good, only of rotten shit! :)
I am fine. You need much more than therapy. you need a life, and to have interest in it. until then you will be as unhappy as you are now.
now, fuck off, you pathetic excuse for a human being.
don't waste your time insulting others gratuitously.
:) Google the double meaning (1 and 2) of that last word, or if you are unable to do it, swallow this crumb, dog:
and I don't give a flying shit if I am banned for this comment, because you started it, with your 2 ugly comments above, and because who gives a shit about hn in the real world anyway. let the whole world know how discriminatory HN is, with a very western-favoring slant, if not outright racism, towards Indians, Asians, etc., by comment posters, voters and moderators.
i'll repeat what i have quoted here a few times before; it's by Amy Hoy:
Fuck HN.
that is what she famously said, somewhere on one of her sites, some years ago. yes, so that means the rottenness of the site started or already existed back then, not just now.
so don't worry, you are in bad company.
cough I hereby propose two new language constructs and corresponding keywords, which can be applied (sounds more functional than implemented,) widely across many languages, at least procedural / imperative ones:
goto and comefrom
with optional synonyms:
leave to and return from
the above can be shortened to as little as two letters each:
I can't quite tell if you're serious. Continuations are fun, so I'll post this on the off chance it helps someone.
They are perplexing until they aren't. Model stack frames as independent state. When you return from a function the stack frame can stick around. Now later, place your stack pointer back in the frame that you returned from earlier.
Add a convention for passing arguments when you update the stack pointer as above. Now you have continuations.
so you can place your stack pointer back in the frame that you returned from earlier? that's probably the point at which they stopped understanding continuations before even starting.
I was explaining the joke? Since the person I was replying to seemed to wonder if it was really a joke, whereas for me, structurally it was obviously a joke.
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..
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.
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.
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() { /* ... */ }`
No, it is terrible that "they" continue to extend and "improve" HTML.
This is the reason it seems impossible for an independent web browser to be created and maintained: because what should be a simple and predictable spec over the last twenty years is a rapidly moving target that takes significant resources just to track.
We could have ten different open-source web browsers (like Konqueror) if we weren't cramming the HTML spec full of bloat that nobody wants and that we all install extensions to disable anyway ...
I’m pretty sure this is the only goal. Everyone with a neuron or two can see that the internet doesn’t use web tech and abstracts it away as soon as possible. These people just grow their corporate security by adding nonsensical bullshit that makes zero difference irl.
Sane competition, developers and end users would benefit from competition. This is just corporate lock-in. When a user is required to install Chrome for using a web app we're failing him as a platform, and the open web goes off the rail
Having a browser written entirely (or mostly) in a memory safe language.
LadyBird is now using some Swift, but most of the code is still C++. The browser, while extremely impressive (and I’m very thankful it exists), has a ways to go before it’s a true replacement for Chromium/Blink, Firefox/Gecko or Safari/WebKit, and rewriting all the existing code in Swift would be a massive undertaking.
Chromium and Firefox also use some Rust, but re-writing those browsers entirely in it would be an even larger undertaking.
In contrast, a simpler browser spec would make it far easier to create a brand new browser in a memory safe language. Not only would this massively improve security on all operating systems as the browser is a huge vector for exploits, it’d also allow for the creation of new, more secure operating systems. Currently, arguably the biggest blocker for using something like RedoxOS (an OS written in Rust) is that it doesn’t have a web browser that can actually work for a lot of the web. But if the web browser spec were simpler, it’d be much easier to create one and then use that OS.
Obviously we can’t go back in time and make a simpler web-spec, and removing features is a terrible idea as it’d break existing websites. I do think, though, that it’s fair to think very hard before adding new features. I think a complete feature freeze would be overkill — some new features could legitimately make web development simpler and cleaner for many webdevs. I do think there needs to be some thought as to what the end-goal for web browsers is. Is there one? Or will we forever continue to add new features at the current pace? If so, the hopes of building a new, more secure browser are dim. And personally I’d prefer a more secure browser to one with more features.
As a comparison, C++ has been adding plenty of new features, but nearly no devs are aware of the full feature set, and despite the goal of making things simpler, I think many devs are as lost as ever with it, as they still have to interface with code written in old and different manners. On the web dev side, some JS and CSS features do legitimately simplify development and make things easier, but I think it’s fair to say that’s not the case for all new features added.
Is this really the action/messaging pattern that Next, Be and then Apple and probably others used about 30 years ago, or did I miss something here.
It was useful in a way but basically evolved into interface-based controller patterns due to the needed complexities and the whish to keep the basic underlying design pattern. So I'd expect to see lots of enhanvement requests once that box was opened :)
There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.
You thought web was 15 years behind, but it quickly catches up to 30 years old tech!
News like this make me feel sick. I thought it could become something usable in my lifetime, but I’m knee osteoarthritis years old and it still reinvents poor man’s target-action. Sad clownage.
> 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.
> 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.
Horrible. We're going to end up with three separate languages: CSS, HTML, and Javascript, which will each be turing-complete programming languages with completely-overlapping featuresets, and there will be no clear reason to use one over the other.
Browsers will have to implement support for three PL runtimes. Everything will be complicated and confused.
There are tradeoffs. Further increasing the barrier to entry for new web browsers benefits the entrenched players and hurts end users by yielding fewer alternatives.
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.
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.
It's not just shifting complexity. It improves locality of behavior (LoB). You can look at a <button> element and immediately know what it does (within the limited domain of "command"s). This is a dramatic improvement to readability.
My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there. Behavior of the page can be made visible! There's so much allure to me to hypermedia that's able to declare itself well.
This could radically enhance user agency, if users/extensions can rewire the page on the fly, without having to delve into the (bundled, minified) JS layers.
There's also a chance the just-merged (!) moveBefore() capability means that frameworks will recreate HTML elements less, which is a modern regression that has severely hampered extensions/user agency. https://github.com/whatwg/dom/pull/1307
> My long-shot hope is that the page can come to embody most of the wiring on the page, that how things interact can be encoded there.
I would love this. As a Tailwind user the last few years, it’s really been refreshing to have my styles both readable and inline on the elements instead of filed away in SCSS I’ll never see again. Even with scoped styles, some components get large enough that it feels unwieldy
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.
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.)
>> 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.
I'm not a web dev, so I apologize if my questions are naive. Does this mean its a chrome-only thing or does it become a web standard? I ask because I would like to imagine the future isn't tied to Google's whims, graveyard of initiatives, and requirements.
That would be really nice, but, that’s been the way of it for the last few features too… it might not get adopted, but if enough people start using it…
My experience with anything declarative is that features are gradually bolted on until it eventually just becomes imperative (and ugly). For example HCL.
I believe declarative should stay purely declarative to describe data/documents in a static state (e.g. HTML, JSON) and an imperative “layer” can be used to generate or regenerate it, if needed.
Random aside. Their code snippet has this comment:
// popovers have light dismiss which influences our state
And I hadn't heard of that phrase before! Turns out it means "clicking elsewhere closes the thing:"
> "Light dismiss" means that clicking outside of a popover whose `popover` attribute is in the auto state will close the popover.[0]
Like what, say, a `<select>` does when open.
Strikes this dev as a pretty unintuitive way to phrase that. At first I thought it was "light" as in "light DOM," but I guess it's "light" as an antonym of "explicit?" Looks like there was some back and forth on this, and it was even proposed as an attribute: https://github.com/openui/open-ui/issues/834
Also random aside. I dislike this pattern for modal dialogs. Often times I will need to gather information from somewhere else, and in the process of attempting to get focus back to the dialog I've touched/tapped/clicked on something that dismisses the dialog. Very annoying.
I'm okay with modal dialogs working that way as long as people get the message: dialogs are supposed to be ephemeral. If closing the dialog loses important state, or you need information from something under the dialog in order to use the dialog, what you have shouldn't be a modal dialog. And you can tell, because in most UI frameworks that widget is just begging to be closed. Unfortunately, a lot of teams don't get the message.
I don’t say this often, but Jira got this correct. When you’re creating a new ticket, it’s done in a modal. But if you close it or click the “X”, it minimizes to the bottom of the page so that you can look at other tickets, or look up something relevant to the one you’re making.
I’ve been trained that modals are ephemeral, and I have to take a sec of “ugh I have to close this to look stuff up…wait, no I don’t” when using Jira
Just noticed this bug in Simplifi expense tracking web app. The drop down to update the category of a transaction has multiple levels (e.g. Business:Travel:Lodging) and as soon as I hover over a nested drop down the whole thing disappears.
Light is the opposite of hard (ie hard close). It makes more sense (to me!) to use explicit vs implicit close? Clicking outside the popover means an implicit close.
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
+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.
Ian Hickson, who authored the HTML5 spec and leads Flutter, has written about exactly this, Towards a Modern Web Stack [0][1], to create a new stack that can handle modern web applications. Flutter is a part of it but he talks about a more general (and generalizable) stack. He's on the HN thread as well expanding on the rationale behind it. Interestingly, it seems like specific people on HN don't exactly like it, a bit funny to witness their crash outs.
I have gone through Hickson's proposal, interesting.
I notice though that he is proposing to address the problem from the opposite direction to mine, though I think his approach is also viable. I dream of an HTML-like platform built to support rich UI apps, with much higher-level configurable primitives that eliminate the need for massive amounts of scripting and dependencies. He talks about providing properly configurable low-level primitives.
Both approaches can work if built properly to support what developers actually want to do. One thing that put me off WASM was the dependence on JS to bootstrap it. I just did not want to have JS in pipeline again whatsoever if I was taking that approach. The advantage of high-lvel primitives is that there will be much more of what developers want to build that is already built into the platform.
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.
>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?
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.
It’s not executing JS. The names map to JS methods but both the HTML and JS call into C++ (or rust or swift whatever the browser is written in). Arbitrary JS code execution cannot occur. Of course if you’re ingesting user generated content you should not allow these attributes on buttons (but for proper security you should already have an allow-list of tags and attributes on any user generated content).
> the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.
Didn't these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions/attributes?
Sometimes things like these make me wonder if the people in charge are conscious about that everything they are putting in will stay there forever. You can't just release an update and remove stuff you ("you" as in: the web devs at your company that happen to be in the same company that builds a browser) don't need any more.
I thought that was odd, too. It would have made more sense if they'd implemented this for media controls first, and then consolidated the popover attributes into it later. This feels like a record for fastest deprecation of a web feature ever.
269 comments
[ 2.4 ms ] story [ 288 ms ] threadAre we back to the IE-era mess then?
If so, let's bring <marquee> back.
No, of course not. Web standards are whatever google decides they are.
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.
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 in Firefox and Safari
https://caniuse.com/mdn-html_elements_marquee
https://github.com/WebKit/standards-positions/issues/264
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...
But not too polite. The compiler wouldn't like that.
https://en.m.wikipedia.org/wiki/Boo_(programming_language)
Let's bring back pronominal adverbs! You may already be familiar with such classics as "therefore" or "whereas". Why not revive all of them? No longer are "hereunder" and "thereinafter" the sole domain of lawyers. That alone would be an epic meme indeed, but we must go therebeyond. It is difficult to believe that anyone ever actually used words like "therethroughout" or "wherewithin", but we can make sure someone does.
You can even make up your own!
Just take any demonstrative (this/that/these/those), interrogative (what/which/who/where), or third-person personal pronoun, and turn it into the corresponding locative adverb, depending on whether you want to indicate being at, coming from, or going to something:
This -> Here/Hence/Hither;
That -> There/Thence/Thither;
What/who/which -> Where/Whence/Whither;
Him/Her/Them -> There/Thence/Thither; etc.
Makes sense? No questions? Great!
Now pick your favorite preposition and stick it on the end. Don't forget to experiment with some archaic prepositions like "anighst", "overthwart", and -- here's a really good one -- "withinside". That one means "within / inside" and I'm sure you can already see the potential.
"What place should I go into?" Nope! "Whitherwithinside should I go?" Now we're talking.
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.
Of course, COMEFROM's grown up (and very real) sibling is ALTER GOTO in COBOL.
https://www.cs.virginia.edu/~asb/teaching/cs415-fall05/docs/...
https://esolangs.org/wiki/Threaded_INTERCAL
- 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.)
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.
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
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.
intro:
you are talking to an Indian who lives in India, and who knows Hindi (a language derived from Sanskrit) fluently (and has been complimented multiple times for his Hindi speaking ability by native Hindi speakers), and who has studied Sanskrit for 3 years in high school and then 2 years in college, and Hindi for 4 years in high school, including grammar, vocabulary and literature (both poetry and prose) in both languages), and also essay-writing in Hindi. and got a high score in class in both those languages, over all the years that he studied them.
and who has spoken Hindi for much of his adult life.
both those languages are written in Devanagari.
>Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine.
whether the (programming) language can grok Unicode, has nothing to do with the number of people who use either Sanskrit or Devanagari, so your statement lacks logic, overall.
you said:
>Sanskrit is written in Devanagari script which is used by nearly a billion people
that statement shows ignorance of actual facts.
here is why:
I had an idea about these points informally, already, being an Indian who lives in India, but I still did a few quick googles, to verify:
List of languages by number of native speakers in India:
https://en.m.wikipedia.org/wiki/List_of_languages_by_number_...
Demographics of India:
https://en.m.wikipedia.org/wiki/Demographics_of_India
https://www.google.com/search?q=number+of+people+who+use+dev...
top paragraph of the results of the above search:
>Today, the Devanagari script is used to write three major languages: Hindi (over 520 million speakers), Marathi (over 83 million speakers) and Nepali (over 14 million speakers).
even if you add the number of people in the Indian diaspora, such as in Fiji, the Caribbean, etc., you will not come to nearly a billion.
you made a wrong assumption:
> You want to pose a challenge, maybe try something like Rongorongo or Klingon.
you assumed that I was posing a challenge. I was not.
you seem to have not recognised that my comment was made in jest:
>b-b-but ... does Perl support Sanskrit?
first of all, I am posting again one of my earlier comments in reply to you:
https://news.ycombinator.com/user?id=fuzztester
let the whole world see it, and know you for the kind of guy you are, chuckadams, you creep, fake, ignoramus and liar.
acting (faux) scholarly and trying to tell me things (which are totally wrong) about my own country and culture, you jackass. you are laughable.
fool. everyone here noticed that you "cleverly" avoided replying to any of my above points, and instead tried to divert the topic by trying to insult me, you fuckhead and fucktard:
>I don't think you're capable of jest. Get some therapy.
hee hee hee.
not just me, no sane or decent person is interested in the opinions of a retard like you, except other retards like you, of which I know there are many, so some are sure to downvote my comment, but who the bloody fuck cares for votes or opinions of others, except losers like you and your friends, who I am sure you will encourage to waste their unvaluable time in downvoting, because laid off and no work and little money left, right? There are tons of recent posts on HN about all the people feeling the pain of no jobs and no money, which situation is partly if not largely due to the brain-dead shenanigans of jokers like you, who kept on demanding unsustainable raises, for years (which is why your jobs went to India and Ukraine and Mexico and ...), and job hopping for the same, which has now finally ended in so many of you guys being kicked out of your comfy, highly overpaid jobs, so that now you are on the street, scrabbling to make ends meet.
you are not capable of anything good, only of rotten shit! :)
I am fine. You need much more than therapy. you need a life, and to have interest in it. until then you will be as unhappy as you are now.
now, fuck off, you pathetic excuse for a human being.
don't waste your time insulting others gratuitously.
:) Google the double meaning (1 and 2) of that last word, or if you are unable to do it, swallow this crumb, dog:
https://www.dictionary.com/browse/gratuitously
and I don't give a flying shit if I am banned for this comment, because you started it, with your 2 ugly comments above, and because who gives a shit about hn in the real world anyway. let the whole world know how discriminatory HN is, with a very western-favoring slant, if not outright racism, towards Indians, Asians, etc., by comment posters, voters and moderators.
i'll repeat what i have quoted here a few times before; it's by Amy Hoy:
that is what she famously said, somewhere on one of her sites, some years ago. yes, so that means the rottenness of the site started or already existed back then, not just now. so don't worry, you are in bad company.But still, so long as it’s a script in Unicode, it should all work fine.
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?
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.
Of course modern LLVM already breaks it up into chunks anyway (given certain flags at least) so it likely isn't contiguous regardless.
they make it cumbersome to use by hand, but not impossible
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.
Still appreciate the new features though.
Although, the buttons are very interesting.
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
Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.
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() { /* ... */ }`
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 ...
To what end?
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.
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.
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?
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.
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.
[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
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
I would love this. As a Tailwind user the last few years, it’s really been refreshing to have my styles both readable and inline on the elements instead of filed away in SCSS I’ll never see again. Even with scoped styles, some components get large enough that it feels unwieldy
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.
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.)
> 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.
https://caniuse.com/mdn-api_commandevent
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.
> "Light dismiss" means that clicking outside of a popover whose `popover` attribute is in the auto state will close the popover.[0]
Like what, say, a `<select>` does when open.
Strikes this dev as a pretty unintuitive way to phrase that. At first I thought it was "light" as in "light DOM," but I guess it's "light" as an antonym of "explicit?" Looks like there was some back and forth on this, and it was even proposed as an attribute: https://github.com/openui/open-ui/issues/834
[0] https://html.spec.whatwg.org/multipage/popover.html#popover-...
I’ve been trained that modals are ephemeral, and I have to take a sec of “ugh I have to close this to look stuff up…wait, no I don’t” when using Jira
We've learned a lot about security, DX, and UX since those times. A new platform can apply all those.
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.
[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.
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/
Less javascript the better, plus it allows to impute dynamic behavior from HTML tags, without parsing JS code
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.
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.
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.