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

[CSSWG] Minutes Virtual F2F 2020-04-29 Part I: Container Queries, CSS Multicol [css-multicol]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 12 May 2020 19:05:55 -0400
Message-ID: <CADhPm3uqKyjW-LqDKEo16d-QTaAASxkk749etQGZNq8EDxMnpw@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.

Container Queries

  - There were two proposals presented to tackle container queries:
      - From bkardell a switch() function:
      - From dbaron an @container query:
  - The group encourages both proposals to continue exploring and
      detailing out motivations behind the solutions.
  - There were concerns with both proposals, but especially the
      @container query, creating circularities. dbaron will look
      deeper into the problem for 1-D containment.
  - The @container rule seemed like it would be more intuitive for
      authors. There's a definite need to ensure that the model chosen
      works well for authors so it's important to work through
      usability before shipping.

CSS Multicol

  - RESOLVED: Balance before spanners always (Issue #4689: Defining
              what happens with column-fill in unconstrained
              containers for continuous and fragmented contexts)


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

  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Dave Cramer, Hachette Livre
  Elika J. Etemad, Invited Expert
  Rob Flack, Google
  Simon Fraser, Apple
  Chris Harrelson, Google
  Daniel Holbert, Mozilla
  Koji Ishii, Google
  Brian Kardell, Igalia
  Brad Kemper, Invited Expert
  Jonathan Kew, Mozilla
  Rune Lillesveen, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Theresa O'Connor, Apple
  François REMY, Invited Expert
  Manuel Rego, Igalia
  Florian Rivoal, Invited Expert
  Cassondra Roberts, Red Hat
  Anders Ruud, Google
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Fuqiao Xue, W3C

Scribe: flackr

