- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Nov 2020 17:23:06 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view] Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions`, and agreed to the following: * `RESOLVED: change the PR to just ifNeeded bits with a reference to scroll snap as long as it's handling the use cases` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [cssom-view] Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions<br> <dael> github: https://github.com/w3c/csswg-drafts/pull/5677<br> <dael> zcorpan_: A brief explanation. We wanted to extend scrollIntoView and Focus API to control if scroll should happen and if it does what the alignment should be; center, start, end alignment<br> <dael> zcorpan_: I think the question is what the API shape should look like. Which use cases we're trying to solve.<br> <dael> zcorpan_: There's at least one polyfill impl these behaviors so we have some data on what webdevs want<br> <dael> zcorpan_: Question is what to build intot he platform and how<br> <dael> zcorpan_: One option is add or utilize CSS properties for this. Or having a dictionary you pass into Focus or scrollIntoView methods. Other both<br> <dael> zcorpan_: Scroll behavior smooth you can do both. CSS property for smooth scrolling and you can opt in/out from JS<br> <dael> astearns: When you say that there's JS and CSS options for smooth scrolling it's just opting into it not any of the alignment?<br> <dael> zcorpan_: Smooth scrolling exists for scrollingINtoView. Issue is adding scroll alignment and if needed<br> <dael> fantasai: Shouldn't scroll alignment be handled by scroll snap alignment property?<br> <dael> zcorpan_: Maybe. Not familiar<br> <smfr> q+<br> <dael> fantasai: Has a scroll snap align with the values you typed. Supposed to take into account when scrolling even when scroll snap is not on.<br> <smfr> q-<br> <dael> faceless2: afaict that defines the alignemnt. There's a margin for spacing. All supposed to be for scrollIntoView type operations<br> <dael> f/faceless2/fantasai<br> <chris> I can't join the WebEx. On IRC only for now<br> <dael> zcorpan_: If needed means if a scroll should happen or not depending on if the element is already visible<br> <dael> fantasai: The default behavior is if needed. So if I tab to something not in view it scrolls to view?<br> <dael> zcorpan_: Exactly. Default is different for focus and scroll into view. Scroll into view always scrolls and focus is only if needed. You can override the behavior for both APIs if we extend the methods<br> <dael> fantasai: Always means what? Scrolls even if in view?<br> <dael> zcorpan_: Yeah, scrolls to spec alignment<br> <dael> fantasai: Like a target. Gotcha.<br> <dael> fantasai: We don't have anything like that.<br> <dael> fantasai: For alignment I recommend reading scroll snap<br> <dael> smfr: Also scroll padding that does scroll margin and padding<br> <dael> fantasai: All take effect even when scroll snapping not on<br> <dael> zcorpan_: That's good. Then possible CSS property is suffiecient and we don't need to override in API. Depends on if you want different alignment for different API calls<br> <dael> fantasai: Start with the CSS property, make sure it's impl, and wait if people ask for different behavior in different APIs<br> <dael> zcorpan_: But ifNeeded primitive still needs to be added if I understand<br> <dael> astearns: Is that an extra value or a new property?<br> <dael> zcorpan_: Not sure if it makes sense as a CSS property. Could add to focus and ScrollIntoView mentor<br> <dael> astearns: And determine if it ineeds to be in CSS on usage<br> <dael> fantasai: If you need to bring something into an alignment on scroll when it's target of ScrollIntoView I think you can turn on scroll snap. Don't know if there's a use case for a CSS property. I can see wanting to get one or other behavior out of APIs with different behaviors<br> <dael> zcorpan_: Agree<br> <dael> zcorpan_: Other issue is that browsers have different default behavior for scroll alignment on focus<br> <dael> zcorpan_: I think the way to fix that is by changing FF to match WK and Blink<br> <dael> zcorpan_: There is a Mozilla bug about that. Not fixed yet.<br> <dael> astearns: Mozilla bug is backed up by spec text?<br> <dael> zcorpan_: The PR leaves scroll alignment on focus undefinedd. We'd need to spec what we want<br> <dael> zcorpan_: Two behaviors are centering or start alignment if I remember correctly. FF does start alignment, WK and Blink do center. That's on focus<br> <dael> astearns: And is there an issue about the default alignment behavior? Did we resolve on what we wanted here and get spec updated to back getting it fixed in Gecko?<br> <dael> zcorpan_: It's part of this discussion, not a sep issue<br> <dael> astearns: Does the PR define the behavior?<br> <dael> zcorpan_: No, not for focus<br> <dael> zcorpan_: If the WG thinks one behavior is better we can resolve and spec. Otherwise we can wait for FF to change or WK or Blink to change to match FF<br> <dael> astearns: I don't know that I have an opinion which behavior is better<br> <emilio> q+<br> <dael> astearns: Could see an argument for Gecko b/c want to start reading at the top instead of having to scroll after focus<br> <astearns> ack emilio<br> <zcorpan_> The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1410112<br> <dael> emilio: I don't know if it's the same bug but we've discussed changes a couple times. We needed feedback from our a11y folks.<br> <dael> emilio: Other thing is if you do scroll if you're already visible. I haven't read the whole log so may have discussed. I remember Blink havign a compat issue we didn't. In general I don't think we'd be opposed to changing<br> <dael> zcorpan_: Bugzilla I pasted in IRC explains the two behaviors<br> <dael> zcorpan_: Three cases we care about. Element entirely in view is no scrolling; interop. Partially in view where WK and Blink scroll to nearest edge in block and inline. Entirely out of view they scroll to center, center.<br> <dael> zcorpan_: Nearest edge is the edge of the viewport closest to the element<br> <dael> astearns: The least amount of scrolling to take the element entirely into view<br> <emilio> https://github.com/w3c/csswg-drafts/issues/4778<br> <dael> emilio: This is more subtile. In inline access WK and Blink used to have a magic value where if it was out of view by less than an amount it wouldn't scroll. That's another thing to take into account<br> <dael> emilio: Generally centering makes sense. For sites that don't use proper padding the element might hide under fixedPos which is unfortunate<br> <dael> astearns: Suggest we resolve to reduce the PR to just the if needed bits and wait to see if Gecko can change and we spec default behavior if they can<br> <dael> smfr: What about prevent scroll argument?<br> <dael> zcorpan_: That is spec and impl<br> <dael> zcorpan_: as far as I know. Not sure if it's everywhere. It is in Chromium at least.<br> <dael> fantasai: astearns there was an argument for why there's centering in Gecko?<br> <dael> emilio: WK and Blink center. Gecko is sometimes unfortunate with scroll padding<br> <dael> astearns: Prop: Reduce PR to just hte If Needed bits<br> <dael> zcorpan_: And check if scroll snapping is enough for alignment use cases<br> <dael> fantasai: If you work on scrolling zcorpan_ read the whole module and let us know if we need adjustments.<br> <dael> zcorpan_: Can do that<br> <dael> smfr: I feel like both css properties and API properties there's a lot about scroll. might need algo to desc interaction. If Needed take into acocunt scroll padding?<br> <dael> fantasai: Should. In scroll module it is expected to apply to all the APIs<br> <dael> smfr: Okay<br> <dael> astearns: If it isn't there might be work a reference to scroll snap in CSSOM View. Just so people can follow breadcrumbs<br> <dael> zcorpan_: Essentially spec ifNeeded behavior in terms of scroll snap<br> <fantasai> https://drafts.csswg.org/css-scroll-snap-1/#scroll-padding<br> <dael> astearns: Objections to change to PR to just ifNeeded bits with a reference to scroll snap as long as it's handling the use cases<br> <fantasai> https://drafts.csswg.org/css-scroll-snap-1/#scroll-margin<br> <dael> RESOLVED: change the PR to just ifNeeded bits with a reference to scroll snap as long as it's handling the use cases<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5677#issuecomment-729828630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 November 2020 17:23:09 UTC