[CSSWG] Minutes Telecon 2022-11-23 [scroll-animations]

   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

   - RESOLVED: Accept proposal to allow keyframes outside of the
               animation's duration (negative %, >100%)

   - 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

   - RESOLVED: Accept fantasai's PR for adding view() function to
     ACTION: fantasai to clarify which element it applies to

CSS Anchor Positioning

   Tab asked for feedback on fallbacks for anchor positioning.


   - There is interest in adding pseudo-classes for resource loading
     state; the editors will draft edits and come back.

   - 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

   - RESOLVED: paired defaults apply to all highlights


Agenda: https://lists.w3.org/Archives/Public/www-style/2022Nov/0011.html
Log: https://www.w3.org/2022/11/23-css-irc

   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


   <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
   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
   TabAtkins: would have string just be the literal value of the string
   TabAtkins: which means we can't mix keywords with other values in
   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
   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: 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

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 

Received on Tuesday, 23 May 2023 05:32:23 UTC