- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jun 2022 17:00:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `should :fullscreen be a modal state?`, and agreed to the following: * `RESOLVED: Fullscreen elements should inert the stuff behind them, and match :modal` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: should :fullscreen be a modal state?<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7311<br> <TabAtkins> chrishtr: We introduced :modal, which brought ot our attention that Chrome impl of FullScreen makes it modal (stuff behidn is inert) but other impls don't do that<br> <ntim> q+<br> <TabAtkins> chrishtr: Think we should resolve on whethe rfullscreen is modal, which both affects inert and whether :modal applies to it<br> <TabAtkins> chrishtr: Don't have a strong opinion on how we go<br> <Rossen_> ack ntim<br> <TabAtkins> ntim: I think it makes sense to make the stuff behind fullscreen inert<br> <TabAtkins> ntim: But not sure webdevs would expect :modal pseudoclass tomatch in this case<br> <TabAtkins> Aka *my exact argument for why we should have named it :modal-dialog*<br> <TabAtkins> emilio: Unsure what webkit does for fullscreen<br> <TabAtkins> ntim: webkit's impl is old but if we redid it I'd make it inert<br> <TabAtkins> emilio: In firefox you can interact with stuff behind it; you can set pointer-events:none and then interact with the page<br> <TabAtkins> ntim: I don't have strong opinion, but it seems unexpected that you can do that<br> <TabAtkins> emilio: I don't particularly mind either way, was just pointing out that you can, unless you do the chromium thing of makign the undelrying page inert<br> <flackr> q+<br> <TabAtkins> fantasai: This is less of a style question. I think the inertness is less significant<br> <jensimmons> q=<br> <jensimmons> q+<br> <TabAtkins> fantasai: Think we need toudnerstand if there are use-cases for being not inert<br> <TabAtkins> fantasai: Unsure we're equipped to resolve on this during this call<br> <TabAtkins> fantasai: probably need info from people authoring fullscreen stuff and see if it's necessary to fullscreen something that doesn't take up the whole screen<br> <TabAtkins> ntim: This issue aside, it seems unexpected either way for :modal to apply to fullscreen elements, regardless of whether stuff behind is inert<br> <TabAtkins> ntim: :modal comes from modal dialogs<br> <TabAtkins> fantasai: They might not, but we decided it means things with modal qualities. Fullscreen might not be first in mind, but if it has those qualities it should match<br> <flackr> +1<br> <masonf> +1<br> <Rossen_> ack flackr<br> <TabAtkins> flackr: If the content behidn wasn't inert it would be in tab order as well, which could be confusing if you could tab out of the fullscreen element<br> <TabAtkins> emilio: fair<br> <TabAtkins> jensimmons: this raises a11y memories, if visually a fullscreen element covers everything, so assumption is the stuff behidn isn't accessible, having it not be inert could make it different for people using other a11y tools<br> <TabAtkins> jensimmons: I'm wondering what the use-cases would be for making the contents behidn a fullscreen *not* inert<br> <TabAtkins> jensimmons: Maybe there should be a way to toggle it off, but default should be for inert<br> <TabAtkins> fantasai: I buy that<br> <bkardell_> agree<br> <masonf> +1<br> <TabAtkins> Rossen_: strong agree<br> <bramus> +1<br> <chrishtr> Agree on inert making sense given these arguments<br> <SebastianZartner> +1 for what jensimmons said.<br> <TabAtkins> emilio: fair point. Then :modal should apply to fullscreen.<br> <florian> +1 to Jen<br> <masonf> q+<br> <Rossen_> q?<br> <TabAtkins> fantasai: Right, so decision is whether it's inert, and whether :modal applies is a consequence<br> <Rossen_> ack jensimmons<br> <TabAtkins> masonf: Strong agree with points, think fullscreen should inert the rest of the page<br> <Rossen_> ack masonf<br> <TabAtkins> masonf: Do we include special provisions for fullscreen escaping that inertness, like dialogs have?<br> <TabAtkins> masonf: Like if you inert the entire page the fullscreen shoudln't be inert, need provisions for that<br> <TabAtkins> ntim: That's what fullscreen does<br> <TabAtkins> masonf: Sure just want to make sure it's captured<br> <Rossen_> q?<br> <TabAtkins> Rossen_: additional thoughts or objections?<br> <TabAtkins> plinss: In conext of dialogs there's clear spec ni html of what puts the dialog into a modal state<br> <TabAtkins> plinss: in my mind that is what puts into a :modal pseudoclass<br> <TabAtkins> plinss: think it's important to not just catch things that are modal-ish<br> <masonf> q+<br> <TabAtkins> emilio: Yeah fullscreen spec should define the modalness<br> <masonf> q-<br> <TabAtkins> plinss: So as long as it's defined that fullscreen puts it into this state just like dialog, unsure that we should just auto-apply it because it resembles modalness<br> <TabAtkins> Rossen_: so if i understand, fullscreen elements *are* modal from html behavior like dialogs, and rely on same behavior. is that clarification?<br> <TabAtkins> plinss: I'm saying :modal shoudln't apply unless something is *defined as* "being modal", not just because it's kinda modal-ish in some respects. HTML is very clear about modal, need to respect that.<br> <TabAtkins> plinss: So if fullscreen uses that same definition it's fine.<br> <masonf> q+<br> <ntim> https://html.spec.whatwg.org/multipage/interactive-elements.html#is-modal<br> <SebastianZartner> Maybe we can at least resolve on fullscreen elements making the reset inert.<br> <TabAtkins> masonf: +1 to that<br> <TabAtkins> masonf: Note that HTML doesn't define "being modal", it defines how a dialog become smodal. But that can probably be pulled out into a proper definition.<br> <TabAtkins> RESOLVED: Fullscreen elements should inert the stuff behind them, and match :modal<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7311#issuecomment-1163385752 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 June 2022 17:00:37 UTC