- 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