8 ms·

As a web dev, I fully agree with this, but with a huge exception: clickable text. Anything that is meant to be read as content should absolutely, without fail,

As a web dev, I fully agree with this, but with a huge exception: clickable text. 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.

hkon 1y ago
I disagree. Selection takes priority.
watwut 1y ago
Totally not, those ahould be selectable too.
- catapart 1y ago
  When text becomes selected, instead of allowing the control to work as expected, the focus cannot move between the elements as expected. It breaks the UX for keyboard-only users. I can appreciate that this is not something everyone has to contend with, but for accessibility's sake, the default behavior should at the very least be mitigated. So you're advocating for either hurting the keyboard experience or injecting javascript to over-manage the experience. 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.
  - huimang 1y ago
    This breaks translation. Text must be selectable.
    - catapart 1y ago
      Good UX means including translations for supported languages, not telling the user "do it yourself by highlighting content". 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.
      - ginko 1y ago
        What about unsupported languages?
        davorak 1y ago
        Even when the language is supported I have had GDPR popups block that language selection. The text in the popup was also not selectable which made it very hard to read what I was or was not agreeing to.
    - odo1242 1y ago
      What would be your ideal solution to the described problem? (Clicking on UI elements selecting text instead of processing the click)
      - catapart 1y ago
        I know you're not asking me, but I would really love the "copy" feature added to ALL context menus. 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.
  - djtango 1y ago
    I personally like to click text absent mindedly when I'm reading a bit like holding your finger while reading Also if you're a non native speaker you want to be able to select the text so you can translate it
    - catapart 1y ago
      Why would you want to translate "My Account" into another language? And, more pertinently, why should I support it, at the expense of keyboard-only users?
      - Ghoelian 1y ago
        > Why would you want to translate "My Account" into another language? When you don't know the language or what "My Account" means? Not everyone speaks English.
        catapart 1y ago
        And you also can't understand the icon? And the context? And the translations I provided?
        Ukv 1y ago
        A menu with "我的帳戶" in it, and often a generic icon or no icon at all, doesn't really have sufficient context to determine what the button means. If the website is already translated into your language then great, but many websites aren't (because it's a small site, or you don't speak one of the most common languages, or it's aimed at a different audience, etc.)
        catapart 1y ago
        Ah, so the website had bad UX? I think we've found the issue!
        1y ago
  - whstl 1y ago
    What's that behavior? 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.
    - catapart 1y ago
      Use a mouse to click inside of a word link (like "threads") in the HN header. Try to drag to highlight. Note that the link tries to drag instead of highlighting. This is default behavior for anchors because of the issues that it would otherwise cause with the whole selection API. 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.
      - whstl 1y ago
        Then I don't think the article is advocating for what you think it is. You are saying "tab headers, buttons, or even text-sparse tiles [...] should, prevent text selection". The website is advocating for not disabling selection, not for enabling in random places.
        catapart 1y ago
        I don't think you understand the technical applications that the website is advocating for. I can appreciate that the technicalities are frustrating, but the web works the way it works, for better or worse.
        whstl 1y ago
        Nope. I am saying the web should work the way it is, like Hacker News does, as I already have brought up elsewhere. You are saying "tab headers, buttons, or even text-sparse tiles [...] should, prevent text selection". The article is saying the same thing I am. Basically don't do `user-select: none;`. The example is itself in the article's CSS.
whstl 1y ago
100% disagree. 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.
- catapart 1y ago
  isn't selectable because it breaks the UX for keyboard-only users. 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.
  - whstl 1y ago
    I already asked below, how and where does it break? 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.
    - catapart 1y ago
      Give me an example of a real-world use case where this caused you an issue, and I'll show you where their UX design is poorly made, rather than a need for selectable text in a clickable element.
      - whstl 1y ago
        Sure, I had one recently. 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.
Sevii 1y ago
I do not want to have to go into the dev console to copy the text of some random thing you think shouldn't be clickable. It's happened way too many times.
csmantle 1y ago
I sometimes shop on Japanese webstores for CDs and merch. Many of these sites are actually where natives buy stuff, so few to no translations are available there. It's a routine for me to copy the Japanese on the nav bar to a translator, then get a list like "Cart <tab> Orders <tab> Account <tab> Help". Another example for buttons. Assuming I don't speak Chinese, how could I know what "下单" and "返回" mean without copy-pasting them into a translator?
- ZYbCRq22HbJ2y7 1y ago
  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/aohfkhjeigihecojbfdalfmaflgpdpbk?pli=1 https://chromewebstore.google.com/detail/user-select-all/aoh... - https://chromewebstore.google.com/detail/enable-user-select/hipjlflbbjaojdoecdgbelgofbfckpai https://chromewebstore.google.com/detail/enable-user-select/... - https://addons.mozilla.org/en-US/firefox/addon/select-like-a-boss/ https://addons.mozilla.org/en-US/firefox/addon/select-like-a... - https://addons.mozilla.org/en-US/firefox/addon/user-select/ https://addons.mozilla.org/en-US/firefox/addon/user-select/
  - csmantle 1y ago
    Yeah that's possible for us geeks ;) But UX talks about how everyone interacts with our site. We couldn't just ask all visitors to be experts.
    - ZYbCRq22HbJ2y7 1y ago
      > But UX talks about how everyone interacts 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.
Hobadee 1y ago
Real-world example I use nearly daily: Selecting the nav header that's the ticket number in our ticketing system. I copy-paste the number elsewhere. 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.
- n8m8 1y ago
  I almost always copy this by double clicking after the `/` in the URL
  - fkyoureadthedoc 1y ago
    Enter, stage left, ServiceNow hell urls
  - grues-dinner 1y ago
    Gitlab has killed this with their slide in issues. If you have an issue open, and you copy the address, it's just a huge unique ID context thing. So you have to scroll to the top and use the little copy link button at the top of the page.
- tetromino_ 1y ago
  Then all those nav headers need to have a little button on the side to open a floating div with copy-pasteable content. Or, if needed - different versions of copy-pasteable content (as a command line for copy-pasting into the terminal, json, etc.) This is a standard UI convention used by all internal dev tools at my current company.
  - lupire 1y ago
    Oh don't worry, it's a tooltip, so you can see it, but not copy it.
- Anon1096 1y ago
  Something I absolutely loved while working at Meta was that basically every internal system has some kind of ticket ID, and more importantly, wherever it's displayed near the top of the page you very likely can click-to-copy it. And the click-to-copy gives you a rich version of the ticket ID that you could paste into Google Docs and have the link to the ticket page embedded already. Really small feature that improved the life of engineers a lot considering how much you're copy/pasting IDs around. It's the type of UX care that I expect ServiceNow type third party systems will never have.
procaryote 1y ago
> 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. 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.
sbuttgereit 1y ago
A case can be made for graphic like elements like buttons, but for text: treat it like text even if it's clickable. 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.
- gdwatson 1y ago
  The point isn't that the developer should disable text selection whenever he thinks it's unnecessary, which would indeed be silly. It's that sometimes the user interface rules for navigating selectable text conflict or interfere with the user interface rules for navigating, say, a set of tab panes. In that situation, making the tab titles selectable will cause grief. I agree with your address example. That is user data, and it should be selectable.
  - catapart 1y ago
    I appreciate your understanding!
  - sbuttgereit 1y ago
    I don't think we disagree, too much. tab panes matches the "button" example. However, I am sympathetic to those arguing translation. Sometimes I'll visit Japanese or Chinese websites. With some frequency, even if most of the site has an English edition, I'll find some UI element not translated, including buttons and the like... OK I think it was the commenter that I responded to, in a different reply said... just Google it if it's a single word. Great! But I don't even know where to begin to get the right characters from my old fashioned US keyboard. So now I have to Google for how to use my keyboard to get the characters I want, which also may need pre-requisite knowledge of the language I'm trying to translate (radicals and all that jazz)... that's a heavier lift than may be anticipated and where a simple copy/paste into an appropriate translator would make things much, much easier. I would suggest this: make everything buttons, links, tabs, etc. selectable and copyable unless there is a real explicit and compelling reason to do otherwise. Now to be fair, I'm old enough to have been "online" in some fashion or another since before general public internet access availability was a thing... so my expectations for butter-like user experiences are low and my desire to do any damn thing I want high... but even today, there are probably still more websites which don't stop you from copying anything than there are searching for that polished experience where only the right things can be selected. The discontinuity and the deviation from the expectation that I can copy anything I also find as something which diminishes the user experience, even if occasionally I'm annoyed by over selecting things.
bobbylarrybobby 1y ago
It's always bothered me that links on webpages are single click to open. They should require double clicking to open (like just about everything else on a computer) and single click should be used to start selecting text, like everywhere else on a computer.
- catapart 1y ago
  You know, I've often wondered how much simpler UX would be if this had been the case from the start. Hard to make any predictions, but one can optimistically dream...
  - dylan604 1y ago
    I'm guessing it would be much more disruptive for touch devices. It would definitely reduce the number of erroneous clicks when just trying to touch to scroll the screen.
- cosmic_cheese 1y ago
  A double-click would better represent intent/consent, too, which the web has had long had issues with. Accidentally clicking things is too easy and frequent.
- harshreality 1y ago
  When you run an app from the taskbar or start menu, you single-click on the app icon, or single-click on the Start menu button and then single-click on the app. 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?
gdwatson 1y ago
I agree. The closer to a traditional desktop U.I. you get, the jankier selecting clickable text becomes. For a simple web form, leaving labels selectable is no big deal and probably a win. But for something trying to behave like a tabbed dialog box, it breaks navigation left and right.
xnx 1y ago
> It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way. 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.
- catapart 1y ago
  Ah yes "design less" by "forcing selectability where it is not a feature by default". 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.
tomrod 1y ago
As a long-time web user, some push back. I just want text. Give me clickable links if needed. HTMLv2 was enough for most information, most of the rest is eye candy.
reaperducer 1y ago
It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way. 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.
- catapart 1y ago
  [flagged]
- 9dev 1y ago
  That is not what they meant and you know it. They were talking about buttons labelled "OK", "Back", or "Confirm". Buttons that wouldn’t be selectable in a native app either, but somehow we don’t complaints about that here.
gspencley 1y ago
I disagree. In a lot of cases text will be clickable, but will also contain content that you want to copy/paste into Wikipedia or a search engine etc. Think annotations (click on this text for more information) or headers/titles that are a proper noun that references something public... like a person's name or a place or a type of object or something. 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."
nahumba 1y ago
Do you know how many times i wanted to select the clickable link in google search result?
- kuekacang 1y ago
  Back in the day I requested chrome feature "copy text" in addition to "copy link" on <a> context menu. Now I tried it it's no longer there.
  - TeMPOraL 1y ago
    It's not? Just checked a Chrome instance I had handy, it has all three options in the context menu - "Copy", "Copy link address" and "Copy link to highlight". First one copies text in between <a> ... </a>, second one copies the href attribute, and third one copies the link to page you're on with that weird URL framgment-based arbitrary text anchor/highlight scheme. All three work on Google search results for me.
    - kuekacang 1y ago
      Maybe weird behavior on my end? Or perhaps you need to select part of <a>'s content to trigger it?
slater 1y ago
Counterpoint to that is the bizarre "everything must be a link!" state of things on modern websites. Heck, even on hn - click on a user's name in these replies, it goes to their profile page. great! then on that profile page, the user's name is... a link back to the same page.
sethammons 1y ago
No, text should be selectable, even when links. The amount of times I've accidentally highlighted instead of clicking? Maybe a couple? The amount of times that frustrated or confused me? Absolutely zero. I want to select the text of a link and copy the text of a link. I want to do this but I run into issues _daily_, esp. on mobile. PagerDuty app, I'm looking at you! Mobile seems to assume that you, in no world ever, could ever want to select text.
- grues-dinner 1y ago
  Being unable to select text out of a link is absolutely infuriating when you want to just copy a piece of it, either because it's a reference number or something, or you want to translate it. Mobile is nearly impossible, and desktop is also fiddly in many cases. Often when translating it's easier to just OCR the area with the dictionary app, which is madness when it started as text.
  - jayknight 1y ago
    At least in Firefox, holding down alt while selecting let's you do it within a link without triggering a click event.
    - follower 1y ago
      TIL. Thank you! Now I just have to remember this next time I need to select text within a link. :)
    - andreashaerter 1y ago
      Wow. How could I not know but needed this since ages. Thank you!
