- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Nov 2022 20:29:30 -0500
- 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.
=========================================
Administrative
--------------
- There is a proposed extra session for next week to focus on scroll
animations
Selectors
---------
- Resolution on issue #7676 (The forgiving nature of :has breaks
jQuery when used with a complex :has selector) will wait until
next week to allow folks to take a deeper look
- RESOLVED: Merge a limited version of
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md
into Selectors 5 (Issue #4805: Custom state pseudo class
proposal)
- RESOLVED: Take this up for Selectors 5, fantasai and tabatkins
will come back with proposed text (Issue #6867: Pseudo
class to indicated when a slot has content)
Scroll Animations
-----------------
- RESOLVED: Adopt the general path forward of allowing more granular
animation control, Rob will write proposed explainer for
it (Issue #7440: No-motion / forced-reduced-motion issue
draft)
CSS Values
----------
- RESOLVED: ID-Fragment-only URLs use tree-scoped reference
mechanics (Issue #3320: Clarify fragment URLs resolve
against the current tree, not document tree)
CSS Display
-----------
- RESOLVED: Adopt this proposal, and work out the details (Issue
#6429: Why is display listed as not animatable instead
of animation type: discrete?)
===== FULL MINUTES BELOW ======
Agenda: https://github.com/w3c/csswg-drafts/projects/35
Present:
Jake Archibald
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Paul Grenier
Chris Harrelson
Jonathan Kew
Vladimir Levin
Peter Linss
Cameron McCormack
Eric Meyer
François Remy
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Daniel Holbert
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: emeyer
Administrative
==============
astearns: Propose an extra session next week to talk just about
scroll animations
Selectors
=========
The forgiving nature of :has breaks jQuery when used with a complex
:has selector
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7676
<Rossen> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1249958942
TabAtkins: Added to agenda by Elika, the last comment was someone
asking about HTTPArchive data collection
fantasai: We need a follow-up, so to figure out who needs to do what
to move this forward
fantasai: we really need to know if we're making this change or not,
and what we need to know to decide that
fremy: Question is, what's the behavior in Chromium and did it
change?
Rossen: Who is the last person who updated, a committer on Chromium
or?
<miriam> They maintain postCSS I think
fantasai: We need someone to follow up on this. It can't just sit
here.
emilio: It seems Chromium now has WebKit's original behavior
Rossen: Who can take a more proactive approach to this?
<chrishtr> I can ask andruud async for an update on httparchive
research
fantasai: We could take dbaron's proposal to limit forgiving parsing
behavior to :is() and :where()
fantasai: If we have forgiving parsing to :has() it becomes
confusing, as some selectors have forgiving parsing and
others (e.g. :not()) don't, limiting as David proposed is
simpler because authors only need to remember that these
two selectors have forgiving parsing and nothing else
does; and also authors can control where it goes by
wrapping with :is() wherever they want it
<Rossen> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1249958942
<chrishtr> There are also some use counters about to go to stable
channel, see
https://groups.google.com/a/chromium.org/g/blink-dev/c/RJrIxJA9LYw/m/csOGouXNAAAJ
astearns: Perhaps we should punt to next week since we still need
HTTParchive data
fantasai: We only need that if we don't take David's proposal to
narrow forgiving parsing down to :is() and :where()
<fantasai> but either way I'm okay to punt to next week
Rossen: I'm happy to push this to next week to allow people to take
a deeper look
Rossen: It doesn't sound like people are ready to make a decision,
so I don't think we should spend more time on this issue
Custom state pseudo class proposal
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4805
fantasai: Should we be taking this up and drafting it into Selectors
5, or are we waiting to collect interest or information?
TabAtkins: Based on our last comment, we're not super interested in
implementing
fantasai: I'll untag it from selectors 4
Rossen: Anyone else interested in taking this up?
TabAtkins: The open question is about to do with non-booleans
<Rossen> explainer -
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md
<jarhar> I made a HTML PR here: https://github.com/whatwg/html/pull/8467
TabAtkins: Okay, we actually should take that up. We could merge it
into selectors.
fantasai: We should merge it into 5, not 4.
<TabAtkins> https://wicg.github.io/custom-state-pseudo-class/
Rossen: The resolution is we're going to take the boolean part into
selectors 5.
TabAtkins: Joey reminded he has an issue to put this in HTML. We
should mention it in selectors but point over to HTML.
RESOLVED: Merge a limited version of
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/custom-states-and-state-pseudo-class.md
into Selectors 5
Pseudo class to indicated when a slot has content
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6867
fantasai: I wanted to know if this is something we want to pursue.
plinss was asked whether or not we can check to see if
something has slotted content. Is this something we want
to do?
TabAtkins: The use case makes sense and the argument is reasonable.
The fact you can't tell if text content has been slotted
in leaves a whole. I say was call it ‘:has-slotted'
PaulG: Is the example intended to be a slot name?
TabAtkins: ‘::slotted' will select anything slotted into that slot.
fantasai: Tab and I should draft a proposal.
Rossen: Would this be level 4?
fantasai: No, 5
<fantasai> ACTION: Tab + fantasai to draft into Selectors 5
RESOLVED: Take this up for Selectors 5, fantasai and tabatkins will
come back with proposed text
Scroll Animations
=================
No-motion / forced-reduced-motion issue draft
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7440
flackr: In TAG review, we determined they were going to cause a lot
of full-page animations
flackr: There's concern that we have a query for reduced motion, but
there's interest in a UA policy to shut off animation
fantasai: We could shut off all animation forms, but people want a
way to override that
fantasai: Don't think we should have it at a page level
fantasai: If we want the ability to override a forced shutdown of
all animations, we need to provide it on a granular level
flackr: Would this be per element?
fantasai: Per animation
flackr: So we're talking about a new property?
fantasai: We might not want the author to be able to override the
UA, but if we do, it should be per animation.
fantasai: This would mean adding some kind of way to set this for
each animation
PaulG: It sounds like developers in commercial and ad spaces will
put !important on all their animations, leading to a
back-and-forth war between devs and users. I don't love the
idea of overrides.
emilio: For users who do this, what I've seen user stylesheets set
animation: none
emilio: I guess that doesn't work with web animations, but we could
make it work with a user setting to ban web animations
emilio: I don't feel great about a per-animation switch
emilio: This seems somewhat similar to forced-colors, perhaps we
could use a similar approach here
flackr: Even though this opens the door for authors to override,
they can already do it in JS, and in a worse way
emeyer: If there's a property that lets authors disable
per-animation, wouldn't they use a universal selector to
override for every element every animation?
flackr: Won't they use GSAP or something?
<TabAtkins> More generally, we have similar "let me handle this
manually" properties in a few places and trust people to
use it responsibly.
PaulG: People with serious disorders or epilepsy will disable JS. It
would be better for them if they can disable CSS animations.
PaulG: If they can't shut off CSS the same way they can JS, they
have less control
fantasai: If we do this declarative way, that allows the browser to
have different levels of policy. One could be force all
animations off, another force off, and a third could be
force off and ignore overrides. We can allow that
explicitly.
fantasai: There was a suggestion at proposal time to allow a
force-off, but allow authors to override with a switch.
fantasai: If someone wants to behave badly, they can always go to
JS. With the CSS approach, authors will have to confront
their decision to override accessibility concerns.
fantasai: It is a little bit different from normal ad wars, I think
TabAtkins: We have other properties where we let authors explicitly
opt into handling things manually, and trust they'll be
used when necessary and good
TabAtkins: As a general rule, our policy seems to be to let people
opt out on individual levels when there's a good reason
jensimmons: Part of the complexity is people have different needs
for levels of motion, and a boolean doesn't work
jensimmons: A lot of people want or need to turn off extreme or fast
animation; a designer might do that stuff because they
think that's cool
jensimmons: users who don't want extreme animation might want small
animations
jensimmons: I'm for something that will let authors deal with this
kind of nuance
jensimmons: If we can also have a switch for users who need no
motion at all, that would be an ideal way to go
<PaulG> https://www.w3.org/TR/adapt-content/ provides levels of
importance in animation
<jensimmons> We should design CSS to work the way we want, to
provide the result we want, and not rely on a
dependency on JS. CSS itself should be well defined as
a language, and we don't want to require Authors to use
JS to handle animation motion properly.
flackr: From what I hear, there's general support for this idea,
which is good. Let's put together a more concrete proposal
and bring it back to the WG
fantasai: I think this should be a standalone for now, but this will
have to integrate into animation, scroll-animations, web
animations, transitions, [a couple more the scribe missed]
flackr: We have a bit of flexibility because these are declarative
to split apart whether the animation is motion-inducing or
not. Is there an appetite to distinguish those from opacity
and so forth?
PaulG: If you look at the adapt-content document, they talk about
levels of distraction. The more descriptive we can get, the
better.
RESOLVED: Adopt the general path forward of allowing more granular
animation control, Rob will write proposed explainer for it
CSS Values
==========
Clarify fragment URLs resolve against the current tree, not
document tree
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3320
TabAtkins: Brought up a few weeks ago and wasn't introduced properly
TabAtkins: Several years ago, we discussed behavior of fragment-only
URLs and how they react to the <base> element or
Navigation API, changing page URL, etc.
TabAtkins: They're necessary for SVG references, and if they can be
shifted, that can break things
TabAtkins: Fragment URLs are supposed to be special, if you write a
fragment-only URL in they're always resolved against the
current document, regardless of URL situation
TabAtkins: Browsers were in several places at the time, but we
decided this was a good place to go
TabAtkins: The question arose how this works in Shadow trees. Are
fragment-only URLs resolved against the current document,
or are they resolved against the tree they appear in?
TabAtkins: Web Components group thought it was most reasonable to
resolve inside the current tree, I agreed
TabAtkins: Question is: is this okay that fragment URLs resolve
against the current tree? Is the spec text okay or do I
need to fix it up?
emilio: The current tree means the tree of the stylesheet that
specified the URL, right?
TabAtkins: Yes.
emilio: That may be tricky with SVG <use> elements, which sucks
emilio: Seems the most sensible, but it isn't the current behavior
of anyone
TabAtkins: No other behavior allows SVGs with references to work
inside of a shadow tree at all
emilio: The tree of the stylesheet makes more sense
<TabAtkins> Essentially, treating fragment-only URLs as being
tree-scoped
heycam: I can understand using this proposal
PaulG: Does this apply to text-fragment URLs, and is a web component
has CSS and it uses fragment URLs, can that leak to other
shadow DOMs and the parent document?
TabAtkins: For the first, the spec assumes only IDs exist, and I'll
clarify that this only applies to fragment URLs and
doesn't apply to other things like text-fragment
<fantasai> There's also #xywh= fragments etc. to worry about ...
PaulG: It sounds like will process such that CSS in a component
could detect IDs in other trees
TabAtkins: Nope, the opposite
TabAtkins: If the stylesheet is in the shadow, it'll only see IDs in
the shadow; if it's in the light, it'll only see IDs in
the light.
JakeA: This wouldn't change the scope of ARIA things like
aria-describedby, yes?
TabAtkins: This is just about the CSS url() function
TabAtkins: This is why we need raw element references so we can
reference across trees
heycam: 1. It might be weird with the stylesheet relative thing when
you look at computed style, now you have a state behind the
computed value not represented by that style
heycam: 2. Have we considered an alternative approach where we
change the way IDs get resolved by looking up the tree?
TabAtkins: 1. Yes, this does introduce state not expressed in the
text. This is how we handle tree-scope references already
and explicitly resolved to do it that way.
TabAtkins: If you set font family, it remembers the tree it was set
in. If you read computed style in a shadow, you read it
and set it back to the inline style, it will change that
reference
TabAtkins: 2. Automatically searching up trees is how tree scope
works today
TabAtkins: assuming I use the same behavior, you look up the tree
and if you don't find anything, you can maybe find things
in the light
heycam: Ah, that's different from how I was understanding things.
<fantasai> I think the spec doesn't currently express this nuance
TabAtkins: There's still state. If you use a ::part, it will search
in the light DOM, not the shadow
TabAtkins: If you explicitly inherit, that will capture the original
tree it was set on. If it inherits into a shadow tree, it
will still search the light tree.
fantasai: We're binding the fragment to a tree, and inheriting that
binding. Need to make that clear in the spec.
fantasai: Also that it doesn't just look in its own tree, it looks
up trees.
TabAtkins: I need to use tree-scoped references explicitly.
fantasai: In this text to handle ID fragments, you hadn't considered
other fragments. What do we anticipate what happens there?
TabAtkins: I don't know, haven't thought about it in detail. For ID
references, we get this behavior, the rest are undefined.
fantasai: We have to define those
<fantasai> <!DOCTYPE html>
<fantasai> <base href="http://example.com/">
<fantasai> ...
<fantasai> <a href="#anchor" style="background-image:
url(#image)">link</a>
fantasai: Other question: with base URLs, there's an example (see
above) which is resolved against one document and an image
resolving against a different document
fantasai: Firefox and WebKit don't handle this
fantasai: Do we actually want to change this behavior to something I
think authors will find more confusing?
TabAtkins: This is based in an older decision and didn't want to
re-litigate it
fantasai: Do we want to keep going in this direction?
TabAtkins: We have to, or else SVGs in shadow DOMs will break and
can't be fixed
fantasai: Can't you put a base in a component and have it resolve
against that?
TabAtkins: Probably not. <base> is terrible old HTML we should
discourage
fantasai: I do want confirmation from browsers that they still want
this to be where we go
emilio: It seems okay from my point of view
heycam: I think it's fine as well
<fantasai> testcase:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbase%20href%3D%22https%3A%2F%2Fxanthir.com%2Fpony%22%3E%0A%3Ca%20href%3D%22%23linky%22%20style%3D%22background%3A%20url(%23foo)%3B%20font-size%3A%202em%22%3Etest%3C%2Fa%3E%0A
<TabAtkins> proposed resolution: ID-Fragment-only URLs use
tree-scoped reference mechanics
RESOLVED: ID-Fragment-only URLs use tree-scoped reference mechanics
ACTION: bring back text for WG review
CSS Display
===========
scribe: fremy
Why is display listed as not animatable instead of animation
type: discrete?
------------------------------------------------------------
github-bot: https://github.com/w3c/csswg-drafts/issues/6429
flackr: Display is currently not animatable
flackr: mostly because none would cancel the animation
flackr: but there are valid use cases
flackr: My proposal is to allow animation
flackr: but flip "none" when the animation reaches 100% only
flackr: We would need this restriction, because web animations would
allow the animation to continue even if the element goes away
flackr: so, the idea is that if we interpolate between two values
flackr: the non-"none" value would win
astearns: What is smfr's take on this?
astearns: he isn't on the call
astearns: anybody can take this over for him?
heycam: At first glance, this seems reasonable
heycam: I can't see any reason why this would cause issues
TabAtkins: The fundamental problem is going from "none" to something
TabAtkins: but there are also values that change box types
TabAtkins: and that makes it difficult to preserve an animation
across box-generation changes
TabAtkins: but we could define that
emilio: Writing mode an direction can affect animations as well
fantasai: And text-orientation
fantasai: but leaving those as non-animatable seems fine
TabAtkins: That categorization makes sense to me
PaulG: This can be used to keep a distracting and harmful element
visible using an animation that never lets "none" apply,
troll the user with an animation
fantasai: A user stylesheet can disable the animation
fantasai: so this wouldn't make a difference, I think
fantasai: There might be bugs in user agents right now, but this is
what is specced
PaulG: But !important would not override the animation
fantasai: No, animations are in the cascade
fantasai: so !important static would override the animation
PaulG: So you don't have to override the animation property?
fantasai: no, the property is enough
<fantasai> -> https://www.w3.org/TR/css-cascade-5/#cascade-sort
<fantasai> -> https://drafts.csswg.org/css-cascade-3/implementation-report
<fantasai> (Safari currently doesn't handle animations cascade
correctly, but Gecko and Blink do)
emilio: One question about the behavior: what happens if you put
display:none on a keyframe? is that allowed?
emilio: At parse time that is not allowed
emilio: but you can sneak this using a custom property
flackr: Yes, we want to make sure some properties should stay within
acceptable values
emilio: And if doesn't ? what would happen?
flackr: I guess not having a display value
emilio: So, make display:none in the animation behave as
display:revert (use the value outside of the animation)
emilio: we can work out the details later though
flackr: There is no circularity with web animations, so display:none
doesn't stop the animation
emilio: Right
ydaniv: "discrete" animation flip half-way
ydaniv: can we instead flip where the author wants it?
flackr: This is the second part of my proposal
flackr: The value would not change, until you reach the keyframe
that sets the value
ydaniv: and what about other values?
ydaniv: Isn't it more predictable if it always behave as a flip?
flackr: I think this gives less flexibility to the developers
flackr: they can still choose to have the keyframes have any duration
flackr: If you flip immediately, this duration is no longer
something the author controls
astearns: Are we not concerned by using a different timing for
display than other values?
ydaniv: I would suppose that other wanting to go from grid to flex
don't want to wait
flackr: All discrete proposals behave like that
TabAtkins: And you can control where that 50% happens by having
another keyframe
astearns: but for none, we need something special
heycam: What about transition:all?
flackr: No, because all only affects non-discrete properties
flackr: we could enable transitions for more, but we would probably
make a new keyword
astearns: Any other comment on this proposal?
astearns: Any concern about going further?
astearns: Proposed resolution is to adopt and start writing the spec
text
astearns: Any objection?
RESOLVED: Adopt this proposal, and work out the details
<fantasai> Note: this should go into display-4
Received on Thursday, 1 December 2022 01:30:10 UTC