User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; sv-SE; rv:126.96.36.199) Gecko/20090729 Firefox/3.5.2
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.
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.
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 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.)
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.
Agreed with dbaron - it is premature for *us* to remove the -moz- prefix.
I've followed up on www-style 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).
The definition of ::selection was now readded in the CSS Pseudo-Elements 4 specification:
*** Bug 1220404 has been marked as a duplicate of this bug. ***
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:
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 (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 http://www.newyorker.com/wp-content/assets/dist/js/core.min.js?cb=20160208233313
Here the excerpt of the code :)
(In reply to Karl Dubost :karlcow from comment #10)
> 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.
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.
In addition to:
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