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

[CSSWG] Minutes Virtual F2F 2020-04-30 Part III: CSS Snapshot, Masonry Layout, CSS Backgrounds, Foldable & dual-screen devices [snapshot-2020] [css-backgrounds-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 15 May 2020 18:39:11 -0400
Message-ID: <CADhPm3t8cPRs4U7uhZtW=sPpzPVLOJLLiuUU=Snx66ZT_-Pfsg@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 Snapshot

  - RESOLVED: Move contain-1, cascade-4, easing-1 to the official
  - Grid was argued to not be ready to move into the official section
      due to the number of outstanding issues.
  - Align was argued to not be ready to move into the rough interop
      section due to the sections on display:block not being
      implemented yet.
  - RESOLVED: Move writing-modes-4, display-3, font-loading-3 to the
              "fairly stable" bucket
  - Color-4 was not ready to move into fairly stable as it still needs
      more work.
  - Fonts-4 was not ready to move into fairly stable as it had too
      many open issues, though may be moved later in 2020 when the
      spec is closer to CR.
  - RESOLVED: Have snapshot buckets all be sections

Masonry Layout

  - There's a new explainer for masonry layout (Issue #4650) with more
      details on the proposed spec:
  - There still wasn't agreement on if masonry layout should be grid 3
      or on its own. An issue will be opened so it can be discussed
  - Masonry layout works for both columns and rows, but fails if set
      on both.
  - An issue will be opened on how masonry layout interacts with
      intrinsic size. The definition in the explainer seems like it
      will need additional details and some possible solutions were

CSS Backgrounds 4

  - RESOLVED: Close #4996 (Suggestion: “background-opacity” CSS
              property (as suggested by CSS-Tricks.com)) and #4706
              (`background-filter`) as no-change; filter() is what's
              intended to solve these cases.

Foldable & dual-screen devices

  - dlibby gave an update to the group on the changes that have been
      made for multi-screen extensibility based on the previous
  - Solving for multiple geometry across multiple folds seems like it
      will require complex calculations and some people in the group
      believed that for simplicity the original scope should be just
      multiple folds without complex geometry.


Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-two-time-slot-b

Scribe: fantasai

