The overlay CSS property

[josepharhar]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: The overlay CSS property
• Specification or proposal URL (if available): https://drafts.csswg.org/css-position-4/#overlay
• Explainer URL (if available): https://github.com/chrishtr/rendering/blob/master/entry-exit-animations.md
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

The CSS Spec is done. There are additional tie-ins to HTML and fullscreen:

• Remove top layer definitions, now that CSS Position 4 contains them. whatwg/fullscreen#223
• Use CSS spec for top layer whatwg/html#9093

Here is the CSSWG issue: w3c/csswg-drafts#8189

[zcorpan]

@dholbert @emilio

[SebastianZ]

The CSS Spec is done.

As Alan Stearns points out in w3c/csswg-drafts#8730, there's still an open discussion.

Sebastian

[itpropro]

w3c/csswg-drafts#8730 was resolved over a year ago, has the position changed or are there plans to work on https://bugzilla.mozilla.org/show_bug.cgi?id=1841456?

[birtles]

For what it's worth, I think it's weird that this can only be set by transitions and not animations. If we want to keep that behavior, I think we need to specify exactly how that works.

For example, if a CSSTransition object has no owning element, does the overlay property specified on any associated keyframe effect still have an effect?

The fact that only transitions can set it is only defined in non-normative text (although later normative text assumes it to be the case) and the decision to make ignoring transitions in some circumstances undefined is going to cause interop issues:

User agents may, at their discretion, remove a running transition on overlay. The conditions for this are intentionally undefined.

For example, does pausing such a transition cause it to be ignored? What about seeking it?

[itpropro]

For what it's worth, I think it's weird that this can only be set by transitions and not animations. If we want to keep that behavior, I think we need to specify exactly how that works.

For example, if a CSSTransition object has no owning element, does the overlay property specified on any associated keyframe effect still have an effect?

The fact that only transitions can set it is only defined in non-normative text (although later normative text assumes it to be the case) and the decision to make ignoring transitions in some circumstances undefined is going to cause interop issues:

User agents may, at their discretion, remove a running transition on overlay. The conditions for this are intentionally undefined.

For example, does pausing such a transition cause it to be ignored? What about seeking it?

I think as it is currently only used in a very specific context (Popover API, allow-discrete) and setting it by a transition property basically enables animating it, these use cases can be described quite clearly.
The user agent setting it is by the spec also reserved for the specific use case of preventing potential abuse scenarios. This would require a specific list of conditions to specify what would be considered as abuse.
I haven't looked at the implementation in Chromium, but I would assume this work has already been done in their implementation.

[birtles]

I don't doubt the utility of this-I use it myself. I'm just saying this needs spec work/discussion.

[emilio]

I think I agree with @birtles, this in general feels very narrowly scope.

However I think it is well defined how it works in terms of animations unless I'm missing something?

In particular, it's defined to be * { overlay: none !important } at the UA-stylesheet level, which overrides animations, right?

[birtles]

However I think it is well defined how it works in terms of animations unless I'm missing something?

In particular, it's defined to be * { overlay: none !important } at the UA-stylesheet level, which overrides animations, right?

Yeah, I think you're right (since animations without an owning element target the animations level of the cascade (ref)).

That said, I still think this should be available to regular animations too since my experience with modal dialogs has shown transitions are sometimes not sufficient for outro animations (e.g.).

I'm also a bit concerned the deliberately undefined heuristics for ignoring transitions are possibly going to cause interop headaches.

It's also not entirely trivial to come up with good heuristics. For example, pausing a transition could cause it to persist its effect forever which could be abused. Ignoring paused transitions, however, would make DevTools less useful since you wouldn't be able to inspect outro animations. Likewise for transitions whose playback rate is slowed down significantly, or transitions that are periodically seek-ed backwards such that they never end.

[tabatkins]

Right. Per the spec, nothing prevents you from applying an 'overlay' animation, it's just not going to do anything, due to the property always having a value set in the UA-important cascade origin. Due to the way transitions work, they'll activate and apply even between UA-important value changes, but animations apply between the author and author-important cascade origins, so they'll be ignored.

That said, I still think this should be available to regular animations too since my experience with modal dialogs has shown transitions are sometimes not sufficient for outro animations

Without some additional magic, it's not possible to allow something in animations but not in normal properties, so we'd need some extra hand-waving there. Even if we did that, tho, it would still allow authors to keep things in the top layer indefinitely. (The spec uses the 'overlay' value as part of its logic on when to remove something from the top layer.) We'd have to invoke the "kick it out anyway" heuristic more aggressively, whereas currently it's something that should only trigger when you're doing something weird.

I'm also a bit concerned the deliberately undefined heuristics for ignoring transitions are possibly going to cause interop headaches.

It's completely undefined at the moment to allow exploration; we'd be happy to add some actual rules based on implementation experience. The expectation, tho, is that it would only get applied to "weird" cases - a transition lasting many seconds, for example. If your "leaving the top layer" animation is >15s long, you're doing something incredibly weird.

It's also not entirely trivial to come up with good heuristics.

This is a big part of why we haven't specified them in detail yet. For example, I could imagine the heuristic allowing them to persist indefinitely if DevTools is open.

[birtles]

That said, I still think this should be available to regular animations too since my experience with modal dialogs has shown transitions are sometimes not sufficient for outro animations

Without some additional magic, it's not possible to allow something in animations but not in normal properties, so we'd need some extra hand-waving there. Even if we did that, tho, it would still allow authors to keep things in the top layer indefinitely. (The spec uses the 'overlay' value as part of its logic on when to remove something from the top layer.) We'd have to invoke the "kick it out anyway" heuristic more aggressively, whereas currently it's something that should only trigger when you're doing something weird.

Yeah, I can see that would be difficult. Maybe it's ok for overlay to only be animatable via transitions initially and we can explore ways to expand that later.

In my case, I was building a drawer component using a modal <dialog> and transitions were an awkward fit for the outro animation. (From memory, at least one issue was the duration of the outro animation varies based on the computed height of the drawer.) Instead, I ended up blocking close requests, running the outro animation using Web Animations, then closing the dialog when they complete—awkward and error prone but maybe good enough for now.

[tabatkins]

I'll say I definitely sympathize with the use-case; the fact that you have to coordinate an outro animation with the transition is definitely bad. It's just weighed against the confusion potential of 'overlay' not really doing anything for authors; if it was settable, all they could do would be (a) delay an element from leaving the top layer (by setting overlay:auto before it leaves), or (b) force an element in the top layer list to not render in the top layer (by setting overlay:none while it's in the top layer list). In all other situations it would do nothing regardless of value, and that's weird.

All around it's kinda a weird thing, unfortunately.