- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jan 2022 16:46:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `how does top-layer interact with ancestors`, and agreed to the following: * `RESOLVED: Set visiblity:hidden on modal dialogs` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: how does top-layer interact with ancestors<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6939<br> <TabAtkins> smfr: top-laye ris used by <dialog>, ::backdrop,e tc<br> <TabAtkins> smfr: They generate new stackign contexts, escape ancestor opacity, other graphical effects<br> <TabAtkins> smfr: 'visibility' is a bit different<br> <TabAtkins> smfr: It's inherited; as specced, a visibility:hidden ancesotr will hide a dialog<br> <TabAtkins> [simon was dropped]<br> <TabAtkins> smfr: Tab responded with a confusing comment<br> <fantasai> TabAtkins: ...<br> <TabAtkins> smfr: he said top-layer things are reparented in the box tree<br> <TabAtkins> smfr: so that doesn't affect inheritance<br> <TabAtkins> smfr: I think people might be confused about that effect with visibility<br> <TabAtkins> smfr: Maybe UA stylesheet should put visibility:visible on the dialog?<br> <TabAtkins> ntim: Worth nothing - display:none on the ancestor propogates to the top-layer element<br> <TabAtkins> emilio: unsure to what extent display and visiblity work together<br> <TabAtkins> emilio: was going to suggest Simon's UA stylesheet tweak to make it work<br> <fantasai> TabAtkins: That seems fine to me. I don't see a particular issue to set 'visiblity' in the UA stylesheet<br> <fantasai> TabAtkins: I think it is surprising that a dialog would stay hidden if the ancestor is hidden<br> <TabAtkins> emilio: Seems like a special case, yeah. But other than that, no strong feeling.<br> <fantasai> TabAtkins: I guess 2 resolutions<br> <fantasai> TabAtkins: a) Top-layer elements are essentially reparented in the box tree, so visual effects from containers don't apply, but inheritance applies as normal<br> <fantasai> TabAtkins: b) We add rule to UA stylesheet that dialog is visibility: visible<br> <fantasai> emilio: I'm not super convinced we should add it<br> <fantasai> emilio: could argue the same for a ton of other properties<br> <fantasai> emilio: but not strong, so won't object<br> <fantasai> astearns: what other properties?<br> <TabAtkins> emilio: everything that inherits, like pointer-events<br> <TabAtkins> emilio: anything that inherits thru could potentially be weird<br> <TabAtkins> astearns: And we're onlyt alking about setting visibility and not display<br> <fantasai> TabAtkins: display is consistent with what I said because it can't be reparented in the box tree, because it's not in the box tree<br> <TabAtkins> astearns: So first proposal from tab is top-layer elements are reparented in teh box tree, and point out that inheritance isn't affected by that<br> <TabAtkins> smfr: The "etc" in the spec text needs clarification<br> <emilio> q+<br> <TabAtkins> TabAtkins: agree, can do that<br> <astearns> ack emilio<br> <TabAtkins> emilio: related to 'display' issue, something came up recently while triaging<br> <TabAtkins> emilio: Blink will create a box if the dialgo is a child of the replaced element<br> <fantasai> TabAtkins: I probably agree with you, decided on that in my comment too quickly. Because affects box generation, dialog shouldn't display at all<br> <TabAtkins> astearns: So any more discussion on the "reparenting in box tree" portion?<br> <fantasai> smfr: do we need to be that specific?<br> <fantasai> TabAtkins: You asked a bunch of questions, need to have consistent answers<br> <fantasai> TabAtkins: and having this conceptual model gives us consistent answers<br> <TabAtkins> ntim: I think stacking context/containing block dfns are enough to cover those cases<br> <fantasai> TabAtkins: Possibly<br> <fantasai> TabAtkins: I can review and see if that's enough<br> <fantasai> astearns: So why don't we not take that resolution for now, and you cna review<br> <TabAtkins> astearns: Okay so the etc<br> <fantasai> ntim: pointer-events<br> <fantasai> TabAtkins: It's an inherited property, so will just inherit. Unless we want to do a reset in the UA stylesheet<br> <fantasai> astearns: Do we need to resolve on resetting visibility?<br> <fantasai> TabAtkins: OK, let's do that<br> <fantasai> astearns: Proposed to have UA stylesheet reset visibility for dialog ... what about other top-level elements?<br> <fantasai> TabAtkins: Can't for other elements, can be arbitrary elements<br> <fantasai> TabAtkins: so can only do for dialog<br> <fantasai> astearns: OK, so proposed is that UA stylesheet sets 'visibility' on dialog<br> <fantasai> smfr: when they are in the modal state<br> <fantasai> fantasai: I believe there's a :modal pseudo-class in HTML<br> <fantasai> ntim: we have a pseudo-class, but internal, not exposed in CSS<br> <fantasai> iank_: I wrote that internal class<br> <fantasai> iank_: Wording is there, but not actually in the HTML spec<br> <fantasai> astearns: Anything else we can use to select?<br> <fantasai> TabAtkins: reasons we don't want to go into, are they blockers to putting in HTML spec or historical?<br> <fantasai> iank_: There was pushback to adding as an actual pseudo-class<br> <smfr> q+<br> <fantasai> iank_: HTML spec didn't want to define pseudo-classes itself<br> <fantasai> TabAtkins: put it in Selectors<br> <fantasai> ntim: UA stylesheet, should have a statement about it<br> <astearns> ack smfr<br> <fantasai> smfr: Comment about ::backdrop<br> <fantasai> smfr: current behavior, if have visiblity:hidden ancestor on dialog<br> <fantasai> smfr: is that dialog is hidden but backdrop shows up<br> <fantasai> smfr: because backdrop not affected by inherted visibility, that's not great<br> <fantasai> TabAtkins: right, because ::backdrop inherits from the root<br> <fantasai> emilio: I thought it didn't inherit, which causes problems with system properties<br> <fantasai> rune: ...<br> <iank_> https://html.spec.whatwg.org/#phrasing-content-3 and scroll up<br> <fantasai> emilio: Which is something we may want to consider fixing<br> <fantasai> TabAtkins: That can be done in today's CSS by setting 'all: initial' in the ::backdrop stylesheet<br> <fantasai> TabAtkins: so explainable in current CSS<br> <fantasai> emilio: is it though?<br> <iank_> "The dialog element, when its is modal flag is true, is expected to act as if it had a user-agent-level style sheet rule setting the following properties:"<br> <fantasai> emilio: all doesn't reset custom properties<br> <fantasai> emilio: We have an agenda item about selection, e.g. new ::selection model not inheriting from original element which causes other issues<br> <fantasai> iank_: Quoted the prose from HTML<br> <fantasai> TabAtkins: HTMl spec says "pretend there's a pseudo-class, and apply these properties"<br> <fantasai> TabAtkins: let's just define the pseudo-class<br> <fantasai> iank_: Pushback was exposing the internal pseudo-class to web developers<br> <fantasai> astearns: Is there a concern about exposing to web devs?<br> <fantasai> emilio: I think Gecko was the first to implement via internal pseudo-class<br> <fantasai> emilio: Everyone converged on that model<br> <fantasai> emilio: I think at first there was some resistance to expose a pseudo-class because not how some browsers work<br> <fantasai> emilio: but at this point, given we have interop in that sense, all browsers have internal pseudo-class<br> <fantasai> emilio: maybe makes sense to expose it<br> <fantasai> iank_: Agree it makes sense, but think we'll still get pushback from WHATWG<br> <fantasai> iank_: Another thing that could be internal class but isn't<br> <fantasai> TabAtkins: we don't have to invoke WHATWG, we just put it in Selectors<br> <fantasai> TabAtkins: as long as browsers want that, not a jurisdictional problem<br> <fantasai> emilio: ...<br> <fantasai> TabAtkins: To change the styling of a dialog based on whether it's open in a modal style or not, if UA wants to do it don't see why authors wouldn't want to do it<br> <fantasai> ntim: I don't see much use case for it<br> <fantasai> ntim: Unlikely that someone will call showModal() and show() on the same dialog<br> <fantasai> astearns: I suggest we separate out whether propertly-defined pseudo into own issue<br> <fantasai> astearns: but whether or not we do that, we should define certain things for dialog using existing internal pseudo-class<br> <fantasai> astearns: so have some changes mentioning that you set visiblity and perhaps pointer-events<br> <fantasai> astearns: using same handwavy definition that HTML currently has<br> <fantasai> astearns: and separately figure out whether we need an exposed real pseudo-class to put into Selectors<br> <fantasai> astearns: does that sound reasonable?<br> <fantasai> TabAtkins: OK, opening issue<br> <fantasai> astearns: So can we resolve to set visiblity using internal pseudo-class?<br> <fantasai> astearns: Anyone want to continue discussing? Anyone have an objection?<br> <fantasai> [continued silence]<br> <fantasai> RESOLVED: Set visiblity:hidden on modal dialogs<br> <fantasai> astearns: Any other property to resolve now, or continue discussing in the issue?<br> <fantasai> ntim: Pointer-events maybe?<br> <fantasai> ntim: Idk if it should be auto or all ...<br> <fantasai> astearns: In interest of time, let's punt to issue<br> <fantasai> astearns: and find out what the value should be and figure out any other properties that should be set in this way<br> <fantasai> astearns: Done with this issue for today<br> <fantasai> astearns: bit about box-tree reparenting, should that be a separate issue so don't lose track of it?<br> <TabAtkins> (new issue for :modal-dialog https://github.com/w3c/csswg-drafts/issues/6965)<br> <fantasai> astearns: OK, we'll keep this issue just about properties to set in UA stylesheet<br> <fantasai> astearns: separate issue on modal pseudo-class<br> <fantasai> astearns: and separate issue on reparenting<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6939#issuecomment-1016657928 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 January 2022 16:46:16 UTC