[CSSWG] Minutes Telecon 2023-06-28 [css-animations-2] [css-backgrounds-4] [css-text-4] [css-fonts]

  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 Animations

  - RESOLVED: Go with option 2, "check for only the initial value (one
              list item, being auto)" (Issue #6530: Should the initial
              value for animation-duration be auto?)

CSS Backgrounds

  - RESOLVED: Adopt proposal above, background-* into css-backgrounds,
              border-* and box-shadow into css-borders, and
              box-decoration-break into css-box (Issue #7664: Split
              CSS Backgrounds into separate specs?)
  - RESOLVED: Add shorthand for background-* minus background-color,
              name TBD (Issue #8726: Add background-layers property to
              set everything but background-color)

CSS Text

  - RESOLVED: Remove auto () from word-boundary-detection, add keyword
              to word-break for this functionality (Issue #7193: Don't
              provide a language parameter for word-boundary-detection)

CSS Font

  - Munira introduced the proposal in issue #8922 (Proposal: Animating
      font-palette) and showed some slides
      ( https://lists.w3.org/Archives/Public/www-archive/2023Jun/0004.html )
      to further illustrate the new functionality. Feedback and
      questions are welcome in the issue.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jun/0006.html

  Adam Argyle
  Rossen Atanassov
  Oriol Brufau
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Paul Grenier
  Daniel Holbert
  Vladimir Levin
  Chris Lilley
  Peter Linss
  Dominik Röttsches
  Jen Simmons
  Miriam Suzanne
  Munira Tursunova
  Bramus Van Damme
  Sebastian Zartner

  Rachel Andrew
  Tab Atkins

Chair: Rossen

Scribe: drott

CSS Animations

Should the initial value for animation-duration be auto?
  github: https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1587313405

  fantasai: We changed animation-duration initial value to auto
  fantasai: But we need that to return 0 seconds for time based
  fantasai: someone? wanted to clarify when that triggers
  <fantasai> https://github.com/w3c/csswg-drafts/pull/8952
  fanatasai: Drafted a PR for that (triggers when animation timeline
             is at 0)
  fantasai: If there is only one list value, and that computed value
            is auto
  fantasai: Wanted to confirm with the working group - is the draft
            suitable? Which version do we want to go with?
  fantasai: Alternative is to allow multiple values, but all of them
            need to be auto

  flackr: The significant use case is: initial value of animation
          timeline should be covered
  flackr: Proposed PR is good in that regard, unless developer changes
          animation timeline
  flackr: Reason we didn't want to expose multiple values was: didn't
          want to expose the duration repeat behavior
  rossen: Any reasons for concern?
  rossen: Proposal to stick with single value?
  <fantasai> Options were:
  <fantasai> 1. auto values individually convert to 0s, can have a
             mixed list
  <fantasai> 2. check for only the initial value (one list item, being
  <fantasai> 3. check for the entire list being auto (but multiple
             values ok)
  rossen: No objections heard to go with single value?
  rossen: Based on that clarification, anyone changed their mind?

  RESOLVED: Go with option 2, "check for only the initial value (one
            list item, being auto)"

CSS Backgrounds
  scribes: fantasai & drott

Split CSS Backgrounds into separate specs?
  github-bot: https://github.com/w3c/csswg-drafts/issues/7664

  SebastianZ: Suggestion is to split up the CSS Background 4 spec
              into 3
  SebastianZ: Initial suggestion was to split into 2, but this didn't
              turn out very well
  SebastianZ: Idea is to focus each spec on one thing
  SebastianZ: because backgrounds covers backgrounds, borders, and box
  SebastianZ: and we want to edit separately, and also make progress
  SebastianZ: Suggestion is into css-background-4 related to
  SebastianZ: Borders 4 cover everything border-related
  SebastianZ: and CSS box-decorations-4 which covers box shadow and
              its longhands and anything else related to box
  <fantasai> https://www.w3.org/TR/css-box-3/
  fantasai: We also have a spec called box-model
  fantasai: Spec that covers margins and paddings
  fantasai: that would put us into quite a lot of spec
  fantasai: Backgrounds is fairly self evident, other splits are less
  fantasai: Divisions not super clean, border-... applies kinda a
  fantasai: Might make it hard for people to look for - if we have it
            spread across 4 specs
  SebastianZ: Bringing in the box model, which wasn't covered in that
  SebastianZ: Idea was to have clear concepts borders, backgrounds,
  fantasai: border-image has a background to it - concerned as to:
            What's what?
  fantasai: I like the idea of splitting it, but uncertain about how
            to do it cleanly, making it so it's obvious
  SebastianZ: Counter proposal? atm it's confusion: CSS Backgrounds
              and Borders, box shadow not mentioned in the title,
              mixing things
  e.g. box-decoration-break affects borders and background also
  fantasai: Don't have a good answer atm

  rossen: Evident we have shifted in how borders and backgrounds are
          becoming more decorative
  rossen: Over time, all of these concepts have progressed - seems
          reasonable for backgrounds, borders, decorations to be split
  rossen: To fantasai's point, we have some horizontal concepts in ..
          box model?
  fantasai: They're interconnected: use case: author: where do i find
            the corresponding spec?
  fantasai: Question is: where do people find things
  fantasai: box-model spec suitable place for box decorations?
  SebastianZ: Many new features coming to background and borders - if
              put in box-spec spec becomes very long
  fantasai: Backgrounds and borders being separate is ok, box
            decoration being a separate spec seems too much
  rossen: If we split this into only two specs, as a starting point
  rossen: Let's say borders and backgrounds would be split off
  rossen: Where to put decorations?
  fantasai: I think putting box-shadow into borders makes sense, it
            outlines the border
  fantasai: but box-decoration-break could maybe go into css-box
  fantasai: since it also affects margins / padding

  castastrophe: What would be the downside of a long spec?
  castastrophe: We could also do cross-linking, and use it to a

  jensimmons: Sounds like there might not be enough consensus to
  fantasai: Split into backgrounds 4 and borders 4
  fantasai: backgrounds-* into css-backgrounds, borders-* into
  fantasai: box-shadow into css-borders
  fantasai: box-decoration-break into css-box
  Rossen: If that seems reasonable to you - perhaps we could go ahead
          with that proposal? Wanna address castatstrophe point?
  SebastianZ: It's box-shadow that does not fit well into one of those
  SebastianZ: discussion started with others raising that box-shadow
              should stand on its own
  fantasai: box-shadow should go into the border spec
  fantasai: it's effectively functioning as a border
  fantasai: box-decoration-break would go into css-box; it affects
            margins and padding too

  rossen: Would the proposed split into borders 4 and backgrounds 4,
          with fantasai's described split suitable?
  plinss: I'm in favor of fantasai's proposal, but feel like shadows
          should go into backgrounds
  plinss: but I don't feel strongly
  plinss: it doesn't affect sizing
  fantasai: Neither does border-image
  Rossen: [summarizes proposal]
  <fantasai> background-* into css-backgrounds
  <fantasai> border-* (including border-image) into css-borders
  <fantasai> box-shadow into css-borders
  <fantasai> box-decoration-break into css-box
  <ntim> sounds good to me
  Rossen: Any objections?

  RESOLVED: Adopt proposal above, background-* into css-backgrounds,
            border-* and box-shadow into css-borders, and
            box-decoration-break into css-box

  SebastianZ: Thanks for resolving
  Rossen: It's important to get to topics that are not everyone's most
          important, not let them languish

Add background-layers property to set everything but background-color
  github: https://github.com/w3c/csswg-drafts/issues/8726

  <fantasai> -> summary comment
  SebastianZ: Initial proposal was to create background-layers
              property that is separate from background-color but is
              otherwise same as 'background' shorthand
  SebastianZ: The discussion went on and had different proposal to
              cover that use case
  SebastianZ: 1st was new shorthand described above
  SebastianZ: Another that includes everything except images and color
  SebastianZ: Third was a ::background() pseudo-element
  SebastianZ: Fourth was to add new keyword to skip overwriting the
  SebastianZ: and last was from Oriol to make no change, but teach
              authors to use background-color: revert-layer
  SebastianZ: My personal opinion is to have something like the
              original proposal
  SebastianZ: from my view it's the easiest way to achieve this as an
  SebastianZ: Other suggestions have advantages as well

  fantasai: Agree with SebastianZ
  fantasai: Tackling list-editing cascade is a big project, worth
            doing, but unnecessary
  fantasai: Just adding a shorthand is simple and solves the problem,
            biggest problem is naming the shorthand

  ntim: Problem is you'll have 3 properties with similar syntax, hard
        to know the differences
  ntim: You can do background: url, url, and then background-image:
        url, url; and then background-layers: url, url

  miriam: I agree with SebastianZ and fantasai
  miriam: I mostly wanted to push against the 'revert-layer' option
  miriam: Teaching authors to use revert-layer is great! But it has
          specific cases where that's useful solution
  miriam: but it requires adding new layers, and want to do that
  miriam: Doesn't make sense as a universal solution to this problem
  ntim: I had a proposal to put positioning into shorthand without
        image, to avoid confusion of three properties that can take an
  SebastianZ: That was my second option
  fantasai: Not a good idea, then you'd have to maintain two lists
  fantasai: 1 for images, 1 for positioning
  fantasai: Sometimes there's use cases for splitting those things -
            but images and positioning are cascading together, so they
            should be declared together
  fantasai: I'd advocate for original proposal, just need a shorthand
            name that makes sense

  Rossen: Sounds like many folks leaning towards original proposal
  Rossen: Would there be objections to resolve on the original
          proposal, and naming later?

  RESOLVED: Add shorthand for background-* minus background-color,
            name TBD

CSS Text

Don't provide a language parameter for word-boundary-detection
  github: https://github.com/w3c/csswg-drafts/issues/7193

  myles: This is a topic about line-breaking
  myles: We're implementing fancy line breaking, and I hear Chrome is
         doing the same
  myles: Interesting part is that it's based on words and phrases
         for CJK
  myles: Right now opt-in for CSS is word-boundary-detection with auto
  myles: Auto value in CSS is actually a function that takes a locale
  myles: This issue is for removing the locale string
  myles: 2 reasons we think it's good idea to remove
  myles: 1st, we don't have ability to do this in our platform APIs,
         can't distinguish language
  myles: 2nd is, if dictionaries aren't available for a language we
         fall back to normal rules, and that's fine, not a deal-breaker
  myles: so turn it on for some languages and not others, doesn't help
         authors and doesn't help implementers

  florian: Doing something like this has been on my to-do list for a
           long time, so thanks for the push
  florian: this is the direction I want to go in as well, and i18nWG
           as well
  florian: As for specific PR, I haven't reviewed yet, and will do
           this week
  florian: Needs more work
  florian: You extracted some bits to put into word-break, and that's
           fine, but leftover bits don't make sense
  <iank> From my understanding (I'd need to double check with Koji) I
         believe we support a new separate value for word-break.
  florian: We might actually want to remove the rest of
           word-boundary-detection entirely
  florian: and then there's some shared definitions if we're keeping
           it, and word-break with new value, so it needs more
           editorial adjustment
  florian: but we're getting somewhere
  florian: But I have a question, in the new PR
  florian: I've heard argued both ways before
  florian: so wondering what you had in mind
  florian: You said in intro, "this is for phrase detection"
  florian: but there was also suggestion of doing phrase grouping for
           languages like English, which do space separation
  florian: this would e.g. group noun with its article
  florian: Are you thinking MAY, MUST NOT, or SHOULD for such
  myles: First few topics you describe are editorial, don't need to
         discuss in WG
  myles: Last question, our linebreakers right now don't affect Latin
  myles: In the future we might want to add support
  iank: same here
  <iank> (I believe we are the same - but I might be wrong - and would
         have to double check with Koji).

  florian: So even though this is on my back burner, I will be able to
           within the week
  florian: so I certainly like to do this
  florian: I think we probably also want to ask i18nWG for part you
           didn't touch
  florian: for languages like Thai, effectively this is already
           baked in
  florian: Thai doesn't use spaces, but it uses dictionary-based word
           detection to find word breaks
  florian: that's by default
  florian: but the word-boundary-detection had option to turn that
           off, in case authors wanted to do it manually
  florian: Maybe because they are e.g. writing a language that's not
           quite Thai
  florian: So question for i18nWG is, do we want to preserve this
           ability? In which case we might need a keyword for that in
           word-break as well
  Rossen: Florian, can't tell if you're diverting resolution?
  florian: It's going in the right direction, but not ready yet

  myles: Proposal is to remove auto() function from
         word-boundary-detection and add keyword to word-break
  florian: Fully support
  Rossen: Any additional comments or objections?

  RESOLVED: Remove auto () from word-boundary-detection, add keyword
            to word-break for this functionality

CSS Font

Proposal: Animating font-palette
  github: https://github.com/w3c/csswg-drafts/issues/8922

  Slides: https://docs.google.com/presentation/d/1BFi93NfOUyziJRKciq6lnUOOo1hhgtibE10ZuELzCvo/edit#slide=id.g2554d2a7bfc_1_48
  Slides archive link:

  munira: Hi, I'm Munira, software engineer on Chrome team
  munira: Current way to animate font-palette is by JS
  munira: Let's say we want to animate between 2 palettes, in order to
          do that we need to first manually retrieve color records
          from font
  [slide 2]
  munira: After that, we need to interpolate each color
  munira: then override
  munira: if someone can consider color interpolation space
  munira: Lastly we need to override the colors from the interpolated
  munira: Needs to be done once in each frame of animation process
  munira: by making font-palette colors animatable we can animate
          using CSS
  [slide 3]
  munira: Here you can see discrete vs smooth interpolation
  munira: between pink and gray palettes
  munira: when feature is implemented, can do it easily declaratively
          in CSS
  [slide 4]
  munira: Here is syntax suggestion
  munira: font-palette is represented by custom identifier
  munira: and then animated
  munira: If we wanted computed style in the middle, what would we get?
  munira: We can't currently represent this
  [slide 6]
  munira: For that we introduce palette-mix() function to represent
          during animation
  [slide 7]
  munira: Here you can see the syntaxes of the new mix function
  munira: It's similar to color mix
  munira: it should use OKLab for interpolation
  munira: unless otherwise specified
  munira: We also can introduce a new animation type, by mix() function
  [slide 8]
  [slide 9]
  munira: Short version is animating font-palette using JS is
          complicated, but using the new function web authors can
          animate just using declarative CSS
  munira: If you want to find out more, see GH issue

  Rossen: Thanks for the presentation, and for compressing your
          presentation, was really great
  Rossen: I'm sorry to press you for time like this
  fantasai: What's the relation to the mix() function?
  svgeesus: mix() function wouldn't work for this
  svgeesus: ... as tabatkins pointed out in the issue
  svgeesus: You're interpolating palettes not colors
  fantasai: mix() should work, as long as start and endpoints are
            representable which they are
  <drott> Yes, issue is: https://github.com/w3c/csswg-drafts/issues/8922
          - feedback is welcome.
  Rossen: OK, wrapping up

Received on Wednesday, 28 June 2023 23:37:04 UTC