Skip to content

[css-om-view] Describe layout and visual viewports #4724

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

Open
smfr opened this issue Feb 1, 2020 · 1 comment
Open

[css-om-view] Describe layout and visual viewports #4724

smfr opened this issue Feb 1, 2020 · 1 comment

Comments

@smfr
Copy link
Contributor

smfr commented Feb 1, 2020

https://www.w3.org/TR/cssom-view-1/

Browsers have converged on a common model for laying out position:fixed and position:sticky elements in the face of pinch zooming. CSS OM View should specify the underlying model, and provide some terms that other specs can reference ("layout viewport", "visual viewport").

https://wicg.github.io/visual-viewport/ will need to reference these.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-om-view] Describe layout and visual viewports, and agreed to the following:

  • RESOLVED: Start defining what we call layout and visual viewport
The full IRC log of that discussion <dael> Topic: [css-om-view] Describe layout and visual viewports
<dael> github: https://github.com//issues/4724
<dael> smfr: Rossen_ and I talked offline. I think browser have converserge on mech for fixed post in fac eof page zoom. 2 rectangles layout and visual viewport. Not defined anywhere. WOuld be willing to write text to live in CSSOM View. Asking res to add a section to the spec for the layout and visual viewport. I expect bikeshedding
<dael> Rossen_: I support adding the text. Question- besides describing what it is and does what else is there to be done?
<dael> Rossen_: Don't anticiplate providing units or capabilities that are accessible to css?
<dael> smfr: Right. Think should desc how they interact. When you zoom and scroll some fixedpos will disappear is unexpected for some authors. Spec should explain
<florian> q+
<dael> Rossen_: 100% with you. Wanted to make sure only thing we're doing is adding explination. Not adding capabilities for authors to target
<dael> smfr: Correct
<dael> smfr: There is a viewport API spec which will reference this.
<dael> Rossen_: Link?
<dael> astearns: In issue
<astearns> ack florian
<heycam> +1 on moving towards being able to write down what <meta viewport> does
<dael> florian: I'm supportive of this. For a long time this was intended to be done once anyone had time. All sorts of reference in css to "the viewport" but we have multiple. Eventually we'll need to spec the viewport metatag and a css way to adjust so I suggest write definitions so viewport can be touched eventually
<dael> smfr: Additional wrinkle is we have not spec how scroll position is derived. I think some movement to being around layout viewport, but we should spec that as well
<dael> florian: Need to define the viewports then audit the specs to what they're referring to. This is one of those but I'm sure many more
<dael> Rossen_: Good to remember what constitutes an initial containing block in prsense of these viewports
<dael> Rossen_: For abspos the containing block is layout viewport but for fixed it's visual viewport. That's observable for user
<dael> smfr: Yes. Not sure those viewports are right but yes
<dael> florian: Maybe do this as a series of PRs defining the viewports. Then finding instances of specs where they're referred will take longer. Shouldn't be a single pull request.
<dael> smfr: Correct
<dael> astearns: Prop: Start defining what we call layout and visual viewport
<dael> astearns: I'm hearing consensus. Any concerns or objections?
<dael> florian: Proccedural. If defined in OM View it forces us to have it as a spec that goes to REC. If it's moving makes dependency chain awk.
<dael> astearns: True whereveer they are
<dael> florian: True. We can start there and move if we're blocked
<dael> astearns: Or a L1 with just these. Do you have asuggestion of where else?
<dael> florian: A viewport. Device adaptation originally but it's becoming fiction
<dael> fantasai: We could drop the fiction and focus what's in there. I don't think there's a reason to keep stuff not being impl
<dael> smfr: I would prefer not device adaptation b/c these concepts feel more fund. to basic css. Coordinate systems not just about device adaptation they're fairly fundemental
<dael> astearns: We can hash this out at a later time. Let's get it done and then haggle.
<dael> astearns: Obj?
<fantasai> I'd probably keep coordinate systems in either cssom-view or css-overflow
<dael> RESOLVED: Start defining what we call layout and visual viewport
<fantasai> but layout viewport vs visual viewport is more fundamental than OM
<dael> astearns: Past that we discussed other things we might need to define. Good to have a note saying these things aren't yet defined but likely to come out of this work? So we've got a record of thigns we might get to?
<fantasai> so I think device-adaptation is a better place, if we make it to be more fundamental
<dael> smfr: Sure, happy to add.

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

2 participants