Window Controls Overlay resize events

[michaelwasserman]

The Window Controls Overlay explainer mentions firing the resize event when the origin or a page action (extension/translate/etc. buttons) shows or hides in the overlay.

I hope the explainer/spec might explore some considerations here:

1. Is there any precedent for resize events firing with changes that don't affect the overall rectangular content area bounds? Would it make sense to use a separate event for overlay bounds changes?
2. Would the event be fired for each step of hide/show animations, or just once as each element's target visibility changes? (firing with animation steps might be a performance concern, and aligning client/non-client bounds changes is tricky)

[amandabaker]

1. Is there any precedent for resize events firing with changes that don't affect the overall rectangular content area bounds? Would it make sense to use a separate event for overlay bounds changes?

I don't believe there is a precedent for resize events being called when the rectangular client are bounds are not changed, but this is also not a pattern I've seen before at all. Most overlays or dialogs that occlude the client area are transient (fullscreen controls, Ctrl+F popup dialog, etc.), and there is no intention of having a web developer try to lay out content around an overlay.

In contrast, the window controls overlay is a "permanent" piece of the browser chrome that is occluding the client area, so when the size of the overlay changes, the effective client area changes as well, even though the rectangular client area bounds are not affected.

We had previously considered introducing a new event to signal the resize (discussion here: #184) , but ultimately decided to stick with reusing resize. That said, I'm not entirely opposed to introducing a new event because technically, this isn't a resize per the spec.

2. Would the event be fired for each step of hide/show animations, or just once as each element's target visibility changes? (firing with animation steps might be a performance concern, and aligning client/non-client bounds changes is tricky)

I think it makes more sense to only fire when complete.

There are two layout options:

1. CSS environment variables: if a dev uses the env() variables to layout the web content's fake "title bar" area, then it doesn't matter how often resize is fired.
2. JavaScript and resize:
   1. Fire resize once: allows a developer to build their own smooth animations. For example, when the origin text fades out, the overlay resizes. The dev can compare the difference between the size of the overlay before and after, then do a custom animation to resize their content smoothly.
   2. Fire resize on each step: I don't see this working out well. When testing resizing a window then laying out content using JS, this is pretty jumpy (which is how we ended up with the CSS env's)

[michaelwasserman]

Thanks for the thoughtful reply.

I worried that existing resize handlers would now have to distinguish between client bounds and overlay bounds changes, but that's only true for sites opting into this feature, and perhaps it's doubtful that such sites would blindly trigger a complex manual layout on each resize event, wrongly assuming that resize always pertains to client bounds.

I guess my question about the frequency of resize events is equally applicable to the frequency of changes to the CSS environment variables. I suspect that both firing 'resize' and changing CSS values when the overlay completes its transition is reasonable. It would be nice as a user to see site content animate in tandem with overlay text and buttons sliding in/out, but a separate animation like you describe would probably be sufficient.

It might be nice to document the intended timing of JS events and CSS value changes in the explainer.