Closed smfr closed 3 years ago
There's also <center>
and <div align>
, which use https://html.spec.whatwg.org/multipage/rendering.html#align-descendants apparently. Seems weird indeed that HTML has so many non-CSS centering mechanisms.
<center>
and [align]
should both be describable via justify-items: legacy center;
(/legacy right
or legacy left
); that's what we designed those values for. It does depend on browsers implementing justify-self
on display: block
, which hasn't happened yet. We'd be very interested to know if there are quirks we aren't handling there.
As for <dialog>
, if I'm reading it correctly it means:
I think that's it?
So the centering behavior, first, is a basic align-self: safe center;
into the alignment container.
The missing piece is just setting up the alignment container, as neither abspos nor fixpos give the desired rectangle. This instead requires a stateful rendering-sensitive "snapshot" of the current viewport position relative to the rest of the document. The timing issue already exists for things like animations, which start their timeline when an element first generates a box, so we can lean on that concept.
I forget - I think dialog is supposed to display in the top layer, too? Is that a necessary thing to capture here?
Top layer rendering is clearly speced, so this is just about positioning.
(Though note https://fullscreen.spec.whatwg.org/#rendering. Moving that to CSS would be appreciated as well.)
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
I would love to be able to transition/animate these in and out, too, though that may be a separate problem altogether
Details on the proposal:
align-self: safe center
; this takes care of the centering within the viewport.I think the one question I can think of wrt CSS interaction is where the inset
values are injected, if it's at the preshint level or into the style attribute or something else. Depends on what's reasonably implementable and what's reasonably Web-compatible...
@keithjgrant Together with selecting on [open], I think this should allow for animations and transitions of most aspects of dialog layout.
@annevk Does that make sense, or do you need more info for the HTML spec parts of this?
That sounds like an okay plan. I'm not sure I understand "Closed Accepted by CSSWG Resolution" as there still seems to be quite a bit of work outstanding.
@tabatkins for <center>
and align=""
, is there some issue to track on that?
Together with selecting on [open], I think this should allow for animations and transitions of most aspects of dialog layout.
When browsers first added support, this allowed for animating in, but not animating out. Once the dialog closed, it was immediately removed from view by the browser and no CSS I tried was capable of altering this behavior...
This still seems to be the case in Chrome, though Firefox has improved things a little. In Firefox, display: block
can be used to show a "closed" dialog (so e.g. a fade-out animation can be applied on close). Firefox positions the dialog with an inline top
and z-index
, which are only present while open, so these would have to be manually re-calculated to match after the close attribute is removed. In any case, it seems browsers are taking a kind of "whatever works" approach to how these are styled & stacked in a top rendering layer — getting those clearly defined will be a win.
This still seems to be the case in Chrome, though Firefox has improved things a little.
It has to be said that Mozilla has not shipped its implementation yet.
In Firefox,
display: block
can be used to show a "closed" dialog (so e.g. a fade-out animation can be applied on close). Firefox positions the dialog with an inlinetop
andz-index
, which are only present while open, so these would have to be manually re-calculated to match after the close attribute is removed.
As far as I can see, top
and z-index
are not set inline, at least on Windows 10, though here are the styles that are currently used for the element:
Sebastian
Oh right. I forgot I'm on FF Nightly here
@annevk That mapping is covered by https://github.com/whatwg/html/issues/3428
Afaict, this issue is basically solved on the CSS side, except insofar as the "top layer" is still defined in Fullscreen rather than in a CSS spec. If that should be moved over, it deserves its own issue since it's not about DIALOG specifically...
I'll copy over the conclusions from this issue into the WHATWG issue.
Filed the "define Fullscreen rendering in CSS" issue in https://github.com/w3c/csswg-drafts/issues/4998
@fantasai @annevk what about having two attributes on the dialog that map to these properties? That would reuse the general attribute-mapping mechanism which seems sane to me.
(This is about the viewport insets, of course).
Context: Gecko is looking at implementing dialog positioning, and having a layout engine hack seems really sad.
We could potentially also do it without magic attributes and just storing the offsets in the HTMLDialogElement
instance itself, I guess, then injecting the rules in the cascade at the pres hints level, but I'm not sure if there's a precedent for such a thing.
So to be clear, the problem here is
DOM snapshots the top/bottom of the viewport as inset property values when the dialog is opened, and rewrites those values if the viewport is resized.
right? It wasn't entirely clear to me how we would implement that specification-wise. Are new values that act like that another possibility we could consider? If this is a useful primitive, I'm not sure why CSS shouldn't offer it natively.
(Using content attributes for styling seems to go against separation of markup and style, but I might be misunderstanding something. Your final solution would work, but would still make HTML own some layout logic it probably shouldn't.)
So the current thing is pretty weird. As far as I can tell, fixed dialogs are not an issue, but abspos dialogs somehow depend on the current root scroll position from where the dialog is open.
Implementing this in the layout engine itself is pretty unfortunate IMHO. Also the current specified behavior of repositioning whenever the viewport size changes has some pretty weird effects in presence of scrolling. (You position the dialog, scroll down so that the dialog is out of view, resize the window and the dialog is back up again, that looks borked).
Can we discuss alternatives?
Either snapshot the state in the DOM, and make DOM read the scroll position from showModal()
and maybe react to resizes and such. Probably such a declaration would be inserted in the presentational hints level in the cascade, so that authors can override it.
Maybe, instead, make dialogs have something like max-height: 100vh
, and force them to be scrollable? That makes fixed-positioned dialogs more sound / appealing. I need to admit I'm not sure what the usecase for an absolutely positioned dialog is in the first place, that's not how any other dialog like OS dialogs work, afaict.
@smfr I wonder what your thoughts on this are?
(Tagging as agenda+ as I to double-check with the working group whether the resolution above still stands, how it would behave for abspos dialogs, and if so, what are the specifics of how the snapshotted offsets end up in the cascade)
My preferred approach would be to always host the dialog inside a position:fixed container and describe something that makes the dialog scrollable if taller than the screen. But I'm not sure that gives the desired positioning behavior. I'm not a fan of the "snapshot the scroll position" approaches.
Dumb question: what is the dialog's containing block for a modal dialog?
My preferred approach would be to always host the dialog inside a position:fixed container and describe something that makes the dialog scrollable if taller than the screen.
I agree actually! So maybe the dialogs should just be max-height: 100vh; overflow: auto;
or something of that sort. Was that something like what you had in mind? Or some other kind of magic?
Dumb question: what is the dialog's containing block for a modal dialog?
I think right now it depends, if it's fixedpos it'd be the viewport, if it's abspos it'd be the ICB.
Part of the desire here was
authors should be able to achieve the same positioning behavior for their own elements.
so if we allow the abspos behavior, we should also add some new CSS to allow authors to apply this to their own elements. That's not something I relish doing, since we'd then probably need the same special-casing for all the properties that force containing-block-for-positioned-descendants (filters, transforms etc).
This is a strong argument to just go with the fixed pos approach. Do we know if the "should be able to scroll the dialog out of view" behavior is a strong requirement? Who came up with it?
Here's some of the history found through git log --grep=dialog
in rough chronological order:
Things related to the first commit:
I didn't really spot anything that suggested these tradeoffs were considered in detail.
It seems @mattto and @tabatkins were involved so maybe they can provide some context, though it's also been many years.
I can spend some time adding some use-counters to the Blink implementation to see what is being used. What do folks want to know?
If we can go for position fixed behaviour we could define this as a "center" static-position.
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
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. iank_: I think a different solution for anchoring down the road
I think we should open a separate issue for this because authors do want this capability outside of the specific <dialog>
need (eg: tooltips, dropdown menus, etc). So this should be thought about sooner rather than later. In the research that @annevk shared there are many examples that are not centered and are anchored to an element. While I get the implementation concerns I'm also curious of making the dialog itself the scroller via overflow behavior is the right way. Most of the scenarios that come to mind however normally don't fit in what seems to be the primary definition (based on what is shipping) as a <dialogue>
.
cc: @melanierichards
@bfgeek I think this deserves its own issue? Also are there other use cases for :modal
or is it just for flipping the DIALOG element between position: absolute/fixed
in the UA default style sheet?
Regarding :modal
, it seems to me that modal
should really be an attribute, just like open
. Then, not only would that state be targetable with normal attribute selectors, but with the added benefit of being able to create modals with HTML. It always puzzled me why there is an open
attribute, but not a modal
attribute.
+1 to what @LeaVerou - ironically we had this discussion in March of 2019 and likewise wanted an attribute
The CSS Working Group just discussed Dialog element
, and agreed to the following:
RESOLVED: Add a hidden pseudo-class for this purpose, in order to solve styling issue while leavine open the possibility of HTML improving its API
emilio: might want to fix it, but it's a separate issue ... iank_: I don't think having an attribute API for dialog is a good idea
@bfgeek @emilio @LeaVerou the aspect of open being an attribute
I would like to call attention to a resolution in Open UI regarding the open attribute/property on the <select>
that would behave the way in which authors would expect it to (eg: open/close based on the attributes existence).
https://github.com/WICG/open-ui/pull/236
cc: @una @dandclark @melanierichards
I see this issue is closed, but I don't understand how one is supposed to position the dialogue? E.g. some wish to position the dialog at the top of the screen?
As shown in my previous comment, the dialog is centered via margin: auto;
by default. So, you can position it at the top by adding margin: 0;
.
Sebastian
HTML describes the "centered alignment" of a dialog element in somewhat opaque prose.
Blink's implementation of this is a hack in their rendering code
This needs to be described in terms of CSS (ideally as some rules in the UA stylesheet). Apparently it's not implementable in CSS, which is a problem. First, UAs should not have to add custom layout code for the dialog element, and second authors should be able to achieve the same positioning behavior for their own elements.