- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Jan 2020 16:38:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `<dialog> positioning`, and agreed to the following: * `RESOLVED: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description` * `RESOLVED: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: <dialog> positioning<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4645<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4645<br> <fantasai> ScribeNick: fantasai<br> <fantasai> TabAtkins: Dialog layout description, two modes<br> <fantasai> TabAtkins: 2nd one is a very long run-on sentence that's weird and not described in CSS<br> <fantasai> TabAtkins: Behavior is useful, but unfortunate not in CSS<br> <fantasai> TabAtkins: So a few things to do<br> <fantasai> TabAtkins: First question, is this worth trying to put into CSS?<br> <fantasai> TabAtkins: Next, quick description of what it is and what might be involved, to get an idea of how it would work<br> <AmeliaBR> Define in CSS please!<br> <fantasai> TabAtkins: Thoughts on whether to describe in CSS, or treat as a special one-off case in HTML<br> <fantasai> florian: In general, think it's better to do in CSS<br> <fantasai> florian: but if extremely complicated * low value, maybe not<br> <fantasai> smfr: Authors might want to use the same type of positioning for their own fake dialogs<br> <fantasai> smfr: so better to have in CSS<br> <AmeliaBR> Defining in CSS also makes it easier to modify / override with CSS (e.g., by media queries, interactions with other CSS).<br> <fantasai> TabAtkins: Aim to get a resolution to add this to CSS, does anyone object to me putting this into some spec, probably css-position?<br> <fantasai> TabAtkins: I'm taking the silence as assent<br> <fantasai> tantek: Any security considerations wrt lowering barriers to making fake dialogs?<br> <fantasai> TabAtkins: Can do in JS already<br> <fantasai> TabAtkins: So can we take a resolution to that?<br> <fantasai> RESOLVED: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description<br> <fantasai> fantasai: ...<br> <fantasai> TabAtkins: ...<br> <fantasai> emilio: It's a stateful position, because you don't want to reposition the dialog when you scroll or relayout<br> <fantasai> TabAtkins: here's the basic description<br> <fantasai> TabAtkins: Ignoring stacking context aspect<br> <fantasai> TabAtkins: but for positioning bit<br> <fantasai> TabAtkins: It's basically abspos<br> <fantasai> TabAtkins: where we figure out the offset to apply when it first comes into existence<br> <fantasai> TabAtkins: such that it's safe-centered into viewport<br> <fantasai> TabAtkins: from that point on, it's just abspos -- you scroll the page, it scrolls off<br> <fantasai> TabAtkins: if you dismiss the dialog and regenerate, it will recalculate its position<br> <fantasai> TabAtkins: interesting question is when do we clock thispoint in time?<br> <fantasai> TabAtkins: Answer should be when animation starts<br> <fantasai> iank_: Another way to define is in the DOM layer<br> <fantasai> iank_: for the DIALOG element it could query what the layout is and set the top directly via CSS<br> <fantasai> TabAtkins: Essentially built-in JS<br> <fantasai> iank_: We do this for other things<br> <tantek> is it not fixedpos? huh<br> <fantasai> iank_: It's not great, but might be impler<br> <TabAtkins> nope, it scrolls if you scrol lthe page<br> <fantasai> s/imp/simp/<br> <fantasai> emilio: My objection wrt when boxes are created is that engines create boxes at different times<br> <fantasai> emilio: When you change the display value, Blink will reposition, because it destroys the box and loses the state<br> <fantasai> TabAtkins: If you go from not having boxes to having boxes, you reposition. Having boxes to having boxes, you don't reposition<br> <fantasai> TabAtkins: Ian's description was also quite good, smfr what do you think?<br> <heycam> fantasai: to describe Ian's suggestion, at the point the dialog is launched, the UA sets the top/bottom/left/right to be an absolute position edges of the viewport<br> <heycam> ... and then, we use the alignment properties to center it within that area<br> <heycam> ... then you don't have to calculate the centering<br> <heycam> ... just use the inset properties to bring the abspos range to match the current viewport range when the dialog is launched<br> <heycam> smfr: sounds like you're snapshotting the layout viewport<br> <heycam> fantasai: you're assigning abspos inset properties so that you're creating a box that overlaps exactly the fixedpos containing block<br> <heycam> smfr: wondering if it should be defined in terms of the layout viewport somehow<br> <heycam> TabAtkins: the HTML spec does require recalculating the position if the viewport changes size<br> <heycam> ... guess that's still possible, it's just a ResizeObserver on the window<br> <heycam> smfr: another question is if the user zooms. same behavior as fixpos?<br> <heycam> fantasai: as abspos, if the user wants to zoom in to see the dialog they should be able to<br> <heycam> TabAtkins: don't want fixpos magic. abspos with magic setting at a particular time<br> <heycam> fantasai: I think that this works and is simpler than creating a new magic model with timing implications<br> <heycam> fantasai: question I have is, if you have a dialog that's inside one of these containing block trapping elements, how do you get this element to escape and become contained byt the containing block<br> <heycam> TabAtkins: that's answered by top-layer<br> <heycam> ... in this mode it's always kicked into that<br> <heycam> ... do need to specify top layer rendering<br> <heycam> fantasai: putting something there changes stacking context and containing block?<br> <heycam> TabAtkins: yes<br> <heycam> ... abspos containing block becomes the root<br> <heycam> fantasai: how does that interact with transforms or contain layout?<br> <heycam> TabAtkins: layout containgment should still be fine with escaping<br> <heycam> ... and transforms it changes its parent<br> <heycam> ... it's no longer transformed<br> <heycam> iank_: yes. it's weird<br> <heycam> fantasai: so it sounds like what we're doing is defining a way to put something into the top layer, out of the box tree, into this parallel box tree (list) where the containing block is the size of the entire page<br> <heycam> TabAtkins: I think that's the right thing<br> <heycam> TabAtkins: think it's the whole page<br> <heycam> heycam: interactions with full screen? they'll both be in the top layer<br> <heycam> TabAtkins: we'll need to deal with that<br> <heycam> ... separate but intersecting topics<br> <heycam> smfr: top layers will stack up<br> <heycam> ... if you have full screen and dialog<br> <heycam> fantasai: what's the stacking order?<br> <heycam> smfr: whichever's created first<br> <heycam> ... but we need to define that<br> <heycam> fantasai: it's not as much of a mess as fieldset/legend...<br> <heycam> iank_: painting wise this is more interesting<br> <heycam> smfr: part of me wonders if we need to maintain compat with dialog layout. is this sensible behavior in HTML? or should we define something different<br> <heycam> ... think only Chrome has shipped<br> <heycam> TabAtkins: I've used dialogs in personal projects and enjoyed it<br> <heycam> iank_: are we the only ones shipping it?<br> <heycam> TabAtkins: I think so<br> <heycam> iank_: I would be up for potentially investigating what compat risk there is if there's a more sane model that we think we can ship<br> <heycam> ... the compat thing will be the question<br> <heycam> ... Simon what caused you to start investigating this?<br> <heycam> smfr: I was just looking at how the implementation would work in WebKit<br> <heycam> ... and I dug into the Blink code and found a function deep down<br> <fantasai> i/fantasai: to describe Ian/scribenick: heycam<br> <heycam> ... in block rendering<br> <heycam> ... didn't want to do the same thing<br> <smfr> s/in block rendering/in block layout/<br> <heycam> RESOLVED: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering<br> <heycam> smfr: can we also resolve on specifying top layer behavior in CSS somewhere?<br> <heycam> ... it needs to live along with paint order and z-index<br> <heycam> ... wherever CSS 2.2 Appendix E will go<br> <heycam> fantasai: probably CSS Position?<br> <heycam> smfr: or a new spec<br> <heycam> smfr: I feel like a paint order spec is probably necessary<br> <heycam> dbaron: I think we need a spec for a bunch of rendering stuff, including common terminology<br> <heycam> ... if you remember the big table of horrible test cases for stacking contexts, etc., we need a spec to cover that<br> <heycam> fantasai: so new spec for the painting order<br> <tantek_> perhaps that could include hit-testing which is directly related to stacking order etc.<br> <heycam> dbaron: CSS Rendering Model or CSS Painting Model?<br> <tantek_> more than just painting, the stacking order affects hit-testing<br> <fantasai> scribenick: fantasai<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-577763803 using your GitHub account
Received on Thursday, 23 January 2020 16:38:52 UTC