CSS Snapshot
  github: https://github.com/w3c/csswg-drafts/issues/4715

  astearns: I think all we need to decide is which specs go in which
  astearns: At the moment, there are four specs proposed to graduate
            to official CSS
  astearns: 2 to graduate to "rough interop"
  astearns: and 6 into "fairly stable"
  astearns: Proposed to add to official set
  astearns: Grid 1
  astearns: Contain 1
  astearns: Cascade 4
  astearns: Easing 1

  fantasai: I don't think Grid is stable enough yet
  fantasai: Shouldn't go into snapshot in the current state
  fantasai: Lots of open issues
  fantasai: Also publication is still blocked on test cases

  Scribe: heycam

  chris: What does stable mean?
  chris: People are relying on it
  fantasai: The original purpose of the snapshot--might want to
            rethink, but--we had a whole bunch of specs that were
            basically RECs
  fantasai: but didn't have a completed "all tests pass, full test
            suite" etc.
  fantasai: Known limitations of the test suite, known bugs unfixed
  fantasai: We wanted to capture the fact that these specs are
            basically RECs, but have a few things need fixing up,
            which might take a while
  fantasai: The bar for getting into that top level is really high
  fantasai: Another problem right now, we have a lot of specs which
            should be in CR but are not
  fantasai: The poster child for these: animations, transitions,
            those kinds of things
  fantasai: We added a note to the snapshot saying these are widely
            implemented, with fiddly bits not worked out yet. That new
  fantasai: Then for completeness, we have a bunch of CRs, may as well
            put them in there. but they're not at the "this is a Rec"
  fantasai: That's how we got to this point with those categories
  fantasai: Not sure what we need from the snapshot right now
  <dbaron> I'm not quite sure I agree with the description of the
           third category
  fantasai: The purpose of the snapshot was to communicate actual
            status which was not obvious from the official status
            of the specs

  astearns: I propose we don't discuss the purpose of the snapshots
  astearns: we have a list of specs that have been suggested to add,
            we can just move through them, and choose not to move
            individual specs if we want
  astearns: for the remaining things, that are being considered to be
            put into the official section, any objection to contain-1,
            cascade-4, and easing-1?
  <TabAtkins> I object to Grid being omitted; I don't think that this
              is worth anything to authors if something of Grid's
              practical status is omitted.
  fremy: It's really weird that you would have contain but not grid
  florian: contain is a rec, grid is not
  fantasai: Grid is not stable, the spec text is not at the same level
            of stability
  TabAtkins: Regardless of still tweaking grid, authors are depending
             on grid in its current form in production all over the
  TabAtkins: If it's not considered stable for the snapshot, I'm not
             sure what message it's communicating if grid is not there
  fantasai: It wasn't originally intended for authors
  fantasai: hence we might want to discuss the purpose of snapshots
  dbaron: I think Grid is in a similar state to what we thought about
          animations a few years ago
  dbaron: when it went into this category
  astearns: The first category is "roughtly interoperable"
  fantasai: Grid belongs there, not the top category
  AmeliaBR: Three categories are: official stable specs, roughly
            interoperable but needs more spec work, fairly
            stable but needs more impl experience
  AmeliaBR: transitions, animations, grid, these are all in the "rough
            interop" category
  AmeliaBR: moving one up and not the others, not sure what the
            argument is for that

  astearns: To make some progress, I didn't hear objections for
            contain-1, cascade-4, easing-1
  <dbaron> (BTW, I think I was confused about what was proposed to
           move where when I made my last comment.)

  RESOLVED: Move contain-1, cascade-4, easing-1 to the official

  astearns: Two candidates for adding to "rough interop"
  astearns: align-3 and cascade-4
  fantasai: I thought cascade-4 was at the top now?
  astearns: cascade-3 is in the official part, cascade-4 is currently
            in the "fairly stable" part
  fantasai: cascade-4 I think is revert + scoping?
  fantasai: shadow DOM scoping stuff
  dbaron: I have comments on align, but maybe we should talk about
          cascade first
  florian: cascade is part of the resolution we just took
  astearns: Sorry, my duplication problem
  astearns: Let's talk about align

  dbaron: One question about align is to what extent it's roughly
          interop varies depending on what you're talking about
  dbaron: Align is pretty interop if you talk about it applying it
  dbaron: but for applying display:block, it's mostly not implemented
          at all
  dbaron: so I think that makes it a little unclear where it should go
  AmeliaBR: Are the parts of align that were originally defined in
            terms of flexbox/grid, is that text still in those spec?
            or has it been moved out to align
  fantasai: Believe it's in flexbox, was never in grid
  astearns: Seems like enough for me not to move it up to "rough
  heycam: Might want to split out the application to block to a
          separate level
  astearns: Yes but there's still value to having the aspiration in
            the current spec
  chris: There is a cost to splitting it out, can cause impls to slow
  dbaron: In this case, we're in a position where the longer we wait,
          the more likely we'll have compat problems if we do it
  dbaron: to the point that from a Gecko perspective we wouldn't be
          comfortable implementing first
  dbaron: If we impl, find it is compatible, nobody else impls, then a
          year later we find it's no longer compatible, and we have to
          take it out
  astearns: For snapshot purposes, let's move on

  astearns: The last category is "fairly stable"
  astearns: 5 spec suggested to move into it
  astearns: writing-modes-4 (fairly small), display-1, fonts-4,
            font-loading-3, color-4
  chris: Despite being the editor, I will argue against color-4
  chris: It's not quite ready
  chris: The working color space needs to be added

  chris: fonts-4, I would argue for that
  chris: The variable font part is good, rest is fairly reasonable
  chris: I will resist splitting out the color font stuff
  chris: I want to encourage impls by having it in there
  fantasai: There are a lot of open issues on fonts-4
  chris: 67 of them
  fantasai: Putting it into stable-ish category usually indicates
            fewer issues
  fantasai: In terms of open issues, what does that look like?
  chris: Lots of little issues. a pile related to generic font
         families, ~20 of them
  chris: Many will be closed with no effort or dealt with
  chris: Think it's reasonably mature though
  fantasai: If it's reasonably mature, we should try to get it into CR
            and push it forward
  fantasai: If it makes sense, push out the generic fonts stuff to
            level 5...
  chris: I did ask i18n for wide review today
  chris: but I give them a 3-6 months to CR guesstimate
  fantasai: I would love to see fonts-4 in CR
  fantasai: At that point it would be great to add to the snapshot
  fantasai: but given there are significant open issues, I don't think
            it qualifies as "fairly stable"
  fantasai: but I think you're not far from there, could probably add
            it later in 2020

  astearns: So let's not add it to the snapshot for now
  astearns: We're down to 3 new candidates
  astearns: writing-modes-4, display-1, font-loading-3
  dbaron: I would like to change display-1 to display-3, since
          display-1 doesn't exist
  astearns: Any concerns with those three specs going into the "fairly
            stable" bucket?
  astearns: any objections?

  RESOLVED: Move writing-modes-4, display-3, font-loading-3 to the
            "fairly stable" bucket

  astearns: Organizational question about the buckets:
  astearns: Two are sections, one is a note. why not have 3 sections?
  fantasai: I think that would probably make sense!
  astearns: Any objections to having 3 sections?
  chris: sgtm

  RESOLVED: Have snapshot buckets all be sections

  <dbaron> FWIW, I think I somewhat preferred the note setup rather
           than switching to sections, but I'm ok with sections
  <fantasai> dbaron, why?
  <fantasai> not that I necessarily disagree, just want to know your
             reasons :)
  <dbaron> fantasai, I guess I liked the idea of the snapshot defining
           one thing rather than three things

  chris: Who's pushing it forward? florian made the first draft
  florian: I am the editor
  florian: I'm OK with doing some of it

  Scribe: fantasai

