-
Notifications
You must be signed in to change notification settings - Fork 3.4k
element.focus() in $mdSidenav causes page jump #1891
Comments
Focus is necessary for accessibility purposes, so that keyboard and screen reader users are directed into sidenav when it opens. Sounds like we may need to do some CSS wrangling to support both use cases. Can you provide a Codepen or Plunker with your markup showing the jump? |
I am also having this issue, I do not want it to snap, is there a way to override this behavior? I do not want the sidenav to "snap" causing the page to jump. Here is a link to an example of the "snapping": |
Perhaps a fix like this would work:
http://stackoverflow.com/questions/4963053/focus-to-input-without-scolling |
Smooth scrolling is something I've done in the past. That makes it so you can still focus an element and while smoothing out the jump. |
Except thats not the desired effect, why force scrolling? could we have it as an optional config property? I think most people would just want the side nav to slide out and thats it. I would say if people want it to scroll smoothly down, they could just write their own javascript to do it. It just seems to go away from being extensible if you force scrolling. You could implement no scrolling/no snapping and then if someone wants to smooth scroll, they could add an event to handle it. Just my 2 cents. |
The scrolling would only be added to smooth out |
I guess, I wonder why its required to scroll, to me it would make sense to have two behaviors. One that doesn't scroll but still focuses, and one that focuses and scrolls. Could be set by a config property on the side nav. |
This is actually causing us issues in our app, because we want to focus inputs when the sidenav opens - and it appears that this is overriding that for us. |
Or at the very least have an option that disables focus entirely, that way for those who want to create their own focus behavior rather than being forced into one way, could do that. Just have a warning that if you remove focus it will break screen readers until you implement your own. This would fix every issue, with the caveat that in documentation you would have to warn the end user about the possibility of breaking screen readers temporally. |
Ok, this sounds like a good candidate for more options. The |
👍 |
So the issue with scrolling is that the sidenav could be inside of a scrolled element, complicating the calculated offset top. I'll keep working on it, but I'm hoping the override introduced in #2108 will be enough of a fix for this issue. Let me know. |
I'm using the latest version, but It seems to me that this issue is still open...I made a plunker to see the bug. When I open the menù from toggle, the page focuses on sidenav and scroll to it. how to prevent this scroll? |
+1 |
Currently the sidenav is position absolute so it's at the top of the page when it comes in. So when it's focused you scroll to the top. Make it position fixed so when the focus happens it's already in view and goes no where. No js overrides required
|
+1 override with css doesn't work for me |
|
+1 |
+1 |
Something like that. I will css this for now. +1 and thank you. |
The overide with CSS doesn't work for me. I would like my design to remain as such, i don't want to mess with my CSS. It's just the focus behaviour that i would like to turn off. Can this be implemented? |
I'm dealing with the same problem now. Any solutions besides position: fixed; ? |
@midhunadarvin @tellyipock please open a new issue with a CodePen reproduction. |
Hi,
I am building an application which has a layout similar to the angular material design site. At the very top of the page however, is another md-toolbar. Below the first toolbar is the sidenav and the main content area.
With a layout like this when the sidenav is finished opening, element.focus() is called. This causes the page to focus to the sidenav toolbar top, and causes the toolbar above the sidenav to be partially visible (since the page has scrolled). Is it really necessary to have the element.focus() in the updateIsOpen function? If I comment out element.focus(), the issue is fixed.
if (scope.isOpen) {
//element.focus();
}
The text was updated successfully, but these errors were encountered: