The “expando” stuff is certainly bizarre, but there’s nothing weird about an attribute for non-selectable text; it’s just never been standardized. KDE and Safari have “-khtml-user-select: none”, and I think Mozilla/Firefox have their own attribute name. It’s useful functionality: all other GUIs distinguish between text as content and text as a part of the UI, and don’t let you select text in window titlebars, menus, checkbox titles, etc.
This is too obvious, but:
“Microsoft made Web development unbearable for 12 years, and all I got was this lousy t-shirt”
Me again. I read through the “expando” docs, and it’s actually not that bizarre. Shall I explain?
1. The “expando” property controls the ability to add arbitrary named properties to DOM objects. If expando is turned off, attempts to set nonstandard properties will fail. As the docs point out, this can be a useful way to make sure you’re not screwing up by misspelling or mis-capitalizing a property name.
2. The “unselectable” property isn’t hardcoded into the DOM; there isn’t some native instance variable corresponding to it. Rather, it’s just stored as one of these arbitrary “expando” properties on the DOM object. This makes sense, if it was added late in a development cycle or it wasn’t felt to be worth the resources of adding another ivar to the native object.
3. So what the docs are pointing out is that, if you turned off the “expando” property on a DOM object, then you can’t set its “unselectable” property, because it’s not recognized as a standard property of the object.
I’m all in favor of making fun of Microsoft (I work for Apple, after all), and there’s plenty to make fun of them about, but this particular thingy happens to make sense if you read through the docs.
What are they smoking? Expando 2.0
— Andy 
> -khtml-user-select: none
So Safari implements this feature in an accepted vendor-specific fashion, in a way that can ultimately be overridden by the end user (presumably “* { -khtml-user-select: inherit ! important }” or something would work in a user stylehseet?)
OK, I see the similarity. Do you see the difference?
— Mark
UNSELECTABLE may be used for DIV elements. So here’s a good idea: why don’t we all start wrapping all our page content with div unselectable = on?
Then all text everywhere will be unselectable, but only for IE users.
The date of this post? It’s significant, right?
> The date of this post? It’s significant, right?
No. I’m not participating in Internet Jackass Day; I don’t need a special day to be a jackass on the internet. And the described browser behavior is real.
— Mark
I actually wanted to use the “unselectable” attribute in a web app I’m designing. However, it also seems to mean that the dom element that is unselectable not only can’t be visibly selected, but also does seem to cancel keyboard events after the user clicks on it - which is somewhere between side effect and “makes some amount of sense, even if it is unfortunate.”
— LKM