- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 29 Aug 2022 19:59:12 -0400
- 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
--------------
- 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:
https://github.com/w3c/csswg-drafts/issues/7468
- 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:
https://github.com/w3c/csswg-drafts/issues/7549
- 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.
Snapshot
--------
- 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
#5115)
===== FULL MEETING MINUTES ======
Agenda: https://github.com/w3c/csswg-drafts/projects/30
Present:
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
Administrative
==============
Charter
-------
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
complained)
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
timelines
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
nothing
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
function
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
shipping
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:
https://static-misc-3.glitch.me/linear-easing/4.html
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
easings
emilio: I don't feel strongly about having a linear function vs
generic
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
apart
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
function
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
resolution
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
Snapshot
========
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
draft...
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
place
Rossen: I was hoping to hear from Tab or dbaron or Emilio on this
topic
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
subtrees
emilio: display-locking
emilio: and same for a bunch of other APIs
emilio: getComputedStyle, updating style on the element you're
querying
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
defined
Rossen: and move on
Rossen: which would allow at least us in TAG to close the event loop
issue
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
level
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
========================
TPAC
----
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
schedule
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