Just normal web things
heather-buchel.com
heather-buchel.com
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.
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:
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.
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:
www.reddit.com##+js(aeld, mousedown, isSelectionOutOfRange)
www.reddit.com##+js(aeld, mouseup, shouldShowButton)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.
I am instead 'loading' 13396#20429. Which of course isn't reloading
the page but scrolling to a specific header.
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.
The way I think about it is that you assume a level of responsibility whenever you tinker with default affordances. Your "feature" isn't restricted to whatever narrow conception or intention you had when you designed it. It consists in the totality of a visitor's actual experience.
If I change the logic of the the back button, I'm changing what the back button affords on this particular website and become responsible for whatever happens as a result.
That includes confused and frustrated users saying "Screw you and your broken website."
Or take, e.g., the way scrollbars work, which can be very browser-and-OS-specific. Are you sure you want to assume responsibility for that? How sensitive are you to the downside, really?
Essentially, you're making your website speak a kind of creole. You've forgone any right to be upset if your visitors don't speak it and shouldn't be surprised if they persist in "misinterpreting" it.
Forget about avoiding such "features" because you want to be nice to your visitors. It always seemed to me they offer limited upside and unlimited downside.
On the other hand web apps absolutely can play a little more with the UX if it provides value to the user. But if it's in the browser, some of this really do still apply. I'm all in on web apps, its a universally accessible platform for development outside the walled gardens of app stores.
What we need to stop doing is treating every single website as an app!
If you want your page to appear in search results on a search engine, it's not a web app it's a website.
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.
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.
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.
I see this most often with the city and state inputs, where city is a text input and state is a drop-down/select menu.
As a Texan, I will type my city, tab to the State select menu and type "t" followed by another "t" then tab to the next form element.
But what I'm seeing lately is a text input (search field) dressed up like a drop-down menu... So my t , t input results in a text search for a literal "tt" instead of selecting Tennessee then Texas. It's so aggravating.
Now if someone chooses to click the triangle in the drop-down menu, and scroll through the states, the element would work as expected... If you only wanted to interact with the element with you mouse.
If it ain't broke, don't fix it.
And then because code sharing across apps/frameworks/companies/etc was historically very hard, only really big companies had enough headcount to build fully functional, accessible, customizable replacements for built-in components. Web Components solve this, allowing global collaboration on common leaf node components like <select>.
Related: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...
An example: I don't really want to add a click event listener to a link to make it display in a modal (or whatever). Because this event is too low-level and now my listener needs to check modifier keys. What I really want is to somehow tell the browser "if the current window URL is about to change via this anchor element, call this function instead". The user is still free to open their links in new windows or tabs and my code will not be triggered for those cases.
A CSS example: I don't really want to set cursor images for every element and pseudo-class. I'm forced to list every element that uses the cursor I'm overriding. What I really want is to tell the browser "use this custom cursor image wherever you were going to use the default (hand/wait/resize/etc) cursor". My code would then be future-proofed for new elements/UI.
Sometimes I feel that certain browser APIs suffer from the XY problem.
This is pretty doable using javascript - just register an onclick on the <a> tag and have your event handler cancel the default navigation behaviour. Your website will then continue to work great even if the user has javascript disabled. And all the built in browser behaviour (like the right click "link" menu, and ctrl+click) still works perfectly.
That said, this is a pretty obscure "trick". It would certainly be nice if the DOM API made this easier to do.
Also, .preventDefault() wasn't obscure in the jQuery era; if it's obscure now that's a sad commentary.
I believe that’s the use case for the Navigation API.
Ctrl + click or middle mouse button didn't work on links, right click didn't work, selecting and copying text didn't work, inspect element didn't work (due to how the technology is built), even attempting to zoom the page did nothing.
This article does ring true both because of that experience, as well as some of the SPA implementations I've seen even with more conventional technologies.
I haven't once been convinced by any flutter demo, web or mobile, that feels like it has even passably good UX.
In general, don't try to improve browser's default behavior.
Fuck everyone who does that.
That's shiny example of doing it right. Too sad it's pretty much only one.
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.
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...
- 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)
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.
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”.
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.
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.
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.
The worst offender for this is my bank which doesn't provide a way to copy my IBAN.
It's even worse on mobile where I'll often have to send myself a link (sometimes one step back to how I got there) to deal with it on desktop.
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.
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.
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.
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.
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.
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.
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 ..
window.addEventListener('keydown', ev => {
if ('kf'.indexOf(ev.key) >= 0 && ev.ctrlKey)
ev.stopPropagation()
}, true);
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.
I'm guessing you do this by adding an external mouse and keyboard?
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
Ah the Discourse classic. But did you know if you hit ctrl+F twice sequentially you can override that annoying behavior!
>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.
I don't see any on FF Android :P
> What did I miss? Let me know on Mastodon.
*opens Mastodon*
*sees it hijack arrow keys*