Re: [csswg-drafts] [cssom-view] Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions

At this stage, I would like to summarize the current status and suggest some opinions on this PR.
I attached some comments(//) into the WebIDL below to clarify the meaning of the terms.
enum ScrollBehavior { "auto", "instant", "smooth" };
enum ScrollIntoViewMode { "always", "if-needed" }; // 1. prefer "if-needed" than suffixes"
enum ScrollLogicalPosition { "start", "center", "end", "nearest" };

dictionary ScrollOptions {
  ScrollBehavior behavior = "auto";

dictionary ScrollIntoViewOptions : ScrollOptions {
  ScrollIntoViewMode scroll = "always";
  ScrollLogicalPosition block = "start";
  ScrollLogicalPosition inline = "nearest";

dictionary FocusScrollOptions : ScrollOptions {
  ScrollIntoViewMode scroll = "if-needed"; // 2. scroll to scrollMode
  ScrollLogicalPosition block = "start"; // 3. default value: same as ScrollIntoViewOptions
  ScrollLogicalPosition inline = "nearest";

dictionary FocusOptions {
  boolean preventScroll = false;
  FocusScrollOptions scrollOptions;

void focus(optional FocusOptions options);

// For instances (applied the comments above)
elm.focus({preventScroll: false});
elm.focus({scrollOptions: {behavior: "smooth"}});
elm.focus({scrollOptions: {behavior: "smooth", scrollMode: "always", block: "center"}});
elm.scrollIntoView({behavior: "smooth", scrollMode: "if-hidden", block: "nearest"});

First of all, the current IDL seems so complicated enough to support the scrolling options for the focus function, so I totally agree @zcorpan's opinion to prevent having increasingly complicated dictionaries.

Honestly, before the UA support for smooth scrolling, the feature has been supported by several libraries or polyfills using requestAnimationFrame(). However, in case of scrolling options for the focus function, there seems no way to control the scrolling behavior when the focus is moved to another element due to several reasons such as focus-related events with no cancelable. In addition, the important thing is that developers want to use the native focus function in order to support the focus-related a11y features and one of the biggest challenges is to handle the scrolling.

With such a background, I would strongly suggest that focus function can embrace the FocusScrollOptions dictionary as well as the preventScroll property. The WebIDL above couldn't be happier to me, while the case of partially view would be handled by other API (e.g. IntersectionObserver).

Regarding the WebIDL above, I would like to put some comments, but it's not the strong opinions. The basic design of WebIDL seems well-organized enough to me.

1. **prefer "if-needed" than suffixes of "-if-needed",  prefer "if-hidden" than "if-needed"**
We need an option to specify whether to trigger scrolling or not when the element is fully in the view. Basically, scrollIntoView() enables the scrolling in that case, but focus() doesn't, so we defined the FocusScrollOption dictionary with different default value from the ScrollIntoViewOptions dictionary. As I see, there seems no correlation between "if-needed" that can control to happen scrolling and the ScrollLogicalPosition dictionary that specifies the position after scrolling. In many cases, developers want only to use the "if-needed" option, not to use the "block" or "inline" options, so I'm in favor of the ScrollIntoViewMode approach than the suffixes of "-if-needed" approach.
In addition, it would be difficult to understand the meaning of "if-**needed**" even now. I agree on the design of "if-needed" in consideration of `scrollIntoViewIfNeeded", but it's not the standard API (only support in WebKit and Blink). If this work proceed well, scrollIntoView with "if-needed" could be same as the scrollIntoViewIfNeeded so that it could be deprecated naturally. It seems so difficult to define a new term instead of "if-needed", but I suggest "if-hidden" that means **scrolling only if the element is hidden (partially or entirely in the view)**. I guess "if-hidden" could be used in scrollIntoView method to support several use cases while it has even been supported in JS libraries. Surely no problem to me with "if-needed" as is for BC.

2. **scroll to scrollMode**
`scroll` property name as the ScrollIntoViewMode type seems kind of general term, so I prefer to change the term like scrollMode.
elm.scrollIntoView({behavior: "smooth", scroll: "if-needed"});
elm.scrollIntoView({behavior: "smooth", scrollMode: "if-needed"});

3. **The default values of FocusScrollOptions would be same as ScrollIntoViewOptions**
{block: start, inline: nearest} would be good for FocusScrollOptions (same as ScrollIntoViewOptions)

GitHub Notification of comment by anawhj
Please view or discuss this issue at using your GitHub account

Received on Monday, 9 October 2017 04:39:06 UTC