- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Jul 2022 18:53:22 -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.
=========================================
Upcoming Hybrid Meetings
------------------------
- NYC Hybrid F2F is next week. Please add availability to the wiki:
https://wiki.csswg.org/planning/nyc-2022
- TPAC registration is open and hotels are filling fast. If planning
on attending, register soon at https://www.w3.org/register/tpac2022
CSS Overflow 3
--------------
- RESOLVED: Close no change (Issue #7464: Shorten the name of
overflow-clip-margin)
Selectors 4
-----------
- RESOLVED: Disallow all current pseudo-elements inside of :has(),
allow future pseudo-elements to define that they are
valid if useful/possible (Issue #7463: Disallow
pseudo-elements inside :has())
CSS Conditional
---------------
- RESOLVED: Add .matches to CSSMediaRule and CSSSupportsRule (Issue
#4240: Make CSSSupportsRule expose whether its condition
is met)
CSS Sizing
----------
- RESOLVED: Drop the "not relevant to the user" condition from
contain-intrinsic-size:auto (Issue #6308: Only apply
contain-intrinsic-size:auto with content-visibility:auto)
Scroll Animations
-----------------
- RESOLVED: ViewTimeline progress is not clamped by scrollable range
(Issue #7432: Should range of ViewTimeline be clamped to
scrollable range?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jul/0007.html
Present:
Rachel Andrew
Tab Atkins Bittner
David Baron
Mike Bremford
Oriol Brufau
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Daniel Holbert
Jonathan Kew
Vladimir Levin
Daniel Libby
Chris Lilley
Peter Linss
Eric Meyer
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Regrets:
Florian Rivoal
All TAG Members
Scribe: TabAtkins
Scribe's Scribe: fantasai
Upcoming Hybrid Meetings
========================
astearns: In-person hybrid meeting next week
<fantasai> https://wiki.csswg.org/planning/nyc-2022
astearns: If you haven't added yourself to the wiki page for what
times you're available, please do so. Let me know if you
have trouble editing.
astearns: I've started making a project and dividing up topics by
time, but knowing when people are available will make it
way easier.
fantasai: Some logistics.
fantasai: We are asking everyone to take a PCR before showing up, and
wear an n95 when traveling and particularly in an airport
at all times.
fantasai: Have your drinks/snacks in the air, circulation is way
better than airport.
fantasai: Plenty of restaurants with outside seating. We'll have
meals at the venue, including breakfast, too.
fantasai: Masks during the meeting, can do whatever you want
Wednesday evening on.
fantasai: Any questions, let me know
<tantek> +1 fantasai
<astearns> https://www.w3.org/register/tpac2022
astearns: TPAC registration is open
astearns: If you're planning to come, please register. Hotel rooms at
the venue are already disappearing.
astearns: If planning to attend remotely, also register so we'll know
who's calling in for what.
chris: TPAC remote will be zoom, not webex
CSS Overflow 3
==============
Shorten the name of overflow-clip-margin
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7464
fantasai: Was looking over how long our property names are getting
once we add logical longhands.
fantasai: Was considering just using overflow-margin
TabAtkins: I echo jfkthame, dropping 'clip' implies it works on all
values of overflow, not just 'clip'
emilio: Given 2 engines shipped, unless there's a strong use-case to
rename I'd rather not do it
<vmpstr> +1
<jfkthame> +1
astearns: Given negative feedback, okay to close no change?
fantasai: Yes
RESOLVED: Close no change.
Selectors 4
===========
Disallow pseudo-elements inside :has()
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7463
fantasai: Proposal was to make selector invalid if a pseudo-element
is inside of :has()
<emilio> +1
TabAtkins: Object to that as a general thing, because the reason we
were doing that was because of conditional pseudo-elements
(conditional on properties)
TabAtkins: but shared element transitions has use case for checking
existence of pseudos
TabAtkins: much more awkward API if we don't have ability
TabAtkins: Outside of that, I think we should make a list of
pseudo-elements that are allowed, and disallow the rest
TabAtkins: so the shared element transition ones, and just because
they don't have an effect (because they exist at all
times), ::marker/before/after
TabAtkins: but I can go either way on that
TabAtkins: Wouldn't do anything
TabAtkins: but need a list for those that don't create cycles
fantasai: Prefer to make things invalid rather than valid but
meaningless
fantasai: If we need to have exception for SET pseudos, fine, but
since most pseudos won't make sense we should disallow all
others.
fantasai: Can always make them valid later, less likely to cause
problems that way
dbaron: I agree with "list of the ones that work"
dbaron: Skeptical about putting before/after/marker on that list.
dbaron: Not sure the statement they always exist makes sense.
dbaron: Do before and after exist on replaced elements? Does marker
exist on non-list items?
dbaron: Not sure what the spec says to that last one, which I find
confusing.
TabAtkins: Fine with just disallowing before/after/marker
<bramus> `::backdrop` might also be a handy one to allow, could
unblock `:top-layer` as that would become `:has(::backdrop)`
<fantasai> bramus, that's just weird
<faceless> Aren't they all defined to not exist on items with
display:none?
astearns: Do we have the allowlist or blocklist?
fantasai: Proposal is an allowlist, assume invalid otherwise
astearns: What's the allowlist?
fantasai: The SET pseudos
astearns: What about bramus' suggestion about ::backdrop?
fantasai: I think it's a little weird. Not really needed, should do
that as a :top-level instead.
ntim: "Does ::backdrop exist?" is also not clear
ntim: Still think it's weird if the state can change
astearns: So seems the proposed resolution is that all current
pseudo-elements in :has() are invalid, but allow for future
pseudo-elements to define that they work
<chris> That sounds good to me
ntim: What does "invalid" mean?
TabAtkins: Means "invalid" - the selector inside of :has() is dropped.
astearns: Objections?
RESOLVED: Disallow all current pseudo-elements inside of :has(),
allow future pseudo-elements to define that they are valid
if useful/possible
CSS Content & GCPM
==================
Duplicate property definition for string-set
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6435
faceless: Issue filed on spec I now own
faceless: Need to review specs that use <content-list>
faceless: Will fix once review
chris: Think reason is that GCPM's definition wasn't specific enough,
so we just forked it. Should just align them.
faceless: I think we do *need* two slightly different definitions
faceless: Will fix when I'm back from vacation
astearns: Propose we wait until you evaluate it, then
astearns: Is the dupe causing immediate problems?
chris: Causing a problem with automated validators
TabAtkins: w3c tooling is complaining about two different
definitions. They can maintain a manual fix for now but
would like it to be correct in source
CSS Conditional
===============
Make CSSSupportsRule expose whether its condition is met
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4240
chris: Perfectly reasonable to have a getter to know whether the
condition matches
chris: Most discussion is bikeshedding the name, not whether it
should exist or not
chris: Interested if there's arguments against
TabAtkins: Definitely should exist, could recreate by running it
through existing APIs
dbaron: Agree it should exist. At some point when I drafted the IDL I
made a common base class for supports and media. Might not
exist now, but if we make a bool like this we should make it
common between the rules
<TabAtkins> Strong agree
fantasai: Yeah, suggest putting it on CSSConditionRule superclass,
which does exist
fantasai: emilio pointed out it's tricky on @container rules since
they rely on the element being matched as well
fantasai: But we should have consistent naming even if it's
individual methods on each subclass
emilio: Yeah, superclass is tricky because CQs shouldn't have it
emilio: I think the API for CQs would look a bit different, would be
a function that takes an element, and it would force layout,
etc.
emilio: So I think it should exist, but not on the superclass
TabAtkins: I suggest we just define a getter on the subclasses it
makes sense for, yeah
fantasai: Sure, but what's it called?
TabAtkins: .matches works, already on MQlist
TabAtkins: meaning carries over well
emilio: fwiw, "matches" is what we use internally in Gecko
chris: .met would work, but okay with .matches too
fantasai: Happy to go with .matches since MQList already has it
<chris> fine with matches
astearns: So proposed resolution to add .matches to the relevant
conditional rules
dholbert: Question about subclasses vs superclass
dholbert: Can we put in an intermediate superclass so it's shared?
TabAtkins: IDL supports this, but it is an observable change
TabAtkins: We thought it would be useful for ConditionalRule, but
less clear if it's worth it for this
astearns: Which rules are affected?
TabAtkins: @media and @supports
<chris> emilio could you propose some IDL in the issue?
<emilio> chris: sure, `readonly attribute boolean matches;` on the
two individual rules?
<TabAtkins> yeah, that's the IDL
RESOLVED: Add .matches to CSSMediaRule and CSSSupportsRule
CSS Sizing
==========
Only apply contain-intrinsic-size: auto with content-visibility: auto
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6308#issuecomment-1191880225
vmpstr: We previous resolved that contain-intrinsic-size:auto applies
only if content-visibility:auto also applies
vmpstr: When doing spec changes there was some confusion that Oriol
pointed out about whether this also applies to
content-visibility:hidden
vmpstr: For context, we have "relevant to the user", and "skips its
contents"
vmpstr: For content-visibility:hidden, we say the affected element
always skips its contents
vmpstr: For content-visibility:auto, it skips its content only if
it's not relevant to the user
vmpstr: So current spec text for contain-intrinsic-size:auto applies
if the element is not relevant to the user *and* skips its
contents
vmpstr: This wording implies if should apply to
content-visibility:hidden, but only if it's not relevant to
the user. This isn't a state we track for
content-visibility:hidden elements
vmpstr: I don't think we *should* track that state. Should change the
spec.
vmpstr: I don't feel strongly about how
vmpstr: Could drop "is relevant to the user" from
contain-intrinsic-size, so it'll apply to
content-visibility:hidden always, or content-visibility:auto
when it skips its content
vmpstr: Alternately could make it clear that contain-intrinsic-size
only applies to content-visibility:auto
vmpstr: TAG talked about only applying it to content-visibility:auto
vmpstr: Applying it to content-visibility:hidden seems a little
awkward. Dunno use-cases, value doesn't switch between
skipping contents and not; dev just sets it.
oriol: Clarification: content-visibility:hidden always skips
contents, then it triggers size containment.
oriol: With size containment we don't record last remembered size
oriol: If content-visibility:hidden is applied from the start we'll
never have a size
oriol: So this can affect when you're adding
content-visibility:hidden dynamically and there was a
remembered size from before; question is whether to use it
or not
flackr: I think from a dev point of view, applying it to hidden
allows authors to use hidden to do their own show/hide logic
(rather than relying on content-visibility:auto)
TabAtkins: I wrote the spec the way it was because it seemed to me
that it was something that applied to certain concepts,
and anything using those concepts would want ...
TabAtkins: I agree it's slightly wrong
TabAtkins: but iirc, it was intentionally written to rely on a
quality of the element rather than a property value
TabAtkins: specifically because I thought hidden should apply
vmpstr: So I think easiest is to just make it apply if the element
skips its content, and remove the relevant from the user
condition
emilio: I think there's a tangential issue about this. Should also
define how long a remembered size remains
emilio: Oriol has been writing some changes that implement the spec
to the letter; it's not great
emilio: Adds some complexity to remove remembered size at
intersection observer time.
emilio: So depending on how we resolve this, the interaction of
switching between values might be more complex
astearns: emilio/oriol, are you okay with removing "relevant to the
user" and raise further issues as we go? or do you prefer
locking to a property value
emilio: Don't think I have a strong opinion
oriol: Fine with either
oriol: Think problems emilio referred to are a bit orthogonal
astearns: So does anyone want to argue against dropping the condition?
astearns: So proposed resolution is to remove the "not relevant to
the user" condition in contain-intrinsic-size
RESOLVED: Drop the "not relevant to the user" condition from
contain-intrinsic-size:auto
astearns: Anyone think we need to bring this back to the TAG?
Scroll Animations
=================
Should range of ViewTimeline be clamped to scrollable range?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7432
flackr: In ViewTimeline, if the subject you're observing is at the
top of the page it starts in view, and you can never scroll
to a position where it's "start".
flackr: Does it start part of the way thru the animation, or do we
clamp the range?
flackr: There are use-cases for entry/exit where it's clearly better
to not clamp the range
flackr: Slightly better for parallax if we do
flackr: But think it's possible to produce a clamped range from an
unclamped, but can't do the latter reasonably
flackr: So I propose we don't clamp the range. In the future we can
consider another phase or something if we do need to address
this.
<TabAtkins> Makes sense to me
<fantasai> +1 to optimizing for fade-in/fade-out type animations
astearns: Is the range clamping a discoverable thing?
flackr: Not clamping is the easier thing for devs to reason about
flackr: Clamping means suddenly your produced times change if your
element is near the beginning or end of the scroller
flackr: It's completely observable what time you get and if it's
clamped or not
flackr: Could be exposed if we had a start and end scroll offset; the
offsets would be negative
flackr: Don't remember if we have that or not, we might
ydaniv: Not sure I follow on clamping
flackr: It means you'd always be able to reach the full range of the
animation
flackr: So if the element started in view it would start at 0% and
progress to 100% as it scrolled out of view
flackr: I think it's more confusing to do that
flackr: It complicates the relationship between position and
animation progress
ydaniv: So if I have an enter animation, but the element starts
halfway on screen
ydaniv: So if you clamp, I'd still start at 0% and progress the whole
animation?
<bramus> +1 on not clamping
flackr: Right
flackr: Whereas unclamped it would start at 50% of the entry phase,
matching the progress
ydaniv: For me, not clamping is the natural way to go
ydaniv: So like fade-in/fade-out, if my element is already in the
displayed area...
flackr: Think there might be a conflation of scroll-trigger and
scroll-driven animations
flackr: So if the element is halfway in, unclamped would make it half
faded in
flackr: There are a few places where clamping is useful, if you do
want the full set of keyframes available.
flackr: Example in the issue - an oversized image and I want it to
transition from topmost to bottom most.
flackr: If it starts onscreen you can use an exit animation anyway
ydaniv: So I vote for not clamping and maybe creating a clamp
mechanism later, since it seems like extra magic
flackr: Yeah that's the proposal. I don't think we should make the
clamp mechanism yet, until we see use-cases.
astearns: So proposed resolution is that ViewTimeline progress is not
clamped to the scrollable range
RESOLVED: ViewTimeline progress is not clamped by scrollable range
Received on Wednesday, 27 July 2022 22:54:03 UTC