- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 21:46:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-5] Improve active marker calculation`, and agreed to the following: * `RESOLVED: Relax spec for less definitive cases, miriam to add use cases to issue, flackr to write possible algorithm(s) as examples` <details><summary>The full IRC log of that discussion</summary> <fantasai> s/Topic: Pub/Subtopic: Pub/<br> <fantasai> flackr: Currently in spec we select the marker whose target has scrolled at least as far as, if not further than,<br> <fantasai> flackr: but this means that as you scroll into next section, doesn't become active until it hits its aligned position<br> <fantasai> flackr: e.g. at top of viewport<br> <fantasai> flackr: similarly for carousel use cases, doesn't switch until next item is completely scrolled into view<br> <fantasai> flackr: [demo of lag in the scroll marker]<br> <fantasai> flackr: proposing more intelligent selection, finds next marker when it's closer to the viewport<br> <fantasai> flackr: rough proposed algorithm in the spec<br> <fantasai> flackr: details are nuanced, because don't need to be larger than scrollport<br> <florian> q+<br> <fantasai> flackr: for example distance from one heading to another<br> <miriam> q+<br> <fantasai> flackr: so wanted to take a resolution that yes, we make changes<br> <fantasai> flackr: similar to if we were snapping, would change to the new thing<br> <fantasai> flackr: not quite the same because scroll targets could be headings, not the entire section<br> <fantasai> flackr: so this is why we can't share exactly the scroll snap properties<br> <Rossen6> ack fantasai<br> <dholbert> fantasai: haven't thought through it in detail, but going in this direction does make sense<br> <kizu> q+<br> <fantasai> florian: Makese sense to go in this direction, but wonder if it shouldn't be a quality of implementation issue<br> <Rossen6> ack florian<br> <fantasai> florian: Can imagine variants<br> <fantasai> florian: e.g. if you are scrolling towards one vs (missed)<br> <fantasai> florian: may be some nuances<br> <fantasai> flackr: could keep it open for now<br> <fantasai> flackr: but in any case what you're proposing shouldn't be disalowed<br> <fantasai> miriam: there's some advantage to predictability<br> <fantasai> miriam: so I have some concerns about being too clever with it<br> <fantasai> miriam: which makes me lean other way from Florian, maybe better to keep it simple and consistent across browsers<br> <fantasai> miriam: definitely I don't trust the concept of "closer" because one heading can be much closer when still not in th viewport<br> <fantasai> miriam: it has to be a lot more clever than that<br> <fantasai> flackr: cleverer thing written in the issue<br> <fantasai> miriam: don't want to lose simple and predictable<br> <florian> q?<br> <florian> q+<br> <Rossen6> ack miriam<br> <fantasai> flackr: would it make sense to come back with a concrete somewhat clever proposal and see if we can agree on it?<br> <fantasai> kizu: what's proposed there in the issue makes sense<br> <fantasai> kizu: this is close to my latest implementation of this<br> <kizu> https://github.com/w3c/csswg-drafts/issues/10917#issuecomment-2380087937<br> <fantasai> kizu: [describes his latest marvel of CSS engineering]<br> <fantasai> kizu: in Chrome you can see how it works<br> <fantasai> kizu: I really like this, it's very in line with what flackr wrote<br> <fantasai> kizu: but would be nice to see exactly what's proposed<br> <Rossen6> ack *<br> <Rossen6> ack kizu<br> <fantasai> flackr: for discussion with mia, goes both ways<br> <Rossen6> ack florian<br> <fantasai> s/flackr/florian/<br> <fantasai> florian: to the extent people will build on it, better to have more predictability<br> <fantasai> florian: on the other hand this is in UX space, and trade-offs in one UA might differe from other UA, possibly depending on input modalities<br> <fantasai> florian: I would expect UAs to fine-tune this, which might result in different answers<br> <fantasai> florian: so providing flexibility seems useful<br> <fantasai> miriam: less about building on top and, already there are use cases where I would want different ansewrs<br> <fantasai> miriam: if I was being clever<br> <fantasai> miriam: I would come up with a different clever algo for ToC than for carousel slider<br> <fantasai> miriam: so that makes me mistrust the idea that we can find one clever option that will work across use cases<br> <fantasai> flackr: could add for a snapping carousel, if using scroll position that you would land on after snapping<br> <fantasai> flackr: so this exampe with carousel is slightly contrived, since I'm holding downt the scrolling mechanism<br> <fantasai> flackr: but in any free-flowing content, this problem is as I showed you<br> <Rossen6> ack fantasai<br> <dholbert> fantasai: I don't remember what's in the spec, but if there are constraints we are sure of, e.g. this should definitely be the scroll marker, we should document those in the spec<br> <dholbert> fantasai: for cases where we need to decide the next action, we/miriam shoudl document some use cases<br> <dholbert> fantasai: flackr should perhaps document the parameters that are worth reasoning about when comparing strategies here<br> <dholbert> fantasai: once we have the examples for these use cases, we can decide which direction to go<br> <dholbert> flackr: what sorts of examples might be handy?<br> <dholbert> fantasai: e.g. "if you're an implementor and you're looking at these two cases, here's how you might write an algorithm to land on the right thing"<br> <dholbert> fantasai: maybe with an illustration, but that's optional<br> <fantasai> flackr: Propose resolve as keep spec as-is, but miriam adds use cases, flackr adds example algorithms ...<br> <fantasai> flackr: but might require resolving that there's flexibility in the spec<br> <fantasai> flackr: so should we resolve on flexibility in the spec?<br> <dholbert> fantasai: there's some flexibility, and some non-flexibility<br> <dholbert> fantasai: there are cases when e.g. you'd land on a thing where it's obvious you need to pick that scroll marker<br> <fantasai> flackr: I think for this demo should relax it a bit<br> <florian> q?<br> <fantasai> flackr: so need to remove the explicit algorithm about finding the thing before the current scroll position and use more open language<br> <fantasai> flackr: similar to snap point selection<br> <florian> +1<br> <fantasai> PROPOSED: Relax spec for less definitive cases, miriam to add use cases to issue, flackr to write possible algorithm(s) as examples<br> <fantasai> RESOLVED: Relax spec for less definitive cases, miriam to add use cases to issue, flackr to write possible algorithm(s) as examples<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10917#issuecomment-2380121265 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 21:46:25 UTC