Re: [csswg-drafts] [selectors] Should :active apply to dialogs? (#7258)

Open UI just discussed this today since @tantek brought it to the group.

**TLDR:** There were no concrete usecases in the designs systems/solutions that the group knows about or works on currently and wants to wait for concrete use-cases to present themselves before solving this scenario

<details>
     <summary>Full IRC Log</summary>
     <p>tantek: this was discussed in CSSWG, not enough info in CSSWG to make decision, I thought, so wanted to bring it here

tantek: I basically wanted the considerations from this group to be taken into account

gregwhitworth: peter's comment is basically, should you be able to select the active dialog with the active pseudo class?

bkardell_: some people had the concern that it is not intuitive… not sure if that's the big thing, for me the concern is some worry that because :active is used in stylesheets today so you would get false matches when people start using dialog?

<gregwhitworth> link to plinss comment: https://github.com/w3c/csswg-drafts/issues/7258#issuecomment-1119861263

bkardell_: but maybe that's no problem as those sites don't use dialog now and they can change it when they start using

JonathanNeal: I saw the concern with :active… I use it myself for the 'pressing' state, the point after a spacebar or click begins… I find it to be an underused/poorly defined thing… it does have a meaning that I thinki s different… while I support the idea of this pseudo class I was going to ask if current had been considered?

JonathanNeal: I thought it was supposed to represent the current item to be displayed?

tantek: we did distinguish between functionality and bikesheddding the name of pseudo class

tantek: could this group address this separately?

tantek: so would the functionality tbe useful vs what do we call it and how does it match naming conventions?

masonf: I wanted to ask… was it decided not to combine it, I saw :active-modal , I presume that's off the table?

<JonathanNeal> I see value in knowing the active/current modal.

tantek: I think we were not able to get to the naming in the meaning

<JonathanNeal> I actually meant to ask how the “active modal” was defined. Does it contain focus? focus intent?

masonf: oh I mean… combining the two things in one pseudo class, I don't care about the names as much, but about that :modal and :active are two pseudo classes and not combined into a single one

emilio: imagine you have a popup instead of dialog, like a tooltip, you probably wouldn't want the pseudo class to stop applying to the dialog?

masonf: why not?

masonf: what would you expect if the popup obscures the dialog?

emilio: modal dialogs are special in the sense that only one dialog is not inert…

<JonathanNeal> I also support the general pseudo-class, like `:hover`, versus a specific pseudo-class like `:active-dialog`.

masonf: even if there is a popup on top of it and it covers the entire dialog?

emilio: yes because the popup doesn't have modal semantics, doesn't make rest of page inert/

emilio: in Gecko we need a pseucodlass internally to distinuish modal from top most dialog

<miriam> +1 to emilio's point

emilio: I'm not sure what the distinction brings on something that is a modal… as long as it is not a modal you can just position things differently… can only have one at the time, and not true for any other top layer el

masonf: what does it mean to be top layer if I'm not necessarily on top of everything else, is something I was asked

emilio: the use case is highlighting or styling differently the active dialog, you may not care if it is on top

emilio: imagine a dialog that has a popup like thing… you lose the ability to differentiate the inert from the non inert if you just make the pseudo class the top most thing in the top layer?

emilio: I guess there is also a use case for distinguishing the top most thing?

masonf: that was a compelling example, maybe there is a need for two pseudo classes

tantek: there is the concept of active from UI perspective, and then there is the :active semantic, and they are not the same

tantek: :active is defined in CSS 1, it is something we have to live with… but we can avoid confusing developers

<tantek> is this purely for "top most" (which sounds presentational) or is this about which modal dialog has the user's focus, in which case perhaps :focus-within https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-within could be combined with :modal?

tantek: the term topmost has been used… I'm not sure if I like that, it's kind of got a presentational framing. Is this about what the user's focus is, maybe something like focus-within could help?

tantek: so what is the actual functionality we are looking for… as opposed to what could we reuse from existing concepts?

JonathanNeal: want to +1 what tantek just said

JonathanNeal: my question is: could someone define this 'active top most' that we could apply to things like <select> and modal and see if we could pair it somehow?

JonathanNeal: is there a definition of what that potentially general state is?

JonathanNeal: is it the thing that is the top most?

masonf: that is what needs to be discussed more… I heard two. One is the non inert dialog, effectively the top most dialog… the other is the one I came to the meeting with, of all the top layer elements, which one is on top of all of them?

JonathanNeal: is there a quality to the top most, like it has the focus intent, is there some qualitative thing we can know about?

masonf: you can have a topmost element that doesn't have the focus entirely, it is just in the top

<JonathanNeal> Maybe `:modal:with-intent`?

emilio: for dialog that is the intention… you can't (@@@) have a hidden dialog in the top layer, I think the intention is that that is the onlly interactive thing

tantek: that's why I brought up focus-within, I think that kind of has that notion of interactive

<JonathanNeal> Or `:modal:intent-within`.

emilio: I think focus can move outside of the tab, so focus-within might not match anything within the page

tantek: what styling are authors trying to do with the top most thing? or is it that folks want to know this is the thing that users must interact with ?

emilio: that's fair… in an ideal world, modal dialogs could properly trap focus and you could guarantee there's focus in that

<masonf> +1 to tantek's comment: we need concrete use cases for these things before trying to design how they work.

gregwhitworth: what I would recommend based on what I have heard… what if we actioned somebody to find use cases, but I'm not sure what wer're looking for, I don't even know what to ask?

gregwhitworth: the pseudo class modal only applies to dialogs

<JonathanNeal> Does a modal have focus intent? By focus indent, I am referring to the effect when we click an anchor link? And it would apply even if the modal does not or cannot receive focus?

gregwhitworth: so in some scenario something is occurring in some state for dialog… so not sure if we could even task someone with investigating this more as I'm not sure what sort of use case we're looking for here?

emilio: I think Peter was the first who brought this up because internally we need to distinguish between dialog is modal and dialog is the top most one that isn't inert

<tantek> https://github.com/w3c/csswg-drafts/issues/7258

emilio: there is a point to get more concrete use cases

tantek: I believe what Peter is expressing is that… dialog that the user CAN interact with vs MUST interact with… that's very different from the notion ':active' in CSS so far

tantek: so it's about drawing attention to an element in the page

<JonathanNeal> I could see using the `:not()` variant to blur the modals behind the “top-most”.

scotto: I was wondering about use cases too and I'm not sure either what we're trying to solve

scotto: something like an ARIA modal wouldn't trigger this pseudo class, this seems specifically for dialog and any other custom modal popups that someone might make, I'm not sure how that would apply if it is not defined in the web platform… so yes +1 we need some use cases

<tantek> +1 scotto

gregwhitworth: thinking of what we have in Salesforce… a use case I can think of is where a dialog is trying to convey some perceived active state, may be focused, may not be, may even not necessarily be modal

gregwhitworth: in a teaching UI

scotto: but you probably wouldn't even want a thing in a teaching UI to be modal

gregwhitworth: exactly and probably not the pseudo class either, we would be handling it just with popups, wouldn't need active or enter on or others

masonf: seems like part of the reason looking at the notes is for this group to look at use cases

gregwhitworth: seems to me we want to ask the community in Discord or Twitter

tantek: instead of bleeding into the abstract, we are looking for something concrete

flackr: with the real use cases, it is possible that focus-within match the expectations

flackr: focus does get restored if focus-within gets lost when you switch tabs it is put back, I noticed

gregwhitworth: ok cool, so action would be to sum up the request for use cases and share it

gregwhitworth: do we even want to?

masonf: this seems like something we can add later to the platform and it would still be compatible

tantek: probably good feedback for CSSWG, don't need to rush it, wait for use cases to present themselves
</details>

-- 
GitHub Notification of comment by gregwhitworth
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7258#issuecomment-1132073838 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 19 May 2022 18:46:48 UTC