fullscreen

fullscreen copied to clipboard

The current spec explicitly states that elements in the top layer may have position: absolute and in which case, it's containing block would be the initial containing block.

If I understand correctly, the difference for the containing block to be the viewport and the initial containing block is whether the position is affected by the scroll offset. However, does it make sense to allow scroll offset to affect the position of a top layer element? I don't think so.

The top layer elements should be rendered on top of the page scrollbars, otherwise it would be really unfortunate for fullscreen.

If we position something in the top layer based on the scroll offset, and it is shown during fullscreen, it could easily be positioned in a place where user can never see, because user is not able to operate the scrollbar of the page in fullscreen in general.

Thus I propose that we always use the viewport as the containing block of the elements in the top layer, and do not touch the position property at all.

I'm not sure that works for <dialog>. The reason we have this setup is because of that element.

Yeah, I see that's for <dialog>. But I don't understand why <dialog> needs that setup.

As I mentioned above, top layer should be rendered on top of the scrollbar, which means the ::backdrop of <dialog> should effectively block user from reaching the scrollbar. Given that, how does it make sense to have absolute position?

What does it mean to render something on top of the scrollbar, and what happens if the viewport is too small to fit the <dialog> or fullscreened element?

I'm confused about the interaction between the scrollbar of the page and the top layer.

So if there is a page with scrollbars, how should top layer elements be rendered? A or B?

A seems to be unfortunate for fullscreen, while B implies that position: absolute is useless for top layer elements. Alternatively, we can probably say, we render like A but hide the scrollbar in fullscreen?

what happens if the viewport is too small to fit the

or fullscreened element?

You cannot do anything for fullscreened element, because they are fixed anyway.

Hmm, OK. Indeed it seems weird to render scrollbars if you cannot actually scroll. Have you tested which browsers currently do this?

Blink do A for <dialog>. For fullscreen, I believe all browsers currently still use :root:fullscreen-ancestor { overflow: hidden; }, which is the third way I mentioned.

However, we have removed :fullscreen-ancestor long ago. In addition, as we've also removed the hierarchy restriction, it now becomes hard to maintain that pseudo-class efficiently.

(Also, changing overflow property is expensive in Gecko, hence I want to get rid of it anyway)

It does seem like something that overrides overflow is what's needed here, no?

If we can do B directly, we don't need to override overflow. If we decide that we do want A, then we do need to find a way to suppress the scrollbars for fullscreen.

I'm pretty sure we want A for <dialog>. I'm starting to think that even for fullscreen content you might want to be able to scroll, with the option to override that from CSS if the developer feels confident it won't be needed...

I'm starting to think that even for fullscreen content you might want to be able to scroll, with the option to override that from CSS if the developer feels confident it won't be needed...

Authors can always specify overflow: scroll on the fullscreen element, so that's not an issue.

This is a problem in https://bugs.chromium.org/p/chromium/issues/detail?id=543946

Before trying to figure out how to make <dialog> and Fullscreen work together, do we all agree that for Fullscreen it would make the most sense if scrollbars of any ancestors are not visible? If they are, then what effect should using them actually have?

In fullscreen, all ancestors up to the root of the document should already have been hidden behind ::backdrop by default, so it doesn't make sense to hide their scrollbars.

The only question is the viewport, which is still a geometry parent of top layer elements.

Let me check how did I resolve this... I definitely met this issue before, otherwise I wouldn't file this issue :)

So what I did is, explicitly overriding the viewport's scrollbar style (without touching anything else) when the fullscreen element is neither null nor the root. (Code and comment can be found here)

So overflow of <body> would be propagated to viewport as normal if <html> has its default value of overflow, but if we are in fullscreen, even if the overflow is scroll, the viewport would behave as if it is hidden. I'd propose we add this behavior to the spec.

The wording could probably be: when the fullscreen element is neither null nor the root element, the computed value of viewport's overflow property is ignored, and hidden is used instead.

The root element is explicitly excluded so that people can request fullscreen on the root and have the whole document be viewed in fullscreen as if in normal window.

The wording could probably be: when the fullscreen element is neither null nor the root element, the computed value of viewport's overflow property is ignored, and hidden is used instead.

Is the viewport something that has style at all, or could this be the root element? If it's the root element, should this override show up in the computed style?

Based on CSS spec, the viewport does have some kind of style, and viewport is not the root element in the DOM tree.

You can find the following paragraph in the spec:

UAs must apply the 'overflow' property set on the root element to the viewport. When ..., user agents must instead apply the 'overflow' property from the first such child element to the viewport, if the value on the root element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'.

And I don't think overflow on the viewport can be accessed via any API (nor any other CSS properties in general).

Is the viewport something that has style at all, or could this be the root element? If it's the root element, should this override show up in the computed style?

Also, "used value" in general doesn't show up in the computed style.