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

[CSSWG] Virtual F2F 2021-02-11 Part I: CSS Contain [css-contain]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Feb 2021 19:29:24 -0500
Message-ID: <CADhPm3v6J4NwzMrWRNy2M+xs4PmmVb4RCmHf7VXCSRAHZUmG+Q@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 Contain

  - Conversation after the last meeting lead to a new proposal for
      the use case behind the content-visibility: hidden-matchable
      proposal (Issue #5595: content-visibility: hidden-matchable).
      This proposal is for a new HTML attribute so discussion will
      move the WHATWG.
  - miriam presented the proposed solution to add container queries
      (Issue #5796: Fleshing out @container queries with single-axis
      containment). The proposal was well received and the group asked
      some clarification questions about use cases and planned
  - RESOLVED: Define container queries in css-contain-3, editors L2
              editors + Miriam (Issue #5796)


Agenda: https://github.com/w3c/csswg-drafts/projects/14

  Adam Argyle
  Joey Arhar
  Rossen Atanassov
  Tab Atkins-Bittner
  Mike Bremford
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos
  Elika Etemad
  Javier Fernandez
  Brandon Ferrua
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Sanket Joshi
  Brian Kardell
  Jonathon Kew
  Una Kravets
  Daniel Libby
  Chris Lilley
  Peter Linss
  Alison Maher
  Myles Maxfield
  François Remy
  Florian Rivoal
  Cassondra Roberts
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Scribe: fantasai
Scribe's scribe: TabAtkins

CSS Contain

content-visibility: hidden-matchable
  github: https://github.com/w3c/csswg-drafts/issues/5595

  Rossen: Lively discussion last time, continued for awhile afterwards
  Rossen: Reopening topic only to call for objections to adding this
          to our charter

  chrishtr: What I suggest is we do a short update
  chrishtr: We discussed a version that was CSS property with events
  chrishtr: various objections in the issue
  chrishtr: After meeting, fantasai met with people and drafted a
  chrishtr: and the proposal was to add an attribute that says "look
            inside this subtree for matches"
  chrishtr: attribute wouldn't imply any particular visual behavior
  chrishtr: When things found, event fired, and also remove attribute
            from element
  chrishtr: allows writing attribute selectors, which in most use
            cases, allows dev to show content without script
  chrishtr: which is something CSS version couldn't do
  fantasai: Not sure the attribute wouldn't imply visual behavior
  fantasai: But probably there should be a default
  fantasai: Whether it uses content-visibility:hidden or display:none
            is an interesting question
  fantasai: But by default it should hide things one way or another
  fantasai: Just putting the attribute would allow the mechanism to
            work even if the author does nothing else, but author
            could customize
  florian: I think discussion shows that the topic has potential,
           use-case is important
  florian: I'm not voting for any particular version of it to be put
           in a spec just yet, but should keep going on topic

  chrishtr: I suggest we phrase the charter as adding an HTML
            attribute for hidden content that should be searched
  hober: Shouldn't that go to HTML not us?
  Rossen: Did we decide not to use that property at all?
  chrishtr: Under this proposal, would use attribute to signal
  Rossen: So searchability and discovery capabilities of DOM content
          would be deferred to HTML proposal as an attribute
  Rossen: and would pursue that in WHATWG
  Rossen: and for us pursue what happens in CSS
  chrishtr: Default styling yeah
  Rossen: So we add content-visibility:hidden to charter?
  hober: No charter changes necessary

  florian: I think we need a bit more discussion here in CSSWG before
           we pass to WHATWG
  myles: We have a pretty clear path forward here that doesn't involve
         a new CSS value, so don't think keeping discussion in CSS
         makes sense
  Rossen: If not adding anything to CSS, let's not discuss

Fleshing out @container queries with single-axis containment
  github: https://github.com/w3c/csswg-drafts/issues/5796
  slides: https://lists.w3.org/Archives/Public/www-archive/2021Feb/att-0002/Container_Queries_Proposal_-_vF2F_2021-02-09.pdf

  [ Miriam presents ]
  miriam: Each card is responding to its own container, regardless
          of window size
  miriam: so to make that work, have to describe container itself
  miriam: to establish containers in this proposal
  miriam: What's required is having size and layout containment
  miriam: by applying size and layout containment, we can establish
          them as containment contexts
  miriam: A bit of a problem here also noted by dbaron
  miriam: size containment is very invasive
  miriam: if always have to explicitly set height and width, doesn't
          work for many use case [which need auto content-based height]
  miriam: need 1D containment
  miriam: Chrome developing prototype to prove that can work for
          inline axis
  miriam: for block axis, a bit more complicated
  miriam: If that doesn't work, then width/height can't be made to
          work because can be either inline or block
  miriam: most essential however is inline-size

  miriam: dbaron's syntax looks like this:
          @container <selector> (<query>) { <rules> }
  miriam: If we have to be explicit about which containers we're
          looking at, less flexible
  miriam: Really what we want is to say h2 or card can respond to
          whatever container it's in, and wherever we put it can
  miriam: modular that way
  miriam: Proposal is to remove the selector block
  miriam: just describe the query, not the container that it will
          match against
  miriam: and instead we use the DOM tree to find the container that
          we're in
  miriam: so each card looks up its ancestors to the first container
          that has the limits we're querying
  miriam: code example [slide]
          @container (min-width: 40ch) { ... change grid template ... }
  miriam: That would work in any container

  miriam: h2 is good example of why this needs to be very modular
  miriam: Might want to use h2 in any container, not defining
          specifically how one component work
  miriam: tree can be nested however
  miriam: If both are h2, they each look up their nearest ancestor
          container and respond to size of that container
  [shows tree]
  miriam: Rules in @container apply when ancestor with appropriate
          containment, and query applies

  miriam: query against actual values on element, not the viewport,
          can look at e.g. actual font size of the element
  miriam: Could we have queries that respond to font size on container
          / element?
  miriam: Containment is external
  miriam: so can't query e.g. size available to you in a grid track,
          always querying the element itself
  miriam: That's one place where the switch proposal would be a bit
          more powerful
  miriam: but this is also something we can work around by adding an
          intermediate wrapper
  miriam: Add an element that's a container as the grid item, put the
          card inside

  miriam: Some talk of alternate syntax based on pseudo-class
  miriam: :container(query)
  miriam: Some downsides and some positives
  miriam: Adding in nesting, becomes quite similar
  miriam: This provides a few use cases that the @container wouldn't

  miriam: A lot of other open questions
  miriam: some of them already have issues, some don't
  miriam: We can dig into any of that later
  miriam: [links to explainer, issue, TAG review]
  <astearns> https://github.com/oddbird/css-sandbox/blob/main/src/rwd/query/explainer.md
  <astearns> tag review: https://github.com/w3ctag/design-reviews/issues/592
  <myles> miriam that was very helpful, thank you!!!

  bkardell: I think this is great
  bkardell: Question when presenting, are there known use cases for
            block direction?
  miriam: Think would be similar to viewport height use cases
  miriam: Those are rare
  bkardell: I found use cases for thing you're doing first, easier
            part with very strict containment
  bkardell: plenty for inline-axis
  bkardell: much more than I thought there were initially
  bkardell: I actually agree with you that nesting is super-important
            to work out for a whole bunch of things
  bkardell: We're making a lot of choices differently; nesting is big
            deal, one of the biggest things we could work on
  bkardell: would like us to prioritize
  bkardell: Also want to express that this is awesome, and would love
            to coordinate some more between Igalia and Google who are
            doing this work
  bkardell: to make alignments
  bkardell: Some similarities in internals that would be good to sort
  bkardell: Some opportunities to sugar things as well

  fremy: Very good proposal, like the feel of it
  fremy: I am wondering if makes sense to say that everything
         containing something becomes a container
  fremy: Sometimes you need containment just for performance reasons,
         be weird if that also changes layout / changes what container
         is being queried
  fremy: maybe add a new value to get queries?

  fremy: Something that you can do with this that can't be done
  fremy: can use these containers to set display:none to things
  fremy: which would change counters etc.
  fremy: Maybe we need a bit more containment that just size?

  fremy: Unsure also about how easy to implement
  miriam: Anders and Rune have been working on that, idk if they're

  fremy: Globally I like the idea, if I make one change to proposal,
         if we don't use selectors about what is a container, then
         need to have an explicit way to indicate which is a container
  miriam: Solution you mentioned, of explicit value for contain, that
          would address the issues you raised
  chrishtr: Was this about counters?
  miriam: Potential of accidentally creating a container somewhere
  miriam: I haven't found use cases where you want to skip a
          containment box
  miriam: but being more explicit can be handled by a specific value
  miriam: Also way it relates to counters, might need style containment
  miriam: Bulky if contain: inline-size layout style
  miriam: maybe can all be combined into the explicit value
  fremy: Exactly what I had in mind

  leaverou: I wanted to say, 2 syntaxes proposed at-rule vs
  leaverou: Is pseudo-class actually doable?
  leaverou: They match at an earlier stage, can't match at computed
            value time
  TabAtkins: Generally speaking yes
  TabAtkins: Theoretically don't need to if there's not a computation
  TabAtkins: Could do another pass later, but usually want to avoid
  leaverou: Thought significant pushback against 2 passes
  florian: But in this case we need it anyway
  leaverou: If both fair game, I think pseudo-class syntax allows
            combining with other selector criteria if both doable
  <fremy> btw, this won't require just two pass, it would require one
          pass per element, but each pass might require a layout pass
          in between

  argyle: So many fun use cases, breakdown so good
  argyle: One of the differences between switch and container syntax
  argyle: question of what am I targeting
  argyle: Switch can know its own size
  argyle: that's an important use case
  argyle: Container might have 20 items in it, what's the space I'm
  argyle: Not sure how to wrestle with those thoughts
  argyle: Pseudo-class selector might be opportunity to specify which
  argyle: What if want immediate parent?
  <una> +1 to the individual container
  miriam: Wouldn't be immediate parent, would be nearest contained
  argyle: What if you want container a few steps up?
  miriam: Question has come up, but haven't come up with any use cases
          for it
  miriam: With regards to switch, agree, that's why these are parallel
  miriam: With switch(), element queries itself, but is limited in how
          much can be changed
  miriam: can't change width based on width
  miriam: limited properties, but querying actual self space
  miriam: but with this one querying something external, but can
          change anything inside it
  miriam: Addresses different use cases with a bit of overlap, both
          worth pursuing

  fremy: With regards to leaverou's multiple passes
  fremy: You don't need to have multiple passes
  fremy: need one pass for element
  fremy: but need to do layout
  fremy: You only need to layout outside the container in one pass,
         and inside in the second pass, so it's not really two passes
  fremy: One case I feel a big issue
  fremy: proposal of containing only in one dimension
  fremy: That's the only case you have to do layout and then styling
         inside container
  fremy: then have to do layout of everything again
  fremy: That could change size of container
  fremy: That one is much more tricky, and could do layout many times
  fremy: multiplied by nesting of containers
  fremy: Bigger problem, not easy to solve
  fremy: If you have only one, unsure if there's any restriction that
         we don't have to do the layout of everything in a nested way,
         so maybe file an issue that and think about it
  miriam: issue opened already

  Rossen: OK, good presentation, what do you want to ask WG?
  miriam: Support for going forward, and feedback like I'm getting

  una: For slide 15, you have great diagram of initial container and
       then blue and pink items wider and vertical items
  una: theoretically same component
  una: What I see is that you set containment once, on parent
  una: each individual element querying?
  miriam: Matched with this code [other slide]
  miriam: containment on sidebar, main, grid-items
  miriam: those 5 containers
  miriam: single card component appears in each container
  miriam: each one querying its most immediate container
  una: So containment on immediate parent, and can nest
  una: ancestor. You pick the closest ancestor with container

  una: In theory, could you set containment on body?
  una: and have on any child
  miriam: It would act similar to a media query
  miriam: Main advantage would be responding to actual font size not
          environment font size
  miriam: if ancestor ...
  miriam: no container, maybe fall back too root to be smarter

  una: Is it necessary to set containment on children?
  miriam: In order to query something's width, we have to set
          containment on it
  miriam: In order to avoid the loops
  miriam: If only set on body, we can't query the width of the grid

  emilio: There were some versions of proposal that support selectors
  emilio: What happens with Shadow DOM there is a bit weird
  emilio: Stuff like ancestors might not even be in rendering tree at
  emilio: but might be DOM ancestor, ancestor of shadow host
  emilio: Descendant combinators wouldn't work
  emilio: that probably involves more complexity
  emilio: We can probably come up with some reasonable thing to do,
  * leaverou thinks the selector syntax might make it confusing that
             ems resolve based on the container, and not based on the
             element the selector is targeting

  Rossen: Hear a lot of support and excitement about this
  Rossen: Anyone opposed to adopting it?
  chrishtr: Would be new module, not addition to existing?
  <leaverou> +1 from Chris and Lea
  miriam: Potential for it to happen in Containment and Conditional,
          or could be its own

  argyle: Pushback I've heard is that 1D doesn't sound as useful as 2D?
  argyle: If I can't know the width and height of something together,
          how can I make a good decision?
  miriam: You can, but would have to contain both
  miriam: You have to contain whichever dimension you query
  miriam: but containing both dimensions doesn't address a lot of use
  miriam: block-only containment is hard, we're unsure if we can do it
  Rossen: ...

  florian: If we want to pursue this, need to pursue 1D containment on
           its own
  florian: that goes in css-contain
  florian: but needs further work
  florian: rest of it [missed]
  miriam: That's being worked on at Chrome
  Rossen: Spec-wise, where are we in 1D containment
  florian: Discussion in GH that it's likely to be possible, but
           that's as far as we got
  bkardell: 1 issue with some back and forth, that's all
  bkardell: I agree would make sense that it goes there, and is
            prerequisite for the rest
  bkardell: but no reason not to figure out where the rest of it goes
  bkardell: Rest of it, if we put it in a spec, would be dependent on
            1D containment

  fantasai: My suggestion would be to put the whole thing as Contain
            3, and we can figure out exactly where bits go later as we
            work on it.
  fantasai: Either way, 1d-containment needs to be defined in Contain
  fantasai: Draft as a diff spec for now, you can pull things back if
            you need, otherwise L3 will be all container queries
  florian: Unsure if contain-2 is that close to CR, but also not
           opposed to what fantasai said
  <bkardell> is that where we would want to put switch too?

  <nicole> It's so exciting that this is happening. :)
  <una> +1 to the excitement :D
  <bkardell> +1 excitement
  <jensimmons> +1
  <argyle> 🎉
  <leaverou> +1 excitement!
  <tantek> +1 progress!

  Rossen: Proposal here is to add this to css-contain-3
  Rossen: Only question I have is, who works on this besides Miriam?
  florian: I'm already editing level 1 and 2, so happy to tag along
           with 3
  florian: Will focus on containment rather than querying, but...
  Rossen: So level 2 editors + Miriam

  RESOLVED: Define container queries in css-contain-3, editors L2
            editors + Miriam

  <una> WOOO!
  <chrishtr> Excellent!!!!!
  <nicole> 🎉
Received on Thursday, 25 February 2021 00:30:05 UTC

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