- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 28 Jun 2023 19:36:25 -0400
- To: www-style@w3.org
=========================================
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.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jun/0006.html
Present:
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
Regrets:
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
animations
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
auto)
<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
shadow
SebastianZ: and we want to edit separately, and also make progress
separately
SebastianZ: Suggestion is into css-background-4 related to
backgrounds
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
decorations
<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
evident
fantasai: Divisions not super clean, border-... applies kinda a
background
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
issue
SebastianZ: Idea was to have clear concepts borders, backgrounds,
decorations
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
sub-specification?
jensimmons: Sounds like there might not be enough consensus to
resolve?
fantasai: Split into backgrounds 4 and borders 4
fantasai: backgrounds-* into css-backgrounds, borders-* into
css-borders
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
specs
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
https://github.com/w3c/csswg-drafts/issues/8726#issuecomment-1569020794
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
color
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
author
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
carefully
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
image
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
value
myles: Auto value in CSS is actually a function that takes a locale
string
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
languages?
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
scripts
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:
https://lists.w3.org/Archives/Public/www-archive/2023Jun/0004.html
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
values
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