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.
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.
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.
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)
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 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.
> 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.
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.
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.
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.
> 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.
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 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.
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.
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.
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.
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.
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.
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.
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.)
> 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.
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?
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.
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.
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.
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.
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.
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.
> 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.
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.
Get over it, we cant have normal web things. These were invented for an earlier, innocent, more generous era.
The idea of hyperlinks was that the world will self-organise all its information by connecting resources across the WWW. A noble, idealistic vision for the role of computing.
Thats not how it worked out. There is now a self-appointed organizer of all the world's information and a few addictive walled gardens that want you to never follow any outside link.
Software technologies adjust to serve business models. The SPA-fication of websites is part of that process. An existing, widely available stack (WWW browsers, web servers etc) is repurposed selectively to meet altermative objectives. Anything not serving business needs will sooner or later be deprecated.
While various niche protest movements exist, they are really fancyfull, escapist, even elitist affairs.
Who knows, the economics of how we organize the world's information may change yet again (LLMs say hi), bringing yet new tech approaches but i) dont bet on it and ii) the new pattern might be even worse
Positive scenarios do exist, eg Web 3 as the fediverse but they will float on sink on the back of their business models.
There is still a web outside of those walled gardens, and it is bigger than it has ever been, even when you remove all the corporate websites and NPCs that use them.
> Let me zoom in on my browser without the website getting all out of whack.
This, weirdly, is a remarkably hard problem. I always like to think that I build sites that will be responsive and will scale correctly when zoomed, but not only is that not the case, but different browsers also handle zooming in substantially different ways such that I don’t even have a target to aim at.
Suffice it to say that it’s difficult to get even an okay representation of any sufficiently complex layout when zoomed, so I just have to settle for “okay”.
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.
> 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.
Some of the things on this list I've never encountered and seem a little like fluff for the post (not being able to copy stuff? hijacking regularly used keystrokes? how often is that happening to you, really?).
Navigation/history tracking is an ongoing battle within SPAs. Not rocket science but if not part of initial planning definitely becomes a problem to implement after-the-fact. Agreed this is something to work on across the web.
But I will take the scrollbar thing into consideration in my next site. I am very guilty of this.
I feel like I suffer from the copy issue at least once a week. My go to solution is inspecting the page source to copy directly from there but it's still extremely annoying. Please make your text selectable/searchable.
The worst offender for this is my bank which doesn't provide a way to copy my IBAN.
Somehow banks decided it's a good security practice to hinder copying and pasting of IBANs, especially when user defines a bank transfer. So here you are, multiple tabs and files open at once, entering IBAN digit by digit and checking multiple times, now you are secure.
The scroll bar thing is hard because Apple already declared war on visible scroll bars (along with all other supposed visual clutter) half a decade ago, so most can’t see them “except after activating them with gestures” anyway.
I agree with the sentiment, but why is this still attributed to JavaScript. This applies to essentially everything exposed to UX, well beyond JS and web. We didn’t JavaScript it away, we bad-developered ourselves through a narrowing hallway until a point where we ended up with a black sheep. JavaScript didn’t enable this, there’s as many issues in this space in environments where JavaScript is not even a player, it may have been a carrier but not the root cause.
I don't blame the developers for this at all. I consider myself strong with accessibility and yet at the last job I was intimidated to bring it up. There accessibility was an anti-pattern. At many places they are just struggling to put text to screen. At these places you need a billion lines of code in multiple frameworks to display "hello world". How can you blame the JavaScript developer when nobody knows what they are doing and everybody points fingers at each other?
This doesn't just apply to accessibility. It also applies to security, performance, and a variety of other things that never happen unless a law suit is coming or a major client stops paying.
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.”
>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.
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.
"Do responsive things. I didn't spend most of my early career convincing clients to let us do a responsive website just for you to serve me up a boring layout that kicks down to your mobile layout as soon as you are less than 1200px."
Can anyone elaborate on this? I feel like I'm missing some context because a desktop layout that kicks down to a mobile layout at a breakpoint sounds like the essence of doing responsive things.
Obviously there are a ton of other aspects of responsiveness, but specifically calling out the layout change makes me think I misunderstood something.
Many elements can be responsive by just letting things float in them. Their width can be governed by their content and outer constraints. One can then define minimum widths for things. This way most of the responsiveness becomes simple and there is usually no need for media queries reacting to a specific width of arbitrarily chosen 1200px or similar. Elements float to the next line, when they don't have enough space any longer.
I understand this as criticism against designs, that are "responsive" in a way, that they simply "snap" at a specific width into a full blown "mobile" looking view, instead of seamlessly adapting to available width.
Having two completely unrelated UIs – one for mobile, one for desktop - isn't really responsive. When done that way there's some point (e.g. 1199px width in the OP's example) where you suddenly have a tiny mobile web site with a ton of blank space on either side (or worse, it stretches it all out to fit and all the blank space is within every single button and widget).
There should either be several progressively more "mobile" breakpoints, or even better, use component queries so individual chunks of the page can rearrange their contents as their available area shrinks.
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?
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.
Hi! I love it. The magic of original HTML inspired my current website : http://razi.ps
I remember the days as a kid when I just threw together CSS and HTML to see how things worked. Playing with the edges of Unicode/ASCII web-host-shittification made for a creative playground ..
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.
A very recent example of how "doing normal things" has been sabotaged in the ChatGPT app is the Ctrl+Shift+C shortcut to open the Dev Console. It now copies the last generated answer.
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
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).
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 ;)
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.
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.
> 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
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.
>Let me see scroll bars Please don't hide them for the sake of your "slick" ui. Sometimes I want to click on the scrollbar and drag it. Just a normal web thing.
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.