[CSSWG] Minutes Telecon 2024-08-28 [css-overflow]

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

  - flackr went over the current explainer for scroll markers (issue
      #10720) looking for support of the general direction. The group
      discussed some feedback and history of the issue and was broadly
      supportive of the direction. Any issues with the explainer can be
      opened separately in github for further discussion.
  - There was no clear winner between the options to address scroll
      snap on content such as auto paginated fragments (Issue #10715:
      Snapping and generating scroll-marker pseudo-elements from
      fragments). flackr will write up a third option that was raised
      on the call and fantasai will add comments to the issue.
  - Issue #10722 (Scroll button pseudo-elements) is a problem space the
      group is interested in solving. The current proposal would
      benefit from more documentation of in and out of scope use cases
      as well as additional details in the proposal.
  - RESOLVED: Blockification of -webkit-box happens at computed value
              time (Issue #10435: When does the blockification of
              -webkit-box occur?)

===== FULL MEETING MINUTES ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2024Aug/0017.html

Present:
  Rachel Andrew
  Adam Argyle
  Tab Atkins-Bittner
  Kevin Babbitt
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Daniel Holbert
  Jonathan Kew
  Roman Komarov
  David Leininger
  Alison Maher
  Cassondra Roberts
  Miriam Suzanne
  Alan Stearns
  Brandon Stewart
  Josh Tumath
  Bramus Van Damme
  Sebastian Zartner

Regrets:
  Chris Lilley
  Lea Verou

Scribe: bramus

Admin
=====

  astearns: Changes to agenda?
  bts: Can we defer grid-gap discussion?
  astearns: I noticed Elika and Oriol aren't here yet, so was planning
            on skipping over anyway
  <dbaron> but I'd like to discuss css-values-5 publication
  <dbaron> we resolved 2 weeks ago
  <dbaron> to publish FPWD
  <dbaron> Chris thought that fantasai was going to send the transition
           request
  <dbaron> but I'm not entirely sure
  <dbaron> so I'd like to know who will send the transition request and
           if I should
  astearns: I will follow up with Chris and Elika on that to make sure
            someone sends a request

CSS Overflow
============

Scroll Markers
--------------
  github: https://github.com/w3c/csswg-drafts/issues/10720

  flackr: We previously discussed the issue of a broad set of ways to
          make it easy for devs to author carousels with css
  flackr: This is one of the features of that
  flackr: Goals is to have a simple way for devs to create nav markers.
          Typically dots in carousels
  flackr: but also useful for TOCs
  flackr: or tabbing mechanism when you have a scrollable tab container
  flackr: have written up a spec in css-overflow-5 as previously
          resolved.
  flackr: Idea is that scroll markers behave as anchor links
  flackr: but they have one main additional component is that you can
          track which one is the active one
  flackr: so for a group there is an extra style that applies to the
          “current one”
  flackr: you can also create the groups as pseudos automatically for
          pagination scenarios based on fragmentation
  flackr: Issue is here to get attention on this and to bring everyone
          up to speed
  flackr: How this could work with regular elements ??? by having
          groups of links
  flackr: Is focus group the right thing or should we have a group name
          (for a later discussion)
  flackr: Already have 1 proposal in the spec and want consensus on the
          direction

  <TabAtkins> +1 from me, I'm very happy with this. Still some work to
              do but I think the current approach and syntax is good

  kizu: Left a comment, like the idea
  kizu: There is a lot of things with related issues
  kizu: One aspect that I think could be quick win
  kizu: to split off highlighting of currently applied marker
  kizu: For all TOCs this would be useful
  kizu: Had a lot of need for this recently
  kizu: TOC, tab list, etc
  kizu: need JS for that now with IO
  kizu: can also use SDA but that's a hack
  kizu: This one thing could be useful to split off
  flackr: Hadn't got chance to respond on issue yet
  flackr: In order to do auto selection it requires to have a grouping
          mechanism
  flackr: because active item needs to know which group it is in
  flackr: so that TOC doesn't interfere with set of inline links
  flackr: I don't think that auto creation adds a whole bunch of
          complexity
  flackr: if we just focused on active state, then we might forget to
          allow auto creation
  flackr: You also mentioned you would like template instantiation
  flackr: Feels like a good thing for filling in content for pseudo
          elements generally
  flackr: something that could be augmented later for markers (and
          ::before, ::after, etc)
  flackr: It's not mutually exclusive to have pseudos for this now
  flackr: having whole thing in spec also doesn't mean vendor has to
          implement the whole thing
  flackr: do see value in having it all specced out now

  florian: Way back in the day opera had tried (for fragmentation use
           case) to have these markers be auto generated or to have an
           API for devs to suppress that
  florian: As far as I remember there was no pseudo element
  florian: not saying we should be doing anything like this
  <florian> https://www.wiumlie.no/2011/reader/
  florian: Want to raise awareness about that effort
  florian: could give some ideas
  flackr: Wasn't aware of that specific case but have feedback that
          authors don't want to write JS to create stuff like this
  flackr: Do see value in purely declarative setup for this
  florian: Absolutely
  florian: Link I shared is either fully automatic or JS
  florian: JS override might be nice
  florian: For context: broader thing back then was to be able to opt
           in to pagination as an alternative to scrolling
  florian: they wanted that feature in that context
  florian: Again, purely sharing for awareness reasons and back-history

  astearns: Where are you with other bits of the process?
  astearns: Implementing things? sending intents? is this getting TAG
            review?

  flackr: Of course it will go through TAG and what not
  flackr: Have a partial experimental thing in Chrome
  flackr: to prove that we can have focusable pseudos
  flackr: and that it supports these use cases
  flackr: Should add a few links with concrete demos in the issue
  flackr: That's where we are at
  flackr: Want to get consensus on specific shape to push this forward
  flackr: make sure everyone is happy

  astearns: Other questions or comments?

  fantasai: Great ? to to work on. Spec needs a bit more explanation.
  fantasai: Makes sense to have ability to have an existing anchor to
            be both a scroll marker and also having the pseudo
  fantasai: spec doesn't do a good job of pulling this together in
            coherent model
  fantasai: (editorial criticism)
  fantasai: Makes sense to pursue this direction
  fantasai: with a little bit of work on the editorial side this would
            be a reasonable FPWD

  astearns: Cool
  astearns: What else do you want for this issue, rob?

  flackr: Please open individual issues on the proposal
  flackr: will make work of editorial work
  astearns: So you don't need resolutions?
  flackr: We already have a resolution to work on this (back in
          February)

Snapping and generating scroll-marker pseudo-elements from fragments
--------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10715

  flackr: One of the things that came up how devs can author content
          around auto paginated fragments (cols or page fragments in
          the future) is how do you actually attach scroll markers or
          snap styling?
  flackr: or other things?
  flackr: There is three general directions
  flackr: The overflow spec already has mention of styling fragments
  flackr: has an nth-fragment selector but there are internal concerns
          about it
  flackr: One option to have a fragment selector that applies to all
          fragments
  flackr: Second option to make the individual properties fragment aware
  flackr: already have issue for scroll-snap-align
  flackr: (firefox and and chrome differ)
  flackr: Could decide that this is a nice way to turn fragments into
          snap areas or markers
  flackr: Third option is a different syntax to make the property aware
          of fragments
  flackr: (code in issue)
  flackr: Second option is nice and simple
  flackr: at least for snap areas: snap areas per fragment box
  flackr: Can do same for scroll markers but feels weird
  flackr: Maybe can go for something different?
  flackr: This is the way to go or should be pursue fragment styling?

  <TabAtkins> I don't have a strong opinion on this, but I support the
              use-case.
  <TabAtkins> Doing it via a non-numbered ::fragment, to avoid implying
              different styling on fragments, seems useful

  astearns: Also support the use case like but don't have feedback on
            choosing
  astearns: Anyone with better opinion?

  fantasai: I think a generic ::fragment representing column in
            multicol is confusing
  fantasai: because we have several different ideas about fragmentation
            and multicol as one type of thing that creates fragments in
            a container
  fantasai: I think ?? set scroll-snap-align on column makes sens but
            should do that with column pseudo element
  <rachelandrew> +1 for scroll snapping on columns, we have issues for
                 that.
  fantasai: One of the discussions in overflow spec was to have
            nth-fragment pseudo element
  fantasai: it represents instances of the block through which the
            content fragments
  fantasai: Very different concept from multicol cols which are boxes
  fantasai: inside the ??
  <astearns> (discussing the overflow: fragment proposal)
  fantasai: Don't think scroll snap align should target column when you
            set it on multicol
  fantasai: should target the col that allows the snap property on ??
  flackr: That is not what is listed in the issue
  flackr: for option 2 it is saying that if you set scroll snap align
          on the in the multicol
  flackr: then should it generate are snap area per generated box
  fantasai: Don't have good answer to that

  flackr: To be clear: not to set scroll snap align on the thing
          establishing the multicol
  flackr: Question is whether setting those should have an effect per
          fragment
  flackr: Could be per property
  fantasai: Yes, transforms and borders for example differ
  flackr: Brought it up as one possible way
  flackr: if you want to snap align, you can wrap everything in
          multicol and then have scroll snap align
  fantasai: It would be better to set scroll snapping on the columns
            themselves
  fantasai: on last col it would be kinda weird
  fantasai: as content could be shorter than the others
  flackr: Yes, so vertical center would align differently

  iank: There are use cases for if you have a fragmented box somewhere
        within multicol to generate a snap area per fragment
  iank: so that would still be useful
  iank: Option 2 if we agree that generating snap are per fragment is
        strictly better behavior (like firefox) … could resolve on that
  iank: other prior art is box-decoration-break
  iank: Don't think that makes … could explore that route
  iank: producing snap area per ? might be better behavior
  flackr: Would solve the snap problem,
  flackr: also need to decide on scroll markers

  astearns: So proposal to resolve on option 2 for snap areas
  astearns: which would be in line with how firefox behaves
  flackr: Yes
  <fantasai> I'm not sure, in a multicol it might make sense to use the
             bounding box as the snap area
  astearns: any concerns with that? or more time needed?
  astearns: do you mean bounding box of all of the fragments, elika?
  <fantasai> yes
  <fantasai> if you imagine for example the use case of highlighting
             something
  <fantasai> and then snapping to that highlighted section
  astearns: (chair hat off) Agree with Ian that there are use cases for
            snapping 2 fragments individually

  astearns: So Elika I think you’d rather not resolve and take it back
            to issue?
  fantasai: Yeah, not sure what to … e.g. article inside scroller and
            highlighting function to highlight things … would you
            expect to snap to each one individually or the whole
            region? not sure
  fantasai: Don't have objection to resolve on ??

  flackr: A thing I heard is that you would be happy with something
          like option 1 if we had a selector based on columns instead
          of fragment?
  flackr: Is that correct?
  flackr: Would be happy to take that as a direction to pursue
  <fantasai> I think we should solve the column-snapping problem
             directly
  <fantasai> and for fragments within the columns, address them also
             directly
  <fantasai> not as a proxy for the column-snapping

  iank: Don't think that solves all the use cases like snap align
  flackr: Agree, there is a separate issue for snap areas
  flackr: Could continue to pursue for fragmented snap area boxes
  flackr: I think we can solve a lot of the use cases that I am trying
          to address with orig issue by having a ::column selector for
          example
  flackr: to create some style for the area

  bramus: Heard requests for grid on that
  bramus: Would that also work there, or only for fragmentation?
  iank: No, probably not

  iank: Other thing:
  iank: If we agree that both cases are useful for scroll snap align,
        then proposal 3 where we say scroll-snap-stop per fragment
        vs not
  iank: Need to decided on default behavior for scroll marker ??
  iank: because one thing here is that if we go with ::column that
        would initially only be valid on scroll marker group and
        scroll snap align (?)

  astearns: So hearing all three options are still in play
  astearns: let's take back to issue
  astearns: can you add comments to all options, fantasai?

  ACTION: fantasai to comment on the options

  astearns: because there are some unanswered questions

  ACTION: rob to write up ::column option

Scroll button pseudo-elements
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10722

  flackr: Other major UI component frequent in carousels is having
          buttons that scroll you through the content
  flackr: also in scrollers in general sometimes
  flackr: next/prev page, scroll up/down, …
  flackr: Proposal is to allow devs to create these with a
          pseudo-element
  <TabAtkins> Big +1 on this, with the only caveat being that we super
              need this ability captured in a property *as well* which
              we can put on normal elements (with some suitable
              restrictions for a11y/usability)
  flackr: few options for what that might look like
  flackr: and many open questions
  flackr: e.g. focus order
  flackr: seen examples of many different way of setting up these
          buttons
  flackr: Want to get some attention on this to figure out if we would
          be happy to pursue this
  flackr: and also some thoughts on specific questions

  florian: Feedback on general idea: on the one hand yes, people do add
           these buttons
  florian: proposal goes much broader
  florian: For scroll buttons, reminds me of something that I wanted to
           do when overlay scrollbars were new
  florian: because those scrollbars hide themselves, I wanted to add
           styles on the element so that users could see that it was
           scrollable
  florian: gave up because I was fighting the UI
  florian: Similarly the trend is no longer to have scroll up/down
           buttons ... these are useful and users can bring them back
           (OS setting) or is this a feature devs should bring back?
  florian: Feel that is is unfortunate that we are fighting back
           through author space on features that UAs have removed, then
           again it is useful
  flackr: In most cases where authors these, they look nothing like the
          thing the UA provides
  flackr: Main use case is to recreate native scrollbars
  flackr: probably are cases that do that, but mostly site specific
          things
  florian: Fact that they look different is not necessarily diagnostic
  florian: what I used to do back in the day also looked very different
           from the removed browser UI, I wouldn't have done that if
           browser kept original UI

  TabAtkins: Like it, dropped syntax nit suggestion in the issue
  TabAtkins: The ability to trigger scrolls in whatever direction
             should be dropped onto a property so that we can put these
             on real elements too
  TabAtkins: having pseudos makes sense too
  TabAtkins: Figuring out restrictions is a little bit more complicated
             on those elements, so having only pseudos is fine too
  flackr: Can do this with invoke action on buttons
  TabAtkins: Sounds reasonable

  SebastianZ: Also am reminded of the popover approach
  SebastianZ: fits more to HTML so that we could introduce HTML attrs
              that would trigger scroll and then those elements could
              be style in any way

  astearns: Want to address q3: absolutely
  astearns: should design so authors can use scroll-start and scroll-end

  bramus: Addressing florian's remark
  bramus: where he wanted to recreate classic scrollbars, think that's
          part of another discussion we already have an issue for
  bramus: where authors want control over overlay vs classic scrollbars
  bramus: so maybe something to discuss in that issue
  florian: I wasn't so much pointing out that authors want to recreate
           classic scrollbars, but rather react to scrollbars being
           less useful as time goes by

  fantasai: I understand the desire to create these buttons using css
  fantasai: Proposal is probably way too simplistic
  fantasai: How much are you going to scroll by? fragment? page? part
            of page? section? next scroll marker?
  fantasai: lot of different amounts
  fantasai: Question about relation to each other and what order to
            they appear compared to other pseudos?
  fantasai: lot of option questions
  fantasai: proposal for 2 pseudos with page-up/down is a bit too
            simple to address problem space
  fantasai: Don't have a good solution do we want to make this more
            complicated now or? – don't know what makes sense here
  fantasai: but see a lot of variation of what users want to do and
            think we need to capture those needs
  flackr: Did mention everything you mentioned as a list of open
          questions
  flackr: definitely underspecified at this moment
  flackr: question is not to resolve, but for me to go formulate
          answers to all those questions and then take it back
  astearns: I suggest yes: work on the questions and need to figure out
            the details

  florian: Do think it is worth exploring this, authors will do this
           anyway, and it'll be more robust if we provide features in
           that space that help
  florian: also UAs, make scrollbars useful please

  astearns: We not only need the questions
  astearns: we need the group of usecases that we are trying to solve
  astearns: maybe a group of usecases that is out of scope
  astearns: discussing things in terms of what the author wants to do
  flackr: excellent feedback
  astearns: so we take this back?

When does the blockification of -webkit-box occur?
--------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10435

  emilio: About -webkit-line-clamp right?
  emilio: turned that into -webkit-box
  emilio: if you have right set of conditions then ?? BFC, but should
          that blockification happen?
  emilio: At what time? ?? time or computed value time?
  emilio: Main argument for doing at computed value time is that it is
          more consistent with things like display block
  emilio: it makes gCS not lie

  iank: Looked into why we did it like that
  iank: Result of us being conservative because we did it first
  iank: so emilio you haven't had any compat issue due to doing it at
        this time?
  emilio: Never
  iank: Would be fine to changing at computed value time with caveat
        that we don't run into issue

  PROPOSED RESOLUTION: blockification of -webkit-box happens at
      computed value time
  astearns: Objections?

  RESOLVED: blockification of -webkit-box happens at computed value time

Received on Wednesday, 28 August 2024 23:59:54 UTC