[CSSWG] Minutes New York F2F 2022-08-01 Part I: Administrative; CSS Easing; Snapshot; Batching and flushing of style and layout information [css-easing] [css-snapshot]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - It is time to recharter the working group. ChrisL has created a
      draft and is requesting the working group review before
      submission. Please see details in:
  - Please submit feedback to the State of CSS survey team on what
      information would help the working group make decisions. Details
      on how to submit are in this issue:
  - The group discussed currently known details about the TPAC meeting.
      Anyone planning on attending, including remote attendance, is
      encouraged to register as soon as possible.

CSS Easing

  - RESOLVED: Publish css-easing-2 FPWD with linear() function (Issue
              #7533: Is linear() easing in a shippable state?)
  - After the FPWD is published and there is TAG review, the group will
      revisit if the linear() function should be added as shippable.


  - RESOLVED: Publish the 2022 snapshot
  - RESOLVED: After the first publication of a year's snapshot, it can
              edited and republished after any WG resolution updating
              the ready-to-ship list, by any WG member

Batching and flushing of style and layout information

  - Emilio will organize a meeting of each of the browsers to see if
      they can come up with some common definition of what could cause
      a flush so authors can try and avoid specific landmines (Issue


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

  Rachel Andrew, Google
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  David Baron, Google
  Oriol Brufau, Igalia
  Emilio Cobos Álvarez, Microsoft
  Elika J Etemad aka fantasai, Invited Expert
  Robert Flack, Google
  Daniel Holbert, Mozilla
  Brian Kardell, Igalia
  Jonathan Kew, Mozilla
  Ian Kilpatrick, Google
  Una Kravets, Google
  Rune Lillesveen, Google
  Chris Lilley, W3C
  Francois REMY, Invited Expert
  Florian Rivoal, Invited Expert
  Cassondra Roberts, Adobe
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Bramus Van Damme, Google
  Lea Verou, Invited Expert

Scribe: TabAtkins


  github: https://github.com/w3c/csswg-drafts/issues/7468

  ChrisL: We have a charter, but it's running out
  ChrisL: We have two years (tried for three once, but people
  ChrisL: Kinda pointless, this is a permanent group, but whatever
  ChrisL: Made a new charter based on the new template
  ChrisL: It's supposed to list all our drafts and status and such,
          been done
  ChrisL: Last year we had 10 specs we said would get to REC. 3 of them
          made it, 7 didn't
  ChrisL: It's worthwhile discussing what specs we do think can get to
          Rec this year
  ChrisL: Also there was some language in the new template that I
          actually prefer the old language. You can see it in the diff
  ChrisL: Anything else that people think should be changed - tried to
          keep it as simple as possible
  ChrisL: AC doesn't like changes, they'll want justification
  ChrisL: So that's it. Shouldn't take long to get this agenda done

  florian: Two comments. You say you started from the template
  florian: But to the extent we can I'd like to keep our existing text.
           And template isn't a requirement
  ChrisL: Normally when I do a new charter I'd start from template.
          Here we started from existing, changed to template, looked at
          diff, and chose piece by piece
  fantasai: Changes look fine to me

  florian: You also said we need to list milestone
  florian: Charter says milestone dates "when available" if not
           available we can skip, and that's intentional
  astearns: We tried to do that in the last charter iteration, but
            wasn't allowed
  florian: AC or PLH?
  ChrisL: Both, we were asked why no milestones
  ChrisL: Just the path of least resistance
  florian: Thanks for doing this, btw

  ChrisL: I think we have more specs in our charter than all other WGs
          combined; we're >50% of the entire official output of the W3C
  ChrisL: So like Variables I'd like to take to Rec today, maybe MQ4.
  ChrisL: Deciding can be done in the issue, if people want to shift
  ChrisL: meanwhile charter is doing horizontal review, that takes a
          few weeks
  ChrisL: then it'll go to W3M, then AC for comments
  ChrisL: That may run out our charter time, if so we'll get 3mon
          extension, no big deal
  florian: If you get pushback on boilerplate rather than substance,
           happy to pushback from the AB side
  ChrisL: So that's it unless there's questions

  ChrisL: Part of the new process requires, if you have a CR, you have
          to repub every 6 months, otherwise you have to publish a
          heartbeat explaining why
  ChrisL: New thing.
  ChrisL: So for the next year I'm gonna be a huge pain in the ass
  florian: Just fyi the process requirement is a SHOULD, and that's
           good if things have changed. If they haven't changed, not
           required and probably shouldn't
  ChrisL: Right, anything that is in the ED but not in the CR isn't
          covered by patent policy. If it hasn't changed, we're missing

State of CSS Survey 2022
  github: https://github.com/w3c/csswg-drafts/issues/7549

  lea: This year I'm helping with the survey
  lea: Very far-reaching, surveys authors about what features they've
       heard about, used, what they can't use, etc
  lea: Chrome team already uses this to prioritize impl (and funds it)
  lea: And we're wondering if some results might be useful for the
       group to help focus
  lea: I posted a link to the repo we use for feedback. Feedback period
       is until Aug 20
  lea: If you have question, please open an issue in the repo I linked

CSS Easing

Is linear() easing in a shippable state?
  github: https://github.com/w3c/csswg-drafts/issues/7533

  emilio: There was a bunch of work to add linear(), spec was written
          by Jake A.
  emilio: End result was quite straightforward, it's a piecewise linear
  emilio: We have an implementation in gecko
  emilio: I just wanted to check whether the group is happy with design
  emilio: I think it's a good compromise for the use-cases it enables
  emilio: So are we confident enough to ship it?
  emilio: Or wait?
  emilio: birtles commented about the feature, says he's happy with it
  emilio: Anyone need more time to check it out?

  scribes: TabAtkins & fantasai

  <iank> is there a tag review for this feature?
  <ChrisLilley> tag review would be good
  Rossen: TAG review for the feature?
  emilio: I don't think so, but can file one

  lea: I haven't looked at this before, what use cases does it address
       and how does it relate to linear keyword?
  emilio: It's a compromise to allow more complex functions than we
          currently allow
  emilio: You can approximate other functions
  lea: Complex path through linear segments?
  emilio: Yes, exactly
  lea: I agree that's really useful!
  TabAtkins: Can approximate any easing function you want
  <bramus> relevant demo that shows how it works:
  emilio: Compromise from adding a bunch of complex functions

  lea: While very useful to approximate, there are many ways to
       interpolate, and linear is only one
  lea: Do we have any plans to add curved interpolation
  lea: and if so, do we want to add a generic function instead of
       different functions by curve?
  <fremy> +1 to lea's point
  emilio: Perhaps. This all was discussed in issue 229
  emilio: There's a follow-up issue, I'll paste link
  <emilio> https://github.com/w3c/csswg-drafts/issues/7508
  <astearns> (previous discussion in
https://github.com/w3c/csswg-drafts/issues/229 )
  <bramus> (also see https://github.com/w3c/csswg-drafts/issues/7508
           which was spilt off from 229)
  <TabAtkins> all is linear, quadratic, and cubic. there are no other
  emilio: I don't feel strongly about having a linear function vs
  lea: I agree with having the functionality in CSS, just unsure about
       the design
  emilio: Discussed bezier, complex spline, etc.
  emilio: I personally don't care
  lea: If trying to approximate a curve, good to have a fallback
  emilio: Usual CSS fallback
  lea: But painful
  TabAtkins: Would still be painful
  <astearns> (not sure interpolation fallback is something we should be
             designing around)
  lea: Have a series of arguments that represent points, and if don't
       support the interpolation method, use the same points but
       different method
  dbaron: If you add specific fallback rules that prevents authors from
          write their own custom fallback
  fantasai: I think at some point we'll want a generic function that
            lets you interpolate differently
  fantasai: but linear() as designed now is simple and straightforward,
            and adding more things to it isn't necessarily better
  fantasai: And some of the other curves require more arguments than
            just the points.
  fantasai: This is just the list of points.
  fantasai: So even if we have a generic function, this is still useful
            on its own for author ease

  ChrisLilley: Good thing about the P5 Linear is you can approximate
               anything with enough points
  ChrisLilley: and you don't have off-curve points to add
  ChrisLilley: Bad thing is it's always going to be discontinuous
  ChrisLilley: If your points get animated, your piecewise thing falls
  ChrisLilley: So another option, and I know I've brought it up before,
               is a thing called a catmull-rom
  ChrisLilley: which automatically produces a smooth curve through a
               set of point
  ChrisLilley: I think this is objectively better
  TabAtkins: It's not just that linear is simple
  TabAtkins: but some things can't be produced with curves, e.g. step
  ChrisLilley: It's not a replacement, but in many cases it would be a
               better thing
  TabAtkins: I agree it's the best simple way to get smoothness
  ChrisLilley: I want that on the record, so when people complain we
               didn't do it it's on the record :)

  fantasai: This spec doesn't have a fpwd
  fantasai: so I think before we decide to ship we should do that and
            get review
  Rossen: and tag review
  fantasai: So I think we should publish fpwd, ask for review, then ask
            if it's ready to ship
  emilio: sounds good

  dbaron: admin - I think when we resolve something's ready to ship, we
          need to file an issue against the snapshot with a link to the
  dbaron: We have a history of resolving that things are shippable and
          not writing it down anywhere
  <ChrisLilley> dbaron++
  <astearns> +1
  dbaron: So I think one requirement should be an open issue against
          the snapshot
  fantasai: I think it should be *in* the snapshot, just edit it
  ChrisLilley: Do we have to wait for December to publish snapshots?
  fantasai: No
  ChrisLilley: Then we should publish

  Rossen: Anything else?

  Rossen: So, objections to FPWD?
  Rossen: css-easing-2

  RESOLVED: Publish css-easing-2 FPWD with linear() function


  fantasai: I suggest a resolution to publish the snapshot
  fantasai: and then once it's published at least once in a year,
            anyone can add to it and repub, not just the editor
  florian: Why not just publish a Note?
  fantasai: We'll update it thru the year, seems like it should be a
  florian: Doesn't need to be
  fantasai: kinda indicates we're updating
  astearns: prefer to just publish as a Note
  astearns: Or else we'll forget

  Rossen: Objections to publishing the snapshot?

  RESOLVED: Publish the 2022 snapshot

  fantasai: Proposed rec - once a year's note has been published, any
            WG member can add to the ready-to-ship list and repub it,
            with WG resolution. don't need to wait for editors

  RESOLVED: After the first publication of a year's snapshot, can be
            repubbed after any WG resolution updating the ready-to-ship
            list, by any WG member

Batching and flushing of style and layout information
  github: https://github.com/w3c/csswg-drafts/issues/5115

  Rossen: This was brought up as part of a longstanding TAG review of
          the html event loop
  Rossen: As we looked at last week's TAG F2F, Tess and I were looking
          over all the issues, what was discussed between WHATWG and
          TAG and here
  Rossen: This was the most relevant issue, defining when styles are
           batched and flushed
  Rossen: Wanted to bring it up to the WG to review
  Rossen: For us to encourage and define how batching/flushing takes
  Rossen: I was hoping to hear from Tab or dbaron or Emilio on this

  TabAtkins: My conclusion is, as I commented in the thread, knowing
             exactly how and where styles etc batched and flushed is
             something that I do not know very well
  TabAtkins: and I don't anticipate other authors knowing either
  TabAtkins: So we should make this implicit, with as minimal manual
             effort as possible
  TabAtkins: Anywhere we leave it up to authors, it will inevitably get
             messed up

  dbaron: I think my original suggestion was pretty wrong
  dbaron: I think the question is it's not entirely clear to me what
          the right thing to do about it is
  dbaron: I think one possibility is that we might be able to write
          some wording that says, the following steps happen whenever X
          happens, unless explicitly specified otherwise
  dbaron: The question is whether we can write that clearly enough that
          it's actually correct
  dbaron: because there may be places, there are algorithms like
          interesctionObserver and resizingObserver
  dbaron: that would need to say something explicitly
  dbaron: What's not clear to me is whether other algorithms need to
          say something explicit
  dbaron: needs someone to sit down and spend a few days trying to
          figure it out
  dbaron: I've been intending to do since filing the issue
  dbaron: Given that, I shouldn't maybe make any promises
  dbaron: it's quite substantive

  ChrisLilley: “Happens whenever” is insufficiently precise
  ChrisLilley: it has to happen immediately before or immediately after
  dbaron: I meant before

  emilio: I wanted to say, this problem has gotten more complicated
          than it needs to be
  emilio: due to some new features
  emilio: This containment feature, content-visibility
  emilio: Prevents flashing of style and layout in some cases, in some
  emilio: display-locking
  emilio: and same for a bunch of other APIs
  emilio: getComputedStyle, updating style on the element you're
  emilio: can cause potentially visible side-effect, e.g. not updating
          transitions in other parts of the page
  emilio: very tricky
  emilio: Defining precisely when an element does style updates, I
          don't think it's possible
  emilio: ...
  emilio: It's not a great spot to be in

  Rossen: Just to drive this forward
  Rossen: One way is for us to undefine this, and precisely channeling
          a little of what Tab was saying, is to say this is not to be
  Rossen: and move on
  Rossen: which would allow at least us in TAG to close the event loop
  Rossen: and say we don't have a well-specified event loop
  Rossen: which most of the platform depends on
  Rossen: but you get what you get
  Rossen: That's an unsatisfying place to be in
  Rossen: I think authors, both feature authors and spec authors, would
          like a bit more specificity or visibility into at least what
          would cause a forced flush
  Rossen: If we can define some of the really big landmines that ought
          to be avoided if possible
  Rossen: that would be a good step in the right direction
  Rossen: So at least as people add their ??, they might not get a
          clear picture of batching
  Rossen: but if you get a place when forcing flush
  Rossen: can avoid it
  Rossen: We can't currently do that
  Rossen: ...
  Rossen: If we can't get to that sort of granularity, at that abstract
  Rossen: that's unsatisfying state to be in
  emilio: Might be useful to get all the engines together, see what the
          different optimizations are, and see if we can come up with a
          way to define a minimum common denominator that we can all
          agree on
  emilio: Then there's also the work of going through all the APIs
  emilio: but hopefully getting tricky parts agreed on can help
  emilio: I agree that it's really unfortunate if we don't end up
          having it consistently applying

  Rossen: Emilio, can you organize this?
  emilio: I can try. Between me and dbaron maybe we can get it done
  Rossen: OK, so this is a good point to take a break

<br duration=15min>

Administrative Continued


  Rossen: Btw, it's lovely to see everyone on the camera.
  Rossen: A few procedural things to discuss about TPAC?
  fremy: Wanted to be 100% clear on which days we had meetings, and if
         we already know the kind of setup we would have there. Just
         wanted to know general information
  [chairs try to remember]
  astearns: I believe we are meeting all day Thursday and Friday
  astearns: and we have a joint meeting with the APA on Monday or
            Tuesday, but we don't know exactly when
  astearns: So main meeting Thu/Fri, which is departure from our usual
  Rossen: So that's in terms of when

  Rossen: Question is what it will be like, guessing you're asking
          about COVID protocols?
  fantasai: Meeting is at a hotel in Vancouver, with standard conf rooms
  fantasai: Dunno their ventilation plans
  fantasai: Masking is required indoors
  fantasai: Lunch is box lunch outside
  fantasai: There will be outdoor seating for at least some people
  fantasai: Think they're gonna try for coffee breaks outside as well
  ChrisLilley: Gonna do zoom VCs
  florian: AV system is supposed to be good
  florian: No shade, just haven't seen it

  florian: If you're planning to do remote attendance, remember that is
           attendance and you need to pay a fee
  florian: But if you're unable to pay the fee, you can ask for a waiver
  bkardell: There is a no-questions-asked waiver policy
  bkardell: You have to email - it's not obvious on the form
  fantasai: I say if you're an IE and don't have sponsorship, don't pay
            the fee. Request a waiver
  fremy: That's all my questions, thank you

  <fantasai> W3C has invested over $100K in A/V equipment to make
             remote attendance work well
  <fantasai> fwiw

  Rossen: The wiki should have the info there, we'll know about who's
          showing up soon
  astearns: We have a link to the TPAC page, we'll set up a wiki page
            on our wiki

Received on Monday, 29 August 2022 23:59:52 UTC