-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculate correct canvas size if more than one parent container has a css transform property #11493
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent some time trying this out and I think that there's two potential issues.
- We only apply the outermost
transform: scale
to the container width. This works in this case where there's 2 transformed elements but only one has a scaled transform. If we have more than one parent element withtransform: scale
, we won't get the correct output.
Something like this doesn't seem to work. Can/should we apply the transform at each step to end up with the final container width?
#new-container {
width: 1200px;
height: 800px;
transform: scale(2);
transform-origin: top left;
}
#scaled-container {
width: 1920px;
height: 1080px;
transform: scale(0.35);
transform-origin: top left;
background-color: grey;
}
#map-container {
width: 1720px;
height: 880px;
transform: translate(100px, 100px);
}
#map {
height: 100%;
width: 100%;
}
<div id="outer-container">
<div id="scaled-container">
<div id="map-container">
<div id="map"></div>
</div>
</div>
</div>
- I think I see why you had the
&& !transformValues
. It's not exactly the right check, but without it, this loop will always iterate all the way out to the<html>
tag. This could easily be a performance drag, especially if there's quite a bit of nesting in the HTML structure. I'm not sure how to get around this without limiting the potential number of transforms that can be applied.
@ryanhamley Thanks for digging into this. It seems the |
@ryanhamley This solution works in most transform use-cases with the exception of rotateY and rotateX. Since rotateY and rotateX did not previously work since using getBoundingClientRect was introduced, I think it is ok to not support these use-cases, that are likely very unlikely. Let me know what you think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works well to fix the reported issue. Handling rotation seems to involve more than just applying the transformation since it breaks zooming around center and possibly other interactions, so it's fine to not handle it, especially since the use case is unclear.
… css transform property (mapbox#11493) * fix canvas sizing to not stop checking transform at parent container
Fixes #11492. Original solution did not consider if more parent containers had transform properties. This fix continues looking for transform values, and avoids exiting early.
Launch Checklist
mapbox-gl-js
changelog:<changelog>Fixes canvas size if more than one parent container has a transform css property.</changelog>