[CSSWG] Minutes Telecon 2023-10-11 [css-overflow][css-ui][css-text][css-scroll-snap]

  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

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)


  - 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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Oct/0004.html

  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

  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
  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> ->
  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
  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
  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
  TabAtkins: Emilio and Ian both have perf concerns about invoking
  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
  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
  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

  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
  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
  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`
  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
  florian: And while we're doing this, we can make progress on both
  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

  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

  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
  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


Allow <textarea> to be sized by contents
  github: https://github.com/w3c/csswg-drafts/issues/7542

  <fantasai> async poll
  <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
  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
  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
  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
  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
  flackr: so wanted to get feedback on this proposal to add explicit
  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
  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