W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes Extended Telecon 2022-10-26 Part I: Publications, View Transitions, Nesting [css-box-3] [css-values-3] [css-color-4] [css-view-transitions] [css-nesting]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 29 Oct 2022 18:38:01 -0400
Message-ID: <CADhPm3uyeum32bX_1cu4ZenjEcBJF18ynrJiUK4WkTDfuzbv1g@mail.gmail.com>
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.
=========================================


Publications
------------

  - RESOLVED: Advance css-box-3 to PR
  - RESOLVED: Accept the above changes
      Changes:
          - Statement about font-relative lengths and text shaping:
              https://github.com/w3c/csswg-drafts/commit/f69413e37d0fe066de4042a299c860e3e938e540
          - Adding a definition of the device pixel:
              https://github.com/w3c/csswg-drafts/commit/66178f3022fbc1d14c801bf296f25f47eab656fc
  - RESOLVED: Publish updated CSS Values and Units L3 CR snapshot
  - RESOLVED: Republish CRD of CSS Color 4

View Transitions
----------------

  - RESOLVED: Use "snapshot viewport" for root element snapshot and UA
              CSS to size and position ::page-transition at snapshot
              viewport (Issue #7859: Define transitions over changing
              viewport)

Nesting
-------

  - RESOLVED: Allow relative selectors for both nesting and @scope
              (Issue #7854: Allow relative selector syntax in @nest
              rules)

  - The group revisited the four proposals to address issue #7834
      (Syntax Invites Errors) which are detailed here:
      https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md
  - The original debate was between options 1 and 3 and in the last
      conversation there was also discussion that option 4 may get
      better results. Discussion first focused on option 1 vs 3.
  - RESOLVED: We're taking option 3 over option 1 (Issue #7834)
  - It was not clear if option 3 or 4 was better and more examples need
      to be added as well as further developer engagement around this
      pair of options.
  - RESOLVED: Change the spec to reflect option 3 (Issue #7834)
  - RESOLVED: Open issue for further discussion of 3 vs 4 (Issue #7834)

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/34

Present:
  Jake Archibald
  Adam Argyle
  Rossen Atanassov
  Tab Atkins
  David Baron
  Oriol Brufau
  Emilio Cobos Álvarez
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Chris Harrelson
  Daniel Holbert
  Jonathan Kew
  Vladimir Levin
  Rune Lillesveen
  Chris Lilley
  Peter Linss
  Eric Meyer
  Morgan Reschenberg
  Khushal Sagar
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme
  Lea Verou

Regrets:
  Rachel Andrew

Chair: Rossen

Scribe: emeyer

Publications
============

CSS Box 3
---------

  fantasai: CSS-box-3 has been in CR for a while, everything in it is
            defined in CSS2 and CSS writing modes L3
  fantasai: Any objections?
  <chris> +1
  <lea> +1

  RESOLVED: Advance css-box-3 to PR

Republish CSS Values and Units L3 CR
------------------------------------
  <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2022OctDec/0033.html
  <fantasai> https://drafts.csswg.org/css-values-3/#changes
  fantasai: We made a bunch of updates to Values & Units, we did
            publish level 4 as requested but level 3 needs a WG
            resolution
  <fantasai> https://github.com/w3c/csswg-drafts/commit/f69413e37d0fe066de4042a299c860e3e938e540
  fantasai: First is an addition statement about font-relative lengths
            and text shaping
  <fantasai> ->
https://github.com/w3c/csswg-drafts/commit/66178f3022fbc1d14c801bf296f25f47eab656fc
  fantasai: Second is adding a definition of the device pixel
  fantasai: If the WG approves both changes, then we can approve
            republishing a snapshot

  Rossen: The first change you posted, for the font-relative lengths,
          any opinions or objections?
  (silence)
  Rossen: Let's call the first change approved
  Rossen: Second is the device pixel definition. Any opinion or
          objections?
  (silence redux)
  Rossen: That is also approved
  Rossen: Any objections to advancing to CR?
  (silence retrois)

  RESOLVED: Accept the above changes
  RESOLVED: Publish updated CSS Values and Units L3 CR snapshot

CSS Color L4
------------
  github: https://github.com/w3c/csswg-drafts/issues/6900

  chris: There's been a bunch of updates since June, I'd like to keep
         it up to date and publish current state
  Rossen: As of this state, any feedback or reasons why we shouldn't
          republish?
  chris: Any objections?

  RESOLVED: Republish CRD of CSS Color 4

CSS Nesting
===========

Discussion on option 4 of CSS nesting
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md

  fremy: This proposal says there can be a group of rules, no need to
         change parsers and it's easy for developer tools
  fremy: You can have a selector, a declaration, then a group of rules
  fremy: Why would we do this? Three main advantages:
  fremy: 1. You can copy and paste without making changes
  fremy: 2. This is parsing as it's done today
  fremy: 3. This is exactly what CSSOM will do
  fremy: Because there's nothing special, if you're writing normal CSS,
         this is as easy as writing your first rule, and just have to
         tab things over
  fremy: This is exactly the same thing you do for @scope
  fremy: With this proposal, because everything uses the same syntax,
         you can reuse your CSS
  fremy: It's CSS as you've always written it
  fremy: You don't have to change the style declaration type
  fremy: Here, the declaration and rules are exactly the same, no need
         to change
  fremy: If you're a tool developer, this is much easier
  fremy: You don't have to switch between parsing modes based on
         changes of syntax
  fremy: This also avoids CSSOM incoherence

  fremy: This is what the Blink people want to implement
  fremy: The pattern also has similarity with XML structure
  fremy: I don't think this proposal is weird, it's something web
         people are used to

  Rossen: We won't take a decision just yet, but want to get through
          the queue
  lea: Inline styles are in scope for nesting for the future, so it's a
       disadvantage of this proposal that nesting doesn't support
       inline styles
  fremy: I don't think it's really that much easier for tool developers
  fremy: If this fits with CSSOM, the CSSOM design may not be ideal

  Rossen: thanks to fremy for the introduction

View Transitions
================

Define transitions over changing viewport
-----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7859

  bokan: This relates to view transitions
  bokan: The issue is that when you're performing a transition, the
         viewport size could change during the transition
  <TabAtkins> +1 to this proposal
  bokan: For example, the mobile navigation bar or virtual keyboard
         could appear/disappear during transition
  bokan: Proposing a “snapshot viewport” that's a rect which stays
         stable in all cases
  bokan: We could position and size this so it goes under all the UI
  bokan: On desktop, we can have similar issues with scrollbars
  bokan: We would position this viewport under all that as well
  bokan: The coordinate space comes from ::page-transition
  bokan: When we capture elements, they're all positioned relative to
         that rect, so it doesn't matter if UI is shown or not
  bokan: The root snapshot is extended to fill the entire rectangle
  bokan: We don't want page content to stretch because scrollbars
         appeared or disappeared
  bokan: There's pretty good consensus among those working on this, but
         looking for feedback

  astearns: Can things be padded with background rather than background
            color?
  bokan: Yes, agreed.

  argyle: This sounds a little hectic with things appearing and
          disappearing during a transition
  argyle: Should we define things appearing or disappearing to come
          before or after the transition?
  argyle: Second question: what if I want to keep UI elements in place
          until after the transition?
  bokan: The URL bar in particular isn't under author control for
         security reasons
  bokan: It is tricky with the URL bar coming in and being animated,
         the browser will have to coordinate things
  bokan: Idea is that when the URL bar comes in, it slides over content
         rather than pushing it around
  bokan: We thought about whether you can wait for UI elements to
         disappear before starting the transition
  bokan: We don't want to delay animations, though
  <iank> for the cross origin case - is it ok that they might be at
         different (page) zoom levels?
  argyle: What do Android apps do?
  argyle: Are there patterns we can look at there?
  bokan: That's a good idea, but if you're doing an SPA, you can keep
         the keyboard up, but the URL bar is most out of authors'
         control
  <jensimmons> Please do research on iOS as well, not just Android.

  ydaniv: You're talking about the sizing of the viewport, it doesn't
          matter if you have to scroll during the transition?
  bokan: I don't think we have to consider scroll here
  ydaniv: Say I'm at the bottom of a list, and on the new page I need
          to scroll to the top
  Rossen: Another example would be an anchor navigation
  bokan: Normally we'd take a screenshot of where you are and another
         for where you're going and then allow crossfade

  flackr: Overall I think this looks good, one comment: whether we can
          show content behind the keyboard will depend on painted
          content
  flackr: The page has laid out to the size with the keyboard showing,
          so content underneath the keyboard was never intended to be
          exposed
  flackr: You can't scroll to it or otherwise access it as a user
  bokan: You can consider it's as if you scrolled it up
  bokan: I think it's fairly rare for pages to rely on height like that
  flackr: I don't think it's that rare for application-like interfaces
  flackr: The other thing is that offsets will be relative to top left
          of the new viewport; what if those change during the
          transition, say by hiding the URL bar
  bokan: Input is blocked while transitioning, so you can't hide the
         URL bar
  bokan: The three things affected are scrollbar, virtual keyboard, and
         URL bar
  flackr: Maybe it's a non-issue then
  bokan: I think if that becomes possible we'd have to have a way to
         fix the rect

  jensimmons: Since we're designing for the web, we need to look at all
              the mobile OSes, so please do also look at iOS and other
              mobile OSes
  <astearns> if we can do better than Android and iOS, then we
             definitely should (rather than matching current app
             behavior)
  bokan: As far as we know, things work similarly between Android and
         iOS
  bokan: We are by default trying to make things more consistent
  PaulG: A Bluetooth keyboard connected to a mobile device can
         immediately hide the virtual keyboard, so make sure you're
         testing that case
  <fremy> +1, this sounds good to me

  khush: I put up a proposed resolution
  <astearns> proposed resolution: Use "snapshot viewport" for root
             element snapshot and UA CSS to size and position
             ::page-transition at snapshot viewport.
  Rossen: What does the WG think about that proposed resolution?
  fremy: I think this is a solid proposal and adjust as we find problems
  Rossen: Any objections?

  RESOLVED: Use "snapshot viewport" for root element snapshot and UA
            CSS to size and position ::page-transition at snapshot
            viewport

CSS Nesting
===========

Allow relative selector syntax in @nest rules
---------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7854

  fantasai: We had talked about adopting relative selectors as a way of
            writing nested selectors
  fantasai: Thus is you have a combinator, you could just write it
            without prefixing with an ampersand (&)
  fantasai: I believe all proposed syntaxes can accept having relative
            selectors
  fantasai: I propose we allow that for all of them
  fantasai: In option 1, one proposal is you can only put a relative
            after @nest, but you wouldn't need an &
  <lea> +1 for relative selectors, +1 for not requiring @nest (the less
        @nest the better...)
  fremy: We can also do this for @scope
  fantasai: I believe that's correct
  miriam: I don't remember if we clarified that, but I agree it should
          work

  fantasai: I'll break this down
  fantasai: Do we want to allow relative selectors for nesting and
            @scope?
  Rossen: Feedback or objections?
  flackr: It's a bit odd that we support all selectors except
          descendant because of the parsing ambiguousness
  Rossen: Still not hearing objections, so will call this resolved
  <miriam> scope spec says :scope is assumed at the start of selectors,
           which is similar to allowing this (but not entirely explicit)
  <argyle> I like the relative selector feature as nesting 2
  <fantasai> Note: @scope already has this

  RESOLVED: allow relative selectors for both nesting and @scope

  fantasai: The next piece is that for option 1 syntax, where you have
            to start with an ampersand, do we require it @nest?
  <fremy> proposal is we allow `@nest > x` == `@nest & > x`
  lea: The less @nest, the better
  TabAtkins: I don't think it's useful to discuss option 1 syntax since
             we don't know if we're going to use it
  fantasai: Whether descendant selectors are allowed to be written as
            relative selectors in nesting will depend on a following
            discussion
  astearns: Because of the weirdness about descendant selectors, should
            we define an actual optional syntax for descendant
            selectors in nest and @scope situations?
  TabAtkins: I think we should but that should be a different discussion
  Rossen: Please open an issue on that if we don't already have one,
          Alan?
  Rossen: Anything else on this topic?
  (no)

  <br dur=12m>

Syntax Invites Errors
---------------------
  github: https://github.com/w3c/csswg-drafts/issues/7834
  scribe: ydaniv

  <Rossen> https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md
  lea: If you followed all this and have an opinion but haven't
       recorded a vote, please do so!

  astearns: Who wants to present summary
  TabAtkins: We've got 4 options covering all the possibilities
  TabAtkins: option 1: either start with @nest or &
  TabAtkins: option 2: you have a parser switch and afterwards only
             style rules, so they're unambiguous and don't need special
             prefixing
  TabAtkins: option 3: your selector has to start with anything but an
             ident
  TabAtkins: in a rare case where you do need to start with ident you
             can either use an & or wrap it up with :is() or :where()
  TabAtkins: option 4: what FRemy presented either as separate block or
             separate block following an &

  astearns: We've had a poll. I wonder whether there's another
            combination of starting with 1 and relaxing later to 3.
  TabAtkins: Not sure it's a good idea to change syntax
  <fantasai> ->
https://github.com/w3c/csswg-drafts/blob/main/css-nesting-1/proposals.md#twitter-polls
  fantasai: lea did a couple of twitter polls which are also helpful
  fantasai: we have a significant majority that people prefer not
            requiring & at all times
  fantasai: we have a large number of authors who are not going to be
            satisfied with option 1

  argyle: There are many other projects with different syntax who are
          using different syntax and are not considered in the polls
  argyle: just wanna make sure they're included in this conversation
  <TabAtkins> (Though note there are even larger ecosystems that are
              using nesting syntaxes without a required & prefix.)

  lea: Authors are not complaining, they just accept it is what it is.
       But I have seen authors complaining that current syntax is too
       noisy
  <fantasai> lea++
  <argyle> var(--foo) got the same response
  lea: This is why we brought this up
  lea: they really need nesting, but they will use what they have, even
       if it could be better

  jensimmons: I really like option 4 the best. It's really simple.
              Other options are really complicated. I feel like CSS
              should be fun and simple
  jensimmons: option 4 captures that
  <florian> +1 to jensimmons

  fremy: I agree with what lea said. At the end of the day you have to
         ship something.
  fremy: people use what they have
  fremy: I would not object to option 3. It's not the best I think. I
         like 4 better.
  <fremy< https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1292196313
  fremy: one point I want to highlight, option 4 is the least complexity
  fremy: we define 3 different syntaxes for nesting. It may change...
  fremy: You have to consistently switch between syntaxes. I think this
         is a big weakness
  fremy: why add ambiguity when we can keep it simple. But if other
         people prefer other options and are comfortable with tradeoffs
         then we might as well do it
  ericmeyer: I like option 4. Makes the most sense as an author.

  argyle: May pick whatever syntax via any tool they choose.
  argyle: when you reason option 1 has the least things to remember.
          The least ambiguous
  argyle: feels like a win win win across the board
  argyle: you don't have to remember what you can/can't use. Not need
          to teach what's an ident
  argyle: all options eventually rely on &
  <fantasai> Option 4 is the most unambiguous, and quite likely the
             easiest to implement.
  <fantasai> Whether it's the best, idk, but it's the most unambiguous
  <lea> Not sure where it's founded that other options would take
        longer to implement. We only have one data point here.
  fremy: not true, option 4 does not

  jensimmons: I don't really like the idea of us coming up with syntax
              now and changing later.
  jensimmons: as someone who's taught authors, I don't think it'll go
              well if we change syntax 3 yrs down the road
  jensimmons: our best shot is now
  <TabAtkins> Big +1 to Jen's point - adding new *functionality* later
              is fine, adding new syntaxes for no new functionality is
              bad.
  <fantasai> +1
  <lea> +1
  jensimmons: we should plan on our very best solution and be done
              with it
  jensimmons: I also believe strongly that nesting is important for
              people to code better and easier
  jensimmons: if they have to remember many rule with a lot of mental
              complexity it's an overhead
  jensimmons: not assume that using other tools is something everyone
              will be okay with
  jensimmons: I want nesting to be easy and fast to use, I want it to
              be elegant, and if there's a bug it's a typo and not
              because you're using the wrong variant of syntax
  jensimmons: option 4 we haven't talked much about before. I haven't
              heard others talking about it much

  TabAtkins: I'd like to say what I don't like about option 4
  TabAtkins:  I'm very strongly opposed to 4. 1. it is not nested,
              feels unnatural
  <bramus> +1
  <JakeA> +1 to the it's-not-actually-nested issue
  TabAtkins:  the idea that it's chained after and not inside the block
  <bramus> authors already know how to nest, from at-rules, markup, etc.
  TabAtkins: option 4 is the only that's not compatible with current
             state. It doesn't mix with the rest.
  <fantasai> wrt style attributes, we could just allow the rule block
             to be placed inside the style attr, if we don't want to
             add a new attribute. This has the same parsing properties.
  <lea> +1 to everything TabAtkins is saying
  TabAtkins: if you want nest existing rules into other rules you have
             to go to bottom and add there
  TabAtkins: in general having things in a sibling-wise way is not a
             great idea
  TabAtkins: in parent-child relationship things are always nested.
             other options do that, 4 does not
  TabAtkins: I also want to stress that this is not harder to parse
  TabAtkins: 1 & 3 are identical. 2 is a bit harder
  TabAtkins: 4 isn't difficult in any way, simply new
  flackr: we mentioned in option 3 that it's possible to relax further.
  flackr: it may be, but not a good idea
  TabAtkins: not a possible idea ^_^
  TabAtkins: Selectors just have fundamentally infinite overlap with
             property:value declarations

  miriam: I agree generally with what Tab said. option 4 is weird. It's
          all trade offs. 3 is the one I voted for.
  miriam: there's one rule to learn, always start with a symbol
  miriam: I like the idea that both allow for forgiving parsing

  bramus: I think nesting without nesting is also inventing weird things

  dbaron: I think that 4.iii variant is somewhat different than others.
          Having look at it more, looks like you have a selector and
          bunch of things after it
  dbaron: after looking it while doesn't feel like a un-nested rule
  astearns: I was on the queue to say something similar
  astearns: we also had another similar proposal of nesting a new block
            inside
  astearns: which gets rid of the weirdness
  <fantasai> ->
https://github.com/w3c/csswg-drafts/issues/7834#issuecomment-1282700284
  <fantasai> Conceptually, style rules would now have three parts:
  <fantasai> a selector
  <fantasai> a declaration block
  <fantasai> a style rule block (optional)
  <TabAtkins> that extra indent is very significant!
  <TabAtkins> just do some RCV with instant runoffs

  fantasai: My suggestion we have a lot of options
  fantasai: pick between 1 or 3 and then continue
  astearns: we're not picking a winner, we're choosing which avenue
            to take
  TabAtkins: I suggest we take binding votes
  <bramus> +1 on binding vote
  fantasai: I think the problem is that people are trying to implement
            and we should be trying to resolve today
  fantasai: suggest polling between 1 and 3
  <fantasai> POLL: Option 1 vs Option 3
  astearns: taking 2 votes: whether to continue with 1 or change to 3
            please put your vote
  <TabAtkins> 3
  <lea> 3
  <fantasai> 3
  <argyle> 1
  <oriol> 1
  <miriam> 3
  <JakeA> 1
  <flackr> 3
  <dbaron> 3
  <patrickangle> 3
  <futhark> 1
  <bramus> 3
  <jensimmons> 3
  <astearns> 3
  <fremy> 3
  <Sebastian_Zartner> 1
  <emeyer> 3
  <ydaniv> 3
  <florian> 3
  astearns: Looks very much in favor of 3
  fantasai: We're taking option 3 over 1

  RESOLVED: We're taking option 3 over option 1

  fantasai: anyone want's to add anything to the discussion of option 3
            versus option 4?
  astearns: I think that option 4 may get us to a better place
  fantasai: option 4 has two viable options...
  fantasai: ... two adjacent blocks, or some punctuation between them (
            which would allow omitting the first block)
  fremy: There's one thing I dislike, the idea that this is usability
         against "I don't like it"
  TabAtkins: I think this is a bad characterization
  jensimmons: I heard people say that option 4 doesn't feel like
              nesting because they're not nested inside. Not like SASS.
  jensimmons: but I feel like I get that, I hated it, but then thought
              what it opens up, it became my first choice
  jensimmons: it lets me write more simply without repeating
  jensimmons: feels like we're trying to solve reality where instead we
              could choose a different way to accomplish more
  <TabAtkins> Big objection against 4 is the inconsistency with other
              syntaxes or planned future syntaxes. At-rules - do they
              have to go in the property or the rule block? Nested
              @media - how do we do properties directly inside of it
              with option 4 syntax? This is common and popular in Sass,
              for example.
  TabAtkins: I said before that option 4 is inconsistent with current
             syntax and others
  TabAtkins: introducing a new postfix syntax will cause us problems in
             may ways
  TabAtkins: instead of using current syntax which works nicely
  <lea> Oh great point, +1 TabAtkins
  <TabAtkins> My dream would be to accept the "arbitrary lookahead"
              option and just mix everything directly. It avoids all
              issues *except* parsing perf. :/
  fantasai: I agree with Jen about portability between contexts
  fantasai: I have reservations against, options 3 has more rules to
            learn but portability troubles me
  fantasai: we can make changes to syntax
  fantasai: there are ways around nesting media rules

  astearns: shall we take 3 vs. 4 poll? please vote
  <TabAtkins> 3
  <JakeA> 3
  <bramus> 3
  <lea> 3
  <argyle> 3
  <fremy> 4
  <astearns> 4
  <oriol> 4
  <jensimmons> 4
  <flackr> 3
  <florian> 4
  <dbaron> 4
  <andreubotella> 3
  <patrickangle> 4
  <Sebastian_Zartner> 3
  <ydaniv> 4
  <fantasai> probably 4
  <jensimmons> ericmeyer isn't here, but he said 4 before
  <dholbert> 4
  TabAtkins: Editors choice
  lea: Which editor?

  astearns: Slightly in favor of 4
  astearns: if we want to take a binding resolution 4 wins
  TabAtkins: I would object, it's very annoying.
  argyle: I agree
  <JakeA> Poll developers for 3 vs 4?
  astearns: We could change the draft to 3, and leave this question open
  florian: It's effectively making a decision
  astearns: If we're conflicted then we should not ship
  <argyle> its just a prototype, no intent to ship
  lea: It's already implemented behind a flag
  astearns: Then their shipping shouldn't affect our decision
  jensimmons: I would be disappointed if Google ships and this affects
              our process
  argyle: Google never intended to ship
  argyle: no one was intending to ship
  jensimmons: Pressure is good
  <florian> Sorry for my earlier comment about lack of decision being a
            decision. I had mistakenly understood that this was about
            to ship anyways. Happy I was wrong.

  fantasai: I think we should take suggestions to put options in front
            of developers and get more feedback
  fantasai: we could get more collaboration
  fantasai: Would be reasonable to update draft to 3 since we like it
            better than option 1
  fantasai: Get more feedback about 4 and come back when we're more
            confident
  fantasai: We have to get it right, this is going to fundamentally
            change how we write CSS for ~80% of style rules for the
            rest of the life of CSS
  <JakeA> The future is longer than the past :D

  jensimmons: What Tab said about syntax sounded interesting would like
              to see example
  argyle: I suggest writing many examples and see how it comes up
  argyle: with option 4 & 3
  <fantasai> +1

  astearns: Proposed resolution to change draft to 3 and leave 4 to
            another talk
  astearns: I don't think it's useful anymore

  RESOLVED: Change the spec to reflect option 3

  astearns: Who will take this to developers?
  lea: Together with someone else
  fantasai: I can help
  miriam: Me too
  fantasai: We should also mark issue into the draft for people to see
  astearns: done with this issue
  astearns: 10 mins break

  RESOLVED: Open issue for further discussion of 3 vs 4
Received on Saturday, 29 October 2022 22:38:45 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC