- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 May 2017 05:17:38 +0000
- To: public-css-archive@w3.org
When the UA is doing the focusing itself, based on the tab key or actual mouse focusing, I believe this is probably OK to leave as a quality of implementation. But when you are doing the focusing via javascript, I can see how the UA, lacking some information about the context and about why something is being focused, could do it wrong (and scroll too much, or in ways unexpected to the user). So having some way to control that seems useful. Since you want different scrolling behaviors depending on how the script triggers the focus, I think that the parameter to Element.focus() makes more sense than the css property. I think maybe the values should be different though, as I am not sure "none" is a desirable value. Having a focused element be entirely off screen doesn't sound good. Maybe the choice is more between: 1. when focusing an element, if it is not already entirely within the [optimal viewing region](https://drafts.csswg.org/css-scroll-snap/#optimal-viewing-region), scroll to put it there. 2. when focusing an element, if it is already partly within the [optimal viewing region](https://drafts.csswg.org/css-scroll-snap/#optimal-viewing-region), don't scroll. If it is entirely outside, do scroll. That said, option 2 still has issues: if only 1px is in the optimal viewing region, you probably want to scroll anyway. But where is the threshold? -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1388#issuecomment-302610940 using your GitHub account
Received on Friday, 19 May 2017 05:17:46 UTC