W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes Telecon 2020-02-05 [css-om-view] [css-sizing] [snapshot-2020]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 5 Feb 2020 21:14:54 -0500
Message-ID: <CADhPm3t_U-D74sSEXCpK4zjeXF-rdngHXvpoQKDaAn8KatkZig@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSSOM View
----------

  - RESOLVED: Have smfr put in a blanket MAY saying in some situations
              browsers can have these functions do nothing (Issue
              #4728: Window move and resize functions should be
              allowed to do nothing)
  - RESOLVED: Start defining what we call layout and visual viewport
              (Issue #4724: Describe layout and visual viewports)

CSS Sizing
----------

  - Those on the call agreed that the intrinsic-size values should be
      ordered like physical properties (width then height), however
      those arguing for logical ordering weren't represented on the
      call so the group will wait until next week before resolving.

Snapshot 2020
-------------

  - The group has set a goal of having the 2020 snapshot ready for
      publication at the next F2F. What should be included is
      currently being tracked in Issue #4715 (Let's make snapshot 2020
      while the year is still young).
  - A separate GitHub issue will be opened to contain the conversation
      about how to message in one document what is in CSS.


Proposing new CSS primitives to enable great web experiences on
    foldable & dual-screen devices
---------------------------------------------------------------

  - dlibby introduced the proposal to create a new media feature
      called 'spanning' which would indicate when a viewport spans
      multiple screens such as on a hinged device as well as 4 new
      environment variables to interact with the hinge's location.
      (Issue #4736)
  - The group was receptive to this work and interested in seeing the
      proposal fleshed out further. The media feature not being
      specific to hinged devices is important so that it can extend
      into the future as technology advances and can also be extended
      into multiple monitor set ups used now.
  - The proposal has good examples in it, but could use a call out to
      exactly the elements that would be spanning the hinge so that
      it's clear why the new properties are needed.
  - More examples around how the env variables interact different
      layout mechanisms would also be helpful.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Feb/0000.html

Present:
  Rossen Atanassov
  David Baron
  Christian Biesinger
  Zouhir Chahoud
  Elika Etemad
  Simon Fraser
  Brian Kardell
  Dael Jackson
  Sanket Joshi
  Daniel Libby
  Chris Lilley
  Peter Linss
  Cameron McCormack
  Florian Rivoal
  Jen Simmons
  Lea Verou

Regrets:
  Rachel Andrew
  Tab Atkins
  Mike Bremford
  Oriol Brufau
  Stanton Marcum
  Manuel Rego Casasnovas
  Christopher Schmitt

Scribe: dael

CSSOM View
==========

Window move and resize functions should be allowed to do nothing
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4728

  smfr: CSSOM view defines moving and resizing windows, including
        browser windows
  smfr: Text restricts to only do things in certain cases which
        basically means pop up from window.open
  smfr: Following spec suggests window can't self resize which might
        be a mistake
  smfr: Main desire for the issue is to state browsers often prevent
        content from moving in other conditions then those in spec.
        For example may be a tab. Would like to add text to say any
        move and resize functions may do nothing
  <bkardell> sgtm
  astearns: One sgtm in IRC. Other comments or concerns?

  heycam: To confirm restrictions on which kinds of windows is
          specified in spec?
  smfr: Says window A can move or resize window B if window A is
        familiar with window B and if it's auxiliary browsing context.
        No additional optout for the UA to decide this is bad
  Rossen: window.open has capability to provide desired size and
          location?
  smfr: Yes, takes features including height and width it'll be
        opened. I don't suggest changes to that

  florian: Are there uses that are not abuse? If they do good to
           ensure browsers do it when used legit.
  smfr: There is legit use. Used to be able to click a button and open
        tiled windows. Internet apps that might still be common. With
        many browsers having tabs it doesn't make sense for page to
        resize window. I see this as cutting off annoying things. Not
        as many legit uses, but not forward looking
  bkardell: Even legit don't answer how to do on mobile
  smfr: Yeah, on mobile makes no sense.
  smfr: And browser can't distinguish legit from abuse.
  florian: Generally I'm fine allowing browser to curtail. If there
           are valid reasons to keep want to make sure not breaking
           them

  smfr: Would like to hear Chrome and FF behavior. Safari considers it
        a pop-up if it's opened with a width. That's part of loose
        nature of browser wanting to cut off abuse
  astearns: Assuming other impl don't have details at hand. Anyone
            want to go code spelunking?
  heycam: I can report back in issue if that's helpful
  smfr: I don't want to spec when it's allowed, I just want an opt out
        in spec text
  astearns: May opt out. And if possible to get more details in if
            browsers agree that's fine in the future. Blanket may for
            now
  smfr: Yeah
  heycam: Fine with a blanket may for now.
  astearns: Prop: Have smfr put in a blanket MAY saying in some
            situations browsers can have these functions do nothing

  RESOLVED: Have smfr put in a blanket MAY saying in some situations
            browsers can have these functions do nothing

Describe layout and visual viewports
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4724

  smfr: Rossen and I talked offline. I think browser have converged on
        mechanism for fixedpos in face of page zoom: 2 rectangles-
        layout and visual viewport. Not defined anywhere. Would be
        willing to write text to live in CSSOM View. Asking for a
        resolution to add a section to the spec for the layout and
        visual viewport. I expect bikeshedding the names
  Rossen: I support adding the text. Question- besides describing what
          it is and does what else is there to be done?
  Rossen: Don't anticipate providing units or capabilities that are
          accessible to css?
  smfr: Right. Think it should describe how they interact. When you
        zoom and scroll some fixedpos will disappear is unexpected for
        some authors. Spec should explain
  Rossen: 100% with you. Wanted to make sure only thing we're doing is
          adding explanation. Not adding capabilities for authors to
          target
  smfr: Correct
  smfr: There is a viewport API spec which will reference this.
  Rossen: Link?
  astearns: The link is in ther issue
  <heycam> +1 on moving towards being able to write down what <meta
           viewport> does

  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
  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
  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
  Rossen: Good to remember what constitutes an initial containing
          block in presence of these viewports
  Rossen: For abspos the containing block is layout viewport but for
          fixed it's visual viewport. That's observable for user
  smfr: Yes. Not sure those viewports are right but yes
  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.
  smfr: Correct

  astearns: Proposal: Start defining what we call layout and visual
            viewport
  astearns: I'm hearing consensus. Any concerns or objections?
  florian: Procedural: 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 awkward.
  astearns: True wherever they are
  florian: True. We can start there and move if we're blocked
  astearns: Or a L1 with just these. Do you have a suggestion of where
            else?
  florian: A viewport. Device adaptation originally but it's becoming
           fiction
  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
  smfr: I would prefer not device adaptation b/c these concepts feel
        more fundamental to basic CSS. Coordinate systems not just
        about device adaptation they're fairly fundamental
  astearns: We can hash this out at a later time. Let's get it done
            and then haggle.
  <fantasai> I'd probably keep coordinate systems in either cssom-view
             or css-overflow
  <fantasai> but layout viewport vs visual viewport is more
             fundamental than OM
  <fantasai> so I think device-adaptation is a better place, if we
             make it to be more fundamental
  astearns: Objections?

  RESOLVED: Start defining what we call layout and visual viewport

  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 things we might get to?
  smfr: Sure, happy to add a note.

CSS Sizing
==========

Determine order of intrinsic-size values
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4531#issuecomment-578214370

  astearns: TabAtkins wanted to defer but suggested to start so we can
            get some discussion in the issue
  Rossen: In addition to existing resolution?
  astearns: Yes.
  fantasai: Order of values ties into broader CSS problem with
            ordering of values. Got a solid set of ordering for box
            sides. For here it's 2 value one per axis.
  fantasai: We have 2 sets of conventions in place. We have logic
            properties like grid shorthand and scroll-snap-align which
            we went vertical axis first. y first x second. Older
            physical are x first y second.
  fantasai: Question is which convention for size. Block then inline
            or width then height or something different?
  fantasai: That's the basic question and not very simple. There is
            size for page that is physical. Width then height.
            background-size is also physical. I think we should do
            width followed by height.
  cbiesinger: Agree. Two length version of margins has height first
  fantasai: That's why when went logical we did height first.
            Reviewing I think that's a mistake but it's too late to
            fix. Physical are width, height and logical are block,
            inline.
  Rossen: Let's not repeat mistake. Let's keep width and height
  ??: Agree

  astearns: Fairly convincing to be consistent with other size
            properties.
  astearns: Height and width was suggested last time we talked
  cbiesinger: Wasn't it block and inline suggested?
  astearns: Fair, yeah.
  astearns: Can anyone capture argument for block then inline?
  fantasai: Main argument is we're moving toward logical coordinates
            in syntax design. Why grid and flex and scroll-snap are
            logical. But there's a large list of physical and sizing
            and boxes are in that category. This is a size property it
            should probably slot into that grouping.
  fantasai: That's what I feel. But we can argue we don't have a size
            shorthand so we could make it be logical.
  fantasai: Problem is we have background-size and size in paged
            media. We don't have a shorthand for box-size but we have
            sizes elsewhere in CSS.
  fantasai: Nice to shift to logical but I think more inconsistent
  fantasai: Once we figure out how to switch shorthand between logical
            and physical we can switch this too. That's an open issue
            on CSS Logical
  fantasai: This issue seems minor but ties into a systemic problem
            that's not solved
  cbiesinger: Shouldn't block property on solving systemic issue

  astearns: People on call are in consensus on width and height. We
            have an impl that agrees and wants to get it implemented.
  astearns: Could resolve knowing people want to revisit. Should we
            resolve or wait?
  Rossen: Resolve. We can always revisit. We've spent 10 minutes and
          are fairly convinced
  fantasai: Anyone on the call with a different opinion?
  <TabAtkins> I'm unhappy with this being inconsistent with the
              existing two-value logical properties. Can we just
              record this as a conversation and not resolve yet?
  astearns: Only TabAtkins who is reading IRC. Not sure if Chris H had
            a strong opinion. Don't think he did
  astearns: [Reads TabAtkins]
  astearns: Let's take to the issue for another week and resolve next
            week
  <fantasai> TabAtkins, yeah, but if we make it logical, it'd end up
             being inconsistent with background-size and page-size
  <TabAtkins> page-size I don't care about, nobody uses it.
              background-size is a reasonable counter-argument; we're
              inconsistent either way. :(

Snapshot 2020
=============

Let's make snapshot 2020 while the year is still young
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4715

  chris: I wanted to start. Last time we did a snapshot was a while
         ago. We were trying to publish at beginning of year.
  chris: Nothing to propose, but I'd like people to look and comment
         and add what spec you want.
  chris: Also discussion on what snapshot should mean. Would prefer
         that separate unless it resolves quickly. Would like to get a
         snapshot out.
  florian: Would like to say we aim for a ready to approve snapshot by
           next F2F. Let github discussion happen and then someone,
           maybe me, can write a draft
  florian: Important part is the few things that ought to be in
           snapshot and missing one publication to get in there. We
           should deal with them first
  chris: There is an issue with the FPWDs we agreed to publish.
         Separate thing I need to deal with. fantasai the patch tool
         isn't working, I might not be doing it right.
  fantasai: Let's talk about it.

  astearns: Sounds like plan is hash out what goes into snapshot in
            the issue with reminders on calls. Have a draft ready
            before we meet in Cork?
  chris: Sounds great

  astearns: Changes to the schedule?
  jensimmons: Just a comment about scope of snapshot convo to be about
              snapshot. I agree. There does seem to be a growing
              conversation about if we should define CSS 4 or a more
              marketing term. I agree that's a separate thing. The
              snapshot is a function of the WG. It's a good idea to
              consider something like CSS 4 but that's a different
              topic
  astearns: Might be good to raise a separate issue on the messaging.
            We should keep this github to publishing the snapshot
            we've engaged in producing.
  astearns: Anything else on snapshot?
  astearns: Please do look. There are a number of questions about
            which drafts should go in.
  <florian> I'll make an ED today, so that we can start to iterate.

Proposing new CSS primitives to enable great web experiences on
    foldable & dual-screen devices
===============================================================
  github: https://github.com/w3c/csswg-drafts/issues/4736

  dlibby: As maybe you've seen Microsoft has announced 2 new dual
          screen devices.
  dlibby: Given these are cross a variety of platforms and browsers
          looking at this for web would be great. CSS is great for
          layouts. Been bandying about ways to expose CSS for this so
          they can control how web content is in relation to the hinge.
  dlibby: Had some principles about don't want to expose unnecessary
          new capabilities. Trying to be cognizant that these devices
          aren't comprehensive of future. Don't want to shut door on
          future form factors.
  dlibby: It's a new media feature called 'spanning' Intent is to
          describe when viewport is spanning several screens. Depends
          on how viewport is positioned.
  dlibby: Need to understand where gap/hinge is in terms of CSS
          coordinates. Proposed 4 environment variables to describe
          where is the fold, width and height of fold
  dlibby: Excited to hear feedback, if this sounds reasonable, any
          drawbacks. Definitely open to changing based on collective
          experience

  florian: Always a challenge for a new MQ for new device.
           Categorizing devices doesn't stand as time passes. I'm
           happy to see this proposal is trying to test a relevant
           aspect of what's going on. Means we're on the right path. A
           little concerned about environment variable. When it comes
           to sizing I think this is likely to overlap the unsolved
           viewport units conversation and which parts have and don't
           have scrollbar and keyboard
  florian: All the struggle with vh/vw seem to overlap here. I don't
           have a solution. Problem space seems reasonable.
  dlibby: Makes sense. Aware of some interaction with things like vch
          unit to reference visual viewport. I would agree there's
          rationalization to be had there.
  dlibby: Being described with viewport units I don't think it sits
          how we've been thinking about it. Not sure if you're just
          noting tie-ins
  florian: Similar issue, not necessarily units. If you want to size
           something to 80% after folding, what 80% are you talking
           about? Problems are same as vh/vw even if not same units.

  jensimmons: Question: Haven't thought a lot about devices with
              hinge. Is mental model for anyone designing for screen
              simply that there's a wider screen with a web window
              like we've known for years and then suddenly it's
              magically half as wide and that's it? It jumps wide to
              narrow and narrow to wide?
  jensimmons: Or is it that people think about design of the screen
              where you have more space then that. WHen you open a
              browser window it's usually one space and when you go
              wide it goes two up? Are there thing like that?
  jensimmons: Is it simply a different way but similar to responsive
              or is it more complicated where you have 2 up because
              the new screen?
  <Rossen> https://user-images.githubusercontent.com/5052316/73715033-8a3e5b00-46c7-11ea-8839-af3801c97502.png
  Rossen: A little of both. Awareness of hinge is important and that's
          what described in spanning. Spanning is going across hinge
          in middle. That allows you to create different experience on
          that hinge location
  Rossen: If you look at motivational examples in issue they're pretty
          well thought through. If there's an email app you can do
          columns on left for folder, email titles and then right side
          is full experience with selected message
  Rossen: These are doable but if you don't know where hinge is you
          have content half on one side and half on the other. That's
          a simple example. Many others that Zouhir has been working on
  Rossen: Knowing where hinge is is important
  dlibby: Knowing where hinge is and mapping to it might be useful to
          developers in many cases. Also different OSes treat the gap
          differently, e.g. some mask content in that area whereas
          others split the screen apart.
  jensimmons: Some of these things we know so far like where is screen
              aren't issues. This is where hinge is.
  Rossen: Right. And this is why we're not defining viewport, but
          there's something that splits viewport

  astearns: Is this proposed MQ matching cases where physical hardware
            doesn't have hinge. Thinking like a reader view or
            something like that where might want to layout differently
            between left and right page. I think the answer is this MQ
            is not for a case like Kindle to view on content where
            content flows from one side to another. This is about
            having a physical gap in screen
  Rossen: I don't think we're insisting on physical paradigm. I can
          see an epub that uses multiple tabs internally to drive that
          experience using this CSS mechanism. It's something we
          haven't thought about. Good to consider
  myles: It's clear there are use cases for one browser window to span
         both halves. I've also seen use cases like in explainer with
         Google maps where one half has map and other is locations.
         For one big browser window we can do that today. 2 panes
         could be solved with presentation API
  myles: Your proposal is more powerful because allows mix both these.
         Some content aligns to fold and other span both. I haven't
         seen cases for this mix. Can you describe one?
  dlibby: I think you said there's single window paradigm and you
          split content. The other where you lean on presentation API
          to open another full window. Correct?
  myles: What type of content are you encouraging web designers to
         create with this API. Because with no API web designers could
         create for this. Presentation API would encourage 2 different
         independent. You haven't proposed either of those types.
         You're proposing a 3rd type that doesn't fall into first two
         buckets. What type of content are you encouraging that's not
         in those buckets?
  astearns: Specifically a mixed mode were some content is split but
            other content spans both?
  Rossen: Let's consider a mail app with an application bar that spans
          both screens and then left and right sections for the two
          screens
  myles: Yeah, I think that answers. A nav bar that spans across the
         fold.

  heycam: A little unclear to me if the model here is the window that
          spans the two displays. Does it have a strip of pixels which
          are not rendered because they overlap the folder or is the
          back buffer for the window is split? Or both?
  dlibby: Accommodate both. Early Microsoft devices is that they'd
          have different. One has pixels across the back and the other
          has a split. In one case your fold-width would be 0 but it's
          still there
  heycam: Understood.
  heycam: For UI or content you want to span, the toolbar and you've
          got buttons you want to avoid the fold space so you don't
          lose half a button- not sure if there's a great way to use
          env variable to make them avoid fold if you're using
          flexbox. I guess you can fallback to script
  Rossen: What you're saying is exactly what [missed] to avoid having
          loss of content to avoid having the button fall under the
          hinge
  Rossen: If you see fold width it essentially describes that space
  heycam: I'm imagining a flexbox container that spans the width. I'm
          not sure how you use nth env variable to make sure the flex
          items when you get to fold one doesn't go over fold.
  florian: Similar is a 3 column grid where you want 2 and 1 and you
           don't care which side is the 2 but you don't want a split
           grid.
  Zouhir: First one is a single flexbox with an arbitrary number of
          buttons with width. You won't know when buttons reach hinge
          but it'll help you make 2 columns. Request is a single flex
          and avoid the gaps
  heycam: Right. That might be an example of the more general region
          flow
  Zouhir: The original demos we experimented with we didn't touch on
          arbitrary number of children avoiding hinge. We did make
          multiple grid and flexbox where we can snap to the fold
          nicely. It's a good note to take
  astearns: Good to add examples of env variables with layout
            mechanisms
  <fantasai> It sounds like you really need media queries against the
             fold offsets

  plinss: Couple points- Lot of work is being done on folding screens
          and I'm hesitant to do something in CSS that we'll have to
          carry around when folding screens might no longer have
          hinges. However multiple monitors on desktop is common.
          Would like to make sure if we solve what we do applies on
          desktops as well. Food for thought
  <fantasai> plinss++
  <Rossen> +1 to plinss
  dlibby: Good feedback. Have that in the back of our mind but not
          concrete
  Rossen: We've taken steps to make sure that's not obstructed. But
          yeah multi-monitor is first that came to discussion
  plinss: And there's 4 monitors in a grid where you have vertical and
          horizontal
  astearns: Thanks for the introduction. I'm sure we'll discuss on the
            issue and again on a call
Received on Thursday, 6 February 2020 02:15:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:15 UTC