Closed Bug 509958 Opened 15 years ago Closed 6 years ago

Remove the -moz prefix from ::selection


(Core :: CSS Parsing and Computation, enhancement)

Not set



Tracking Status
firefox62 --- fixed


(Reporter: deprecationmail, Assigned: emilio, NeedInfo)


(Depends on 1 open bug, Blocks 1 open bug, )


(Keywords: dev-doc-complete, site-compat)


(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; sv-SE; rv: 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
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.
Closed: 14 years ago
Resolution: --- → WONTFIX
For the record, ::selection was included in a Candidate Recommendation, so we're allowed to remove the prefix if we implement it correctly.

However, it's not clear what correctly means based on that candidate recommendation; for a description of the ambiguities, see
I see. Looking at the spec, and comparing with what we support from, 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: (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, but if our implementations behavior matches the other browsers in those issues, I don't think it will be a problem.)
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.
Resolution: WONTFIX → ---
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).

Blocks: unprefix
Keywords: dev-doc-needed
Depends on: 176170
The definition of ::selection was now readded in the CSS Pseudo-Elements 4 specification:

Ever confirmed: true
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
(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).


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

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

You're right if your screenshot at shows what you see when the text is selected. On Windows it looks rather like
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.

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.
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.
Flags: needinfo?(deprecationmail)
Keywords: site-compat
See Also: → 1427680
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:

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

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.
Assignee: nobody → emilio
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 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.
Attachment #8962190 - Flags: review?(xidorn+moz)
Attachment #8962190 - Flags: review?(dbaron)
Please send an intent to unprefix to dev-platform and describe this situation there.
Depends on: 1449010
Are there tests that demonstrate the interoperability of current browser behavior?
(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.
Fwiw, CSSWG recommends that Mozilla unprefix, despite not following the spec:
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 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.
Attachment #8962190 - Flags: review?(xidorn+moz) → review+
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...
Attachment #8962190 - Flags: review?(dbaron) → review+
Pushed by
Unprefix :-moz-selection. r=dbaron,xidorn
Pushed by
Remove an unused whitelist entry from a test that only runs on opt builds. r=me on a CLOSED TREE
Closed: 14 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Depends on: 1460870
Browser compat data is updated for this: and I think that's all the doc update needed here, but please let me know if we need anything else.
See Also: → 1689120
You need to log in before you can comment on or make changes to this bug.