509958 - Remove the -moz prefix from ::selection

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement)

Description

[d]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; sv-SE; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: 

The Psuedo-element ::selection has not been in the specs (for CSS3) since 2005, but it is still implemented in three layout engines, Presto, Webkit and Gecko. The first two uses ::selection without a prefix, like -webkit or similar, but Gecko does not. I can no longer see any reason to keeping the -moz prefix. The implementation is complete, the other engines are already doing it. We can't keep it in Experimental status forever, and the spec isn't likely to change either.

Reproducible: Always

Comment 1

[d]

After learning more about how specs and implementations work (seven months ago I was young and inexperienced ;P), I'll mark this as WONTFIX. When/if ::selection gets added to the CSS3 spec, or a future CSS spec, feel free to reopen this bug again.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

For the record, ::selection was included in a Candidate Recommendation, so we're allowed to remove the prefix if we implement it correctly.
http://www.w3.org/TR/2001/CR-css3-selectors-20011113/

However, it's not clear what correctly means based on that candidate recommendation; for a description of the ambiguities, see
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html

Comment 3

[d]

I see. Looking at the spec, and comparing with what we support from https://developer.mozilla.org/en/CSS/%3a%3aselection, it feels as we got partial support, but definitely support the most important. I don't know how our implementation match the ones in Webkit and Presto, but I can't see much harm in removing the -moz prefix. The properties we don't support can be added later, if demand for them is high, and for now, they'll just be ignored by us (if other browsers even support them).

It would've been nice to see full support for the properties we "do" support at least, though. This testcase: https://bug183646.bugzilla.mozilla.org/attachment.cgi?id=408753 (from bug 183646) brings up our most important issue, I think, where we won't style selected text in forms (and similar). It also seems we have issues with first selecting inside a contenteditable field, and then selecting something outside it.

Bug 176170 is a tracking bug about ::selection, where some other issues are highlighted.

In general, I think developers would appreciate if we removed the prefix, as that would mean they wouldn't have to use up double the space in their CSS for defining rules for both Gecko-browsers and other browsers. I'd like your opinion on, if the issues mentioned above is important enough to hold off on removing the prefix.

