https://jsfiddle.net/dg16dwjj/7/ it's working for me after a bit of investigation

The fact that desired functionality can be achieved with CSS is great. We can leave this bug open to determine whether the current behavior (without the CSS workaround), matches the specified behavior.

It looks like it doesn't.

falken, why would dialog recentering depend on top, bottom (see dbeam's workaround styles in Comment 1)?

Chrome’s implementation works as follows. The centering is scheduled to occur once when showModal() is called. If the dialog is meant to be centered (top and bottom are both auto), it’ll calculate the top position that will center it and use that top centered value. It continues to use that centered value until it top/bottom are set to override it. That way it survives future layouts.

The spec additionally called to recenter when the window viewport size changed horizontally, but I didn’t implement that. Similar to anchored positioning, the implementation didn’t match all the features of the spec.

I’m not sure whether the the dialog is expected to relayout when content is added. The spec says to set the centered position “when it is in that mode and has new rendering boxes created”, which I interpreted to mean when the dialog itself is shown, not when boxes inside the dialog are created. That seems logical; otherwise the spec might say "created or removed" to recenter when content is removed as well.

So I’m not totally sure why top/bottom of 0 are centering the dialog. This would seem to totally bypass the dialog centering logic. Does a div set to top/bottom 0 with dialog’s default CSS style also center? Or maybe centering is a side-effect of being in the top layer?

See also the FAQ “How do I position a dialog?” at http://demo.agektmr.com/dialog/.

So it seems like *at least* "Dialog does not re-center itself vertically when window is resized" is a bug per spec. It would be great to find/write web platform tests for this.

falken, why didn't we implement the resizing part? There's a story here about new style or layout properties needed to track this or something?

Adding layout to see if they have ideas.

We should keep in mind FF is implementing dialog now and it would be good to make it interoperable, might be a good time to rationalize tests and specs.

dominicc@: is it common to specify at this level of granularity?

adding top/bottom: 0; to user agent styles and keeping unspecified would improve the default style and those that care about specific presentation could override or also set explicitly to ensure.

it'd be worth trying this before specifying, IMO, to see if folks like it (or if it breaks anybody).

> falken, why didn't we implement the resizing part?

I don't think there was a strong reason, it just didn't block shipping and was something that could be added later if people turned out to really want it.

I think it wouldn't be too difficult to implement this: on resize you'd mark the dialog as needing center positioning (m_centeringMode = NeedsCentering) and it'd be centered on the next layout. Or maybe call forceLayoutForCentering() directly.

@dbeam: Common to specify which part at this level of granularity? I think the high level goal is independent, interoperable implementations. Whatever it takes to get that.

Setting top/bottom in the UA stylesheet isn't that appealing to me for these reasons:
- We don't seem to understand why top/bottom: 0 works as a workaround yet.
- It doesn't fix the behavior per spec, which talks about top/bottom: auto recentering on resize. (We would have to change the spec.)


@falken, thanks for the pointers. You wrote:

> The spec additionally called to recenter when the window viewport size changed horizontally, but I didn’t implement that.

Did you mean vertically? Because the dialog does seem to recenter when you resize horizontally, just not vertically.

So here's the actions we need here:

- File a spec bug getting clarification on what it means to create boxes and when a dialog should be recentered.
- Fix the vertical resize centering we're missing per falken's notes.
- Web platform tests so Firefox and Chrome can interoperate.

I guess I'll tentatively own this but feel free to poach.

Talked with falken offline. Horizontal was not a typo--the spec is specific about recentering when the viewport is resized horizontally.

- File a spec bug getting clarification on what it means to create boxes and when a dialog should be recentered. @domenic, general complaint here is that dialog is weird/vague talking about when layout boxes are created. Does anything do that? Is the meaning of that written down? This is particularly pertinent to when you're adding content to a dialog and whether it should recenter.
- Fix the *horizontal* resize centering we're missing per falken's notes.
- Web platform tests so Firefox and Chrome can interoperate.

> File a spec bug getting clarification on what it means to create boxes and when a dialog should be recentered. @domenic, general complaint here is that dialog is weird/vague talking about when layout boxes are created. Does anything do that? Is the meaning of that written down? This is particularly pertinent to when you're adding content to a dialog and whether it should recenter.

My understanding is that this is a well-known primitive from CSS land. Adding tabatkins@ to confirm.

We're working on a related fix (logical centering instead of always rtl/horizontal) at https://github.com/whatwg/html/pull/2208 and it's coming with web platform tests: https://github.com/w3c/web-platform-tests/pull/4605. Gecko is interested in implementing that although falken@ stated it's not a high priority for Blink.

See also https://github.com/whatwg/html/issues/2185#issuecomment-267486210 which outlines the reasoning behind this setup in a bit of detail.

Bulk disowning per sshruthi's email about bug triage best practices.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot