Meeting minutes
[css-text-4] Don't provide a language parameter for word-boundary-detection
rossen_: This was myles's item, requesting it to be added early.
rossen_: don't see myles on the call, anyone to bring that up?
w3c/csswg-drafts#6530 (comment)
github: 6530
[css-animations-2] Should the initial value for animation-duration be auto?
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> w3c/
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> 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 (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?
RESOLUTION: Go with option 2, "check for only the initial value (one list item, being auto)"
[css-backgrounds-4] Split CSS Backgrounds into separate specs?
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
https://
<drott> fantasai: we also have a spec called box-model
<drott> fantasai: spec that covers margins and paddings
<drott> fantasai: that would put us into quite a lot of spec
<drott> fantasai: backgrounds is fairly self evident, other splits are less evident
<drott> fantasai: divisions not super clean, border-... applies kinda a background
<drott> fantasai: might make it hard for people to look for - if we have it spread across 4 specs
<drott> SebastianZ: bringing in the box model, which wasn't covered in that issue
<drott> SebastianZ: idea was to have clear concepts borders, backgrounds, decorations
<drott> fantasai: border-image has a background to it - concerned as to: What's what?
<drott> fantasai: i like the idea of splitting it, but uncertain about how to do it cleanly, making it so it's obvious
<drott> 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
<drott> fantasai: don't have a good answer atm
<drott> rossen_: evident we have shifted in how borders and backgrounds are becoming more decorative
<drott> rossen_: over time, all of these concepts have progressed - seems reasonable for backgrounds, borders, decorations to be split
<drott> rossen_: to fantasai's point, we have some horizontal concepts in .. box model?
<drott> fantasai: they're interconnected: use case: author: where do i find the corresponding spec?
<drott> fantasai: question is: where do people find things
<drott> fantasai: box-model spec suitable place for box decorations?
<drott> SebastianZ: many new features coming to background and borders - if put in box-spec spec becomes very long
<drott> fantasai: backgrounds and borders being separate is ok, box decoration being a separate spec seems too much
<drott> rossen_: if we split this into only two specs, as a starting point
<drott> rossen_: let's say borders and backgrounds would be split off
<drott> 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
<drott> castastrophe: what would be the downside of a long spec?
<drott> castastrophe: we could also do cross-linking, and use it to a sub-specification?
<drott> jensimmons: sounds like there might not be enough consensus to resolve?
<drott> 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
<drott> Rossen: If that seems reasonable to you - perhaps we could go ahead with that proposal? Wanna address castatstrophe point?
<drott> SebastianZ: it's box-shadow that does not fit well into one of those specs
<drott> SebastianZ: discussion started with others raising that box-shadow should stand on its own
<drott> 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
<drott> 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]
background-* into css-backgrounds
<ntim> sounds good to me
border-* (including border-image) into css-borders
box-shadow into css-borders
box-decoration-break into css-box
Rossen_: any objections?
RESOLUTION: 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
border-radius adjustment formula
github: w3c/
fantasai: not prepared to present; suggest taking at F2F where we have better visuals
[css-background-4] add background-layers property to set everything but background-color
SebastianZ: initial proposal was to create background-layers property that is separate from background-color but is otherwise same as 'background' shorhtand
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> w3c/
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 adantages 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
<drott> fantasai: not a good idea, then you'd have to maintain two lists
<drott> fantasai: 1 for images, 1 for positioning
<drott> fantasai: sometimes there's use cases for splitting those things - but images and positioning are cascading together, so they should be declared together
<drott> 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?
RESOLUTION: add shorthand for background-* minus background-color, name TBD
language parameters for word-boundary-detection
github: w3c/
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
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
<iank_> (I believe we are the same - but I might be wrong - and would have to double check with Koji).
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?
RESOLUTION: remove auto () from word-boundary-detection, add keyword to word-break for this functionality
Animating font-palette
github: w3c/
-> www-archive@w3.org
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 anually retriefve color records from font
munira: that, we need to interpolate each color
munira: then overrid
munira: if someone can consider color nterpolation 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
munira: here you can see disrete vs smooth interpolation
munira: between pink and gray palettes
munira: when feature is implemented, can do it easily declaratively in CSS
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
munira: for that we introduce palette-mix() function to represent during animation
munira: here you can see the syntaxes of the new mix function
munira: it's siimlar 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
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?
<drott> svgeesus: mix() function wouldn't work for this
<dbaron> 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: w3c/
Rossen_: OK, wrapping up
<drott> Slides archive link: https://