- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Dec 2023 20:06:43 -0500
- 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. ========================================= Upcoming Meetings ----------------- - Next week there will be an extra hour of meeting to cover additional topics. - The next F2F will be Feb 12-14 in Mountain View CA. Group members are asked to add to the wiki if they will be attending. CSS Values ---------- - RESOLVED: Percents that are resolved against numbers do that at parse time (Issue #9395: Resolve `<percentage>` representing `<number>` or `<angle>` at parse time) - RESOLVED: Drop mix() from Values 4 (Issue #9343: Abandon mix()?) - RESOLVED: We will never use mix to represent a single interpolated value but may have something like it for expressing the whole interpolation (Issue #9343) Scroll Snap ----------- - RESOLVED: Specify option 7 [Join with preceding ranges if there are later overlapping ranges and the gap is short] as normative behavior (Issue #9187: Improve or clarify nested snap behaviors) - RESOLVED: Specify the whole list in this order as normative behavior (Issue #9622: Standardize snap point selection with multiple aligned boxes) CSS Lists --------- - RESOLVED: Revert the previous resolution and the associated edits (Issue #5477: CSS counter scope/inheritance is incompatible with HTML ordinals) - RESOLVED: The working group is interested in defining an opt-in narrow scope for counter resets. Exact syntax tbd (Issue #5477) Scroll Animations ----------------- - The group wants to make sure that if we make changes in issue #8915 (Blocking effects of timeline-scope) it wouldn't lead to problems that would make containment less impactful. Discussion will return to the issue for more investigation. ===== FULL MEETING MINUTES ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2023Dec/0000.html Present: Tab Atkins-Bittner Elika Etemad Robert Flack Daniel Holbert Dael Jackson Vladimir Levin Peter Linss Florian Rivoal Alan Stearns Miriam Suzanne Regrets: Rachel Andrew Oriol Brufau Chris Harrelson Jonathan Kew Bramus Van Damme Sebastian Zartner Chair: astearns Scribe: dael Upcoming Meetings ================= astearns: I think we can get through a few things today astearns: Housekeeping- I posted the possible agenda for an extra hour of meeting that I'm planning to announce for next week astearns: It's the hour before the regular meeting. I'll get that posted today and ask if there's anything else to add <@astearns> https://wiki.csswg.org/planning/mountain-view-2024 astearns: Second, TabAtkins announced to private list we have a meeting for Feb 12-14. There is a wiki page up. Please add at least your name so we know who is coming astearns: I think that's it for my housekeeping. Anything else? fantasai: We should try and plan F2F after that at some point astearns: Yep. On my list to poke Tess about the Apple hosted-meeting fantasai: I think we're still on for that. Main thing to figure out is dates astearns: I'll get that going too CSS Values ========== Resolve `<percentage>` representing `<number>` or `<angle>` at parse time -------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/9395 TabAtkins: Pointed out that while the spec says we simplify trees at computed and used time, there's significant browser interop at resolving percents of numbers at parse time. Calc(50%) in opacity and you read back immediately you get .5 TabAtkins: I don't have much of an opinion. I'm fine leaving spec as-is or with modifying spec to say % resolved against numbers are resolved at parse time. Either is okay with me, so question of what do browsers want to do fantasai: Another relevant question is would authors have an opinion on it TabAtkins: I've never heard anyone have an opinion. I haven't looked deeply, but haven't spotted it fantasai: I think tend to keep specified values as specified. Example a lot of color stuff could be at parse time, but we don't. Same with bg position stuff astearns: If we decide we want that behavior is it likely that all the browsers will change their current code to adapt? TabAtkins: Given I'm not seeing anyone say anything, I suggest we resolve to match browser behavior florian: Only thought against that direction is the more you preserve the easier it is for browser tools that work off OM. But not sure if we've followed that enough for it to be practical TabAtkins: Agree. And if you want high quality you have to do it like dev tools astearns: And there is now a dev tools API TabAtkins: It is very important to get access to the invalid stuff and you cannot get it from the OM. I'm not super sympathetic to needing values for an editor concern. Author surprise would be different, but I don't see that. fantasai: Situation is we're kind of inconsistent where some things can resolve and some can't? astearns: For things that do resolve against a number, only exception is filter argument. florian: Anyway, I think Tab's suggestion is reasonable TabAtkins: Can drop some tests and highlight that filter effect needs a change fantasai: Just put a warning where you write the thing that it's not always going to resolve like line-height astearns: An example of something that looks like it would work but doesn't would be reasonable to put in spec TabAtkins: I think line-height is most reasonable thing. Good idea astearns: Proposal: Percents that are resolved against numbers do that at parse time astearns: And we'll have an example of something that doesn't quite fit the pattern and we'll add wpt for this astearns: Objections? RESOLVED: Percents that are resolved against numbers do that at parse time Abandon mix()? -------------- github: https://github.com/w3c/csswg-drafts/issues/9343 TabAtkins: First off, to clarify. Since issue was filled mix() gained a new syntax. We're not talking about that. This is about dropping original feature for mix(). It was intended to let us represent values that couldn't be written as computed but do interpolate TabAtkins: Since then we added sufficient specialized functions to values 5 to handle all cases we know where this happens. Only a handful of cases that needed the generic interpolation. TabAtkins: So, I believe we can drop the generic interpolator and stick with the specific ones that handle each thing that needs special behavior florian: And it did not represent things that are not interpolable? TabAtkins: Correct, it was invalid syntax fantasai: Two reasons mix was added. One was for these interpolations that you can't show intermediary value. Other was create syntax to allow authors to represent an interpolation of a value between two breakpoints in a MQ. It's not that the intermediary can't be represented but it's because you want a range depending on another calc fantasai: That's what mix was originally for. Since then, TabAtkins and I decided it should be kicked from level 4. But the other function of mix where you can take a whole property value and interpolate between it and another value based on how far you are in a 800px window florian: And you could represented it but not well? fantasai: You could, but now that there's calc-mix you can represent. But if you have something like discrete keywords you can't unless there's an existing mix value miriam: You've basically answered my question. TabAtkins: They cover the case for the types they're meant for. There's a bunch of types like keywords that don't have a mix function miriam: That use case feels useful to me fantasai: I think there are reasons to want something like mix. I don't think we want to impl as is. Reasonable to resolve not in L4 but seems reasonable to explore TabAtkins: Also resolve that we're not intending mix to represent intermediate values would be good. But intent that it's useful for authors to say somewhere on this path is good. Good to resolve that we're not keeping mix to rep intermediate values astearns: Proposal: We will drop mix from L4. Specifically, we don't want to use it for the generic representation of interpolated values but we may in a future level come up with something like mix to express the interpolation itself fantasai: 2 resolutions. Drop mix from Values L4. Second is: Keep exploring mix for interpolation use cases but not for representing a single interpolated value <TabAtkins> proposed: we're not keeping mix() *for the purpose of representing intermediate values*. keeping it for *authors wanting to interpolate arbitrary things* is still on the table astearns: First part, drop mix from Values 4. Objections? RESOLVED: Drop mix() from Values 4 astearns: Second is we will never use mix to represent a single interpolated value but may have something like it for expressing the whole interpolation fantasai: It shouldn't be the only way to represent the value RESOLVED: We will never use mix to represent a single interpolated value but may have something like it for expressing the whole interpolation Scroll Snap =========== Improve or clarify nested snap behaviors ---------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/9187 flackr: Previously discussed this. Use case is when you have nested snap points want to respect inner ones as discrete stops that are separate. flackr: Previously suggest avoiding inner, but that mad tiny gaps. fantasai had alternate that joined inner with outer that follows. Had some concerns about asymmetrical flackr: Compromise is when the gap between the inner snap areas is larger than viewport it's a discrete area you can snap to. When it's smaller it joins with previous inner snap area flackr: Already have a condition for length between snap areas. And I think it satisfies both use cases. Made a demo page with all the various proposals. Adam tried it out and voted his support flackr: Hoping we can go with this. <TabAtkins> I haven't been able to experiment with this myself, but Adam has and likes flackr's suggestion, and it does sound pretty reasonable. <TabAtkins> So +1 fantasai: Compare to scrollport or snapport? flackr: Snapport fantasai: Sounds like a good direction. Not sure how final we'll be until there's a prototype, but happy to go in this direction. Wondering if we want to spec it out now or spec as you could do this but it's technically undefined flackr: I'm in favor of spec out and pushing for this to be the direction. We already have browser differences. It feels like spec will bring more attention <astearns> +1 to specifying behavior fantasai: Yeah, I think we put algorithm in spec. Just if we should require or if it's an example florian: This will be fiddly, so we should we write it with intent that it's normative so we get same behavior fantasai: Okay flackr: +1 astearns: I didn't read all the options flackr: I did make prototype so we can play with it astearns: Is it option 7 or option 7 plus other things? flackr: Just option 7 florian: I wouldn't be surprised if we have to revisit once people play with it, but until then this is a reasonable place to start astearns: Proposal: Specify option 7 as normative behavior astearns: Objections? RESOLVED: Specify option 7 as normative behavior astearns: Thanks flackr for doing the demo and going through options Standardize snap point selection with multiple aligned boxes ------------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/9622 flackr: The spec says that when there's multiple boxes that are currently in a valid snap position, other than preferring targetted the browser can pick any box. I feel this makes spec things like snap events harder and I'd like to normatively define in these cases <TabAtkins> +1 to this proposal, and specifically the exact proposed list. I think flackr's example for keeping 5 and 6 in the current order makes sense flackr: Proposed a specific algo here that preserves the intern for focused elements but then items that are aligned in both axis, inner elements. flackr: Basically, trying to provide a standard answer for what is the snapped item. <@fantasai> TabAtkins, flackr's example isn't about the ordering, just about whether 5 makes sense as a rule <TabAtkins> disagree, I think it's a good example of why you *should* eliminate the large element from being the snap target before you discover there's an overlap in the axises florian: Here too I think good to have specific behavior encoded. Proposal here, are the rules because they make sense or is it having observed people in these cases this works better flackr: Constructed rules to what I think makes sense florian: Okay. Doesn't mean I object. But because we're not spec we may have browser differences so it gives us room to pick a good one. I'm not sure if it's easy to find use cases that depend on this, but would be good flackr: If it helps, Chrome is semi-random because depends on construction order florian: How would we go about finding live use cases that fall into this flackr: Only way you can observe which item is snapped is by which item is snapped when you change layout. Only way authors could do this today is scroll changes but relying on multiple aligned items florian: I guess you won't break much if you change flackr: It's a bit of an edge case astearns: There's talk in IRC about order of step 5 and 6 fantasai: Step 5 is inner vs outer and 6 is about if you happen to have snap positions in two axis that come from same element you want that element rather than snap in one axis flackr: Yes, if you have a 2d you want something that aligns in box axis. fantasai: If you have a 9 grid you care about the one in the middle. Okay flackr: As I mentioned, 5 might not be necessary. If you have inner area aligned it could make snap not valid for the outer area flackr: No strong feelings about which one goes first <TabAtkins> I have medium-strong feelings that the current order is best. flackr: Sorry, I do. I posted an example. You have an inner item aligned. Technically both boxes in my diagram are snap for inner and outer. You probably want the aligned fantasai: But if they're aligned in both axis you skip set 6 TabAtkins: If you take same case but more inner one inside a bit, it does argue better behavior is block axis to take the inner so you don't want it eliminated by match checking florian: I agree flackr: Agree with that fantasai: Okay astearns: Consensus on ordering. How much of this do we make normative? astearns: With my chair hat off, I'm in favor of spec the whole thing. Otherwise we may not find issues if people don't impl whole list flackr: My preference as well. And impact is subtle. Only observable today is what is aligned after layout change florian: I don't think there's complexity to give variance to browsers. Have a precise behavior seems good for complex demos fantasai: Where are snapping events defined? flackr: Scroll snap 2 fantasai: They're not published so should do something about that. This becomes more critical for level 2 astearns: fantasai are you okay spec the whole list as normative? fantasai: Okay with that. Could mark as at risk for L1, but should write it all out astearns: Proposal: Specify the whole list in this order as normative behavior flackr: I think it's not too hard to test. I'll help astearns: Objections? RESOLVED: Specify the whole list in this order as normative behavior fantasai: What should we do about scroll snap L2 draft? It's just an ED astearns: Is it ready for FPWD? fantasai: Don't know flackr: Have a PR in progress to add detail about event timing. This issue is in support of changing the targets of snap events to be a single element in each axis flackr: I guess that's to say I don't know florian: Land the PR and then publish? flackr: I think finishing the inflight PR would make sense astearns: fantasai, how about you open an issue saying we should have a FPWD for L2 and people can comment and get focus CSS Lists ========= CSS counter scope/inheritance is incompatible with HTML ordinals ---------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5477 TabAtkins: A little while ago...several years...we talked about what changes to make to the counter scoping algo to make it workable as a mechanism to explain html lists TabAtkins: html lists have weird behaviors for legacy reasons. I tried to write a fix that fixed what's in the thread but there's close behavior it did not solve. A related change that would fix both is define a counter has an associated scope, wide or narrow. Default is wide where it's visible to children and following siblings until scope of same name is declared. Narrow is only visible to children TabAtkins: That matched how counters. You have an ol and outside of that you have an li, today because wide scoping the li sees the counter scope from the ol and will increment that. TabAtkins: There's some reasonable cases that are less intuitive due to wide. TabAtkins: Ability to declare scope to be narrow fixes this properly. It will be somewhat magic same way list item counter is. Will be slightly more reasonable for authors where they intent it to number a list among children TabAtkins: Concept also carried to when thinking about toggles. Having wide and narrow was necessary there. I think it's proved out that is useful. TabAtkins: Precise mechanics I have not figured out. Happy to take a resolution to figure out florian: Wide is default and narrow is opt-in to match html? TabAtkins: Correct astearns: Other questions or opinions? astearns: First thing would be revert previous? astearns: Proposal: Revert the previous resolution and the associated edits astearns: Objections? RESOLVED: Revert the previous resolution and the associated edits <TabAtkins> valid markup that gets weird currently is in https://github.com/w3c/csswg-drafts/issues/9076 astearns: Proposal: The working group is interested in defining an opt-in narrow scope for counter resets. Exact syntax tbd TabAtkins: I expect it'll work same as reverse counter specs, but I haven't dug in enough to be certain astearns: Objections? florian: Question- you mentioned html has weird edge case. Narrow scope seems too clean to cover. Do we end up matching html or is there a bajillion corner cases where we're different? TabAtkins: I think this brings us all the way or very very close enough that browsers could call it good. I know wide behavior is web breaking if applied to html counters florian: We'll discover it soon enough. We create narrow and if it doesn't work people will tell us TabAtkins: I think remaining weird was list item counter and we resolved how to handle that. Where if you don't declare on an ol it happens. I'm not completely loaded on this and it's complex RESOLVED: The working group is interested in defining an opt-in narrow scope for counter resets. Exact syntax tbd TabAtkins: Issue #9076 was also covered in this discussion as well. It was the same case Scroll Animations ================= Blocking effects of timeline-scope ---------------------------------- github: https://github.com/w3c/csswg-drafts/issues/8915 astearns: On the agenda to confirm we do want style containers to block timeline names from escaping. Is it container queries or style queries? florian: Container query on which style is based? astearns: Anyone have a better handle on this? florian: Superficially this seems fine to me astearns: We had already resolved we'd not allow timelines to escape a container of some kind miriam: Containment for container queries includes style. If you set up an inline size container you are implicitly adding style containment. That's scope the timeline name flackr: And that seemed unnecessary restriction and might want to scope the layout that has containment astearns: From my recollection we have other names that don't leak. I think just doing this to be consistent? florian: I think...I think it would be appropriate to spend more time on this. Containment is not just useful behavior, but guarantee that certain constraints are matched. Just because we can't immediately find a case where there's a problem doesn't mean there isn't one. florian: If we build this and the web depends on it but it doesn't work that breaks container queries. We don't want to defeat containment by doing this. vmpstr: I think this is an observation that lets us skip work in subtree. If these names escape the work becomes necessary flackr: Agree. If we want to leak better to say size containment doesn't require strict style containment flackr: Issue came about because using a container query florian: Types of containment don't have dependency, but container queries use both flackr: I think that's what we're getting at, the core. You should be able to leak names even if have container florian: So style is strict but not invoked miriam: Have to do part because counters escaping flackr: Need to think through florian: That means breaking style containment into two things. One is invoked by container and the other is not but is by content visibility. florian: I suspect explicit values are better if we go there astearns: We're not going to get to a resolution today. Let's take it back to the issue and try and work this through astearns: Thanks everyone for calling. There will be an extra hour at the start of next week's meeting. astearns: Please put your availability on the Feb wiki
Received on Friday, 8 December 2023 01:07:16 UTC