[CSSWG] Minutes Telecon 2023-12-06 [css-values][css-scroll-snap][css-lists][scroll-animations]

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

  - Next week there will be an extra hour of meeting to cover
      additional topics.
  - The next F2F will be Feb 12-14 in Mountain View CA. Group members
      are asked to add to the wiki if they will be attending.

CSS Values
----------

  - RESOLVED: Percents that are resolved against numbers do that at
              parse time (Issue #9395: Resolve `<percentage>`
              representing `<number>` or `<angle>` at parse time)
  - RESOLVED: Drop mix() from Values 4 (Issue #9343: Abandon mix()?)
  - RESOLVED: We will never use mix to represent a single interpolated
              value but may have something like it for expressing the
              whole interpolation (Issue #9343)

Scroll Snap
-----------

  - RESOLVED: Specify option 7 [Join with preceding ranges if there are
              later overlapping ranges and the gap is short] as
              normative behavior (Issue #9187: Improve or clarify
              nested snap behaviors)
  - RESOLVED: Specify the whole list in this order as normative
              behavior (Issue #9622: Standardize snap point selection
              with multiple aligned boxes)

 CSS Lists
 ---------

   - RESOLVED: Revert the previous resolution and the associated edits
               (Issue #5477: CSS counter scope/inheritance is
               incompatible with HTML ordinals)
   - RESOLVED: The working group is interested in defining an opt-in
               narrow scope for counter resets. Exact syntax tbd (Issue
               #5477)

Scroll Animations
-----------------

  - The group wants to make sure that if we make changes in issue #8915
      (Blocking effects of timeline-scope) it wouldn't lead to problems
      that would make containment less impactful. Discussion will
      return to the issue for more investigation.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2023Dec/0000.html

Present:
  Tab Atkins-Bittner
  Elika Etemad
  Robert Flack
  Daniel Holbert
  Dael Jackson
  Vladimir Levin
  Peter Linss
  Florian Rivoal
  Alan Stearns
  Miriam Suzanne

Regrets:
  Rachel Andrew
  Oriol Brufau
  Chris Harrelson
  Jonathan Kew
  Bramus Van Damme
  Sebastian Zartner

Chair: astearns

Scribe: dael

Upcoming Meetings
=================

  astearns: I think we can get through a few things today
  astearns: Housekeeping- I posted the possible agenda for an extra
            hour of meeting that I'm planning to announce for next week
  astearns: It's the hour before the regular meeting. I'll get that
            posted today and ask if there's anything else to add

  <@astearns> https://wiki.csswg.org/planning/mountain-view-2024
  astearns: Second, TabAtkins announced to private list we have a
            meeting for Feb 12-14. There is a wiki page up. Please add
            at least your name so we know who is coming
  astearns: I think that's it for my housekeeping. Anything else?
  fantasai: We should try and plan F2F after that at some point
  astearns: Yep. On my list to poke Tess about the Apple hosted-meeting
  fantasai: I think we're still on for that. Main thing to figure out
            is dates
  astearns: I'll get that going too

CSS Values
==========

Resolve `<percentage>` representing `<number>` or `<angle>` at
    parse time
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9395

  TabAtkins: Pointed out that while the spec says we simplify trees at
             computed and used time, there's significant browser
             interop at resolving percents of numbers at parse time.
             Calc(50%) in opacity and you read back immediately you
             get .5
  TabAtkins: I don't have much of an opinion. I'm fine leaving spec
             as-is or with modifying spec to say % resolved against
             numbers are resolved at parse time. Either is okay with
             me, so question of what do browsers want to do

  fantasai: Another relevant question is would authors have an opinion
            on it
  TabAtkins: I've never heard anyone have an opinion. I haven't looked
             deeply, but haven't spotted it
  fantasai: I think tend to keep specified values as specified. Example
            a lot of color stuff could be at parse time, but we don't.
            Same with bg position stuff

  astearns: If we decide we want that behavior is it likely that all
            the browsers will change their current code to adapt?
  TabAtkins: Given I'm not seeing anyone say anything, I suggest we
             resolve to match browser behavior

  florian: Only thought against that direction is the more you preserve
           the easier it is for browser tools that work off OM. But not
           sure if we've followed that enough for it to be practical
  TabAtkins: Agree. And if you want high quality you have to do it like
             dev tools
  astearns: And there is now a dev tools API
  TabAtkins: It is very important to get access to the invalid stuff
             and you cannot get it from the OM. I'm not super
             sympathetic to needing values for an editor concern.
             Author surprise would be different, but I don't see that.
  fantasai: Situation is we're kind of inconsistent where some things
            can resolve and some can't?
  astearns: For things that do resolve against a number, only exception
            is filter argument.
  florian: Anyway, I think Tab's suggestion is reasonable

  TabAtkins: Can drop some tests and highlight that filter effect needs
             a change
  fantasai: Just put a warning where you write the thing that it's not
            always going to resolve like line-height
  astearns: An example of something that looks like it would work but
            doesn't would be reasonable to put in spec
  TabAtkins: I think line-height is most reasonable thing. Good idea
  astearns: Proposal: Percents that are resolved against numbers do
            that at parse time
  astearns: And we'll have an example of something that doesn't quite
            fit the pattern and we'll add wpt for this
  astearns: Objections?

  RESOLVED: Percents that are resolved against numbers do that at parse
            time

Abandon mix()?
--------------
  github: https://github.com/w3c/csswg-drafts/issues/9343

  TabAtkins: First off, to clarify. Since issue was filled mix() gained
             a new syntax. We're not talking about that. This is about
             dropping original feature for mix(). It was intended to
             let us represent values that couldn't be written as
             computed but do interpolate
  TabAtkins: Since then we added sufficient specialized functions to
             values 5 to handle all cases we know where this happens.
             Only a handful of cases that needed the generic
             interpolation.
  TabAtkins: So, I believe we can drop the generic interpolator and
             stick with the specific ones that handle each thing that
             needs special behavior
  florian: And it did not represent things that are not interpolable?
  TabAtkins: Correct, it was invalid syntax

  fantasai: Two reasons mix was added. One was for these interpolations
            that you can't show intermediary value. Other was create
            syntax to allow authors to represent an interpolation of a
            value between two breakpoints in a MQ. It's not that the
            intermediary can't be represented but it's because you want
            a range depending on another calc
  fantasai: That's what mix was originally for. Since then, TabAtkins
            and I decided it should be kicked from level 4. But the
            other function of mix where you can take a whole property
            value and interpolate between it and another value based on
            how far you are in a 800px window
  florian: And you could represented it but not well?
  fantasai: You could, but now that there's calc-mix you can represent.
            But if you have something like discrete keywords you can't
            unless there's an existing mix value
  miriam: You've basically answered my question.
  TabAtkins: They cover the case for the types they're meant for.
             There's a bunch of types like keywords that don't have a
             mix function
  miriam: That use case feels useful to me

  fantasai: I think there are reasons to want something like mix. I
            don't think we want to impl as is. Reasonable to resolve
            not in L4 but seems reasonable to explore
  TabAtkins: Also resolve that we're not intending mix to represent
             intermediate values would be good. But intent that it's
             useful for authors to say somewhere on this path is good.
             Good to resolve that we're not keeping mix to rep
             intermediate values
  astearns: Proposal: We will drop mix from L4. Specifically, we don't
            want to use it for the generic representation of
            interpolated values but we may in a future level come up
            with something like mix to express the interpolation itself
  fantasai: 2 resolutions. Drop mix from Values L4. Second is: Keep
            exploring mix for interpolation use cases but not for
            representing a single interpolated value
  <TabAtkins> proposed: we're not keeping mix() *for the purpose of
              representing intermediate values*. keeping it for
              *authors wanting to interpolate arbitrary things* is
              still on the table
  astearns: First part, drop mix from Values 4. Objections?

  RESOLVED: Drop mix() from Values 4

  astearns: Second is we will never use mix to represent a single
            interpolated value but may have something like it for
            expressing the whole interpolation
  fantasai: It shouldn't be the only way to represent the value

  RESOLVED: We will never use mix to represent a single interpolated
            value but may have something like it for expressing the
            whole interpolation

Scroll Snap
===========

Improve or clarify nested snap behaviors
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9187

  flackr: Previously discussed this. Use case is when you have nested
          snap points want to respect inner ones as discrete stops that
          are separate.
  flackr: Previously suggest avoiding inner, but that mad tiny gaps.
          fantasai had alternate that joined inner with outer that
          follows. Had some concerns about asymmetrical
  flackr: Compromise is when the gap between the inner snap areas is
          larger than viewport it's a discrete area you can snap to.
          When it's smaller it joins with previous inner snap area
  flackr: Already have a condition for length between snap areas. And I
          think it satisfies both use cases. Made a demo page with all
          the various proposals. Adam tried it out and voted his support
  flackr: Hoping we can go with this.
  <TabAtkins> I haven't been able to experiment with this myself, but
              Adam has and likes flackr's suggestion, and it does sound
              pretty reasonable.
  <TabAtkins> So +1

  fantasai: Compare to scrollport or snapport?
  flackr: Snapport
  fantasai: Sounds like a good direction. Not sure how final we'll be
            until there's a prototype, but happy to go in this
            direction. Wondering if we want to spec it out now or spec
            as you could do this but it's technically undefined
  flackr: I'm in favor of spec out and pushing for this to be the
          direction. We already have browser differences. It feels like
          spec will bring more attention
  <astearns> +1 to specifying behavior
  fantasai: Yeah, I think we put algorithm in spec. Just if we should
            require or if it's an example
  florian: This will be fiddly, so we should we write it with intent
           that it's normative so we get same behavior
  fantasai: Okay
  flackr: +1

  astearns: I didn't read all the options
  flackr: I did make prototype so we can play with it
  astearns: Is it option 7 or option 7 plus other things?
  flackr: Just option 7
  florian: I wouldn't be surprised if we have to revisit once people
           play with it, but until then this is a reasonable place to
           start
  astearns: Proposal: Specify option 7 as normative behavior
  astearns: Objections?

  RESOLVED: Specify option 7 as normative behavior

  astearns: Thanks flackr for doing the demo and going through options

Standardize snap point selection with multiple aligned boxes
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9622

  flackr: The spec says that when there's multiple boxes that are
          currently in a valid snap position, other than preferring
          targetted the browser can pick any box. I feel this makes
          spec things like snap events harder and I'd like to
          normatively define in these cases
  <TabAtkins> +1 to this proposal, and specifically the exact proposed
              list. I think flackr's example for keeping 5 and 6 in the
              current order makes sense
  flackr: Proposed a specific algo here that preserves the intern for
          focused elements but then items that are aligned in both
          axis, inner elements.
  flackr: Basically, trying to provide a standard answer for what is
          the snapped item.

  <@fantasai> TabAtkins, flackr's example isn't about the ordering,
              just about whether 5 makes sense as a rule
  <TabAtkins> disagree, I think it's a good example of why you *should*
              eliminate the large element from being the snap target
              before you discover there's an overlap in the axises

  florian: Here too I think good to have specific behavior encoded.
           Proposal here, are the rules because they make sense or is
           it having observed people in these cases this works better
  flackr: Constructed rules to what I think makes sense
  florian: Okay. Doesn't mean I object. But because we're not spec we
           may have browser differences so it gives us room to pick a
           good one. I'm not sure if it's easy to find use cases that
           depend on this, but would be good
  flackr: If it helps, Chrome is semi-random because depends on
          construction order
  florian: How would we go about finding live use cases that fall into
           this
  flackr: Only way you can observe which item is snapped is by which
          item is snapped when you change layout. Only way authors
          could do this today is scroll changes but relying on multiple
          aligned items
  florian: I guess you won't break much if you change
  flackr: It's a bit of an edge case

  astearns: There's talk in IRC about order of step 5 and 6
  fantasai: Step 5 is inner vs outer and 6 is about if you happen to
            have snap positions in two axis that come from same element
            you want that element rather than snap in one axis
  flackr: Yes, if you have a 2d you want something that aligns in box
          axis.
  fantasai: If you have a 9 grid you care about the one in the middle.
            Okay
  flackr: As I mentioned, 5 might not be necessary. If you have inner
          area aligned it could make snap not valid for the outer area
  flackr: No strong feelings about which one goes first
  <TabAtkins> I have medium-strong feelings that the current order is
              best.
  flackr: Sorry, I do. I posted an example. You have an inner item
          aligned. Technically both boxes in my diagram are snap for
          inner and outer. You probably want the aligned
  fantasai: But if they're aligned in both axis you skip set 6
  TabAtkins: If you take same case but more inner one inside a bit, it
             does argue better behavior is block axis to take the inner
             so you don't want it eliminated by match checking
  florian: I agree
  flackr: Agree with that
  fantasai: Okay

  astearns: Consensus on ordering. How much of this do we make
            normative?
  astearns: With my chair hat off, I'm in favor of spec the whole
            thing. Otherwise we may not find issues if people don't
            impl whole list
  flackr: My preference as well. And impact is subtle. Only observable
          today is what is aligned after layout change
  florian: I don't think there's complexity to give variance to
           browsers. Have a precise behavior seems good for complex
           demos
  fantasai: Where are snapping events defined?
  flackr: Scroll snap 2
  fantasai: They're not published so should do something about that.
            This becomes more critical for level 2

  astearns: fantasai are you okay spec the whole list as normative?
  fantasai: Okay with that. Could mark as at risk for L1, but should
            write it all out
  astearns: Proposal: Specify the whole list in this order as normative
            behavior
  flackr: I think it's not too hard to test. I'll help
  astearns: Objections?

  RESOLVED: Specify the whole list in this order as normative behavior

  fantasai: What should we do about scroll snap L2 draft? It's just
            an ED
  astearns: Is it ready for FPWD?
  fantasai: Don't know
  flackr: Have a PR in progress to add detail about event timing. This
          issue is in support of changing the targets of snap events to
          be a single element in each axis
  flackr: I guess that's to say I don't know
  florian: Land the PR and then publish?
  flackr: I think finishing the inflight PR would make sense
  astearns: fantasai, how about you open an issue saying we should have
            a FPWD for L2 and people can comment and get focus

CSS Lists
=========

CSS counter scope/inheritance is incompatible with HTML ordinals
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5477

  TabAtkins: A little while ago...several years...we talked about what
             changes to make to the counter scoping algo to make it
             workable as a mechanism to explain html lists
  TabAtkins: html lists have weird behaviors for legacy reasons. I
             tried to write a fix that fixed what's in the thread but
             there's close behavior it did not solve. A related change
             that would fix both is define a counter has an associated
             scope, wide or narrow. Default is wide where it's visible
             to children and following siblings until scope of same
             name is declared. Narrow is only visible to children
  TabAtkins: That matched how counters. You have an ol and outside of
             that you have an li, today because wide scoping the li
             sees the counter scope from the ol and will increment that.
  TabAtkins: There's some reasonable cases that are less intuitive due
             to wide.
  TabAtkins: Ability to declare scope to be narrow fixes this properly.
             It will be somewhat magic same way list item counter is.
             Will be slightly more reasonable for authors where they
             intent it to number a list among children
  TabAtkins: Concept also carried to when thinking about toggles.
             Having wide and narrow was necessary there. I think it's
             proved out that is useful.
  TabAtkins: Precise mechanics I have not figured out. Happy to take a
             resolution to figure out

  florian: Wide is default and narrow is opt-in to match html?
  TabAtkins: Correct

  astearns: Other questions or opinions?
  astearns: First thing would be revert previous?
  astearns: Proposal: Revert the previous resolution and the associated
            edits
  astearns: Objections?

  RESOLVED: Revert the previous resolution and the associated edits

  <TabAtkins> valid markup that gets weird currently is in
              https://github.com/w3c/csswg-drafts/issues/9076

  astearns: Proposal: The working group is interested in defining an
            opt-in narrow scope for counter resets. Exact syntax tbd
  TabAtkins: I expect it'll work same as reverse counter specs, but I
             haven't dug in enough to be certain
  astearns: Objections?

  florian: Question- you mentioned html has weird edge case. Narrow
           scope seems too clean to cover. Do we end up matching html
           or is there a bajillion corner cases where we're different?
  TabAtkins: I think this brings us all the way or very very close
             enough that browsers could call it good. I know wide
             behavior is web breaking if applied to html counters
  florian: We'll discover it soon enough. We create narrow and if it
           doesn't work people will tell us
  TabAtkins: I think remaining weird was list item counter and we
             resolved how to handle that. Where if you don't declare on
             an ol it happens. I'm not completely loaded on this and
             it's complex

  RESOLVED: The working group is interested in defining an opt-in
            narrow scope for counter resets. Exact syntax tbd

  TabAtkins: Issue #9076 was also covered in this discussion as well.
             It was the same case

Scroll Animations
=================

Blocking effects of timeline-scope
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/8915

  astearns: On the agenda to confirm we do want style containers to
            block timeline names from escaping. Is it container queries
            or style queries?
  florian: Container query on which style is based?
  astearns: Anyone have a better handle on this?
  florian: Superficially this seems fine to me
  astearns: We had already resolved we'd not allow timelines to escape
            a container of some kind

  miriam: Containment for container queries includes style. If you set
          up an inline size container you are implicitly adding style
          containment. That's scope the timeline name
  flackr: And that seemed unnecessary restriction and might want to
          scope the layout that has containment
  astearns: From my recollection we have other names that don't leak. I
            think just doing this to be consistent?
  florian: I think...I think it would be appropriate to spend more time
           on this. Containment is not just useful behavior, but
           guarantee that certain constraints are matched. Just because
           we can't immediately find a case where there's a problem
           doesn't mean there isn't one.
  florian: If we build this and the web depends on it but it doesn't
           work that breaks container queries. We don't want to defeat
           containment by doing this.
  vmpstr: I think this is an observation that lets us skip work in
          subtree. If these names escape the work becomes necessary
  flackr: Agree. If we want to leak better to say size containment
          doesn't require strict style containment
  flackr: Issue came about because using a container query
  florian: Types of containment don't have dependency, but container
           queries use both
  flackr: I think that's what we're getting at, the core. You should be
          able to leak names even if have container
  florian: So style is strict but not invoked
  miriam: Have to do part because counters escaping
  flackr: Need to think through
  florian: That means breaking style containment into two things. One
           is invoked by container and the other is not but is by
           content visibility.
  florian: I suspect explicit values are better if we go there

  astearns: We're not going to get to a resolution today. Let's take it
            back to the issue and try and work this through
  astearns: Thanks everyone for calling. There will be an extra hour at
            the start of next week's meeting.
  astearns: Please put your availability on the Feb wiki

Received on Friday, 8 December 2023 01:07:16 UTC