Firefox and Chrome don't always do shortest path transitions when interpolating between two transformation matrices. In order to rotate an element in the desired direction, use rotate{X,Y,Z}() instead of matrix3d() and use identity transforms like zero-degree rotations or zero-pixel translations to ensure that the beginning and end transform states consist of the same sequence of transform functions.

1. See csscube2.html

   • This uses matrix3d() to rotate a cube 90 degrees at a time about either the X, Y, or Z axis.
   • The arrow key controls are the same as in Block Party 3D.
     • Use the left and right arrow keys to rotate about the Z axis.
     • Use the up and down arrow keys to rotate about the X axis.
     • Use shift + left and shift + right to rotate about the Y axis.
   • Safari exhibits the desired behavior. The cube is always rotated in the desired direction about the desired axis.
   • Chrome and Firefox don't always exhibit the desired behavior. For example, Firefox sometimes rotates the cube 270 degrees in the opposite direction instead of 90 degrees in the desired direction. Chrome and Firefox also sometimes rotate the cube about multiple axes simultaneously instead of just the desired axis.
2. See csscube7.html

   • This uses the rotation method I settled on for Block Party 3D.
   • rotate{X,Y,Z}() are used instead of matrix3d()
   • Before each transition, I ensure that the transform state I'm transitioning from consists of the same sequence of rotate functions as the transform state I'm transitioning to.
3. See "Interpolation of Matrices" in the CSS Transforms spec.

   • Editor's Draft (25 Nov 2014)
   • Working Draft (26 Nov 2013)

Firefox transitions to an incorrect state in certain cases when using transitions and animations with 3d transforms. This may be related to [1].

1. See FirefoxBug.html (doesn't include the -webkit properties), FirefoxBug+Webkit.html (includes the -webkit properties), or FirefoxBugCube.html (includes the -webkit properties)

   • The upside-down A should rotate 90 degrees counterclockwise, but in Firefox it rotates 90 degrees clockwise and then flips to the correct end state.
   • A workaround is to add a zero-degree rotation around the same axis, i.e. rotateZ(0deg), to the transform state at the beginning of the animation (the "from" state).

   
   Note (2/25/2016): The -webkit properties are no longer necessary as of Safari 9.0 (9/30/2015).

Chrome and Safari don't send mouse events (like mousedown and mouseover) to the displayed element in certain cases. Thus mouse event listeners registered in JavaScript are not called, and cursor and hover styles are not triggered.

Note (2/25/2016): This is no longer an issue in Safari. This must have been fixed sometime in the past year between Safari versions 7.1.2 and 9.0.3. However, it is still an issue in Chrome.

1. See WebkitBug.html

   • A div with the number 4 in it is rotated -90 degrees about the X axis.
   • The parent div is rotated +90 degrees about the X axis, thus bringing the number 4 div back into view.
   • The correct behavior would be for the number 4 to turn red and the mouse cursor to change to the one associated with the "move" value when the mouse pointer is anywhere over either div.
   • However, mouse events are not sent to either div (and thus the cursor and color changes are not triggered) unless the mouse pointer is precisely positioned over the X axis.

   
   Mouse events are sent properly in Firefox.
   
   Any of the following can be used as workarounds in Chrome and Safari:

   1. Set the (-webkit-)perspective property to a value other than "none".
   2. Rotate the parent div by a fraction of a degree more or less than 90 degrees, e.g. 90.01 or 89.99 degrees.
   3. Use matrix3d() to rotate the parent div 90 degrees.

   
   The workaround used in Block Party 3D is to set -webkit-perspective to 100000px when the perspective checkbox is unchecked.

See IntersectBug.html

• This is a modified version of the example given in comment #26 for Chromium Issue 126479.
• Safari renders these intersecting divs correctly.
• Chrome and Firefox render the entire red div above the green div. However, mouse events are still sent to the green div in the area where the red div should be behind the green div. So mouse events are sent correctly, but the right side of the red div should not be displayed.
  
  Note (2/25/2016): Chrome now renders these divs correctly. This must have been fixed sometime in the past year between Chrome versions 39.0.2171.95 and 48.0.2564.116.

Safari stacking order bug: Elements like the "solverReasonBox", "partyReasonBox", and "gameBox" divs should be stacked on top of the "space" div (and thus they should always appear on top of all of the 3d-transformed blocks which are descendants of the "space" div) since they're positioned (absolute or fixed) like the "space" div, and they appear after it in the HTML (see "Stacking without z-index"). However, Safari will render the parts of 3d-transformed elements that have Z coordinates greater than 0 above any such divs that should be higher in the stacking order. Explicitly setting the z-index of all involved elements (in CSS or JavaScript) doesn't change this behavior. Mouse events, however, are sent correctly to the topmost element in the stacking order. Firefox and Chrome render the stacking order correctly. The workaround used in Block Party 3D is to push the blocks below the z=0 plane when they're not being dragged.

Safari transition bug: Changing the duration of the "left" transition for the "partyReason" class from 0.4s to 0.5s causes the divs of that class to not transition left to exactly 0px. The transition seems to stop at 1px or 2px. Firefox and Chrome handle the transition correctly regardless of the duration.