- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Oct 2023 19:06:49 -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.
=========================================
Alternate masonry path forward
------------------------------
- Issue #9041 contains several issues with the masonry layout and how
it would work with grid. They've been separated into individual
issues for easier discussion and resolution.
CSS Overflow
------------
- RESOLVED: Spec 'continue: collapse', add issue about whether
'line-clamp' invokes 'discard' or 'collapse' (Issue
#7708: Is continue: discard working in the fragment tree
useful?)
Review async poll results
-------------------------
- Doing async polls as proposed in issue #9438 was overall successful
in gathering data on preferences and surfacing new ideas and
questions. The group is open to continuing to use them when
appropriate to inform decisions.
- RESOLVED: Async polls should allow emoji reactions (Issue #9438)
- RESOLVED: Edit top comment to link to the poll (Issue #9438)
- RESOLVED: Open polls should be listed at top of agenda / proposed
agenda emails as a reminder (Issue #9438)
CSS UI
------
- RESOLVED: field-sizing: content | fixed (Issue #7542: Allow
<textarea> to be sized by contents)
CSS Text
--------
- RESOLVED: text-wrap-mode (Issue #9102: Move "balance | stable |
pretty" out of text-wrap)
CSS Scroll Snap
---------------
- flackr introduced issue #9187 (Improve or clarify nested snap
behaviors) and showed the improved diagrams available to aid
discussion. Group members were encouraged to review the issue and
comment on github.
===== FULL MEETING MINUTES =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Oct/0004.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Andreu Botella
Emilio Cobos Álvarez
Yehonatan Daniv
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Jonathan Kew
David Leininger
Vladimir Levin
Chris Lilley
Peter Linss
Alison Maher
ChangSeok Oh
Cassondra Roberts
Noam Rosenthal
Khushal Sagar
Jen Simmons
Miriam Suzanne
Lea Verou
Sebastian Zartner
Regrets:
Oriol Brufau
Eric Meyer
Bramus Van Damme
Chair: Rossen
Scribe: TabAtkins
Rossen: Any additional items?
flackr: I have an item we didn't get to last week about scroll snap
<flackr> https://github.com/w3c/csswg-drafts/issues/9187
Alternate masonry path forward
==============================
github: https://github.com/w3c/csswg-drafts/issues/9041
iank: When Masonry was introduced there was discussion about whether
this should be a new display type, or built into grid
iank: After reviewing this in more detail, I'm more convinced we want
a new display type
iank: We didn't have a great proposal for what this would look like,
so I typed up some details in a quick issue
iank: There's some fundamental tensions between Masonry layout and
Grid. This leads to some undesirable complexities, possibly
performance problems
iank: So for a new masonry display type, we can do masonry-first,
rather than bolting it onto Grid
iank: This is so far a very simple proposal, it can be extended in
the future, but it concentrates on the core use-cases
iank: Handful of props. masonry-template tells how your non-masonry'd
tracks look
iank: One detail is that, at least for now, having all your tracks
the same size is important for perf.
iank: We also haven't seen different-size tracks in the wild.
iank: Another is masonry-direction, same concept as flex.
iank: There are example where you want your masonry items to flow
upwards
iank: Another detail - you can tell a masonry item to span, but not
specify in a specific track. Again, based on use-cases we
haven't found any use for that.
iank: A few other bits about alignment, squaring off.
Rossen: Next steps?
iank: We might be interested in prototyping this in Chromium. I think
if there are any fundamental issues, or use-cases that aren't
covered by this proposal, that would be good to hear about
Rossen: I see the issue thread is already fairly active, some +1s,
some open issues.
Rossen: I propose we take the conversation back to the issue. When we
have enough of an understanding on next steps we can bring
them here.
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-1710838816
fantasai: I took Ian's issues and split them out into sub-issues
fantasai: I think we should go through and address these individually
fantasai: The question of whether to make this a new display type or
part of grid is kinda like the top of this issue, but some
of the questions are "well is it even possible to build
this into grid?" and I think we should answer that first
fantasai: Then the question about a new display type isn't about
whether or not it's possible, but whether it's *better* to
be part of Grid or a separate display type.
fantasai: I think all the issues Ian raises are addressable within
the Grid framework, so it would be good to go through the
individual issues to see if they're actually blockers.
fantasai: Then we can come back and see whether there's actually a
blocker that forces a new display type, or if it *is*
possible in Grid so it'll be more a decision of which is
better
iank: One thing I want to ensure is that, while lots of things are
possible, perf is important. I'm concerned about quadratic
behavior to add this into Grid.
plinss: Orthogonal q - what's the status of layout worklets?
iank: We have a prototype; we want to clean it up after our layout
rearchitecture.
iank: It's not a huge list of issues, we're just evaluating where it
is on priority.
plinss: k, just curious. If we're experimenting with new display
types, seems like a great opportunity to explore in userland
<TabAtkins> (fwiw I'm fairly certain Masonry *can* be done in the
existing layout worklet API)
CSS Overflow
============
scribe: fantasai
scribe's scribe: TabAtkins
Is continue: discard working in the fragment tree useful?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7708
TabAtkins: We have the 'continue: discard' functionality, part of
'line-clamp' feature
TabAtkins: can say element only has 3 lines of text, ellipsized,
discard the rest
TabAtkins: used to be defined in a very bizarre way in WebKit
TabAtkins: want to change
TabAtkins: Currently defined in terms of fragmentation
TabAtkins: we already have a good definition of how fragmentation
works
TabAtkins: Emilio and Ian both have perf concerns about invoking
fragmentation
TabAtkins: and wanted to address this in a simpler manner
TabAtkins: that accomplishes the right thing
TabAtkins: but lets us do the rest of the stuff -- suppression,
question of what happens to stuff after cut point -- in a
cheaper simpler way
TabAtkins: Florian had a list of questions, which didn't have clear
answers
TabAtkins: Andreu and Ian went through the list of questions
TabAtkins: and we summarized at the end
TabAtkins: A few open questions, but I think that overall this looks
reasonably well-defined
TabAtkins: assuming it is in fact better for perf, seems it also
accomplishes the same thing for author purposes
TabAtkins: so, question is, Florian do you still have concerns?
TabAtkins: Should we continue to pursue this approach and spec it out?
chrishtr: It's not just perf, it's also very difficult to implement
fragmentation definition in the spec
chrishtr: so I think there's a huge practicality advantage to
Emilio's proposal
florian: Many of the questions have been answered, and I'm now less
fuzzy on how it works, so that's helpful
florian: Some questions which are important haven't been answered
yet, so I suspend judgement until I understand how that works
florian: in terms of complexity, yes, version that involves
fragmentation is more complex
florian: however I wonder if the difference isn't overstated
florian: given Andreu has been able to prototype both
florian: So it seems more easily within reach than originally
suspected
florian: However, I'd like to move away from overall battle about the
approach without discussing the details
florian: just having a meta discussion slows us down
florian: we should write both down
florian: to be really sure what we mean
florian: The fundamental mechanics are different, but at the edges
there are likely details that can inform each other
florian: E.g. A few interesting questions have been raised about
fragmentation, and I think there are answers
florian: and for alternative approach, questions that I'd like answers
florian: so my preference would be to spec both, and use the
implementations from Andreu to explore compat, performance,
and usefulness to authors
florian: In the trivial cases, both will do the same thing
florian: but if you try to apply to more complex content, there will
be differences in behavior
florian: and being able to see those results will help us understand
whether one is better, or if each is better in different
cases
[missed]
andreubotella: I agree with Florian in that maybe we should try to
figure out both approaches at the spec level
andreubotella: and use the prototypes
andreubotella: In terms of implementation complexity, 'continue:
discard' in Chromium took me maybe three months (not
all in one set)
andreubotella: with multicol/overflow columns you have discarded
behavior... I prototyped that first
andreubotella: I had to be judicious in which assertions to fire when
boxes were not laid out, but otherwise not much
difficulty
andreubotella: implementing line-clamping on top of that was not hard
andreubotella: implementation in Firefox, which doesn't have
fragments as output would be a lot more complicated
andreubotella: not impossible to do without re-architecting, might
have more perf cost.
<Rossen> I recall implementing it in EdgeHTML and it was painful
andreubotella: My understanding is WebKit is working to output
fragments, and WebKit did not want to block on them
being able to implement the new model
iank: Wrt implementability, I think Blink is in the best situation
for 'continue: discard'
iank: but at the end of the day, I'd like this feature in all engines
iank: implementability will be far easier with 'continue: collapse';
same in WebKit
chrishtr: To add on about implementation, thanks for details
andreubotella
chrishtr: 3 months is what I would have expected
chrishtr: because we have new layout architecture, we can build this
on top
chrishtr: I don't think that it's easy at all to do it in WebKit or
Gecko, and would have multi-year delay to get feature in
hands of developers
chrishtr: and it's a highly requested feature
chrishtr: As I understand it, the clipping version does solve a lot
of their problems, and is way way easier in engines that
haven't invested into fragment-based architecture
chrishtr: My proposal is to add another value to the spec that is the
clipping version
chrishtr: don't remove the other one
chrishtr: could even ship the other version also
chrishtr: but in the nearer term, could implement the second property
chrishtr: and then be able to compare in practice, what are the gaps,
and allow engines to prioritize adding the second version
over time
florian: I agree we should spec both. I don't think I'm ready today
to decide which should be invoked by the `line-clamp`
shorthand
florian: because it would be different values on 'continue', e.g.
'continue: discard' vs 'continue: collapse'
florian: If we can agree on that today, we can make some progress.
Going further, I have more issues
chrishtr: So we'll spec 'continue: collapse', write down complete
spec, add tests, work through issues, and then come back to
group
florian: And while we're doing this, we can make progress on both
variants
florian: That sounds good to me
fantasai: I'm a little confused about the assertion that Gecko
doesn't work on a fragment basis
fantasai: The fundamental layout object in gecko is a fragment; the
whole layout algo is based on that
fantasai: Boxes aren't even a first-class object, fragments are, and
boxes are a linked chain
fantasai: So I'm not sure I understand why this is more difficult in
gecko than another engine
fantasai: not that I disagree with the approach, necessarily, just
confused
emilio: The main issue is that fragments cannot easily be discarded.
So to implement continue:discard, you need to lie and keep
the layout object around, and push it into a list of things
that haven't been laid out, and figure out how that interacts
with everything else
emilio: it's not only implementability, but what does "discard" mean
for a lot of the things that interact with layout tree, like
OM, caret movement, etc.?
andreubotella: I'm not sure we should ship both variants in
non-experimental builds of engines
andreubotella: if we agree that discard is better, which I'm not sure
we agree, but we ship collapse first, then authors
will depend on that. I'm not sure that's what we want
to encourage
<chrishtr> if collapse works for a developer use case that's great.
if it doesn't and a browser supports discard, they'll use
that
Rossen: So the last agreement was that we a path forward to
experiment with both
florian: Proposal would be to spec 'continue: collapse', put an issue
in the spec about whether 'line-clamp' invokes that or
'continue: discard'
florian: work through issues in both, and see where that takes us
Rossen: ok, let's take a resolution on that
PROPOSAL: Spec 'continue: collapse', add issue about whether
'line-clamp' invokes 'discard' or 'collapse'
RESOLVED: Spec 'continue: collapse', add issue about whether
'line-clamp' invokes 'discard' or 'collapse'
Review async poll results
=========================
github: https://github.com/w3c/csswg-drafts/issues/9438
lea: We have a few more votes than we did... let me try to pull up
the links
<fantasai> https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1747805436
<fantasai> https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1747785298
lea: One poll was about sizing form controls by contents
lea: we have 11 votes in that
lea: I'll leave up to you whether that was a success or not
lea: I still wouldn't say there's exactly consensus
lea: Plus 25 votes from non-WG members
lea: there does seem to be a clear consensus there for `field-sizing`
although people are proposing other names
lea: but from non-WG members strong preference `field-sizing`, also
from poll that jensimmons posted
Rossen: Sounds like this suggests field-sizing
<TabAtkins> yup, field-sizing looks pretty decisive to me
Rossen: Looking through comments and engagement from non-members,
curious... how much additional complexity would such async
polls add to us?
Rossen: Additional names are being suggested, this seems polls +
continued conversation
fantasai: I think helps actually
<fantasai> https://twitter.com/csswg/status/1711816620534886464
fantasai: Good to get the comments from authors, and ideas also
fantasai: I think we got the information we needed, and higher
quality than if we only had poll results themselves
jensimmons: Doing polls, whether ourselves or externally, these are
not scientifically valid
jensimmons: if you study research and stats, there are so many flaws
<lea> +1, the point is to get to the best option, not to be rigid
jensimmons: So it means we can't lock ourselves into assuming that a
poll is the truth. We still have to use our humanity. I
like mixing different polls. We get valuable information.
jensimmons: We just need the quick way to get many more people
involved in the conversation
jensimmons: Very valuable in helping us get to the wisest choice
florian: Voted for the minority choice, but no objection with the
majority view
<TabAtkins> +1, point is to get a quick answer from a larger quorum,
and see if there is a wide consensus. No different than
our straw polls, which also still need interpretation.
<florian> +1 to jensimmons
plinss: One comment I saw was, why isn't this part of width/height
properties
iank: We covered this previously, basically lots of times when you
trigger min/max content sizing
iank: and lots of quirks tied into these input elements that we
wanted to disable
iank: so that's why we thought a switch on the algorithm was best
iank: but we did discuss previously
Rossen: Sounds like this is good input, and additional commentary
although maybe distracting is also good signal
<TabAtkins> plinss, https://twitter.com/tabatkins/status/1712147099951968699
Rossen: So next question is, can we take the results and resolve?
Rossen: do we just accept the results?
<lea> data-informed instead of data-driven :)
jensimmons: the poll isn't determinitive, it's informative, we still
make the decisions as usual
<fantasai> +1 lea
fantasai: We should take each issue, and in consideration of the
poll, make the decision
chrishtr: Yes, let's take each issue
CSS UI
======
Allow <textarea> to be sized by contents
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7542
<fantasai> async poll
https://github.com/w3c/csswg-drafts/issues/7542#issuecomment-1747805436
<TabAtkins> field-sizing: content | fixed
<florian> WFM
Rossen: objections to resolving?
<fantasai> +1
RESOLVED: field-sizing: content | fixed
<chrishtr> yay!
<chrishtr> I love this feature
CSS Text
========
Move "balance | stable | pretty" out of text-wrap
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1747785298
<lea> https://github.com/w3c/csswg-drafts/issues/9102#issuecomment-1747785298
lea: This async poll had a difference, that did not allow input from
WG members (because we did it first, before deciding to add
emojis)
lea: I think the version with emojis worked really well
lea: The reactions also bumped the comment up which made the comment
more visible
lea: and also we were able to get both opinions at a glance, whereas
here we only get WG perspective
lea: Here we got 10 votes, `text-wrap-mode` seems to be a clear
winner, but not as definitive
lea: both me and Brad said they would prefer `white-space-wrap` if it
were an option
florian: Between two choices, I did abstain. I would be against
white-space-wrap
Rossen: Poll is leaning text-wrap-mode
Rossen: Any objections?
RESOLVED: text-wrap-mode
Review async poll results
=========================
github: https://github.com/w3c/csswg-drafts/issues/9438
Rossen: Between the two different polls, if we want to do this going
forward, what would be the process? what would work best?
lea: I think what we did with emojis in second one worked well
lea: Downside is we're limited to 8 options, but that's probably
fine, I don't think we've needed more
lea: Main issue is, how do we make sure that the poll is easy to find?
lea: Adding to agenda helped, but maybe have a policy to add it to
the first post, or adding a link from first post
lea: since discussion continues (which is great) makes harder and
harder to find the poll
lea: Counting votes is manual, so that gives an incorrect count --
but I was able to spot easily. Still can happen
<dbaron> for the record, those writing polls may find this list of
github reaction emoji shorthands useful: :+1 :-1 :grin :tada
:confused :heart :rocket :eyes
florian: I would suggest list of open polls at top of the agenda, so
that people looking at agenda can see that as their homework
easily
fantasai: Agree, and for counts, we can not have counts until we
close the poll. People can count.
Rossen: We can continue to refine
fantasai: I like Lea's idea to edit top comment with a link to the
poll
Rossen: Let's draft up the steps into the meta issue
lea: If we capture these as resolutions, they'll be automatically
captured in the issue :)
RESOLVED: Async polls should allow emoji reactions
RESOLVED: Edit top comment to link to the poll
RESOLVED: Open polls should be listed at top of agenda / proposed
agenda emails as a reminder
CSS Scroll Snap
===============
Improve or clarify nested snap behaviors
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9187
flackr: We've had many devs trying to use scroll-snap reach out to us
regarding different things they're trying to build
flackr: one common use case is nesting snap areas to have a large
area you can scroll freely, and some mandatory areas
flackr: paginated view within larger scroller
flackr: the spec suggests that this should be supported
flackr: but normative text doesn't explicitly define the expected
outcome
flackr: so wanted to get feedback on this proposal to add explicit
text
flackr: when you're in overly large snap area, should avoid
inter-snap areas
flackr: this creates desired effect of screens within a larger snap
area
flackr: you either fully snap into view or avoid them
flackr: so proposal for change
flackr: a few cases to discuss, what do you do if those inter-snap
areas aren't screen sized
flackr: not want to introduce large jumps in scroll because of
single-line snap area
flackr: but I think we can define reasonable behaviors
flackr: do we think this is reasonable to put in the spec?
flackr: I can propose spec text, and have examples and diagrams
Rossen: Thanks for intro, indeed the diagrams in the issue and spec
are making this very visual and easy to follow
Rossen: not seeing anyone in the queue, if interested in topic engage
in issue and perhaps can return later
Received on Wednesday, 11 October 2023 23:07:21 UTC