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