[fullscreen] Should fullscreen be a modal state?

[chrishtr]

Currently, fullscreen is modal in Chromium (via inert), and has been for the past 5 years apparently. But it's not modal in at least Gecko.

The fullscreen spec doesn't specify modal-ness. This issue is to track whether we should add it or not. See also #6965 .

[chrishtr]

I think we should go one way or another and put it in the spec, because it will affect the behavior of the :modal pseudoclass.

[css-meeting-bot]

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

The full IRC log of that discussion

<TabAtkins> Topic: should :fullscreen be a modal state?
<TabAtkins> github: https://github.com//issues/7311
<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
<ntim> q+
<TabAtkins> chrishtr: Think we should resolve on whethe rfullscreen is modal, which both affects inert and whether :modal applies to it
<TabAtkins> chrishtr: Don't have a strong opinion on how we go
<Rossen_> ack ntim
<TabAtkins> ntim: I think it makes sense to make the stuff behind fullscreen inert
<TabAtkins> ntim: But not sure webdevs would expect :modal pseudoclass tomatch in this case
<TabAtkins> Aka *my exact argument for why we should have named it :modal-dialog*
<TabAtkins> emilio: Unsure what webkit does for fullscreen
<TabAtkins> ntim: webkit's impl is old but if we redid it I'd make it inert
<TabAtkins> emilio: In firefox you can interact with stuff behind it; you can set pointer-events:none and then interact with the page
<TabAtkins> ntim: I don't have strong opinion, but it seems unexpected that you can do that
<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
<flackr> q+
<TabAtkins> fantasai: This is less of a style question. I think the inertness is less significant
<jensimmons> q=
<jensimmons> q+
<TabAtkins> fantasai: Think we need toudnerstand if there are use-cases for being not inert
<TabAtkins> fantasai: Unsure we're equipped to resolve on this during this call
<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
<TabAtkins> ntim: This issue aside, it seems unexpected either way for :modal to apply to fullscreen elements, regardless of whether stuff behind is inert
<TabAtkins> ntim: :modal comes from modal dialogs
<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
<flackr> +1
<masonf> +1
<Rossen_> ack flackr
<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
<TabAtkins> emilio: fair
<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
<TabAtkins> jensimmons: I'm wondering what the use-cases would be for making the contents behidn a fullscreen *not* inert
<TabAtkins> jensimmons: Maybe there should be a way to toggle it off, but default should be for inert
<TabAtkins> fantasai: I buy that
<bkardell_> agree
<masonf> +1
<TabAtkins> Rossen_: strong agree
<bramus> +1
<chrishtr> Agree on inert making sense given these arguments
<SebastianZartner> +1 for what jensimmons said.
<TabAtkins> emilio: fair point. Then :modal should apply to fullscreen.
<florian> +1 to Jen
<masonf> q+
<Rossen_> q?
<TabAtkins> fantasai: Right, so decision is whether it's inert, and whether :modal applies is a consequence
<Rossen_> ack jensimmons
<TabAtkins> masonf: Strong agree with points, think fullscreen should inert the rest of the page
<Rossen_> ack masonf
<TabAtkins> masonf: Do we include special provisions for fullscreen escaping that inertness, like dialogs have?
<TabAtkins> masonf: Like if you inert the entire page the fullscreen shoudln't be inert, need provisions for that
<TabAtkins> ntim: That's what fullscreen does
<TabAtkins> masonf: Sure just want to make sure it's captured
<Rossen_> q?
<TabAtkins> Rossen_: additional thoughts or objections?
<TabAtkins> plinss: In conext of dialogs there's clear spec ni html of what puts the dialog into a modal state
<TabAtkins> plinss: in my mind that is what puts into a :modal pseudoclass
<TabAtkins> plinss: think it's important to not just catch things that are modal-ish
<masonf> q+
<TabAtkins> emilio: Yeah fullscreen spec should define the modalness
<masonf> q-
<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
<TabAtkins> Rossen_: so if i understand, fullscreen elements *are* modal from html behavior like dialogs, and rely on same behavior. is that clarification?
<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.
<TabAtkins> plinss: So if fullscreen uses that same definition it's fine.
<masonf> q+
<ntim> https://html.spec.whatwg.org/multipage/interactive-elements.html#is-modal
<SebastianZartner> Maybe we can at least resolve on fullscreen elements making the reset inert.
<TabAtkins> masonf: +1 to that
<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.
<TabAtkins> RESOLVED: Fullscreen elements should inert the stuff behind them, and match :modal

[zcorpan]

Issue for the Fullscreen spec: whatwg/fullscreen#15