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-device-adapt] Terminology: define layout viewport and visual viewport #206

Open
frivoal opened this issue Jun 21, 2016 · 15 comments
Open

Comments

@frivoal
Copy link
Collaborator

frivoal commented Jun 21, 2016

All (probably all, I would need to check in detail), the references in the device adaptation spec to viewports are actually about the layout viewports, so the initial viewport is about the initial layout viewport, and the actual viewport is about the actual layout viewport. This should be made explicit, and the spec should define what the layout viewport and visual viewport are.

@bradkemper
Copy link
Contributor

I find the terms "actual viewport" and "initial viewport" confusing, and even a little misleading. To me, "actual viewport" sounds like the one that should match the dimensions of the actual glass of my phone, and the "initial viewport" is what is initially laid out prior to scaling it or cropping it to fit the phone.

Can we just replace those terms with layout viewport and visual viewport?

@frivoal
Copy link
Collaborator Author

frivoal commented Jun 28, 2016

I completely agree that the terminology is confusing, and lacks explanations. However, we cannot simply replace initial and actual with layout and visual, because that's not what they are.
The actual and initial viewport are different states of the layout viewport as you work out the caracteristics of the device and apply styles. Now, at different points, various viewports may have the same size as various others, so it is easy to confuse them (especially with poor / poorly explained terminology), but they are separate concepts.

I think that this lack of clarity is one of the major thing holding back this specification, and as an editor, I absolutely want to fix it, and have an idea on how to do that (a somewhat significant editorial rewrite), but I haven't been able to free up enough time to do it.

@bradkemper
Copy link
Contributor

Okay. I would still ask to try to find a better word than "actual". It isn't clear to me that it is any more actual or real than the other viewport concepts.

@frivoal
Copy link
Collaborator Author

frivoal commented Jun 30, 2016

Maybe "computed" or "used" would resonate better with the rest of CSS terminology. I'll think about it.

@bradkemper
Copy link
Contributor

Offhand, "used" sounds pretty good to me.

@jihyerish
Copy link
Contributor

How about the following definitions?

  • Initial layout viewport
    • The viewport which is given by the window or viewing area of UA
    • In general, the size of the viewport is the size of the window on the desktop browser, whereas that is as same as the physical pixels as depicted on the screen of the mobile device
  • Actual(Used / Computed) layout viewport
    • The viewport which is applied cascaded viewport descriptors
    • The size of the viewport is as same as that of the initial containing block
    • Pixel dimensions are specified in CSS pixels.
  • Visual viewport
    • The part of the page that is currently shown on the screen
    • Pixel dimensions are specified in hardware(device) pixels

@jihyerish
Copy link
Contributor

Maybe "computed" or "used" would resonate better with the rest of CSS terminology.

Both look fine to me. I think "computed" is better but I don't feel strongly.

@frivoal
Copy link
Collaborator Author

frivoal commented Sep 5, 2016

How about the following definitions?

Yes, that seems right (maybe except the part about the visual viewport being in hardware pixels, although that may depend exactly on what is meant by that).

Aside from editorial work to introduce the concepts, explain their relationship and significance, and make sure they are understandable from an author/user point of view (not from a browser internals point of view), I expect that what will go into the spec will be similar to what you said, with more details and making sure all the terminology is right.

@RByers
Copy link
Contributor

RByers commented Sep 20, 2016

Here's a tiny presentation that summarizes how we (blink) look at this. This is related to our Viewport API proposal, which should perhaps refer to terms defined in css-device-adapt.

@RByers
Copy link
Contributor

RByers commented Apr 19, 2017

See here where, given the implementation trend and existing specs, I suggest renaming "layout viewport" to simply "viewport". We should still define "viewport" and "visual viewport" as separate concepts here, but "visual viewport" should almost never need to be mentioned by other specs.

@bokand
Copy link
Contributor

bokand commented Apr 19, 2017

I agree with Rick that "viewport" should default to what we colloquially call "layout viewport". "Layout viewport" is somewhat of a misnomer (in Chrome at least) as the ICB and "layout viewport" may differ in size under some scenarios. e.g. if the page has an element wider than the ICB, the layout viewport is expanded so that it covers the entire content width (to a limit). We do this since the layout viewport must always fully contain the visual viewport and we want to allow users to zoom out to fit the content width. It'd be more accurate to call it the "position: fixed viewport" or "minimally zoomed viewport".

I haven't seen how Safari iOS handles these cases yet, I'm looking into that now. IIRC Edge worked differently from Chrome here, I think their "layout viewport" really is the same size as the ICB regardless of the minimum-zoom/content width. In any case, I don't think we should enshrine "layout viewport" since it implies that it influences layout which reverses the relationship. IMHO, the fact that it often matches the size of the ICB is incidental to its purpose.

@bokand
Copy link
Contributor

bokand commented Apr 19, 2017

BTW, the sizing of the layout viewport and its relationship to minimum scale is an interop issue that we should also look into fixing and specifying.

birtles added a commit to birtles/csswg-drafts that referenced this issue Dec 4, 2017
Drop "pending" state and add separate `pending` member to Animation
@a2sheppy
Copy link

a2sheppy commented Jan 14, 2020

I think I disagree that we can settle for allowing the single word "viewport" to default to meaning "layout viewport." The tendency people have to drop the adjective when using terms repeatedly will eventually lead to confusion. I think, instead, a different term should be found for "visual viewport." I honestly like something like "zoomport." Nice, short, one word term that's easily differentiated from "viewport," but is similar enough to be clear it's related.

My concern is the ease with which dropping the specificity can introduce confusion is pretty substantial. People are very prone to dropping adjectives like "visual" without even realizing they're doing so. By using the single word "viewport" as shorthand for a longer term like "layout viewport", we invite confusion when people inevitably shorten "visual viewport" to simply "viewport", whether by mistake or simply because they're tired of saying or writing "visual viewport" every time they refer to it.

@hiikezoe
Copy link

Using a totally different word sounds reasonable to me. That's said, all major browsers have already shipped the visualViewport API, so it's hard to rename it? Then can we rename "layout viewport" to something different words? "layout port", "layout size", etc. etc? Though I am not sure we've already exposed "viewport" in web exposed APIs or not. (To me, "view" looks a confusing word in these days)

@smfr
Copy link
Contributor

smfr commented Jan 15, 2020

I agree that we could rename "layout viewport" to something else; it's not a "viewport" in the sense that you can't see it. It's more akin to a kind of "containing block".

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

10 participants