- tomaskafka 1y ago
  Double click selects text. What to do with web app elements where people double click or rapidly click?
  - 1y ago
temporallobe 1y ago
All text should be selectable (and therefore readable) to support accessibility tools - at least if you’re app or site is Section 508 compliant or similar.
spankalee 1y ago
This would be a mistake, a common one though. Instead of disallowing selection on the text with CSS, call `event.preventDefault()` in the click handler. This keeps a click that you handle from triggering the built-in text selection path, but you can still click-and-drag to select text.
klibertp 1y ago
As long as you still offer an easy way to highlight the button text. Triple-click (at least in FF on Linux) highlights paragraphs or other block-elements contents; it should be allowed on things where a single-click does navigation. This would be very out of the way for normal users, but would allow easily and quickly highlighting (and copying) parts of the interface.
48terry 1y ago
I want to share which tabs on this tabpanel are the most interesting for a friend of mine to read. How would you suggest I get their labels?
silverwind 1y ago
Accidential drags are can be detected an prevented in JS, which is imho the best solution.
jmull 1y ago
Please don't try to second guess what should be selectable/copyable!
mvdtnz 1y ago
[flagged]
mc3301 1y ago
There are often button which do important things, I want to double check the meaning of before clicking them. Selecting the text to copy/paste into a translator is absolutely beneficial. And in Japan, the general layout of the "Go back to previous screen" and "confirm and continue" (left and right, respectively), is reversed from what English readers might be used to. So if I can't select the text... I open up a hand-drawing-chinese-characters app and slowly draw out each character? I'd rather be able to select the text. Note: unfortunately, so many button in Japanese UIs are actually .png files. I know this from experience of using and building apps and websites here.
gradstudent 1y ago
Strong disagree. I often want to grab the contents of a page, tab headers and all, and paste that into a text editor for subsequent manipulation. Please don't design your pages in a way that makes unilateral decisions on behalf of the user.

