[CSSWG] Minutes Telecon 2023-05-03 [scroll-animations] [css-overflow] [css-ui]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Upcoming F2F

  - The preference from current survey respondents was for a F2F on
      the west coast hosted by Apple the week of July 17th. Unless
      anyone reaches out either on the private list or directly to
      Rossen by next week's telecon, that will be the final decision.

Scroll Animations

  - RESOLVED: We will accept this PR and close the issue (Issue #8694:
              Handling changed size/position in current frame)
  - RESOLVED: Return positive infinity for time values after the
              range, and negative infinity for times coinciding with
              and before (Issue #8114: Clarifying behavior of

CSS Overflow

  - RESOLVED: Explicitly define that overflow:clip does clip
              scrollable overflow (Issue #8607: What clips scrollable
  - RESOLVED: 'clip' and 'clip-path' do not clip scrollable overflow
              (Issue #8607)


  - The group reviewed the proposal to add
      min-intrinsic-sizing:from-textarea and
      min-intrinsic-sizing:from-input for the sizing use case outlined
      in issue #7542 (Allow <textarea> to be sized by contents). The
      group discussed if this should be two properties or just one and
      generally landed on needing two properties. There was a request
      to have a week to discuss further so this will be on next week's


Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0002.html

  Rossen Atanassov
  Elika Etemad
  Robert Flack
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Ian Kilpatrick
  Vladimir Levin
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Miriam Suzanne

  Rachel Andrew
  Tab Atkins
  David Baron
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Jonathan Kew
  Chris Lilley
  Bramus Van Damme
  Lea Verou

Chair: astearns

Scribe: dael

Agenda Setting

  astearns: Looks like we're getting enough of a quorum
  astearns: Does anyone have adjustments to the agenda? We're going to
            skip item 4 in favor of having emilio on the call
  chrishtr: If anyone has feedback on item 4 who is on the call it
            would be helpful to take into account
  iank: If we get to item 7 there's an issue that needs to be
        discussed at the same time
  astearns: chrishtr are you asking people to comment on the issue?
  chrishtr: Yes, please review what Vlad summarized and provide
            feedback. If anyone has live concern they think would be
            useful please say, but most useful is feedback on issue
  astearns: We'll call for anyone that wants to spend a bit of time
            when we get to it
  [un-minuted announcement]

Upcoming F2F

  Rossen: We did get a few replies as of last week based on the
          questions fantasai and I double asked in the private list
  Rossen: Didn't get as many replies as compared to previous. Current
          tally for what we asked is based on a little less than 10
          responses. Suggests most likely location is going to be West
          Coast with corporate hosting of Apple
  Rossen: Most people want the one in Mexico that's hard to resist
          based on the pictures :)
  Rossen: That's where we're at today. If you have strong feelings
          please reply to use either on the private channel or
          directly to me. Ideally this is something we can resolve by
          next week's call so Tess and company has enough time to book
  fantasai: If you want to respond privately, respond to me or Rossen
  jensimmons: When is the meeting?
  Rossen: Week of July 17
  jensimmons: Thank you
  Rossen: Sooner we decide the higher chances we have that myself or
          astearns will make it. Calendars are filling up for most
          folks. I know for myself I need to know in advance
  astearns: And getting largest number of participants able to
            participate. The earlier we can get it set the better

  Rossen: Let me be more decisive. As of right now feedback is West
          Coast and hosted by Apple. If you have strong reasons to
          outweigh this and support to sponsor please let us know. If
          we don't hear anything by next call we'll decide west coast
          F2F week of July 17 hosted by Apple
  astearns: Alright, we'll have this decided by next week. Please send
            any input to Rossen and fantasai

Scroll Animations

Handling changed size/position in current frame
  github: https://github.com/w3c/csswg-drafts/issues/8694

  flackr: With view timelines we have named ranges that are related to
          the position and size of their subject within their scroller
  flackr: This means that if the position or size changes the named
          range can change which changes animation progress and visual
  flackr: Per spec no update if the size or position changes.
          Proposing we detect when this happens. It's similar to when
          we detect new timelines. It would be if it moves or changes
          size and we trigger a new layout cycle
  flackr: I have a spec PR to make the change. Main point is condition
          I noted and that it does it after resize observer and resize
          observer might change which we would want to respond to
  flackr: Proposal is accept the PR that adds a change in position or
          size of subject as a condition to do a layout cycle
  astearns: You have people commenting on issue and PR but not calling
            out changes
  flackr: Discussed with iank who I think is on call
  astearns: Any concerns or questions?
  astearns: Objections to accept the PR?

  vmpstr: What are implications to updating timeline. Can sizes
          change? Asking because doing this after resize observer
          means if updating can change size the size observation has
          to be on next frame
  flackr: Size can change
  flackr: It's generally frowned upon to animate size or layout and
          expect frame perfect
  flackr: Trade off if we run before resize observer where we wouldn't
          guarantee the timeline is correct or after
  astearns: Is that enough of an answer?
  vmpstr: I think that's fine. Just have an issue later on the agenda
          that's similar for non-timelines
  astearns: Anything else on this issue?
  astearns: Proposal: We will accept this PR and close the issue
  astearns: Objections?

  RESOLVED: We will accept this PR and close the issue

Clarifying behavior of getCurrentTime(rangeName)
  github: https://github.com/w3c/csswg-drafts/issues/8114

  astearns: Follow up about what happens when start = end
  flackr: I believe fantasai added to agenda. Clarification is how to
          handle start time = end time
  flackr: I've prop never return 0 for current time with assumption
          dev is plugging this into an animation and if they plug - or
          + infinity they guarantee the animation is before or after
          phase and that's not same as the effect they're copying
          time of

  fantasai: I don't have much of an opinion. If it's not 0, then what
            is it? Can we resolve on what we want it to be?
  flackr: It's what you said in your second option.
  flackr: [reads]
  <astearns> Return positive infinity for time values after the range,
             and negative infinity for times coinciding with and
  fantasai: So negative infinity for coinciding? I don't know I
            thought through this.
  flackr: Yes, that is correct
  fantasai: I know I suggested negative infinity, but I don't
            remember why
  <fantasai> and maybe I got it backwards when typing
  astearns: Only difference between your options is what we do with
            time values coinciding with a single point in the range
  fantasai: Right, if you land on that point should it be before or
            after start
  flackr: I believe I compared this to a running animation with 0
          duration. Recollection is your statement matched the
          animation behavior
  fantasai: If you think it's right, I'm fine. I just want to make sure

  astearns: My question- is this just an edge case we're filling a
            rational answer in for or is this something devs are
            expected to handle?
  flackr: My opinion this is a bit of an edge case and we're trying to
          fill in value that would give the same effect as an
          animation with that range
  astearns: Other comments on this?

  astearns: Proposal: Return positive infinity for time values after
            the range, and negative infinity for times coinciding with
            and before
  astearns: Objections?

  RESOLVED: Return positive infinity for time values after the range,
            and negative infinity for times coinciding with and before

  astearns: As fantasai said, seems a bit weird but this is a good...
  flackr: I did paste a demo on March 10 demonstrating. So I'm not
  astearns: If you have time fantasai or anyone else please take a bit
            of time considering implications in case we want to revisit

CSS Contain

content-visibility: auto visibility check timing needs details
  github: https://github.com/w3c/csswg-drafts/issues/8542#issuecomment-1515216159

  astearns: Anyone on the call want to put something on the record to
            help with discussion next week?
  vmpstr: I'm happy to introduce the issue. Not asking for resolution
          because emilio isn't here
  astearns: At the beginning of call chrishtr asked for people to take
            a look and speak up now or add comments
  astearns: We'll come back next week

CSS Counter Styles

cjk-earthly-branch and cjk-heavenly-stem
  github: https://github.com/w3c/csswg-drafts/issues/8596

  astearns: Does anyone know what needs discussing?

CSS Overflow

What clips scrollable overflow?
  github: https://github.com/w3c/csswg-drafts/issues/8607

  fantasai: We are trying to figure out how we're defining scrollable
            overflow. clip-path seems to not clip scrollable overflow.
            clip has no interop. What behavior do we want here
  fantasai: smfr said clip-path should be like a mask. iank suggested
            clip and clip-path should behave the same
  florian: So this is not visually clipping, but clipping the effect
           on scrollability
  iank: Yes. And I somewhat agree with smfr as well
  fantasai: Proposal: Overflow-clip clips scrollable overflow.
            clip-path and clip do not clip scrollable overflow; they
            just clip painting

  astearns: A bit of a concern that if we define clip to have this
            behavior it may not actually come to be. I don't think
            browser implementors won't be all that concerned about
            interop on clip
  iank: webkit and blink are consistent with clip. I think Gecko is
        only odd one out
  astearns: Other comments?
  astearns: There were results in test case. What does spec say?
  fantasai: I think it's not defined for clip path
  florian: overflow:clip not an objection but feeling a bit odd. If
           I'm not misremembering in terms of floats poking out
           overflow:clip lets them do that. So overflow:clip does clip
           geometry for scrollable and not for floats. Maybe a bit
           weird but I guess okay
  astearns: Sounds like a candidate for a test case
  astearns: Is it the case that overflow:clip is specced to say it
            clips scrollable overflow?
  astearns: Do we need two resolutions, one for overflow:clip and one
            for clip and clip path? Or is overflow:clip handled?
  florian: In the spec overflow:clip is spec to say UI is not supposed
           to provide scrolling interface. At time written probably
           meant for element, not its parents. Maybe needs

  astearns: Proposal 1: Explicitly define that overflow:clip does clip
            scrollable overflow
  astearns: According to test case we're speccing reality
  chrishtr: In all browsers, right?
  iank: Correct
  astearns: Objections?
  <chrishtr> sgtm

  RESOLVED: Explicitly define that overflow:clip does clip scrollable

  chrishtr: According to issue css-clip does not have interop
  iank: Webkit and Blink are the same. only Gecko clips scrollable
  chrishtr: On WwebKit and Blink neither clip nor clip-path effects
            scrollable overflow
  iank: Right. But only clip in Gecko
  chrishtr: Proposal is match WwebKit and Blink?
  iank: Yes
  chrishtr: Makes sense
  dholbert: Makes sense to me too. Digging into code to understand why
            they're different but not sure. Seems reasonable
  iank: Clip is such an old property I wouldn't be surprised if it's
        old behavior
  astearns: Other comments?

  astearns: Proposal: We specify that clip and clip-path do not clip
            scrollable overflow
  chrishtr: What about masking? Has anyone checked that?
  astearns: I'm guessing we have not
  chrishtr: Pretty sure it does the same as clip-path in blink. I
            think we should align them all together
  astearns: Makes sense to me
  dholbert: Might be good to do testing on that before we resolve
  astearns: Let's resolve on clip and clip-path for now and then let's
            take a look at masking. Let's have that be a separate
  chrishtr: Okay
  astearns: Proposal: clip and clip-path do not clip scrollable
  astearns: Objections?

  RESOLVED: clip and clip-path do not clip scrollable overflow

  ACTION chrishtr check out if masking has the same issue as clip and
         open an issue if necessary

  iank: I'd be surprised if it doesn't behave correctly
  astearns: But the spec may need words


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

  iank: The goal is to allow for textarea to grow number of content
        and grow in inline dimension with content
  iank: Previously discussed to achieve with min-intrinsic-sizing
        property. Seems like a reasonable idea
  iank: One way would be add 2 new values, one for textarea and one
        for input
  iank: you would say min-intrinsic-sizing and it would switch to
        being sized based on the area
  iank: Any thoughts or concerns?

  astearns: Reason you are using the element names instead of
            something more generic like from-content?
  iank: They sort of work in different axes. textarea is in block and
        inputs are intrinsic for block dimension. If someone sets a
        reset it's not clear you want both so probably need individual
  fantasai: I had the same question about why 2-axes. If we're
            splitting the axes we should maybe consider axis. Is it
            split on axis or on type of input?
  fantasai: And then is this going to change the way auto works?
  iank: What do you mean by change how auto works?
  fantasai: When the input as an auto-width it currently sizes to a
            magic number
  <astearns> from-inline-content-size/from-block-content-size (for
             those who like to type a lot)
  iank: full width for textarea we haven't heard demand to grow in
        inline size
  iank: Is theoretically possible but I would prefer to keep. If we
        did it for both axes for textarea it would be weird behavior
        when they're in something like flexbox. Current magic is
        simple and looks at columns
  iank: Prefer to keep textarea just for block. If we split
        min-intrinsic-sizing that's the other issue if we want to
        add it.

  vmpstr: I just wanted to ask for input if I spec
          min-intrinsic-size:from-input would the input shrink below
          default size?
  iank: Correct. Expected webdev will put a min-width on that element

  miriam: I like this. For me your argument it does one thing on
          textarea and another on input seems like an argument for one
          value. Seems weird to align the right value to the right
  miriam: Why do I need to say textarea as the target and the value
          rather than getting the right behavior
  iank: Related to next issue which is splitting axes for
        min-intrinsic-sizing. Might be better to talk about that
        first. If we split that property in 2 than from-input would
        only apply to one.
  iank: Could have a from-content but somewhat find that more
        difficult to understand. I think this is less magic. content
        is an overloaded word
  iank: I like the explicitness of from-input and from-textarea
  astearns: I like solution of splitting min-intrinsic-size as a
            solution to the reset issue
  iank: I would still come back to some content would be confusing
  iank: It is possible; we could have intrinsic sized text areas in
        inline axis. I don't think it's desirable
  astearns: That's not part of current proposal, right?
  iank: Correct. Future thing to keep in mind

  fantasai: I think this is workable. From author PoV I think the
            original proposal we had discussed to use min- and
            max-content feels more understandable. I'd prefer that if
            we can
  iank: I don't think we can. Flexboxes are everywhere and it would
        change the auto min-size. We'd need an explicit switch for
        switching the algorithm similar to what min-intrinsic-size
        does for scrolling. We won't be able to shift that
  fantasai: What's the case it changes behavior?
  iank: A few. People use min-content/max-content on things already.
        Would change any input elements with this already. Other thing
        is it would change flexbox. Flexbox uses min-content size
        directly and that would change
  iank: I think emilio tried to implement. I don't think we can
        shift it
  fantasai: Make sense to put keywords on width and height? Seems like
            a pretty indirect method.
  iank: At the moment it's switching the algorithm we use to determine
        content size. All input elements and textarea have a special
        metric and this would default to the default. I think
        min-intrinsic-sizing is a good place to do this since the min
        size for scrollable is there also

  fantasai: I think I'd like to talk this over with TabAtkins. But I
            agree we need to solve the use case
  iank: As long as it's not...been trying to come up with a proposal
        that satisfies everyone's desire for a while. I think this is
        the best so far
  fantasai: min-intrinsic-sizing property is about min and not
            intrinsic sizing. Or is this a new proposal? We have an
            intrinsic-sizing property. Is this separate?
  iank: This is the original property
  fantasai: That's about how we find the min intrinsic size, but not
            about something like max intrinsic size.
  iank: Weird thing about inputs is they're the same thing
  fantasai: Yeah, some elements don't have difference between min and
            max. A div with one word has equal min and max.
  iank: Input elements that's also true
  fantasai: Right, because they have a fixed length intrinsic size.
  fantasai: We're trying to allow elements to be resized from their
            content. For a text area in block axis min and max will be
            the same. Concept does exist for difference if you want it
  fantasai: Would make sense if you tried to size as if they're a
            regular element you get that behavior. And you can't here
            because it's only giving one size.
  fantasai: Probably solves use case, but I think what makes sense is
            to make this behave more like a replaced element
  iank: Specifically for input case you cannot get an input to wrap
        multiple lines
  fantasai: Yes, they're no-wrap
  iank: You can't get min vs max for these elements today
  fantasai: But if we wanted to do something on inline axis for
            textarea there would be possible 2 sizes
  iank: But no one is asking for that
  fantasai: I agree. I think if we can try and get everything to fit
            in that's a good directly
  fantasai: I think min-intrinsic-size...what min-width:auto resolves
            to is a little different from what is the intrinsic size.

  fantasai: I would rather try and talk this over with TabAtkins
  astearns: Can you commit to that over the next week?
  fantasai: If TabAtkins is available tomorrow or Friday, yeah.
  [discussion on TabAtkins availability]
  astearns: iank okay with you if we put this and 8620 on the agenda
            next week?
  iank: Sure
  astearns: Next week we'll start with content-visibility and then
            this two issues

  astearns: I think we're out of time. Thanks everybody for calling in.

Received on Thursday, 4 May 2023 23:03:20 UTC