bokand/bokand.github.io

bokand.github.io's Issues

Firefox >= 67 implements "minimum scale size" fixed viewport sizing

Firefox, as of version 67, now implements Chromium's "minimum scale size" model for sizing the fixed viewport. That is to say:

• It computes a "minimum scale" as the largest of the "intrinsic minimum" (the scale where the page content fits the screen *), any minimum-scale from the meta viewport tag, and 0.25.
• It computes a "minimum scale size" as the size of the visual viewport when zoomed out to the minimum scale, and sizes the "fixed viewport" to that.
• The "fixed viewport" thusly sized determines the attachment of position: fixed elements, the extents to which you can scroll if the page is overflow: hidden, and the scroll port that governs window.scrollX/Y movements.

These changes have been landing incrementally since Firefox 65, but it should all be in place as of Firefox 67 (which is in beta as of the time of this writing).

(*) There is a remaining known inconsistency with Chromium regarding the "intrinsic minimum" scale: Firefox computes it as the larger of the scale where the content height fits the visual viewport height, and the scale where the content width fits the visual viewport width. Chromium seems to consider the width only. This is tracked in bug 1508177 and we plan to align with the Chromium behaviour here too.

Thoughts on fixed viewport sizing

Quoting from the "Fixed viewport size" section of the Web Viewports Explainer:

[In Chrome, t]he fixed viewport is sized to the minimum scale size.
...
Since Chrome's the only one that's not sizing the fixed viewport to the ICB, perhaps we should change to that.

I'm trying to understand how that would work more precisely.

It seems to me like there are two sizes we can choosen from:

1. The size specified by the meta viewport tag.
2. Something derived from the content size, like the "minimum scale size".

IIUC, Chrome currently sizes the ICB to (1), and the fixed viewport to (2).

If we want the fixed viewport and the ICB are to have the same size, then it seems the options are:

• Size both to (1)

  This doesn't seem to be web compatible. On many sites, (1) is narrower (because they have a meta viewport tag with width=device-width), (2) is wider (because the content size is wider, and they don't have a minimum scale, or have a sufficiently small minimum scale), and they use overflow-x: hidden on the root element (see e.g. most of the sites in the webcompat issues linked to bug 1123938). Such sites currently:

  • Work fine in Chrome, because Chrome sizes the fixed viewport to (2).
  • Work fine in Safari, because even though Safari sizes the fixed viewport to (1), they seem to ignore overflow: hidden on the root element. (According to this comment they "used to" ignore overflow: hidden, but as far as I can tell they still do. I'm basing this on the fact that on this test page, which has a content size larger than the minimum scale size, Safari allows scrolling in the entire content area.)
  • Are broken in Firefox (in that the content that overflows (1) is "out of reach"), because Firefox sizes the fixed viewport to (1), and doesn't ignore overflow: hidden on the root element.

  .
  So, if Chrome plans to go with this option, it would either break such sites, or have to start ignoring overflow: hidden like Safari does to avoid breaking such sites.

• Size both to (2)

  This doesn't seem to work, because (2) is a function of the content size, which can depend on the ICB size (e.g. consider a document element with width: 50%), so trying to size the ICB to (2) would introduce a layout cycle.

David, could you clarify which of these options you had in mind, or perhaps something else I'm not thinking of?

Clarification on Safari's behaviour for fixed position elements

The page https://theres-waldo.github.io/mozilla-testcases/bug1473699.html was tested in Safari on an iPhone simulator and the behaviour observed was that the fixed position elements were being attached to the visual viewport when we zoom out to the minimum scale. However, the explainer document states that the behaviour of fixed position elements on Safari is such that the fixed position elements are attached to the layout viewport when we zoom out to minimum-scale. Do you know if Safari has perhaps had a recent change in behaviour that hasn't been reflected in the explainer document yet?

Additional viewport-related improvements in Firefox

In recent Firefox releases we have implemented additional improvements to viewport-related behaviour:

• In Firefox 68, we shipped the Visual Viewport API (on Android).
• In Firefox 72, we fixed a remaining viewport sizing inconsistency related to the handling of the "intrinsic minimum" (described at the bottom of this post).
• In Firefox 73 (currently in beta), we have changed innerWidth/innerHeight to reflect the dimensions of the fixed viewport.

With these changes, I believe we are now in alignment with Chrome on all viewport-related behaviours described in this explainer doc. Please let me know if I overlooked anything!

Firefox >= 63 attaches fixed elements to the larger of the ICB or the visual viewport

In Firefox 63, the handling of position:fixed elements was changed so that they're attached to the larger of the ICB or the visual viewport.

This matches the behaviour of Safari, and on most pages (namely, ones where the min-scale size = the ICB size) Chrome.

Filing this issue to track updating the document to reflect this.

Definition of "minimum scale size"

The explainer defines "minimum scale", but not "minimum scale size".

Based on my reading, the definition ought to be "the size of the visual viewport when zoomed out to the minimum scale". Is that accurate?

Should scrollIntoView() scroll an element into the visual viewport?

If you load https://bokand.github.io/viewporttest.html in Chromium, zoom in such that the target element is out of view, and click the target.scrollIntoView button, the element does not get scrolled into the visual viewport.

Should it?

What should `document.scrollingElement.clientWidth` return?

On a page where the fixed viewport is larger than the ICB, what should document.scrollingElement.clientWidth return?

My experimentation seems to show that in Chrome it currently returns the ICB width.

• Is this observation correct?

• If so, is this the desired behaviour?

The spec says it should return "the viewport width excluding the size of a rendered scroll bar (if any)". Obviously, "viewport" in existing specs is ambiguous, but seeing as it's talking about scroll bars, I would think that, considering the implementation model described here, we'd want to use the scroll port width of one of the two scrollers, and the ICB width is neither.

I did look at this spreadsheet (linked from this section of the explainer doc) which lists the various APIs, but it's not clear to me whether it's up to date, as it talks about the "layout viewport" and not the "fixed viewport".

The explainer doc itself says that Chrome has moved to an "all fixed" model, which makes the current behaviour seem suprising.

Layout viewport scrollbars

Apologies if it's not appropriate to raise issues for something like this. But I've been looking at the different viewports and behaviours on browsers and I've noticed for the layout viewport there are potentially a couple of slightly different definitions:

• Including scrollbars: MDN for example explains the layout viewport as follows: "The area within the innerHeight and innerWidth is generally considered the layout viewport. The browser chrome is not considered part of the viewport."
  https://developer.mozilla.org/en-US/docs/Web/CSS/Viewport_concepts . Now these properties include scrollbars.
• Not including scrollbars: as described by yourself and others, referring to it as the area a fixed element is positioned with top, bottom, left, right of 0. This personally makes more sense to me as this is actually the space elements are laid out relative to.

Not sure if mentioning this distinction anywhere is worth it, and I could be missing something, but it does seem to be a little bit of a dual definition.

Cheers

A second role for the fixed viewport?

According to the explainer, the defining role of the fixed viewport is that it is the rect that position:fixed elements attach to and get their size from.

However, it would appear that, at least in Chromium, it serves a second role as well: it defines the bounds past which you cannot scroll if the html or body element is overflow: hidden. (I'm not sure what the appropriate name / a good name for this quantity is. In Firefox codebase terminology it would be the "scroll port" of the root scrollable element.)

A few questions:

• Is the above characterization accurate?
• Are these two roles of the fixed viewport fundamentally linked?
• Given this additional role, is the name "fixed viewport" still preferable over "layout viewport" for this quantity?