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

[CSSWG] Minutes Virtual F2F 2020-07-27 Part I: Grid, Overflow [css-grid] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 3 Aug 2020 19:42:11 -0400
Message-ID: <CADhPm3t6dEgmaaqaUARJqGgK8NbLHjLOE=EOxkHEZT9oO_i+-w@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.

CSS Grid

  - RESOLVED: The auto minimum size is zero for grid items that span
              multiple tracks when at least one of those tracks is
              flexible. (Issue #4783: Intrinsic contributions for
              items spanning flex tracks are not web compatible)
  - RESOLVED: When distributing the intrinsic contribution of a grid
              item, if it spans flexible tracks, excess size is
              distributed to those tracks and not to fixed/auto sized
              tracks. (Issue #4783)
  - RESOLVED: Accept the edits made to the ED re minimum vs
              min-content (and add WPT tests) (Issue #4790: Growth
              limits not increased with min-content contributions of
              spanning items)

CSS Overflow

  - There was interest in exposing pan and zoom functionality through
      CSS (Issue #5275: Consider adding new CSS primitive for
      per-element panning and zooming (for web maps))
  - This is a complex space so it's important to make sure all use
      cases have been investigated and there is a proposal that takes
      them into account
  - Concerns were raised that on the web this wouldn't be used for
      maps since people will want their custom solutions. However there
      are other use cases such as PDFs that could also use pan and
  - An additional possible benefit would be standardizing the gestures
      for these actions which would be good for accessibility and
      interaction from new / unusual devices.
  - A possible solution would be to have new generic property that
      switches into pan+zoom mode and a gesture-based JS approach
      which authors could hook into and make their own approach.


Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#monday

  Rossen Atanassov, Microsoft
  Tab Atkins-Bittner, Google
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Simon Fraser, Apple
  Daniel Holbert, Mozilla
  Dael Jackson, Invited Expert
  Una Kravets, Google
  Peter Linss, Invited Expert
  Alison Maher, Microsoft
  Myles Maxfield, Apple
  Cameron McCormack, Mozilla
  Tess O'Connor, Apple
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Devin Rousso, Apple
  Jen Simmons, Apple
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Lea Verou, Invited Expert

Scribe: AmeliaBR

Upcoming Meetings

  astearns: I don't think there's much housekeeping. TPAC will be
            virtual, need to start planning, hopefully more in advance
            then for this
  TabAtkins: When is TPAC?
  fantasai: Late October, but the TPAC week is for breakouts, groups
            are encouraged to do F2F not on that week, so TPAC will be
            more spread out to make room for time zones.
  fantasai: AC meeting also a separate week.

CSS Grid

Intrinsic contributions for items spanning flex tracks not web
  github: https://github.com/w3c/csswg-drafts/issues/4783#issuecomment-587749012

  oriol: This is a web incompatibility issue.
  oriol: In the last published version of spec, we weren't taking into
         account intrinsic contributions of items that span multiple
         tracks, if one of those tracks was flexible.
  oriol: This doesn't make much sense. So we changed in ED, but when
         I tried to implement the change I had to revert because it
         wasn't web compatible.
  oriol: My proposal is to alter the draft to keep as much of the new
         behavior as possible, but still be web compatible.
  oriol: But I found 2 different problems.

  Oriol: First, there's a common pattern of 12 columns sized with 1fr.
         The intention is that all columns are equal sized & not
         overflow. But problem is that 1fr by default has `auto` min
         size, which takes intrinsic size into count.
  oriol: Right now, you don't see the auto min because most items span
         multi-columns. If we changed that so the intrinsic has an
         effect, you could make columns uneven or even overflow
  oriol: Now, this is partly an author error. You'd get the overflow
         if you had items that didn't span multiple columns. Could use
         minmax() to make it work, but since 1fr was working, authors
         didn't do that.
  oriol: So suggestion is that the auto min width of elements is zero
         if they span multiple tracks, at least one track is flexible.
  oriol: Then in the algorithm, we'd change the auto min width, but
         the rest would work out based on that.
  oriol: But if someone explicitly said `min-content` for minimum
         width, that would work correctly.
  oriol: I think this would handle most web compat issues.
  oriol: There's an example with code & images in the issue.
  <fantasai> +1 to Oriol's proposal

  jensimmons: So, right now this is about making things easier for
              authors? They *can* do what they want either way, but
              this is about making the default better?
  oriol: Right now in browsers, you can't use min-content or
         max-content for these items. It always behaves as zero. So
         the proposal is to support that. It's what the current draft
         was trying to do, but the change addresses the compat. Going
         back to always being zero isn't very useful.
  fantasai: FWIW, tab & I support the proposal.
  oriol: Should I cover the other issue, or resolve on this.

  PROPOSAL: The auto minimum size is zero for grid items that span
            multiple tracks when at least one of those tracks is

  astearns: Are there any concerns about having a switch based on
            spanning multiple tracks.
  fantasai: I think that's better than the alternative.
  fantasai: The published draft already has a switch based on spanning
            multiple tracks. It means we don't consider intrinsic
            sizes at all. The existing change to the ED got rid of
            that, but it's not compatible by default.
  fantasai: Oriol's proposal is that by default you get the current
            behavior, but if you specify something explicit that is
            used instead.
  fantasai: So yes, we have an inconsistency about whether the
            intrinsic size is considered, based on spanning multiple
            tracks. But we're shifting the inconsistency from the grid
            algorithm to the definition of auto min size.
  <fremy> fwiw, now that understand the difference between current and
          proposed, I support this change
  Rossen: But we're still having an inconsistency in auto min size.
          The default behavior isn't do the right thing.
  fantasai: Yes, but it's do what authors currently expect because of
            current implementations.
  Rossen: Is compat that bad?
  fantasai: Yes.
  Rossen: OK, so I guess this is least worst solution.

  RESOLVED: The auto minimum size is zero for grid items that span
            multiple tracks when at least one of those tracks is

  oriol: OK, the second problem affected authors who knew about the
         problem of using auto minimum in a flexible track, so they
         used an explicit minimum of zero, which then causes a
         separate problem.
  oriol: If you have 2 columns, one sized with minmax, other with 1fr.
         One item in auto column only, the other item crosses both.
  oriol: Author expects the flex item to fit the item that's only in
         that column, but we resolved in 3075 that *all* the flexible
         tracks, if they don't have an intrinsic minimum, it would be
         spread across all the tracks that an item spans.
  oriol: Otherwise, a minimum size on a particular item could cause it
         to overflow.
  oriol: But generally the element spanning both columns is the larger
         one, so this can result in stretching the column & therefore
         the other item too much.
  oriol: This could have been fixed with the content keywords, but
         since setting a minimum of zero was formerly a good way to do
         this, that's what they used.
  oriol: Proposal is to modify resolution from 3075. If an item spans
         flexible tracks, when running track-sizing algorithm, the
         intrinsic contribution will only be distributed among the
         *flexible* tracks it spans, not the non-flexible ones.
  oriol: That would solve this use case. There wouldn't be too much
         contribution going to the auto column, all the extra would go
         to the flexible one.
  oriol: The resolution we just took would still cover the use case we
         were trying to solve in the previous issue.

  astearns: We never resolved that other issue.
  fantasai: But the resolution we just had would address it, with this
            one modification.
  fantasai: I think there are some subtleties to define in what we
            mean by flexible tracks taking up this extra size. E.g.,
            depends on whether it has a fixed or intrinsic minimum
            size, and whether we're sizing the grid under a min size
  oriol: Should we do this at all if sizing under a min/max content
  fantasai: In that situation, we always consider the contents. That's
            expected. But I think we still have some errors there were
            we consider the max, but not the min. So we do need to
            think about those details.
  <fantasai> https://drafts.csswg.org/css-grid-1/#algo-flex-tracks
  fremy: My impression of this topic is that we had something widely
         implemented that we didn't think was well designed, but now
         we're making piecemeal changes to try to fix compatibility.
         But I'm afraid we're going to get inconsistent implementation
         where some browsers make some of these changes but not
         others. Reminds me of CSS tables, in a bad way. We're going
         to need careful tests to make sure we have consistency.
  TabAtkins: Elika & I have been adding tests against the changes
             section, so we should catch that quickly.
  fantasai: And we can add tests for these changes in next couple
  astearns: So, you have no concerns about these particular changes,
            just about following up with tests?
  fremy: Yes.

  astearns: fantasai, the other issue you raised about the algorithm
            not handling min/ max content, that's a separate issue?
  fantasai: yes, we can still go ahead with this.

  oriol: PROPOSAL: When distributing the intrinsic contribution of a
         grid item, if it spans flexible tracks, excess size is
         distributed to those tracks and not to fixed/auto sized
  Rossen: {Gives an example}
  oriol: No. If there are fixed size tracks, that size is subtracted
         before distributing extra to the flexible tracks.
  Rossen: OK, then I agree. Need to make that clear.

  RESOLVED: When distributing the intrinsic contribution of a grid
            item, if it spans flexible tracks, excess size is
            distributed to those tracks and not to fixed/auto sized

  astearns: ... and add tests

Growth limits not increased with min-content contributions of spanning
  github: https://github.com/w3c/csswg-drafts/issues/4790#issuecomment-664068575

  <fantasai> https://drafts.csswg.org/css-grid-1/#algo-content
  fantasai: This will make more sense if I pull up the relevant
            section of the spec. ↑
  fantasai: There are several sections in how we handle intrinsic
            sizes. Minimums first, then maximums. For minimums,
            there's auto, min-content, max-content. For maximums,
            there's no auto, so min-content then max-content.
  fantasai: When we edited the spec recently to add new terminology,
            we accidentally said “minimum” when we meant
            “min-content”. But when we went to fix that, discovered
            had been implemented as written, so need to confirm the
  fantasai: The current text is rather nonsensical. It's very rare/
            weird that min-content would be specified as the maximum
            value of your minmax range while not also the minimum.
            We should fix it.

  astearns: Anyone have actual web compat information measured? Or
            should we change & see if we get negative feedback.
  oriol: I do know there is no WPT for the bad behavior, although
         there is a Chromium internal test.
  <fremy> sounds unexpected to me
  fantasai: I can't see any reason why anyone would write this code,
            with min-content in the max side of a minmax function.
            -> minmax(<length>, min-content)
  fremy: I don't expect people would do that. We should be able to fix
  PROPOSAL: Accept the edits made to the ED re minimum vs min-content
            (and add WPT tests)

  RESOLVED: Accept the edits made to the ED re minimum vs min-content
            (and add WPT tests)

CSS Overflow
  Scribe: fantasai

CSS primitive for per-element panning and zooming
  github: https://github.com/w3c/csswg-drafts/issues/5275

  AmeliaBR: This has come up with work I've been doing, and zcorpan
            was reviewing, on standardizing map viewers
  AmeliaBR: A map embed, where you move around the map on the screen
            and zoom in / out
  AmeliaBR: There's no standard way to describe that behavior in specs
  AmeliaBR: But it is a very common pattern, with common interaction
  AmeliaBR: Mouse behaves a certain way, touch behaves a certain wain
  AmeliaBR: In addition to map viewers, also common for product photos
            on a retail site
  AmeliaBR: data visualizations

  AmeliaBR: Some things to think about..
  AmeliaBR: two different aspects of typical pan+zoom impl
  AmeliaBR: One is the UI and interaction patterns
  AmeliaBR: how the end-user indicates, by gestures or whatever, where
            they want to go and and zooming in / out
  AmeliaBR: The other aspect is loading content, e.g. higher-resolution
  AmeliaBR: From a CSS perspective, they are going to be two
            independent things to think about
  AmeliaBR: Loading in separate content, have something similar to a
            MQ scoped to a particular container that has a zoom state
  AmeliaBR: triggers picture sources or whatever

  AmeliaBR: Basic prerequisite for that is to have a standardized way
            to describe pan + zoom
  AmeliaBR: Which as a lot of similarities to scrolling environments
  AmeliaBR: but the standard actions are a little different, different
            translation of input;
  AmeliaBR: different established pattern of movement
  AmeliaBR: Other thing is that you don't necessarily start at the
            beginning and scroll down, often starting in the middle
  AmeliaBR: and usually not showing scrollbars
  AmeliaBR: So established pattern of panning, semi-standardized
  AmeliaBR: not always implemented in a way that is
            keyboard-accessible, or devices otherwise unique wrt inputs
  AmeliaBR: So much easier for authors to have a standard way to
            switch into this mode, don't have to code up a lot of JS
  AmeliaBR: and can make it more cross-platform and accessible

  AmeliaBR: No proposal yet, but wanted to bring up to CSSWG, is it
            something appropriate to address in CSS? Any opinions on

  <tantek> interesting, Google Maps is a *mix* of infinite pan in the
           horizontal direction, while having blocking scrolling in
           the vertical direction!
  <tantek> Yandex maps also only does (infinite) pan horizontally and
           (blocking) scroll vertically.

  emilio: I was chatting about this with some of the zooming folks in
  emilio: Zooming and panning is limited to top-level content document
  emilio: Depends on specific use cases you want to solve
  emilio: Not enabling for iframes etc, is artificial limitation
  emilio: Depending on set of use cases, documents already have all
          these APIs, visual viewport API etc.
  emilio: allow authors to react to these things
  emilio: Depending on set of use cases, if enabling on iframes solves
          them, could be relatively easy to do
  AmeliaBR: That's interesting. So describing it as the same
            pinch-zoom behavior that we have in most mobile browsers
  AmeliaBR: but scoped to a specific element
  AmeliaBR: One thing there, I don't know enough about mobile a11y if
            there's standard mapping to keyboard controls for
            pinch-zoom view

  TabAtkins: I think this is great and interesting
  TabAtkins: especially on touch devices, interaction is similar wrt
             scroll vs pan
  TabAtkins: but being able to opt into more pan+zoom interaction
             easily on desktop would be useful

  TabAtkins: You said something about being media-query?
  TabAtkins: Needs to be a property modifying how we handle overflow
  TabAtkins: particularly because of wrapping behavior necessary for
             some cases
  AmeliaBR: MQ thing was for the loading different resolution images
  AmeliaBR: e.g. in a picture source
  TabAtkins: Talking about level of detail?
  AmeliaBR: Yes
  TabAtkins: Level of detail is a much more complicated topic
  TabAtkins: If we can separate from overflow interaction... it's much
  AmeliaBR: Agree it's the next level, and first level would be to
            standardize pan-zoom interaction
  AmeliaBR: and zoom part of it, so long as it's exposed to authors so
            they can detect the desired level
  AmeliaBR: that can be JS at first
  AmeliaBR: and work on declarative way to do that as we go along

  AmeliaBR: You brought up another point, tantek brought up too,
  AmeliaBR: in some environments, such as maps, you want a wrap-around
  AmeliaBR: If you scroll to the end, scrolls back to the beginning;
            spherical or cylindrical coordinate system
  AmeliaBR: Other areas in CSS where it might be useful, like an image
  AmeliaBR: where you scroll to the end, end up at the beginning
  AmeliaBR: Again, slightly separate from panning interaction itself
  AmeliaBR: but is also a relevant part of the discussions

  heycam: I think it's worthwhile thinking about this further
  heycam: My one concern is that we know what the full set of
          requirements are around panning and zooming
  heycam: so that we don't design a feature that goes 90% of the way,
          but the last 10% requires reimplementing everything
  heycam: E.g. some JS things let you pinch-rotate the map
  heycam: if not a good way to do that, they authors might feel like
          re-implementing everything
  <tantek> oh yeah, there's also two-finger-tilt in some maps!
  heycam: Might want to list what are the missing features, that
          doesn't allow doing maps online
  heycam: what's missing/janky
  heycam: so we know the design space

  smfr: Echo some of heycam's concerns
  smfr: Different clients have different needs
  smfr: some have very specific requirements
  smfr: anything we make might not be enough, end up using JS again
  smfr: Maybe we should focus on primitives that people require to do
  smfr: one is always getting gestures right
  smfr: sometimes it's vertical scroll, sometimes it's pinch-zooming,
  smfr: WebKit had some non-standard events like this

  smfr: Different areas of the page with different zoom levels, could
        have confusion wrt MQ or something
  smfr: Need to figure that out
  AmeliaBR: Just answering to last bit about CSS transforms, that's
            how I picture it
  AmeliaBR: similar to CSS transforms or SVG viewbox, where it is a
            localized transform that gets added to that stack
  AmeliaBR: That's how it was originally specced for SVG, that there
            would be a user interaction that ends up changing the
            viewbox transform
  AmeliaBR: That never got implemented in browser versions of SVG

  dbaron: I agree with a lot of the concerns brought up so far
  dbaron: a lot of panning and zooming is complex behavior
  dbaron: as mentioned
  dbaron: Also many sites change fragment of the URL in response to
          panning and zooming, so you can bookmark where you are
  dbaron: An interesting thing to investigate, if we do or don't want
          to do something, requires a more concrete proposal about
          something to add
  dbaron: and an analysis of how that thing is useful for all the
          consumers that are out there
  <dbaron> Example of the pan/zoom results being in the URL (in a very
           common format for putting it in the URL):

  <tantek> could see pan as an alternative to scroll, meaning it wraps
           around in that dimension. that seems like a nice
           incremental enhancement.
  <tantek> gmap-pedometer is also horizontal pan, vertical scroll

  fremy: I think that's similar to what other said before
  fremy: Map use case, it's unlikely to desire to do in CSS
  fremy: When you start to do zooming, dimensions of pixel changes
         over time
  fremy: with dynamic contents
  fremy: it's easier to adapt yourself as zooming
  fremy: than to back-propagate to elements shown
  fremy: For use case for maps, highly unlikely anyone would prefer
         CSS solution
  fremy: but other cases
  fremy: if you include PDF or SVG documents
  fremy: Sometimes it's really nice to be able to zoom on them
  fremy: and these contents do not react to gestures
  fremy: so more reasonable use case to focus on these
  fremy: So you really want to provide view on fixed contents
  fremy: For maps, need to know where user is, fetching data to get
         new info, new tiles, etc.
  fremy: I'm not sure it would work for a world map to fit in CSS
  fremy: At least for dynamic use cases, seems highly unlikely for CSS
         to provide a solution
  fremy: so if working on that, suggest to focus on static use cases
  fremy: You want the effect, but don't want to include an entire

  chrishtr: In addition to what fremy said, about dynamic scenario,
            where devs want top optimize pixels at different zoom
            levels and to ??
  chrishtr: A lot of maps these days are drawn with WebGL anyway, I
            don't think this approach would work with WebGL
  AmeliaBR: Could work if you have a top-level DIV which maintains
            interaction with users, and passes things as events
  AmeliaBR: just as many things use position on scrollbar to trigger
            things, but still using normal scrolling
  chrishtr: Common gestures across sites would be useful

  Rossen: I think most everything was said already
  Rossen: Want to underline here, still the motivation or use case
          here involves quite a bit of complexity
  Rossen: Zoom as a gesture, as a capability of a presentation system,
          is a very overloaded behavior, that has many different parts
          that more often than not apps are hooking into
  Rossen: Initiation of zoom vs when it is already steady
  Rossen: visual zoom, layout-affecting zoom
  Rossen: semantic zoom, going through levels of different categories
          of app logic
  Rossen: loads / unloads resources
  Rossen: so this is also a type of zoom
  Rossen: Tab summarized as, what are primitives we're missing here?
  Rossen: When we thought about this in the past
  Rossen: and attempted to extend zoom for application developers
  Rossen: the main point was, what are the primitives that a platform
          such as CSS needs to provide
  Rossen: capabilities and observability of it
  Rossen: To extend that we do to today, quite far on this journey
  Rossen: can observe types of transforms applied, etc.

  Rossen: But you also mentioned something interesting
  Rossen: around a11y, and this being able to help a11y
  Rossen: What do you mean by that?
  Rossen: is that the ability to use zoom as an intent? or are there
          experiences broken today?
  AmeliaBR: Specifically about existing author code and libraries
            aren't necessarily working well with different ways people
            interact with their computer
  AmeliaBR: Pan and zoom via keyboard controls is very opaque and
            inconsistent from site to site
  AmeliaBR: just by standardizing it, we could move towards the
            browser controlling that standard interaction
  AmeliaBR: and making sure it's accessible for all the ways people
            interact with their computer
  AmeliaBR: Being able to zoom is also an a11y issue, but not
            necessarily going to line up with author's decision that
            certain content is zoomable

  Rossen: Usually what we specify here, we specify different modality
          of input
  Rossen: and capability of apps to provide the zoom experience or
  Rossen: whether [lists input actions that all translate to same
  Rossen: Reality is these will differ vastly between capabilities of
  Rossen: and standardizing on these types of gestures or higher-level
  Rossen: will be more troublesome than if we identify primitives
          missing in the platform to allow awareness of this thing

  TabAtkins: I strongly agree with idea that this would be really
             useful for a11y, because not relying on bespoke and
             incomplete JS solutions to a very common modality
  TabAtkins: As something becomes common, if it's addressed by random
             JS solution, won't be accessible to people not having
             same setup as JS author
  TabAtkins: Capturing, as Amelia says, that this is meant to be a pan/
             zoom thing
  TabAtkins: As dbaron says, we need a concrete proposal
  TabAtkins: I propose two parts
  TabAtkins: 1. new generic property that switches into pan+zoom mode
  TabAtkins: 2. A gesture-based JS approach, so you can hook that, and
             then roll your own pan+ zoom
  TabAtkins: So you can roll your own, as people currently do with
             'overflow: hidden'
  <tantek> +1 TabAtkins
  TabAtkins: So, CSS side that does things automatically as long as
             you do simple thing
  TabAtkins: and JS side that standardizes pan+zoom gestures, and lets
             people hook that to do further stuff
  TabAtkins: build on top of mouse/keyboard gestures etc.
  <smfr> not scroll events (they are reactive, not prescriptive)
  <smfr> say input events like mouse and wheel
  AmeliaBR: That's a useful breakdown
  AmeliaBR: Also need to take into consideration what exactly overflow
            would look like, all different things that need to be
  AmeliaBR: semantic gesture events, for pan+zoom

  <tantek> was tilt explicitly excluded or just not brought up?
  <TabAtkins> not brought up
  <tantek> e.g. Google maps on a touch device, two finger up/down
           gesture will tilt the map up/down

  AmeliaBR: One question, who would be standardizing group for adding
            new events?
  <tantek> good question, what would the TAG say?
  TabAtkins: I think WICG until it gets picked up by DOM?
  fremy: But we do have CSS events too
  smfr: We also have scroll events
  smfr: You want all the input events to be defined in the same place
  <tantek> pan / zoom / tilt / rotate

  fantasai: In addition to capturing the gestures that would
            correspond to pan/zoom/etc
  fantasai: I think if you had pan/zoom mode for overflow, we have
            currently a lot of APIs for getting the current scroll
            position and for directing to go to a particular position
  fantasai: You'd probably want analogous methods that would let you
            do the same things in pan+zoom, e.g. get zoom level or set
            zoom level
  <tantek> +1 fantasai, zoom level equivalents to scroll settings
  <tantek> The only request I have is to include tilt & rotate in pan
           & zoom considerations / designs
Received on Monday, 3 August 2020 23:43:07 UTC

This archive was generated by hypermail 2.4.0 : Monday, 3 August 2020 23:43:08 UTC