Masonry Layout
  github: https://github.com/w3c/csswg-drafts/issues/4650
  explainer: https://github.com/w3c/csswg-drafts/blob/master/css-grid-2/MASONRY-EXPLAINER.md
  example: https://codepen.io/jensimmons/full/QWjqbJj

  heycam: Small update since we last talked about this in A Coruña
          where jensimmons gave a great introduction
  heycam: Since that time, Mats has done some refining of the idea in
          the issue
  heycam: and has landed a prototype in Gecko
  heycam: Want to get feedback
  heycam: Also written up an explainer doc
  heycam: Thought it might be helpful to have a more high-level
  heycam: so not wading through GH issue
  heycam: Don't know whether people are wanting to dive into
          discussions about particular aspects of the proposal or not
  heycam: Now that we have a prototype and an explainer, might be
          worth people filing individual issues against the proposal
  astearns: definite +1 to individual issue

  fantasai: Great to have individual issues. Why not have a FPWD? We
            have agreed to work on it.
  heycam: Seemed like people were not sure about whether this should
          be a grid feature or not
  fantasai: When we come up with early stage work; we're often unsure
            about many things. Doesn't mean we don't draft it up and
            publish it.
  AmeliaBR: Can we agree to adopt this concept as described in this
            explainer as something we want written up in css-grid-2
            spec or grid-3?
  AmeliaBR: So question is can we agree to adopt what's written up?
  fantasai: Thought we already agreed to adopt.
  heycam: Thought we only agreed on the idea.
  heycam: If people willing to resolve on, for now, keep this as
          something to the grid model
  heycam: add to grid-3
  astearns: We officially agreed to adopt and assigned editors

  jensimmons: There seemed to be a lot of debate in the group about
              whether built on grid
  jensimmons: Example, fallback is grid, very nice
  jensimmons: Idea that Mats had to use masonry as part of Grid spec
              means you get Masonry in one dimension while all power
              of grid in the other dimension
  jensimmons: so rows can be masonry and columns are full power of grid
  jensimmons: But other ideas, certain people very strongly held
  jensimmons: didn't like using Grid as the place to do masonry,
              wanted display: masonry
  jensimmons: I've seen some reactions from folks on Twitter etc.
  jensimmons: "you can already do this, why new thing", Well no you
  jensimmons: They think of it as multicol or flexbox
  jensimmons: Open question, should this be part of Grid
  jensimmons: But enough of a disagreement that we weren't sure

  florian: Remains an open question, will have to dive in at some
           later point
  florian: but even if it's an open question, can still decide if it
           starts in Grid 3 and split later or start later and merge
           later, but should put it somewhere
  <fremy> (votes for separate spec)

  dbaron: Also one other distinction here, worth thinking about
  dbaron: To what extent we want to put prototyping into formal spec
  dbaron: vs having documents about those things that are more
  dbaron: Some amount of formal spec language
  dbaron: but serve a different audience as part of trying to solicit
          feedback from people who might use the thing
  fantasai: I don't see why that needs to be a separate doc that's not
            adopted by the WG.
  fantasai: I think publishing a side explainer that's not official
            work of the working group.... seems like not part of
            official work of WG.
  iank: Gives impression to Web devs that they can give feedback
  dbaron: Just because it's an explainer doesn't mean it's not
          official working group work. It's in the repo
  fantasai: [said stuff that did not get captured, likely about
             how if publishing stuff officially is offputting
             feedback, that's a problem that should be addressed,
             not worked around by publishing stuff off-site]
  dbaron: Idea of explainers was to address that problem

  Rossen: Seem to be getting off topic
  astearns: Let's put aside how we work and where work happens, look
            at demo

  <jensimmons> demo: https://codepen.io/jensimmons/pen/QWjqbJj?editors=1100
  <jensimmons> display: grid;
  <jensimmons> grid-template-rows: masonry;
  <jensimmons> grid-template-columns: repeat(auto-fill, 20rem);
  jensimmons: Mats's design is elegant
  jensimmons: Shape of this layout can be accomplished in multicol,
              but the ordering cannot
  Rossen: this is awesome
  jensimmons: Responsive design style
  jensimmons: narrower it's 2 col, wider is 4 or 5 columns
  jensimmons: Content gets rearranged
  jensimmons: but always in masonry style layout
  jensimmons: One of the main reasons people keep doing this layout in
              JS is because of lazy-loading
  jensimmons: They want to load new content into the bottom
  jensimmons: using a proper masonry layout, first levels of content
              stay at the top, add to the bottom
  jensimmons: with multicol, everything gets rearranged each time you
              add content
  jensimmons: [shows code]
  jensimmons: This one is auto-fill columns of even size, but could
              make different-sized columns... anything you can do in
              Grid, can do in Masonry layout
  jensimmons: Fallback, if you open in current FF, has
              grid-template-rows: auto (default value), so everything
              lines up and just have extra space in the rows

  Rossen: Someone asked if only available for rows, suspect not
  jensimmons: Could define columns as masonry
  dholbert: Works in either axis
  jensimmons: What happens if you put in both axes
  dholbert: You can't, fails in one
  dholbert: Probably behaves as none

  AmeliaBR: Looking through explainer, thing that was new since last
            time I saw this is how this interacts with intrinsic sizing
  AmeliaBR: and way it suggests is to just use the 1st item that goes
            in each column as the one that decides the size of that
  AmeliaBR: which I guess is similar to fixed mode for table column
  AmeliaBR: but it's a little weird, unsure if there are other
            solutions for it
  heycam: You're right, hadn't thought about the analogy to fixed
          table layout
  heycam: The grid items you know for sure will be in particular
          column, they're the only ones you can rely on to size the
  heycam: can choose those that are placed in a particular column
  heycam: or ones which by automatic placement
  heycam: would go into a particular column
  heycam: which is true of the items in the first row
  heycam: Do agree it feels a bit odd, other items can't influence
  heycam: I think you can by forcing them to be in the top row with
          grid-placement properties maybe??
  heycam: not sure what else you could do apart from not allowing grid
          items to influence sizes

  AmeliaBR: Question for those who know grid layout better than I do,
            when we have regular auto layout with intrinsic rows
  AmeliaBR: How does that handle cycles
  fantasai: In grid layout, you have to do placement before you can do
            the sizing of the columns
  fantasai: because the sizing can depend on what's in it
  fantasai: Grid placement doesn't depend on the size of anything
  fantasai: You start putting things into slots, doesn't matter what
            the size of the item is
  fantasai: That's not true of masonry layout, which is where this
            rule is coming in
  fantasai: You need to know which column it's in to size it, but in
            order to size the column, you need to know what's in it
  fantasai: So the proposal is using the items that we know will be in
            a particular column
  fantasai: What we could do is do an initial sizing pass based on the
            items we know, with an explicit column or in top row
  fantasai: Then place all the items into appropriate columns, then
            run the grid sizing algorithm on all of the items to adjust
            the sizes but not re-place the items.
  fantasai: So later items would also influence the size of the
  fantasai: This could cause, depending on width -> height influences,
            could cause them to shift higher/lower in their columns.
  AmeliaBR: Way they approached it, seems simple as anything
  AmeliaBR: Most of the time this layout seems to be used with
            fixed-width cols
  florian: Also if we take fantasai's approach, probably want a switch
           it off, so that column heights can remain stable over time
           as you load comments.

  astearns: Comments on the proposal / demo?
  astearns: I agree with fantasai that this should be in an official
            document. We did resolve on doing that.
  astearns: Let's open a separate issue for that question
  astearns: Let's assume it goes into css-grid-3
  astearns: and have the issue have discussion for why that might not
            be the case
  astearns: and come back to this next week
  astearns: and decide if it goes into grid-3 or a separate module
  astearns: Put your arguments into the issue soon

  astearns: Thanks for explainer, do like having a more
            generally-accessible version of our documents
  astearns: I'm glad it's in our repo
  astearns: and thanks for demo, cool to see
  heycam: File specific issues on e.g. sizing
  astearns: Break up into subtopics will help, yes
  fantasai: I think we should be publishing our work, so we should
            also consider publishing the explainer either as a FPWD,
            or as a Note at some point.


