Repository navigation
[css-pseudo-4] ::selection vs ::inactive-selection #4579
Description
The spec seems to imply that ::selection and ::inactive-selection are mutually exclusive, when actually ::selection applies to inactive selections currently. The spec should be updated to make their interaction compatible with this behavior.
Possibilities:
- ::selection and ::inactive-selection apply to the same highlight pseudo-element, possibly with ::inactive-selection at a higher specificity
- ::selection and ::inactive-selection are separate highlight pseudo-elements that both apply to the range of an inactive selection, with ::inactive-selection at a higher level than ::selection (in the same way ::spelling-error and ::grammar-error layer when applied to the same text)
Interested in feedback from any implementers, on what makes sense implementation-wise.
Activity
heycam commentedon Dec 18, 2019
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.
sanketj commentedon Dec 18, 2019
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.
css-meeting-bot commentedon Jan 8, 2020
The CSS Working Group just discussed
] ::selection vs ::inactive-selection.The full IRC log of that discussion
<dael> Topic: ] ::selection vs ::inactive-selection<fantasai> github: https://github.com//issues/4579
<dael> github: https://github.com//issues/4579
<dael> fantasai: Relationship between them. It's impl that ::selection appies to active selection. If your window is inactive you still have color. Two ways for them to interact. One is inactive selection is another highlight and layers on top. Alternative is the cascade together and one only applies sometimes.
<dael> fantasai: Given previous resolution if you're using semi-transparent for selection and inactive selection and inactive goes on top of active so we have to cascade
<dael> fantasai: Want to know if there's other thoughts
<dael> fantasai: If we casscade might want to switch syntax so ::selection has a function name
<dael> AmeliaBR: Is there a compat need to make selection and inactive selection to be cumulative and not exclusive? Default behavior is there's different styles
<dael> dbaron: Possible to get inactive behavior with selection combined with other selectors?
<dael> fantasai: Based on inactivety of window. DOn't have a way to select
<dael> dbaron: Make one?
<dael> fantasai: Maybe with a MQ?
<dael> myles: That's significantly more powerful then what we agreed. Is there a reason to make more powerful? That's exposing more info to websites
<dael> dbaron: One level think it's more powerful. Another thing it's easier to impl b/c don't have to impl cascading pseudo elements
<dbaron> s/it's easier/it might be easier/
<dael> fantasai: I think there's a number of websites that would want to know if cage is active. Is it expose and do we want to?
<dael> florian: Sniff from selection?
<dael> fantasai: No
<tantek> 10:01 I have to go, interested to hear how this selector conversation goes. I tend to agree with dbaron that window inactivity should be a separate selector
<dael> Rossen_: Out of time.
<dael> Rossen_: I propose we leave this open until next time and resolve then
<AmeliaBR> Firefox has a inactive-window pseudoclass: https://developer.mozilla.org/en-US/docs/Web/CSS/:-moz-window-inactive
<dael> fantasai: Okay
AmeliaBR commentedon Jan 8, 2020
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.AmeliaBR commentedon Jan 15, 2020
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.
astearns commentedon Jan 15, 2020
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
fantasai commentedon May 5, 2020
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?
SelenIT commentedon May 7, 2020
In Blink, the
::selection:window-inactivepseudo-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.emilio commentedon May 7, 2020
Yeah, in gecko I think you can do
:-moz-window-inactive::selectionas well, fwiw.css-meeting-bot commentedon May 27, 2020
The CSS Working Group just discussed
[css-pseudo-4] ::selection vs ::inactive-selection.The full IRC log of that discussion
<dael> Topic: [css-pseudo-4] ::selection vs ::inactive-selection<dael> github: https://github.com//issues/4579
<dael> fantasai: Looked like going to use pseudo class combo but I didn't have anything to move forward with what it would be. Some comments on window for active but selection can be inactive when window is active. I'm not sure all behaviors intended or if we can do it all. I need help figuring it out. Does anyone have enough familiarity to know where we need the switch?
<dael> AmeliaBR: Browsers must have this code b/c they have default highlight styles. I guess it's a question to dig into code bases and look for consistency we can build on
<dael> emilio: Somewhat familiar with Gecko. Inactive selections in active window just not rendered. An input an have selection-start and -end but if you select outside we don't render selection on input
<dael> fantasai: Selected but invisible?
<dael> emilio: Yes
<dael> florian: Feels like different things
<dael> fantasai: Than it is selected, right? Maybe that's another state. It's selected and selection has default background
<dael> emilio: Opposite. Two states, window-active and -inactive. I think confusing to users if you allow display selection of something they can't edit b/c not focusable
<dael> emilio: afaict in FF there's active and inactive selection and that's it. Inactive matches the inactive window
<dael> fantasai: Active selection in active window, selection in inactive window, invisible selection?
<dael> emilio: Active selection in do that's main or not and that's only when they are active and rendered.
<dael> fantasai: I'm playing with it so I can see it.
<dael> fantasai: Question on what other browsers do.
<dael> fantasai: Also, can you from the DOM tell if content in the invisible input selection is selected?
<dael> emilio: I think so from DOM APIs. Only want to access is selection-start and -end. This is from memory
<dael> florian: Actually selected? If you copy do you copy from it?
<dael> emilio: ONly from active section of active window
<dael> florian: Feels like it could not be a selection
<dael> emilio: If you programmatically focus you should it
<dael> florian: It's a memory of where selction would be created if you focus the element
<dael> florian: If you do operations it acts on that selection?
<dael> emilio: I don't think so
<AmeliaBR> q?
<dael> fantasai: florian concept makes snese but how is it in the DOM? THer'es active, inactive, and remembered selection.
<dael> emilio: ALso things like defining page 1 which is different states. Don't know if we want to expose to authors
<dael> fantasai: Still need info on blink and webkit
<dael> AmeliaBR: Quick test. Chromium on windows is same as FF in that it remembers selections in imputs but no style if move focus away
<dael> AmeliaBR: One difference is if you have selection inside iframe and tab away FF it's same as inactive window selection, chromium no highlighting except regular input
<dael> AmeliaBR: Both have the style where inactive window gets different style effect
<dael> AmeliaBR: If point is represent browser default in CSS having inactive in combo with selection is sufficient. Can't check webkit, but chromium and FF that's the main requirement
<dael> fantasai: Good to hear from webkit. In terms of window active vs not I think that's a MQ not pseudo class
<dael> astearns: Sounds like we need test cases to outline scenarios and see if there's concordance between browsers and than decide how we'll express
<dael> fantasai: Seems like we could replecate what we know of with active window MQ and ::Selection and need to know if works on webkit.
<dael> smfr: Get webkit data for next week
<dael> fantasai: Okay
<dael> fantasai: Current state of proposal is we propose no active vs inactive media query [missed] Any comment on that approach assuming it checks out?
<dael> astearns: We'll leave this open. Keep on the agenda or wait on data?
<dael> fantasai: Wait on webkit
fantasai commentedon May 27, 2020
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.
megangardner commentedon Jun 2, 2020
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.
css-meeting-bot commentedon Oct 23, 2020
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 featureThe full IRC log of that discussion
<TabAtkins> Topic: ::selection vs ::inactive-selection<TabAtkins> github: https://github.com//issues/4579
<masonfreed> tantek, thanks. I think.
<TabAtkins> fantasai: We'd talkeda bout replacing the selection/inactive-selection distinction with a MQ for whether th eparent window is inactive
<TabAtkins> fantasai: So question is if we're actually doing that, should I remove ::inactive-selection from Pseudo and open an MQ issue?
<TabAtkins> florian: Seems good, but it seemed there was an active question about how much nuance there is about active vs inactive iframes?
<TabAtkins> fantasai: It seemed commented that we could get by with just the two, but we can make this an issue for the WG.
<GameMaker> q+
<TabAtkins> TabAtkins: Since impls dont' have ::inactive-seelction anyway, we can decide that later?
<Rossen_> ack GameMaker
<tantek> s/seelction/selection
<TabAtkins> GameMaker: Looking at the PDF at the bottom, I made a comparison of all browsers
<TabAtkins> GameMaker: Can't recall exact thoughts at the time, but based on these results, I was fine with making a MQ
<Rossen_> q?
<TabAtkins> Rossen_: So what's the proposed resolution?
<TabAtkins> fantasai: Removed ::inactive-selection from Pseudo 4, and add an issue on MQ to add an active-window media feature
<TabAtkins> Rossen_: Objections?
<tantek> s/talkeda bout/talked about
<TabAtkins> florian_irc: Are we removing it while we're thinking about it, and it's gone? Or will we maybe put it back?
<TabAtkins> florian_irc: Asking because we have tests for this - should I mark as tentative, or delete?
<TabAtkins> fantasai: Mark as tentative until we're totally finished on this issue. Good chance we can just revise later
<TabAtkins> RESOLVED: Remove ::inactive-selection from Pseudo 4, and add an issue on MQ to add an active-window media feature
[css-lists-3] Remove ::inactive-selection; investigate mediaquery ins…