Bug 263454

Created attachment 468285 [details] Expected result vs. actual result. ## Steps to reproduce (1) Load the JSFiddle (https://jsfiddle.net/donmccurdy/twy3p2zv/), which sets up (1) a WebGL canvas, and (2) an overlay div with matching CSS 3D transforms as described below (2) Adjust the "width" and "height" sliders, scaling the container div (3) Watch position of the ":)" relative to the box ## Expected result The CSS 3D transform should work the same way regardless of the width/height of the parent container, keeping the ":)" div centered relative to the WebGL canvas. ## Actual result The position of the ":)" div shifts significantly for certain values of "width" and "height" In my tests, even-numbered pixel widths and heights seem to avoid the error. ## Additional information The CSS 3D transforms used are coming from THREE.CSS3DRenderer, as found here: https://github.com/mrdoob/three.js/blob/181e04eea8b569dc09048f9dc644310ed6b745a6/examples/jsm/renderers/CSS3DRenderer.js#L128-L183. To briefly describe their purpose and the DOM structure: 1. An outer "viewElement" is sized to match the canvas, and uses `transform-origin: 0px 0px;` and `perspective: 857.803px;` (or similar) to match WebGL perspective. 2. Inside that, "cameraElement" uses `transform-style: preserve-3d;` and a matrix3d transform matching the WebGL camera transform. 3. Within that, an "objectElement" uses a matrix3d transform to position the div within the 3D scene. This is a means of positioning HTML content over a specific region of a 3D scene drawn by WebGL, useful where we want to ensure annotations and interactive elements are done in accessible HTML, on top of a less-accessible WebGL canvas. Versions of this are implemented separately by three.js (https://threejs.org/), React Three Fiber (https://docs.pmnd.rs/react-three-fiber/), and threlte (https://threlte.xyz/), and all implementations hit the same bug. In my writeup for three.js (https://github.com/mrdoob/three.js/issues/26950) I've noted a similar bug in Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=1494366#makechanges), although it triggers under different circumstances – based on the left and top offsets of the parent element, not the width and height. Firefox displays the element position correctly regardless of offset and size, though it does have some other problems when "position:sticky" is introduced to a parent. In both Safari and Firefox, the element is also rendered at lower resolution than might be ideal. If needed, I can come up with a version of this JSFiddle that doesn't depend on three.js.