On Monday, November 12, 2018 at 2:57:14 AM UTC+9, Emilio Cobos Álvarez wrote: > Summary: Unprefix the -moz-user-select property, so that it works > without the -moz- prefix. > > We happen to be supporting the -webkit- prefixed version of the > property, but other browsers support it also unprefixed, which causes a > lot of confusion. > > As part of this work I'm also unshipping the following values from > content (or entirely, if they have no internal usage): > > * -moz-all: Was meant to behave as an alias of `all`, but in practice > that's not true. Plus all external usage I found was followed by a > -webkit-user-select: all which would override it. > > * -moz-text: It's an internal value which was introduced in bug > 1181130. It's only used from contenteditable.css and I haven't > investigated removing it completely, but I'm restricting it to > user-agent stylesheets. I found no relevant external usage. > > * tri-state, element, elements, toggle: We parse these but do nothing > with them (lol, I know, right?). They're no longer in the spec so should > be removed. > > We also have a non-standard '-moz-none' alias to 'none' which I haven't > investigated removing yet, but probably should in a followup to this bug. > > Bug: 1492958 for the removal of non-standard values, 1492739 for the > unprefixing. > > Link to standard: https://drafts.csswg.org/css-ui-4/#propdef-user-select > > Platform coverage: All > > Estimated or target release: FF65 > > Preference behind which this will be implemented: None > > Is this feature enabled by default in sandboxed iframes? Yes > > DevTools bug: N/A > > Do other browser engines implement this? > > This is an interesting question. The current status is: > > * Blink supports user-select unprefixed and -webkit- prefixed, with > the same values we'd support after this bug (except our non-standard > -moz-none alias). > > * Edge supports the -ms- prefixed version of the property, and the > -webkit- prefixed version. Edge is the only engine to support the > 'contain' value. > > * WebKit only supports the -webkit- prefixed version. > > So all browsers support as of today the -webkit- prefixed version of the > property, which is a fun state of affairs, with a slightly different set > of values. > > I think we should try to unprefix sooner than later so this doesn't end > up being something similar to '-webkit-apperance'. Given Chrome supports > the same thing as us unprefixed, I think it's reasonable to do this. > > web-platform-tests: Test coverage for all the values is pre-existing. > There's unfortunately little coverage in WPT, but a lot in our selection > and contenteditable tests. > > Is this feature restricted to secure contexts? No, as this is merely > unprefixing an existing property. > > Thoughts? > > -- Emilio
I support doing this. This has existed forever, and is used quite a bit, so keeping that prefixed isn't helping anyone. I would like to note however that the basic way the property works (inherited vs not, initial value of auto, different between 'auto' and 'text') is different in the spec and in your implementation. The difference is intentional, and necessary to support the `contain` value and to have a model that explains what happens on editable elements. As long as you don't support the contain value, the difference in behavior should be minimal and barely noticeable in most cases, so this may not be a blocker, but if you're working on this property anyway, it seems to me that this would be a good time to switch to the spec's behavior while you're at it. —Florian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