[discussion about when to schedule more 4-hour blocks to soak up some
    of the excess agenda items]
[group would like to have more next week, details will be discussed on
    mailing list]

Backgrounds 4
  scribe: TabAtkins

  github: https://github.com/w3c/csswg-drafts/issues/4706

  AmeliaBR: This issue, and the next about background-opacity, are
            basically the same issue
  AmeliaBR: When you have layered backgrounds, sometimes you want to
            modify those backgrounds, or see one thru the other
  AmeliaBR: Like have a dark overlay over a texture image
  AmeliaBR: Or you want a slightly blurred image so it's not as
            distracting from the text over top
  AmeliaBR: Right now no way to do that
  AmeliaBR: Some things you can do with blend modes, but not a lot
  AmeliaBR: So today people have to instead put the bg on a
            pseudo-element and abspos it behind the element's content,
            and then use 'filter' on it
  AmeliaBR: Suggestion is to add more properties that describe
            filter-effects, or perhaps just a simple opacity.
  AmeliaBR: One thing that immediately is brought up is that we have a
            spec for this functionality - in filter effects, there's a
            filter() function that should take an image, apply filters
            to it
  AmeliaBR: So could say "background-image: filter(url(...)
  AmeliaBR: But no impl of that
  <faceless2> We implemented it yesterday!
  AmeliaBR: Don't know the reasons for that, if there are technical
            issues or just priority
  <fantasai> There's also https://drafts.fxtf.org/filter-effects-2/
             which has no FPWD or anything
  AmeliaBR: Other side, about separating to properties, that might be
            nicer from an authoring perspective to just reuse the
            existing bg model, rather than trying to squish everything
            into a property
  AmeliaBR: But need to talk about whether people will implement if
            specced in a different way

  smfr: We do have stable impl of filter() in webkit
  smfr: I like it because authors are used to filter property, this is
        a simple way to apply that in a different context
  smfr: And lets you do the classic thing of shipping one set of
        images and changing them on the fly with filters to do what
        you want
  smfr: Plus you can animate the filters
  smfr: So I like filter(), would like to hear from other implementors
  smfr: There's also a proposal to support the same filters for canvas
  smfr: So if they don't have it already, will need it soon anyway
  smfr: Also, filter() can be used anywhere, like border-image. If
        doing a background-* property, can't apply it to other image

  faceless2: One difference between background-filter and filter(),
             background-filter applies to all layers after merging,
             filter() is per-layer
  faceless2: Also when trying to blur image, filter doesn't apply
             beyond the bounds of the image
  faceless2: Not a problem if you have a single image covering the
             whole bg
  faceless2: But if you're tiling the image, you won't get the desired
  faceless2: So I think there's still a usecase for a whole-layer
  fantasai: Good point

  fantasai: There's a proposal for backdrop-filter property; it does
            something else entirely.
  <TabAtkins> It's not the background at all, actually
  smfr: backdrop-filter is different
  smfr: It renders what's behind the element, then filter it. *Then*
        the element itself, including its background, is composited
        atop it.

  fantasai: So there's still another case for compositing the bg
            layers together before filtering
  smfr: Yeah, definitely a difference there. Use-cases for both
  smfr: For backgrounds, if you're using colors you can use alpha.
  smfr: Would be curious to see use-cases for bg-filter that wants the
        whole bg at once
  smfr: And if doing it for bg, why not for border? So you can blur
        your borders? Feature-creep potential.
  fantasai: I think there are cases of people using bg to make a
            stretchable scene in several layers, and there you'd want
            to composite them together before applying opacity
  smfr: That's a good use case

  astearns: Any response to smfr's question about other impls of the
            filter() function?
  iank: Have to check with the team
  emilio: Seems like putting it in the image is the more flexible
          thing to do

  dbaron: Someone mentioned tiled bg images, and diff between blurring
          each tile vs the whole set
  dbaron: One control that's common here is what's off the edge
  dbaron: One option is the edge is transparent black, vs closest
          pixel, vs pretend you tiled
  dbaron: So with that control you could get the effect you wanted
  dbaron: Filter controls like that are generally applicable, worth
  AmeliaBR: That's called edgemode attribute on feGaussianBlur
  AmeliaBR: filter() is, as defined in spec, should magically choose
            edgemode based on tiling or not
  <smfr> “For the <blur()> function the edgeMode attribute on the
         feGaussianBlur element is set to duplicate. This produces
         more pleasant results on the edges of the filtered input
  AmeliaBR: If bg image is tiled, is does blurring smoothly.
  AmeliaBR: So for what is getting filtered, I think that's worth
            talking about, but if there's a concern, there are ways to
            address that concern.
  <TabAtkins> I can dust off the @filter rule proposal, dino expressed
              interest in it again a while back...

  AmeliaBR: Maybe there are use-cases for both "filter each layer" vs
            "filter layers together"
  AmeliaBR: But filter() function is def treating each image before

  AmeliaBR: Other question is why only bg?
  AmeliaBR: I brought this up as well. If we did it as a separate
            property, all the other similar groups would want a
            matching prop, so could add a bunch of properties.
  AmeliaBR: fill-image-filter, border-image-filter, etc

  faceless2: Re: compositing borders together, table borders would
             make me cry...
  faceless2: And table bgs are stacked up as well, phew

  heycam: I think it's not just an issue with tiling; agree we need
          something to fix that.
  heycam: Also stretching - before or after filter() could affect
  <TabAtkins> Yeah, blur() would act differently if applied before or
              after stretching.

  AmeliaBR: So, we have filter() in the spec. There are clear
  AmeliaBR: Do we feel that, from an authoring or impl standpoint,
            filter() isn't good enough and we need to look at new
            options? Or is it good enough, we close this no-change,
            and continue working on filter()
  fantasai: I think this addresses a number of the cases.
  fantasai: But think it doesn't address "I want opacity on entire bg
            at once, but not on the text", which is a common use

  TabAtkins: One of the things suggested there was a ::background
  TabAtkins: if you could put filter on that, could achieve that case
             at least syntactically it's easy
  astearns: Would end up with a lot of pseudos for each thing you
            might want to filter...
  astearns: Then you run into "well if you do it for bgs, why not
            borders, etc"
  TabAtkins: Well, so far it seems that filter per layer shouldn't be
             handled by separate properties
  TabAtkins: Pursue filter() function as preferred method for that
  astearns: Do we leave background-filter issue open to deal with the
            background-all-at-once case?
  AmeliaBR: I think we should see more use of filter() before we say
            that use case isn't addressed
  AmeliaBR: Think we need wider use of the filter() before we can
            conclude we need to address more use-cases
  astearns: So we can do that - close these as no-change and use
            filter() function
  astearns: Objections?

  RESOLVED: Close #4736 and #4715 as no-change; filter() is what's
            intended to solve these cases.

