- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 23 May 2023 01:32:13 -0400
- To: W3C style mailing list <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.
=========================================
Scroll Animations
-----------------
https://github.com/w3c/csswg-drafts/issues/7825#issuecomment-1306090794
- RESOLVED: Accept proposal to allow keyframes outside of the
animation's duration (negative %, >100%)
https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1306097703
- RESOLVED: Insets accept either a string containing CSS, or a
sequence of TypedOM values.
- RESOLVED: Existing ViewTimeline.startOffset and .endOffset attributes
incorporate inset calculations
- RESOLVED: Defer adding inset properties to the timeline object
https://github.com/w3c/csswg-drafts/issues/7587
- RESOLVED: Accept fantasai's PR for adding view() function to
animation-timeline
https://github.com/w3c/csswg-drafts/pull/7988
ACTION: fantasai to clarify which element it applies to
CSS Anchor Positioning
----------------------
https://github.com/w3c/csswg-drafts/issues/7757
Tab asked for feedback on fallbacks for anchor positioning.
Selectors
---------
https://github.com/w3c/csswg-drafts/issues/7467
- There is interest in adding pseudo-classes for resource loading
state; the editors will draft edits and come back.
https://github.com/w3c/csswg-drafts/issues/7085
- RESOLVED: allow the "logical combination pseudo-classes" after
pseudo-elements, with their contents having the same
restrictions as the pseudo-elements themselves otherwise
would have
- RESOLVED: Allow the logical-combination pseudo-classes generically,
anywhere their contents are allowed.
- RESOLVED: Allow pseudo-elements to define additional pseudo-classes
they allow to be placed after them.
CSS Pseudo-elements
-------------------
https://github.com/w3c/csswg-drafts/issues/7837
- RESOLVED: paired defaults apply to all highlights
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Nov/0011.html
Log: https://www.w3.org/2022/11/23-css-irc
Present:
Rachel Andrew
Jake Archibald
Adam Argyle
Rossen Atanassov
Tab Atkins
Delan Azabani
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Chris Harrelson
Brad Kemper
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Peter Linss
François Remy
Khusal Sagar
Miriam Suzanne
Bramus Van Damme
Chair: Rossen
Scribe: TabAtkins, fantasai
Administrative
==============
<JakeA> For today's meeting, can we swap #7797 for #8113?
<TabAtkins> Rossen: Could I pull up the css-anchor topic just for,
like, a 2-minute awareness check? Don't need to resolve,
just want to make sure people who care about it know I
have a solution proposed that could use some other eyes.
<Rossen> Yup
Scroll Animations
=================
Keyframe offsets outside of the animations
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7825#issuecomment-1306090794
Rossen: Proposed resolution linked in the agenda
flackr: with scroll animations, especially with dynamically defined
keyframes, you can end up with offsets outside the range
flackr: Proposed solution is to allow these. They don't change the
animation's active duration, but their effects still apply
and just get clipped to the end of the animation duration.
flackr: But don't allow it for classic animations, due to possible
back-compat problems
<TabAtkins> +1 to this
<TabAtkins> we allow overshoot in other places like gradients
RESOLVED: Accept proposal to allow keyframes outside of the
animation's duration (negative %, >100%)
JS API for view-timeline-inset
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1306097703
flackr: Proposal was to allow insets in the ViewTimelineOptions object
as either a string or a pair of CSSNumericValues
flackr: But I recalled on other issues there were parsing concerns for
things other than idents
flackr: So I pinged Tab on this issue
flackr: So yes we should add this attr, but should it support strings?
TabAtkins: While we aren't 100% consistent, we try to avoid doing CSS
parsing on small instances of CSS values in APIs like this
TabAtkins: because in the rare cases where you need to do an escape,
it needs to be double-escaped
TabAtkins: The general rule for identifiers is that we don't parse
strings [missed]
TabAtkins: You can express any string as an ident if it's properly
escaped
TabAtkins: [something else]
TabAtkins: So I proposed not allowing string-based values here, and
just sticking with the TypedOM objects
TabAtkins: They're easy to work with
flackr: should still allow string for auto
TabAtkins: especially because we need to allow identifiers, we'd need
to do string parsing in identifiers
TabAtkins: if you wanted a name with a weird thing, would need to
double-escape
TabAtkins: would have string just be the literal value of the string
TabAtkins: which means we can't mix keywords with other values in
strings
fantasai: I think the argument for wanting to allow string-based is
that you can pipe getComputedStyle() right back into it
fantasai: and just easier to write as a literal "2px" rather than
CSS.px(2)
fantasai: re ident escaping concerns, there's no custom idents in this
API so escapes are never necessary anyway
flackr: I'm a little curious - if we want to use TypedOM objects going
forward, is there easy ways to get that?
TabAtkins: There's a TypedOM for computed style
TabAtkins: not all values have that defined, but for simple things
it should work
TabAtkins: for more complex ones, will just get a string
flackr: so maybe that alleviates some simple concerns
fantasai: Well what's the computed style of -inset? It's one or two
values, so what will we get out of typed om computed style?
flackr: this is a new property, we can define it to be what we want
for the input
fantasai: So what would that be?
flackr: A sequence of numeric or identifier values
flackr: So I propose we only accept the TypedOM representation, and
specify the computed typed om for the property to give the
same values, to support passthru
<dbaron>
https://developer.mozilla.org/en-US/docs/Web/API/CSS_Typed_OM_API#browser_compatibility
dbaron: is the API not gonna work right if the impl wants to do this
without typed om?
dbaron: I ask because TypedOM is implemented right now in chromium
but not gecko or webkit
flackr: sounds like it would be an issue
<iank> I believe webkit has an implementation, just not shipped yet
fantasai: What's the downside of string-based?
fantasai: If we have both you can use whichever is easiest
<ydaniv> +1 for both
TabAtkins: my only concern is impl complexity, and slightly being more
consistent about parsing css vs taking strings literally,
but I can go either way
<fantasai> Proposed to accept both string and TypedOM 2-value sequence
inset within ViewTimeline Options
PROPOSED: Insets accept either a string or a sequence of typedom values
chrishtr: Do we need to specify how the string is parsed?
flackr: Matches the CSS property
RESOLVED: Insets accept either a string containing CSS, or a sequence of
TypedOM values.
<fantasai> Proposed that existing ViewTimeline.startOffset and
.endOffset attributes incorporate inset calculations
(so that they continue to accurately represent the
start/end scroll offsets of the ViewTimeline within
the scroll container).
<flackr> +1
<ydaniv> +1
<bramus> +1
RESOLVED: Existing ViewTimeline.startOffset and .endOffset attributes
incorporate inset calculations
fantasai: final, do we expose the inset values on the timeline itself?
doesn't seem to be use-cases. But we *could* add an inset or
startInset/endInset to the timeline if we wanted to.
<flackr> +1 to deferring for now
<flackr> (this is resolution 3 from
https://github.com/w3c/csswg-drafts/issues/7748#issuecomment-1306097703 )
fantasai: not sure if it needs to be done or not, so unless someone
thinks it's important we recommend resolving not to do it
for now
RESOLVED: Defer adding inset properties to the timeline object
Declarative anchor fallback positioning
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7757
TabAtkins: At previous meeting when introduced anchor positioning
TabAtkins: Emilio brought up that XUL had similar functionality,
and had a simple declarative way to express fallbacks
TabAtkins: This is good, current fallback is very complex
TabAtkins: I have a proposal in this thread for solving that
TabAtkins: Can still use full complex positioning if necessary,
but this should solve common cases
TabAtkins: Not looking for resolution right now, just wanted to get
attention for review and comment
iank: Can you briefly describe this mode?
TabAtkins: The way you opt into it, rather than declaring a side to
align to in the anchor
TabAtkins: Instead you say "auto", and it will automatically choose
the opposite side of the property you're setting
TabAtkins: but if you would trigger fallback positioning, we flip around
TabAtkins: and align your bottom edge to the top edge
TabAtkins: so we can do this positioning without affecting layout
TabAtkins: then if neither works, we go to normal fallback rules
iank: idk that you need auto on opposite side
iank: how does this interact with maximum number of fallbacks?
TabAtkins: need auto on other side because if not, there's nothing
to fall back to
TabAtkins: If you specify this for your top property, we can't switch
to using bottom if your bottom is zero
iank: ok
TabAtkins: wrt maximums, this will be part of that list
TabAtkins: effectively position fallback will have an extra entry,
so this will be factored into that maximum
iank: does this mean you need to set on both insets?
TabAtkins: no, set one to anchor and the other to auto
TabAtkins: it will be naturally sized
TabAtkins: we'll swap the properties if we need to for fallback reasons
[note that auto is the initial value]
iank: You can embed an anchor inside of a calc() expression
iank: so if you're not using the ?? anchor, what does that calc()
expression resolve to?
TabAtkins: after doing the flip?
TabAtkins: it resolves to the appropriate other edge
TabAtkins: Luckily because insets are specified in opposite directions
TabAtkins: if you use calc() to put you 10px from bottom edge, that
same calc() will work against the top
iank: so you're taking the whole calc() and putting it in the other
property, and the other property becomes auto?
TabAtkins: yes, we resolve exactly as if you'd done it on the other side
TabAtkins: just as position fallback already works, but we make it
automatic for obvious placement
iank: sounds fine, just concerned about magical swapping of computed
values at layout time
TabAtkins: This is exactly position fallback, the same feature,
we're just giving you one for free
iank: not exactly, because you're taking e.g. top is auto, bottom is
calc() expression with anchor
iank: the position fallback then is like the top becomes that calc()
function and bottom becomes auto
iank: oh, and I see, you're saying that this will automatically
populate a fallback position entry with those two things
iank: okay, that makes sense
iank: if you can write that as a note, this is how it should be
implemented, that would be helpful
fremy: Small question
fremy: because I believe this would be common
fremy: what happens if you do it for top and left, and if so what happens?
TabAtkins: what exactly will happen is a great question, which I have
not thought through the implications of!
TabAtkins: I don't have an answer for you yet.
TabAtkins: I don't think it's hugely important what the answer is...
worst case maybe generate 3 fallbacks, generating vertical
flip, horizontal flip, or both
TabAtkins: will think about it
fremy: I guess maybe we can check what tooltips do on iOS/MacOS/Windows
<iank> likely want the flips in the logical space vs the physical?
<iank> block flip vs. vertical flip
<fantasai> +1 iank
TabAtkins: just wanted to get feedback, this was helpful
<TabAtkins> well, doesn't matter, point is you flip to the opposite
side of wherever it's specified
Add view() to animation-timeline
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7587
<fantasai> PR: https://github.com/w3c/csswg-drafts/pull/7988
* fantasai defers to flackr
flackr: so we defined scroll() for anonymous timelines, but there was
no convenient way to describe an anonymous view timeline
flackr: I believe fantasai already has a PR for this, so asking for
resolution to use that
<fantasai> -> https://github.com/w3c/csswg-drafts/pull/7988/files
<bramus> +1 on resolving.
TabAtkins: I assume that anonymous view timelines work similar to
anonymous scroll timelines? Just look in the tree for the
nearest obvious thing?
fantasai: Yes, it looks up to the nearest scroll container
<TabAtkins> +1
ACTION fantasai: clarify that it applies to the element it's specified on
RESOLVED: Accept fantasai's PR for adding view() function to
animation-timeline
Additional resource-state pseudo-classes for img/picture
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7467
fantasai: someone asked about pseudos for images to indicate whether
they're loading, failed, stalled
fantasai: So does the WG think this is reasonable?
<dbaron> I think Gecko has internal pseudo-classes that do this
fantasai: do we make loading & buffering both match when a video is
trying to buffer and when an image is loading?
TabAtkins: Like allow both to apply to either condition?
fantasai: Yeah they're both loading, though I'm not sure if the words
are appropriate
TabAtkins: I'm happy to defer that to editors
<bradk> applies to any element that can take time loading,
e.g. iframes?
Rossen: Sounds like there's general approval, should we resolve on
"yes, details TBD"?
<bradk> +1
<bramus> +1
<chrishtr> +1
fantasai: We can propose edits and come back.
ACTION: editors to propose edits
Allow more pseudo-classes after pseudo-elements
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7085
TabAtkins: Currently, pseudo-elements allow a few pseudos to be put
after them, :hover etc.
TabAtkins: question is whether to allow combinatoric ones
(:is()/:not()/:where()) to be applied as well
TabAtkins: Further, some pseudo-elements represent specific elements
elsewhere in the DOM
TabAtkins: wondering if specific pseudo-elements can opt into allowing
additional pseudo-elements
TabAtkins: but that's a different issue
TabAtkins: but first issue, allowing combinatoric ones
TabAtkins: Contents are still restricted to the user-action pseudos
JakeA: we're interested in this for view-transitions
JakeA: want to know if old or new view is :only-child
JakeA: so allowing that would be useful
fantasai: two issues, one is we have a set of pseudos that are already
allowed, and do we allow them to be put in :is()/etc
fantasai: second is allowing other pseudos on case-by-case basis, we
should talk about that separately
fantasai: for :is()/:not()/:where(), it's about whether we can express
the combinations of the user action pseudos
<tabatkins> https://github.com/w3c/csswg-drafts/pull/8041/files
<tantek> could see this being useful for webdevs
oriol: these use forgiving parsing, would invalid pseudos be valid
within them?
TabAtkins: yes
TabAtkins: this would allow more safely adding more pseudo-classes
to a selector in the future
Rossen: any other opinions?
TabAtkins: proposed, allow the "logical combination pseudo-classes"
after pseudo-elements, with their contents having the same
restrictions as the pseudo-elements themselves otherwise
would have
RESOLVED: allow the "logical combination pseudo-classes" after
pseudo-elements, with their contents having the same
restrictions as the pseudo-elements themselves otherwise
would have
fantasai: and more generically I want to resolve that the logical-combo
pseudos can be used *anywhere* their contents are allowed
TabAtkins: I agree with being more generic if we can get away with it
fantasai: wanted to ask if anyone saw a problem with that
<tantek> no objection
<tabatkins> (Don't think there's much issue beyond just implementing it.)
RESOLVED: Allow the logical-combination pseudo-classes generically,
anywhere their contents are allowed.
TabAtkins: Second part of issue, should we allow additional
pseudo-classes other than user-action pseudo-classes to be
put after pseudo-elements?
fremy: On previous resolution, does that mean you can change styles on
::before:hover ?
TabAtkins: yes
fremy: what if you create a loop with ::first-line:hover?
TabAtkins: hover loop, we already have that problem
<tabatkins> Consider p:hover ::first-line
fremy: ok
<JakeA> I'm still +1 this
<bradk> +1
TabAtkins: back to issue, should we allow lifting restrictions on
pseudo-elements followed by pseudo-classes?
<argyle> +1
<miriam> +1
fantasai: Okay as long as we do it as an allowlist, rather than
blanket allowing everything
JakeA: would folks be happy with us using :only-child for view transitions?
TabAtkins: As long as it matches intent
TabAtkins: defined as up to two children, and this one says if you
have only one
JakeA: But usually it doesn't count pseudos...
JakeA: but I guess if we're applying it to a pseudo
<bradk> :only-pseudo-element?
TabAtkins: pseudo-elements live in the tree
RESOLVED: Allow pseudo-elements to define additional pseudo-classes
they allow to be placed after them.
Paired defaults
---------------
github: https://github.com/w3c/csswg-drafts/issues/7837
delan: This issue won't affect implementation complexity much, about
what makes sense to authors
delan: some highlight pseudos have default background color and
default color
delan: e.g. ::selection has default colors; also ::target-text
delan: but it's not true for e.g. spelling/grammar error, where
default styles add squiggly lines but don't change colors
delan: ::selection has special behavior called "paired defaults"
delan: rule is there for compat reasons
delan: means that those default colors only get used
delan: if neither color nor background was set by the author
delan: beside compat, has some other benefits
delan: prevents illegible combination of colors
delan: e.g. some browsers have light text for selections, and some
have dark text
delan: so question is, should these apply to other highlight types?
delan: or only to ::selection?
florian: Point about default colors being relied on makes sense,
so I would say yes it should apply to all
emilio: Gecko doesn't have this magic if the author specifies
selection styles
emilio: do you know the state of interop?
delan: it's also in Gecko
emilio: if you specify ::selection { background: green; color: green; }
we wouldn't magically infer the color
delan: that's separate
delan: this is if the author only sets one of these properties, does
it get the UA color or does it get transparent/currentcolor?
delan: inverting is a separate issue
florian: If we don't do it we have a risk of browser-dependent
illegible things, and that's bad
fantasai: I think proposed resolution is, do we apply paired defaults
to all highlights
fantasai: so do we have any objections? if not we can resolve
delan: so resolution is that they would apply to all fo the highlights?
fantasai: ...
florian: we have delan, fantasai, and myself agreeing and nobody is
pushing back
Rossen: I'm not hearing any objections, so let's resolve
Rossen: if anyone thinks about this we can come back and change if necessary
RESOLVED: paired defaults apply to all highlights
Rossen: Happy Thanksgiving for those in the US
Rossen: Remember next week is a long call, starts 7am Pacific for 3 hours
Meeting closed.
<RRSAgent> I have made the request to generate
https://www.w3.org/2022/11/23-css-minutes.html
Received on Tuesday, 23 May 2023 05:32:23 UTC