edit: It is intentional for sure, the other entries in this blog have selectable text.
Exquisite bait m'lord!
... or maybe the word that's connected to hippo and rhymes with "crisy"
(OkCupid also had an article saying why you should never pay for online dating, which coincidentally was taken down the same day they were acquired by Match.)
Also, OkCupid gave people different prices based on whether they said they were a man or woman. I wonder if anyone ever sued them in a class action.
I dunno. Even if I zoom so I can click precisely where I want to select or edit, my phone still insists on doing the operation in another place. And some places are just completely forbidden.
Using a computer with boxing gloves ought to be a lot more precise than that.
body {
-webkit-user-select: none;
-webkit-touch-callout: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
}
*##html, body, body *:style(user-select: auto !important)Pros: 1. safer (what you see is what you select), 2. also works with images, 3. all text can be selected
Anything that is meant to be read as content should absolutely, without fail, be selectable and copyable (assuming appropriate permissions).
But stuff like tab headers, buttons, or even text-sparse tiles - things meant for the user to click on - can, and usually should, prevent text selection. It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way.
Exceptions to every rule, and to every exception of that rule, of course. But for the most part, allowing text highlighting in those clickable areas is a rough UX.
* note that I did not include anchor links; those are meant to be inline within text content and should therefore be selectable.
To each their own, but I'd rather neither of those things at the expense of not being able to select "Home", "My Account", "Settings", etc. Shit that nobody actually needs to select anyway.
Not translating entire articles to a language you don't support has the easy remedy of letting people select the text and use third party tools to support their specific use-cases. But not including translations for your clickable content for languages that aren't supported are the literal practical limits of ability. I would rather my apps work for people in languages I do support, with full accessibility (and minimal scripting overhead), than to have them work poorly for keyboard-only users in all languages, regardless of my app's support for them.
Again, we're talking about the stuff that should be iconic. Things that can literally be represented by icons. Buttons and tab headings. Things that you shouldn't actually need translated AT ALL, much less into every single language there is.
Right clicking a standard anchor element gives you the "copy link" option, but you don't get to copy the word without having it selected. Would be nice to just have a "copy word" feature, for starters. Could even be expanded so that it auto-selects the text after copying it so that if you wanted to copy more than just one word, you could expand the highlight (with the little widgets on mobile, or with keyboard/mouse selection in that one state on desktop) and then get a "copy text" option that copies all of the selected content.
Also if you're a non native speaker you want to be able to select the text so you can translate it
And, more pertinently, why should I support it, at the expense of keyboard-only users?
When you don't know the language or what "My Account" means? Not everyone speaks English.
Do you have an example of a website where selectable text makes keyboard navigation not possible? Could this be a browser problem?
I can tab between links here in HN and it's perfectly also selectable.
Alternatively, set your cursor at the end of the header in the empty space, and drag your mouse backward to highlight the items. At that point, you can highlight the text, because you started in a non-user-select-limited area.
Note that this is default browser behavior. Inspect the styles and see that they have applied no selection styling to those anchors. This is the thing I'm advocating for. Make the web work like the web works, and disregard people telling you that "everything must be selectable" not because it shouldn't be, but because there are features that expect certain functionality to work well with the other features of the web.
The website is advocating for not disabling selection, not for enabling in random places.
I am saying the web should work the way it is, like Hacker News does, as I already have brought up elsewhere.
The article is saying the same thing. Basically don't do `user-select: none;`. The example is itself in the article's CSS.
The article is not advocating for breaking anything.
And unlike me you haven't provided a single example so far, only workarounds for people who don't like your suggestions.
In your original post you say "But stuff like tab headers, buttons, or even text-sparse tiles - things meant for the user to click on - can, and usually should, prevent text selection" and you explicitly mention that you leave out anchors.
So far no reply to me has talked about problems causing by having selectable "tab headers, buttons, or even text-sparse tiles".
I am still 100% open to hearing about it. But I can do away with the personal attacks and sarcasm.
You can drag slightly above/below to select it, or use shift + arrow keys. I personally use a plugin[0] to allow dragging within the text too, and haven't noticed any issues.
[0]: https://addons.mozilla.org/en-GB/firefox/addon/drag-select-l...
> Note that this is default browser behavior [...] This is the thing I'm advocating for.
If you're just advocating for the default browser behaviour, which does somewhat allow selection of link text, then that may be worth clarifying above - since I think people are interpreting your comments as advocating for those buttons that prevent text selection entirely (and I'm not really sure how else to interpret "the default behavior should at the very least be mitigated").
The people who seem to have the most trouble understanding what I'm advocating for are the people who seem to only be taking a user-centric approach to the situation, rather than grappling with the practicalities of the web environment.
At this point, I'm over trying to make anyone understand anything. They'll either get it, when it is relevant for them to get it, or they won't and it won't matter to me or anyone else at all.
In a year, we might have better web functionality or a new built-in browser or OS feature, or any number of other things that could mitigate this specific gripe, so I'm not super concerned about any of it. Those that understand what I'm saying will have better UX for heeding the advice with appropriate exception. And those that don't won't make UX worth using. No worries either way!
Not everyone is fluent in every language, and not every website works perfectly with the browser's translator.
There will be situations where people will want to translate that ONE word that is actually in a button or tab, and isn't selectable because someone thought they knew better.
Has nothing to do with "thinking" anything. It's about testing with accessibility parameters and
knowing* what practical problems occur.If you really need to translate ONE WORD, it's not that onerous to type it. You're bringing edge-case hypotheticals to a discussion about practical functionality.
Hacker News is fully selectable, and still fully useable with the keyboard.
> it's not that onerous to type it.
Yes it is, if I don't even know what the letters are. Not every country uses the latin alphabet. And not every people coming to latin-alphabet countries know what those letters are.
There is a certain page of one of the Bundesagentur für Arbeit websites that doesn't play well with automatic translation.
I speak B2 level German, but even then some of the technical terms are still complicated or unknown for me. This included one very long German word that was in a BIG RED button and the text in the big red button was not selectable, in the manner described in the article.
I think I found your problem. Not sure why you think the solution is to make everything work worse for keyboard users.
You can highlight the buttons (most times) in Safari on MacOS, but you can't select the text and copy it or translate it.
<input value="reply" type="submit">I am curious what operating system you can select text from the buttons on though. I might spin up browserstack to experiment.
This is what is copied from the login page, you can see that the button text is missing:
Login
username: password:
Forgot your password?
Create Account
username: password:
But yeah, HN isn't the best in this regard :)
Maybe dang will one day consider changing to <button>reply</button>!
How would you have me type it?
But that's not what the topic is. The topic is HOW developers should accomodate users. And I'm simply taking the stance that preventing user selectability is a lesser evil in specific cases than universal selectability, because the former can be mitigated with less scripting overhead than the latter.
For Kanji the numbers are around 2136 and 1200 and respectively.
If you know the language, then you don't need this.
But if you're claiming that you can type a random Hanzi or Kanji character you see in an interface without speaking the language, you are either missing something here or not arguing in good faith.
If the word uses the exact character set on your keyboard, sure. How am I going to type Kanji?
by screenshotting it and copying the text out of the screenshot
by putting a screenshot itself into chatgpt
I'm curious what real world scenario you've imagined yourself in with a kanji button that you don't understand within the rest of a website in kanji that you do understand, but don't know how to type kanji?
The argument here isn't that it's _impossible_ to do that with copying disabled, it's that it's _more annoying_.
By providing a list of _more annoying_ ways to do something, you're reinforcing the argument, not refuting it.
yes it's absolutely just as easy to point my phone's translate app at the button.
any more questions?
I also find it rather difficult to point my phone at itself when trying to translate a word it's currently displaying; but maybe that's also a skill issue.
On top of the real concerns around otherwise selectable text in a writing system not supported by the user's keyboard, there's also the issue of whether or not they can even operate enough of a keyboard to transcribe whatever text they want to translate.
Just do whatever you want and then listen to your actual users' feedback.
I worked on an application that I had to make button text not selectable because the old people using it kept selecting text on the buttons by mistake instead of clicking/activating the button and getting stuck during a clinical trial.
Should I have left it selectable to pass the HN accessibility shamers purity tests, or listened to the users?
I empathize with translation, as I have to do it to pretty much every chipset firmware documentation I come across. So I just don't really understand where all of these issues are occurring with people not being able to translate stuff. Feels like a lot of people are maybe using a lot of websites that they aren't the target users for...
Because "I'm not worried about users my application does not support"
I'm sorry you are FORCED to use a bunch of apps that do not seem to respect you as a user. My apps respond to feedback from my users and their accessibility concerns are about selectable text in clickable content, NOT about having difficulty translating my apps. As far as I know, my apps are translated by whatever browser plugins or third-party tools those users who screenshot it for me are using. I only support six languages, but I get a lot of tickets from others, so I'm not sure where all this language stuff becomes an issue, but it doesn't seem to be a problem based on what I'm advocating for.
I'm confident that I can type just a tiny fraction of all Latin characters all world languages use. I'm sure that pretty much any Vietnamese word is way beyond my keyboard layout. No clue about writing any non-Latin script. Can you type any Cyrillic, Kanji, Hebrew, Abjad, …, character you see?
Disabling selection in non-textual parts of websites is unfortunately something that happens quite frequently, but people rarely notice.
This is naturally for websites without i18n. Very common especially in government and public websites.
Another example for buttons. Assuming I don't speak Chinese, how could I know what "下单" and "返回" mean without copy-pasting them into a translator?
If you are on mobile hands up? but why break UX for people who use a site in its native language?
I think a way to resolve things like this is to have media features.
For example:
@media(prefers-user-select: all){ * {user-select: all;} }
If it was an established known issue, then maybe people would do something like:
:not(:lang('base-lang')) { * {user-select: all;} }
- https://chromewebstore.google.com/detail/user-select-all/aoh...
- https://chromewebstore.google.com/detail/enable-user-select/...
- https://addons.mozilla.org/en-US/firefox/addon/select-like-a...
- https://addons.mozilla.org/en-US/firefox/addon/user-select/
It doesn't. It should, in an ideal world, but it definitely isn't the goal of people who design human-computer interfaces to allow everyone who interacts with a computer to be happy with the way it functions.
Of course there are many other bad design decisions that go into requiring me to do this, but it's still a real example of why all text should be selectable.
This is a standard UI convention used by all internal dev tools at my current company.
No.
Outlook mail for example is full of your principle, which means copying a mail address becomes a «hover over the not-selectable mail address to pop up a contact card, scroll down the contact card to where the mail address shows up again, but is again unselectable, click the "copy to clipboard" icon»
Just make text selectable.
In the Web version of Outlook, there are regularly times where the location of an appointment is a street address. That text is typically clickable. But the click action doesn't correspond to the choice of mapping service I might want to use in any one instance or to the fact that I might have other actions, like copying the address into another email/sms/etc. Outlook followed your philosophy. You can't select and copy that text, save for going through several auxiliary clicks just to get to a spot where you can. It's the most annoying behavior I can imagine.
That you think that you sitting in a meeting room talking it over with colleagues, or perhaps I'm a meeting in your own mind can assign legitimate uses and not, when something other than say security might be at stake, is just wrongheaded.
And by the way, that address being the link that it is is great 60%, 70% of the time. But when it's not it's clearly a design mistake.
I agree with your address example. That is user data, and it should be selectable.
Sure, icons on the desktop, or just about anything in a file/app explorer window, require a double-click by default, because the lineage of the main desktop area is just a file explorer window without the window decorations.
I think it might be about stakeholders wanting the web to "feel" more native and interactive. Double-clicking to "go" feels too much like you're interacting with the web as if it's a file browser. They want it to feel more immediate?
In principle I'd prefer the consistency of double-click or double-tap everywhere, but I'm used to adjusting based on context. Wouldn't double-tapping annoy everyone who primarily uses mobile devices?
If consistency between systems is more important than usability, it probably makes more sense to use single click to open in the OS (which has been an option in Windows for 30 years).
How do you do this?
> can, and usually should, prevent text selection
Please don't. You're overthinking. Be a better designer by designing less.
I swear, the platitudes are what kills me. Design and publish a site used by professionals and let me know what kind of feedback you get.
It's more annoying when your web site won't let me copy a package tracking number to paste into my chosen package tracking program. Maybe I don't want to use your system. Maybe the program I have is better.
Just because a web dev can't think of any reasons someone would want to copy text doesn't mean the reasons don't exist. It just means the developer lacks imagination.
Astonishing to me how many people will rally around "let me use it my way so that I can work around the setup in a way that fits my needs", as opposed to "fix your app to fit my needs".
Personally, though, I'd be more than happy for you to never use a system I made, so long as it meant I made the system more accessible for my users in ways that fit their needs.
I don't think that's an "exception." I think that's common enough to make me ask: "please don't make that text not selectable ever."
In the case that it is in another language, I'd probably just use google translate if I'm not fluent enough in reading the language.
I don't even want to ask how you came to this example.
Every day this forum becomes more like reddit.
https://github.com/TheJoeFin/Windows10-Community/issues/17
Fortunately, there is a setting for this in Firefox:
>about:config change: dom.w3c_pointer_events.scroll_by_pen.enabled set it to False.
It was something not specific of mobile apps, it was something present on internet for some decades (specially when bandwidth or mailbox sizes didn't added enough to be a concern to send something as image instead of text).
But in this particular moment of history, we have AIs that can extract the text from an image, do the translation and maybe write an answer about what is there. Or be a new attack vector against AI agents.
A browser (say, Firefox) is a "User Agent". Agents are supposed to act on our behalf, and in our best interests when ambiguities are present.
So, why are OUR user agents acting on behalf of website operators and their admins and users, and not on our behalf?
Having CSS that prevents usability shouldn't be implemented. Or it should be an easy toggle to turn on/off, without having to resort to Ublock Origin filters.
Same with 'prevention of right-click'. Why is this even implemented?
Or JavaScript also has a lot of onerous calls that are anti-user. I can understand why some of them are needed, but again, should be trivial to toggle.
So, why aren't our agents acting like proper agents?
I'm honestly at a loss with unselectable text, but for example capturing the right mouse button is very useful for applications.
Anyway, yes, it should be easy to turn those things off site-wide, like it's easy to zoom.
If the same operator also controls the entire adspace in the web, and has significant impact/input on other connected media devices beyond webbrowsers, what incentive do they have to empower users to "ignore" content, be it ads, ai slop, bad UI? Ther's literally none, the number still goes up revenue wise.
Unavoidable content delivery attached to revenue generation is the present and the future and the only solution is disonnected services/products that aren't tied to dollars.
I've often thought that this is actually a fundamental failure in mouse-and-screen based UI that we sadly didn't catch early enough in the design of the desktop. One of the mouse buttons should be dedicated to text selection and able to select any text. Document contents, browser contents, the text in an error message or a button... It should all be selectable and there should be a dedicated button for it. That frees up the other buttons to only ever mean "interact with something interactable."
(No suggestions for how we'd do this in touch; touch just has a different metaphor).
Now to my actual response to this: there is a new official tool for Android devices that allows doing OCR, text selection (including copying), translation and even search, as well as reverse image search and music detection. I'm talking about the Circle to Search feature; it is a great thing wherever you look at it from. Especially for this exact situation.
I wish there were a similar tool for desktop OSes (Linux, windows, macOS) that is as easy to use as CTS.
Android has a nice feature though, you can go into multitask view and hit "Select" and select any visible text for copy. Except that WHATSAPP BLOCKS IT FOR BUSINESS ACCOUNTS. You know, the kind that are likely in a local language, making it impossible to translate.
I hate tech so much, it makes me irrationally angry. So much busy work to make users' lives markedly WORSE.
One moment you're rage-posting on HackerNews, next you're authoring a manifesto on a typewriter in a remote cabin in the woods.
But for apps... good luck finding a solution.
At least Twitter, which I use the most, lets you select text.
The one I hate the most is Spotify. Copying the name of a song or an artist is something I do regularly, yet there’s no way to do it in the app.
... alright I see...
>"(Because Tinder is a rape-friendly lure trap.)"
I just sat down. Who the hell starts a conversation off like this?
you're saying that you load images, even store in my cache - but simply disallow same UX you allow on other images? wtf
A lot of websites include (anti-)features that make it extremely difficult for me to read and this severely limits the amount that I interact with the site. Features that hijack text selection in some way or preventing it entirely for whatever misguided reason are some of the worst offenders. Yes, I realise that not everything is for me -- I am getting that message loud and clear.
Preventing text selection is one of the most egregious and hostile ways to make your software unfriendly, but those insidious "share this quote" popout drawers are slowly fading in right behind it[0], hyperactively reflowing the layout and appending random snippets of selected text to the URL.
Reading is the most basic, most fundamental way to interact with the web. It's fundamental to using software in general. It seems to be necessary to point out that 'reading' and 'looking at' are not interchangeable terms. Frankly, designers should know better.
[0] Except they're not, because you can't select the text, obviously.
I often find myself having the tiniest of complaints about using something but never get around to writing about it.
- can’t select app reviews text (for translation for example)
- WhatsApp text bubbles don’t let you select text inside at all
- WeChat: exact same
Overall, it’s also very annoying when apps just don’t give you the standard OS options for a field. Like WhatsApp or WeChat does not give you access to the normal contextual menu at all, so no "translate" for your messages outside of what is or isn’t supported by the app itself, etc.
I added this uBO filter just yesterday:
app.termly.io##*:style(user-select: unset !important;)
MattDamonSpace•2h ago
Technology!
dhosek•2h ago