Foldable & dual-screen devices
  scribe: AmeliaBR
  github: https://github.com/w3c/csswg-drafts/issues/4736
  explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Foldables/explainer.md

  dlibby: A few months ago, we wrote up initial thinking on this
          project space. Specifically, foldables with 2 identical
          screens. We've had a lot of feedback, a lot about more
          exotic form factors or possible application to desktop
  dlibby: (shares slides from explainer) This was the proposal, a new
          media feature, screen-spanning, with value describing
          direction, and then environment variables for the dimensions.
  dlibby: We went back to the drawing board based on feedback. Some
          detailed comments about how this interacts with bezels and
          so on, and how can we make it extensible to multiple dividers
          /folds in different directions. So need more complex
          environmental variables.

  fantasai: This slide shows 4 panes, but 3 in the media query. Is
            that correct?
  dlibby: Yes, though that's open for debate. We're counting the
          number of folds/divisions, not panes.
  dlibby: For the environment variable, that means we then have an
          array-like structure, needs a way to access the nth value.
          Can't use comma, because that's the fallback. One
          possibility is a nested function.
  fantasai: Or could just use a space separated `env(divider-left 3,
  <fremy> @dlibby: also, why not just divider-left-1, divider-left-2,

  dlibby: We then can start looking at more complicated cases (3 by 2
          panes in example). Should there be different names to access
          horizontal vs vertical, top vs left. Getting a little
          overwhelming in complexity. Wanted feedback from WG about
          whether there is a more generic way to describe this.

  smfr: I don't really have a mental model of how content is supposed
        to interact with the different screens. Can you pinch zoom on
        one screen, or would that zoom the whole display? Or
        scrolling, doesn't the divider line move relative to the
  dlibby: Our proposal was based on defining things in the “client”
          coordinate system, doesn't change by scrolling. Zooming,
          haven't looked at that. Depends on a pinch or layout zoom,
          whether it changes the geometry in CSS px.
  fantasai: Generally, we say pinch zoom shouldn't change geometry,
            don't re-compute layout. But layout zoom would require
            computing everything.

  fantasai: On the slide, you're calling this 1,2,3,4 dividers for the
            top row and then the bottom row. That's really confusing
            to number in this wrapping fashion. I'd try to name more
            like grid dividers, assuming continuous columns, maybe
            taking the widest gap if they're not all the same.
  plinss: I agree that number seems weird, but in multi-monitors,
          they're not necessarily be in a grid layout. We can't assume
          something simple if we want to include that.
  florian: And desktop screens are often different sizes.
  plinss: And that will probably be true in future for foldable mobile
  dlibby: Yes, we're trying to define in a generic way that doesn't
          make geometry assumptions.
  fantasai: But at a certain point, what are the chances that you're
            going to make a design for inconsistent sizes of panels
            arranged arbitrarily in space? Can we start with a simple
            assumption of a grid-like layout. The original proposal
            was for just a single fold.
  plinss: But we should at least consider whether more complex is
  fantasai: So long as simple cases stay simple.
  dlibby: Agree with that. Kind of hard at this point in time to
          imagine all application use cases and all devices in the
  <fantasai> extending to multi-fold from single fold wasn't hard, so
             worth doing; extending to arbitrary geometry in space,
             it's harder, so I wouldn't be opposed if there was a
             proposal that handle complex cases but still kept simple
             cases simple, but don't want us to get stuck on trying to
             solve arbitrary geometry and make simple cases hard or
             impossible for the next 5 yrs

  astearns: Like with custom origins and masonry, it would be helpful
            if specific questions are split out into separate issues.
            Right now we have a giant discussion. As these questions
            come up, please make separate issues.
  dlibby: Agreed. Main goal for this f2f is to ensure we're on the
          right track.

  astearns: On that note, any other concerns that came up from the
  florian: I'm slightly concerned about how this media query will be
           used & is it the best approach to the problem. E.g., can
           you make your grid just nicely snap to the folds, without
           needing to calculate all the environment variables,
           margins, and so on of ancestors and previous siblings and
  <fantasai> +1 to florian, that's important consideration
  Rossen: Snapping to the gaps is definite a use case, but we have so
          many different layout contexts, and we already have ways to
          make those sizings. Yes it uses calc. But if tomorrow we
          change grid, we don't want to need to retrofit a lot of
          magic. Trying to keep it simple rather than baking in
          interactions with all layout models.
  fantasai: I do think that florian's point is really important. We
            don't want people to need to calculate many layers of
            margin and padding to figure out where they are on the
  Rossen: I disagree.
  dlibby: There's certainly things we can look at, but I do think this
          proposal covers the basic primitives to start to get
          developers exploring things. Integrating with special layout
          modes could be revisited.

  <tantek> Curious about relation to "multi screen" work if any
  <tantek> In particular I'm curious about possible overlap with
           https://www.w3.org/2014/secondscreen/ specs and thoughts

  fantasai: One thing to look at might be re-using fragmentation module
            to avoid breaks. That's what fragmentation is designed to
  astearns: Most examples I've seen treat different screens
            differently, two or more separate layouts. Not fragmenting
            content across screens.
  Rossen: And fragmentation is one-dimensional.

  astearns: We have dave & Mike on the call, can we talk string-set()?
  bremford: Let's push that back.

  [scheduling discussion for possible long call next week]
Received on Friday, 15 May 2020 22:39:58 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:14 UTC