- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 29 Apr 2026 17:01:23 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position-4] Consider removing the overlay property`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> jarhar: overlay property I feel like has become a bit of a developer issue<br> <kbabbitt> ... to this day I'm still helping people out with demos where something doesn't work because they forgot overlay in list of properties to transition<br> <kbabbitt> ... all these cases seems like a no-brainer with the stuff set up with a display animation<br> <kbabbitt> ... should be able to figure out that element should be kept in top layer until end of animation<br> <kbabbitt> ... thinking of ways to remove overlay<br> <kbabbitt> ... could wait until element becomes display:none<br> <kbabbitt> ... started seeing things that concerned me with this<br> <lwarlow> q+<br> <kbabbitt> ... said a lot in the issue already<br> <kbabbitt> ... there was in my last comment, referenced 2 things, a Chrome regression bug where someone was expecting display:block to return a popover from top layer to document flow<br> <kbabbitt> ... jake archibald had an example that becaome a tooltip and then went to document flow<br> <kbabbitt> ... remove overlay and keep things in top layer until display:none, these two examnples wouldn't work properly anymore<br> <kbabbitt> ... another idea I had was, maybe we can do something smarty with looking at display animations<br> <kbabbitt> ... if there's currently an animation for display on this element, we can keep in top layter until animation finishes<br> <kbabbitt> ... thought about this more again a few minutes ago and posted another comment<br> <kbabbitt> ... in hide popover steps, update pseudo classes<br> <kbabbitt> ... to give author CSS time to start a display aniation<br> <kbabbitt> ... query element afterwards to see if a display animation started<br> <kbabbitt> ... if sio, wait for it to finish and then remove from top layer<br> <kbabbitt> ... if not, remove from top layer right now<br> <kbabbitt> ... good indication author is not trying to do a top layer animation<br> <kbabbitt> ... was thinking about prototyping some of this stuff, didn't finish but started<br> <masonf> qq+<br> <ntim> q+<br> <kbabbitt> ... any thoughts on whether this is a good idea or bad idea?<br> <emilio> q+<br> <kbabbitt> masonf: my original prototype for popover was designed this way, it worked very nicely<br> <astearns> ack masonf<br> <Zakim> masonf, you wanted to react to emilio<br> <astearns> ack lwarlow<br> <flackr> q+<br> <kbabbitt> lwarlow: 2 points<br> <kbabbitt> ... is part of the issue the overlay property and people not remembering it because it's only in Chromium?<br> <kbabbitt> ... documentation concern more than implementation one<br> <kbabbitt> ... if we need a signal that this is top layer in some other situation, overlay property seems to make sense<br> <kbabbitt> ... if we did not get rid of it, idea of looking at display property doesn't work because you might have a popover going to in page and actually hiding<br> <kbabbitt> ... one thing you could look at is position property as well<br> <kbabbitt> ... does position property get updated to e.g. static which would return to in page flow<br> <kbabbitt> ... can say okay they're moving to in page flow rather than hiding<br> <kbabbitt> ... and could use that plus display check to see if this should happen or not<br> <kbabbitt> ... don't know if there would be other use cases to solve, might be one idea<br> <astearns> ack ntim<br> <kbabbitt> ntim: one suggestion I had on issue was to make overlay a longhand of display<br> <jarhar9> the popover element is position:fixed whether its open or closed, so by default it wouldn't currently change its position<br> <kbabbitt> ... so if you transition display that would transition overlay as well so you wouldn't need to specify both<br> <flackr> +1 was going to suggest the same thing, transitioning display should implicitly transition overlay<br> <kbabbitt> ... brings up some of the previous questions about shorthanding<br> <kbabbitt> ... but I think it solves this nicely without any magic<br> <astearns> ack emilio<br> <keithamus> q+<br> <kbabbitt> emilio: that seems a bit, wanted to suggest something similar, but thinking more about it, I think I disagree ... if you make display a shorthand, then setting display:none also uunsets overlay<br> <keithamus> q-<br> <kbabbitt> ... but setting display something else also does<br> <kbabbitt> ... need to make display ... need a bit of magic at the very least<br> <kbabbitt> ntim: some of this is in UA stylesheet, sets overlay !important alreadyh<br> <kbabbitt> ... transition will happen anyway because of that<br> <kbabbitt> flackr: from value would have overlay<br> <keithamus> q+<br> <kbabbitt> emilio: then you need to serialize it somehow, getComputedStyle of display<br> <kbabbitt> ntim: some font properties are reset-only<br> <kbabbitt> ... don't necessarily need to serialize for some shorthands<br> <kbabbitt> emilio: a shorthand either serializes its value or empty string<br> <kbabbitt> ... so gCS for display would serialize empty string which would be weird<br> <kbabbitt> astearns: let's set aside details of shorthanding strategy until we get through queue<br> <kbabbitt> emilio: another proposal related to that, transition property display also expands to overlay<br> <kbabbitt> ... that's a bit more scoped maybe<br> <kbabbitt> astearns: not sure I get that suggestion<br> <astearns> ack flackr<br> <kbabbitt> flackr: a lot of what I was going to say has been covered, was going to suggest same thing that transitioning display should implicitly transition overlay<br> <kbabbitt> ... how we do that is a technical question, emilio's suggestion of this being some magic in transition may be a good one<br> <jarhar9> expanding transition-property:display to overlay but not expanding display:block to also do overlay makes sense i think<br> <kbabbitt> ... one reason I think we should do this instead of display magic is you end up with weird cases where you can hae a display animation whose values are the same but that causes overlay to stick<br> <kbabbitt> ... hard to explain to developers if this is internal magic, easier if it's actually doing a transition on overlay propertu<br> <astearns> ack dbaron<br> <kbabbitt> dbaron: 2 things, one is, to reiterate point that part of what's going on is that we have a property ... goal here with overlay property wqas to have a property authors couldn't change except by transitioning<br> <kbabbitt> ... which is a little wierd<br> <kbabbitt> ... only thing that sets is !important rules in UA sheet<br> <kbabbitt> ... that docukment when something is in the top layer<br> <kbabbitt> ... but then we allow it to be transitioned so authors can mess with timing of when change happens, but not with the fact that it's happening<br> <kbabbitt> ... I think I'm more okay with emilio's suggestion of making it specific to transition-propertuy<br> <kbabbitt> ... broader shorthanding would have interesting implications for serialization and other things I don't think we want to take on here<br> <astearns> ack keithamus<br> <kbabbitt> ... shorthanding relationship specific to transition-property soundsl ike a plausible solution<br> <kbabbitt> keithamus: border-image on border shorthand doesn't serialize<br> <kbabbitt> ... weird side ffect is you can't express border shorthand after border-image<br> <bramus> Same with a bunch of animation-* properties<br> <kbabbitt> ... a bit of a user gotcha, understand you can't express overlay property ,might be weird side effects<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: just wanted to point out, additional considerations outside ths cope of this discyussion<br> <kbabbitt> ... often. need to preserve anchoring relationship<br> <kbabbitt> ... UA styles applyed to modal to state modal-ness and at which point it disappears<br> <kbabbitt> ... can affect animations in awkward ways<br> <keithamus> q+<br> <kbabbitt> ... don't have solutions, just more problems<br> <astearns> ack keithamus<br> <flackr> q+<br> <kbabbitt> keithamus: if I remember, in Gecko the dialog's modalness is part of its top layer ness<br> <kbabbitt> ... happen at the same time<br> <lwarlow> q+<br> <kbabbitt> ... but we don't implement overlayu<br> <kbabbitt> ... agree implicit anchor has same awkwardness<br> <astearns> ack flackr<br> <kbabbitt> ... if you don't do these in tandem, gets you into weird states where you might reposition in the middle of an animation<br> <kbabbitt> flackr: haven't thought through details but one approach to solve related properties would be to transition them as well<br> <kbabbitt> ... maybe this is getting into broader ... maybe we should have a transition shorthand for all properties changing during modality change<br> <astearns> ack lwarlow<br> <kbabbitt> ... that'd be a way I could imagine style engine handling this potentially<br> <kbabbitt> lwarlow: on the modal pseudo class implicit popover, yes it's awkward engine needs to keep 3 states in sync<br> <kbabbitt> ... I think we have a spec PR that fixes this, don't think it's that big a deal<br> <ntim> q+<br> <kbabbitt> ... popover data implicit = null, set modal = false, and one after the other in each of these ases<br> <kbabbitt> ... in reality I think it's fine<br> <kbabbitt> ... having said that I think webkit does ? similarly<br> <kbabbitt> ... they don't do overlay, haven't shipped it<br> <kbabbitt> ... don't think 3 states managed together is that hard once spec has it<br> <emilio> q+<br> <astearns> ack ntim<br> <kbabbitt> ntim: also question of position UA styles<br> <kbabbitt> ... where a modal dialog has top something left something right something<br> <kbabbitt> ... I know jarhar had a PR to solve that<br> <kbabbitt> ... by magically applying UA styles during transiton<br> <kbabbitt> ... but I'm not very satisified with that, but that's a different issue<br> <kbabbitt> ... don't need to solve here<br> <astearns> ack emilio<br> <kbabbitt> emilio: there's some precedent in things that take property name lists to take magic keywor4ds<br> <kbabbitt> .... will-change for instance<br> <kbabbitt> ... will-change: draw for example<br> <kbabbitt> ... could consider something similar here<br> <kbabbitt> astearns: we've been discussing how to deal with the animations of things moving to and from top layer<br> <iank_> "scroll-position | contents | <custom-ident>"<br> <kbabbitt> ... but the issue started with describing the overlay property's existence being a footgun<br> <kbabbitt> ... are just adding a footgun to this problem by adding magic to transition-property?<br> <kbabbitt> flackr: disagree. footgun was that develkopers forgot to specify<br> <keithamus> q+<br> <kbabbitt> ... making way to animate this more automatic is addressing this footgun<br> <kbabbitt> astearns: jarhar9 do you agree? are you okay keeping this property and adding stuff to make it work?<br> <astearns> ack keithamus<br> <kbabbitt> jarhar9: yes<br> <ntim> :modal pseudo-class issue: https://github.com/w3c/csswg-drafts/issues/13594<br> <kbabbitt> keithamus: is there more magic required if you had, could hold stuff in top layer forever if you set animation timing to a large number<br> <kbabbitt> ... could open a popover and hold in top layer forever with a long animation<br> <masonf> q+<br> <kbabbitt> ... might need more magic there to circumvent those issues<br> <lwarlow> Do we actually need to make any change? Is the status quo not okay?<br> <astearns> ack masonf<br> <kbabbitt> masonf: is that an attack vector? could just do with popover manual yourself<br> <kbabbitt> keithamus: circumvention where you could close ... popover manual is not issue but modal dialog is, makes rest of page inert<br> <kbabbitt> ... if held open with animation, even pressing escape twice would not dismiss<br> <lwarlow> q+<br> <kbabbitt> masonf: but modality and top layer are different things<br> <kbabbitt> ... this should not hold modaliuty, should hold top layer<br> <kbabbitt> keithamus: then it gets tricky<br> <kbabbitt> ... contradicts earlier discussion that these are same state<br> <kbabbitt> ... gets tricky becquse you're top layer dialog that isn't modal<br> <fantasai> masonf, that'll mean that `:modal` styles top matching though, right?<br> <kbabbitt> lwarlow: ? exist to prevent navigation<br> <kbabbitt> ... double pressing escape is not a problem<br> <kbabbitt> ... none of these are attack vectors<br> <kbabbitt> masonf: right<br> <kbabbitt> astearns: I think we need to take this back to the issue an dhave a detailed proposal for how we deal with exit animations if we keep overlay property<br> <kbabbitt> ... once we have that we can get a resolution<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13200#issuecomment-4345836438 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 April 2026 17:01:24 UTC