- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jun 2020 16:45:31 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[dialog element] <dialog> positioning should be describable in CSS`, and agreed to the following: * `RESOLVED: We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [dialog element] <dialog> positioning should be describable in CSS<br> <dael> github: ttps://github.com/w3c/csswg-drafts/issues/4645<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4645<br> <dael> emilio: Started looking into dialog and whole positioning for abspos dialog is weird. Have to snapshot scroll psoition at time you open.<br> <dael> emilio: I think it's not common since most dialogs I know are fixedpos and height of screen at most<br> <dael> emilio: Some discussion in the past. I wonder what is model people feel we should have. fantasai prop snapshot scroll position in dom and apply that<br> <dael> emilio: I think I would like simplier and make dialogs fixedpos, scrollable with max-height is the screen height. Only Chrome ships dialog so I'd like to know their feelings<br> <dael> TabAtkins: Played a bit. Does ability to anchor a dialog to a mouse event exist or is it limited to dialog center on screen<br> <fantasai> issue was about describing the behavior specced in HTML, didn't look into making fundamental changes to it :)<br> <dael> emilio: I don't think we can attach to an element<br> <dael> TabAtkins: If we ever do want to attach to an element some mech is the thing being used to position non-anchor dialogs. If we switch non-anchor to fixedpos we have to figure out how to do it for non-anchored.<br> <dael> iank_: I think a different solution for anchoring down the road<br> <dael> iank_: I tried to work out where this originally came from. It was something like 8 years ago. Only concern I have is webcompat. Given we're only shipping it might be fine. Want to add use counters to see what sites are triggering. Otherwise changing to fixed height and overflow auto sounds fine<br> <dael> emilio: Other weird thing is reposition dialog when viewport resizes. That just feels weird.<br> <dael> iank_: Dialog should always be centered given abspos constraint<br> <dael> emilio: Agree. Whole snapshot is redone when viewport is resized<br> <dael> iank_: Sure. DOn't disagree this is crazy behavior<br> <dael> iank_: I'll add a blink use counter to determine when we're snapshotting a non-0 scroll position. That should cover it and give us insight in web compat<br> <dael> TabAtkins: Okay resolve pending data showing we can't this is the way to go?<br> <dael> iank_: fine<br> <dael> TabAtkins: Prop: We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data<br> <dael> smfr: Only for mobile and therefore in top layer?<br> <dael> TabAtkins: Yeah<br> <dael> smfr: Don't have to worry about transforms b/c not in top layer?<br> <TabAtkins> s/mobile/modal/<br> <dael> TabAtkins: Yeah<br> <dael> chrishtr: Does thia mount to styling same as fulls creen element?<br> <dael> TabAtkins: Yeah<br> <dael> chrishtr: It would just allow a margin?<br> <dael> iank_: top left at 0 but margins are auto which centers<br> <dael> chrishtr: Only difference it margins, sounds good to me. Recently reviewed full screen so this is not a problem<br> <dael> hober: Seems good if they converge since intended to use same underlying<br> <dael> astearns: Do we need to be explicit about connection?<br> <dael> hober: Are since use notion of top layer. A lot of refactor on full screen spec that could move some of this to other specs<br> <dael> chrishtr: Is dialog in a css spec?<br> <dael> TabAtkins: Just in ?? right now<br> <dael> chrishtr: Can we define where we'd put it when work is done?<br> <dael> TabAtkins: I think it's still fine for special styling rules to live in html spec. Only if we're adding new functionality should it be in css.<br> <dael> chrishtr: THe rendering monkeypatches need to be moved<br> <AmeliaBR> s/??/HTML/<br> <dael> tab: We're planning to kill those<br> <dael> AmeliaBR: One new magic thing is idea of top layer. Is that desc?<br> <dael> TabAtkins: Have an open issue for it in positioning spec<br> <dael> AmeliaBR: Needs to be defined and than html can define dialog as rendered in top layer with these properties. Than we solve dialog being desc by css tems in the html spec<br> <dael> chrishtr: Sounds right and same for full screen<br> <dael> florian: And if there is not css terms to desc we should create it rather than have it be magic<br> <dael> fantasai: Desc top layer is a sep open issue<br> <dael> astearns: Any magic aside from top layer?<br> <dael> TabAtkins: Assuming we use prop from earlier no. It's just a fixedpos container<br> <dael> chrishtr: top layer is in a special place b/c it's above scrollbars<br> <dael> TabAtkins: Yes. As fantasai said describing the top layer is a sep issue<br> <dael> astearns: Have open issue for top layer, we will define that. For this issue we're going to resolve that We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data<br> <dael> astearns: Any objections?<br> <dael> RESOLVED: We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data<br> <dael> astearns: Good to get to top layer definition soon so we can remove the magic.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-642130060 using your GitHub account
Received on Wednesday, 10 June 2020 16:45:33 UTC