Container Queries

  <astearns> https://gist.github.com/bkardell/e5d702b15c7bcf2de2d60b80b916e53c
  bkardell: There have been various proposals in the past. They haven't
            accounted for how CSS works in many cases.
  bkardell: CSS seems magical, you can express things in conflict and
            CSS will sort them out.
  bkardell: A lot of the proposals mix up phases, selector matching
            after the fact, etc.
  bkardell: Based on Matthew's ideas, in conversation with CSSWG
            members, we decided to start with the core architecture
  bkardell: Idea is a switch() function. It's relatively simple:
            properties can expose context variables that can provide
            multiple answers to a question
  bkardell: e.g. grid-template-columns can expose available inline
            size and, at the right time, use it to figure out which
            answer fits
  bkardell: Internally it doesn't need to go back and do selector
            matching / recompute the world.

  bkardell: Idea is to lay down internal pathways, not a solution in
            itself to container queries, but will solve a lot of use
            cases with little effort.
  bkardell: This proposal is related to calc() (which we have) and
            toggle() (which we don't). This could be used to handle the
            toggle() use cases so we may not need it if we have
  bkardell: Other places it could fit, examples in toggle() where you
            want to alternate between emphasized and non-emphasized
  bkardell: and alignment based on ??
  bkardell: dbaron will present notes. These are first lower level
            steps that should be valuable
  bkardell: Want to be clear that we're exploring both higher level
            and lower level because they're both good
  bkardell: Igalia is doing some small investments in trying this with
            inline available size and grid template columns to gain
            implementation experience
  bkardell: no specific timelines or ETAs though

  florian: There's two fundamental problems. Circularities: if you
           switch into the different layout then that can create
           infinite loops.
  florian: Other is wanting to do selectors after you've done layout
  florian: This mostly affects the two step selector after layout
           where you provide both answers ahead of time.
  florian: AFAICT this does not address the circularity problem, but
           that can be addressed with containment.
  florian: With containment we solved looping, but to make container
           queries based on containment, you'd have to run selectors
           after containment.
  iank: Few different options during intrinsic sizing phase. One is
  iank: Other is to think about it how percentage margins are handled.
  iank: During intrinsic sizes percentage margins are unknown. We can
        evaluate the switch() in the default case which provides an
        answer but may not always be correct.
  bkardell: Also worth noting, part of it is improving containment
            because it doesn't currently solve some of the cases

  <dbaron> https://github.com/dbaron/container-queries-implementability
  dbaron: I've been working on another proposal in this space ^,
          basically been thinking about what we can do to build the
          thing that developers are asking for
  dbaron: Florian's right, we need to somehow tie this to containment.
          The thing I've wanted to build is an @container rule (naming
          tbd) that takes selector and media query and has CSS rules
          inside which apply to descendants that match the selector.
  dbaron: Then you figure out what you need to solve looping problems.
          Containment is extremely useful for this except it doesn't
          actually do the thing we want.
  dbaron: 'contain: size' has the issue that you need to give the size
          in both dimensions. Developers often want an input size and
          an output size, e.g. a width comes from environment, do
          container queries based on width, but you want auto height.
  dbaron: Containment today doesn't do this.
  <fremy> +1 to what David just said. Most people want that indeed
          (contain: width for container queries).

  dbaron: One of the pieces to this is describing how containment
          would work in 1 dimension
  dbaron: This is complicated from a specification point of view, but
          not significantly more complicated than containment as it is
          today from an impl point of view
  dbaron: right now containment is specified that you do layout as if
          the element has no children. When implementing that you have
          to dig into each layout algo for each display type, and look
          at the types where it does things based on children and
          check containment before that.
  dbaron: Specifying how containment works when we want containment in
          1 dimension and not the other requires that we work through
          specifying that for the various layout effects.
  dbaron: If you do containment in one dimension, and do containment
          in the other dimension, it should be equivalent to
          containment today
  dbaron: The other thing is it must do containment, i.e. if you
          contain in 1-d then the contents better not influence the
  dbaron: Beyond those two constraints, the layout should be as
          similar as possible as what you get with layout without
          containment in the other dimension.
  dbaron: This is not required but a thing we'd like to satisfy as
          much as possible.

  dbaron: Given that, if you have 1-d containment, what does it take
          to do a thing with an @container rule
  dbaron: From an impl perspective, you end up with a bit of impl
          complexity, but not a huge amount. The changes are at a
          relatively high level.
  dbaron: With the idea that if you want to run this sort of thing,
          you want to finish layout down to the element with the
          container query
  dbaron: and then go back and do a later styling and layout pass to
          finish things up
  dbaron: so you have to alternate between style and layout
  dbaron: This has a performance cost, but that cost is lower than
          simulating something like this with resize observer
  dbaron: With resize observer, you go back and do style and layout
          many times, but you have to do the whole tree.
  bkardell: And multiple passes through event loop

  dbaron: Proposal has more details.

  dbaron: One other thing we should consider, if we have @container,
          it should also be tied to concept of scope in CSS cascading.
  dbaron: Making rules that are a higher priority than other rules
          with that hook we have in cascading algorithm
  dbaron: I think it's worth considering, not necessarily required

  Rossen: Anyone going to go over third proposal?
  bkardell: I mentioned it, what florian, dbaron and I said are the
            troubles with that proposal
  bkardell: That one ends up potentially having to go back through
            selector matching, though it seems many of the higher
            level mitigations dbaron is doing could probably be done
            with similar twiddling with internals

  florian: My intuition with how container queries might work is
           similar to dbaron's. What convinced me it wouldn't work
           is that I don't think 1-d containment can work.
  florian: With a simple example, if you grow in height you may
           eventually overflow container, get a scrollbar, and
           influence width.
  florian: And there will be other similar cases like this. It didn't
           seem like there were obvious solutions to these problems
  florian: Do you have answers to that?
  dbaron: Need to think about that more.

  emilio: One slightly problematic thing. It makes simple stuff like
          getting computed value of property which mostly doesn't
          require layout now require layout. This may be an impl
          problem we can get around when container queries aren't in
  dbaron: I think that's true of both proposals
  emilio: It depends on what the computed value of the switch() would
          be, may not require resolving it.
  emilio: If you treat it like min() and max() or percentages, where
          computed value is min/max/percentage you don't need to run
  dbaron: But you still need to if you want to do something based on
          that value.
  emilio: Yes. I think the output of computed style with your proposal
          is much more usable, but also more expensive.
  emilio: I think it can be mitigated in impl I suspect.

  fremy: dbaron you said implementing this has minimal impact on how
         browsers do styling. I think this is possible but what is
         impact on style invalidation? Right now there's a lot of work
         on what to invalidate when e.g. you switch a class.
  fremy: When you have selectors depending on the size of objects ,I
         think, it becomes much more complicated to determine which
         selectors apply after a change.
  fremy: I think you may need smarter invalidation, or to keep track
         of these things in some way. This is one problem I could
  fremy: As for Florian's remark, I think this is valid, e.g. height
         dependent on width. But with more restrictions this may be
  fremy: e.g. maybe you always get scrollbar or don't get any scrollbar

  fremy: I quite like the switch() proposal in general. Fiddling with
         it it seems quite attractive.
  fremy: With emilio's computed style proposal, you don't know which
         value you'll get from computed style.
  emilio: I was assuming it would be layout time resolution.
  iank: Right
  fremy: But let's say you change color of text to blue based on
         something, and that inherits.
  emilio: Resolves to different things during layout.
  fremy: I think this is something we need to talk about..
  emilio: Maybe this is issue with proposal itself, you can't isolate
          a single value.
  iank: Definitely an issue with the switch() proposal, inheriting.

  iank: dbaron, the @container applies only to descendants and not
  dbaron: Yes, that's right
  iank: It might be confusing for web developers because typically
        people want to change something about box itself based on
        width, e.g. grid template columns
  iank: There's tweaks we could do to size containment to get this to
        work correctly. We could get it to work on itself if you limit
        the properties it applies to.
  iank: If you cut out sizing properties and display you could get a
        lot to work.
  dbaron: That seems reasonable
  iank: I'm not sure about complexity of scoping various properties,
        but not allowing switching flex direction or grid template is
        fairly limiting.
  iank: Imposing that means you don't have to answer a lot of
        difficult questions.

  fantasai: About dbaron's comment on cascade, if we make scoping
            available to container queries that same mechanism should
            be available for normal rules.
  dbaron: Current proposal does this by making media query part of the
          rule optional.
  dbaron: You don't have to provide media query at all.

  iank: I agree with dbaron that implementing 1-d size containment is
        relatively trivial from an implementation perspective.

  chrishtr: It sounds like 1-d size containment is considered
            important no matter which alternative is chosen. I'm not
            sure if it has independent value - haven't thought about
  chrishtr: Perhaps this should be worked out independently of
            choosing anything around container query solutions?
  bkardell: That was my statement as well.
  chrishtr: I was looking at some of the issues and it seemed to still
            be left open whether it was circular.

  chrishtr: Second question: in the limit are these two proposals
            the same or not?
  bkardell: I think in many ways dbaron's is many proposals. At the
            low level there are necessary steps, containment which is
            valuable regardless.
  bkardell: Our low level fundamental thing has to do with fitting a
            new function with context awareness into the system.
  bkardell: We want a higher level thing whether that's an @rule or
            pseudo class, etc.
  bkardell: Comparing them is hard. Anything you could do with one is
            hard to measure at this stage.
  iank: Broadly agree with bkardell, dbaron's proposal is more
        expressive, you can do more things.
  iank: but there's a tradeoff in performance characteristics. I'm
        curious to see how powerful people find this.
  chrishtr: So e.g. you'd be able to change styles on descendant with
  iank: No, switch() can't do that, it's just context for that element.
  chrishtr: So switch() is only for that element, dbaron's is only for
  bkardell: In the issue, we suggested changing the current context so
            it's not about your parent but your current parent value.
  fremy: Not entirely true, you can have custom properties which
         inherit to the children.
  dbaron: Only if they're computed in computed values which people are
          saying they're not.
  fremy: True.
  Rossen: Let's go through queue and figure out next steps.

  emilio: Why is switch() a different function and not a specific value
          inside calc()?
  emilio: Seems this would be a more natural way to implement it /
          more flexible.
  <TabAtkins> ?? I'm not sure what that would mean, switch() is a much
              wider idea than just numeric stuff.
  <bkardell> emilio, can you maybe share some pseudo-code?
  <emilio> bkardell, it'd need some sugar to implement simple ifs in
           calc() I guess, but you can get around with `min` / `max`,
           so something like `max(min(available-inline-size - 100px,
           0px) + 1px, 0px) * 100` or such
  <emilio> bkardell, There was a separate proposal for an `if(
           condition, <true>, <false>)` function inside `calc()`
  <emilio> bkardell, seems like `switch()` is basically that, plus the
           new `available-inline-size` value

  jensimmons: I'm glad we're pursuing seriously several ideas how to
              do this. From an author's POV, I think @container rule
              is much more what authors are expecting. I think people
              will want to define a component and say if the size is X
              then use this layout, otherwise other layout.
  jensimmons: A switch() statement would require authors to parse
              different parts of layout and put different statements
              on each item in that card in that component.
  jensimmons: Reminds me a lot of responsive images, which industry
              was very excited to have, but people are struggling to
              understand it / use it on their site because it's hard
              to know what syntax to write where.
  jensimmons: Not because syntax is complicated, but mental model is
              complicated with that tool.
  <fremy> (nodding to what jensimmons just said)
  jensimmons: The media query allows you to think about it differently
              than responsive image syntax, it's much easier.
  jensimmons: Don't know yet what's possible, just throwing in 2c.
  <myles> jensimmons said pretty much exactly what I was going to say

  bkardell: Nobody wants to stop at switch(), we shouldn't be comparing
            @rule and container query.
  bkardell: We want to work out the internals and how we get there and
            what abilities that gives us along the way.
  bkardell: What's attractive about switch() is that it's relatively
            small and finite and mostly in the right place in existing
  bkardell: I think we could get this done quickly and then move
            beyond that to a higher level thing like a media query /
  bkardell: dbaron has done more trying to drill down but we're
            basically approaching the low level problem from other end

  jensimmons: I'd love to figure this out and have a bigger long term
              plan, being more ambitious about long term plan.
  jensimmons: It might be nice / tempting to ship something quickly
              that's maybe not ideal, but the problem is author
              community will not pick this up e.g. grid vs flex.
  jensimmons: There's a cost to shipping tools which aren't ideal
  <castastrophe> +1 jensimmons
  <castastrophe> Great points
  jensimmons: We may end up stuck with this.

  * rachelandrew could help write up some examples that would be
                 understandable for authors to imagine how they might
                 use these, in order to get feedback.

  futhark: Connecting this with scoped styling is a good idea. One
           thing is authors in frameworks also want scoped styling.
  futhark: It's also connected to components and invalidations with
           scoped styling for them.

  dbaron: I wanted to comment about switch() proposal, piece I'm most
          concerned about is complexity of the context properties
  dbaron: One of the pieces at the core is defining a set of context
          values for each property. The idea is that they'd be
          different for each property.
  dbaron: This would be a thing that we roll out separately by adding
          support for each property or sets of properties / new
          context values.
  dbaron: There's two things about this: there's a bunch of spec
          development / browser dev that goes into adding each thing,
          and it seems there's a good bit of complexity in
  dbaron: i.e. is the width auto? It's no longer at the implementation
          level where you provide the element. You need to make sure
          you have all of context properties for the things switch is
          conditioned on.

  florian: Still not clear why switch doesn't have loops or
           circularities. I'd like to see more information about how
           this works.
  florian: i.e. the weakness I see in 1-d containment seems to be
           there as well.
  florian: There's a lot of inherent circularities in layout but this
           stuff is still size related.
  florian: Please write more about the model.

  <dbaron> btw, I'm not that worried about fremy's invalidation
           question; I think underneath there would just have to be
           sequences of one thing invalidating another (which wouldn't
           be any more inefficient than usual, since it's a multi-pass
           thing anyway).

  <fremy> florian, my guess for your question, is that switch() isn't
          a guarantee of correctness
  <florian> fremy, I'm not so much concerned about correctness (
            although that's a concern too), but more about stability.
            If the answer becomes different when you run the
            calculation twice, then it's going to be a mess.
  <fremy> florian, I don't think that would be a concern, except if
          the browser had a bug in the first place
  <florian> fremy, possible, but that's why I want a better
            understanding of the model, so that I try to write
            specific examples that might break it and see if they
            actually do

  Rossen: I'm hearing quite a bit of support to continue to invest in
          exploring solutions and defining a sensible model that cuts
          down on circularity.
  Rossen: I think jensimmons overall reminder about the big picture is
          an absolute must.
  <castastrophe> +1 container queries will reduce so much ugly JS
  <jensimmons> +1000 for exploring these!
  <leaverou> +Number.MAX_VALUE for exploring container queries!
             Authors will be elated

  Rossen: dbaron, anything you're looking for from WG?
  bkardell: A sanity check, this was a useful discussion. We've had
            numerous discussions to make sure there's no reason we
            would not consider these.
  bkardell: As long as CSSWG is amenable to exploring these, Igalia is
            still hacking around seeing what we can do
  bkardell: We think containment in a single direction is the next
            logical step and valuable on its own.
  bkardell: Discussing the higher level thing is valuable, but those
            are the immediate next steps I think.
  dbaron: Yes, I think the biggest thing I was looking for is
          feedback. I'm concerned about the point Florian raised and
          need to think about it. This was a piece I'd forgotten about.

  dbaron: I'm less convinced that containment in a single direction is
          useful on its own. If someone has particular things it would
          be useful for I'd love to hear them
  bkardell: We did a lot outreach, some of their excitement about
            resizeobserver was muted because you can't do containment
            in a single direction
  bkardell: It is entirely possible to create non-runaway (in css
            engine) runaway cases

  chrishtr: bkardell did you record use cases?
  bkardell: We have a lot of notes
  bkardell: Need to be published

  Rossen: Let's try to end
  Rossen: Thanks dbaron and bkardell. As chrishtr pointed out it would
          be useful to summarize the motivational use cases in one
          place to allow others to continue to engage
  bkardell: Fast note, in these discussions it's worth pointing out
            community has come up with a similar solution. Martin
            Auswöger is doing this (
https://au.si/css-conditions-cq-alternative ).
            There are patterns in use in the wild doing thing with
            calc and clever bits to do things like switch() idea for
            what that's worth.

<br length=5 />

Scribe: fantasai

column-fill in unconstrained containers: continuous vs fragmented
  github https://github.com/w3c/csswg-drafts/issues/4689

  rachelandrew: Leftover issue, last one still open on multicol
  rachelandrew: Last F2F resolved we want to go with behavior that
                Firefox has wrt column-fill
  rachelandrew: and falling out of that, spec text doesn't say
                anything about spanners, should we always balance
                before spanners
  rachelandrew: Clarification was that where firefox is putting
                everything in one column, need to clarify if that
                happens before spanner or not
  rachelandrew: Does that trump column-fill ?

  fantasai: We should be balancing between spanners... pretty sure
            that was our original intention.
  rachelandrew: Can't think of a use case for not balancing before a
  florian: Further clarification, should balance from start of current
  florian: Previous fragmentainers are independent of that.

  dbaron: I think I agree that balancing before spanner is the right
  dbaron: Brings up question of whether current balancing control is
          the right thing.
  dbaron: Do you balance at end, before fragment break, before
          spanner... three things.
  dbaron: Do we need more controls? or do people don't really care so
          much about the others
  dbaron: Balance before spanner seems fine.

  Rossen: +1 I think that's what we did in our EdgeHTML implementation
          of multicol

  Rossen: Can we resolve?
  Rossen: Any objections?

  RESOLVED: Balance before spanners always
Received on Tuesday, 12 May 2020 23:06:39 UTC

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