Last Comment Bug 509958 - Remove the -moz prefix from ::selection
: Remove the -moz prefix from ::selection
Status: NEW
: dev-doc-needed
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: unspecified
: All All
: -- enhancement with 18 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://dev.w3.org/csswg/css-pseudo-4/...
: 1220404 (view as bug list)
Depends on: 176170 1265639
Blocks: unprefix
  Show dependency treegraph
 
Reported: 2009-08-12 07:39 PDT by d
Modified: 2016-06-16 06:35 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description d 2009-08-12 07:39:44 PDT
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 2010-03-05 09:29:06 PST
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+2 (review requests must explain patch) 2010-03-05 09:51:21 PST
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 2010-03-06 07:39:58 PST
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+2 (review requests must explain patch) 2010-03-06 09:40:03 PST
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 2013-12-11 11:12:42 PST
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] 2015-01-17 15:39:55 PST
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 7 Gingerbread Man 2015-10-31 15:47:42 PDT
*** Bug 1220404 has been marked as a duplicate of this bug. ***
Comment 8 Karl Dubost :karlcow 2016-02-09 21:39:03 PST
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] 2016-02-09 23:29:53 PST
(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 2016-02-09 23:44:09 PST
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] 2016-02-10 00:22:08 PST
(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] (UTC+8) 2016-05-07 06:47:21 PDT
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+2 (review requests must explain patch) 2016-06-16 06:35:41 PDT
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

Note You need to log in before you can comment on or make changes to this bug.