- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Jul 2024 19:15:13 -0400
- 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.
=========================================
TPAC
----
- RESOLVED: Adopt masking requirement for CSSWG meeting room Th/Fri
at TPAC plus daily testing as documented in wiki
https://wiki.csswg.org/planning/tpac-2024#proposed-covid-protocols
CSS Contain
-----------
- RESOLVED: container-type does not force layout containment, but
does force an independent formatting context (Issue
#10544: Weaker form of layout containment for container
queries)
View Transitions
----------------
- RESOLVED: UA is allowed to capture old elements in low resolution
if they are off-screen (Issue #8282: Ignore offscreen
elements from participating in transitions)
- The group discussed the possibility of using 'auto' for issue #8320
(view-transition-name determined by element). The focus was on
the ability to interact with this 'auto' element and potentially
using an ID to allow interaction. Good progress was made on the
call and discussion will return to github for further refinement.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jul/0008.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Stephen Chenney
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Chris Lilley
Alison Maher
Romain Menke
Eric Meyer
Tim Nguyen
Florian Rivoal
Noam Rosenthal
Khushal Sagar
Alan Stearns
Brandon Stewart
Lea Verou
Sebastian Zartner
Regrets:
Mason Freed
Chris Harrelson
Miriam Suzanne
Chair: Rossen
Scribe: fantasai
Scribe's scribe: TabAtkins
Administrivia
=============
Rossen: expecting lighter participation from Google this week
Rossen: Any changes to agenda?
Rossen: We can tweak as we go if needed
In-room masking at TPAC 2024
----------------------------
astearns: Got some clarification from W3C CEO about what we can do
for TPAC
astearns: I'm proposing that we have an enforced masking for everyone
who comes to our Thu/Fri meeting in the room
astearns: and require daily testing for WG members
astearns: TPAC will provide tests, but not require them
<florian> +1
<fantasai> +1
lea: Posted https://lists.w3.org/Archives/Member/w3c-css-wg/2024JulSep/0074.html
lea: I'm not going to debate whether masks should be required, people
have opinions
lea: but our meeting is at TPAC, not just our meeting but other
events -- lunch, joint meetings, etc.
lea: We can't require other groups to wear masks
lea: requiring only for CSSWG members does little for transmission
lea: Requiring masking for some people not others isn't reasonable
lea: and eating lunch together indoors is counter to masking in-room
lea: What do people plan to do? That said, +1 to daily testing,
that's a no brainer
TabAtkins: The answer for people who can't be around unmasked people
is, they eat their meals outside and dial into joint
meetings
astearns: We don't have control over joint meetings, the only thing
we can control is our own meeting room on Thursday/Friday
Rossen: Monday-Wed no requirement
Rossen: but during travel?
astearns: Just a recommendation
<TabAtkins> "masking when other people aren't gives all the downsides
but none of the benefits" is absolutely wrong; I avoid
sickness while traveling by masking on my own.
lea: If people don't plan during joint meetings then we can refine
and allow for joint meetings
fantasai: My reading form the schedule is our Joint meetings are Mon/
Tue, not at our time
fantasai: wrt during joint meetings, we probably have to honor the
rules of whoever's hosting
fantasai: In terms of masking or not during other periods, we want to
consistently mask on Thu/Fri because covid lingers
fantasai: and +1 to what Tab said, people who want to be more careful
will sit outside
dbaron: A few of us in A Coruña did eat outside
dbaron: my understanding is that TPAC is providing food outside
dbaron: I would continue doing that
dbaron: I do plan to mask all the time indoors
<TabAtkins> I also will be eating outside if at all possible; I try
to whenever I'm in large groups to the extent that is
reasonable and possible.
<noamr> For the joint sessions, we can politely ask that people from
the other WG mask?
<astearns> noamr: yes, we can ask
Rossen: Proposal is to require masking in our room for thu/fri [and
testing daily]
<lea> -1 but I will not object
Rossen: Are there objections?
wiki: https://wiki.csswg.org/planning/tpac-2024#proposed-covid-protocols
RESOLVED: Adopt masking requirement for CSSWG meeting room Th/Fri at
TPAC plus daily testing as documented in wiki
CSS Contain
===========
Weaker form of layout containment for container queries
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10544
iank: When we did CQ, we split containment into layout and size
containment
iank: inline-size and block-size also
iank: We've been running into issues because of enforcing layout
containment
iank: When you CQ, you can't baseline-align, you can't allow abspos/
fixedpos to escape, scrollable overflow is broken, etc.
iank: side-effects are annoying for developers
iank: After investigation, the only restriction we really need is
that it establishes a new formatting context
iank: Lots of issues where devs ask us to remove these restrictions
iank: A few paths forward
iank: Most ideal one, which contains the most compat risk -- but
we're fine trying that, roll out behind a flag and work with
devs to fix sites -- is to change container type to not enforce
layout containment, just size containment
iank: and also establish a new formatting context
iank: That's my ideal proposal
iank: There are a couple other variants possible
iank: miriam would also like to take this variant
florian: I'm unsure. I understand the desire to relax these
constraints
florian: but not convinced about necessity
florian: e.g. abspos, if you allow to escape, then at a higher level
in the tree they could cause scrollbars
florian: which then change the layout space you have to lay out in
florian: which changes the width you're querying against
florian: So it's annoying, but the constraint was there to break the
circularity
florian: So yes, annoying, but are they necessary? And otherwise how
do you cope?
iank: Falls under "always move forward" constraint
iank: if you set up container, then can cause relayout
iank: principle is moving forward -- so you add scrollbars, and don't
remove them
emilio: I was going to bring up similar concerns
emilio: Last time I checked, browsers still somewhat inconsistent
with regards to circularities
emilio: has that changed?
emilio: Not opposed to removing, but...
emilio: For all browsers it's straightforward to do *something*
emilio: we break cycles similarly to webkit
iank: I don't think you or webkit are following the spec
emilio: For us it would be a bigger change, because circular case
would become a lot more common
iank: block-size circularity is pretty common, actually
iank: and I would like to fix this for web developers. It's the #1
complaint we receive for container queries
emilio: They should complain to the WG
iank: They have been
florian: "always move forward" approach, you're saying FF and WK
don't follow it well? How well is specified?
florian: Are we sure that we can gain interop on this approach?
florian: If so, then that's a path forward
florian: but if unproven, then maybe it's premature to resolve this
issue
florian: maybe need to make sure "always move forward" is
web-compatible
iank: We do it today, so definitely web-compatible
iank: FF and WK fail some tests because not doing it correctly
iank: it comes down to interleaving style and layout, and I think
we're the only ones doing it correctly today
florian: Is it well-defined enough?
iank: I also don't want to stall on this issue, because compat closes
<emilio> +1
fantasai: Can't speak for webkit, but in principle we want to support
authors making their use cases work
fantasai: Some concerns about style/layout interleaving being
underspecified -- I know Tab was handwaving at it in
anchorpos spec
fantasai: Would be good to get that specced thoroughly
fantasai: but I think we should support Chrome experimenting to see
how far we can push this in the direction that authors
expect
florian: Not exactly sure what the difference in practice is between
option 1 and 2, but seems fine.
iank: [proposal]
iank: Option 1 is introducing a new containment type, and then we
have to define what that does
iank: This option bypasses it
<iank> proposed resolution: container-type does not force layout
containment, but does force an independent formatting context.
RESOLVED: container-type does not force layout containment, but does
force an independent formatting context
fantasai: [asking TabAtkins and iank to work on defining style+layout
interleaving more thoroughly and bring it back to the WG
for review]
<TabAtkins> Yeah happy to get an edit into the spec and ask for review
View Transitions
================
Ignore offscreen elements from participating in transitions
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8282
noamr: We were discussing optimization to render new live element in
place of old element snapshot for when it's offscreen
noamr: but there were some concerns from WebKit wrt having two live
images
<noamr> https://github.com/w3c/csswg-drafts/issues/8282#issuecomment-2245542731
noamr: Discussed using transparent image, but that would create a
fade-in that's not necessarily what's wanted
noamr: Could make it implementation defined, but we lose
compatibility here
noamr: Another option is to figure out the implementation
noamr: Option I like the best is keep spec as-is, but say that if an
element is off-screen, the UA can capture it at low resolution
noamr: so if you have elements cross-fading from far away, might
appear blurry
noamr: Also, using view-timeline, authors that want to override can
do so
noamr: by giving a different view transition class and use a
different animation
noamr: Other option that was raised was to make one capture at the
beginning of the new element, and use that as the old element
khush: I like idea of having UA decide the rasterization range
khush: and browser can make trade-offs based on, is this a low-end
device, etc.
fantasai: I think the idea of doing low-res captures and a capture of
the new state is interesting. Not sure what makes the most
sense, trying to get Tim to sign on
noamr: Concern with using new image as old image is the semantic
difference
noamr: Want to also not create jank
fantasai: You mentioned could capture low-res or not at all
fantasai: If you have something that isn't captured; you're saying an
opt is a low-res or not capturing at all, if you realize
partway thru that you need the old image and didn't capture
it, what do you do
noamr: You'd see whatever it is you've captured
flackr: You'd either capture or not up front, and then have
transparency if didn't capture
vmpstr: Another option is we don't capture anything in the old, but
we also don't do the cross-fade by default
vmpstr: only display the new pseudo-element
fantasai: For "only display the new element", I think in that case
you'd need to somehow allow the author to select those cases
fantasai: so if *they're* doing a cross-fade they'll realize they
can't do it
fantasai: if their animation depends on the old image existing, so
they can adapt to it
fantasai: So on the "this is an optimization" perspective, doing a
low-res capture makes more sense to me
fantasai: In cases where the UA didn't capture the old el and
realized they need it, I think transparent might be
problematic
fantasai: So instead in that case, if you optimize too hard, just
take a capture of the new dom and use that instead
vmpstr: Low-res capture cross-fading to that might have artifacts
that are unappealing
fantasai: To be clear, not saying... you'd only use the new dom in
place of the old if you'd *failed* to capture anything at
all. If you have a lower capture you should use that
khush: On aspect of authors should be able to detect this
khush: for not capturing the old
khush: would it be enough to give the author a pseudo-class?
khush: UA would not do a cross-fade, and the author can then do a
customization
<vmpstr> +1
khush: [something] is not trivial to do
khush: implementation concerns were raised on WK side
noamr: Aside from being detectable, also want good default
noamr: I like the idea of having one capture of new element in the
rare case where we didn't capture anything
ntim: I would prefer low-res capture of the old state
ntim: I think that's the easiest thing to implement
ntim: for authors [garbled]
ntim: show nothing solution is more disruptive to the user
noamr: I would suggest something
noamr: We say that you can display low-resolution image of the element
noamr: that way we discourage showing totally transparent images
noamr: We don't have to resolve on what happens when we didn't
capture anything right now
noamr: we can capture a low-res image, and we discourage capturing
fully transparent
noamr: If there's an issue, we can resolve on it then; might not be
necessary
ntim: low-res of old capture seems reasonable to me
khush: Do we want authors to be able to detect this?
khush: low-res cross-fade could be looking bad
vmpstr: Use case would be e.g. grid-reorder where image is coming in
from far off the screen
khush: Right now you see the same content, but now you'd see
cross-fade between low-res and high-res
noamr: Can detect if something came from offscreen using view-timeline
noamr: e.g. in grid-reordering case
noamr: Maybe we can resolve on the degradation in a different
resolution
<khush> I'm ok with that
<vmpstr> yep, that's fine
ntim: Agree with noamr, detecting degradation should be a separate
issue so we can get the syntax right
ntim: but right now you can detect animations from off-screen
noamr: Proposed resolution, if old element is off-screen, UA can
capture in low resolution
flackr: Should we change the UA animation at least to use the new
image, since we know that's better?
noamr: That defeats the purpose
flackr: Developer animation would still work using old image
flackr: but the UA animation would not need cross-fade...
flackr: So this doesn't fix not needing to capture issue?
noamr: It fixes a perf issue, a lot less memory etc.
RESOLVED: UA is allowed to capture old elements in low resolution if
they are off-screen
view-transition-name determined by element
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8320
noamr: Automatically generating names
noamr: Proposal from Apple to do 'auto'
noamr: Previous agreement was to also come up with a proposal around
attr()
noamr: so I think we should move forward with 'auto' for now
noamr: The thing that wasn't clear in proposal, it creates pseudos
without names, so how can you animate them?
noamr: These are nameless pseudos that you can style with CSS
fantasai: That's what view-transition-class is for, right?
noamr: But you can't grab them with element.animate
noamr: unless we add an API to get via view-transition-class
khush: We conceptually convinced ourselves that if you need to do
specific targeting, then use explicit names
khush: but if you want to "do this to all with
view-transition-class", proper way to do in script would be to
use pseudo-elements
khush: and grab them with that
khush: I don't think we need to block on that, but could allow for
extension later
<fantasai> +1
<flackr> +1
<flackr> there are a lot of things that you can't do without the
PseudoElement interface
noamr: Also ok if some things not supported for auto because it's a
convenience feature. Can always fall back to generate view
transition names if you want to do something specific
noamr: What was worrying me about auto was that you start using it
and then realize you need to generate names later
noamr: but it's a trade-off
ntim: Could name it differently, to make restrictions more explicit
noamr: Maybe better as a function?
ntim: it could be another keyword, e.g. from-element or something
noamr: it's very similar to the view() function ...
<vmpstr> we then would have to exclude the new name from valid
view-transition-names (auto is already excluded)
fantasai: I think they're quite different.
fantasai: view does do lookup to the element itself, but so do other
features
fantasai: For 'auto' I think some of the restrictions you were
discussing, like not working for cross-document, there was
some discussion in the issue of using the ID of the element
if it has one
fantasai: I think that makes sense to build in, so we don't
necessarily have to restrict it from cross-doc transitions
fantasai: I think what you could say is if the element has an ID,
identify it by that. If the element is recreated, you're
mapping across the change. If it doesn't have an ID, you
use the object identity, and that doesn't work
cross-document
noamr: I think that works. But you can style a shadow part
noamr: like my-slider::part(inner-bar)
noamr: Right now the only way to style things in web components is to
use parts, those are also uniquely identifiably ID+part name
noamr: So we can say auto means ID and ID+part, and if that doesn't
exist use object identity
noamr: And then some APIs still aren't resolved, you can't reach that
element
fantasai: Yeah that's fine
<TabAtkins> (makes enough sense to me)
Rossen: From privacy / security point of view, are we OK?
Rossen: Have we thought about what using those IDs mean?
noamr: Doesn't really expose anything... it's like selectors
Rossen: Cross-doc?
noamr: This is same-origin
noamr: The whole security around cross-document transitions is based
on same-origin
noamr: Exposing view-transition-name and ID is same in that regard
khush: Trying to understand the ID proposals
khush: so it sounds like we'd have different layers of names now
khush: explicitly named is one, then IDs, then shadow DOM
khush: I'm curious if we've seen enough use cases for cross-document
to go down this rabbit-hole, rather than limiting to
same-document
khush: also some script APIs where where you need a string to identify
khush: Our goal is to give you something, but not uniquely identify
the pseudo-element
khush: What name do we use when we give a name for these in our
script APIs?
noamr: Seems a lot of details to work out, but made good progress.
I'll summarize in issue
Rossen: Ok, let's end here and pick up again next week
Received on Wednesday, 24 July 2024 23:15:46 UTC