hkon 1y ago

I disagree. Selection takes priority.

watwut 1y ago

Totally not, those ahould be selectable too.

catapart 1y ago
When text becomes selected, instead of allowing the control to work as expected, the focus cannot move between the elements as expected. It breaks the UX for keyboard-only users. I can appreciate that this is not something everyone has to contend with, but for accessibility's sake, the default behavior should at the very least be mitigated. So you're advocating for either hurting the keyboard experience or injecting javascript to over-manage the experience. 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.
- huimang 1y ago
  This breaks translation. Text must be selectable.
  - catapart 1y ago
    Good UX means including translations for supported languages, not telling the user "do it yourself by highlighting content". 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.
    - ginko 1y ago
      What about unsupported languages?
      - davorak 1y ago
        Even when the language is supported I have had GDPR popups block that language selection. The text in the popup was also not selectable which made it very hard to read what I was or was not agreeing to.
  - odo1242 1y ago
    What would be your ideal solution to the described problem? (Clicking on UI elements selecting text instead of processing the click)
    - catapart 1y ago
      I know you're not asking me, but I would really love the "copy" feature added to ALL context menus. 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.
- djtango 1y ago
  I personally like to click text absent mindedly when I'm reading a bit like holding your finger while reading Also if you're a non native speaker you want to be able to select the text so you can translate it
  - catapart 1y ago
    Why would you want to translate "My Account" into another language? And, more pertinently, why should I support it, at the expense of keyboard-only users?
    - Ghoelian 1y ago
      > Why would you want to translate "My Account" into another language? When you don't know the language or what "My Account" means? Not everyone speaks English.
      - catapart 1y ago
        And you also can't understand the icon? And the context? And the translations I provided?
        Ukv 1y ago
        A menu with "我的帳戶" in it, and often a generic icon or no icon at all, doesn't really have sufficient context to determine what the button means. If the website is already translated into your language then great, but many websites aren't (because it's a small site, or you don't speak one of the most common languages, or it's aimed at a different audience, etc.)
        catapart 1y ago
        Ah, so the website had bad UX? I think we've found the issue!
        1y ago
- whstl 1y ago
  What's that behavior? 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.
  - catapart 1y ago
    Use a mouse to click inside of a word link (like "threads") in the HN header. Try to drag to highlight. Note that the link tries to drag instead of highlighting. This is default behavior for anchors because of the issues that it would otherwise cause with the whole selection API. 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.
    - whstl 1y ago
      Then I don't think the article is advocating for what you think it is. You are saying "tab headers, buttons, or even text-sparse tiles [...] should, prevent text selection". The website is advocating for not disabling selection, not for enabling in random places.
      - catapart 1y ago
        I don't think you understand the technical applications that the website is advocating for. I can appreciate that the technicalities are frustrating, but the web works the way it works, for better or worse.
        whstl 1y ago
        Nope. I am saying the web should work the way it is, like Hacker News does, as I already have brought up elsewhere. You are saying "tab headers, buttons, or even text-sparse tiles [...] should, prevent text selection". The article is saying the same thing I am. Basically don't do `user-select: none;`. The example is itself in the article's CSS.

whstl 1y ago

100% disagree. 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.

catapart 1y ago
isn't selectable because it breaks the UX for keyboard-only users. 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.
- whstl 1y ago
  I already asked below, how and where does it break? 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.
  - catapart 1y ago
    Give me an example of a real-world use case where this caused you an issue, and I'll show you where their UX design is poorly made, rather than a need for selectable text in a clickable element.
    - whstl 1y ago
      Sure, I had one recently. 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.

Sevii 1y ago

I do not want to have to go into the dev console to copy the text of some random thing you think shouldn't be clickable. It's happened way too many times.

csmantle 1y ago

I sometimes shop on Japanese webstores for CDs and merch. Many of these sites are actually where natives buy stuff, so few to no translations are available there. It's a routine for me to copy the Japanese on the nav bar to a translator, then get a list like "Cart <tab> Orders <tab> Account <tab> Help". Another example for buttons. Assuming I don't speak Chinese, how could I know what "下单" and "返回" mean without copy-pasting them into a translator?

ZYbCRq22HbJ2y7 1y ago
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/aohfkhjeigihecojbfdalfmaflgpdpbk?pli=1 https://chromewebstore.google.com/detail/user-select-all/aoh... - https://chromewebstore.google.com/detail/enable-user-select/hipjlflbbjaojdoecdgbelgofbfckpai https://chromewebstore.google.com/detail/enable-user-select/... - https://addons.mozilla.org/en-US/firefox/addon/select-like-a-boss/ https://addons.mozilla.org/en-US/firefox/addon/select-like-a... - https://addons.mozilla.org/en-US/firefox/addon/user-select/ https://addons.mozilla.org/en-US/firefox/addon/user-select/
- csmantle 1y ago
  Yeah that's possible for us geeks ;) But UX talks about how everyone interacts with our site. We couldn't just ask all visitors to be experts.
  - ZYbCRq22HbJ2y7 1y ago
    > But UX talks about how everyone interacts 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.

Hobadee 1y ago

Real-world example I use nearly daily: Selecting the nav header that's the ticket number in our ticketing system. I copy-paste the number elsewhere. 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.

n8m8 1y ago
I almost always copy this by double clicking after the `/` in the URL
- fkyoureadthedoc 1y ago
  Enter, stage left, ServiceNow hell urls
- grues-dinner 1y ago
  Gitlab has killed this with their slide in issues. If you have an issue open, and you copy the address, it's just a huge unique ID context thing. So you have to scroll to the top and use the little copy link button at the top of the page.
tetromino_ 1y ago
Then all those nav headers need to have a little button on the side to open a floating div with copy-pasteable content. Or, if needed - different versions of copy-pasteable content (as a command line for copy-pasting into the terminal, json, etc.) This is a standard UI convention used by all internal dev tools at my current company.
- lupire 1y ago
  Oh don't worry, it's a tooltip, so you can see it, but not copy it.
Anon1096 1y ago
Something I absolutely loved while working at Meta was that basically every internal system has some kind of ticket ID, and more importantly, wherever it's displayed near the top of the page you very likely can click-to-copy it. And the click-to-copy gives you a rich version of the ticket ID that you could paste into Google Docs and have the link to the ticket page embedded already. Really small feature that improved the life of engineers a lot considering how much you're copy/pasting IDs around. It's the type of UX care that I expect ServiceNow type third party systems will never have.

procaryote 1y ago

> 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. 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.

sbuttgereit 1y ago

A case can be made for graphic like elements like buttons, but for text: treat it like text even if it's clickable. 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.

gdwatson 1y ago
The point isn't that the developer should disable text selection whenever he thinks it's unnecessary, which would indeed be silly. It's that sometimes the user interface rules for navigating selectable text conflict or interfere with the user interface rules for navigating, say, a set of tab panes. In that situation, making the tab titles selectable will cause grief. I agree with your address example. That is user data, and it should be selectable.
- catapart 1y ago
  I appreciate your understanding!
- sbuttgereit 1y ago
  I don't think we disagree, too much. tab panes matches the "button" example. However, I am sympathetic to those arguing translation. Sometimes I'll visit Japanese or Chinese websites. With some frequency, even if most of the site has an English edition, I'll find some UI element not translated, including buttons and the like... OK I think it was the commenter that I responded to, in a different reply said... just Google it if it's a single word. Great! But I don't even know where to begin to get the right characters from my old fashioned US keyboard. So now I have to Google for how to use my keyboard to get the characters I want, which also may need pre-requisite knowledge of the language I'm trying to translate (radicals and all that jazz)... that's a heavier lift than may be anticipated and where a simple copy/paste into an appropriate translator would make things much, much easier. I would suggest this: make everything buttons, links, tabs, etc. selectable and copyable unless there is a real explicit and compelling reason to do otherwise. Now to be fair, I'm old enough to have been "online" in some fashion or another since before general public internet access availability was a thing... so my expectations for butter-like user experiences are low and my desire to do any damn thing I want high... but even today, there are probably still more websites which don't stop you from copying anything than there are searching for that polished experience where only the right things can be selected. The discontinuity and the deviation from the expectation that I can copy anything I also find as something which diminishes the user experience, even if occasionally I'm annoyed by over selecting things.

bobbylarrybobby 1y ago

It's always bothered me that links on webpages are single click to open. They should require double clicking to open (like just about everything else on a computer) and single click should be used to start selecting text, like everywhere else on a computer.

catapart 1y ago
You know, I've often wondered how much simpler UX would be if this had been the case from the start. Hard to make any predictions, but one can optimistically dream...
- dylan604 1y ago
  I'm guessing it would be much more disruptive for touch devices. It would definitely reduce the number of erroneous clicks when just trying to touch to scroll the screen.
cosmic_cheese 1y ago
A double-click would better represent intent/consent, too, which the web has had long had issues with. Accidentally clicking things is too easy and frequent.
harshreality 1y ago
When you run an app from the taskbar or start menu, you single-click on the app icon, or single-click on the Start menu button and then single-click on the app. 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?

gdwatson 1y ago

I agree. The closer to a traditional desktop U.I. you get, the jankier selecting clickable text becomes. For a simple web form, leaving labels selectable is no big deal and probably a win. But for something trying to behave like a tabbed dialog box, it breaks navigation left and right.

xnx 1y ago

> It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way. 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.

catapart 1y ago
Ah yes "design less" by "forcing selectability where it is not a feature by default". 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.

tomrod 1y ago

As a long-time web user, some push back. I just want text. Give me clickable links if needed. HTMLv2 was enough for most information, most of the rest is eye candy.

reaperducer 1y ago

It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way. 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.

catapart 1y ago
[flagged]
9dev 1y ago
That is not what they meant and you know it. They were talking about buttons labelled "OK", "Back", or "Confirm". Buttons that wouldn’t be selectable in a native app either, but somehow we don’t complaints about that here.

gspencley 1y ago

I disagree. In a lot of cases text will be clickable, but will also contain content that you want to copy/paste into Wikipedia or a search engine etc. Think annotations (click on this text for more information) or headers/titles that are a proper noun that references something public... like a person's name or a place or a type of object or something. 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."

nahumba 1y ago

Do you know how many times i wanted to select the clickable link in google search result?

kuekacang 1y ago
Back in the day I requested chrome feature "copy text" in addition to "copy link" on <a> context menu. Now I tried it it's no longer there.
- TeMPOraL 1y ago
  It's not? Just checked a Chrome instance I had handy, it has all three options in the context menu - "Copy", "Copy link address" and "Copy link to highlight". First one copies text in between <a> ... </a>, second one copies the href attribute, and third one copies the link to page you're on with that weird URL framgment-based arbitrary text anchor/highlight scheme. All three work on Google search results for me.
  - kuekacang 1y ago
    Maybe weird behavior on my end? Or perhaps you need to select part of <a>'s content to trigger it?

slater 1y ago

Counterpoint to that is the bizarre "everything must be a link!" state of things on modern websites. Heck, even on hn - click on a user's name in these replies, it goes to their profile page. great! then on that profile page, the user's name is... a link back to the same page.

sethammons 1y ago

No, text should be selectable, even when links. The amount of times I've accidentally highlighted instead of clicking? Maybe a couple? The amount of times that frustrated or confused me? Absolutely zero. I want to select the text of a link and copy the text of a link. I want to do this but I run into issues _daily_, esp. on mobile. PagerDuty app, I'm looking at you! Mobile seems to assume that you, in no world ever, could ever want to select text.

grues-dinner 1y ago
Being unable to select text out of a link is absolutely infuriating when you want to just copy a piece of it, either because it's a reference number or something, or you want to translate it. Mobile is nearly impossible, and desktop is also fiddly in many cases. Often when translating it's easier to just OCR the area with the dictionary app, which is madness when it started as text.
- jayknight 1y ago
  At least in Firefox, holding down alt while selecting let's you do it within a link without triggering a click event.
  - follower 1y ago
    TIL. Thank you! Now I just have to remember this next time I need to select text within a link. :)
  - andreashaerter 1y ago
    Wow. How could I not know but needed this since ages. Thank you!
