One thing that happens when you learn to build web things using React before learning html, is that you don't care about links.<p>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.<p>This is the only thing I'm a dictator about. There is zero room for negotiation when it comes to links.
Love this.<p>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 <i>actual</i> experience.<p>If I change the logic of the the back button, I'm changing what the back button <i>affords</i> on this particular website and become responsible for whatever happens as a result.<p>That includes confused and frustrated users saying "Screw you and your broken website."<p>Or take, e.g., the way scrollbars work, which can be very browser-and-OS-specific. Are you <i>sure</i> you want to assume responsibility for that? How sensitive are you to the downside, <i>really</i>?<p>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.<p>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.
I think of this as the "appification of <i>websites</i>", we need to stop doing it. We need to move back to SSR and sprinkles of JS on <i>websites</i>.<p>On the other hand <i>web apps</i> 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.<p>What we need to stop doing is treating <i>every single website as an app</i>!<p>If you want your page to appear in search results on a search engine, it's not a <i>web app</i> it's a <i>website</i>.
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…
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.<p>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.<p>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.<p>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.<p>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.<p>If it ain't broke, don't fix it.
I believe most of the issues with broken link behaviour results from the lack of higher-level methods to override the default link behaviour.<p>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 <i>really</i> 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.<p>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 <i>really</i> 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.<p>Sometimes I feel that certain browser APIs suffer from the XY 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: <a href="https://gallery.flutter.dev" rel="nofollow noreferrer">https://gallery.flutter.dev</a> (I think it was the Reply example in particular)<p>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.<p>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.
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.<p>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.<p>Fuck everyone who does that.
There are really only two problems here, and they are as old as the web itself:<p>1) Low Expectations<p>2) No definitions, standards, baselines defining people and/or practice<p>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.<p>Sigh.<p>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.<p>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.<p>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.<p>Here is a quick hypothetical example:<p>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<p>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.<p>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.<p>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...
I'm aware of 5 operations that a standard link should support:<p>- Left-click (obvious)<p>- Right-click (context menu)<p>- Middle-click (open in new tab)<p>- Ctrl-click (open in new tab)<p>- Shift-click (open in new window)<p>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.
Get over it, we cant have normal web things. These were invented for an earlier, innocent, more generous era.<p>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.<p>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.<p>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.<p>While various niche protest movements exist, they are really fancyfull, escapist, even elitist affairs.<p>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<p>Positive scenarios do exist, eg Web 3 as the fediverse but they will float on sink on the back of their business models.
> Let me zoom in on my browser without the website getting all out of whack.<p>This, weirdly, is a remarkably hard problem. I always like to <i>think</i> that I build sites that will be responsive and will scale correctly when zoomed, but not only is that <i>not</i> the case, but different browsers also handle zooming in substantially different ways such that I don’t even have a target to aim at.<p>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”.
[self-promotion] The article author appears to be using Windows, but on Mac and iOS there's StopTheMadness: <a href="https://underpassapp.com/StopTheMadness/" rel="nofollow noreferrer">https://underpassapp.com/StopTheMadness/</a>
A very specific but related tip about not disabling zoom:<p>You can stop using user-scalable=no and maximum-scale=1 in viewport meta tags now
<a href="https://lukeplant.me.uk/blog/posts/you-can-stop-using-user-scalable-no-and-maximum-scale-1-in-viewport-meta-tags-now/" rel="nofollow noreferrer">https://lukeplant.me.uk/blog/posts/you-can-stop-using-user-s...</a>
> Let me zoom in on my browser without the website getting all out of whack. I just want to be able to read.<p>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%.<p>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?).<p>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.<p>But I will take the scrollbar thing into consideration in my next site. I am very guilty of this.
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.
We need Dogme95 for websites.<p><a href="https://en.m.wikipedia.org/wiki/Dogme_95" rel="nofollow noreferrer">https://en.m.wikipedia.org/wiki/Dogme_95</a>
>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.<p>You can bypass this by selecting the url bar before using ctrl-f.
Here here!<p>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.<p>So on the sites I know do it I just double tap CMD-f and I get the normal page search.
I hope everyone reads this and listens.<p>I’ll always long for the days of simple websites but I know they are gone and that’s fine.<p>The least we could do, however, is preserve some modicum of standards and usability.<p>I’ll throw in ability to open images/media as standalone files to this list.
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."<p>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.<p>Obviously there are a ton of other aspects of responsiveness, but specifically calling out the layout change makes me think I misunderstood something.
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 : <a href="http://razi.ps" rel="nofollow noreferrer">http://razi.ps</a><p>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 ..
Yeah, this is a life saver, for those affected by a recent fad:<p><pre><code> window.addEventListener('keydown', ev => {
if ('kf'.indexOf(ev.key) >= 0 && ev.ctrlKey)
ev.stopPropagation()
}, true);
</code></pre>
For me this goes into a global userscript until browsers put back control into user's hands.
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.
> Let me copy text so I can paste it.<p>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?
> beause "you can't hover or tab on mobile, right?" (wrong)<p>I'm guessing you do this by adding an external mouse and keyboard?
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.<p>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.<p>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.<p>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.
> 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.<p>Ah the Discourse classic. But did you know if you hit ctrl+F twice sequentially you can override that annoying behavior!
I totally agree with all of this. But:<p>>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.<p>I don't see any on FF Android :P
> Stop hijacking my typical browser shortcuts for use in your own app<p>> What did I miss? Let me know on Mastodon.<p>*opens Mastodon*<p>*sees it hijack arrow keys*