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;
}
I think it's safe to assume that being unable to select text on this page is not unintentional, as several comments here assume, nor "ironic", but an intentional effort to demonstrate how annoying this behavior is. *##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.
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.
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?
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.
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;} }
But that wouldn't guarantee you could select text on an interactive element, plenty of other things could prevent it.If it was an established known issue, then maybe people would do something like:
:not(:lang('base-lang')) { * {user-select: all;} }
It looks like there are plenty of extensions for this:- 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.
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.
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.
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.
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.
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.
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
MattDamonSpace•1h ago
Technology!
dhosek•1h ago