Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
fantasai opened this issue Apr 23, 2020 · 7 comments
Open

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

fantasai opened this issue Apr 23, 2020 · 7 comments

Comments

@fantasai
Copy link
Collaborator

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
Copy link
Contributor

See also whatwg/fullscreen#165

@bramus
Copy link
Contributor

bramus commented May 13, 2022

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
Copy link
Contributor

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
Copy link
Contributor

bramus commented May 13, 2022

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

@SebastianZ
Copy link
Contributor

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
Copy link
Contributor

mfreed7 commented Jun 1, 2022

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.

josepharhar added a commit to josepharhar/html that referenced this issue Mar 30, 2023
The top layer has been added to the CSS spec, and this patch moves the
top layer references from the fullscreen spec to the CSS spec and uses
new algorithms to add and remove from the top layer defined in the CSS
spec.

Moving the top layer to the CSS spec has been discussed in these issues:
w3c/csswg-drafts#4998
w3c/csswg-drafts#6939
w3c/csswg-drafts#7845
w3c/csswg-drafts#8240
@tabatkins
Copy link
Member

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.)

annevk pushed a commit to whatwg/html that referenced this issue Jun 21, 2023
This change moves the top layer references from Fullscreen to CSS and uses the new algorithms to add and remove from the top layer.

Moving the top layer concept to CSS has been discussed in these issues:

* w3c/csswg-drafts#4998
* w3c/csswg-drafts#6939
* w3c/csswg-drafts#7845
* w3c/csswg-drafts#8240

Tests: web-platform-tests/wpt#39828.
rubberyuzu pushed a commit to rubberyuzu/html that referenced this issue Jul 20, 2023
This change moves the top layer references from Fullscreen to CSS and uses the new algorithms to add and remove from the top layer.

Moving the top layer concept to CSS has been discussed in these issues:

* w3c/csswg-drafts#4998
* w3c/csswg-drafts#6939
* w3c/csswg-drafts#7845
* w3c/csswg-drafts#8240

Tests: web-platform-tests/wpt#39828.
rubberyuzu pushed a commit to rubberyuzu/html that referenced this issue Jul 21, 2023
This change moves the top layer references from Fullscreen to CSS and uses the new algorithms to add and remove from the top layer.

Moving the top layer concept to CSS has been discussed in these issues:

* w3c/csswg-drafts#4998
* w3c/csswg-drafts#6939
* w3c/csswg-drafts#7845
* w3c/csswg-drafts#8240

Tests: web-platform-tests/wpt#39828.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants