browser should not even let the page see this action
> Don't roll your own link navigation.
browser should not even let the page see this action
> Don't roll your own text selection.
browser should not even let the page see this action
> Don't roll your own copy and paste.
browser should not even let the page see this action
I'm serious. WHY javascript code is even allowed to see all these actions of the user? We already loaded the page and rendered it - we users must already be free to do with the content as we please
scrolling: used by games, maps, image viewers
link navigation: used for client-side routing (youtube/twitch, any website with a chat window)
text selection and copy/paste: word processors, spreadsheet editors, forum software, etc.
I'm not sure if your question was sincere or if you were trying to say that the web should not support these use cases.
Features paramount in a document viewer (broadly, "respect the user's local document viewing preferences") aren't desirable in a general purpose application platform.
A large number of companies/web developers don't think of themselves as offering the user a document to view on their own terms, but rather an "experience" that they want full control over (which means, most of the time: show ads and record user behavior).
If you're offering me a game, fair enough. But if you're showing me my hotel reservation or electric bill, I want a document, not an ""experience"".
It's a thing you can do. But it is very bad for extensions and extension developers for the same reasons that Java applets, Flash, and Shockwave were bad for the web. These apps are difficult for end users to customize. It's a real bane to tinkerers. And it's a shame that "view source" has slowly grown completely useless over the decades.
[1]: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
Out of curiosity, does anyone like the way Google Maps hijacks scrolling? I use a trackpad. When I scroll, I'd want it to pan around on the map, not zoom in and out (which always feels awful as a scroll action and never stops where I want it to).
Click-drag to pan doesn't feel nice.
It doesn't really matter anymore, since 99% of maps use is on mobile now, but this was always a small pain point to me in the past.
Pinching/spreading with index and middle finger feels unergonomic. Using my thumb on the trackpad would also feel unnatural, as would putting my 2 index fingers on the trackpad.
2 finger scroll is something you can "fling" such that the zooming motion continues even as your fingers have been lifted off the trackpad. Trying to "fling" a spread-out motion with your index and middle finger is an awkward motion, and of course in a pinching motion, your fingers would just crash into each other, so you'd have to lift before they crash. Pretty awkward.
On the phone, I often prefer tap then drag up/down (i.e. touch, lift, touch, slide) to zoom in/out with a single finger. It allows me to "fling" the zooming motion so it continues after I've lifted my finger. It makes a phone's interface behave like a trackpad's scrolling-zoom.
Panning by swiping feels so natural. That it breaks on a trackpad feels like a major oversight.
I have strong suspicion that it's exactly because of the “document” history why web is so approachable to creators, why there is “view source” and ultimately why you can hop from simple html blog, to CRUD app, to advanced CAD software.
aaaand you lost my interest the moment money got involved
all these things are already fixable by browser extensions - what is lacking is exposing that in browser options and even making it the default
Nope we haven’t. At least not in a web application. At least not since the days Infinite Scrolling was invented. IIRC Twitter, for eg, only renders a partial list depending on the scroll position.
I once wrote a NER tagger, where implementing custom text selection allowed users to not stress about selecting the exact word boundaries when manually tagging 1000s of words per day.
I can probably find legitimate use cases for almost of these things in the list. While I agree with the broader theme of the article, this idea that the user agent should be a dumb display is not valid.
I mean, I'm all for for switching to Lua or smth (which is a slightly different anti-JS camp than yours), but the problem isn't in interactive (or even non-frozen) pages in general - it's in pages reading user actions that user doesn't expect/want to
That's all there really is to it: Mosaic added image support. Investors got excited and asked if the images could animate, if they could record click data and credit card data, if they could add video and additional presentational elements. Holistic user experiences were secondary.
To move forward we have to accept that most of this wasn't an accident and it needs some breaking changes.
I was already in favor of banning it. You don't have to keep trying to convince me.
Okay, snark off. But as someone who dislikes the proliferation of "web apps", I'd be perfectly happy to see Google Docs and others die off if it meant we moved back to real, locally run applications.
Because the alternative is UI/UX Designers and Visionary Managers insisting on keeping Flash and Java Applets and Microsoft Visual Silverlight .Net++ around forever, because you can't do some things in the browser and We Need To Do Them.
Some things have minimal complexity that either lives in the language itself or in libraries. The Web has minimal bells and whistles that are either implemented in the browsers itself or in plugins.
I don't enjoy needing to "go back" 100 times, once for each page of the book just to return to f.e. search results I opened the book from
Because on the modern web, the user is the content, sold to the highest bidder.
* Don't roll your own standard controls
Seriously. Don't. You want a single-select box? Use a combo box or radio button group. Want an edit box? Use an edit box. Want a list that finds things as you type? That's in the standard too. Don't roll your own.
This "roll our own controls for everything" bothers me to no end as a screen reader user, because practically nobody properly follows ARIA best practices, and that leads to a less accessible internet.
The one in webkit on macOS isn’t quite as good, but is better than the one in firefox if only because firefox closes the picker when you type a year in to move far through time. Good thing firefox is open source.
You mean your browser's. There is no "the browser".
The date range selector used in Google Flights is a near flawless control. The implementation can be done, it’s just hard.
I have a personal issue with having a 500KB page load, so a button press can be animated.
I hate how most "modern" websites have MEGABYTES of JavaScript. CSS? Pack it in a js bundle with JSX and object literals. Images? Throw them in too, just make it load on demand.
Hell, just put a <div id=root/> there and let js do the rest. It's not like we have browsers and networks and edge nodes optimized to render websites in other ways.
Bloated sites need to go. Putting makeup on the pig and it’s still a pig.
Congratulations, now your website is a shitty experience for your users. Well done.
The engineers and designers then proceed to do as they're told because they like that nice fat paycheck at the end of the month more than they like the service they're building. Which is fair enough.
twitter and google and google maps and so many have rolled their own and they completely suck compared to just letting the browser render an img tag. They inevitably fail on some bad multitouch interaction that affects the web page, and the image viewer container. Or they add some slow-as-molasses zooming effect.
The great things about all these crypto libraries are:
- Minimal to no dependencies
- Coded by security conscious people
- Often externally audited
I wish more libs/deps are crafted like them. Until then the risk of rolling your own vs using a dep isn’t as different as it could be.
One other possible title of this article could just be, don’t break UI conventions. Which is not the same thing.
Instead of trying to download and configure a date time thing (for something app specific like domain specific date ranges) rather than having to rely on the configuration of a larger library, then having to manage all future major version upgrades (and some of these npm libraries have major versions every year!) why not just create your own smaller surface area component? It’ll be literally zero maintenance compared to managing an npm dependency in your app.
Many eyes are supposed to make bugs shallow. In the webdev space, many eyes on something like React lead to numerous opinionated alternatives, each successful enough to warrant consideration. This doesn’t seem to be slowing down, either.
Meanwhile, vanilla HTML and DOM capabilities have never been stronger.
all providers only document their bloat-spyware-buggy javascript that creates a button and handles all in the client.
then using libraries you are open to attacks in one hundred ways because those implement all the unrealistic things in the spec (including overriding issuer and setting crypto to nothing, via attacker controlled fields). after two days of evaluating i just gave up and wrote my own, server side and handling the singular case everyone uses. 20 lines, which was less then adopting the libraries.
Unfortunately, it’s 1) difficult to reach consensus 2) difficult to broadcast and 3) difficult to enforce. For example, even when major browsers achieve 1) and (e.g. implement a standard component) 2) and 3) are still huge gaps.
agreed, that page decided they needed to write their own scrolling logic and it made the page horrible.
Whatever you do don't teach AI how to do this or there could be a flood of VPN's speaking new but not really new ciphers that code breaking farms won't know what to do with and ciphers that are not known to exist and yet nobody ever really rolled their own.
This concept was conceived whilst interacting with Rubix cube players.
However, scrollbars, context menus, modal windows, and date pickers are rendered within the extents of the web page, and get replaced all the time.
It is my opinion that these controls don't need to be styled to match the website, because they're not part of the website. They're part of the browser. Non-diegetic. Outside the fourth wall.
Javascript in the browser was a mistake. And if we had to have it, the suitable scope of it was what we had around 2004.
Google invested tens of billions in it realizing they had a way of owning the browser space simply by making it insanely complex. Just hire all of the web standards people, tell them to go crazy and then also hire thousands of C++ browser developers for decades to implement everything. Boom, a moat!
You can do terrible things with JS but you can do great things too.
There are too many words in that sentence. Here are the words that can be removed: "browser", "in" and "the".
No, that's how you end up with a mountain of bad half-assed implementations. You should only roll your own when truly necessary, and only after thoroughly understanding the problem and the existing mature solutions and honestly comparing that against your own ideas to see if you're missing important aspects of the problem.
And even after doing all that, when it comes to implementing custom UI for something that already has a standard approach, you should still usually throw away your custom version because it won't be better by a wide enough margin to justify the effort users will need to invest in re-learning and breaking their existing habits.
Save your UI experimentation for your personal tools, and don't inflict it on innocent users.
For those not trying to implement the dark patterns that enshittify the web.
If you don't roll your own back button behavior, you've missed the opportunity to show a few more ads.
If you don't make your window full screen on my shitty old tablet browser (yes, I'm looking at you, BBC), then it's far too easy for me to close your window. (Joke's on you, though -- my old Samsung tablet has a physical back button.)