tomaskafka 1y ago
Double click selects text. What to do with web app elements where people double click or rapidly click?
- 1y ago

temporallobe 1y ago

All text should be selectable (and therefore readable) to support accessibility tools - at least if you’re app or site is Section 508 compliant or similar.

spankalee 1y ago

This would be a mistake, a common one though. Instead of disallowing selection on the text with CSS, call `event.preventDefault()` in the click handler. This keeps a click that you handle from triggering the built-in text selection path, but you can still click-and-drag to select text.

klibertp 1y ago

As long as you still offer an easy way to highlight the button text. Triple-click (at least in FF on Linux) highlights paragraphs or other block-elements contents; it should be allowed on things where a single-click does navigation. This would be very out of the way for normal users, but would allow easily and quickly highlighting (and copying) parts of the interface.

48terry 1y ago

I want to share which tabs on this tabpanel are the most interesting for a friend of mine to read. How would you suggest I get their labels?

silverwind 1y ago

Accidential drags are can be detected an prevented in JS, which is imho the best solution.

jmull 1y ago

Please don't try to second guess what should be selectable/copyable!

mvdtnz 1y ago

[flagged]

mc3301 1y ago

There are often button which do important things, I want to double check the meaning of before clicking them. Selecting the text to copy/paste into a translator is absolutely beneficial. And in Japan, the general layout of the "Go back to previous screen" and "confirm and continue" (left and right, respectively), is reversed from what English readers might be used to. So if I can't select the text... I open up a hand-drawing-chinese-characters app and slowly draw out each character? I'd rather be able to select the text. Note: unfortunately, so many button in Japanese UIs are actually .png files. I know this from experience of using and building apps and websites here.

gradstudent 1y ago

Strong disagree. I often want to grab the contents of a page, tab headers and all, and paste that into a text editor for subsequent manipulation. Please don't design your pages in a way that makes unilateral decisions on behalf of the user.