- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 12 May 2020 19:05:55 -0400
- 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:
https://gist.github.com/bkardell/e5d702b15c7bcf2de2d60b80b916e53c
- From dbaron an @container query:
https://github.com/dbaron/container-queries-implementability
- 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)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-one-time-slot-a
Present:
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
problems.
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
switch()
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
containment
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
width
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
use.
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
layout.
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
imagine.
fremy: As for Florian's remark, I think this is valid, e.g. height
dependent on width. But with more restrictions this may be
solvable.
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
itself?
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
this.
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
switch()?
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
descendants.
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
architectures.
bkardell: I think we could get this done quickly and then move
beyond that to a higher level thing like a media query /
pseudoclass.
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
quickly.
<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
notion.
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
implementation.
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 />
Multicol
========
Scribe: fantasai
column-fill in unconstrained containers: continuous vs fragmented
contexts
------------------------------------------------------------------
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
spanner.
florian: Further clarification, should balance from start of current
fragmentainer.
florian: Previous fragmentainers are independent of that.
dbaron: I think I agree that balancing before spanner is the right
thing.
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