23:55:55 RRSAgent has joined #css 23:56:00 logging to https://www.w3.org/2024/11/06-css-irc 23:56:00 RRSAgent, make logs Public 23:56:01 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:00:20 kbabbitt has joined #css 00:00:29 present+ 00:01:06 DavidA has joined #css 00:02:25 dholbert has joined #css 00:03:29 gfaujdar has joined #css 00:07:08 present+ 00:07:29 present+ 00:08:01 present+ 00:08:17 present+ 00:12:15 Topic: CSS Values Level 5 00:12:21 Subtopic: [css-variables-1][css-values-5] Define "arbitrary substitution function" 00:12:40 scribenick: florian 00:12:41 https://drafts.csswg.org/css-values-5/#arbitrary-substitution 00:13:16 fantasai: we do a bunch of substitutions, that check at computed value time it is valid 00:13:31 TabAtkins: that's not appendix A in values 5 00:13:44 s/not/now 00:13:50 whoops 00:13:54 i'll be right there 00:14:08 fantasai: just asking if that's fine 00:14:09 https://github.com/w3c/csswg-drafts/issues/10679#issuecomment-2266364116 00:14:15 fantasai: other questions can be handle as a follow up question 00:14:56 fantasai: guillaume asked about where these are valid 00:15:10 fantasai: we might need to make that context dependent, based on which functions 00:15:22 fantasai: that would be a follow up issue 00:15:46 astearns: this is just spec definitions? 00:15:58 fantasai: yes, for var. makes things more reusable 00:16:15 fantasai: should not result in any changes in existing specs 00:16:22 s/specs/features/ 00:16:51 astearns: glad Guillaume has already looked at this, he's a graet reviewer 00:16:57 astearns: shall we leave it there and go on? 00:16:59 scribe+ 00:17:07 Subtopic: [css-values-4][Editorial] `` type that other specs reference 00:17:20 fantasai: we have a lot of places we' 00:17:32 fantasai: we're using the not/and/or microsyntax - MQs, SQs, style queries, etc 00:17:35 fantasai: and now if() 00:17:49 fantasai: So we decided it would be more understandable to factor out that commonality into its own syntax "multiplier" 00:17:56 fantasai: similar to * and # in grammars 00:18:15 fantasai: So we introduced `]>` 00:18:26 fantasai: This isn't for authors to write, it's part of our Value Definition Syntax 00:18:42 https://drafts.csswg.org/css-values-5/#boolean 00:18:44 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 https://drafts.csswg.org/css-values-5/#value-defs 00:18:56 fantasai: It's defined here, and also in the valdefs list 00:19:16 fantasai: [describes the syntax] 00:19:40 astearns: Currently it's just in Values 5, hasn't moved to toher specs? 00:19:41 fantasai: right 00:19:43 btw my comment about naming was about sounding like true/false rather than and/or/not 00:20:02 TabAtkins: we have an example of applying it to @container queries, since that's a complex grammar 00:20:15 TabAtkins: makes it easier to understand 00:20:44 astearns: [reads dbaron's comment] 00:20:48 TabAtkins: Lea also had this comment 00:20:50 TabAtkins: open to suggestions 00:21:06 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 dholbert: "boolean-condition"? 00:21:29 fantasai: note that it is a functinoal syntax, not just `` by itself, there's something between the []. 00:21:59 astearns: do we want any particular resoltion? 00:22:06 fantasai: if we're happy, we can accept adding it to the VDS 00:22:19 astearns: I think I'd like to noodle on the name a bit more 00:22:38 astearns: but i don't really have an idea of what to repalce it with 00:22:54 fantasai: we could make it longer with `` but unsure if that's clearer 00:23:04 dholbert: makes it clearer it's not just true/false in the programming sense 00:23:28 dholbert: in the issue I saw a bunch of `<*-condition>` grammar terms used with it, so maybe `` would be good to follow it 00:23:51 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 ]> = not | 00:23:53 [ [ and ]* 00:23:53 | [ or ]* ] 00:23:54

= | ( ]> ) | 00:24:03 fantasai: [explains] 00:24:32 fantasai: it's kinda a syntactic function in the same way as + is, just more sophisticated 00:24:47

