Hacker News Reader

Comment by jscheel | Hacker News Reader

I'm not sure "user-select: none" is "2 days away." I shudder to think about the hacks I've done to make it work. My favorite is capturing clicks on an overlay, then translating the click point to where it needs to be and simulating a new click with the modified values on the underlying layer, which also happened to be in an iframe. I still get shivers.

View on HN

If you care for "user-select: none", you might be surprised to know that there wasn't an official spec for it to help the browsers interoperably converge, and you might be happy to learn that I just made one: http://dev.w3.org/csswg/css-ui-4/#content-selection

Awesome, thanks for submitting that!

Love that standards are being written in the discussion here. As each standard hits 90% I'm going to write a detailed post on the use of them which will go with the email - I've made a start on user-select. I'd be happy to credit you along with a link to this standard if you'd like. Or I'd love to get your feedback on a draft of the article as you seem to be the authority on this! Drop me an email (me@alexmuir.com) if you get a moment.

I got a moment, so I did drop you a mail:) Thanks for looping me in.

This is my first exposure to "user-select: none" and it strikes me as a copy control mechanism. Is that the only reason for this, or are their other use cases?

Off the top of my head, I could imagine it being useful to prevent accidental selection of text in, say, a paint app or something. *I may be misinterpreting the purpose, however.

Very useful for kiosks where people interact with a screen and have no clue they are using a maximized browser. Selecting text of labels is not expected in a "native" app

I'm curious what you're trying to do. That rule sounds like it would be perfect for causing the same sort of irritation as the "disable right-click" and "disable copy-paste" scripts that were popular years ago.

The spec suggests that it would more be to avoid selecting things that are not part of the text flow of the document, which would be a usability win. i.e. captions that are in the middle of the flow, etc.

But you're right to point out it could be used by the unscrupulous sort of people who also like to disable right click, and that would indeed by highly annoying.

If you have suggestions on how to mitigate that (making the feature less useful as a copy protection without affecting (too much) the intended use, I'm happy to update the spec.

Is a modifier key possible? E.g. holding down shift allows you to select all text? Or a context-menu option on the unselectable text to copy the whole block? Excuse my naiveté.

CSS is device neutral and works on things that don't have shift keys or context menus, so we can't specify the mechanism. However, we can make it allowed, or even recommended for browsers to provide a way to select anyway, even if the spec leaves it up to the browser what UI it wants to use for that.

Done: https://twitter.com/CSScommits/status/587951029661990912

It's not, I promise. For our product (https://populr.me), we want to keep our interface's styles and javascript completely separate from our user's themes' custom styles and javascript. Our editor actually loads the user's themed page into an iframe and overlays interface elements in the parent page on top of everything.

Reply on news.ycombinator.com