[css-round-display][mediaquery] Properly define 'viewport-fit'

[jihyerish]

CC @frivoal

I modified the draft about 'viewport-fit' to apply the resolution we made at the SF f2f.

• https://drafts.csswg.org/css-round-display/#viewport-fit-descriptor
  (Check the resolution in here)

I have some unclear things related to it:

• When viewport-fit: auto, is it right that the initial viewport will not change?
• The result of the examples below have the same meanings?
  • @viewport (viewport-fit: cover) { ... }
  • @viewport (width: auto) { ... }

[frivoal]

Thanks for this edit. To bring it fully in line with the resolution, I think you should make the following changes:

1. in the cover and contain definitions, change “The initial viewport is the [...]” to “The initial layout viewport and the visual viewport are set to the [...]”. ([css-device-adapt] Terminology: define layout viewport and visual viewport #206 is about properly defining that terminology)
2. I would move the following sentence into a note: “With this value, 'border-boundary: display' and 'shape-inside: display' have no effect”. You are not trying to define new behavior here, just to explain how these two things interact. This is better done as an informative note than as normative text.
3. I would rephrase this sentence: “UA can paint the area which is outside the contained viewport for ‘contain’. ” → “What the UA paints outside of the viewport is undefined. It may be the background color of the canvas, or anything else that the UA deems appropriate.”
4. I don't think your definition of auto really matches the resolution. How about this instead:

How the shape and size of the screen affects the initial layout viewport and the visual viewport is UA-defined, with the constraint that the UA must ensure that all the content can be viewed by the user, including documents designed for rectangular displays and that may have content in the corners. Making ''auto'' behave the same same as ''contain'' is one possible way to meet this requirement, but other approaches involving scrolling, panning, zooming or other mechanisms are encouraged as well.

1. “Because of this, some part of the page is clipped.” –> “Because of this, depending on the size of the viewport, some part of the page may be clipped.”

[frivoal]

Also, the syntax in your examples is incorrect.

@viewport (viewport-fit: cover) { /* styles for the round screen */ }
should be

@viewport {
  viewport-fit: cover;
}
@media (shape: round) {
  /* styles for the round screen */
}
@media (shape: rect) {
  /* styles for the rectangular screen */
}

[frivoal]

To answer your questions,

When viewport-fit: auto, is it right that the initial viewport will not change?

Not really. See the definition I propose above.

The result of the examples below have the same meanings?
    @viewport (viewport-fit: cover) { ... }
    @viewport (width: auto) { ... }

@viewport {width: auto; } is the default value if there's nothing else in the UA stylesheet. It does not cancel viewport-fit. Here's how they work together:

Let's say with have a round screen with a diameter of 200px. The size of the inscribed rectangle is diameter / sqrt(2) = 141 px.

• Example 1: @viewport { width: auto; viewport-fit: cover; }
  The width and height of the layout viewport and visual viewport are 200px, so the initial zoom level is 1.
• Example 2: @viewport { width: auto; viewport-fit: contain; }
  The width and height of the layout viewport and visual viewport are 141px, so the initial zoom level is 1.
• Example 3: @viewport { min-width: 400px; viewport-fit: cover; }
  The width and height of the layout viewport are 400px, and the width and height of the visual viewport are 200px, so the initial zoom level is 0.5.
• Example 4: @viewport { min-width: 400px; viewport-fit: contain; }
  The width and height of the layout viewport are 400px, and the width and height of the visual viewport are 141px, so the initial zoom level is 0.3525.

You would use example 1 if you have content that takes into account rounded corners and has a layout that deals with very small sizes well.

You would use example 2 if you have content that does not take into account rounded corners but has a layout that deals with very small sizes well.

You would use example 3 if you have content that takes into account rounded corners but has a layout that does not deal well with small sizes of less than 400px.

You would use example 4 if you have content that does not take into account rounded corners and has a layout that does not deal well with small sizes of less than 400px.

The UA stylesheet of mobile browser typically contains @viewport {min-width: 980px;} (or behaves as if they did), so authors need to use @viewport {width: auto; } to override that when they have designed for small screens. UAs for watches should do the same, as specified at https://drafts.csswg.org/css-device-adapt/#small-screen-ua

[bradkemper]

the UA must ensure that all the content can be viewed by the user

That wording doesn't cut it, though I know what you mean. Current UAs don't do that. Content that is absolutely positioned far to the left or top, or with a huge negative indent or negative margin, or with a negative z-axis to put it under the canvas, or even with 'visibility: hidden' or 'display:none' can often not be viewed by the user (unless you count the inclusion of developer tools to change the CSS)..

[frivoal]

@bradkemper Good point: do you have a better wording? Something like "the UA must ensure that the entire layout viewport and any content overflowing it on the block-end and inline-end sides can be viewed [...]". That's not a terribly nice phrasing, but it is probably more correct. Do you have a better suggestion?

[bradkemper]

@bradkemper Good point: do you have a better wording? Something like "the UA must ensure that the entire layout viewport and any content overflowing it on the block-end and inline-end sides can be viewed [...]". That's not a terribly nice phrasing, but it is probably more correct. Do you have a better suggestion?

I wish I did. It's tricky. There is also the body { overflow: hidden; } situation that should not be disallowed.

[bradkemper]

Maybe something like this:

How the shape and size of the screen affects the initial layout viewport and the visual viewport is UA-defined, with the constraint that the UA must ensure that all the significant content that would be visible/reachable on a rectangular display can be viewed/reached by the user on the round display, including documents that may have content in the corners. The UA may use its own heuristics to determine what is significant, but generally decorations such as backgrounds, borders, box shadows, etc. may be considered insignificant. Making ''auto'' behave the same same as ''contain'' is one possible way to meet this requirement, but other approaches involving scrolling, panning, zooming or other mechanisms are encouraged as well.

[frivoal]

Defining this in terms of "what would be reachable / visible on a rectangular display" is probably the right way to deal with it: this is actually the intent, so why not spell it out, and it is a verifiable non-fuzzy claim (regardless of whether an automated testing setup is easy to put together).

I am less sure about restricting it to “significant” content. While I agree that insignificant things, by definition, aren't important, agreeing on what's significant is trickier, and I think the fuzziness that this introduces in the definition will cause more problems than it solves.

[bradkemper]

It seems like we need to allow some latitude for the UA to determine significance, or else we should define it. We shouldn't consider a UA as no conforming if it had 2mm corner rounding covering up some white background, for instance. The line between how much it can obscure or not should be defined either fuzzily or clearly.

[jihyerish]

@frivoal

Example 1: @Viewport { width: auto; viewport-fit: cover; }
The width and height of the layout viewport and visual viewport are 200px, so the initial zoom level is 1.
Example 2: @Viewport { width: auto; viewport-fit: contain; }
The width and height of the layout viewport and visual viewport are 141px, so the initial zoom level is 1.
Example 3: @Viewport { min-width: 400px; viewport-fit: cover; }
The width and height of the layout viewport are 400px, and the width and height of the visual viewport are 200px, so the initial zoom level is 0.5.
Example 4: @Viewport { min-width: 400px; viewport-fit: contain; }
The width and height of the layout viewport are 400px, and the width and height of the visual viewport are 141px, so the initial zoom level is 0.3525.

Those are really nice examples to understand how width and viewport-fit work.
In the example, more precisely, does 'layout viewport' mean 'actual layout viewport'?

Also, I think it's better to change the definition of 'viewport-fit' from "set the size of the initial viewport" to "set the size of the visual viewport" if 'visual viewport' is defined in Device Adaptation Spec.
(I suggested the definition of that terminology in #206.)

[frivoal]

Hi @jihyerish, sorry for the very late answer.

Those are really nice examples to understand how width and viewport-fit work.
In the example, more precisely, does 'layout viewport' mean 'actual layout viewport'?

Yes

I think it's better to change the definition of 'viewport-fit' from "set the size of the initial viewport" to "set the size of the visual viewport" if 'visual viewport' is defined in Device Adaptation Spec.

I don't think so. If you set the initial viewport, it will also indirectly set the visual viewport, but it will do more than that. Unless there is some other @viewport rule doing something to the width or height of the viewport, it will also set the layout viewport to that size.

I realize that this would be a lot clearer if all these terms were properly defined, and that it is on me to go do that. I hope to be able to have time to do that soon, but so far I have not been able to prioritize it. Really sorry about that.