= ]> 00:25:11 astearns: I think I do prefer boolean-expr in that last example 00:25:13 fantasai: ok 00:25:32 I like as well 00:25:34 fantasai: so should we resolve to add boolean-expression? 00:25:48 smfr has joined #css 00:25:49 boolean-expr is fine too 00:26:04 TabAtkins: i really want to shorten it to expr, I did that reflexively when minuting 00:26:31 PROPOSED: Add as a value definition syntax function multiplying its argument into a boolean expression microsyntax 00:26:40 fantasai: i'm fine, tho we don't usually use shortened terms 00:26:52 fantasai: it would be exposed in @property? 00:26:55 astearns: let's propose it with boolean-expr 00:26:57 TabAtkins: no, not unless we say so 00:27:04 astearns: objection? 00:27:17 RESOLVED: Add as a value definition syntax function multiplying its argument into a boolean expression microsyntax 00:27:51 Subtopic: Republishing Tasks Permathread 00:27:54 https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2452708704 00:28:18 fantasai: We added in if(), inherit(), redefined attr() to match WG resolution so it's var-like 00:28:26 fantasai: imported arbitrary-substitution function from variables 00:28:45 fantasai: and imported the production, since it's used in attr() now 00:28:52 fantasai: We can resolve to publish now, or do it later if needed 00:29:00 astearns: and this is just a regular WD? 00:29:11 astearns: We can just use the wiki resolution 00:29:20 fantasai: It's just enough significatn changes I wanted to get a heads up on it 00:29:30 astearns: Anyone on the call want more review beofre this is published? 00:29:37 fantasai: you can certainly review after; we'll still handle issues 00:29:48 astearns: not hearing requests for additional review, proposed we publish a new Values 5 WD 00:29:57 RESOLVED: Publish a new WD of Values 5 00:31:20 [publication discussion] 00:31:25 [not relevant to an issue] 00:31:37 github-bot, end topic 00:33:00 github-bot, topic https://github.com/w3c/csswg-drafts/issues/8799 00:33:00 Topic: [web-animations-2] Progress APIs 00:33:00 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8799. 00:33:44 DavidA has joined #css 00:34:07 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 DavidA: there is a .progress that exists in AnimationEffect that has a .getComputedTiming() function 00:34:32 DavidA: but that only reflects the progress of the current animation 00:34:44 DavidA: got some feedback that it coudl be confusing to share the name since they mean different things 00:35:05 DavidA: wanted to consider renaming the Animation progress field either totalProgress or currentProgress 00:35:13 DavidA: not sure which is better to go with 00:35:19 DavidA: currentProgress is related to currentTime 00:35:29 DavidA: but totalProgress more strongly reflects taht it covers all the iterations 00:35:51 fantasai: okay so it's a .progress on AnimationEffect... 00:35:55 DavidA: no, on Animation itself 00:36:00 fantasai: is there one on AnimationEffect? 00:36:04 DavidA: indirectly, kinda 00:36:11 AnimationEffect.getComputedTiming().progress 00:36:55 vmpstr: yehonatan also said he thinks progress if fine and he'd find currentProgress confusing 00:37:08 Present+ 00:37:09 https://www.w3.org/TR/web-animations-1/#calculating-the-overall-progress 00:37:16 dholbert: WebAnim 1 uses overallProgress 00:37:34 dholbert: it differentiates that from "simple" iteration progress 00:37:40 https://drafts.csswg.org/web-animations-1/#dictdef-computedeffecttiming 00:37:52 astearns: "overall" is just a name in the algo, not part of the exposed API? 00:37:53 dholbert: yeah 00:38:01 .endTie 00:38:04 .endTime 00:38:06 .activeDuration 00:38:08 .localTime 00:38:10 .progress 00:38:12 fantasai: so this is on an object called ComputedEffectTiming, which has... 00:38:15 .currentIteration 00:38:34 fantasai: and we're suggesting renaming .progress 00:38:46 fantasai: we currently have .activeDuration, .localTime, .currentIteration 00:39:02 DavidA: Oh, not the progress field on this object 00:39:06 DavidA: The one on the Animation class 00:39:08 I kind of like `overallProgress` 00:39:22 yeah i'm kinda leaning toward overall 00:39:32 https://drafts.csswg.org/web-animations-1/#the-animation-interface 00:39:47 DavidA: .progress on ComputedEffectTiming has existed for a while, changing woudl be hard 00:40:13 s/ComputedEffectTiming/getComputedTiming/ 00:40:17 fantasai: can you string multiple Animations together? 00:40:31 DavidA: I'm not sure... 00:40:47 kbabbitt1 has joined #css 00:41:33 dholbert: i'm slightly uneasy about "total" because it sounds like a summation 00:41:40 +1 00:41:46 +1 00:42:00 astearns: I'd expect "total progress" to not change over time 00:42:25 DavidA: okay so overallProgress is still something we could consider, or currentProgress 00:42:42 fantasai: since timingeffect has currentTime and progress, what's the problem with just using progress on this? 00:42:53 s/currentTime/localTime/ 00:42:54 fantasai: you'd get the context off of which object you're getting from 00:43:14 request for something other than `progress`: https://github.com/w3ctag/design-reviews/issues/994#issuecomment-2427287323 00:44:05 astearns: [summarizes Jeffrey's comment] 00:44:26 TabAtkins: effect timing can run an animation multipel times, and progress gives you progress of the iteration 00:44:40 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 TabAtkins: can't change that one, but maybe use a different word here 00:45:13 fantasai: i don't mind overall progress, i'm just saying we both have startTimes, they mean different things 00:45:55 fantasai: can tell from context 00:46:15 TabAtkins: progress has a different interpretation, because [missed] 00:46:48 TabAtkins: AnimationEffect has a .endTime 00:46:56 TabAtkins: Effect timing and animation have same interpretation of those 00:47:18 (last 2 lines were answering vmpstr asking about whether startTime has the same meaning on both) 00:47:30 TabAtkins: Animation has a .startTime and no .endTime / AnimationEffect has .endTime and no .startTime 00:47:49 vmpstr: Progress, one cycles per iteration, so wouldn't be the same value at any particular point 00:47:53 TabAtkins: for progress, right 00:48:06 vmpstr: but if startTime and endTime both existed on the same object, they would be the same, right? 00:48:18 TabAtkins: AFAICT from a quick read, they refer to the same type of concept 00:48:29 TabAtkins: it's beginning of whole thing it's doing, vs iteratin 00:48:44 astearns: gist I'm getting, is ppl think there's enough difference to have a different name 00:48:54 fantasai: i'm okay with overallProgress 00:49:06 astearns: so proposed resolution is we change Animation.progress to Animation.overallProgress 00:49:26 RESOLVED: change Animation.progress to Animation.overallProgress 00:50:23 Topic: [css-view-transitions-2] How are invalid types validated? 00:50:44 vmpstr: in VT we have a notion of "types" you can specify 00:50:55 vmpstr: there are some type names that are invalid, like "none" or anything with "-ua-*" 00:51:11 vmpstr: Tim asked how these are validated in the JS APi, and suggested throwing a syntax error 00:51:19 vmpstr: previously we resolved not to do validation in the script api 00:51:29 vmpstr: we just use what the author specified, but ignore the invalid bits 00:51:36 vmpstr: a silent filtering 00:51:40 vmpstr: we'd like to maintain that 00:52:10 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 sounds reasonable to me 00:52:44 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 astearns: In my reading of Tim's post, it sounds like he's fine as long as it's defined. 00:53:08 vmpstr: I have the same reading 00:53:15 fantasai: I checked with Tim and he's ok with resolving 00:53:23 astearns: so proposed resolution is close no change, it's already handled 00:53:28 RESOLVED: close no change 00:53:36 Topic: [css-backgrounds-4] Can you chain `border-area` and `text` in `background-clip`? 00:53:53 fantasai: suggestion to combine some of the background-clip areas, particularly 'text' and 'border-area' 00:53:54 https://github.com/w3c/csswg-drafts/issues/10696#issuecomment-2284375965 00:54:00 fantasai: this seems fine to me 00:54:17 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 fantasai: we can enable particular combos as needed; currently i think text and border-area is the only reasonable one 00:55:05 TabAtkins: okay, it's a combination of the two areas, i thought it was gonna be an intersection 00:55:14 does this preclude doing intersections later? 00:55:17 smfr: yeah it saves you from ahving to do two backgrounds if they'd be the same 00:55:38 fantasai: i think if you want an intersection we should have a specific syntax for it 00:55:50 TabAtkins: once you get there, ordering dependency matters 00:55:57 TabAtkins: interesting feature, but requires justification and development 00:56:14 (clipping background to the text that is inside the <*-box> seems like not too unusual a request 00:56:15 astearns: so proposal is to add `border-area || text` as a valid value 00:56:22 astearns: no prejudice against more changes in the future 00:56:29 astearns: objections? 00:56:43 RESOLVED: Add `border-area || text` to the background-clip syntax 00:57:11 github-bot, end topic 00:57:25 (and I left a comment on #2) 00:57:45 (I've been on the call for the last ~20 minutes, but don't want to make noise right now) 00:57:58 zrhoffman1 has joined #css 01:24:23 zakim, end meeting 01:24:24 As of this point the attendees have been kbabbitt, gfaujdar, dholbert, vmpstr, DavidA, TabAtkins, dbaron 01:24:25 RRSAgent, please draft minutes v2 01:24:27 I have made the request to generate https://www.w3.org/2024/11/06-css-minutes.html Zakim 01:24:34 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 01:24:34 Zakim has left #css