This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
All browsers scroll an element into view [1] upon the element gaining focus [2]. Of course they behave differently in doing so (varying scroll to top, bottom, center). Can we have this scrolling step formally defined so user agents might eventually behave the same way? I'd also like to mention that this scrolling behavior can currently *not* be prevented. When CSS Transitions and CSS Animations are used to reveal the focus target, authors have to wait for the transition to finish before setting focus. If they don't wait, content is at risk of being scrolled by the user agent, effectively messing up any complex UI. It would go a long way if we could extend Element.focus [3] in a way that prevents this native scrolling. [1] http://dev.w3.org/csswg/cssom-view/#scroll-an-element-into-view [2] http://www.w3.org/html/wg/drafts/html/master/editing.html#focusing-steps [3] http://www.w3.org/html/wg/drafts/html/master/editing.html#focus-management-apis
I think this might be a duplicate of an existing bug, but I don't have time to check yet. Adding it to the list in the hopes that I do so soon :)
Is this a duplicate of 16186?
I don't believe this is a duplicate of 16186 per se - although the issues seem closely related. Bug 16186 is looking at things based on document navigation, i.e. in response to the document's URL fragment changing. From what I understand, focusing a particular element does not equate to navigating the document. I may be mistaken and this may actually be the same thing, in which case this bug is to be considered a duplicate of 16186 - with the addition of asking for a way to prevent or delay the scrolling.
bug was copied to whatwg/html - https://github.com/whatwg/html/issues/94
Moved to HTML on Github: https://github.com/w3c/html/issues/300