CSS3DRenderer elements position offset on browser zoom

I am using the WebGLRenderer to output 3D Geometries and CSS3DRenderer for user interface element and text. Unlike the examples, I have fitted both renderers inside a div, as I have a sidebar for eccomerce/other UI purpose.

The setup works fine using 100% browser zoom level, however on certain browser zoom on Chrome, the positioning of the CSS3DRenderer objects is shifted weirdly.

I have created an example on CodePen using a perspective camera. Positioned a 3D cube(Red color) and CSS3DObject divs(yellow color) at the same position.


At 100% browser zoom, both WebGL rendered elements and the CSS3D elements are in the same position

90% zoom broke
At 90% browserzoom, the renderers diverge. Somehow they converge again at certain zoom points. In chrome 75% browserZoom the renderers converge again. Any ideas what is causing this issue?

Notes:

  1. In full screen examples, using window.height and window.width this does not occur.
  2. This only occurs using perspective camera, orthographic camera works fine
  3. The position of the actual div elements seems correct if I go through the . However graphically it is shifted…
    position of div
  4. Seems like a possible solution would be to use an iframe so that window sizing can be used but Id rather find out what went wrong here.
  5. Issue on Chrome Version 87.0.4280.141.
  6. Firefox 84.0.2 works fine.

Is this a duplicate of the following stackoverflow thread?

Seems that the previous zoom issue affecting chromium matrix3d() transform with different page zoom levels was fixed in 2016 which should enable proper usage of browser zoom and matrix3d transform.

This seems to be a different issue but Chromium specific issue as well as the the codepen example works flawlessly with Firefox 84.0.2.

But the stackoverlflow post is from 2018 :thinking:

18th Feb 2014 post :innocent:, and was only solved later in 2016 from a 2013 chromium bug report :sweat_smile: 242685 - chromium - An open-source project to help move the web forward. - Monorail

1 Like

Oh you are right! I was confused with the English date syntax :man_facepalming:. Sorry!

Yes, what was posted in another forum years ago does NOT have to do anything with this forum.

As for the problem , make sure your document has body tag attached and set its margin to 0. Also font-size: 0 will help clean up the unwanted white spaces.

1 Like

I don’t see how adding the margin 0 and font-size 0 would help but I added it plus some other body resets into the codepen anyway with body tag with no effect.

I have already ensures the CSS3DRenderer div and WebGLRenderer are in the same location with same height and width.

As for body and font-size you’re right, codepen does take care of that for you - but adding the following CSS does seem to fix the issue:

* {
  margin: 0;
}

It’s probably just some browser-specific / codepen-specific CSS kicking in at specific zoom levels - your code and all calculations are 100% fine.

1 Like

body !== .body

See it for yourself Test.html (3.8 KB)

1 Like

Not a good practice

Ahh, my bad. Yea, you are absolutely right on this. Adding margin:0 to the body solves the issue.

Thanks.

Update:
For Chromium based browsers, it seems that Browser zoom will break the display position of the CSS elements in the CSS3DRenderer unless CSS3DRenderer is positioned on position 0,0 of the window.

This was probably why setting body margins to 0 earlier worked and full screen examples are not affected.

Anything else causes visual positioning issues with zoom such as a left sidebar or topbar/content.

Example codepen with lhs sidebar:

I am gonna take a break from this and finish up my work. The I will decide whether to use an iframe which based on the codepens is a viable workaround or leave it and put a warning somewhere.

1 Like