[css-position-4] Define "top layer" positioning scheme

[fantasai]

The Fullscreen API spec describes a rendering model which does not map directly to CSS. It's been suggested that we make add the necessary CSS primitives.
https://fullscreen.spec.whatwg.org/#rendering

[chrishtr]

See also whatwg/fullscreen#165

[bramus]

With fullscreen, dialog, (the experimental) page transitions, (the upcoming) <popup> all talking about top-layer, would it be a good time to bump this one up?

In addition to defining the top layer concept, I see related these discussions/requests:

1. Allow authors to select the top layer
2. Allow authors to define whether an element should go in a top layer or not

Also see part of the discussion in #6965 that talked about a :top-layer pseudo-class selector.

[chrishtr]

This issue is not tracking allowing authors to select the top layer with CSS (I don't think that's a good idea; see discussion in issue #6965). It's about moving the style sheet rules from the fullscreen spec, and the description of how the boxes for the top-layer content is reparented, over to a CSS spec.

[bramus]

Yes, was mentioning the other/related items in order to paint the bigger picture, independent of their outcome.

[SebastianZ]

Regarding the prior discussions, it sounds to me like there's actually a need for multiple (UA) top layers.

A definition for allowing elements to be placed in the top layer might have these requirements:

• Any element can be placed into the top layer.
• If there are multiple elements of different DOM subtrees to be placed in the top layer, the one later in the DOM tree wins.
• A descendant element of a top-layer element can be placed into its own top layer.

With this, the often mentioned use case of having a tooltip within a dialog within a fullscreen element could be covered. Each of them would be placed in its own top layer.

In case the rules above are unclear, here are some examples which hopefully make it easier to understand the concept:

Simple case:

<a>
  <top-layer/> <!-- Will be in the top layer (above <c/>) -->
  <b>
    <c/>
  </b>
</a>

Two elements in top layer:

<a>
  <top-layer/>
  <b>
    <c/>
  </b>
  <top-layer/> <!-- Will be in the top layer (above <c/> and <d/>) because it's later in the DOM tree than the other <top-layer/> -->
  <d/>
</a>

Nested elements in top layer:

<a>
  <top-layer> <!-- Will be put in the top layer (above <e/>) -->
    <b>
      <top-layer> <!-- Will be in the top layer above the outer <top-layer/> (and <c/>) -->
      <c/>
    </b>
  </top-layer>
  <d>
    <e/>
  </d>
</a>

Note: While this is meant to define UA-controlled top layers, it could easily be extended to include author-defined top layers. The only additional rule would be that UA top layers are always above authored ones in their relative context.

Sebastian

[mfreed7]

Regarding the prior discussions, it sounds to me like there's actually a need for multiple (UA) top layers.

I just wanted to call out the Popup API Proposal, which is being incubated in the OpenUI WG. We've been thinking about these issues and many more, and we're working on a proposal, and prototype in Chromium, to support these use cases. There has been significant discussion. There are many nuances involved in creating the types of UI that use a "top layer" concept, so we'd really love your feedback on the proposal. For example, a dedicated <popup> type element was ruled out due to significant accessibility issues. Additionally, a CSS-based solution was similarly ruled out due to significant limitations such as not allowing a tooltip on top of a dialog.

The hope is to bring the Popup API to a WHATWG PR fairly soon. There are some CSSWG pieces, such as the :top-layer pseudo class (or perhaps a different name, based on discussions).

I think this issue might need a bit of clarification. One interpretation is that it is about adding a CSS primitive to move elements into and out of the top layer. (Hopefully not.) The other interpretation is that the descriptions about how the top layer works should be augmented and moved into CSS specs.

[tabatkins]

This is now more or less done, in CSS Position 4.

I based the behavior on Rune's suggested outline. This differs slightly from the simpler model described in the Fullscreen spec. Notably:

• In Fullscreen, adding an element to top layer that's already there moves it to the back. In Position, it stays where it is, unless there's already a pending removal request (in which case we shift it to the back and delete the pending removal; essentially we eagerly process the removal).

  This change is a no-op in practice; every algo that puts things in the top layer first checks if the element is already in the top layer, and manually removes it if so.

• Fullscreen doesn't have pending removals - to remove something from the list, you just remove it. In Position, removing an element from the top layer goes thru a pending removal list, which is drained as part of Update The Rendering in HTML. This syncs the element's presence in the "top layer" with whether it's currently rendered in the top layer.

  This might be simplifiable, now that we rely on the 'overlay' property to determine whether it should be killed or not, but, @lilles can explain if it's not. (If we just relied on 'overlay' we'd lose the "if not rendered" bit from the cleanup; I dunno how significant this is.)