Bad layout on high dpi at certain browser width

[lheberlie]

This feedback was received from the Zurich JavaScript team at a training event recently hosted. While users were reading the ArcGIS API for JavaScript and the browser zoom (Ctrl/Cmd + 1) is activated on high dpi displays, the layout is bad around the breakpoint. Both navigation tabs and dropdown are visible, and the content is below the sidebar. I am not sure what browser or version was used.

devicePixelRatio: 1.25
window.innerwidth: 1023

[paulcpederson]

I just looked into this and fixing will be extremely difficult. Essentially the problem is that in media queries, once you are zoomed in, the browser handles the math differently. We use max-width: $breakpoint - 1 for some of our media queries and when zoomed in, there is a small number of pixels that actually fall inside that pixel because the 1px is now larger due to being zoomed in. To fix this we would need to do one of several things:

1. use level 4 media queries (width < $breakpoint). This is impossible in Sass currently and has poor support
2. Change all of our breakpoints to use ems/rems. This would be a huge breaking change, and could have bugs with people who are resetting the html font size for smaller type
3. Change how the responsive show hide classes are implemented. I looked into this and because there is no way in css to reset from display: none to the browser default, this will most likely break a lot of people's code.

None of these are appealing to me. This is a pretty small edge case (zoomed in and screen width is exactly X pixels wide), so I think this should be tabled until Sass and Browsers implement level 4 media queries, at which point we can address it.

For what it's worth, bootstrap also had this issue and they decided to not fix: twbs/bootstrap#19197

[sreinhard]

@paulcpederson thanks for looking into this. I see that this is hard to fix properly.

This is a pretty small edge case (zoomed in and screen width is exactly X pixels wide)

The reason I'm running into this regularly, is that the critical pixel width happens to be exactly half the width of my screen, and I often dock the browser with the windows key + arrow keys.

Would it be possible to move the breakpoint by a few pixels to make this edge case less likely to be hit in practice?

My setup (everything pretty common I think):

• OS: windows
• Browser: chrome
• Screen resolution: 2560x1440
• Zoom: 125%

[paulcpederson]

@sreinhard why do you zoom in?

[paulcpederson]

@sreinhard @lheberlie can you two try this out again. There was a slight tweak to the columns, so I'm wondering if that helped at all.

[sreinhard]

@paulcpederson how would I test this? I can still reproduce the issue on https://jscore.esri.com/javascript/latest

The reason I zoom in, is that text is easier to read on my monitor. Note that this is a global Windows setting, which the browser picks up. The zoom level in my browser is 100%.

[paulcpederson]

@sreinhard visit the Calcite Web docs (http://esri.github.io/calcite-web/documentation/) with the configuration that's problematic and see if that breakpoint hits at the exactly wrong place for you still.

The js docs won't be on the newer version of the CSS framework yet.

[sreinhard]

@paulcpederson on this page the half screen layout is ok. the bad layout happens at around 859 pixels now, which is very hard to hit manually for me.

[paulcpederson]

OK, I think we can close this as a known issue. Once level-4 media queries are widely supported and Sass allows their syntax we can reopen and improve.