You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use the map container's offsetHeight and offsetWidth to size the map canvas element, which leads to odd behavior when using a border, including Map#getCenter, Map#getBounds, etc. returning incorrect values for what is visible to the user because some of the map canvas will be hidden by the container.
If we used clientHeight/clientWidth to size the canvas, we would eliminate this behavior, but I'm not sure what the original reasoning was behind the choice to use offset*
This would qualify as a breaking change. If we decide not to make this change, we could specify in the documentation that a map's container cannot have a border.
Expected Behavior
with client{Height/Width} sizing, canvas remains within the main content area of the container element
Actual Behavior
with current behavior, canvas overflows the main content area and is partially hidden due to a border being used on the container element
I think it's save to switch to clientWidth/Height. offsetWidth/Height was there pretty much since the first commit. I would guess that the original reason for the choice is that those two get mixed up all the time. :)
@ryanhamley I think those lines are referring to the Popup element's container, but we probably want to make the change there as well because users may want to use borders on their popups as well.
@jfirebaugh as far as I can tell the projection/transform/mouse event code all relies on the canvas container size
I spent a few hours trying to figure out why the canvas was not respecting the style properties of the container and setting the height="480" for no apparent reason. IT would be ideal to use client height.
We currently use the map
container
'soffsetHeight
andoffsetWidth
to size the map canvas element, which leads to odd behavior when using a border, includingMap#getCenter
,Map#getBounds
, etc. returning incorrect values for what is visible to the user because some of the map canvas will be hidden by the container.mapbox-gl-js/src/ui/map.js
Lines 1474 to 1477 in bf88cd7
If we used
clientHeight
/clientWidth
to size the canvas, we would eliminate this behavior, but I'm not sure what the original reasoning was behind the choice to useoffset*
This would qualify as a breaking change. If we decide not to make this change, we could specify in the documentation that a map's
container
cannot have a border.Expected Behavior
with
client{Height/Width}
sizing, canvas remains within the main content area of the container elementActual Behavior
with current behavior, canvas overflows the main content area and is partially hidden due to a border being used on the container element
cc @mourner @jfirebaugh @kkaefer
The text was updated successfully, but these errors were encountered: