-
Notifications
You must be signed in to change notification settings - Fork 645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cssom-view] Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions (Moved to #5677) #1805
Conversation
…lOptions notIfViewed was originally suggested in http://www.w3.org/mid/CAE3TfZPmNWvz1z7XPqFjtg5S+m_9BOmNNHsOZuSrR2z2AgyNHA@mail.gmail.com Now it is needed for HTMLElement focus(options) to match the behavior of focus() in browsers. Since the defaults for focus() is different from the defaults for scrollIntoView(), a new dictionary FocusScrollOptions is introduced. For now the defaults for block and inline are UA-defined. whatwg/html#2787 (comment)
Note that this introduces a boolean dictionary member with default value
https://heycam.github.io/webidl/#dfn-optional-argument-default-value However, the alternative would be to use different members that both default to |
That's a tough one. There's no enum that would work, is there? |
@tobie suggested an alternative name: I'm open for suggestions with enums or other API shapes. |
This? :-/ scrollIntoView({ scroll: "always" });
scrollIntoView({ scroll: "only-when-hidden" }); or: scrollIntoView({ avoidScrolling: "never" });
scrollIntoView({ avoidScrolling: "when-visible" }); |
I like |
Well, then you're back with the boolean defaulting to true issue. |
onlyWhenHidden would default to false, wouldn't it? It does the opposite of
ifNotViewed, which defaulted to true.
|
Well, the issue is both conditions are the default in different APIs. |
"if-needed" would be familiar for developers using |
OK updated the PR per my previous comment. |
Another approach could be to add "-if-needed" suffixes to the keywords in ScrollLogicalPosition. The current
IDL
(No change to |
That looks interesting. |
I don't have a strong preference between these two:
But it looks like the second choice has more benefits for developers. Apart from that, when If it's not, there is no way to do that case.
|
The proposal here says to abort if the element is entirely in view and "if-needed" is specified. If I understand correctly that should cover your use case. But always doesn't mean that scrolling will always take place--e.g., if nearest/nearest is specified and the element is already in view, no scrolling happens. (Or if there's no overflow, there's nothing to scroll.) |
Sorry, I mixed it up. I thought if "if-needed" is specified and the element is entirely out of view, then scrolling happens. So I think it also need to cover this case. |
Currently, the result of Element.focus() on browsers is like this:
You can see how it works here. (Edited by @zcorpan to add Opera, Safari, and to merge same results into a single column.) |
OK, then I think I have misunderstood the requirements. I thought you were happy with a way to turn off scrolling entirely (with So you want to be able to have no scrolling for partially in view, and scroll into view for entirely out of view, correct? Maybe instead of having increasingly complicated dictionaries to cover all possible cases, we could have only |
Yes, no scrolling for partially and entirely in view. |
At this stage, I would like to summarize the current status and suggest some opinions on this PR. 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();
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.
elm.scrollIntoView({behavior: "smooth", scroll: "if-needed"});
elm.scrollIntoView({behavior: "smooth", scrollMode: "if-needed"});
|
Thank you for your analysis and comments @anawhj! Let me try to state my understanding, so we can reach common ground.
To your points:
|
9c4db03
to
f3856df
Compare
As per #1805 (comment) point 2.
I rebased this branch (for |
I agree both that it would work, and that it's not so convenient. Rather than adding another boolean or another value to an enum in the dictionary, which would force us to think hard about naming to make the whole thing non confusing, couldn't we add a numeric That seems to cover everything, without excessive complexity either for authors who want to use this, nor for those who don't care, nor on the implementation side. |
Here is my recommendation on how to best proceed. What we should focus on right now:
What we can do later:
|
cssom-view-1/Overview.bs
Outdated
1. If <var>block</var> is undefined, set <var>block</var> to a UA-defined value. | ||
1. If <var>inline</var> is undefined, set <var>inline</var> to a UA-defined value. | ||
|
||
ISSUE: Define defaults for <var>block</var> and <var>inline</var> for {{FocusScrollOptions}}. | ||
|
||
1. Let <var>position</var> be the scroll position <var>scrolling box</var> would have by following these steps: | ||
1. Let <var>hidden</var> be false. | ||
1. If <var>element edge B</var> is outside (before) <var>scrolling box edge A</var>, or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you push 'tap key' to move the focus to the element partially in view, the focus is moved to the element while scrolling happens to the nearest edge (Chrome and FF). It's the default behavior of focus() and we should support the default behavior even if the FocusScrollOptions
is added into focus().
@zcorpan I agree to add only In addition, |
@zcorpan Thanks for wrapping up the current issue in here. Also, for the future work about FocusScrollOptions, it would be nice to discuss about:
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1410112 |
83e0a2c
to
9c4db03
Compare
It seems all comments consider "Partially in the view" as a single case, but it can be subdivided depending on whether there is available space to show a greater fraction of the element or not. The |
Hey ya'll! I would love to see this move forward 😄 Are we waiting for vendors to give their feedback or can we move forward and get their input later? I maintain a related polyfill for this proposal and based on feedback I'm getting, and the growing popularity of the package itself, I think it's safe to say that developers are very interested. If there's anything I can do to help move things forward then just say the word! 👋 |
Current status: No change, but @annevk said it seems ok to align with Chrome and Safari. No activity.
Edge has switched to Chromium.
Closed as WontFix ("there is no update from the spec discussion in more than 1 year"). |
This pull request is made with a branch in the main repo, rather than from a fork. This continuously puts strain on the build server, which is rebuilding it all the time to keep the bikeshed references current. This is OK for branches that need to have a preview, but this seems stale. It should be (updated and) merged or closed. |
Has there been any movement on the default scrolling behavior for I think it's ok to close this, it can be reopened if there is new interest. We could file an issue so it doesn't get forgotten. |
Yep! It has been merged via a commit in Oct 2017. I believe that the valuable changes in this thread would be needed for many developers. In my side(LG webOS), there are requirements about the following functionalities. A: B: All the cases are mostly covered with the already proposed changes in this thread. |
Moved to #5677 |
TODO: should only scroll into view if needed May need a third-party dependency for that on many browsers. See: w3c/csswg-drafts#1805 https://www.npmjs.com/package/scroll-into-view-if-needed https://caniuse.com/mdn-api_element_scrollintoviewifneeded
TODO: should only scroll into view if needed May need a third-party dependency for that on many browsers. See: w3c/csswg-drafts#1805 https://www.npmjs.com/package/scroll-into-view-if-needed https://caniuse.com/mdn-api_element_scrollintoviewifneeded
TODO: should only scroll into view if needed May need a third-party dependency for that on many browsers. See: w3c/csswg-drafts#1805 https://www.npmjs.com/package/scroll-into-view-if-needed https://caniuse.com/mdn-api_element_scrollintoviewifneeded
notIfViewed was originally suggested in
http://www.w3.org/mid/CAE3TfZPmNWvz1z7XPqFjtg5S+m_9BOmNNHsOZuSrR2z2AgyNHA@mail.gmail.com
Now it is needed for HTMLElement focus(options) to match the behavior
of focus() in browsers. Since the defaults for focus() is different
from the defaults for scrollIntoView(), a new dictionary
FocusScrollOptions is introduced. For now the defaults for block
and inline are UA-defined.
whatwg/html#2787 (comment)