Quick question about -moz-user-select
Alex Faaborg
to content? Also, does anyone know our plans for implementing or not
implementing user-select for CSS3?
-Alex
Mike Beltzner
As I understand it, "-moz" prefixed items are CSS Extensions [1]
which haven't yet been formally added to a CSS specification. To avoid
namespace pollution and the games of "specification through
implementation", the -moz prefix is used to denote "this is only going
to work in Gecko based browsers".
I think (but certainly don't know) that it's exposed to content
because it's a proposed part of a set of user-interface enhancements
to the CSS3 specification [2]. The proposal's items seem to be
attempting to provide better granularity over the creation of UI
elements in web applications using CSS instead of images. Tantek Celik
(who authored the proposal) included some motivation for this
particular element:
> This value is one of the aspects of how a button behaves. The user
> cannot select any of the content inside the button. If for example,
> a user uses a pointing device to click on an element with user-
> select: none, what happens when the pointing device button is "down"
> is addressed by the user-input property, whereas when that pointing
> device button is "released", this property ensures that no selection
> of the contents of the element may remain. Another way to explain
> this is that user-select: none is what gives a button its "push-
> button-springy" feel. The value of 'none' is also useful for static
> text labels in a user interface which are not meant to be selected.
> For example, in the header of an email message window, the portion
> that says "Name:" cannot be selected, whereas the content following
> it can be. Such a static text label would also have user-input: none.
cheers,
mike
[1]: https://developer.mozilla.org/En/CSS_Reference:Mozilla_Extensions
[2]: http://www.w3.org/TR/1999/WD-css3-userint-19990916#user-select
L. David Baron
> Does anyone know the rationale behind why -moz-user-select is exposed to
> content? Also, does anyone know our plans for implementing or not
> implementing user-select for CSS3?
So user-select was dropped from css3 modules (along with a few other
related properties), because it was deemed to be a bad idea and/or
hard to fit with the rest of the CSS model (since properties
shouldn't be able to influence whether selectors match). I'm
actually not entirely sure of the details.
But we implemented -moz-user-{focus,input,modify,select}, and
changed them a good bit from what was ever proposed in any CSS
drafts, and have a whole bunch of dependencies on them.
It might actually be a good idea not to expose them to content; I'm
not sure how much they're used in the wild, though.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
David Bolter
and -webkit-user-select. Perhaps most significantly are hits in a few
toolkits... but we could work with them to change that.
cheers,
David
Alex Faaborg
I actually just encountered it in the wild for the first time and
found the behavior curious, which is why I was wondering the back
story on what it was meant to be used for.
> It might actually be a good idea not to expose them to content
I totally agree, from a user experience standpoint taking away the
user's ability to select stuff is obviously not ideal.
Thanks for the answers, I've added some notes to bug 477152
-Alex
On Feb 5, 2009, at 11:45 PM, L. David Baron wrote:
> On Thursday 2009-02-05 17:28 -0800, Alex Faaborg wrote:
>> Does anyone know the rationale behind why -moz-user-select is
>> exposed to
>> content? Also, does anyone know our plans for implementing or not
>> implementing user-select for CSS3?
>
> So user-select was dropped from css3 modules (along with a few other
> related properties), because it was deemed to be a bad idea and/or
> hard to fit with the rest of the CSS model (since properties
> shouldn't be able to influence whether selectors match). I'm
> actually not entirely sure of the details.
>
> But we implemented -moz-user-{focus,input,modify,select}, and
> changed them a good bit from what was ever proposed in any CSS
> drafts, and have a whole bunch of dependencies on them.
>
> It might actually be a good idea not to expose them to content; I'm
> not sure how much they're used in the wild, though.
>
> -David
>
> --
> L. David Baron http://dbaron.org/
> Mozilla Corporation http://www.mozilla.com/
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Markus Stange
> It might actually be a good idea not to expose them to content; I'm
> not sure how much they're used in the wild, though.
GMails uses -moz-user-select on their new custom buttons.
http://stopdesign.com/archive/2009/02/04/recreating-the-button.html has
more information on those buttons but doesn't mention -moz-user-select.
-Markus
Benjamin Smedberg
>> I'm not sure how much they're used in the wild, though.
>
>
> I actually just encountered it in the wild for the first time and found
> the behavior curious, which is why I was wondering the back story on
> what it was meant to be used for.
>
>> It might actually be a good idea not to expose them to content
>
> I totally agree, from a user experience standpoint taking away the
> user's ability to select stuff is obviously not ideal.
On the other hand, if you're designing web UI, removing the ability to
select things is often what you want. Why can't we provide this ability by
default, and allow users to disable it?
* as a pref, perhaps
* as an extension, certainly
* by manually editing usercontent.css
--BDS