- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Mar 2022 19:12: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 Contain
-----------
- RESOLVED: No change, work on more general solution to more openness
across shadow boundaries (Issue #5984: CQ vs shadow
boundaries)
CSS Values
----------
- emilio will write up how he believes issue #3297 (The lh and rlh
units are more complicated than what they seem) should be
implemented. The group will see if implementers can agree to that
proposal after it's drafted.
Scroll Animations
-----------------
- RESOLVED: Use CSSNumberish for "time" values in Web Animations API
(Issue #7102: CSSNumberish Time values to represent types)
- RESOLVED: Use percentages for scroll-timeline values (Issue #7045:
Percentages vs Pixels for Scroll Timeline Values)
Container Queries
-----------------
- RESOLVED: Make cascade-dependent keywords revert/revert-layer
disallowed in style() queries (Issue #7080: CSS-wide
keywords in style())
- RESOLVED: Other css-wide keywords (initial, inherit, reset) are
allowed (Issue #7080)
- There wasn't time to resolve on issue #7142 (container ;/ style),
but the group agreed to look at what WPT is testing now and add
clarifications to the issue to hopefully resolve it next week.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0010.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins Bittner
Delan Azabani
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Daniel Holbert
Jonathan Kew
Vladimir Levin
Daniel Libby
Chris Lilley
Peter Linss
Alison Maher
Ben Mathwig
Jen Simmons
Miriam Suzanne
Regrets:
Lea Verou
Scribe: fantasai
Scribe's scribe: emilio
Administrative
==============
Rossen: Any extra agenda items or suggested changes?
Rossen: Seems not
Rossen: We had our first physical F2F with the TAG
Rossen: Will share reflections
Rossen: It was definitely great
CSS Content
===========
Implementing content:none on elements is not web-compatible
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6503
TabAtkins: Seems subtle, and I haven't reviewed, so maybe push this
to later
Rossen: Yeah, doesn't seem blocking, so let's move on to next issue
CSS Contain
===========
CQ vs shadow boundaries
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/5984
TabAtkins: Miriam added to agenda
miriam: Issue is, we resolved awhile back that slotted container
queries couldn't see containers in the shadow DOM
miriam: which from the perspective of saying that Shadow DOM things
should be hidden makes a lot of sense
miriam: Problem is very common use case with web components and
shadow DOM these days is to build an entire design system out
of them
miriam: you end up with lots of things nested in slots
miriam: and if container queries can't respond, feels limiting
miriam: Decent workaround, similar to can't measure grid track with
CQ, add an extra element in the slot and measure that
miriam: but wanted to bring that back because feels broken to ppl
using the use case
miriam: Proposed path forward is that Container Queries can respond
to containers that are in the shadow DOM
miriam: That does expose a bit about what's in the shadow DOM
miriam: but feels similar to exposing inheritance
miriam: We're trying to measure space available, and that's impacted
by what's in the shadow DOM
miriam: I can also seem Tab's perspective, there's a disconnect here
in the various ways shadow DOM is used
TabAtkins: My position is that containers declared inside a shadow
shouldn't be visible to light DOM children distributed in
slots
TabAtkins: Shadow DOM was designed to be encapsulated as much as
possible
TabAtkins: some purposeful leaks, e.g. ::parts
TabAtkins: and inheritance leaks through the boundaries, but is minor
TabAtkins: but a number of other things we didn't want things to leak
TabAtkins: e.g font-faces in shadow can't be used by light DOM
TabAtkins: ...
TabAtkins: If you ever say anything in your styles about that font,
won't see that font
TabAtkins: because loaded in Shadow only
TabAtkins: This feels similar
TabAtkins: Container in the shadow is not necessarily part of the
public contract of the shadow implementation
TabAtkins: might be internal, not to be exposed
TabAtkins: If exposed, then existence of that container *is* exposed
TabAtkins: and becomes part of your contract
TabAtkins: That said, I can see the usefulness of having containers
in your shadow, and making that part of your "API" with
surrounding content
TabAtkins: This is showing a conflict between shadow DOM as hidden ??
and shadow DOM as organizing mechanism
TabAtkins: ...
TabAtkins: allows cooperating first-party components
TabAtkins: I think we should have a more open shadow DOM that doesn't
have info-hiding, and those could expose things like
containers and name-defining @rules
TabAtkins: but I don't think that should be an exception to shadow
DOM as we have it today
TabAtkins: We should continue to info-hide when possible
TabAtkins: Doing this would make it impossible for any UA shadow DOM
usage to use containers
TabAtkins: and that's problematic
TabAtkins: so I think we should keep spec as is, not exposed
miriam: Container in Shadow DOM does impact layout, so that's why it
feels weird for it to not impact the measurement
miriam: but I do like the idea of having some explicit control here
TabAtkins: I do get it. Not a good answer right now.
TabAtkins: My preferred decision isn't ideal, it's best given the
current tack.
TabAtkins: And we should solve the problem more generally
Rossen: My current personal lean is more towards trying to find more
general solution, that will work for this and others
Rossen: and not rush into open more dependencies and make shadow DOM
less shadowy
<emilio> +1
Rossen: recognizing the pain as well
Rossen: Are we in a position to break that tie?
* fantasai proposes straw poll
Rossen: Miriam, how do we feel about this?
miriam: As long as we all feel the pain, and want to work towards a
general solution
Rossen: Miriam, if we resolve to work on more general solution, would
it be objectionable?
miriam: No, I would want to work on the more general solution, and
teach the workaround for now
Rossen: Sounds like consensus to me, anyone else with a different
opinion?
Rossen: OK, proposed solution is to leave spec as-is and work on a
more generalized solution to less shadowy shadow boundaries
Rossen: Any objections?
RESOLVED: No change, work on more general solution to more openness
across shadow boundaries
CSS Values
==========
The lh and rlh units are more complicated than what they seem
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3257
emilio: Issue here is that some elements treat their line height at
different times, some are computed value and some used value
emilio: and not interop
emilio: so line height units wouldn't be interop across browsers
emilio: Can't quite change the adjustments
emilio: e.g. single-line input elements act as normal if line-height
is less than ... some tricky things
emilio: Roughly interoperable in terms of effect
emilio: but we should agree, but if we don't agree on when to do the
adjustment, the units will behave differently depending on
whether computed-value time or used value time
Rossen: Do we have any consensus on what should be done?
iank: Remind me, emilio?
iank: Can you remind me, these adjustments are all to do with
'appearance'?
emilio: Not really
emilio: At least chrome applies regardless of appearance
iank: Interesting
emilio: I can check but pretty sure it's not tied to appearance, at
least with input
emilio: unsure about <select>
Rossen: Do we already have experiments and consensus, or trying to
establish now?
* fantasai thinks we don't have consensus, hasn't been
well-investigated
smfr: What if we just remove the units? is there sufficient demand
for these units that we need to solve this problem?
fantasai: Units were added to allow authors to spec margins and sizes
in units of line height, to maintain vertical rhythm
fantasai: I don't think it makes sense to remove them because we
can't figure out what to do with form controls, where
they're unlikely to be used anyway
fantasai: It's better to resolve them to something random on form
controls than it is to remove the units
Rossen: What do you propose we do?
emilio: I think <select> does change computed line-height based on
appearance, and input used line-height regardless of
appearance, and [something something nested elements]
emilio: The resolution I want is that we have an interoperable
definition, before we ship the units
<iank> our control elements are complicated wrt. to this as emilio
suggests.
Rossen: Are you going to be the first ones shipping the units?
emilio: I think I filed this when WebKit added them behind a flag
emilio: I just noticed and looked into the weird edge cases
emilio: I think WebKit is the only one with an implementation right
now
smfr: We turned it off because of this problem
Rossen: So you would be OK to not ship them for awhile?
smfr: I think that's fine
fantasai: I don't want to see these units get stuck on this edge case
fantasai: If we're hang up on this issue I'd be happy to define that
on form control it resolves to 16px or something
fantasai: I don't think the value of these on a form control matters
at all
fantasai: if that's what we're hang up on let's resolve
fantasai: but I wouldn't like for this feature to get stuck on that,
nobody is going to use it on form controls
<miriam> +1 fantasai
<astearns> +1 to fantasai
emilio: To be clear, I don't think this is a hard problem to solve.
Just need to figure out what implementations are doing
emilio: and then decide whether we are fine with these units behaving
oddly on <select>, because computed value would change after
the fact
emilio: so like you would resolve the units based on the
author-specified line-height, when might be overridden later
emilio: I don't think this is an unsolveable problem
emilio: First check if we're all doing the same, and then decide if
the weird behavior is desirable, and document it
fantasai: Happy to just make it undefined on the spec on form
controls, I don't think it matters on form controls
fantasai: I don't think it's a high priority to make it work there
Rossen: Is that something we can start with? Make it undefined on
form controls, and then define it later?
<astearns> would rather we pick a behavior
emilio: I would much rather prefer it was interoperable
emilio: Undefining it is going to backfire
Rossen: It would be undefined on form controls, and interoperable
everywhere else
emilio: Someone will use it on form controls, and start depending on
its behavior
iank: Agree with emilio
<vmpstr> +1
Rossen: Either we leave it as undefined on form controls, or we use
some agreed-upon value, or take this back to the issue and
work with implementers to figure out how this should work
Rossen: which option do we want to take?
emilio: I'm happy to document how I think implementations are going
to work here
emilio: I know what Gecko does, but checking what blink/webkit is
doing
emilio: and see if we agree on it
emilio: If we do then, fine, if we don't agree, then we can decide
what is the least painful way to interop
Rossen: Ok, let's do that. Let's have you go back and write that up
in the issue, and once you have it we'll have something
concrete to talk about
Rossen: and see if rest of engines can agree
Rossen: Does that work?
emilio: Sure
Rossen: OK, sounds like we're going with the third solution.
Rossen: Emilio, once you have a proposal, let's go from there
Rossen: Anything else on this issue?
<fantasai> no, just wanted to make progress so we're not blocking
on it
Scroll Animations
=================
CSSNumberish Time values to represent types
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7102
flackr: Scroll-linked animations is the first animation feature we're
animating that doesn't animate in terms of time values
flackr: Takes a scroll position and ultimately turns it into progress
in an animation
flackr: but animations APIs let you observe the time, e.g.
.currentTime
flackr: So question is whether we should reflect the type of the unit
to make it clear to the developer that it's not a time
flackr: or just make it a double, and have the risk of mixing units
flackr: I've outlined the advantages and disadvantages of each
approach
flackr: We know that using numbers for non-time values works, that is
what we have implemented in Chrome
flackr: We'd have to use CSSNumberish in order to use units, so as
not to break existing content which uses doubles
flackr: My preference is CSSNumberish, since that gives us the
flexibility to know when different types are being into the
system, and raise errors if mixing types
flackr: and we can define conversions, as we have done in current
spec, for taking a time-based animation and ...
flackr: rather than using time units as pixels or percentages
TabAtkins: I agree with flackr, keeping the double for representing
milliseconds is fine
TabAtkins: reasonable for handling that
TabAtkins: Being able to distinguish the actual CSS types when there
is not a clear and obvious answer, and being unable to use
different CSS units, is bad
TabAtkins: so very in favor of accepting all length units here
TabAtkins: it wouldn't be possible if using a single type mapping
against the double
Rossen: Sounds reasonable
Rossen: Anyone here prefer keeping doubles?
Rossen: Why were doubles used? Why didn't we use CSSNumberish?
flackr: Legacy. Animations were only in the time domain; I don't
think numeric values existed when the API was defined
Rossen: Sounds like we have a well-articulated path forward, and
didn't hear anyone pushing for keeping doubles, so calling
for objections
fantasai: Wanted to ask if Birtles had an opinion
flackr: Birtles was reviewing all the changes in Web Animations 2 to
make this change
flackr: so this is just checking with the rest of the WG
flackr: Unless he changed opinion, expect he's on board
Rossen: OK, we can take a resolution, and re-open if he has a problem
Rossen: Didn't hear any objections, so let's resolved
flackr: Brian actually commented on the issue in favor
RESOLVED: Use CSSNumberish for "time" values in Web Animations API
Percentages vs Pixels for Scroll Timeline Values
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7045#issuecomment-1081276755
flackr: For scroll-linked animations, now the question is, what is
the internal time: is it percentages or lengths?
flackr: This would specifically be for the output
flackr: This is just for what we report to the developer; can take
any type as input regardless
flackr: Arguments for each are in the issue, but will try to summarize
flackr: pixel-based is very analogous to the way time works for
regular animations
flackr: scroll-timeline is animating over a length
flackr: whereas for percentages, these are pretty much exactly what
the animation progress is, which is how devs specify keyframes
flackr: and is closer to intersection-observer API as it relates to
view timelines
TabAtkins: Given resolution to the previous issue, is this just about
how we should interpret a double in this case or can we
return a typed value, and then is it a question of which
typed value to return?
flackr: Question of which typed value to return
flackr: for setters, we could even throw for a double, since time
values don't belong in a scroll animation
TabAtkins: In that case, I suggest if the progress value changes as
the scrollable area changes ...
TabAtkins: If you freeze an animation, and you change the scrollable
area size, the time value should stay constant
flackr: Standard behavior is ... mapping to progress
flackr: If a change in the scrollable length causes a change to the
animation progress, using percentages the current time will
also change to reflect that change in animation progress, but
a length will not
flackr: because would have the same absolute scroll position
fantasai: I think that's a pretty convincing argument
bmathwig: Just building on what Tab was saying, what are the
artifacts that would occur should the case of an infinite
scroller and timeline being used, and animation jumps back
to a previous keyframe
bmathwig: Would that cause a disruption in the continuity and
disruption / artifact ?
flackr: I don't think our decision here would affect that. We can
accept either type as input
flackr: The current behavior for most of the animation APIs is that
you specify keyframes in percentage progress, so until we
expand that to express absolute positions in time, won't have
discontinuity
flackr: Regardless of whether output value is pixels or percentages
bmathwig: OK, then percent is interesting... I don't have an opinion,
don't have enough context.
Rossen: OK, where does that leave us?
flackr: Seems we have slight preference for percentages, because maps
directly to animation progress
flackr: If there's no objections, I would resolve on that
flackr: I think we can support both types in terms of specifying
values
flackr: which should make it easy for devs to work with this
Rossen: Should we then try to resolve on percentages?
<bmathwig> +1 for percentages
Rossen: Any objections for using percentages for scroll timeline
values?
RESOLVED: Use percentages for scroll-timeline values
Container Queries
=================
CSS-wide keywords in style()
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7080
miriam: When we're doing style queries, question is how are CSS-wide
keywords handled as values in the query
miriam: Comparing that to computed value of the property
miriam: Conversation is landing on, there are 2 different types of
CSS-wide keywords and maybe want to handle differently
miriam: cascade-dependent keywords like revert and revert-layer,
should be disallowed entirely
miriam: but initial and inherit could be supported
miriam: So wanted to distinguish these types in Cascade spec
miriam: and say in Container Queries spec that one is supported and
other not
miriam: That's the proposal here
TabAtkins: I'm in favor
fantasai: Me too
TabAtkins: On the implementer side, Anders seems fine with this as
well
PROPOSAL: Make cascade-dependent keywords revert/revert-layer
disallowed in style() queries
RESOLVED: Make cascade-dependent keywords revert/revert-layer
disallowed in style() queries
PROPOSAL: other css-wide keywords (initial, inherit, reset) are
allowed
RESOLVED: Other css-wide keywords (initial, inherit, reset) are
allowed
container ;/ style
------------------
github: https://github.com/w3c/csswg-drafts/issues/7142
miriam: With the container shorthand, it takes 2 values, and because
one of them accepts custom idents and other accepts keywords
and hard to distinguish, we have a slash separator
miriam: At this point both are optional
miriam: so can get into situation where you can make this frowny face
in the property declaration syntax
miriam: He suggests it looks weird, unsure if it's an actual problem
miriam: One possibility is to make container-name required in the
shorthand
miriam: The only reason to use the shorthand would be to set both
miriam: with it required, would have to set 'none' as container name
if you want to not have a name
miriam: I don't feel strongly one way or another
miriam: We do want to encourage names, so ...
<TabAtkins> Fine with this, or we can fix the optionality by using
the `[...]!` syntax in the grammar
<TabAtkins> (To resolve the "empty value becomes valid" problem
raised.)
emilio: I see a very similar issue and what we're testing
emilio: What WPT is testing is container-type being mandatory and
container-name being optional
emilio: Why would you specify just the name?
miriam: Right now we have default container-type of style on all
elements
miriam: so that makes it optional
miriam: Sometimes would just want to add a name to the style container
emilio: But shorthand expands to set container type to none
fantasai: We changed the initial value to style
Rossen: Seems we're running out of time here
Rossen: Not hearing any pushback on making container name required,
is it something we can resolve?
* fantasai doesn't have a strong opinion either way
miriam: That's just for the shorthand syntax
emilio: ...
emilio: It makes sense to check what WPT tests are checking, optional
name and required type
Rossen: Sounds we're not ready to resolve today
Rossen: We'll end the call here, and recommend for posting opinions
in issue
Rossen: and we can bring it first thing next week
Rossen: Done for now
Rossen: See you next week
Received on Wednesday, 30 March 2022 23:14:40 UTC