- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 8 Nov 2023 18:59:58 -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.
=========================================
Upcoming F2F
------------
- The group will make a final decision on dates next week after
coordinating with the AB meeting which is targeting a similar
time frame.
CSS4 Discussion
---------------
- Una introduced the community group that is working on helping
people understand and communicate about CSS by introducing naming
conventions that are clear and support discussion needs. The
presentation is available here:
https://lists.w3.org/Archives/Public/www-archive/2023Nov/att-0002/CSS-Next_Community_Group.pdf
- RESOLVED: The CSSWG supports this CG's efforts in defining levels
for CSS as a way for the community to understand and
communicate about batches of CSS features. (Issue #4770:
Let’s Define CSS 4)
CSS View Transitions
--------------------
- RESOLVED: type can accept any idents, except 'none' or '-ua-'
prefixes (Issue #9534: Resolve on descriptor/parameter
names)
- RESOLVED: at-rule is @view-transition, descriptors are 'navigation'
and 'type', 'navigation' grammar is "auto | none" ('type'
grammar already resolved) (Issue #9534)
- RESOLVED: A startVT() called on the new page will force-finish an
MPA VT even if a frame hasn't painted yet. (startVT()
late in the old page is still undefined) (Issue #9512:
Starting a same-doc view transition while a cross-doc
view transition is pending)
- RESOLVED: startVT() on the old doc is ignored if there's an active
MPA VT running, but its callbacks are still dispatched
(Issue #9512)
Filter Effects
--------------
- RESOLVED: Change backdrop-filter's edgeMode to mirror, pending any
objections (FXTF Issue #374: Backdrop filter clipping
with edgeMode="duplicate" creates discontinuity when
moving)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Nov/0001.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Emilio Cobos Álvarez
Yehonatan Daniv
Robert Flack
Paul Grenier
Chris Harrelson
Jonathan Kew
David Leininger
Vladimir Levin
Peter Linss
Eric Meyer
Florian Rivoal
Khushal Sagar
Miriam Suzanne
Brandon Stewart
Regrets:
Oriol Brufau
Lea Verou
Sebastian Zartner
Chair: Rossen
Scribe: TabAtkins
Upcoming F2F
============
Rossen: Are there enough votes to call the winter meeting?
florian: If we have enough info to make a decision, great, but
pointing out we were polling over 3 weeks, for the first two
of these the AB is also polling.
florian: Maybe best to avoid conflicts given we have three between
those.
florian: So maybe chairs should talk to AB chairs.
florian: Possible they'll be in the same city, so maybe that's ok.
But might be good to coordinate.
Rossen: Possibly. Or we just resolve and then tell them.
<astearns> https://app.rallly.co/invite/8EaQBagjc8j6
TabAtkins: We can rule out the first week.
florian: AB might be the first or second week. Ideally we don't
choose 3rd week and AB does 1st, or we both pick 2nd.
fantasai: I think AB is leaning toward second week.
fantasai: Why the poll missing a week between 2 and 3?
<dbaron> (I think there was a previous poll with more options in it.)
TabAtkins: I think someone had a conflict so we ruled it out early.
<astearns> skipped week is a TC39 meeting
Rossen: Okay, I'll ping AB chairs for more info and we'll make final
decision next week.
CSS4 discussion
===============
github: https://github.com/w3c/csswg-drafts/issues/4770
<una> https://docs.google.com/document/d/1ThJggjnuCbz94ckK5ds2UiedyrTrT5Y6V00RVTGgVEw/edit#heading=h.ynsedw1i03ds
una: I'm sharing a window with a presentation, link in chat
una: So issue 4770 started this discussion and this CG, but it's been
going on for years before that
<una> https://docs.google.com/presentation/d/1V3kyGahIl2P2i2J0dlHYhT97ssdfqyQuGpQtUar1aqE/edit#slide=id.g28bb9aacdd6_0_576
una: quick overview of why this is important and what our discussions
were
una: Ultimately CSS3 is a grouping of features covered in "level 3
specs", covers a wide range of features
una: So successful that it's still the most common term used to refer
to "modern CSS"
una: It's how people teach CSS, recruit for CSS jobs, etc
una: Not hard to find CSS3 in job requirements, in teaching syllabuses
una: Saw an oklch() with CSS3 logo attached to it
una: If you search for CSS on google, about half the courses have the
CSS3 logo in some way
una: So easy to see the impact of the term even today
una: Despite this being a fairly specific set of features that don't
line up with today's features.
una: css3.now lists these features, but that's not how the community
talks about it
una: How far we've come as an ecosystem, we have more features than
we ever thought possible when CSS3 started.
una: CQ, layouts, interactions on the web platform
una: So important to change how people talk about CSS
una: Post from dev graham about "what is modern CSS"
una: "modern" is too broad of a definition, can't pinpoint a point in
time or specific set of features
una: So that's the CG. Initially called CSS4 CG, but might be beyond
that, renamed to CSS Next
una: Looks to label features in a clear colloquial way to help people
understand CSS across the ecosystem
una: Other options are Baseline or the CSS Snapshot. Great but don't
think they provide the same impact as "CSS3"
una: Also runs into the same problems as calling something "modern"
una: They just don't have the same cachet either - ES2020, 2021, 2022
vs ES6
<fantasai> +1 the snapshots aren't appropriate for this use
una: So using "CSS" or "Modern CSS" just lacks the meaning we need
una: Better labels have value, even just from marketing standpoint
una: We talked about some goals
una: First, helping devs learn about CSS
una: Helping teachers teach about CSS
una: Employers hire about CSS
una: Help community understand the evolution
una: Some non-goals
una: Affecting the specs themselves.
una: We're not doing anything with the specs themselves.
una: Also out of scope is official documentation, we're not writing
docs
una: And not doing any spec work (should be done in the spec groups)
una: And not defining best practices or managing compat data
una: Our scope, instead, is figuring out the community's
understanding of CSS feature levels, developing and naming those
groups, and educating about those levels.
una: So far our resolution has been:
una: Here's the CSS3 set of specs
una: Roughly 2009-2012
una: CSS4 seems to work out nicely as things that postdate CSS3 for
about 5 years and are things that are now stable
una: and CSS5 is new growing features, just landing
una: In the future CSS6 will be early-stage features just now in
planning or not even there yet.
una: As part of this work we want to do some research, so we did some
early sorting of features into CSS4 vs 5
una: Still working on the final analysis of this
una: So we want to do a community pulse check, checking with the user
group and do some user research.
una: In terms of CSSWG, we're hoping for a few things
una: First, awareness of what we're doing, hopefully a positive
signal from y'all
una: Another is general feedback, particularly in our early sorting
of categories
una: In the process of making a prototype of the research
una: Finally, join meetings - biweekly (correct meaning: every
biweek), Mondays 8am PT/11 ET, 5pm CET. An hour before the CSS
meeting, but on Mondays
<chrishtr> This is an awesome proposal, and so needed. I love it!
<fantasai> Slides:
https://lists.w3.org/Archives/Public/www-archive/2023Nov/att-0002/CSS-Next_Community_Group.pdf
<fantasai> Archived link ^
florian: I'm supportive of the overall effort. Think I like what you
said about CSS4 onwards
florian: A little issue about CSS3 - we have a dfn of that but it
doesn't match what you said.
florian: Currently our CSS3 definition says "everything after CSS2",
so it can't be an immutable category.
florian: So someone needs to change the dfn of CSS3, either us or
y'all
<TabAtkins> (Fine with just changing it, our dfn was based on "we're
not doing any categories anymore")
chrishtr: I think this is a great proposal and very important.
chrishtr: The impact of HTML5 on people's interest in the web, and
getting momentum for people to build things that previously
people didn't think were possible
chrishtr: This has tremendous potential to move the midnshare to make
people recognize CSS has really advanced in leaps and
bounds.
fantasai: +1 to everything Una said, really excited you've picked up
this idea
fantasai: super supportive of what y'all're doing
fantasai: I think if there's any conflict with our Snapshot we can
just fix it
fantasai: And once the CG dfns have settled down and they're happy
with it, I think we should publish it thru CSSWG as a Note
fantasai: So have /TR/CSS3, /TR/CSS4, etc as a Note matching what the
CG comes up with
fantasai: For the Snapshots naming, using the dated versions of the
snapshots as a sub for this, that doesn't really work for
this. They're designed for a different purpose.
fantasai: Even if they were better named they just wouldn't be
suitable.
<florian> +1
<una> +1
Rossen: Do we need a resolution?
una: I think it would be a positive
fantasai: proposed: The CSSWG supports this CG's efforts in defining
levels for CSS as a way for the community to understand
batches of CSS features.
<florian> +1
<TabAtkins> +1
RESOLVED: The CSSWG supports this CG's efforts in defining levels for
CSS as a way for the community to understand and
communicate about batches of CSS features.
chrishtr: Should Una bring back specific proposals to the group about
what is CSS4?
Rossen: It's all in public, she can open an issue
fantasai: I think if Una has stuff she specifically wants reviewed,
an issue will ask us for a review
fantasai: And when the CG thinks they're done, they can ask us to
publish it as a Note thru the WG
<florian> sgtm
CSS View Transitions
====================
Resolve on descriptor/parameter names
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9534
khush: Related to a resolution we had a few weeks ago
khush: to define the at-rule for authors to request a cross-document
VT
khush: What was left was naming
khush: So this is to resolve on the naming
khush: proposal is `@view-transition`
khush: Two descriptors
khush: First, 'navigation', defines what navigations this at-rule
applies to
khush: Currently just "auto" and "none". "none" means don't do it at
all. "auto" loosely means "do it for all navs except reloads".
We have an issue for improving the precision.
khush: But intention is "auto" means "all navigations that make
sense".
khush: Other descriptor is 'type'. Related to a resolution we had
in #8960
<khush> https://github.com/w3c/csswg-drafts/issues/8960
khush: Allowing multiple transitions happening in your doc, and you
want to apply CSS depending on which is actually running.
khush: We defined how that worked for JS-based VTs, so this is adding
the same functionality to cross-document declarative ones.
khush: Naming options are 'type-list', to be consistent with classList
khush: Other is 'type' or 'types'. CSS doesn't seem to pluralize
words, so 'type' is our proposal
khush: And to make it obvious it's the same capability in the JS api,
whatever we pick here will be the same as we use in the JS API
khush: Last question for input
khush: There's a future extension to allow adding UA-defined keywords
into this list
khush: Like if we allow using this for declarative same-document
transitions, there will be a keyword to opt into that.
khush: So we want to make sure we can add UA-specified things to this
later.
khush: A few approaches - 1) the author supplies dashed-ident, so
UA-provided ones will be undashed
khush: Another is we reserve a prefix for UAs and don't let authors
use that
khush: We used that for animations already
khush: So our proposal is you can supply any custom ident, but it
can't start with `-ua-`
fantasai: I think overall this makes sense. Preference for -ua- over
dashed idents
fantasai: More consistent with classes to allow anything
<khush> +1
fantasai: Curious about the comment where the default value is the
empty list and there's no none value
fantasai: We don't have props that can take an empty value anywhere
in CSS, besides custom props
fantasai: So I wonder if 'none' is the reasonable thing
fantasai: Not something you have to specify, just to have a
consistent way to refer to the empty list
vmpstr: My understanding is because the blocks aren't cascading, it's
either set or not set, having an explicit default value isn't
necessary.
fantasai: I agree it's the same, it's just not a pattern we have,
where you can't say the default value.
TabAtkins: No strong thoughts, but a little odd to have an empty
value, we don't do anywhere except custom props
TabAtkins: Can just leave it out
TabAtkins: but generally, I'm slightly against omission being
impossible to express explicitly
TabAtkins: makes some types of code writing awkward to write
TabAtkins: can't pass value, have to pass out-of-band value
TabAtkins: so slightly for doing 'none' and making it a disallowed
name
TabAtkins: wouldn't block on it though
khush: I'm okay with that. We'd disallow "none" in the JS API too to
be consistent
vmpstr: I think that's fine. We'd need to resolve that "none" is not
a valid JS type
khush: So reserved keywords would be "none" and the -ua- prefixes
<TabAtkins> (Note that for the JS API you have to rule out all
ASCII-casing variations.)
Rossen: Can we resolve on that?
<fantasai> PROPOSED: type can accept any idents, except 'none' and
'-ua-*'
<fantasai> PROPOSED: type can accept any idents, except 'none' and
'-ua-*' ; 'none' represents no idents (empty list)
emilio: Do we need `-ua-`? We have `ua-` on font families
<fantasai> do we? I thought we had system-
vmpstr: We use `-ua-` for the keyframes right now, so I'd prefer
being consistent
<khush> +1 to Vlad
<TabAtkins> (I think -ua- is correct; these aren't well-specified by
the group.)
<fantasai> There aren't any font families starting with ua-. We have
system-ui, etc.
RESOLVED: type can accept any idents, except 'none' or '-ua-' prefixes
<khush> https://github.com/w3c/csswg-drafts/issues/9534#issue-1966514190
khush: This issue has names for a few other descriptors as well on
the first comment
khush: So the at-rule name and the descriptor names.
khush: Can we resolve on these?
TabAtkins: Sure.
fantasai: I'm fine in general. Slightly uneasy about "auto" because
it's vague.
fantasai: You're defaulting to same-origin, right? Previous we
discussed using 'same-origin' as the keyword, do we want to
do that?
khush: Right now we're same-origin but exclude reloads, and have an
issue to discuss whether typing a same-origin URL into the nav
counts too.
khush: So it's kinda complex, seems appropriate for 'auto'
fantasai: Ok, I don't have a better idea right now. Feel like it
could benefit from more explicit, but don't have a
suggestions
khush: So I suggest we resolve on "auto" now. We have an issue for
strictly defining "auto", we can talk about a more specific
name at that point.
fantasai: k
<fantasai> PROPOSED: at-rule is named @view-transition
<khush> @view-transition, navigation: auto | none, type
<fantasai> PROPOSED: @view-transition includes a 'navigation: auto |
none' descriptor
RESOLVED: at-rule is @view-transition, descriptors are 'navigation'
and 'type', 'navigation' grammar is "auto | none" ('type'
grammar already resolved)
Starting a same-doc view transition while a cross-doc view transition
is pending
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9512
khush: We can only have one VT at a time
khush: So what to do if the page starts a same-doc VT (script calls
.startViewTransition) while a cross-doc is running?
khush: In same-doc we take latest; if you start a new one it
force-finishes the old one
khush: Proposal is to do the same
khush: Some debate. If you were navigating and just arrived on the
page, do you actually want an abrupt transition and then start
the new one?
khush: In the extreme the doc hasn't drawn a frame yet
khush: So our proposal is we delay setting up a VT object on the doc
until the page has drawn one frame
khush: After that, if you call the JS API, the behavior is the same
as same-doc transitions, latest wins
flackr: I can think of lots of cases where devs use a transition for
an intro animation to the page
flackr: It's common to start a transition before the element is
drawn, that's why we delay a frame
flackr: So your proposal is that even if you call startViewTransition
before the first frame, it cancels the MPA?
khush: No the other way. Conceptually the cross-doc transition isn't
set up until a specific point in the doc lifecycle when a
frame has painted.
khush: Before that, there is no cross-doc view transition.
flackr: So in an MPA you've started the setup on the old page. For
consistency with frameworks that can do both SPA and MPA, I'd
strongly prefer the MPA transition be canceled if you start a
SPA VT even before the old page has painted
khush: Use-case?
flackr: There are frameworks that'll sometimes SPA or MPA depending
on various things. Would be hard to work with it only
sometimes canceling
khush: My problem is, if you do it before the page has drawn a frame,
then by design you'll have an abrupt transition.
flackr: Yeah but that's the same as if you call startVT() before the
previous VT was able to do anything useful
khush: It's about timing. If we defer it, then anything you do before
the page reveal contributes to the state of the DOM
fantasai: Just to confirm we're talking about calling startVT() on
the new page, not on the old page?
khush: Yes. There's a separate question about what to do with a VT on
the old page, but it's very unlikely anyway
flackr: I do just think it's still consistent with the SPA form - we
*have* already started the cross-doc VT by the time the new
page loads.
khush: This isn't a hill I want to die on, I can take either
resolution. Authors can just not call it if the behavior is
wrong.
khush: My proposal was just to hopefully get a "right behavior" by
default if you didn't think about it well
flackr: And my preference is to get a consistent answer between MPA
and SPA.
flackr: So my proposal is startVT() force-finishes the MPA transition
even if it hasn't captured the first frame yet
TabAtkins: overlapping VTs seems a mistake
TabAtkins: so prefer to do the predictable thing than trying to make
it "smart"
fantasai: Make it clear - startVT() on the *new* page that cancels
the MPA transition
TabAtkins: Just making it clear - startVT() late in the old page is
currently undefined then, right? And we'll figure it out
later.
khush: Yes. Let's resolve on the new-page startVT() now.
RESOLVED: A startVT() called on the new page will force-finish an MPA
VT even if a frame hasn't painted yet. (startVT() late in
the old page is still undefined)
khush: Could we decide on the old page behavior? Seemed to be
consensus on "don't cancel" - you're leaving the page and
capturing the last frame, doesn't make sense to cancel the MPA
khush: so proposed: startVT() is ignored on the old doc if there is
an active MPA VT
flackr: I think you still need to run update, though.
Rossen: Sounds like there isn't consensus quite yet, then.
khush: I'm happy with the resolution, we can bring it up if we find
issues.
RESOLVED: startVT() on the old doc is ignored if there's an active
MPA VT running, but its callbacks are still dispatched
Filter Effects
==============
Backdrop filter clipping with edgeMode="duplicate" creates
discontinuity when moving
----------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/374
flackr: So edgeMode=duplicate we specced creates a flickering
discontinuity
flackr: I propose we change the edgeMode for backdrop-filter to be
reflect
flackr: Which smoothly introduces new colors as they enter the edge.
It's *probably* what Safari is doing but I"m not sure, they
haven't commented.
flackr: I wanted this resolved before Interop 24 tries to standardize
this behavior
TabAtkins: I haven't looked at the details but I hate flickering, and
trust flackr to have the right option for making it look
good
fantasai: I think think we have someone working on backdrop-filter
issues and they're out right now. I have confidence in
flackr but I"d like to get their opinion on the issue.
Rossen: So postpone to next week?
TabAtkins: Alternative is resolve pending objections
fantasai: I don't understand enough to know if there might be
objections
fantasai: But I'm okay to resolve if it's clear that we might reopen
RESOLVED: Change backdrop-filter's edgeMode to mirror, pending any
objections
Received on Thursday, 9 November 2023 00:00:32 UTC