d Reporter
	Description • 15 years ago

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

	d Reporter
	Comment 1 • 14 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 2 • 14 years ago

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

	d Reporter
	Comment 3 • 14 years ago

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.)

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 4 • 14 years ago

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.

	Tantek Çelik
	Comment 5 • 11 years ago

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

	Sebastian Zartner [:sebo]
	Comment 6 • 9 years ago

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

	Karl Dubost💡 :karlcow
	Comment 8 • 8 years ago

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

	Sebastian Zartner [:sebo]
	Comment 9 • 8 years ago

(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

	Karl Dubost💡 :karlcow
	Comment 10 • 8 years ago

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

	Sebastian Zartner [:sebo]
	Comment 11 • 8 years ago

(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

	Ting-Yu Lin [:TYLin] (PDT, UTC-7)
	Comment 12 • 8 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 13 • 8 years ago

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

	Vader
	Comment 14 • 7 years ago

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.

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 16 • 6 years ago

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.

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 17 • 6 years ago

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.

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 18 • 6 years ago

Probably some tests to fix:

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

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 19 • 6 years ago

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.

	Xidorn Quan [:xidorn] UTC+11
	Comment 20 • 6 years ago

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

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 21 • 6 years ago

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

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 22 • 6 years ago

(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.

	fantasai
	Comment 23 • 6 years ago

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.

	Xidorn Quan [:xidorn] UTC+11
	Comment 24 • 6 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 25 • 6 years ago

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...

	Pulsebot
	Comment 26 • 6 years ago

Pushed by ecoal95@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/70754a946fde
Unprefix :-moz-selection. r=dbaron,xidorn

	Pulsebot
	Comment 27 • 6 years ago

Pushed by ecoal95@gmail.com:
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

	Kohei Yoshino [:kohei]
	Comment 28 • 6 years ago

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

	Dorel Luca [:dluca]
	Comment 29 • 6 years ago
bugherder

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

	Will Bamberg [:wbamberg]
	Comment 30 • 6 years ago

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.