(Finally, I am not sure if I completely able to follow http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html, but if our implementations behavior matches the other browsers in those issues, I don't think it will be a problem.)

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We should remove the -moz- prefix if we believe that the behavior is correct and we're not planning to make major changes to how it works.

I rather doubt that's the case, though I'd be interested in knowing both how we and how other browsers handle the questions in the www-style post in comment 3.

It's a good bit of work to figure that out, so this isn't something where I can just change the name and commit the patch.

Comment 5

[Tantek Çelik]

Agreed with dbaron - it is premature for *us* to remove the -moz- prefix.

I've followed up on www-style[1] with a proposed plan for answering the questions in dbaron's www-style post that he mentions, and writing spec text accordingly (which if we do end up complying with, passing tests, then we can reconsider unprefixing once that spec text is officially published).

[1] http://lists.w3.org/Archives/Public/www-style/2013Dec/0240.html
[2] http://wiki.csswg.org/spec/css3-ui#issue-30

Comment 6

[Sebastian Zartner [:sebo]]

The definition of ::selection was now readded in the CSS Pseudo-Elements 4 specification:

http://dev.w3.org/csswg/css-pseudo-4/#selectordef-selection

Sebastian

Comment 8

[Karl Dubost💡 :karlcow]

to help with the parity with WebKit/Blink here
There is an interesting webcompat bug on the New-Yorker magazine web site related to a combination of moz-selection and text-shadow and hover

https://webcompat.com/issues/2231

Comment 9

[Sebastian Zartner [:sebo]]

(In reply to Karl Dubost :karlcow from comment #8)
> to help with the parity with WebKit/Blink here
> There is an interesting webcompat bug on the New-Yorker magazine web site
> related to a combination of moz-selection and text-shadow and hover

Note that there is no ::-moz-selection involved in that website. The reason for this issue is that a white text shadow is applied to the links. When selecting the text, the text turns white and gets unreadable, because the text shadow is still there.
The issue can currently be easily solved by removing the shadow on selection:

::-moz-selection {
  text-shadow: none;
  color: highlighttext;
  background-color: highlight;
}

The main issue related to this seems to me whether 'text-shadow' should also be applied on the selection. And if so, whether it should keep its color or be changed in some way to make the text readable.
This was already addressed by fantasai in a W3C post[1] (under point 7).

Sebastian

[1] https://lists.w3.org/Archives/Public/www-style/2014Nov/0188.html

Comment 10

[Karl Dubost💡 :karlcow]

Sebastian, 
We are not seeing the same thing, please look at the thread on the Webcompat bug and look at the code by inspecting it with a clean profile on Firefox.

The code setting the ::-moz-selection is in the "C" function in http://www.newyorker.com/wp-content/assets/dist/js/core.min.js?cb=20160208233313

Here the excerpt of the code :)
https://gist.github.com/karlcow/4e2ca70f20ebfa505b1f

Comment 11

[Sebastian Zartner [:sebo]]

(In reply to Karl Dubost :karlcow from comment #10)
> Sebastian, 
> We are not seeing the same thing

You're right if your screenshot at https://webcompat.com/issues/2231#issuecomment-182150837 shows what you see when the text is selected. On Windows it looks rather like https://webcompat.com/issues/2231#issuecomment-182151662.
Hovering the selection doesn't have any effect on Windows, btw. Also, it looks like the dynamically generated rule isn't applied at all. At least the DevTools' Rules side panel doesn't show the pseudo-element and changing it within the Style Editor doesn't have any effect.

Having said all that, I believe this issue should be filed as a new bug.

Sebastian

Comment 12

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

If we feel it's about time to support ::selection, we might want to continue to support the old ::-moz-selection and implement ::selection behind a pref to buy us more time to figure out the compact issue.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In addition to:
http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
there's also:
https://lists.w3.org/Archives/Public/www-style/2010May/thread.html#msg275
but I think there's also some newer discussion as well.

Also see the various issues listed in the spec at https://drafts.csswg.org/css-pseudo/#highlight-pseudos

Comment 14

[Vader]

Before un-prefixing, please test this pseudo-element with any image. The ::selection (and ::-moz-selection) doesn't work for images ONLY in the Firefox. Opera, Chrome, Safari and Explorer doesn't contain this bug.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

I think keeping this prefixed is causing more trouble than good...

The spec doesn't reflect reality in any way (Gecko and Blink do the same thing, which is just resolving the selection style on the parent element:

  https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/SelectionPaintingUtils.cpp?l=29&rcl=9c03e780d3005b10f5f2debb197350932e43df63
  https://searchfox.org/mozilla-central/rev/8220783953b0311e1d64c2366f732a159f05ed7e/layout/generic/nsTextFrame.cpp#4061

So I'm not concerned about having compat pain because of this. I'll file spec issues and post a patch here.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Filed https://github.com/w3c/csswg-drafts/issues/2474.

I don't think WebKit or Blink have any incentive for changing their behavior to what the spec says, and given they're compatible with us I think we should unprefix.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Probably some tests to fix:

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=9c722030a162e51e95491764aaf328f04cc9f5c9

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Attachment: Unprefix :-moz-selection.

This keeps :-moz-selection working in stylesheets, but that's about it. It aliases it at parse time.

We can do something a bit more fancy aliasing it also in nsCSSPseudoElements. That'd allow getComputedStyle(el, ":-moz-selection") and such to keep working. 

Given https://github.com/w3c/csswg-drafts/issues/2149 I'd expect not many people relying on that, and I'd prefer to avoid that to make removing the prefixed version more easily.

Next thing we could do is the same we do for :-moz-placeholder, and keep it around until selector-matching time, but I'd really prefer to avoid another special-case like that.

Comment 20

[Xidorn Quan [:xidorn] UTC+10]

Please send an intent to unprefix to dev-platform and describe this situation there.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Are there tests that demonstrate the interoperability of current browser behavior?

Comment 22

[Emilio Cobos Álvarez (:emilio)]

(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #21)
> Are there tests that demonstrate the interoperability of current browser
> behavior?

Unfortunately not other than manual test-cases, and the tests I wrote for bug 1449010. Will write some.

Comment 23

[fantasai]

Fwiw, CSSWG recommends that Mozilla unprefix, despite not following the spec: https://github.com/w3c/csswg-drafts/issues/2474
We don't anticipate a web-compat issue, since the behavior in the conditions where browsers don't match the spec is so broken that we can't imagine anyone is relying on it.

Comment 24

[Xidorn Quan [:xidorn] UTC+10]

Comment on attachment 8962190 [details] [diff] [review]
Unprefix :-moz-selection.

Review of attachment 8962190 [details] [diff] [review]:
-----------------------------------------------------------------

The change looks good to me. It would be great if there are some wpt to check the non-broken part of existing behavior which is considered interop between browsers.

Also given that the working group suggests us to unprefix, we should have it there sooner so that we have a chance to test it in Nightly first.

It might be good to have a pref controlling it, but that's probably annoying and not very useful. If we do have any serious regression on some sites, we should just back it out.

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 8962190 [details] [diff] [review]
Unprefix :-moz-selection.

Sorry for the delay.

Sad that we haven't had a chance to try to switch to a behavior that's actually more useful for developers, but I guess this is the pragmatic thing to do...

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/70754a946fde
Unprefix :-moz-selection. r=dbaron,xidorn

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2dc0a563e958
Remove an unused whitelist entry from a test that only runs on opt builds. r=me on a CLOSED TREE

Comment 28

[Kohei Yoshino]

Posted the site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2018/selection-pseudo-element-has-been-unprefixed/

Comment 29

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/70754a946fde
https://hg.mozilla.org/mozilla-central/rev/2dc0a563e958

Comment 30

[Will Bamberg [:wbamberg]]

Browser compat data is updated for this: https://developer.mozilla.org/en-US/docs/Web/CSS/::selection#Browser_compatibility and I think that's all the doc update needed here, but please let me know if we need anything else.