IRC log of css on 2024-11-06

Timestamps are in UTC.

23:55:55 [RRSAgent]
RRSAgent has joined #css
23:56:00 [RRSAgent]
logging to https://www.w3.org/2024/11/06-css-irc
23:56:00 [Zakim]
RRSAgent, make logs Public
23:56:01 [Zakim]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:00:20 [kbabbitt]
kbabbitt has joined #css
00:00:29 [kbabbitt]
present+
00:01:06 [DavidA]
DavidA has joined #css
00:02:25 [dholbert]
dholbert has joined #css
00:03:29 [gfaujdar]
gfaujdar has joined #css
00:07:08 [gfaujdar]
present+
00:07:29 [dholbert]
present+
00:08:01 [vmpstr]
present+
00:08:17 [DavidA]
present+
00:12:15 [fantasai]
Topic: CSS Values Level 5
00:12:21 [github-bot]
Subtopic: [css-variables-1][css-values-5] Define "arbitrary substitution function"
00:12:40 [florian]
scribenick: florian
00:12:41 [fantasai]
https://drafts.csswg.org/css-values-5/#arbitrary-substitution
00:13:16 [florian]
fantasai: we do a bunch of substitutions, that check at computed value time it is valid
00:13:31 [florian]
TabAtkins: that's not appendix A in values 5
00:13:44 [florian]
s/not/now
00:13:50 [TabAtkins]
whoops
00:13:54 [TabAtkins]
i'll be right there
00:14:08 [florian]
fantasai: just asking if that's fine
00:14:09 [fantasai]
https://github.com/w3c/csswg-drafts/issues/10679#issuecomment-2266364116
00:14:15 [florian]
fantasai: other questions can be handle as a follow up question
00:14:56 [florian]
fantasai: guillaume asked about where these are valid
00:15:10 [florian]
fantasai: we might need to make that context dependent, based on which functions
00:15:22 [florian]
fantasai: that would be a follow up issue
00:15:46 [florian]
astearns: this is just spec definitions?
00:15:58 [florian]
fantasai: yes, for var. makes things more reusable
00:16:15 [florian]
fantasai: should not result in any changes in existing specs
00:16:22 [fantasai]
s/specs/features/
00:16:51 [TabAtkins]
astearns: glad Guillaume has already looked at this, he's a graet reviewer
00:16:57 [TabAtkins]
astearns: shall we leave it there and go on?
00:16:59 [TabAtkins]
scribe+
00:17:07 [github-bot]
Subtopic: [css-values-4][Editorial] `<condition>` type that other specs reference
00:17:20 [TabAtkins]
fantasai: we have a lot of places we'
00:17:32 [TabAtkins]
fantasai: we're using the not/and/or microsyntax - MQs, SQs, style queries, etc
00:17:35 [TabAtkins]
fantasai: and now if()
00:17:49 [TabAtkins]
fantasai: So we decided it would be more understandable to factor out that commonality into its own syntax "multiplier"
00:17:56 [TabAtkins]
fantasai: similar to * and # in grammars
00:18:15 [TabAtkins]
fantasai: So we introduced `<boolean [<grammar-here>]>`
00:18:26 [TabAtkins]
fantasai: This isn't for authors to write, it's part of our Value Definition Syntax
00:18:42 [fantasai]
https://drafts.csswg.org/css-values-5/#boolean
00:18:44 [TabAtkins]
fantasai: whatever's inside the brackets is a parameter for the boolean tree (it's the leaves of the and/or/not tree)
00:18:50 [fantasai]
https://drafts.csswg.org/css-values-5/#value-defs
00:18:56 [TabAtkins]
fantasai: It's defined here, and also in the valdefs list
00:19:16 [TabAtkins]
fantasai: [describes the syntax]
00:19:40 [TabAtkins]
astearns: Currently it's just in Values 5, hasn't moved to toher specs?
00:19:41 [TabAtkins]
fantasai: right
00:19:43 [dbaron]
btw my comment about naming was about sounding like true/false rather than and/or/not
00:20:02 [fantasai]
TabAtkins: we have an example of applying it to @container queries, since that's a complex grammar
00:20:15 [fantasai]
TabAtkins: makes it easier to understand
00:20:44 [fantasai]
astearns: [reads dbaron's comment]
00:20:48 [fantasai]
TabAtkins: Lea also had this comment
00:20:50 [fantasai]
TabAtkins: open to suggestions
00:21:06 [TabAtkins]
fantasai: we didn't want to go with "condition" because it's such a generic term, seemed like it would actually be less clear
00:21:12 [TabAtkins]
dholbert: "boolean-condition"?
00:21:29 [TabAtkins]
fantasai: note that it is a functinoal syntax, not just `<boolean>` by itself, there's something between the [].
00:21:59 [TabAtkins]
astearns: do we want any particular resoltion?
00:22:06 [TabAtkins]
fantasai: if we're happy, we can accept adding it to the VDS
00:22:19 [TabAtkins]
astearns: I think I'd like to noodle on the name a bit more
00:22:38 [TabAtkins]
astearns: but i don't really have an idea of what to repalce it with
00:22:54 [TabAtkins]
fantasai: we could make it longer with `<boolean-expression [...]>` but unsure if that's clearer
00:23:04 [TabAtkins]
dholbert: makes it clearer it's not just true/false in the programming sense
00:23:28 [TabAtkins]
dholbert: in the issue I saw a bunch of `<*-condition>` grammar terms used with it, so maybe `<boolean-condition>` would be good to follow it
00:23:51 [TabAtkins]
fantasai: What we're trying to say is that this is the epxression syntax, not the conditions themselves. The condition is inside the []
00:23:53 [fantasai]
<boolean[ <test> ]> = not <boolean-group> | <boolean-group>
00:23:53 [fantasai]
[ [ and <boolean-group> ]*
00:23:53 [fantasai]
| [ or <boolean-group> ]* ]
00:23:54 [fantasai]
<boolean-group> = <test> | ( <boolean[ <test> ]> ) | <general-enclosed>
00:24:03 [TabAtkins]
fantasai: [explains]
00:24:32 [TabAtkins]
fantasai: it's kinda a syntactic function in the same way as + is, just more sophisticated
00:24:47 [fantasai]
<container-query> = <boolean[ <cq-test> ]>
00:25:11 [TabAtkins]
astearns: I think I do prefer boolean-expr in that last example
00:25:13 [TabAtkins]
fantasai: ok
00:25:32 [kbabbitt]
I like <boolean-expression[...]> as well
00:25:34 [TabAtkins]
fantasai: so should we resolve to add boolean-expression?
00:25:48 [smfr]
smfr has joined #css
00:25:49 [kbabbitt]
boolean-expr is fine too
00:26:04 [TabAtkins]
TabAtkins: i really want to shorten it to expr, I did that reflexively when minuting
00:26:31 [fantasai]
PROPOSED: Add <boolean-expression[...]> as a value definition syntax function multiplying its argument into a boolean expression microsyntax
00:26:40 [TabAtkins]
fantasai: i'm fine, tho we don't usually use shortened terms
00:26:52 [fantasai]
fantasai: it would be exposed in @property?
00:26:55 [TabAtkins]
astearns: let's propose it with boolean-expr
00:26:57 [fantasai]
TabAtkins: no, not unless we say so
00:27:04 [TabAtkins]
astearns: objection?
00:27:17 [fantasai]
RESOLVED: Add <boolean-expr[...]> as a value definition syntax function multiplying its argument into a boolean expression microsyntax
00:27:51 [github-bot]
Subtopic: Republishing Tasks Permathread
00:27:54 [fantasai]
https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2452708704
00:28:18 [TabAtkins]
fantasai: We added in if(), inherit(), redefined attr() to match WG resolution so it's var-like
00:28:26 [TabAtkins]
fantasai: imported arbitrary-substitution function from variables
00:28:45 [TabAtkins]
fantasai: and imported the <syntax> production, since it's used in attr() now
00:28:52 [TabAtkins]
fantasai: We can resolve to publish now, or do it later if needed
00:29:00 [TabAtkins]
astearns: and this is just a regular WD?
00:29:11 [TabAtkins]
astearns: We can just use the wiki resolution
00:29:20 [TabAtkins]
fantasai: It's just enough significatn changes I wanted to get a heads up on it
00:29:30 [TabAtkins]
astearns: Anyone on the call want more review beofre this is published?
00:29:37 [TabAtkins]
fantasai: you can certainly review after; we'll still handle issues
00:29:48 [TabAtkins]
astearns: not hearing requests for additional review, proposed we publish a new Values 5 WD
00:29:57 [TabAtkins]
RESOLVED: Publish a new WD of Values 5
00:31:20 [TabAtkins]
[publication discussion]
00:31:25 [TabAtkins]
[not relevant to an issue]
00:31:37 [TabAtkins]
github-bot, end topic
00:33:00 [TabAtkins]
github-bot, topic https://github.com/w3c/csswg-drafts/issues/8799
00:33:00 [github-bot]
Topic: [web-animations-2] Progress APIs
00:33:00 [github-bot]
OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8799.
00:33:44 [DavidA]
DavidA has joined #css
00:34:07 [TabAtkins]
DavidA: we added a property field, it reflects the progress of the animation in a way that reflects the iterations of the animation
00:34:25 [TabAtkins]
DavidA: there is a .progress that exists in AnimationEffect that has a .getComputedTiming() function
00:34:32 [TabAtkins]
DavidA: but that only reflects the progress of the current animation
00:34:44 [TabAtkins]
DavidA: got some feedback that it coudl be confusing to share the name since they mean different things
00:35:05 [TabAtkins]
DavidA: wanted to consider renaming the Animation progress field either totalProgress or currentProgress
00:35:13 [TabAtkins]
DavidA: not sure which is better to go with
00:35:19 [TabAtkins]
DavidA: currentProgress is related to currentTime
00:35:29 [TabAtkins]
DavidA: but totalProgress more strongly reflects taht it covers all the iterations
00:35:51 [TabAtkins]
fantasai: okay so it's a .progress on AnimationEffect...
00:35:55 [TabAtkins]
DavidA: no, on Animation itself
00:36:00 [TabAtkins]
fantasai: is there one on AnimationEffect?
00:36:04 [TabAtkins]
DavidA: indirectly, kinda
00:36:11 [DavidA]
AnimationEffect.getComputedTiming().progress
00:36:55 [TabAtkins]
vmpstr: yehonatan also said he thinks progress if fine and he'd find currentProgress confusing
00:37:08 [dbaron]
Present+
00:37:09 [dholbert]
https://www.w3.org/TR/web-animations-1/#calculating-the-overall-progress
00:37:16 [TabAtkins]
dholbert: WebAnim 1 uses overallProgress
00:37:34 [TabAtkins]
dholbert: it differentiates that from "simple" iteration progress
00:37:40 [fantasai]
https://drafts.csswg.org/web-animations-1/#dictdef-computedeffecttiming
00:37:52 [TabAtkins]
astearns: "overall" is just a name in the algo, not part of the exposed API?
00:37:53 [TabAtkins]
dholbert: yeah
00:38:01 [fantasai]
.endTie
00:38:04 [fantasai]
.endTime
00:38:06 [fantasai]
.activeDuration
00:38:08 [fantasai]
.localTime
00:38:10 [fantasai]
.progress
00:38:12 [TabAtkins]
fantasai: so this is on an object called ComputedEffectTiming, which has...
00:38:15 [fantasai]
.currentIteration
00:38:34 [TabAtkins]
fantasai: and we're suggesting renaming .progress
00:38:46 [TabAtkins]
fantasai: we currently have .activeDuration, .localTime, .currentIteration
00:39:02 [TabAtkins]
DavidA: Oh, not the progress field on this object
00:39:06 [TabAtkins]
DavidA: The one on the Animation class
00:39:08 [astearns]
I kind of like `overallProgress`
00:39:22 [TabAtkins]
yeah i'm kinda leaning toward overall
00:39:32 [fantasai]
https://drafts.csswg.org/web-animations-1/#the-animation-interface
00:39:47 [TabAtkins]
DavidA: .progress on ComputedEffectTiming has existed for a while, changing woudl be hard
00:40:13 [astearns]
s/ComputedEffectTiming/getComputedTiming/
00:40:17 [TabAtkins]
fantasai: can you string multiple Animations together?
00:40:31 [TabAtkins]
DavidA: I'm not sure...
00:40:47 [kbabbitt1]
kbabbitt1 has joined #css
00:41:33 [TabAtkins]
dholbert: i'm slightly uneasy about "total" because it sounds like a summation
00:41:40 [TabAtkins]
+1
00:41:46 [fantasai]
+1
00:42:00 [TabAtkins]
astearns: I'd expect "total progress" to not change over time
00:42:25 [TabAtkins]
DavidA: okay so overallProgress is still something we could consider, or currentProgress
00:42:42 [TabAtkins]
fantasai: since timingeffect has currentTime and progress, what's the problem with just using progress on this?
00:42:53 [fantasai]
s/currentTime/localTime/
00:42:54 [TabAtkins]
fantasai: you'd get the context off of which object you're getting from
00:43:14 [astearns]
request for something other than `progress`: https://github.com/w3ctag/design-reviews/issues/994#issuecomment-2427287323
00:44:05 [TabAtkins]
astearns: [summarizes Jeffrey's comment]
00:44:26 [fantasai]
TabAtkins: effect timing can run an animation multipel times, and progress gives you progress of the iteration
00:44:40 [fantasai]
TabAtkins: this is a 0-1 and done thing, so it's a different concept than what the effect timing one is
00:44:57 [fantasai]
TabAtkins: can't change that one, but maybe use a different word here
00:45:13 [TabAtkins]
fantasai: i don't mind overall progress, i'm just saying we both have startTimes, they mean different things
00:45:55 [fantasai]
fantasai: can tell from context
00:46:15 [fantasai]
TabAtkins: progress has a different interpretation, because [missed]
00:46:48 [fantasai]
TabAtkins: AnimationEffect has a .endTime
00:46:56 [fantasai]
TabAtkins: Effect timing and animation have same interpretation of those
00:47:18 [dbaron]
(last 2 lines were answering vmpstr asking about whether startTime has the same meaning on both)
00:47:30 [fantasai]
TabAtkins: Animation has a .startTime and no .endTime / AnimationEffect has .endTime and no .startTime
00:47:49 [fantasai]
vmpstr: Progress, one cycles per iteration, so wouldn't be the same value at any particular point
00:47:53 [fantasai]
TabAtkins: for progress, right
00:48:06 [fantasai]
vmpstr: but if startTime and endTime both existed on the same object, they would be the same, right?
00:48:18 [fantasai]
TabAtkins: AFAICT from a quick read, they refer to the same type of concept
00:48:29 [fantasai]
TabAtkins: it's beginning of whole thing it's doing, vs iteratin
00:48:44 [fantasai]
astearns: gist I'm getting, is ppl think there's enough difference to have a different name
00:48:54 [TabAtkins]
fantasai: i'm okay with overallProgress
00:49:06 [TabAtkins]
astearns: so proposed resolution is we change Animation.progress to Animation.overallProgress
00:49:26 [TabAtkins]
RESOLVED: change Animation.progress to Animation.overallProgress
00:50:23 [github-bot]
Topic: [css-view-transitions-2] How are invalid types validated?
00:50:44 [TabAtkins]
vmpstr: in VT we have a notion of "types" you can specify
00:50:55 [TabAtkins]
vmpstr: there are some type names that are invalid, like "none" or anything with "-ua-*"
00:51:11 [TabAtkins]
vmpstr: Tim asked how these are validated in the JS APi, and suggested throwing a syntax error
00:51:19 [TabAtkins]
vmpstr: previously we resolved not to do validation in the script api
00:51:29 [TabAtkins]
vmpstr: we just use what the author specified, but ignore the invalid bits
00:51:36 [TabAtkins]
vmpstr: a silent filtering
00:51:40 [TabAtkins]
vmpstr: we'd like to maintain that
00:52:10 [TabAtkins]
vmpstr: also, the @view-transition supports types, and Noam's comment is that if there are invalid types, the pref is for the whole block to be invalid, otherwise it can cause unexpected transitions to happen
00:52:15 [fantasai]
sounds reasonable to me
00:52:44 [TabAtkins]
vmpstr: So I think we'd like close-no-change, tho it's not entirely clear to me that @view-transition reflects fully what I said above. But the script API side, at least, reflects what I said
00:53:01 [TabAtkins]
astearns: In my reading of Tim's post, it sounds like he's fine as long as it's defined.
00:53:08 [TabAtkins]
vmpstr: I have the same reading
00:53:15 [TabAtkins]
fantasai: I checked with Tim and he's ok with resolving
00:53:23 [TabAtkins]
astearns: so proposed resolution is close no change, it's already handled
00:53:28 [TabAtkins]
RESOLVED: close no change
00:53:36 [github-bot]
Topic: [css-backgrounds-4] Can you chain `border-area` and `text` in `background-clip`?
00:53:53 [TabAtkins]
fantasai: suggestion to combine some of the background-clip areas, particularly 'text' and 'border-area'
00:53:54 [fantasai]
https://github.com/w3c/csswg-drafts/issues/10696#issuecomment-2284375965
00:54:00 [TabAtkins]
fantasai: this seems fine to me
00:54:17 [TabAtkins]
fantasai: also a suggestion to allow arbitrary combos, don't think we shoudl do that. not worth it for almost all of the combos.
00:54:32 [TabAtkins]
fantasai: we can enable particular combos as needed; currently i think text and border-area is the only reasonable one
00:55:05 [TabAtkins]
TabAtkins: okay, it's a combination of the two areas, i thought it was gonna be an intersection
00:55:14 [dbaron]
does this preclude doing intersections later?
00:55:17 [TabAtkins]
smfr: yeah it saves you from ahving to do two backgrounds if they'd be the same
00:55:38 [TabAtkins]
fantasai: i think if you want an intersection we should have a specific syntax for it
00:55:50 [fantasai]
TabAtkins: once you get there, ordering dependency matters
00:55:57 [fantasai]
TabAtkins: interesting feature, but requires justification and development
00:56:14 [dbaron]
(clipping background to the text that is inside the <*-box> seems like not too unusual a request
00:56:15 [TabAtkins]
astearns: so proposal is to add `border-area || text` as a valid value
00:56:22 [TabAtkins]
astearns: no prejudice against more changes in the future
00:56:29 [TabAtkins]
astearns: objections?
00:56:43 [TabAtkins]
RESOLVED: Add `border-area || text` to the background-clip syntax
00:57:11 [TabAtkins]
github-bot, end topic
00:57:25 [dbaron]
(and I left a comment on #2)
00:57:45 [dbaron]
(I've been on the call for the last ~20 minutes, but don't want to make noise right now)
00:57:58 [zrhoffman1]
zrhoffman1 has joined #css
01:24:23 [astearns]
zakim, end meeting
01:24:24 [Zakim]
As of this point the attendees have been kbabbitt, gfaujdar, dholbert, vmpstr, DavidA, TabAtkins, dbaron
01:24:25 [Zakim]
RRSAgent, please draft minutes v2
01:24:27 [RRSAgent]
I have made the request to generate https://www.w3.org/2024/11/06-css-minutes.html Zakim
01:24:34 [Zakim]
I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
01:24:34 [Zakim]
Zakim has left #css