- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Dec 2023 00:45:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scroll-snap-2] Standardize snap point selection with multiple aligned boxes`, and agreed to the following: * `RESOLVED: Specify the whole list in this order as normative behavior` <details><summary>The full IRC log of that discussion</summary> <dael> 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 normativelly define in these cases<br> <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<br> <dael> flackr: Proposed a specific algo here that preserves the intern for focused elements but then items that are aligned in both axis, inner elements.<br> <florian> q+<br> <dael> flackr: Basically, trying to provide a standard answer for what is the snaped item.<br> <astearns> ack florian<br> <dael> 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<br> <fantasai> TabAtkins, flackr's example isn't about the ordering, just about whether 5 makes sense as a rule<br> <dael> flackr: Constructed rules to what I think makes sense<br> <dael> florian: Okay. Doesn't mean I object. But b/c 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 dpend on this, but would be good<br> <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<br> <dael> flackr: if it helps, Chrome is semi-random b/c depends on construction order<br> <dael> florian: How would we go about finding live use cases that fall into this<br> <dael> 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<br> <dael> florian: I guess you won't break much if you change<br> <dael> flackr: It's a bit of an edge case<br> <dael> astearns: Talk in IRC about oder of step 5 and 6<br> <dael> 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<br> <dael> flackr: Yes, if you have a 2d you want something that aligns in box axis.<br> <dael> fantasai: If you have a 9 grid you care about the one in the middle. Okay<br> <dael> 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<br> <dael> flackr: no strong feelings about which one goes first<br> <TabAtkins> I have medium-strong feelings that the current order is best.<br> <dael> 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<br> <dael> fantasai: But if they're aligned in both axis you skip set 6<br> <dael> 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<br> <dael> florian: I agree<br> <dael> flackr: Agree with that<br> <dael> fantasai: Okay<br> <dael> astearns: Consensus on ordering. How much of this do we make normative?<br> <dael> astearns: With my chair hat off, I'm in favor of spec the whole thing. Otherwise we may not find issues if people don'timpl whole list<br> <dael> flackr: My preference as well. And impact is subtle. Only observable today is what is aligned after layout change<br> <dael> florian: I don't think there's complexity to give variance to browsers. Have a precise behavior seems good for complex demos<br> <dael> fantasai: Where are snapping events defined?<br> <dael> flackr: scroll snap 2<br> <dael> fantasai: They're not published so should do something about that. This becomes more critical for level 2<br> <dael> astearns: fantasai are you okay spec the whole list as normative?<br> <dael> fantasai: Okay with that. Could mark as at risk for L1, but should write it all out<br> <dael> astearns: Prop: Specify the whole list in this order as normative behavior<br> <dael> flackr: I think it's not too hard to test. I'll help<br> <dael> astearns: Obj?<br> <dael> RESOLVED: Specify the whole list in this order as normative behavior<br> <dael> fantasai: What should we do about scroll snap L2 draft? It's just an ED<br> <dael> astearns: Is it ready for FPWD?<br> <dael> fantasai: Don't know<br> <dael> 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<br> <dael> flackr: I guess that's to say I don't know<br> <dael> florian: Land the PR and then publish?<br> <dael> flackr: I think finishing the inflight PR would make sense<br> <dael> astearns: fantasai, how about you open an issue saying we should have a FPWD for L2 and people can comment and get focus<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9622#issuecomment-1843949800 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 December 2023 00:45:52 UTC