- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 10 Sep 2023 11:49:06 -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 Values
----------
- RESOLVED: WG considered parent() and decided to stay with inherit()
(Issue #2864: inherit() function: like var() for parent
value, for any property)
- RESOLVED: Define inherit() on custom properties only, as a step
towards full thing (Issue #2864)
Scroll Animations
-----------------
- RESOLVED: Close no change (but without prejudice, examples in the
future can change it) (Issue #8688: Scroll and view
timelines should be active in non-printed media)
- RESOLVED: A timeline-scope also prevents the timeline from being
scoped even higher (Issue #8915: Blocking effects of
timeline-scope)
- RESOLVED: contain:style prevents timeline names from leaking out
past it (Issue #8915)
- RESOLVED: Don't add any additional keywords to timeline-scope for
this use-case (for now) (Issue #8915)
- RESOLVED: Put view-timeline-inset into the view-timeline shorthand
(Issue #8926: view-timeline-inset as part of
view-timeline shorthand?)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/38
Present:
Rachel Andrew, Google
Tab Atkins, Google
David Baron, Google
Oriol Brufau, Igalia
Federico Bucchi, Apple
Stephen Chenney, Igalia
Mu-An Chiou, Ministry of Digital Affairs, Taiwan
Emilio Cobos, Mozilla
Yehonatan Daniv, Wix
Matthieu Dubet, Apple
Elika Etemad, Apple
Rob Flack, Google
Megan Gardner, Apple
Sammy Gill, Apple
Daniel Holbert, Mozilla
Brian Kardell, Igalia
Jonathan Kew, Mozilla
Ian Kilpatrick, Google
Una Kravets, Google
Vladimir Levin, Google
Peter Linss, Invited Expert
Theresa O'Connor, Apple
ChangSeok Oh, ByteDance
François Remy, Invited Expert
Florian Rivoal, Invited Expert
Cassondra Roberts, Adobe
Vitor Roriz, Apple
Noam Rosenthal, Google
Khushal Sagar, Google
Jen Simmons, Apple
Alan Stearns, Adobe
Miriam Suzanne, Invited Expert
Bramus Van Damme, Google
Sebastian Zartner, Invited Expert
Scribes: fantasai & TabAtkins
CSS Values
==========
inherit() function: like var() for parent value, for any property
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2864
lea: As pointed out, we already resolved to do it
lea: but might be a good strategy to split out into parts
lea: There was a lot of use-cases for custom property inheritance, it
has defined serialization and a lot of uses
lea: and precedent in container queries of starting with cascading
properties, even though plan is to expand later
lea: Another possibility could be to have custom properties plus a
restricted set of regular properties in L1
lea: The advantage is it covers more use-cases, the disadvantage is
it's harder for authors to understand which is which
lea: but that's a problem with any allowlist, and there's several in
CSS
lea: So I lean toward custom properties + restricted allowlist of
regular properties
lea: It would also be nice to resolve on a name, the issue still
doesn't reflect consensus
lea: Seems consensus leans toward parent
lea: If that's the case, would be good to record a resolution
bramus: Wanted to ask about naming towards parent()
bramus: That might imply from some non-native speakers to select the
direct parent?
dbaron: That's exactly what it means
bramus: Won't walk up to ancestors?
TabAtkins: It will inherit, so get the value from the parent
<TabAtkins> (I still like inherit(), but I'm happy with parent() )
<lea> fyi list of proposed names here:
https://github.com/w3c/csswg-drafts/issues/2864#issuecomment-1645708854
fremy: I think parent() is fine
fremy: Only thing I wonder if instead we can do var() with parent as
first keyword
fremy: then easy to add new sources later
fremy: It's a bit longer though
<TabAtkins> var(parent --foo)
fremy: Just want to propose that but don't have a strong opinion
fremy: but parent() doesn't express that it's a variable
lea: Relating it to var() makes it sound like it's only for custom
properties
<astearns> +1 lea
lea: but the goal is to extend to all properties
lea: highly unlikely that var() wil extend to all properties
<TabAtkins> right, impossible
fremy: fine by me, if no objection to parent()
astearns: other opinions?
oriol: About naming issue, I do like inherit() as a function
oriol: we already have the 'inherit' keyword
oriol: so this is an obvious extension to it
oriol: Why add a completely different keyword
oriol: inherit also looks at the parent
<fantasai> +1 to oriol's argument
<Rossen> +1 to inherit
<lea> inherit was a poor name, but I can see the argument for
consistency.
astearns: Any other opinions about inherit() , parent() etc?
dbaron: I think I might have a slight preference for parent() because
inherit() is about taking the value from the same property
and copying from parent to child
dbaron: but this is more general, says take the value of that
property to use in this parent
astearns: So argument for consistency is less because slightly
different interpretation?
dbaron: That said not a strong preference
lea: The way I see inherit is, by default the default argument is the
property itself, therefore can omit parens
lea: whereas if you use a different property, you need to add parens
and put as argument
<fremy> if there is no strong preference, maybe we can strawpoll and
just take the most popular one?
POLL: 1. inherit() 2. parent()
<bramus> 2
<oriol> 1
<fantasai> 1
<Rossen> 1
<dbaron> 2
<fremy> 1
<SebastianZ> 1
<astearns> 1
<ydaniv> 1
<bts> 1
<TabAtkins> 1 or 2
<lea> abstain
<changseok> 1
<miriam> either
<dholbert> abstain
astearns: not seeing a reason to change
PROPOSED: WG considered parent() and decided to stay with inherit()
RESOLVED: WG considered parent() and decided to stay with inherit()
astearns: You were arguing for doing just custom properties, or just
custom properties and small subset, or doing all at once
dbaron: To be clear, talking about source property, not the property
you're using the function in
[correct]
lea: Want to hear from implementers
astearns: Option to do custom properties now and rest later makes
some sense to me
astearns: I'm less convinced about small subset
<fantasai> +1 to astearns
<emilio> +1
astearns: Why should we do that?
lea: Primary issue with arbitrary properties is primarily shorthands,
and a lot of use cases (if not most) that don't require them
lea: so I suspect we can cover a fairly large percentage of use cases
by having a well-selected allow-list
lea: while not needing to solve serialization
lea: but I'm not an implementer, great to hear from someone who is
emilio: Not particularly about shorthands, but let's consider a
single example
emilio: You have font-family, and browser disagree whether to
serialization as ident or string
emilio: and how you do that changes where it's valid to use
emilio: I think some properties first is a lot more controversial
emilio: for variables, you just have the tokens the author wrote, so
no disagreements between browsers
fantasai: That's a large QA project, to get 100% interop on all
serializations of all possible values in all properties
fantasai: [explains]
dbaron: We could get a bunch of the work done to detect differences
by writing a fuzzer, with WPT as input
dbaron: then we could look at how much work it is
fremy: We tried when we did TypedOM, and ended up not finishing
because so big
TabAtkins: Big, but also I had other things to work on
TabAtkins: wasn't like it was unsolveable
iank: It's solveable, but non-trivial amount of work
astearns: Just so I'm clear on the inherit question
astearns: if we don't allow non-custom properties at the outset,
people can work around it by setting a value on a var, and
using inherit on that var
TabAtkins: yes
<TabAtkins> (finding a good allowlist is nearly the same work as
finding all the differences and working toward fixing
them)
astearns: proposed to resolve on custom properties only at the outset
RESOLVED: Define inherit() on custom properties only, as a step
towards full thing
Scroll Animations
=================
Scroll and view timelines should be active in non-printed media
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8688
flackr: We previously decided that for printing purposes it doesn't
make sense to have scroll animations be inactive
flackr: We defined it in a way that it disables for all paged media
flackr: Wondering if it makes sense to have these still run for paged
media that can change its behavior, like a progress bar on an
e-reader
<astearns> +1 for enabling on interactive paged media devices
flackr: So I propose we support it for paged media generally, just
not for printed media
fantasai: My concern with this is authors are very likely to write
scroll animations that don't work if you don't have
continuous media
fantasai: Like a page might be halfway thru an animation's progress
fantasai: So it won't look good
fantasai: While an author is more likely to write their page in a way
that works if scroll animations don't work at all
fantasai: Lots of reasons to do that
fantasai: but writing the page so that it makes sense when you happen
to paginate halfway thru an animation, it's not likely
fantasai: We could define a page timeline for these kinds of things
which would have discrete steps
fantasai: but I'd rather the author have an explicit understanding
that it has discrete points, it's not continuous
astearns: kneejerk reaction to limit features for paged media because
people could get it wrong
astearns: I'd rather allow people to do things for devices that are
capable of it, and let them deal with the authoring
problems of writing for both continuous and paged
astearns: There are some things you can do in desktop that look bad
in mobile, but we don't disable them there
fantasai: When you don't design for mobile we lay out into a wide
viewport because pages *do* break badly
fantasai: So people don't usually design for print, but it still
generally works
fantasai: But with a scroll animation if you're animating an element
halfway into view, and that's where the page break happens,
you can't see the element
fantasai: If we have a page timeline, and your animations happen to
work for both continuous and discrete, you can just switch
your timeline
fantasai: But if we generally apply a continuous animation to paged
it'll usually break, I think
flackr: It's not arbitrary, it's consistent with a browser
flackr: I'm curious where you'll get 90% is broken
fantasai: Not sure, you'll frequently have problems. Imagine a
paragraph, page break in there, it's 60% in view
fantasai: you'll have 60% opacity because it fragmented there
fantasai: and you can't read it
fantasai: and that's just opacity, if you do fancy transforms or
whatever the interim state can be unreadable
flackr: I was wondering if people would be using view timelines on
things that could be fragmented, and I guess the answer is yes
flackr: My other concern is that having a different type of timeline
is simple for scroll timeline, but do we need something else
for view timeline or do VT just not make sense in paged media?
flackr: I think it's easier for authors to turn them off with an MQ
if they're likely to break
fantasai: They're not gonna do that, they're just not gonna think
about it
<bramus> +1 to fantasai there
ydaniv: Usually people don't animate things that are fragmented
ydaniv: They animate things that they know are gonna stay on the
screen as a unit
ydaniv: In the case of paged media, isn't that closer to having
reduced motion?
ydaniv: If you had something and it was completely disabled, then you
end up with something broken
astearns: Not sure I understood
ydaniv: If someone made a scroll animation for their page but it's
completely disabled on paged media, and the animation was
supposed to bring things into view
ydaniv: so my intuition is that it should behave more like having
reduced motion
astearns: Ah so someone might author a scroll animation and they know
they should turn it off for reduced motion, and they'll
deal with that case, but they won't think about paged media
bramus: I agree with fantasai that authors won't think about this
bramus: I thought her example of animating the opacity was a great
example, if you respected that during printing you could end
up with what looks like an empty page
flackr: And that's if you animate something that can fragment as it
comes into view
flackr: I'm okay with leaving it off, I just wanted to bring it up
with the WG
astearns: And we can leave it like this until someone asks for
animations on an eink device or something
fantasai: I think it would be great to have animations on paged
media, it would just have to handle the fact that it's
paged and discrete
<fantasai> Like, I'm pretty sure a lot of the stuff on NY Times will
break if you try to print it, without explicit
accommodations for printing. NY Times probably has a print
stylesheet, but most websites won't
florian: I was thinking fantasai's earlier analogy with mobile
content was good
florian: It's possible to have a good mobile design but by default
it's broken, so we instead render like a desktop by default
and let you opt into the good behavior
florian: So similar here so it's off by default but you can opt into
working
florian: You mentioned that since it's paginated it might be too hard
to get it right so we just shouldn't do it
florian: But if people *can* get it right we should let people opt in
fantasai: I think until we have an example, like the NYT has a bunch
of animated scrolling articles
fantasai: If they wrote it naively, what would they get out of it?
fantasai: I think it would be broken
florian: Right I think it would be broken by default, so turn it off
by default
florian: so I support it being off by default and having an opt-in
would be nice. But we can add the opt-in for later
astearns: There is an example in the NYT with fragmented regions and
hand-coded scroll animations that works great
fantasai: Yeah that's great, but they wrote it specifically for a
fragmented context, it wasn't just a continuous media
animation that was run thru the paginator
flackr: Was thinking about detecting when an animation was declared
in an MQ for paged media, and having it carry a flag that
lets it work
flackr: The nice thing is that it's not additional syntax
TabAtkins: I would really like to avoid attaching state to something
being in a media query
TabAtkins: we avoided in the past to avoid media queries implying
state
TabAtkins: there might be reasons for it
TabAtkins: but want to avoid
TabAtkins: If we want an opt in, let's have an explicit opt in
TabAtkins: e.g. Opera used to do stuff with paged media and projection
florian: Projection MQ was weird, it made you go full screen or
something like that?
<myles> +1 to avoiding logic of the form "if this was defined in a
media query, take a different behavior"
TabAtkins: presence of MQ at least doesn't change your styles
fremy: Do we have any paged media that's implemented in any browser?
fantasai: Yeah, when you print
fremy: Besides that, we already have agreement on it not working when
we print
flackr: Yeah that was the previous resolution
astearns: Think we're circling a bit, the resolution is to keep it
turned off for all paged media, even if it's interactive
astearns: for now
astearns: So any objections to closing no change?
RESOLVED: Close no change (but without prejudice, examples in the
future can change it)
* fantasai also does not want to figure out the interaction of paging
and fragmentation
<fantasai> Like as you page, the fragmentation changes, because you
animated the height of something is ... really terrifying
Blocking effects of timeline-scope
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8915
fantasai: I just wanted to confirm with the WG the behavior
fantasai: The timeline-scope property is defined to pull the scope of
a timeline name up to an ancestor, which makes it available
to a larger subtree
fantasai: As we were drafting, Robert clarified that it also blocks
the timeline from being pulled further up into a higher
ancestor
fantasai: so I'm just confirming that it desired behavior
fantasai: and second to ask if we want to add keywords to make this
blocking behavior work for all timeline names on an element
flackr: The motivation is that if you define a timeline scope for an
element, you're isolating the effects of the timeline named
there from affecting anything outside that element
flackr: so it's similar to containment in a way
fantasai: So any thoughts or comments about this blocking behavior?
fantasai: if it seems good we can resolve on that
<TabAtkins> (don't really have an opinion, seems fine)
astearns: Objections?
RESOLVED: A timeline-scope also prevents the timeline from being
scoped even higher
fantasai: Do we want to add keywords that add this scope-blocking on
all possible names in a subtree, or all names declared by
the element with timeline-scope?
fantasai: So if you're doing a bunch on a subtree, you want none of
the timeline names to escape the subtree, you don't want to
list them all out
fantasai: or if you're declaring several that you want to be scoped
but you don't want to block your children from lifting
their scopes, maybe a local thing
astearns: Apologies, not actually clear what this would do, I assume
Rob and others have an opinion?
fantasai: Will explain again. If you declare scroll-timeline on a
scroller it's available to its descendants only
fantasai: If you want that timeline available higher, you have to use
timeline-scope on an ancestor referring to it, then it's
visible to the scoping element's descendants.
fantasai: The blocking effect we just talked about means it can't go
even higher
fantasai: [explains in more detail]
fantasai: If you want to encapsulate all the possible scrollers
inside you, you might not know all the names on your
contents
fantasai: if you're in a component or whatever
fantasai: Some higher element in your chain might say
"timeline-scope: foo" and not be looking for your "foo"
timeline, but another one it knows about. But it finds
yours instead.
fantasai: To prevent this you have to preemptively timeline-scope all
of your names.
fantasai: So do we want to make this easier
flackr: It feels a bit odd to re-use timeline-scope for this since
you're not raising the scope
flackr: could we say contain:style prevents the leakage or would that
be too restrictive?
fantasai: Think that's a good idea anyway
flackr: If we need that, do we need a timeline-scope:all?
fantasai: We might be able to get away without it, yeah
<TabAtkins> I agree that contain:style should prevent names
leaking out
<TabAtkins> that's the point
flackr: So that's my proposal, use contain:style
fantasai: Sounds good
astearns: Yeah makes sense
<ydaniv> +1
astearns: Any other opinions?
astearns: Objections?
emilio: Are there use-cases for scoping timeline names but not
counters?
astearns: Whether or not there is, should contain:style scope both
anyway?
emilio: It should yeah
astearns: So I think we can resolve on contain:style and then your
question is about maybe still adding a separate control
astearns: So any objections to contain:style?
RESOLVED: contain:style prevents timeline names from leaking out
past it
astearns: So emilio's question is an argument for adding a keyword to
do just the one thing
astearns: I can't immediately think of a case where you'd want to do
them separately
fantasai: If we did add the keywords, I just thought of 'contain-all'
and 'contain-self'
astearns: I suggest we leave the keywords out until we have evidence
that just using contain:style is insufficient
flackr: If we did have an "all" on timeline scope, I'd also expect
them to raise the scopes they captured
fantasai: Yeah that's why I thought of the "contain-*" names to
separate them a little more from that concept
flackr: Ah right. But for now I think we're comfortable with not
doing this
fantasai: so proposed resolution is to not add keywords for now
astearns: Objections?
RESOLVED: Don't add any additional keywords to timeline-scope for
this use-case (for now)
<fantasai> Side comment: 'contain: style' should probably also affect
anchor-name
view-timeline-inset as part of view-timeline shorthand?
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8926
fantasai: When I drafted up the view-timeline stuff I wasn't sure if
we wanted *-inset to be part of the shorthand or not
fantasai: Currently it's not and this issue is open for discussion
fantasai: The reasons either way is:
fantasai: if it's better for the insets to be reset every time the
author changes the timeline name, it should be in the
shorthand
fantasai: if it's better for them to cascade independently they
should stay separate
fantasai: Since I didn't know which was better I opened the issue
flackr: I'm not aware of strong use-cases for it cascading
independently
flackr: and not having it part of the shorthand is an ergonomic issue
flackr: so I'm in favor of it being in the shorthand
TabAtkins: I agree with what flackr just said
<SebastianZ> +1 on what flackr said.
TabAtkins: I suspect that if you change what you pay attention to,
you probably want insets adjusted as well
TabAtkins: when specifying first time, you probably want to specify
insets together in one declaration
TabAtkins: Also, if no great reason to make exception to the 'all
longhands with this prefix are part of the prefix
shorthand'
<ydaniv> +1 on adding
bramus: I was also wanting it in the shorthand for all those reasons
fantasai: I think having "auto" become the initial value for this
property removes a lot of the reasons to have it cascade
independently, since it refs scroll-padding and that
alleviates a lot of the concerns
astearns: So proposed resolution is to put view-timeline-inset into
the shorthand
astearns: Objections?
RESOLVED: Put view-timeline-inset into the view-timeline shorthand
<br dur=30min>
Received on Sunday, 10 September 2023 15:49:42 UTC