On 11/12/18 2:36 AM, flor...@rivoal.net wrote:
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.
Hmm, you're totally right, that's a very good point and I think we
should not unprefix it without fixing that.
I'll land the patches removing the obsolete values, and file a bug to
make that change before unprefixing.
Thanks Florian!
-- Emilio
—Florian
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
