- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 14 Mar 2024 19:14:59 -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.
=========================================
CSS View Transitions
--------------------
- RESOLVED: Add a mutable .typeList to the VT object (Issue #9542:
Allow changing `types` using JS after (MPA) transition
started?)
- RESOLVED: Close no change (but add a note with some guidance)
(Issue #9526: Behavior of mismatching types between old
and new document)
- RESOLVED: :active-view-transition /
:active-view-transition-type(<ident>) (Issue #9972:
Rename :active-view-transition() pseudo-class)
CSS Transforms & Overflow
-------------------------
- dbaron introduced issue #9458 (Need to better define how transform
affects scrollable overflow) in order to get additional comments
on the issue as they work toward a definition to rectify the
discrepancy in definitions.
Media Queries
-------------
- RESOLVED: Accept this merged PR, re-add the fingerprinting sentence
to the privacy/security section and an inline issue in
the p-r-d section, and open a new issue on it to more
thoroughly discuss it (Issue #9475: prefers-reduced-data
question: special behavior when turned off and on post
page load?)
CSS Scroll Snap
---------------
- RESOLVED: We'll fix the problems in this issue, details TBD (Issue
#9917: Snap point selection when scrolling into view
should try to make targeted element visible)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Mar/0011.html
Present:
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
James Craig
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Chris Harrelson
Anders Hartvoll Ruud
Daniel Holbert
Jonathan Kew
Roman Komarov
Una Kravets
Vladimir Levin
Rune Lillesveen
Noam Rosenthal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Regrets:
Rachel Andrew
Chris Lilley
Penelope McLachlan
Lea Verou
Chair: astearns
Scribe: TabAtkins
CSS View Transitions
====================
Allow changing `types` using JS after (MPA) transition started?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9542
noamr: These issues are related, and not very big, just finishing up
noamr: We want to make types mutable.
noamr: Refresher, types let you define a "masterclass" for the whole
transition. Set a type when you start the VT, can pass types
to the function, then can select based on that type with the
VT pseudos
noamr: So you can use several transition styles in the same page
without having to manually swap them out with JS
noamr: So we wanted to allow changing those types on the VT object.
noamr: Proposed resolution has details, but it's to have .typeList on
the VT object, a DOMTokenList like .classList
noamr: And it works just like changing classes
noamr: We found this useful for cross-document VTs
noamr: sometimes, only after you get the reveal event you know what
the type is gonna be
noamr: maybe some image you expected has or hasn't loaded in the new
page, etc
noamr: So changing the types seems flexible enough
astearns: When you change the typelist in JS, it will no longer match
what was specified in your CSS for the VT
astearns: I'm guessing that's okay and intended, because as the VT is
going you may not have access to that CSS anymore
noamr: Right. First for SPA VTs you define the types in JS anyway.
For cross-doc though, you're correct
noamr: We read the VT from CSS in exactly two places - when you're
ready to leave the old doc, and ready to present the new doc.
noamr: In these cases we'll read the CSS, then in the events you can
change the types via the VT object
bramus: Like this in general.
bramus: Maybe we should also rename the types property that we pass
into the VT starting function
bramus: It's "types" in one function, "typeList" on the VT object
noamr: Yeah, it's called "type" when you start the VT, but there it's
an array, here it's a token list. This is equivalent to
"class" and "classList"
bramus: Ah then there's a typo in the spec saying "types"
noamr: Ah I'll fix
astearns: proposed resolution: mutable .typeList on the VT object.
Objections?
RESOLVED: Add a mutable .typeList to the VT object
Behavior of mismatching types between old and new document
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9526
noamr: Proposed resolution is to close no change, but wanted to
clarify what that means
noamr: For cross-doc VTs, right now you can specify a VT at-rule, and
say which types will be activated for the VT
noamr: On the old and new doc, you're not guaranteed to have the same
list of types
noamr: Right now, it's written and implemented that it doesn't
matter; if the old doc has type A and new has type B, it's up
to the author to deal with this.
noamr: CSS doesn't do anything to reconcile the lists
noamr: Given our previous resolution, if you change the types in the
old doc before you leave, it'll affect which elements are
captured, but then the type will be re-read from the new doc
and override it.
noamr: Whatever happens with the types stays in the doc where it's
defined.
noamr: So we think this is the most flexible and extensible pattern
right now
noamr: Just want to add an informative note to be careful about
changing types
TabAtkins: Sounded like if types mismatch you end up running VT with
types from new doc
noamr: Yes, but when you capture old state you use types from old doc
TabAtkins: Ok, makes sense
astearns: Proposed resolution, add an informative note but otherwise
close no change
RESOLVED: Close no change (but add a note with some guidance)
Rename :active-view-transition() pseudo-class
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9972
noamr: ntim brought this up
noamr: The pseudo-class for types is :active-view-transition()
noamr: Concern it could be confusing, you put the type name in the
function, but not clear that is the requirement. Could maybe
try to put a VT name in there instead
noamr: I'm inclined to not do anything here. I think this could be a
beginner error; VTs do require some learning to use properly.
noamr: But also :active-view-transition(*) just indicates there is
*a* transition running
noamr: We *could* adjust the syntax to make it clearer, but I'm
inclined to leave it as is
<fantasai> https://github.com//issues/9972#issuecomment-1952845753
fantasai: I can see Tim's confusion here, and I also don't have a
great idea to fix it
fantasai: except maybe to have active-view-transition not take an
argument, but have :view-transition-type() take an argument
fantasai: But I do see it's not obvious that if you're selecting on a
type, :active-view-transition is the selector you want
to use
bramus: An alt syntax I proposed is to merge the two. I like the name
"active-view-transition" because there is one ongoing.
bramus: My proposal is the argument syntax could be
`:active-view-transition(type <ident>)`, or you could just
say `:active-view-transition` to select regardless of type
khush: +1 to the reasoning on the name, you can use this without
an arg
khush: I also have an issue to suggest removing the ()s when you
don't need the type
khush: I do see that it's not obvious from a glance that the ident is
a type name, but this is also the only possible way to select
based on a type. You'd be hard-pressed to not find
documentation on this.
<vmpstr> issue for not needing asterisk in active-view-transition:
https://github.com/w3c/csswg-drafts/issues/9626
<noamr> I'm ok with ::active-view-transition /
::active-view-transition(type ident)
<TabAtkins> I lean to Bramus's suggestion
astearns: But Tim has the rebuttal that we shouldn't need to rely on
docs for this
noamr: I'm okay with Bramus's suggestion, :active-view-transition and
:active-view-transition(type <ident>)
<khush> How about active-view-transition-type(*)?
fantasai: I don't think we've ever had a syntax where we name the
value we're about to give, especially when it's only one
possible type
fantasai: Yeah, could go with :active-view-transition-type(), it's
getting long but it's very clear
noamr: Could also separate it into :active-view-transition, then
:view-transition-type()
bramus: But then you'll have to update your CSS if you start
conditionalizing on a type?
TabAtkins: You're already having to change it, this is just changing
the name *as well*
fantasai: I do think :active-view-transition-type() is the clearest,
but it is indeed super long
bramus: Confusing about :active-view-transition-type() is you can
have a VT that doesn't have a type
bramus: But you might want to select based on when the VT
specifically *doesn't* have a type
<fantasai> :active-view-transition / :active-view-transition-type()
fantasai: Yeah, then the empty parens would select that
noamr: Right, so separating the naming does separate the concerns
khush: I like these, but think we could remove the "active" prefix
from the second if it's too long
<TabAtkins> (I think we should remove "active" from the function.)
<fantasai> TabAtkins, we already have ::view-transition though
<fantasai> so ::view-transition and :view-transition would invite a
lot of typos...
bramus: If you don't specify a type, and use
:active-view-transition(*), would that be equivalent to
:active-view-transition?
noamr: I'd say we just drop the asterisk syntax then, since the
no-arglist version does it
bramus: Just wondering if we want to handle a case where you want to
select a VT with *any* type (but not an untyped one)
fantasai: Don't see a use-case for that right now
bramus: Yeah, we can add it later
proposed resolution: :active-view-transition /
:active-view-transition-type(<ident>)
RESOLVED: :active-view-transition /
:active-view-transition-type(<ident>)
(this also closes 9626)
CSS Transforms & Overflow
=========================
Need to better define how transform affects scrollable overflow
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9458
dbaron: Question is how to do this quickly. I think I should just
intro it and then discuss in the issue.
dbaron: Two underlying issues here, perhaps should have separated
them.
dbaron: One of the two affects many testcases you'd write for the
second one.
dbaron: One problem, Transforms and Overflow both have a definition
of how transforms affect scrollable overflow, and they
disagree
dbaron: It appears blink/webkit implement overflow, gecko implements
transform
dbaron: Transform says transformed elements affect overflow both at
their initial position and their transformed position
dbaron: Overflow says they only do it at their transformed position
dbaron: Ian has a comment that he strongly prefers the blink/webkit
behavior, he thinks devs use this to avoid contributing to
overflow sometimes
dbaron: Second issue, we keep running into issues where the fact that
impls do scrollable overflow by wrapping the thing inside the
scrollbars with a block, and we somehow word the spec to
avoid actually mentioning that
dbaron: Underneath, when impls do overflow by wrapping things in a
block, if the last thing in the block is transformed up, if
you use the Overflow spec dfn, there's nothing left to keep
the scrollbar exposing that last bit. But impls do reserve
that space.
dbaron: We keep working around the issue, but I think this isn't
doable. And I don't think we can remove it. So we should
define it.
dbaron: So this is complicated. I'd like people to say what they
think in the issue.
kizu: I'll comment in the issue. Note there's an Oriol proposal about
::contents pseudo, because I think this also includes this.
<kizu> Issue for the contents pseudo-element: github.com//issues/2406
astearns: Okay, taking this back to the issue. Thanks for the intro.
astearns: I'll leave it to David on whether to break this into issues
fantasai: As the editor of Overflow, I'd love it if we can settle on
a description, this is one of a handful of things that are
blocking CR
Media Queries
=============
prefers-reduced-data question: special behavior when turned off and on
post page load?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9475
florian: For most MQs, you want the MQ to react as the env changes
florian: If window resized, (width) should change
florian: (prefers-reduced-data) is not one of these
florian: If you've already loaded heavy assets, then user flips to
wanting reduced data, you don't want to throw away what
you've already loaded and pull down new ones
florian: As currently specified this is technically fine, the spec
doesn't specify how UAs should flip this MQ.
florian: So UA is *allowed* to be smart, and could just not switch it
to preferring reduced data until the next page load.
florian: If the WG agrees with that interpretation, then a recently
merged PR is fine, because it calls this out with a note.
But if the WG disagrees we should remove it and figure out
what the behavior *should* be
florian: I think the issue was converging on agreeing so the note was
just merged a little fast, but if there's disagreement we
should hear it
flackr: I agree that preserving the value is most often going to do
the right thing, but it does preclude future fetches for the
same page from reducing their data usage
flackr: So maybe there's some better solution? Script should be able
to tell what the current value is.
flackr: But for long-running pages, it would be nice to know that the
data is reduced *now*
astearns: Was gonna say the same thing, the note does say you can
wait until next page load, but doesn't preclude updating at
next resource load
flackr: Yeah, but I was suggesting a separate script-visible value.
Right now scripts can only observe the MQ value.
dbaron: The discussion made me think that it might be desirable to
have a functional syntax for the resources rather than an MQ
dbaron: Because if you want to distinguish heavy vs light resource at
time of loading, that might make more sense as part of the
value rather than as part of the MQ
dbaron: But doing it *only* as resource selection might make it hard
to vary other styling
<argyle> save-data http header
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Save-Data
fantasai: Webkit has concerns about prefers-reduced-data
fantasai: Concerns on abuse by websites, and agree with dbaron that
it's better to put choice of resource loading on UA to
decide
astearns: "general concerns" with the feature doesn't necessarily
interact with this note though, if we have the MQ?
fantasai: Yes. *If* we have the MQ, then loading behavior is ...
<fantasai> Media queries don't have a history effect, you apply the
media query except sometimes you maintain the effect of
the previous media query if it changed recently enough...
<fantasai> Media queries aren't the right way to solve this problem
florian: One mitigation is this is not an MQ expected to change
regularly, it changes *sometimes*
florian: But we don't expect users to flip this regularly. It's a bit
of an edge case.
florian: Second part of the issue though, is the PR removed an inline
issue about adding a privacy/security section to the spec (
it's been added, so that makes sense), but there's also a
suggestion to add something about reduced data because it
can potentially expose sensitive data about the page user's
economic station?
astearns: It sounds like the inline issue was removed correctly
because the section is now in there, but perhaps there
should be another inline issue for this specific bit?
florian: The issue was also about this specific case, which wasn't
added.
<argyle> this the fingerprinting section
https://drafts.csswg.org/mediaqueries-5/#mq-prefers-security
TabAtkins: Having the ability to query reduced data rather than
baking into img seems worthwile. Strategy could be to just
use colors instead of images when reduced.
TabAtkins: but agree that it is better to put the source selection
into the resource itself (see srcset)
TabAtkins: so while we can add a usage recommendation pointing to the
image function / srcset and use that for resource selection
TabAtkins: and only use that when changing styling strategy
TabAtkins: Seems still important to do this sort of styling switch in
these cases
florian: I think my proposal is to accept the PR as it landed, it's a
reasonable note.
florian: But also open issues for the rest of the things we said
today, there are several good points.
florian: But as long as we have the feature, the added note seems
right
florian: Seem reasonable?
<TabAtkins> +1
astearns: Seems reasonable to me
fantasai: The issue that we're removing is about undesired
fingerprinting and adding a privacy/security section. That
wasn't added?
florian: The privacy/security section was added, but the
fingerprinting wasn't added
TabAtkins: can we put that sentence in the privacy security section?
florian: Do we want a more thoughtful discussion in the privacy/
security section?
florian: Proposal is to put that fingerprinting sentence in the
privacy/security section, and open an GH issue about
expanding it.
astearns: Propose to accept this merged PR, re-add the fingerprinting
sentence to the privacy/security section, and open a new
issue on it to more thoroughly discuss it.
fantasai: I think we'd also prefer the issue in the p-r-d section so
it's obvious to people discussing it
argyle: I think it's slightly awkward to call out p-r-d when it's
doing something new in fingerprinting, because the other MQs
do similar things - the highlevel warning that they're *all*
fingerprinting vectors, and p-r-d isn't new here.
argyle: If I prefer reduced contrast or forced colors you can also
make decisions about me
argyle: So that's why I was preferring one high-level security
warning about these being fingerprinting vectors.
argyle: So I'm questioning why this is unique here.
fantasai: I think the potential for abuse is higher for income
differentiation
astearns: I think it's useful to discuss the affected populations
for each
astearns: All MQs could have fingerprinting vectors, but they could
each affect different sets, and that seems worth enumerating
argyle: That seems reasonable
florian: In principle that seems fine, but as an editor I don't think
I have the bandwidth to do them myself. PRs welcome, but if
you're depending on me for it you might wait a while
astearns: Propose to accept this merged PR, re-add the fingerprinting
sentence to the privacy/security section and an inline
issue in the p-r-d section, and open a new issue on it to
more thoroughly discuss it.
RESOLVED: Accept this merged PR, re-add the fingerprinting sentence
to the privacy/security section and an inline issue in the
p-r-d section, and open a new issue on it to more
thoroughly discuss it.
CSS Scroll Snap
===============
Snap point selection when scrolling into view should try to make
targeted element visible
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9917
flackr: In scroll snap, we have logic for if you try to scroll an
element that defines a snap area. Since we know it has a
desired span alignment, we will respect that rather than
putting it into the top-left
flackr: but if you have an ancestor with a preferred snap, we don't.
That can be degenerate - if you scroll the element into view,
the ancestor's snap can scroll the element out of view.
flackr: So my proposal is we change the spec to consider ancestors of
the targeted scrolled-to element; if they have a snap area
defined, we snap to that and then try to scroll the targeted
element into view
flackr: there's some details tbd, but we shouldn't change the snap
after the scroll
fantasai: Fixing this makes sense. if the element has a snap area,
snapping to that is ideal, walking the ancestor chain is
only needed insofar as it brings the element into view
fantasai: The behavior we want might be different on mandatory vs
proximity snapping
fantasai: so agree to fix this, but I think it's more complicated
than just choose closest ancestor
flackr: Agree, it's choose closest ancestor *while* scrolling element
into view, some combo of that
fantasai: We could resolve that, to the extent that other snap areas
*interfere* with bringing the element into view, we might
not honor the element's own snap
flackr: The element also might not have snap, though
flackr: We should resolve that a scrollTo *should* put the element
into view, and we need to figure out precisely what that
means wrt ancestors with snap positions
astearns: So proposed is "fix the issue, Rob figures out the details"
fantasai: [missed, but in agreement]
astearns: proposed is we will address the problems enumerated in this
issue
RESOLVED: We'll fix the problems in this issue, details TBD
Received on Thursday, 14 March 2024 23:15:31 UTC