And the mobile brother of that, the “half the things you do are now a slide-up-from-the-bottom modal, which has its own stack, so you get confused and accidentally go back irreversibly many levels when you inadvertently close it.”
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.
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.
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.
Aw man, now I’m sad because that means that’s the next thing Apple will nerf out of existence. I like my clipboard manager and I haven’t ever downloaded malware onto my Mac despite rarely using their crappy App Store. :(
Stage 1: Everything is totally trusting.
Viruses exist, and scanners exist to help you not download anything stupid.
Stage 2: Locked ecosystems like iOS App Store, Platform Vendor claims their 100% diligence will protect you (and them) from all possible bad (or insufficiently-profitable) software.
Apparently they weren’t satisfied
Stage 3: Full Sandboxing and full enforcement of Platform Vendor’s blessed software source only.
Now my computer, like my phone, will only ever have the exact, enumerated features the Platform Vendor blesses me with and I will like it or else. I am free to file a feedback on their website if I’d like a clipboard manager, and they may one day look at that feedback.
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...
Polish ING modifies IBAN on pasting it during bank transfer and forces to enter manually first two digits "for your security". They also disable IBAN selection in transfer summary view, so one cannot copy it and double check before confirming the transfer. ING seems to deploy the most arbitrary "security" measures found on most random blog posts and sprouted during the most brain-dead brainstorming meetings.
Forcing you to manually type the first two digits makes sense to me. If a hacker is able to modify clipboard text, you manually inputting the first two digits should trip up the IBAN checksum.
Whatever are the motivations and reasoning, bank is doing exactly what the bad actors are doing. They modify the text during the copy and paste workflow.
It's only the same thing if you look from a very shallow angle. Stripping part of the user input to ensure it's entered by the person themselves is otherwise completely different from replacing user input with different data. One defends against a specific kind of attack, the other is a malicious attack.
How often to you write random text into the IBAN field of your bank? Never, because it's an identification number? What a coincidence.
I mean, just think this two steps further. Hackers change input, and banks change input, so hackers == banks? But hackers also change what is displayed on the screen, and password fields change what is displayed on the screen, so hackers == password fields? Pressing my mouse button on the "reply" button changes what is displayed, so hackers == my mouse?
No, my premise is very straightforward. Do not modify the text during the copy and paste workflow. Copy and paste workflow is well defined and established concept by now. That bad actors are doing it doesn't mean you should. No point in exaggerating my premise and ridiculing me.
> No, my premise is very straightforward. Do not modify the text during the copy and paste workflow.
That's not the premise you stated earlier. That was: "Banks and hackers do the same thing by modifying the text during the copy and paste workflow", which completely ignores what kinds of modifications are happening.
> Copy and paste workflow is well defined and established concept by now. That bad actors are doing it doesn't mean you should.
See? You're doing it again. Banks are not doing what "bad actors are doing". Banks are doing something else.
> No point in exaggerating my premise and ridiculing me.
I am not exaggerating your premise and ridiculing you, I'm continuing your logic to show its' flawed premise. You stated that "banks and hackers are doing the same thing", and the reason it's the same is due to the literal operation being the same. Why can't I extend this logically to other operations that are the same? A password field changes what is displayed compared to my input, how is that different from a hacker changing what is displayed compared to my input?
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.
> 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?
On Windows at least, any process can read any other process' memory as long as it's running under the same user.
Also, keyloggers don’t have to be in software (for a desktop, I suppose). You can buy one that simply plugs in between keyboard and computer. In this way, I can sympathize with the onscreen idea, however it’s criminal to not at least include a password field that is detectable by all password managers so that it “just works” for them.
(And also criminal to have a password max, short of like 1MB — even then the only reason for the limit is to slightly reduce the harm of some kind of weird DDOS against your login endpoint - whenever I see a password max I always assume this site is so dumbly implemented that they aren’t hashing my password but storing it in plaintext or reversible encrypting it.)
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.
Honestly, robot traffic seems like an issue just because websites are horrendously inefficient. Hundreds of round-trips to external servers, languages that require some orders of magnitude more resources than needed... It shouldn't be so expensive to just serve a page, even considering robots
> Hundreds of round-trips to external servers, languages that require some orders of magnitude more resources than needed... It shouldn't be so expensive to just serve a page, even considering robots
This is not a priority. The features are implemented by more abstraction, ie. TypeScript and web frameworks. Industry's low barrier to entry promotes studying frameworks, not technologies and standards enabling them. Anti-robot measures mostly prevent automated fraud and are there to ensure the ads are displayed, if the whole process will freeze your browser and eat your entire RAM they are fine with it.
You’re right on that part but I think it isn’t so much the server resources but the actual things the bots may be doing. For example making a ton of bot accounts to spread propaganda, or 10,000 “trial accounts” to host untraceable phishing/scam pages, etc. Or for example, an e-commerce site that doesn’t want to be automated into service as a card tester for stolen credit cards with thousands of fraudulent orders.
Idk what you are saying, are you suggesting if I operate a webstore I should let bots place thousands of fraud orders frequently, and eat all those chargeback fees? And… law enforcement? Call the cops every time that happens? At least in my country, the police would say “uhh, ok feel free to file a report,” but they will do zero to investigate it. Which actually makes sense since most of those doing this crime are operating overseas, out of their jurisdiction anyway.
Also, if someone is registering 10,000 accounts that are obviously not real people, I should let them?
First of all, my website, my free speech. I’m free to publish or delete anything on it.
Second, bulk-created fake accounts aren’t needed even for legitimate political speech. That’s more like extreme astroturfing.
That's exactly what developers will tell middle-managers but it won't matter unless you're in a organization that actually value their developer's opinion.
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.
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
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.
I'm aware of 5 operations that a standard link should support:
- Left-click (obvious)
- Right-click (context menu)
- Middle-click (open in new tab)
- Ctrl-click (open in new tab)
- Shift-click (open in new window)
Most sites support at least one of right/middle/ctrl-click, though sometimes you have to Duplicate the tab and then left-click. If none work, and duplicating the tab loses context, it's probably time to abandon hope and find another website.
Note: if at all possible, don’t implement these yourself! You’ll very probably do it wrong for at least some users. For example, ctrl-click for new tab is platform specific: on macOS it should be cmd-click, and ctrl-click should open a context menu. Most if not all are or can be user-configurable, which might not be detected by JS. But the default behaviors will do the right thing unless you override them.
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.
This blog doesn’t touch on the actual issue at hand: businesses make business decisions, not engineering decisions. It’s easy to enumerate a bunch of technical asks and then blame their absence on technical reasons, because it doesn’t require any exploration of the business details. It stays in a nice, safe realm.
To be clear, I personally agree with, and want every single item listed in this blog. I’m a big nerd. But I also recognize that I’m nowhere near anything resembling a typical user. What I want is probably not even on the radar of 99% of users of these websites.
It’s easy to say, “I want X and having X would make me a happier user.” The real question is, “is implementing X an appropriate expenditure of resources if the goal is to build a profitable business?” Usually not. Most users don’t know or don’t care about X. Be careful with the nerd echo chamber we live in that makes us think these things matter to the common person.
For all of this, one could argue, “yeah but they’re being foolish. Long term this is going to bite them.” You might be right! I think you’re right, too. But that’s a business position, not a technical one.
For many businesses, there's a simple incentive that should make them care: SEO.
Although Google and other search engines have said for more than a decade that their bots can execute javascript and navigate SPAs, the truth is that they are not going to simulate a click on every random element with onClick events attached. In many cases, they will not even execute any javascript.
Even in 2023, <a href="URL"> is the best way to make search engines pay attention.
Popular frontend development patterns have also made it nearly impossible to figure out the semantic structure of a page. Everything is a <div> now. But if you care about how your website looks in a search result, you might still want to designate some parts of the page as <main> or <article> and other parts as <aside> or <nav>. This is especially important if your website contains short user-generated snippets (like tweets) along with a lot of auxiliary information, as semantic tags make it easier for search engines to determine what the main content of each URL is.
In short, many websites would still benefit from enforcing proper semantic markup, like we used to do in the good ol' days of the "no tables for layout" crusade.
Now if the business doesn't care about SEO at all (an increasingly common attitude as websites become app-ified), there's always the atomic option: talk to the legal department about the possible consequences of ignoring accessibility.
Someone those businesses hired sold them on shortcuts that are just bad. Trading UX for production speed isn't a thing. Claiming bad UX is a business decision isn't a thing. Bad UX is bad for business. Sure, some of these concerns aren't as important as others. But generally speaking, the idea that saving time on development at the expense of observing very basic UI conventions is just silly.
> is implementing X an appropriate expenditure of resources
Lot of these things just require devs to not actively try to damage the usability of the defaults. It costs money to break the basics that work for free:
- missing keyboard focus indicator? yeah, dev had to go out of his way to remove it, instead of just doing nothing and focusing on the job/content
- can't paste into inputs? someone had to think about preventing this and implemented it
- ctrl+k / ctrl+f is broken? it works if you just write you page and do nothing extra!
- page is blank for people with JS disabled? someone wasted money on a person who had to learn a whole damn programming language and multi-billion dollar company's framework instead of just html/css
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
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’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.
Button elements and other clickable elements are all detected by accessibility tools as such. If links were the only thing they could click, the modern web would be almost completely unusable, which isn't the case.
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?
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
> 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.
What would a college that aimed to teach Web Development as a specialty actually look like?
People look down on bootcampers, but it always feels to me that 99% of what is taught in university programs is similarly only useful in specialized situations. The actual good thing is having had to sit down and write a lot of code before anyone lets you touch anything.
> 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.
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 don't think vanilla HTML/CSS/JS is the way to go for beginners because of the "time to visually interesting results" problem.
I don't think it's worth beginners learning the road rules and safety protocols, because of the "time to being responsible for a heavy, fast motor-vehicle sharing a road with other people" problem.
I'm surprised to not see NEXT.js mentioned. For anyone comfortable in the React world it pushes a much more classic <a> tag link model throughout the app while still allowing reactive and responsive behaviours.
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.
I think at the bare minimum you should strive to be readable, and you can do that with surprisingly few extra lines of CSS and very basic web design principles (avoid using full black or full white backgrounds). CSS is uhh... a choice, but you don't need to know too much in the very beginning to start building up some motivation of making stuff that looks easy on the eyes.
Yes, and text doesn't need to have maximum contrast (#000 over #FFF) to be legible. The website you linked above says:
> W3C's Web Content Accessibility Guidelines set the minimum contrast between text and its background so that it can be read by people with moderately low vision (which is quite common).
If you follow that link to W3C, you'll see that the minimum contrast for text to be considered legible is 3:1, though that's for people with standard vision (it's the lowest rating). To be truly accessible, the minimum we should strive for is 7:1. Anything above that has a AAA rating.
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'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.
The average modern SPA pulls in far more unnecessary JS than the average plain HTML site pulls in via redundant tag structure following the initial page load. Moreover, server-rendered HTML renders far more quickly because there tends to be fewer total requests and there’s no hiccup parsing the JS when it lands, much less the time it takes to execute it.
I always attempt to die on the links should be links hill. So far the only times I didn’t get my way was when the thing was in fact semantically a button, it just happened to use navigation to achieve its aim. Usually in these cases the markup is too complex to shove into a link anyway.
Happy to report that our production site has more links that look like buttons than it does buttons that act like links. It’s almost a meme on my team that Swiz will get you if you use onClick for navigation.
The other hill I enjoy defending is that we should use more browser built-in components instead of trying to design our own.
Luckily that one doesn’t even come up. “Kids these days” don’t know about it :D
I jest, but I am at least 5 years older than everyone else on the team. And have the unfun background of getting into professional webdev before jQuery.
> browser built-in components instead of trying to design our own.
Ugh. Let me know if you have any tips. All the art-school “UX designers” have to have custom date pickers and stupid knockoffs of iOS switches and custom drop-downs when there are actual, better, and automatically-accessible, versions of all those. How do you fight against this vanity design without making an enemy of the whole design team?
Any artist or designer has to learn their medium before they are allowed to produce designs for it. If you want to learn to sculpt, you have to learn what you can and cannot do with clay; if you want to learn to design clothes, you have to learn about fabrics, sewing and tailoring (Jean Paul Gautier and Versace worked as tailors in the industry while they were doing their early work).
Yet there seems to be a free pass where a "web designer" is allowed to dictate how a site should work and look without knowing the basics of HTML, CSS and JS.
Wait until you get asked, by CTOs and business people, to disable F5/refreshing because it breaks the process flow but building a resilient process flow into an old app takes 10x-100x as long. Only for them to realize if you restart the system, disconnect the network, have a timeout, etc. the problem still exists. They even contemplated physically removing F5 before realizing "wait people can just click refresh or remap F5, that won't work".
Same people will also claim "we don't need a frontend dev or a UX designer".
Watching DOM events on the document and disabling key events for the key code 116. One can still trigger document refresh by remapping F5 to other physical key in OS settings, or by clicking refresh button in browser toolbar.
That seems unnecessarily complex compared to watching for a request to the same webpage, intercepting, and dropping the request. I believe that is all the refresh function is doing.
Now ofc I wouldn't give any executives that idea. Don't mess with expected user functionality, that's like UX 101. if I see my navigation tampered with, I flag that site as spam.
Depends on one's determination and motives there are many ways to "disable refresh". One motive I imagine and don't approve is some want their website to feel like a mobile app, for whatever reason.
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.
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.
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!
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)
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:
> dragging the text to a new tab to perform a web search
I had no idea that this worked. I don't "get" intentionally dragging if there's any alternative.
I feel like one of those people who tells people that frowning takes more muscles than smiling, but: dragging seems like it requires so many more muscles to be engaged than the keyboard shortcuts for copy/newtab/paste and then enter.
The way I see it, it's a feature that exists which some people use and prefer. Breaking it (intentionally or accidentally) just isn't something I want to see.
Ha, different strokes for different folks I guess.
Usually when I'm reading something, my hands are off the keyboard and I use one hand to scroll with the mouse. In this scenario, it's so much easier to double-click to select a word and drag it to a new tab instead of reaching for the keyboard.
I totally get that. I had to check what my muscle memory would do in that situation. (Apparently) I select text, right-click, and then choose "search for <selected phrase>" from the context menu.
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.
Yep. Sometimes reddit has an image that’s either incorrectly cropped or it’s zoomed out so far that it’s unreadable. How many times do I need to click on the image before I can see it properly? I’ve counted as many as 4 taps through various awful image viewer things. Sometimes no about of tapping and zooming will render the image properly. The irony is my browser is great at showing images already - panning and zooming works beautifully.
I miss Apollo. The friction with Reddit’s awful design and coding choices makes me use their site a lot less. I think that might be a good thing in the long run. It leaves me hungry for something better.
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.
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.
I think the issue depends on whether you are on a a comment URL (e.g. clicking on the timestamp of a comment), or if you are on the post. If I'm scoped into 20517, the "parent" option is indeed a link to 20429. It will hard load to scope into 20429.
But if I'm on the actual 13396 post and click parent on your comment, I am instead 'loading' 13396#20429. Which of course isn't reloading the page but scrolling to a specific header.
I never personally liked the decision where replying or loading a comment took me to a whole new webpage instead of rending a formbox within 13396 and/or loading 13396#[comment ID], but I imagine there were historical and/or technical reasons for the decision. It generally doesn't bother me as I tend to mostly browse comments and only occasionally respond.
I am instead 'loading' 13396#20429. Which of course isn't reloading
the page but scrolling to a specific header.
No, you're scrolling to that via javascript. Previously this was handled by not interfering with the link to that URL thus preserving history and your location on the page.
GP is talking about the component/feature present in React/Vue/Angular/etc routers that allows links to behave like normal anchor links (allowing to open in another window, etc) but also use the SPA router for navigation when possible.
I'm not making any argument here, just explaining. Also makeitdouble's idea would apply even to non-SPAs or to pages without javascript. For example, I might want to submit a form but in a new tab.
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.
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
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.
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.
Another reason why we shouldn't lose control of our own browsers. Today I can set my own fonts, block elements, basically re-style everything once it arrives at my browser, tailored to my accessibility preferences.
We need a tool that can visit a website, build a summary out of it, and presents it in a standard way, customizable by the user. Like reader mode, but on steroids.
> nevermind the basic accessibility requirements that are often missing like alt text on images
It's easier than ever to make websites accessible and a lot of these new tools enable this. Like throwing linter errors when alt text is not set on images.
A lot of the things described in this article are issues with a lack of skill or maliciousness from the developer or whoever hired them. That copy paste thing? I almost always notice it on the websites of legacy book publishers. I think you can pretty easily guess their motivations.
I dislike react for other reasons but the majority of developers having shallow knowledge of how the web works is not one of them. That's just nature, the most common thing always ends up going to the lowest common denominator. Chocolate: hersheys or nestle, coffee: nespresso pods, food: mcdonalds, programming: javascript...
Then you may be underestimating accessibility guidelines or overestimating LLMs. The problem with inaccessible web applications is precisely that they cannot be interpreted programmatically, which would inhibit AI from performing this interpretation. An inaccessible website would be equivalent to a low quality prompt for an LLM.
The crazy thing about the rampant inaccessibility is that it’s clearly illegal and discriminatory and nobody cares. Any success stories about convincing product managers to stop it?
I'd be interested in more information on the difficulties you've encountered. I do most of my web dev in React and I don't remember encountering difficulties with these items.
Ah, I see what you mean. My common experience is that people I work with build the a11y requirements into the components as required props so you can't ignore them.
There are really only two problems here, and they are as old as the web itself:
1) Low Expectations
2) No definitions, standards, baselines defining people and/or practice
As I have been looking at job posts quite a bit lately everything now is a "Senior Fullstack Engineer" position. This is just so lazy. Then you dive into it and what they really want is some combination of Java or Python, R, Spring, and SQL. Not fullstack. You are wasting peoples' time and worse you are advertising to the public that you either don't understand the technology or just don't care about it.
Sigh.
In programming we call this an "X/Y" problem. You want to solve for "X", a desired end state. Instead of X all you can talk about is "Y", the approach you wish you could take. This is a tremendous anti-pattern. Its also why employers are getting 500 resumes for open positions and nobody seems qualified.
Instead start with the goal: "We are hiring to build a client/server app that can do '_____'. We expect candidates to write/support features X, Y, Z. Your constraints are: A, B, C." The reason why companies don't do this is typically because they have no idea what they are actually doing and they have also gone down several wrong paths already and have a bunch of broken technology to support. That's why they call this tech debt.
Then when it comes to interview time the employer and the candidates know exactly what the goals are and can ask the appropriate questions to appropriately eliminate each other. Otherwise, its just some horrible combination of a blind date and a game show where an audience gets to ridicule the contestants.
Here is a quick hypothetical example:
We are hiring to build a highly distributed media conferencing application. Developers are expected to write TypeScript, pipe stream data from sockets, work both in the browser and the server, and write test automation. Operating constraints include WCAG AA conformance, a privacy conformance checklist drafted by our legal department, and various performance considerations targeting both execution speed and network latency. Ideal candidates will demonstrate solutions during interview time for network latency, writing application logic in the browser, and state management of streamed data.
I'm guilty of doing this because in my game people kept accidentally double clicking and selecting all the text in the UI. What are the best practices around this?
There's nothing wrong with that. A game UI is where you should block text selection. Web-based games that let you accidentally select UI text look unprofessional. I think the author is talking about informational or business apps.
I was reading some article a while back, and as I read I like to highlight what I'm reading with my mouse, but that particular website decided that when I try to highlight text, the appropriate reaction from the site would be a tooltip saying that highlighting is not allowed... So I opened the devtools and copied the whole thing out of spite
On some of my old sites I used to check for whether the document was in an iframe, and go into an infinite loop if it was. The trick is to loop/delay slow enough to not trigger the "script is not responding", but enough to make the browser hellishly unresponsive.
Back in the Flash days I had a cherry bomb I'd put in my code that would crash decompilers in a similar way, if it found _root.stage.parent. It would also phone home first ;)
At least they were being honest about the design decision by actually telling you.
Just as a matter of polishing my apps, I usually go through and make sure that pages that might be printed or PDF-copied will print well, that everything selects where someone might want to copy text, and doesn't select where they're clicking any UI element resembling a button. In other words, I try to make all text fields selectable and printable, and everything else act as a graphic (even if it has some text on it).
In an ideal world, we really should have had another button or key combo for "I want to select the text" that isn't overloaded on "I want to select in general."
The old way was fine when word processors and other apps were completely separate beasts, but the web has blurred all of that and we are unfortunately albatross'd to decisions made in the past.
I want a fifth mouse button where 5-drag always means "select text" independent of all other UI content and as a result all text is selectable because text selection and other manipulations are totally different operations (at the event layer; "mouse down" and "mouse textselect" would be two different events).
Wishful thinking; we're stuck with the UI we have.
> Let me zoom in on my browser without the website getting all out of whack. I just want to be able to read.
This is my new OCD obsession when doing layout. I will keep my browser at 250% zoom for the first 3-4 hours of development. Periodically, I will spot test things like tables up to 500%.
I had no respect for the humble non-breaking space or automatic table layouts until I started doing this.
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.
>Stop hijacking my typical browser shortcuts for use in your own app I've seen this happen with ctrl + f for opening a custom in-app search bar. I don't want that. It doesn't always search the page as usual.
You can bypass this by selecting the url bar before using ctrl-f.
Ctrl-f is often overriden for a reason, though. On modern shitty React sites content outside the viewport may not be loaded into the DOM, so the browser find won't even work. It is quite frustrating the scroll past some text, ctrl-f for it and get "no results".
Correct. The most common perpetrator of "stealing" ctrl-f I use is the Google drive suite (Sheets, Docs, &c) and it's basically necessary. That operation is executed server-side. The client doesn't have the data to do the search.
On the last point, the sites that hijack ctrl-f (or CMD-f) often let you through to the normal page browser search with a second attempts at it if their search UI is still on the page.
So on the sites I know do it I just double tap CMD-f and I get the normal page search.
I hate when people do this on mobile. The Mastodon web app does this, and it's real unfortunate when I hit a picture in someone's stream and I can't make it bigger even though I have more pixels than cones in my eye.
Please, dear God, I just want to see the whiskers on the cat.
Here's my understanding of the current situation: iOS now ignores the viewport setting altogether, while in Chrome, there is a setting in the Accessibility section to "Force enable zoom".
So IIRC there's a workaround (if you want to call it that) for both platforms.
One of many things I hate on crappy modern web is messing with history (API). You click a interesting-looking link somewhere (like HN), go to page. You scroll down, either reading or just skimming, and every funcking header (or even something less important) add entry to you history. To get back to original site you have to click back like a million times.
I'll also add 'infinite scroll'. Just use a pager. It's linkable, searchable, browseable, works correctly with the history. Infinite scroll breaks all of that for no good reason.
Yeah I love that. A site I used to work on put their currency and language picker there, but on half the pages you literally couldn’t reach the footer!
There is one site I always admire (non-ironic) in this regard - twitter. I scroll it's feed, click on tweet, dive into several sub-threads and then I can easily get back to main feed where I was. (Unless they fucked it up recently).
That's shiny example of doing it right. Too sad it's pretty much only one.
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.
250 comments
[ 4.7 ms ] story [ 310 ms ] threadAh the Discourse classic. But did you know if you hit ctrl+F twice sequentially you can override that annoying behavior!
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.
Stage 1: Everything is totally trusting.
Viruses exist, and scanners exist to help you not download anything stupid.
Stage 2: Locked ecosystems like iOS App Store, Platform Vendor claims their 100% diligence will protect you (and them) from all possible bad (or insufficiently-profitable) software.
Apparently they weren’t satisfied
Stage 3: Full Sandboxing and full enforcement of Platform Vendor’s blessed software source only.
Now my computer, like my phone, will only ever have the exact, enumerated features the Platform Vendor blesses me with and I will like it or else. I am free to file a feedback on their website if I’d like a clipboard manager, and they may one day look at that feedback.
I mean, just think this two steps further. Hackers change input, and banks change input, so hackers == banks? But hackers also change what is displayed on the screen, and password fields change what is displayed on the screen, so hackers == password fields? Pressing my mouse button on the "reply" button changes what is displayed, so hackers == my mouse?
That's not the premise you stated earlier. That was: "Banks and hackers do the same thing by modifying the text during the copy and paste workflow", which completely ignores what kinds of modifications are happening.
> Copy and paste workflow is well defined and established concept by now. That bad actors are doing it doesn't mean you should.
See? You're doing it again. Banks are not doing what "bad actors are doing". Banks are doing something else.
> No point in exaggerating my premise and ridiculing me.
I am not exaggerating your premise and ridiculing you, I'm continuing your logic to show its' flawed premise. You stated that "banks and hackers are doing the same thing", and the reason it's the same is due to the literal operation being the same. Why can't I extend this logically to other operations that are the same? A password field changes what is displayed compared to my input, how is that different from a hacker changing what is displayed compared to my input?
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.
On Windows at least, any process can read any other process' memory as long as it's running under the same user.
(And also criminal to have a password max, short of like 1MB — even then the only reason for the limit is to slightly reduce the harm of some kind of weird DDOS against your login endpoint - whenever I see a password max I always assume this site is so dumbly implemented that they aren’t hashing my password but storing it in plaintext or reversible encrypting 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.
This is not a priority. The features are implemented by more abstraction, ie. TypeScript and web frameworks. Industry's low barrier to entry promotes studying frameworks, not technologies and standards enabling them. Anti-robot measures mostly prevent automated fraud and are there to ensure the ads are displayed, if the whole process will freeze your browser and eat your entire RAM they are fine with it.
There's nothing wrong with trial accounts. Phishing/scam pages and card testers are the problem, let law enforcement focus on what's actually illegal.
Also, if someone is registering 10,000 accounts that are obviously not real people, I should let them?
First of all, my website, my free speech. I’m free to publish or delete anything on it.
Second, bulk-created fake accounts aren’t needed even for legitimate political speech. That’s more like extreme astroturfing.
That's exactly what developers will tell middle-managers but it won't matter unless you're in a organization that actually value their developer's opinion.
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.
- Left-click (obvious)
- Right-click (context menu)
- Middle-click (open in new tab)
- Ctrl-click (open in new tab)
- Shift-click (open in new window)
Most sites support at least one of right/middle/ctrl-click, though sometimes you have to Duplicate the tab and then left-click. If none work, and duplicating the tab loses context, it's probably time to abandon hope and find another website.
* Save the link as a .loc file on the desktop
* Open the link in a tab in another browser window, or another browser altogether.
* Add it to a terminal prompt (e.g. curl/wget)
(try it with some links on this site into the text box or your text editor of choice)
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.
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 that text/markdown would have to be restricted not to include any html tags, which are allowed in the "common" md spec.
> would have to be restricted not to include any html tags
The point of this would be to deliver pure content, so "any tag" would definitely not be allowed. My user agent would decide what to render and how.
https://gemini.circumlunar.space/docs/gemtext.gmi
Forbidding them is a one-line change to the spec.
It really annoys me that people keep bringing this up, as if they can't imagine "markdown with html disallowed".
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.
To be clear, I personally agree with, and want every single item listed in this blog. I’m a big nerd. But I also recognize that I’m nowhere near anything resembling a typical user. What I want is probably not even on the radar of 99% of users of these websites.
It’s easy to say, “I want X and having X would make me a happier user.” The real question is, “is implementing X an appropriate expenditure of resources if the goal is to build a profitable business?” Usually not. Most users don’t know or don’t care about X. Be careful with the nerd echo chamber we live in that makes us think these things matter to the common person.
For all of this, one could argue, “yeah but they’re being foolish. Long term this is going to bite them.” You might be right! I think you’re right, too. But that’s a business position, not a technical one.
Although Google and other search engines have said for more than a decade that their bots can execute javascript and navigate SPAs, the truth is that they are not going to simulate a click on every random element with onClick events attached. In many cases, they will not even execute any javascript.
Even in 2023, <a href="URL"> is the best way to make search engines pay attention.
Popular frontend development patterns have also made it nearly impossible to figure out the semantic structure of a page. Everything is a <div> now. But if you care about how your website looks in a search result, you might still want to designate some parts of the page as <main> or <article> and other parts as <aside> or <nav>. This is especially important if your website contains short user-generated snippets (like tweets) along with a lot of auxiliary information, as semantic tags make it easier for search engines to determine what the main content of each URL is.
In short, many websites would still benefit from enforcing proper semantic markup, like we used to do in the good ol' days of the "no tables for layout" crusade.
Now if the business doesn't care about SEO at all (an increasingly common attitude as websites become app-ified), there's always the atomic option: talk to the legal department about the possible consequences of ignoring accessibility.
Lot of these things just require devs to not actively try to damage the usability of the defaults. It costs money to break the basics that work for free:
- missing keyboard focus indicator? yeah, dev had to go out of his way to remove it, instead of just doing nothing and focusing on the job/content
- can't paste into inputs? someone had to think about preventing this and implemented it
- ctrl+k / ctrl+f is broken? it works if you just write you page and do nothing extra!
- page is blank for people with JS disabled? someone wasted money on a person who had to learn a whole damn programming language and multi-billion dollar company's framework instead of just html/css
And that's how we get things like the 737Max
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.
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.
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.
Maybe if you're doing like a painting app or something you don't need to.
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
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.
People look down on bootcampers, but it always feels to me that 99% of what is taught in university programs is similarly only useful in specialized situations. The actual good thing is having had to sit down and write a lot of code before anyone lets you touch anything.
What does such a program look like for Web?
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.
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 don't think it's worth beginners learning the road rules and safety protocols, because of the "time to being responsible for a heavy, fast motor-vehicle sharing a road with other people" problem.
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/
I think at the bare minimum you should strive to be readable, and you can do that with surprisingly few extra lines of CSS and very basic web design principles (avoid using full black or full white backgrounds). CSS is uhh... a choice, but you don't need to know too much in the very beginning to start building up some motivation of making stuff that looks easy on the eyes.
https://perfectmotherfuckingwebsite.com
https://contrastrebellion.com/
If you can't read it, there's probably a wild CSS messing things up on your end.
> W3C's Web Content Accessibility Guidelines set the minimum contrast between text and its background so that it can be read by people with moderately low vision (which is quite common).
If you follow that link to W3C, you'll see that the minimum contrast for text to be considered legible is 3:1, though that's for people with standard vision (it's the lowest rating). To be truly accessible, the minimum we should strive for is 7:1. Anything above that has a AAA rating.
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.
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.
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.
Happy to report that our production site has more links that look like buttons than it does buttons that act like links. It’s almost a meme on my team that Swiz will get you if you use onClick for navigation.
The other hill I enjoy defending is that we should use more browser built-in components instead of trying to design our own.
I jest, but I am at least 5 years older than everyone else on the team. And have the unfun background of getting into professional webdev before jQuery.
Ugh. Let me know if you have any tips. All the art-school “UX designers” have to have custom date pickers and stupid knockoffs of iOS switches and custom drop-downs when there are actual, better, and automatically-accessible, versions of all those. How do you fight against this vanity design without making an enemy of the whole design team?
Yet there seems to be a free pass where a "web designer" is allowed to dictate how a site should work and look without knowing the basics of HTML, CSS and JS.
Same people will also claim "we don't need a frontend dev or a UX designer".
Now ofc I wouldn't give any executives that idea. Don't mess with expected user functionality, that's like UX 101. if I see my navigation tampered with, I flag that site as spam.
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!
Thankfully this behaviour can be blocked with uBlock Origin by adding these rules:
I had no idea that this worked. I don't "get" intentionally dragging if there's any alternative.
I feel like one of those people who tells people that frowning takes more muscles than smiling, but: dragging seems like it requires so many more muscles to be engaged than the keyboard shortcuts for copy/newtab/paste and then enter.
Usually when I'm reading something, my hands are off the keyboard and I use one hand to scroll with the mouse. In this scenario, it's so much easier to double-click to select a word and drag it to a new tab instead of reaching for the keyboard.
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.
I miss Apollo. The friction with Reddit’s awful design and coding choices makes me use their site a lot less. I think that might be a good thing in the long run. It leaves me hungry for something better.
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.
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.
FWIW if you hover over the parent link it is indeed populated with a different URL.
https://news.ycombinator.com/item?id=37013396 (shortened to 13396)
my comment you replied to
https://news.ycombinator.com/item?id=37020429 (shortened to 20429)
and your comment here is
https://news.ycombinator.com/item?id=37020517 (shortened to 20517)
I think the issue depends on whether you are on a a comment URL (e.g. clicking on the timestamp of a comment), or if you are on the post. If I'm scoped into 20517, the "parent" option is indeed a link to 20429. It will hard load to scope into 20429.
But if I'm on the actual 13396 post and click parent on your comment, I am instead 'loading' 13396#20429. Which of course isn't reloading the page but scrolling to a specific header.
I never personally liked the decision where replying or loading a comment took me to a whole new webpage instead of rending a formbox within 13396 and/or loading 13396#[comment ID], but I imagine there were historical and/or technical reasons for the decision. It generally doesn't bother me as I tend to mostly browse comments and only occasionally respond.
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.
I'm not making any argument here, just explaining. Also makeitdouble's idea would apply even to non-SPAs or to pages without javascript. For example, I might want to submit a form but in a new tab.
I still wish they should merge 90% if not 100% of HTMX into official HTML 5 spec.
I’ll always long for the days of simple websites but I know they are gone and that’s fine.
The least we could do, however, is preserve some modicum of standards and usability.
I’ll throw in ability to open images/media as standalone files to this list.
It's easier than ever to make websites accessible and a lot of these new tools enable this. Like throwing linter errors when alt text is not set on images.
A lot of the things described in this article are issues with a lack of skill or maliciousness from the developer or whoever hired them. That copy paste thing? I almost always notice it on the websites of legacy book publishers. I think you can pretty easily guess their motivations.
I dislike react for other reasons but the majority of developers having shallow knowledge of how the web works is not one of them. That's just nature, the most common thing always ends up going to the lowest common denominator. Chocolate: hersheys or nestle, coffee: nespresso pods, food: mcdonalds, programming: javascript...
1) Low Expectations
2) No definitions, standards, baselines defining people and/or practice
As I have been looking at job posts quite a bit lately everything now is a "Senior Fullstack Engineer" position. This is just so lazy. Then you dive into it and what they really want is some combination of Java or Python, R, Spring, and SQL. Not fullstack. You are wasting peoples' time and worse you are advertising to the public that you either don't understand the technology or just don't care about it.
Sigh.
In programming we call this an "X/Y" problem. You want to solve for "X", a desired end state. Instead of X all you can talk about is "Y", the approach you wish you could take. This is a tremendous anti-pattern. Its also why employers are getting 500 resumes for open positions and nobody seems qualified.
Instead start with the goal: "We are hiring to build a client/server app that can do '_____'. We expect candidates to write/support features X, Y, Z. Your constraints are: A, B, C." The reason why companies don't do this is typically because they have no idea what they are actually doing and they have also gone down several wrong paths already and have a bunch of broken technology to support. That's why they call this tech debt.
Then when it comes to interview time the employer and the candidates know exactly what the goals are and can ask the appropriate questions to appropriately eliminate each other. Otherwise, its just some horrible combination of a blind date and a game show where an audience gets to ridicule the contestants.
Here is a quick hypothetical example:
We are hiring to build a highly distributed media conferencing application. Developers are expected to write TypeScript, pipe stream data from sockets, work both in the browser and the server, and write test automation. Operating constraints include WCAG AA conformance, a privacy conformance checklist drafted by our legal department, and various performance considerations targeting both execution speed and network latency. Ideal candidates will demonstrate solutions during interview time for network latency, writing application logic in the browser, and state management of streamed data.
I'm guilty of doing this because in my game people kept accidentally double clicking and selecting all the text in the UI. What are the best practices around this?
Back in the Flash days I had a cherry bomb I'd put in my code that would crash decompilers in a similar way, if it found _root.stage.parent. It would also phone home first ;)
Just as a matter of polishing my apps, I usually go through and make sure that pages that might be printed or PDF-copied will print well, that everything selects where someone might want to copy text, and doesn't select where they're clicking any UI element resembling a button. In other words, I try to make all text fields selectable and printable, and everything else act as a graphic (even if it has some text on it).
Even if it's often abused, user-select exists for a reason.
[But if there is some text in your game that you think users might ever want to copy, please make it selectable!]
The old way was fine when word processors and other apps were completely separate beasts, but the web has blurred all of that and we are unfortunately albatross'd to decisions made in the past.
I want a fifth mouse button where 5-drag always means "select text" independent of all other UI content and as a result all text is selectable because text selection and other manipulations are totally different operations (at the event layer; "mouse down" and "mouse textselect" would be two different events).
Wishful thinking; we're stuck with the UI we have.
This is my new OCD obsession when doing layout. I will keep my browser at 250% zoom for the first 3-4 hours of development. Periodically, I will spot test things like tables up to 500%.
I had no respect for the humble non-breaking space or automatic table layouts until I started doing this.
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.
You can bypass this by selecting the url bar before using ctrl-f.
But that should be an exception, not the rule.
On the last point, the sites that hijack ctrl-f (or CMD-f) often let you through to the normal page browser search with a second attempts at it if their search UI is still on the page.
So on the sites I know do it I just double tap CMD-f and I get the normal page search.
You can stop using user-scalable=no and maximum-scale=1 in viewport meta tags now https://lukeplant.me.uk/blog/posts/you-can-stop-using-user-s...
Please, dear God, I just want to see the whiskers on the cat.
So IIRC there's a workaround (if you want to call it that) for both platforms.
Fuck everyone who does that.
That's shiny example of doing it right. Too sad it's pretty much only one.
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.