The second would be easier to implement since that would make it similar to the other selection-related pseudos in that they are all layered in a particular order. We don't currently have any cascading between pseudo-elements (I think?) so that would be something a little more complex to support.

But layered selections would make it impossible to, say, give active selections one semi-transparent color and inactive selections a different semi-transparent color.

I think having separate pseudo elements for native selection highlights (ie. the second option) makes sense because we have separate pseudo elements for all other types of highlights, including custom highlights (aka ::highlight).

The main difference between this case and the ::spelling-error + ::grammar-error case seems to be that both ::selection and ::inactive-selection will apply to the same set of ranges. If we wanted to emulate this case with custom highlights, we wouldn't be able to do so today as we would have to use separate HighlightRangeGroups for active and inactive selection, which means we would be dealing with separate sets. But if we implemented #4613 , then we could have custom highlights for each selection state applying to the same group, and we would have separate pseudo elements for both.

The CSS Working Group just discussed ] ::selection vs ::inactive-selection.

To the question of whether you can already tell whether a document is active or inactive: yes, via the Page Visibility API and also older JS methods like document.hasFocus(). So exposing the same info indirectly via CSS is not likely to be a concern.

Following up on the discussion in today's call (which didn't get posted because of bot issues, but we can copy it in once Dael has tidied up the minutes):

Testing the default browser selection styles on my system, both Chrome and Firefox on Windows switch to the inactive selection style when you move focus between a main document and an iframe.

So this (the inactive state for selection styling) is definitely different from Page Visibility API hidden state, although it still seems consistent with the document.hasFocus() state.

Neither browser I tested drew an inactive selection for selected text in a text area when the text area no longer had focus (although they remembered the selection for when the element regained focus again). So I don't know if there's a use case for an element-level “inactive” state for styling.

Missed minutes:

dael> Topic: [css-pseudo-4] ::selection vs ::inactive-selection
fantasai: Started discussing last week, came up with...discussion was why not have a MQ intead of two pseudos. Then we ran out of time.
fantasai: Do we want to go in that direction and drop inactive selection from spec and add a MQ to MQ5?
s/inactive selection/::inactive-selection
astearns: Use case for inactive MQ outside of selection?
fantasai: Probably. There's some JS methods that allow you to detect that
#4579 (comment)
astearns: Main difference is instead of having to fully spec both styling you can do all your selection styling and have an inactive override to might reduce duplication
fantasai: We have to do that anyway b/c selection is when window is inactive. Whatever way we take it needs to apply. 3 ways to do it, 2 are in the issue and 3rd is do in a MQ where you can do inactive anything
AmeliaBR: Selection styles always apply active or not is what we have. DOesn't match browser styles. I like MQ idea and have benefit of being able to do things like pause animations and transitions which is more consistent with request animation frame transitions
smfr: Need to be a little careful with window activation. An iframe without focus is inactive color. It's focus state of document maybe.
smfr: Wondering case about inactive selection with the same document as active selection. There may be scenarios like that
AmeliaBR: Interesting. Then inconsistent with page visibility APIs concept of activeinactive. Useful to have specific examples of which browsers and OS conventions do have those distinguishments between this selection is preserved but not currently active and the cases where that can happen
astearns: I'd want to make sure the MQ had as much of same behavior as page visibility API. Doesn't seem like should be a difference if we can manage it
fantasai: Then it's not same as ::inactive-selection. When you have ::inactive-selection and ::active-selection in the same page we need the pseudo
fantasai: Other idea taken up during previous call was a selector on the element that says hey this element is focused so make selection this color. Some word that represents being selectable in an active way. Don't know if it would work
AmeliaBR: That would cover case of text area preserving selection even when text area doesn't have focus. A pseudo class on text area and then selection style with regular selection element?
fantasai: Yeah, I think so. but then...I don't know...need to think about cascading
fantasai: That's good points, we should move to another issue. We won't solve now.
astearns: I'm still interested to see if an inactive MQ would be useful, but may be out of scope for this problem
astearns: Let's continue in GH and maybe on agenda for next week

Formatted January 8 minutes: https://lists.w3.org/Archives/Public/www-style/2020Jan/0002.html
Formatted January 15 minutes: https://lists.w3.org/Archives/Public/www-style/2020Jan/0006.html

The ideas that came out of the last set of discussions was that Media Queries can't help solve this problem, but some kind of selector on the selection-focus state of the element, which could be combined with ::selection.

Problem is, I don't know what the conditions for such a state would be... Someone else with more knowledge of selection/focus user interaction have some idea? @bkardell maybe?

In Blink, the ::selection:window-inactive pseudo-class/pseudo-element combination also used to work (https://twitter.com/simevidas/status/602490370673475584, the related WebKit change dates back to 2009). But it appears to stop working at some point after 2018.

Yeah, in gecko I think you can do :-moz-window-inactive::selection as well, fwiw.

The CSS Working Group just discussed [css-pseudo-4] ::selection vs ::inactive-selection.

So, current state of discussion is, no need for ::inactive-selection, but plan to add a window is active vs inactive media query, which in combination with ::selection should allow the necessary behaviors.

Waiting on WebKit to say if they can emulate their behavior with such a system.

So I gathered data on the state of the browsers currently.
SelectionStyling.pdf
I believe that adding a media query would be a reasonable solution to this problem, both logically, and within the capabilities of WebKit. However, we should consider if allowing an embedded frame to style itself completely differently when it is not focused is fully desirable.

The CSS Working Group just discussed ::selection vs ::inactive-selection, and agreed to the following:

• RESOLVED: Remove ::inactive-selection from Pseudo 4, and add an issue on MQ to add an active-window media feature