One thing that happens when you learn to build web things using React before learning html, is that you don't care about links.
When I joined my team, all links were buttons, random elements, or <a> with onClick. Nobody complained, but that meant ctrl click was useless, right click did not give you the options you wanted.
This is the only thing I'm a dictator about. There is zero room for negotiation when it comes to links.
I also hate this. More and more of this JS nonsense is coming along and abusing the correct way of doing things.
There is a documentation platform called archbee (its even funded by YC) where if you run a search you cant open the search results in new tabs, you have to open one result in the current tab, and if its not what you want, you have to go back, search again and open the next result. This is incredibly infuriating.
The new reddit web version has all the links as buttons. You cannot open these links in a new tab. It drives me crazy and really strange that such a huge internet giant gas such glaring accessibility issues.
New Reddit also messes with text selection with unnecessary JS crap. Wherever you select some text, they show an "Embed" button that prevents you from dragging the text to a new tab to perform a web search.
Thankfully this behaviour can be blocked with uBlock Origin by adding these rules:
The worst thing: i.redd.it no longer returns the image alone, but wraps it in a "viewer" page. I can’t even write an uBlock filter for this, because it relies on an Accept HTTP header.
Imgur does the same, but that at least can be remedied by stripping the Referer header. I wonder how long this will last.
I predict Sec-Fetch-* will be abused for the same purpose. It may be already.
This is probably 50% of the reason I use nitter instead of twitter. Aside from not having to have an account, it lets me right click to open tweet threads in a new tab. Which, given the nature of twitter conversations, seems like pretty key behavior! I want to be able to view conversational threads, but I also want to keep my place in the original page so that I can keep opening new threads! It's really not that hard and the actual twitter UI makes it very difficult (although you can get around it with some browser tweaks, but it's still more annoying than a simple right click)
Ugh. Yes. Bane of my web existence: a site will have a list view and a detail view. Can’t right click (or use extensions) to open one item in its detail view.
Even then, it would almost be forgivable if going back to list view (via their button or the browser button) were instant and seamless, but…
It never is! Going back means waiting for all the content to reload again and losing my position.
Why do you designers keep allowing this?
Edit: and for the final kick in the balls, some websites force all tabs to be the same in some respect! Like, Facebook makes it (or at least did one time) so that you have to have the same chats popped up in every tab. If you close one in one tab, it closes in all other tabs. Why?! There’s a reason I have multiple tabs open!
I'm the same way. If someone is committing code that violates web standards it is not going in unless there's a thorough discussion and an excellent reason for doing so. Lean on the web.
Oh, you and the OP are both making me happy. Plenty of people seem to use nothing but DIV, SPAN, and maybe A or BUTTON. You don’t have to use all the semantic richness of HTML, but damn, at least treat links right. The <a onclick> pattern is awful.
Since we're on the topic of how people should learn to build web things: what do you think are the most important things to learn first to make web stuff? The "right" way? Just raw HTML, CSS, and some JavaScript (Typescript?)? It seems common among programmers to criticize the overuse of web frameworks. Are there a lot of people who learn only web frameworks?
> what do you think are the most important things to learn first to make web stuff? The "right" way? Just raw HTML, CSS, and some JavaScript (Typescript?)?
Yes. I think all web programmers need to know HTML and CSS. CSS is still just as relevant no matter how you build websites. People should also spend time learning HTML. Like, learn how to make content using raw HTML. Read the HTML of some of your favorite sites. This will improve everything you do with react and friends.
> Are there a lot of people who learn only web frameworks?
Yes.
Web programming probably has more programming beginners than any other area of software development. Its easy to learn - there are no C pointers in sight and no manual memory management. Websites work everywhere. And everyone needs a website - so there's lots of demand for web programmers. The debugging tools are also great (and you already have them if you have chrome installed). And frontend engineering is visual and obvious - so when you mess it up, you can usually tell.
So, yes. There's lots of people who learn just enough to scrape by and start making websites. Its great and terrible. I'm glad web programming is such an on-ramp for beginners. But npm is a disaster, and lots of websites are insecure, slow, amateurish messes.
It can be written by hand but that's way too verbose. Pug is a great solution to that problem: it's just HTML but much less verbose. I integrated it with GitHub Pages so pug sources get compiled to HTML and published when commits are pushed. Great experience.
> Are there a lot of people who learn only web frameworks?
Yes, because many people learn web development through bootcamps or other such courses (modern web dev is not usually taught in college, in my experience) which rush you to "job readiness" thus incentivizing using React over vanilla JS since most web dev jobs use React nowadays.
I think it's still a good idea to learn by writing HTML pages, then adding a style and script tag in the head. The scripts and styles become enhancements to the page.
If you go to a code bootcamp, you are learning react. A lot of new developers come from these places. Not a bad thing, but they could spend more time on fundamentals
Set the proper goals. The end state is some software product, such as a website. Far too common beginners will attempt to redefine the goal to something more familiar, something like "how to write code". There are people who spend their entire careers mastering exactly how to write the code. This can be described as "expert beginners".
Somebody needs to be the adult in the room and stop the children from running the daycare. As developers we should already know how to write code, or know how to figure it out, and that shouldn't be open to discussion. The discussion must only be upon defining the goals and stepping backwards one step at a time. This is called planning and proper planning will ensure the necessary automated checks are in place. Then "how to write the code" becomes straight forward as it either conforms to the automated checks or becomes a matter for discussion.
I don't think vanilla HTML/CSS/JS is the way to go for beginners because of the "time to visually interesting results" problem. Starting with a framework that has widgets you can reuse is much more interesting and motivating.
That said, I'd argue that the selected framework should be one that doesn't completely obscure all the underlying HTML/CSS/JS (I'd avoid TypeScript at first) from them so it's easy to learn that when needed, plus it makes debugging using browser dev tools easier and means they'll have transferable skills for learning a second framework.
GWT (RIP, thank goodness) would be the extreme negative example, but React is on that side of the spectrum as well.
Vue, Svelte, Lit, and Angular seem to be the most popular frameworks on the "closer to HTML/CSS/JS" side of the spectrum, though I only have experience with the last two. Lit's great; Angular's not my favorite.
I'm not professional web developer, but I started raw, then expanded with JQuery, then much later tried some frameworks. I think it's important the understand the underlying core HTML/CSS/JS since EVERYTHING ELSE is ultimately abstracting and/or transpiling down to those raw ingredients. But I'm more of a bottom up type of person, so YMMV.
Now, for proper web principles and design methodologies, I'd love for some tips there.
The link and the URL are what made hypertext hyper. They turned words in a document into portals to other documents.
But that web isn’t the one we’re dealing with anymore. We’ve moved from documents to applications. Like tabindex, I’m sure browsers or frameworks will gradually find ways to make any element behave link-like in every way. Which isn’t really a bad thing, it’s just development of the core idea of the web.
Would be better if browsers adjusted so as to deliberately break React and its brethren instead instead of fixing the mess they made. The web used to work great, now look at what it's become. People can't even put a link in the document properly.
I’ve run into this, but it is coming from the UX designer for the product. There is an organization component library, with a corresponding figma library. They insist on using the button component instead of the link component.
Most react component libraries correctly return <a> tags for <Button /> components with an href property, while still styling them as buttons. This preserves the expected link behaviors while satisfying the design obsession with buttons over traditional links.
Specifying button-looking elements for regular navigation actions is definitely wrong, and nearly all UX and UI designers will understand that.
If it triggers an action with consequences, or even navigates users to a single-purpose page where they can select options or confirm the action-- e.g. 'cancel subscription now' or similar-- then it probably should look like a button.
Well you say this now, for nearly a decade no one gives a crap about Web as in HTML, it is all about JS Front End. The current resurgent and support of HTML is relatively new on HN. Other than the very few vocal ones about how the Web should not be an "App". But an interactive web page.
I still wish they should merge 90% if not 100% of HTMX into official HTML 5 spec.
To me this sounds hyper immature. It sounds like you don't really know what you are doing as a technician and instead you are checking whatever box whatever employer at the time tells you to check. Then when confronted with the reality that your output is clearly wrong you instead shift blame to something about tools, because diddling the tools is all you really know what to do.
Is it possible the absence of "links" is unintentional.
As a web user, this sort of "design" has made me focus as a practical matter more on HTTP (requests) instead of HTML (links). It's easy for me to make the links myself once I know where the requests need to go.
It's easy to take JSON and make own HTML. No Javascript needed.
It would be nice if the JavaScript APIs made it easier to do that. Like, obviously you can wrap an element in a <a> tag, but its just enough of a hassle that people don't. Seems like a good API could fix a lot of sites
In my experience, people were abusing links and making everything a button without React. The actual defining attribute - IMO - is that they didn't care about web semantics.
This is one of the first things I changed at a new job. I just opened a PR and made the change without asking anyone. It infriuriates me when apps can't Ctrl+click.
Same boat. My blood pressure increased just reading your comment. The web is run by a bunch of amateurs who don’t know the single core concept of the web: links.
The way I think about it is that you assume a level of responsibility whenever you tinker with default affordances. Your "feature" isn't restricted to whatever narrow conception or intention you had when you designed it. It consists in the totality of a visitor's actual experience.
If I change the logic of the the back button, I'm changing what the back button affords on this particular website and become responsible for whatever happens as a result.
That includes confused and frustrated users saying "Screw you and your broken website."
Or take, e.g., the way scrollbars work, which can be very browser-and-OS-specific. Are you sure you want to assume responsibility for that? How sensitive are you to the downside, really?
Essentially, you're making your website speak a kind of creole. You've forgone any right to be upset if your visitors don't speak it and shouldn't be surprised if they persist in "misinterpreting" it.
Forget about avoiding such "features" because you want to be nice to your visitors. It always seemed to me they offer limited upside and unlimited downside.
Yep, this is exactly right. Websites benefit from design idioms that have been carefully crafted over many years. Every website that disregards these idioms makes itself harder to use because it doesn’t speak the same language as what the user is (perhaps without noticing) used to. I wrote about the loss of design idioms at length: https://loeber.substack.com/p/4-bring-back-idiomatic-design
I think of this as the "appification of websites", we need to stop doing it. We need to move back to SSR and sprinkles of JS on websites.
On the other hand web apps absolutely can play a little more with the UX if it provides value to the user. But if it's in the browser, some of this really do still apply. I'm all in on web apps, its a universally accessible platform for development outside the walled gardens of app stores.
What we need to stop doing is treating every single website as an app!
If you want your page to appear in search results on a search engine, it's not a web app it's a website.
If Gemini had picked markdown instead of gemtext I would've jumped in with both feet.
I get it though -- they're trying to resurrect gopher, which is what gemtext is a modernification of.
Still, I think markdown is our best shot at recovering the real web.
And yes, I know there's a standardization problem. Just pick a standard and run with it. Difficulty picking one is not a reason to pick none. And in case it wasn't obvious I'm talking about markdown without embedded html here.
Why bank websites remove the ability to paste? You have already copied the text when you realize you cannot paste. So what is the point? Writing things by hand are prone to errors and if your clipboard is poisoned you have already copied the stuff by the time you realize you cannot paste…
I always imagine there is an "intro to forms programming" which includes code to disable copy and paste, and its concepts now have thousands of descendants across the web, to the point that people start imagining it's a security measure and proactively copy it. I agree w/you and don't see the point in stopping users from pasting in the first place.
I don't think it specifically violates any accessibility regulations, but preventing pasting has always come across to me as an accessibility violation.
Not only does my bank's website not allow me to paste my "password", it doesn't allow me to type it at all. It's insane. Said "password" is just a 6 digit number (we're not allowed to set our own passwords, because 6 digits is definitely way more secure than the 16 character random strings my password manager generates) and it forces me to enter it using buttons on the page itself with randomized positions. No idea how any of this is supposed to help with security, if my device is already compromised to the point that all my keypresses and clicks are being logged, the attacker can probably also just read the password from the browser's memory...
But, how exactly does being able to install a keylogger on someone's computer mean you can also break memory integrity and steal data from the browser's memory?
From what I know, windows keylogger "services" were very popular some 10 years ago and hence the banks rushing to "fix" it.
I hate this so much, was registering for a new ISP the other day, they blocked paste in the password inputs and broke my password manger. Such an incredible bad decision from a security perspective.
Usually it starts with a company having issues with robot traffic. So they try a bunch of things to hinder the robot(s). They do something, the robot stops working, but after a while it comes back, it's a cat and mouse game essentially.
One day, they (developers pushed by middle managers) disable copy-paste on the login page, and the robot temporary stops working, until a couple of days later, when the robot found a way around it.
On to the next thing to do to stop the robot, but that previous "fix" is still there, with the thinking that "maybe that stops some of the robots", but it probably doesn't.
But there it sits, some ~10-ish lines of JS that will hang around until rewrite v6 when they'll begin from the beginning, and some months/years later come around to disabling it once again.
You can't win; you're going to get robot traffic unless everybody does something like Web Environment Integrity. Seriously.
Just allocate your finite resources in a hierarchical 32-level binary tree based on bit prefixes of the client IP address. Exactly what the root DNS servers do. And exactly what the only mitigation for slowloris attacks does. Then get on with your life.
Not saying this is the case, but there was malware that would check to see if you had copied what looked to be a bitcoin account and replaced it with its own.
Yeah I also hate this but they have a point. Desktop clipboard is a shitshow. Any app can read it willy nilly, certainly if focused but I wouldn’t be surprised if it works in the background on some platforms.
It is one of the prime candidates for a global redesign from scratch, including even physical keys (since copy-paste is so common, certainly more than say caps lock). All the APIs are riddled with decades of tech debt and are entirely platform-specific.
Reminds me of treasurydirect.gov which presents you with a virtual keyboard and you have to click to type out your (case insensitive) password. It is insane
Of course a long, random, unique password from a password manager is best for security, everyone knows that.
So forcing people to instead use a short, easy-to-type, memorable password clearly couldn't possibly be anything else but an attempt to undermine the user's security and put their account at increased risk. That bank does not have your best interests in mind. With that in mind, it doesn't matter why they don't.
So switch to another bank (or better yet, a credit union) that does.
The banks protect you from malicious clipboard manipulation by manipulating the clipboard content ("we let you paste but complete some digits manually") and/or entirely disabling pasting text into text fields. Yes, they employ at least one "security expert" who will elaborately explain you why it's better for your security.
What gets me is when fancy-pants JS devs disguise complexity and features nobody has asked for behind native html looking controls like select menus.
I see this most often with the city and state inputs, where city is a text input and state is a drop-down/select menu.
As a Texan, I will type my city, tab to the State select menu and type "t" followed by another "t" then tab to the next form element.
But what I'm seeing lately is a text input (search field) dressed up like a drop-down menu... So my t , t input results in a text search for a literal "tt" instead of selecting Tennessee then Texas. It's so aggravating.
Now if someone chooses to click the triangle in the drop-down menu, and scroll through the states, the element would work as expected... If you only wanted to interact with the element with you mouse.
This is (was) largely a problem caused by holes in the web platform. Historically it was incredibly hard (if not impossible) to style or otherwise extend the behavior of a true <select>, so most apps had to reimplement it (poorly). <selectmenu> seems to be the new styleable built-in replacement.
And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>.
I believe most of the issues with broken link behaviour results from the lack of higher-level methods to override the default link behaviour.
An example: I don't really want to add a click event listener to a link to make it display in a modal (or whatever). Because this event is too low-level and now my listener needs to check modifier keys. What I really want is to somehow tell the browser "if the current window URL is about to change via this anchor element, call this function instead". The user is still free to open their links in new windows or tabs and my code will not be triggered for those cases.
A CSS example: I don't really want to set cursor images for every element and pseudo-class. I'm forced to list every element that uses the cursor I'm overriding. What I really want is to tell the browser "use this custom cursor image wherever you were going to use the default (hand/wait/resize/etc) cursor". My code would then be future-proofed for new elements/UI.
Sometimes I feel that certain browser APIs suffer from the XY problem.
> What I really want is to somehow tell the browser "if the current window URL is about to change via this anchor element, call this function instead".
This is pretty doable using javascript - just register an onclick on the <a> tag and have your event handler cancel the default navigation behaviour. Your website will then continue to work great even if the user has javascript disabled. And all the built in browser behaviour (like the right click "link" menu, and ctrl+click) still works perfectly.
That said, this is a pretty obscure "trick". It would certainly be nice if the DOM API made this easier to do.
Is there really anything easier to do? If you're disabling the default event, you're doing it to provide some other functionality, which is necessarily going to involve writing a function to attach to a handler, and adding event.preventDefault() at the top is about as easy as it gets. Anything easier would involve eliminating the attached handler, which doesn't make a lot of sense.
Also, .preventDefault() wasn't obscure in the jQuery era; if it's obscure now that's a sad commentary.
In my experience in this case you need to explicitly filter out middle-click, ctrl-click, cmd-click and whatever other features the browser may offer. Otherwise you will accidentally prevent them too. I would love if there was a more specific event that avoided this problem.
I remember the first time when I looked at the Flutter Gallery and was surprised at how things felt just broken in a web browser, for example: https://gallery.flutter.dev (I think it was the Reply example in particular)
Ctrl + click or middle mouse button didn't work on links, right click didn't work, selecting and copying text didn't work, inspect element didn't work (due to how the technology is built), even attempting to zoom the page did nothing.
This article does ring true both because of that experience, as well as some of the SPA implementations I've seen even with more conventional technologies.
It also seems to be doing something weird with text selection, at least on mobile browsers. But I guess the promise of flutter is it’s the same everywhere so this demo should be equally bad on desktop.
Another thing I'd like to add: don't override the scrolling behavior. Don't try to "improve" the scrolling by making it "smoother", because while it may work okay on Windows, on Mac, when using Apple input devices, there's a one-to-one correspondence between you moving your fingers on the trackpad or mouse and scrollable things scrolling. These "improvements" usually feel like scrolling through molasses.
In general, don't try to improve browser's default behavior.
Readit News
When I joined my team, all links were buttons, random elements, or <a> with onClick. Nobody complained, but that meant ctrl click was useless, right click did not give you the options you wanted.
This is the only thing I'm a dictator about. There is zero room for negotiation when it comes to links.
There is a documentation platform called archbee (its even funded by YC) where if you run a search you cant open the search results in new tabs, you have to open one result in the current tab, and if its not what you want, you have to go back, search again and open the next result. This is incredibly infuriating.
You can see this behaviour here for example: https://docs.sparklayer.io/
There's no such thing as this.
Thankfully this behaviour can be blocked with uBlock Origin by adding these rules:
Imgur does the same, but that at least can be remedied by stripping the Referer header. I wonder how long this will last.
I predict Sec-Fetch-* will be abused for the same purpose. It may be already.
Deleted Comment
Deleted Comment
This is a hill I'm always willing to die on. Few things bother me more. Maybe fucking with my browser history...
Whenever I push for things that are technically correct I'm ignored and/or not treated well it seems.
Even then, it would almost be forgivable if going back to list view (via their button or the browser button) were instant and seamless, but…
It never is! Going back means waiting for all the content to reload again and losing my position.
Why do you designers keep allowing this?
Edit: and for the final kick in the balls, some websites force all tabs to be the same in some respect! Like, Facebook makes it (or at least did one time) so that you have to have the same chats popped up in every tab. If you close one in one tab, it closes in all other tabs. Why?! There’s a reason I have multiple tabs open!
Yes. I think all web programmers need to know HTML and CSS. CSS is still just as relevant no matter how you build websites. People should also spend time learning HTML. Like, learn how to make content using raw HTML. Read the HTML of some of your favorite sites. This will improve everything you do with react and friends.
> Are there a lot of people who learn only web frameworks?
Yes.
Web programming probably has more programming beginners than any other area of software development. Its easy to learn - there are no C pointers in sight and no manual memory management. Websites work everywhere. And everyone needs a website - so there's lots of demand for web programmers. The debugging tools are also great (and you already have them if you have chrome installed). And frontend engineering is visual and obvious - so when you mess it up, you can usually tell.
So, yes. There's lots of people who learn just enough to scrape by and start making websites. Its great and terrible. I'm glad web programming is such an on-ramp for beginners. But npm is a disaster, and lots of websites are insecure, slow, amateurish messes.
https://motherfuckingwebsite.com/
Really. At this point this is what websites should strive to be. Text on the screen.
Everything about HTML can be learned from the MDN documentation:
https://developer.mozilla.org/en-US/docs/Web/HTML
It can be written by hand but that's way too verbose. Pug is a great solution to that problem: it's just HTML but much less verbose. I integrated it with GitHub Pages so pug sources get compiled to HTML and published when commits are pushed. Great experience.
https://pugjs.org/
https://github.com/pugjs/pug
After this, the next step is to learn CSS so you can make it look a little nicer.
https://developer.mozilla.org/en-US/docs/Web/CSS
Javascript should only be necessary if you want to do something like this:
https://ciechanow.ski/mechanical-watch/
Yes, because many people learn web development through bootcamps or other such courses (modern web dev is not usually taught in college, in my experience) which rush you to "job readiness" thus incentivizing using React over vanilla JS since most web dev jobs use React nowadays.
If you go to a code bootcamp, you are learning react. A lot of new developers come from these places. Not a bad thing, but they could spend more time on fundamentals
Somebody needs to be the adult in the room and stop the children from running the daycare. As developers we should already know how to write code, or know how to figure it out, and that shouldn't be open to discussion. The discussion must only be upon defining the goals and stepping backwards one step at a time. This is called planning and proper planning will ensure the necessary automated checks are in place. Then "how to write the code" becomes straight forward as it either conforms to the automated checks or becomes a matter for discussion.
That said, I'd argue that the selected framework should be one that doesn't completely obscure all the underlying HTML/CSS/JS (I'd avoid TypeScript at first) from them so it's easy to learn that when needed, plus it makes debugging using browser dev tools easier and means they'll have transferable skills for learning a second framework.
GWT (RIP, thank goodness) would be the extreme negative example, but React is on that side of the spectrum as well.
Vue, Svelte, Lit, and Angular seem to be the most popular frameworks on the "closer to HTML/CSS/JS" side of the spectrum, though I only have experience with the last two. Lit's great; Angular's not my favorite.
Now, for proper web principles and design methodologies, I'd love for some tips there.
But that web isn’t the one we’re dealing with anymore. We’ve moved from documents to applications. Like tabindex, I’m sure browsers or frameworks will gradually find ways to make any element behave link-like in every way. Which isn’t really a bad thing, it’s just development of the core idea of the web.
For instance if a user ctr + cliks a button, have the navigation happen in a tab window even if the URL change is pushed by a JS module down the line.
You need a href for the browser to know where to navigate to.
Just use RouterLink.
It uses a native anchor tag. If you click (without Ctrl/cmd) it prevents default and does the navigation without reload.
If it triggers an action with consequences, or even navigates users to a single-purpose page where they can select options or confirm the action-- e.g. 'cancel subscription now' or similar-- then it probably should look like a button.
I still wish they should merge 90% if not 100% of HTMX into official HTML 5 spec.
As a web user, this sort of "design" has made me focus as a practical matter more on HTTP (requests) instead of HTML (links). It's easy for me to make the links myself once I know where the requests need to go.
It's easy to take JSON and make own HTML. No Javascript needed.
Maybe if you're doing like a painting app or something you don't need to.
Deleted Comment
The way I think about it is that you assume a level of responsibility whenever you tinker with default affordances. Your "feature" isn't restricted to whatever narrow conception or intention you had when you designed it. It consists in the totality of a visitor's actual experience.
If I change the logic of the the back button, I'm changing what the back button affords on this particular website and become responsible for whatever happens as a result.
That includes confused and frustrated users saying "Screw you and your broken website."
Or take, e.g., the way scrollbars work, which can be very browser-and-OS-specific. Are you sure you want to assume responsibility for that? How sensitive are you to the downside, really?
Essentially, you're making your website speak a kind of creole. You've forgone any right to be upset if your visitors don't speak it and shouldn't be surprised if they persist in "misinterpreting" it.
Forget about avoiding such "features" because you want to be nice to your visitors. It always seemed to me they offer limited upside and unlimited downside.
On the other hand web apps absolutely can play a little more with the UX if it provides value to the user. But if it's in the browser, some of this really do still apply. I'm all in on web apps, its a universally accessible platform for development outside the walled gardens of app stores.
What we need to stop doing is treating every single website as an app!
If you want your page to appear in search results on a search engine, it's not a web app it's a website.
I get it though -- they're trying to resurrect gopher, which is what gemtext is a modernification of.
Still, I think markdown is our best shot at recovering the real web.
And yes, I know there's a standardization problem. Just pick a standard and run with it. Difficulty picking one is not a reason to pick none. And in case it wasn't obvious I'm talking about markdown without embedded html here.
But that text/markdown would have to be restricted not to include any html tags, which are allowed in the "common" md spec.
Fortunately with stuff like React Server Components, looks like we are moving back to sprinkling JS for websites, which I'm a big fan of.
But, how exactly does being able to install a keylogger on someone's computer mean you can also break memory integrity and steal data from the browser's memory?
From what I know, windows keylogger "services" were very popular some 10 years ago and hence the banks rushing to "fix" it.
One day, they (developers pushed by middle managers) disable copy-paste on the login page, and the robot temporary stops working, until a couple of days later, when the robot found a way around it.
On to the next thing to do to stop the robot, but that previous "fix" is still there, with the thinking that "maybe that stops some of the robots", but it probably doesn't.
But there it sits, some ~10-ish lines of JS that will hang around until rewrite v6 when they'll begin from the beginning, and some months/years later come around to disabling it once again.
No, I'm absolutely not speaking from experience.
You can't win; you're going to get robot traffic unless everybody does something like Web Environment Integrity. Seriously.
Just allocate your finite resources in a hierarchical 32-level binary tree based on bit prefixes of the client IP address. Exactly what the root DNS servers do. And exactly what the only mitigation for slowloris attacks does. Then get on with your life.
https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
Something like that maybe?
It is one of the prime candidates for a global redesign from scratch, including even physical keys (since copy-paste is so common, certainly more than say caps lock). All the APIs are riddled with decades of tech debt and are entirely platform-specific.
Of course a long, random, unique password from a password manager is best for security, everyone knows that.
So forcing people to instead use a short, easy-to-type, memorable password clearly couldn't possibly be anything else but an attempt to undermine the user's security and put their account at increased risk. That bank does not have your best interests in mind. With that in mind, it doesn't matter why they don't.
So switch to another bank (or better yet, a credit union) that does.
I see this most often with the city and state inputs, where city is a text input and state is a drop-down/select menu.
As a Texan, I will type my city, tab to the State select menu and type "t" followed by another "t" then tab to the next form element.
But what I'm seeing lately is a text input (search field) dressed up like a drop-down menu... So my t , t input results in a text search for a literal "tt" instead of selecting Tennessee then Texas. It's so aggravating.
Now if someone chooses to click the triangle in the drop-down menu, and scroll through the states, the element would work as expected... If you only wanted to interact with the element with you mouse.
If it ain't broke, don't fix it.
And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>.
Related: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...
An example: I don't really want to add a click event listener to a link to make it display in a modal (or whatever). Because this event is too low-level and now my listener needs to check modifier keys. What I really want is to somehow tell the browser "if the current window URL is about to change via this anchor element, call this function instead". The user is still free to open their links in new windows or tabs and my code will not be triggered for those cases.
A CSS example: I don't really want to set cursor images for every element and pseudo-class. I'm forced to list every element that uses the cursor I'm overriding. What I really want is to tell the browser "use this custom cursor image wherever you were going to use the default (hand/wait/resize/etc) cursor". My code would then be future-proofed for new elements/UI.
Sometimes I feel that certain browser APIs suffer from the XY problem.
This is pretty doable using javascript - just register an onclick on the <a> tag and have your event handler cancel the default navigation behaviour. Your website will then continue to work great even if the user has javascript disabled. And all the built in browser behaviour (like the right click "link" menu, and ctrl+click) still works perfectly.
That said, this is a pretty obscure "trick". It would certainly be nice if the DOM API made this easier to do.
Also, .preventDefault() wasn't obscure in the jQuery era; if it's obscure now that's a sad commentary.
I believe that’s the use case for the Navigation API.
Ctrl + click or middle mouse button didn't work on links, right click didn't work, selecting and copying text didn't work, inspect element didn't work (due to how the technology is built), even attempting to zoom the page did nothing.
This article does ring true both because of that experience, as well as some of the SPA implementations I've seen even with more conventional technologies.
I haven't once been convinced by any flutter demo, web or mobile, that feels like it has even passably good UX.
In general, don't try to improve browser's default behavior.