- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Feb 2021 19:29:24 -0500
- 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
behavior.
- RESOLVED: Define container queries in css-contain-3, editors L2
editors + Miriam (Issue #5796)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/14
Present:
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
proposal
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
respond
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
out
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
otherwise,
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
here
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
pseudo-class
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
loop
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
given?
argyle: Not sure how to wrestle with those thoughts
argyle: Pseudo-class selector might be opportunity to specify which
container
argyle: What if want immediate parent?
<una> +1 to the individual container
miriam: Wouldn't be immediate parent, would be nearest contained
parent
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
solutions
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
item
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
all
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,
but...
* 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
cases
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