- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Nov 2022 19:37:33 -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.
=========================================
Scheduling
----------
- Next long call is scheduled on Nov 30th
- Please reply to the email on the private list about if we should
cancel the week of 21 November (US Thanksgiving)
- jensimmons and fantasai are organizing a workshop next Monday on
Inline Layout:
https://fantasai.inkedblade.net/style/events/inline-workshop
Co-authoring CSS Design Principles with the TAG
-----------------------------------------------
- Please add feedback and thoughts on the model to collaborate with
TAG to the github issue (Issue #7835: Co-authoring CSS Design
Principles with the TAG).
CSS Shapes
----------
- RESOLVED: Publish css-shapes-1 CRD (Issue #6450: Updated CR of CSS
Shapes? Administrative Tracker For external review/
publication tracking issues)
CSS View Transitions
--------------------
- RESOLVED: Accept proposal (Issue #7956: Behaviour of the finished
promise)
- RESOLVED: view-transition-image-pair [is the property name] (Issue
#7960: CSS selector keywords)
- RESOLVED: UA styles on the pseudo-DOM stay in sync with author DOM
for any developer observable API (Issue #7812: When to
update the pseudo element styles)
- RESOLVED: Elements under content-visibility:auto element that skip
its contents are not eligible to participate in view
transition (Issue #7874: content-visibility: auto
elements are relevant to the user during a transition)
CSS Contain
-----------
- RESOVLED: Change to present tense for
ContentVisiblityAutoStateChanged (event and object)
(Issue #7603: Incomplete event definition for
ContentVisibilityAutoStateChanged)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Nov/0005.html
Present:
Rachel Andrew
Jake Archibald
Adam Argyle
Rossen Atanassov
Delan Azabani
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Daniel Holbert
Brad Kemper
Jonathan Kew
Chris Lilley
Alison Maher
Morgan Reschenberg
Florian Rivoal
Khushal Sagar
Jen Simmons
Bramus Van Damme
Lea Verou
Regrets:
Delan Azabani
Chair: Rossen
Scribe: fantasai
Scheduling
==========
Rossen: This is about 1/5 the number of Agenda+ issues. We will need,
to and will, have another long call at the end of this month
on November 30th
<astearns> not next week, week after (Nov 23)
Rossen: I sent an email to the private list about week after next
week, US holiday week, asking to see if people will be around
and whether to cancel next week or not
Rossen: Any other topics?
fantasai: 2 things: First- Jen and I are organizing a workshop on
inline layout next Monday
<jensimmons> https://fantasai.inkedblade.net/style/events/inline-workshop
fantasai: Second thing: can the chairs add the "needs edits" label
when we resolve on stuff
fantasai: Workshop is going to read through the spec top to bottom,
make sure people understand, see if it addresses their use
cases, and maybe find issues
Rossen: Any other topics?
Co-authoring CSS Design Principles with the TAG
===============================================
github: https://github.com/w3c/csswg-drafts/issues/7835
lea: As many aware, TAG maintains Web Platform Design Principles
document
lea: including principles for CSS
lea: Down the line will add principles to help authors with their APIs
lea: There is overlap between TAG and CSSWG, but need tighter
integration
lea: and e.g. fold in the documents fantasai is maintaining
lea: Some ideas that came up was, maybe there could be TAG-CSS TF
lea: or maybe have a label in our repo that the CSSWG monitors
lea: open to whatever ideas
Rossen: We already have a TAG/CSSWG TF called Houdini
lea: Houdini has a different focus, though. Can have multiple TFs
with different focus
Rossen: Also my way of nudging group, that we have a bunch of things
we still need to discuss for Houdini :)
Rossen: I think it's an opportunity for the CSSWG to engage and help
us drive better clarity
Rossen: and help implementers and authors
Rossen: Design principles in TAG have had good engagement, and
community seems to be fairly responsive to what's in there
Rossen: so huge +1
fantasai: The url you're linking to isn't a w3.org url
fantasai: github urls might not be around at various points, so
please get in the habit of using the w3.org URL. If its out
of date, update it
<lea> W3C URL: https://www.w3.org/TR/design-principles/
fantasai: Design principles: there's a document that I maintain on
the wiki
fantasai: maybe we can take that as a list of bugs to fix
<fantasai> https://fantasai.inkedblade.net/weblog/2019/designing-css
fantasai: There's also this article^
<florian> https://wiki.csswg.org/faq
florian: Also some interesting material to recycle in the FAQ, goes
into why CSS works the way it does
lea: I just wanted to add, one framing is that we're using this as a
pilot for how we work with other WGs more broadly
lea: Plan is to eventually collaborate with more WGs, so whatever we
decide should be more broadly applicable
fantasai: we could follow model of internationalization wg
fantasai: file issues in multiple repos
<lea> +1 to fantasai's idea
fantasai: e.g. file issue in tag repo and tracking issue in csswg repo
Rossen: Please comment on any ideas about scope or work mode in the
issue
CSS Shapes
==========
Updated CR of CSS Shapes? Administrative Tracker For external review/
publication tracking issues
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6450
chris: I'm whining about this thing not being published since 2014
chris: I went through all the commits since 2014 and updated the
Changes list
chris: added implementation, split privsec section
chris: I think this is ready to go
astearns: Thanks so much for doing that work
astearns: My preference would be to get the edits for reconciling
with gradient syntax first, but since you've done this
work, I'm happy to publish now and republish later with the
edits
chris: Sounds good to me
chris: If you thought those edits would be timely that would be fine,
but if you think it'll confuse people
astearns: No, I am now good for publishing and I can't guarantee that
my edits will be timely
Rossen: +1, thanks for the help chris this is great
Rossen: Objections to publish CRD?
RESOLVED: Publish css-shapes-1 CRD
Rossen: Again, thanks Chris, for doing the work
CSS View Transitions
====================
Behaviour of the finished promise
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7956
JakeA: When you start a view transition, you get an object back that
has some promises that you can use to track various things
JakeA: one of these is the "finished" promise
JakeA: question is, what should happen if the DOM change is
successful, but the transition is not?
JakeA: transition could not be successful in the case of
misconfiguration, e.g. duplicate IDs
JakeA: could also mean that transition is abandoned halfway through,
because more important transition coming in
JakeA: Originally spec would reject unless the transition gets to
final frame
JakeA: goes through the whole duration of the transition
JakeA: Proposing that it finishes whenever it gets to the end state
JakeA: we were influenced by animation.finish()
JakeA: and animation.finished which will resolve
<flackr> +1
JakeA: Desire to change this came after showing them the APIs, and
asking them to guess what it would do
JakeA: that seemed to be where people were leaning :)
Rossen: +1 for taking the time
Rossen: and alignment with animations is awesome
Rossen: any objections?
<bramus> +1
RESOLVED: Accept proposal
JakeA: Yes, animation needs to have stopped (even if not completed),
and user is looking at new state
CSS selector keywords
---------------------
github: https://github.com/w3c/csswg-drafts/issues/7960
khush: This is about resolving on the selector keywords
khush: last meeting we got through everything except #4
khush: This is a pseudo-element for providing isolation for blending
the old and new snapshots
khush: it's a leaf of the tree, only has old and new snapshots
khush: In terms of suggestions for naming, using word 'effect' or
'image', something to indicate that only nodes under here are
replaced elements
khush: and need to disambiguate from view-transition-group() which
can change position/size, and can have other view-transition
elements underneath it
khush: if we go with view-transition-image-foo, what's foo?
khush: Con of using "set" is that it doesn't indicate that DOM order
matters, "list" makes it look like any number of elements but
can only have two, and "pair" is nicest but sometimes there's
only one element
khush: e.g. if DOM element only exists on one side
khush: but if we're okay with that, my proposal is
view-transition-image-pair
fantasai: +1 to using a pair. conceptually you have two things being
transitioned independently
fantasai: wrt image, I'm less sure
JakeA: Tab wanted view-transition-images for brevity, but people
didn't like plural
fantasai: for brevity, could also drop the "image" part and just say
"view-transition-pair"
khush: "view-transition-group" and "view-transition-pair" not
immediately obvious what's the difference
khush: but I could go either way, "view-transition-pair" vs
"view-transition-image-pair"
Rossen: I think group vs pair will clash for many non-native
speakers, but wouldn't object
JakeA: It's not something folks will select a lot, people will select
it ... I don't know, if they want to remove isolation for some
reason?
Rossen: Even more reason to use a longer name
<flackr> Agree with Rossen, I have a slight preference for
view-transition-image-pair for clarity
Rossen: Proposed to resolve on view-transition-image-pair
<JakeA> +1 to image-pair
<khush> +1
<lea> as a non-native speaker, I don't think group and pair are that
frequently confused. Are there languages that do not
distinguish between group and pair?
<ydaniv> +1 to image-pair
Rossen: Objections?
RESOLVED: view-transition-image-pair
When to update the pseudo element styles
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7812
khush: Resolution in the last meeting, recap
khush: Feature creates a pseudo-element which has snapshot and
position from new DOM
khush: live, in sense that new DOM's painting changes will be
reflecting
khush: also if position / layout changes, will be reflected
khush: keeping these two in sync requires step where we do layout on
author DOM, and then generate a UA stylesheet
khush: do we conceptually see this UA style sheet generation as part
of style resolution
khush: e.g. if author changes something about the DOM element, should
they get those changes reflected in the pseudo-element if they
query via script?
khush: or do we treat this as an explicit step that's part of the
feature, and there's a specific point where we get these two
things synced up
khush: Last time we resolved on two explicit points
khush: this is only relevant if dev queries using script
khush: two options are:
khush: 1. Always keep in sync, treat as part of style resolution. If
you call getComputedStyle(), we'll have to resolve style,
generate styles and give an answer
khush: 2. Defined point on a frame, so you'll get stale data,
whatever was computed in the last frame
khush: I think keeping in sync is more correct, but it's also harder
because you have to do this loop to resolve style
khush: and we don't have a strong use case for why author would need
this to always be in sync
khush: so my suggestion is go with 2 defined points where we do this
step
khush: If they query after updating DOM, they'll get stale data
khush: and in the future if we want we can make it more correct
khush: so that all updates are guaranteed to reflect correctly
flackr: My preference is for reflecting up to date values, because
that's what will be presented on screen
flackr: so more consistent
flackr: We only have to do this if the author queries the style, so
most of the time we won't be doing this extra style update
emilio: What's the use case for querying these pseudo-elements, and
is there a defined answer assuming can target elements in the
pseudo tree?
emilio: Can't you write selectors that match multiple of these
elements?
khush: Use case is developer customization, could use information
about what the element's transform or size is
khush: can query existing API
khush: element's size will be its border-box size
khush: Some things not available now, e.g. ink overflow bounds
khush: unless we expose no API for it
khush: I don't have any strong use case, just a speculative maybe you
want to do a funky animation thing
emilio: My point is there's no good answer, if you write ::part() and
that something matches 2-3 elements, what does
getComputedStyle return?
khush: getComputedStyle has option to query an exact pseudo-element,
so you can pass ::view-transition-group(name) and get from
that element
emilio: A pseudo-element selector can match multiple pseudo-elements,
so is it well-defined what happens?
khush: Similar discussion for web animations API, if it matches
multiple pseudo-elements, treat it like querySelector and
return the first one
emilio: So well-defined, ok
emilio: If there's a good answer, then sure
emilio: I assume if it works for web animations, making it work for
getComputedStyle also makes sense
khush: I think flackr mentioned he preferred if we get these in sync
khush: Also my ideal preference, but would it be ok for
implementation complexity if we didn't do that for now, and if
a use case do it right later?
flackr: If you don't do that, values would always be a frame out of
date
flackr: wouldn't be able to use them
khush: Answer for first frame is correct
khush: after UA does construction
khush: It's only if you change as part of RAF as part of ??
khush: We don't retarget animations now anyway, so you'll get visual
jumps
flackr: I've seen authors do things in RAF every frame, to manually
position other elements in response to frames
vmpstr: My preference is not keeping it always up to date, it's
because there's a distinction between keeping styles
conceptually up to date
vmpstr: but this isn't technically style, but UA style sheet that
needs to be updated
vmpstr: ensuring that these values are kept up to date as style is
unnecessary, other than point flackr raised
vmpstr: so I would preferred to have a defined step and update
rendering, this is when the stylesheet is updated to reflect
DOM changes
vmpstr: reason is, from implementation perspective, we would have to
force style and layout to get this information to put in
stylesheet and it's a lot more forced work
vmpstr: seems a lot more rendering needs to be forced in these cases
fantasai: Why not allow both?
fantasai: text wrapping
fantasai: Make it a quality of implementation issue
fantasai: and if it becomes a problem, people can file bugs against
the implementations
fantasai: to improve their fidelity
<flackr> sgtm to leave it up to implementer
khush: I think for wording, use "should"
<flackr> This is also similar to the way reading scroll position may
be more or less out of sync on diff browsers
<khush> UA styles on the pseudo-DOM should stay in sync with author
DOM for any developer observable API
emilio: I think this is quite different from text-wrapping, it's an
API you're asking a question
emilio: I think we can't do hard thing if we do the hard thing if we
do the easy thing at the beginning?
emilio: People will rely on whatever answer you give them
fantasai: But if you give them more accurate answers, would that be a
problem?
emilio: Maybe relying on perf characteristics
emilio: If in a loop, and then changing DOM, implicitly relying on
existing behavior or else stuff becomes super slow
emilio: maybe I'm being too pessimistic...
emilio: My preference would be to define one answer
Rossen: More correct and harder way?
emilio: Don't particularly care. Do understand the implementation
complexity. Also don't see a lot of use cases for this to
begin with
Rossen: I want us to move forward here, take a resolution that's
going to unblock us quicker
<flackr> I suppose if we do the easy thing first we can always try to
change it to the more correct thing and consider the compat
risk then
Rossen: Going back to original proposal, that was for the easier one
which we can get to basically go to market quicker
Rossen: Get implementation experience and feedback, that's initial
ask?
khush: That would be nicer, that said my proposal was on the
assumption that this would be easy to change later
khush: that is, if we make API more correct we would not have a
compat risk
khush: but if we have a compat risk, then I'm ok to do the harder
thing first
Rossen: From point of view of API and its evolution, taking scoped
resolution here doesn't preclude us doing better later
Rossen: our decisions today are open to improvement tomorrow
khush: I didn't quite follow, what are we resolving on?
Rossen: The easier one
khush: Emilio was concerned changing later would be bad for compat
emilio: I think so
emilio: since these are relatively expensive updates
emilio: it's very easy to depend on not doing hard work
Rossen: If I'm hearing, you want to do harder work now now
emilio: I don't mind which we choose, as long as we choose one
khush: If we have to make one choice right now, and given uncertainty
about valid use case, we prefer developer ease over
implementer ease so we do harder thing first
emilio: No strong opinion on which one
emilio: My point is, I think if we start with easy one, we can't
switch to hard one
emilio: not leave it up to UA or future
emilio: let's just decide what we want
emilio: I've no strong opinion, but khush seems to think harder one
is better for devs
<khush> UA styles on the pseudo-DOM stay in sync with author DOM for
any developer observable API
khush: proposal ^
RESOLVED: UA styles on the pseudo-DOM stay in sync with author DOM
for any developer observable API
CSS Contain
===========
Incomplete event definition for ContentVisibilityAutoStateChanged
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7603
oriol: This issue covers different things, but only want to discuss
name of the event
oriol: Contain introduced ContentVisiblityAutoStateChanged event
oriol: This is inconsistent naming, since other events they use the
present tense and this is using past tense
oriol: There's even a proposed design principle in TAG about naming
events about avoiding past tense
oriol: just some legacy events are using past tense
oriol: So should we align with this design principle?
oriol: This feature has already shipped in Blink in July or such
oriol: but maybe it could still be compatible to change or maybe
Blink could support both for awhile or something like that
oriol: Firefox is implementing now, and WebKit has not implemented
this property yet
<fantasai> +1 for consistency
florian: Do you want to change the name of the event and the object
type or just the event?
oriol: It should be consistent
<flackr> I *think* this is the use counter for registrations:
https://chromestatus.com/metrics/feature/timeline/popularity/4328
<vmpstr> https://chromestatus.com/metrics/feature/popularity#ContentVisibilityAutoStateChangedHandlerRegistered
vmpstr: On Chrome status there is 0.048% that register a handle for
this event
vmpstr: It's a low usage but it's non-zero
Rossen: Is that above the threshold? Wasn't it 0.03%
vmpstr: Justification is that the state change has already happened,
different from click event where you can preventDefault
vmpstr: but that's why it was named in the past tense
oriol: Form controls also have change event for afterwards, can't
prevent change, and this event is in present
<flackr> Also animationstart, animationend, transitionstart,
transitionend
* fantasai suggests changing
<emilio> Yeah, lots of precedents there, `visibilitychange` /
`pageshow` / etc
<emilio> +1 for changing
Rossen: Can we resolve to change, and if we get feedback strongly
that this will be a problem, we can revisit?
Rossen: from spec point of view, right thing to resolve is in favor
of change
<fantasai> +1
RESOVLED: Change to present tense for
ContentVisiblityAutoStateChanged (event and object)
CSS View Transitions (continued)
================================
content-visibility: auto elements are relevant to the user during
a transition
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7874
vmpstr: content-visibility: auto not user relevant, they don't update
rendering, so we can't tell if they've been tagged with a
view transition name
vmpstr: so we'd like to say that such elements that are not relevant
to the user can't participate in the view transition because
they're far enough offscreen
flackr: My preference was element can participate, because could move
on screen, but none of its descendants
vmpstr: Sorry, meant the subtree elements cannot be detected as
participating in this transition
vmpstr: content-visibility: auto only affects content
flackr: With that correct, good with that
Rossen: Proposal?
vmpstr: Elements under content-visibility:auto element that skip its
contents are not eligible to be be discovered as
participating in view transition
<flackr> +1
florian: Seems reasonable
<fantasai> +1
Rossen: Objections to resolving on that edited proposal?
RESOLVED: Elements under content-visibility:auto element that skip
its contents are not eligible to participate in view
transition
Rossen: Reminder to reach out on private list if you have opinions
about Thanksgiving week call
Received on Thursday, 10 November 2022 00:38:13 UTC