- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Nov 2024 19:02:24 -0500
- 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 Values
----------
- RESOLVED: Add <boolean-expr[...]> as a value definition syntax
function multiplying its argument into a boolean
expression microsyntax (Issue #10457: `<condition>` type
that other specs reference)
- RESOLVED: Publish a new WD of Values 5
Web Animations
--------------
- RESOLVED: Change Animation.progress to Animation.overallProgress
(Issue #8799: Progress APIs)
View Transitions
----------------
- RESOLVED: Close no change (Issue #10706: How are invalid types
validated?)
CSS Backgrounds
---------------
- RESOLVED: Add `border-area || text` to the background-clip syntax
(Issue #10696: Can you chain `border-area` and `text` in
`background-clip`?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Nov/0000.html
Present:
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
David Baron
Elika Etemad
Daniel Holbert
Vladimir Levin
Florian Rivoal
Gaurav Singh Faujdar
Alan Stearns
Scribe: florian
CSS Values
==========
Define "arbitrary substitution function"
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10679
<fantasai> https://drafts.csswg.org/css-values-5/#arbitrary-substitution
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
fantasai: Just asking if that's fine
<fantasai> https://github.com/w3c/csswg-drafts/issues/10679#issuecomment-2266364116
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
astearns: Glad Guillaume has already looked at this, he's a great
reviewer
astearns: Shall we leave it there and go on?
scribe: TabAtkins
`<condition>` type that other specs reference
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10457
fantasai: We have a lot of places
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://drafts.csswg.org/css-values-5/#boolean
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://drafts.csswg.org/css-values-5/#value-defs
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 other
specs?
fantasai: Right
<dbaron> btw my comment about naming was about sounding like
true/false rather than and/or/not
TabAtkins: We have an example of applying it to @container queries,
since that's a complex grammar
TabAtkins: Makes it easier to understand
astearns: [reads dbaron's comment]
TabAtkins: Lea also had this comment
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 functional syntax, not just `<boolean>`
by itself, there's something between the [].
astearns: Do we want any particular resolution?
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 replace 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 expression
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?
TabAtkins: I really want to shorten it to expr, I did that
reflexively when minuting
<kbabbitt> boolean-expr is fine too
<fantasai> PROPOSED: Add <boolean-expression[...]> as a value
definition syntax function multiplying its argument into a
boolean expression microsyntax
fantasai: I'm fine, though we don't usually use shortened terms
fantasai: It would be exposed in @property?
TabAtkins: No, not unless we say so
astearns: Let's propose it with boolean-expr
astearns: Objection?
RESOLVED: Add <boolean-expr[...]> as a value definition syntax
function multiplying its argument into a boolean expression
microsyntax
Publication
-----------
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-2452708704
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 significant changes I wanted to get a
heads up on it
astearns: Anyone on the call want more review before 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
RESOLVED: Publish a new WD of Values 5
<fantasai> https://wiki.csswg.org/spec/publish
[publication discussion]
[not relevant to an issue]
Web Animations
==============
Progress APIs
-------------
github: https://github.com/w3c/csswg-drafts/issues/8799
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 could 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
<fantasai> https://drafts.csswg.org/web-animations-1/#animation-effect
vmpstr: Yehonatan also said he thinks progress if fine and he'd find
currentProgress confusing
<dholbert> https://www.w3.org/TR/web-animations-1/#calculating-the-overall-progress
dholbert: WebAnim 1 uses overallProgress
dholbert: it differentiates that from "simple" iteration progress
<fantasai> https://drafts.csswg.org/web-animations-1/#dictdef-computedeffecttiming
astearns: "overall" is just a name in the algorithm, not part of the
exposed API?
dholbert: Yeah
<fantasai> .endTime
<fantasai> .activeDuration
<fantasai> .localTime
<fantasai> .progress
<fantasai> .currentIteration
fantasai: So this is on an object called getComputedTiming,
which has...
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`
<TabAtkins> yeah I'm kinda leaning toward overall
<fantasai> https://drafts.csswg.org/web-animations-1/#the-animation-interface
DavidA: .progress on getComputedTiming has existed for a while,
changing would 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`:
https://github.com/w3ctag/design-reviews/issues/994#issuecomment-2427287323
astearns: [summarizes Jeffrey's comment]
TabAtkins: Effect timing can run an animation multiple times, and
progress gives you progress of the iteration
TabAtkins: this is a 0-1 and done thing, so it's a different concept
than what the effect timing one is
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: Can tell from context
TabAtkins: Progress has a different interpretation, because [missed]
TabAtkins: AnimationEffect has a .endTime
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)
TabAtkins: Animation has a .startTime and no .endTime /
AnimationEffect has .endTime and no .startTime
vmpstr: Progress, one cycles per iteration, so wouldn't be the same
value at any particular point
TabAtkins: For progress, right
vmpstr: But if startTime and endTime both existed on the same object,
they would be the same, right?
TabAtkins: AFAICT from a quick read, they refer to the same type of
concept
TabAtkins: it's beginning of whole thing it's doing, vs iteration
astearns: Gist I'm getting, is people 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
RESOLVED: Change Animation.progress to Animation.overallProgress
View Transitions
================
How are invalid types validated?
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10706
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, though 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
RESOLVED: close no change
CSS Backgrounds
===============
Can you chain `border-area` and `text` in `background-clip`?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10696
fantasai: Suggestion to combine some of the background-clip areas,
particularly 'text' and 'border-area'
<fantasai> https://github.com/w3c/csswg-drafts/issues/10696#issuecomment-2284375965
fantasai: This seems fine to me
fantasai: Also a suggestion to allow arbitrary combos, don't think we
should 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 having 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
TabAtkins: once you get there, ordering dependency matters
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?
RESOLVED: Add `border-area || text` to the background-clip syntax
Received on Friday, 8 November 2024 00:02:56 UTC