- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 May 2025 15:30:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] Support setting offscreen content inert`, and agreed to the following: * `RESOLVED: Interactivity does not inherit, and setting it on something that's inert does not change the intertness` <details><summary>The full IRC log of that discussion</summary> <dandclark> masonf: There is an HTML spec PR for this<br> <dandclark> ...It's connecting to CSS concept of interactivity. There have been changes. Part of what's in PR will change<br> <dandclark> ...it keeps existing behavior for modal dialogs. It allows interactivity keyword in CSS to cause intertness. It explains the existing inter attr in terms of that property<br> <dandclark> ...allows to you de-inert things.<br> <dandclark> ...Can exempt subtree to be un-intert. that's expected to change<br> <dandclark> flackr: We're proposing to discuss not de-inerting anymore. Have the interactivity prop be synonomous with the HTML prop<br> <dandclark> ...can't escape inertness aside from preexisting dialog semantics (which is internal magic)<br> <dandclark> flackr: It becomes non-inherited property.<br> <dandclark> ...The way you determine inertness is once you see inert at any point in tree, applies to all descendants, just like inert attribute<br> <dandclark> annevk: Why do we need interactivity property?<br> <dandclark> flackr: So it can be applied dynamically by CSS. Lots of cases where it's useful<br> <jarhar> dandclark: do we still have a11y folks involed in this conversation?<br> <jarhar> dandclark: theyre interested in this conversation, i hope theyre still involved<br> <dandclark> flackr: This has been ongoing discussion<br> <dandclark> ...you can see in various issues<br> <dandclark> ...change to interactivity is part of attempt, if we allign with HTML intert prop, it has the same implications as we already have for that<br> <dandclark> ...nice cleanup, it explains HTML prop like display:none explains hidden property<br> <dandclark> masonf: This change is a result of those convos<br> <dandclark> astearns: This seems like a necessary change, but not sure it's suffiient to address all concerns from a11y folks<br> <dandclark> flackr: Synonymouse with HTML inert<br> <emilio> q+<br> <dandclark> ...can argue it can be used more broadly now. But seems prescriptive to tell authors they can't do this with CSS when they can with HTML<br> <dandclark> astearns: Requires AT to update that it's not just HTML<br> <dandclark> flackr: This is just a browser thing<br> <dandclark> masonf: Right, should be exposed to AT in the same way<br> <astearns> ack emilio<br> <dandclark> emilio: As part of this work are you chaning HTML inert from being magic to be mapped to CSS prop<br> <dandclark> masonf: Answer is yes. There is still magic because dialogs get to de-inert things magically<br> <dandclark> annevk: Will CSS define all the inert logic? Moving that from HTML?<br> <dandclark> masonf: No, defined in both places<br> <dandclark> annevk: Hows' that make sense<br> <dandclark> masonf: HTML spec PR refers to both CSS and HTMl concept of inert<br> <dandclark> annevk: That' snot what you said before<br> <dandclark> masonf: You said the concept of ineert, which is defined in both places<br> <dandclark> masonf: Both mechanisms apply concept of inertnesss to tree<br> <dandclark> ntim: I think anne is referring to conecept of inertness, not the attribute. Why not move the whole def to CSS?<br> <dandclark> flackr: It's editorial<br> <dandclark> ...can define in CSS if that makes more sense<br> <dandclark> masonf: It's already defined in CSS, but yes let's get the language right, any of these are fine<br> <masonf> CSS concept: https://drafts.csswg.org/css-ui-4/#inert<br> <dandclark> annevk: I'm not sure it's editorial. If we move these concepts, we'll have to change a bunch of thigns<br> <dandclark> ...Then css has to be in charge of interactivity, whether nodes are interactive<br> <dandclark> masonf: I think it does, pasted link above^<br> <dandclark> annevk: Identically to what we have in HTML?<br> <dandclark> masonf: HTML links to that definition<br> <dandclark> masonf: The behaviors come from CSS<br> <dandclark> annevk: It's not just editorial. Are the behaviors identical?<br> <dandclark> masonf: My PR removes some of these defs and refers to CSS<br> <dandclark> annevk: But not removing the entire concept<br> <dandclark> annevk: Concept could live in CSS, if identical<br> <dandclark> masonf: I agree<br> <dandclark> astearns: Makes sense to ensure we are defining something identical. But editorial in that it's something we need to work through once we decide the design we've got is what we want to move forward with with.<br> <dandclark> ...whether we have interactivity prop is the more fundamental question, not sure we're there yet<br> <dandclark> ...Hope this change will address the a11y concerns but need to ensure that's the case<br> <dandclark> ...We don't yet have resolution to make interactivity not inherit. Can we resolve?<br> <dandclark> s/Synonymouse/synonymous<br> <dandclark> emilio: Can we resolve in this meeting?<br> <dandclark> astearns: Yes, it's joint meeting<br> <dandclark> annevk: Assumption is that the a11y people not in room agree with this<br> <dandclark> flackr: It's one of the things that have been identified, is a move in the right direction<br> <dandclark> ...remaining concern is whether you should be able to set inertness from CSS at all<br> <dandclark> annevk: Yes that seems separate<br> <dandclark> astearns: But very relevant<br> <dandclark> flackr: But you can, with visibility: hidden<br> <dandclark> Proposed resolution: Make interactivity not inherit.<br> <RRSAgent> I'm logging. Sorry, nothing found for 'link'<br> <RRSAgent> I'm logging. Sorry, nothing found for 'logs'<br> <dandclark> <wordsmithing resolution><br> <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/15-css-minutes.html annevk<br> <dandclark> Proposed resolution: Interactivity does not inherit, and setting it on something that's inert does not change the intertness<br> <masonf> +1<br> <flackr> +1<br> <dandclark> RESOLVED: Interactivity does not inherit, and setting it on something that's inert does not change the intertness<br> <ntim> s/intert/inert :)<br> <dandclark> astearns: I know this CSS prop is important to carousel set of proposals. What happens if there isn't interactivity property?<br> <dandclark> flackr: For a bunch of use cases they'll have to add prop via JS<br> <dandclark> vmpstr: Or they'll add visibility but that limits the effects you can have<br> <dandclark> flackr: Visually changes the things that are not current<br> <dandclark> ...When scrolling, you would see the new contents pop into visibility as it becomes active<br> <dandclark> ...In many use cases you can peek at next content<br> <dandclark> ...Interactivity prop supports this<br> <dandclark> astearns: Can't do this another way?<br> <dandclark> flackr: Right<br> <dandclark> astearns: Other questions or comments?<br> <dandclark> ...before we take it back to issue<br> <dandclark> masonf: I will update to incorporate the resolution, would like review after that<br> <dandclark> astearns: And you'll remove special casing for setting things uninert?<br> <dandclark> masonf: Right<br> <jarhar> https://github.com/whatwg/html/issues/8189#issuecomment-2877242732<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10711#issuecomment-2884252218 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 May 2025 15:30:49 UTC