CSS cubes really showcase what CSS has become over the years, evolving from simple color and dimension directives to a language capable of creating deep, creative visuals. Add animation and you've got something really neat. Unfortunately each CSS cube tutorial I've read is a bit long and a mixes visual style with the cube basics, so I've decided to write a post which provides just the basic detail needed to create a CSS cube. I'm basing my example off of an outstanding CodePen demo by Mircea Georgescu.

HTML5 is the latest revised specification of HTML which provides some additional tags and features (cross browser support, video, audio, and canvas elements, animation and much more) that give the user some space for doing different advanced things. For instance, one of such features (or tags) is the canvas element. CSS3 3D Flip Button. See the Pen CSS3 3d flip button by Sean Michael (@seansean11) on CodePen.default. Unlike all the other buttons on this list, the CSS3 3D Flip Button displays an effect when you click on it. Once you click, the button rolls up to reveal new text and icons. This is great way to indicate a form has been submitted, for. Close the Blinds. Compatible browsers: Chrome, Edge, Firefox, Opera, Safari. Responsive: yes. Color Layers CSS Animation. Simple colored layers might not seem much, but when they move they can convey loads of character. In this example, a set of semi-transparent HTML paragraph tags are animated, and the resulting stacked animation is hypnotic.

The HTML

The cube element, a wrapper in itself, will actually have a wrapper of its own:

Each face of the cube will have its own element. As you can imagine, we'll be CSS-ing the hell out of them to put them in the proper position.

The CSS

Let's take this one meaningful bit at a time. The first meaningful element is the entire animation wrapper, which will provide a CSS perspective for the 3D element:

CSS perspective is a difficult concept to explain but MDN does a great job so I wont duplicate their explanation. To better understand perspective, I recommend modifying the perspective property to see how it effects the demo. Next up is the cube container which will hold all of the different cube faces:

The cube will be 200 pixels wide, with relative positioning so that the absolutely positioned faces will stay within bounds. We'll also use preserve-3d to keep the element 3D and not flat. Before getting to any of the specific face rules, there will be a few general styles that will apply to each face:

With the position and dimensions of the faces set, we can get to creating the transformation code for individual faces:

The rotateY values rotate the faces of the to move the face show the text at the correct angled, while the translateZ setting moves the elements forward and backward within the stack. The translateY setting may be confusing, but note that it represents raising or lowering a face to show 3D effect via the transparent panes. Each face has its own translations settings to place them in the appropriate place, so feel free to modify those values to see why each corresponds to its face.

Horizontal Spinning of the Cube

Of course, what good is a 3D element set without animating it. The answer: none. No good at all. So here are a few steps we need to take to making our precious cube animate horizontally:

Probably easier than you think, yes? The text looks correct due to the facing rotation we implemented originally, and I've used keyframe animation in case we want to add more sexiness in the future.

Vertical Spinning of the Cube

Spinning the cube vertically should simple require changing the animation to Y axis, right? Unfortunately not -- the panes as they are would show text backward in some cases, so we'll need to revise the rotation of a few elements:

... as well as change the animation.

Flattening the Cube

To remove the 3D look of the cube, and simply display one block at a time (without other face hinting), remove the perspective and origin settings from the wrapper:

Now the only one face will display at any given time.

CSS cubes have been around for a while but I hope this article simplified their composition enough for you to attack your own. And don't get discouraged if you run into issues creating your cube -- I did too! I look forward to seeing what you create!

A few months ago I started looking into the feasibility of enhancing HTML documents for VR using CSS. The idea of the experiment was to demonstrate how easy it could be for developers to create VR experiences using web standards, if browsers implemented stereoscopic DOM rendering and supported VR media queries.

The CSSVR prototype turned out much better than I'd hoped. It answered almost all of my questions and made me ask some new ones. There was, however, an issue with creating 3D content suitable for use in a rich VR experience. Aside from the mathmatical complexities and large resulting DOM trees, constructing 3D scenes and objects from rectangular HTML elements just isn't practical, and is all but useless for creating anything other than primitive shapes.

Unfortunately, unless you start building your experience in a framework like a-frame or use WebGL, there's no other way of creating 3D content because browsers have no idea how to deal with a 3D model. But what if browsers could display models natively? How would that work? Would CSSVR be more viable? Would having access to 3D models in more traditional web design be useful?

Since simulating native support for CSSVR was a success, I decided to try the same thing with 3D models. I spent some time thinking about what my ideal implementation would look like and concluded that, if 3D models were supported natively, they would have to behave just like any other HTML element, flowing with content, be styleable with CSS and — because we're dealing with 3D objects — any transform and perspective values would need to propagate up to the model.

There are a few projects around that provide the means to embed 3D models into a document, but they all seem to rely on <iframe> elements, which effectively sandbox the rendered model from other content — using <iframe> elements in this way was a no-go for me. Unfortunately, I couldn't find anything that fitted my requirements, so I had to create something myself.

The <x-model> element

My solution was to use a custom element to add models to the DOM. Unlike most custom elements, <x-model> doesn't generate any content. The element is simply a placeholder that provides access to the DOM and CSSOM. Loading and rendering of models is actually handled by three.js.

Adding a model to a document is as simple as:

Note: glTF (.gltf and .glb) and OBJ (.obj) model formats are currently supported.

When the first <x-model> element is added to the DOM, a THREE.WebGLRenderer is created and the resulting <canvas> is added to the document. The canvas is styled to cover the viewport and its pointer-events property is set to none, allowing underlying DOM nodes to receive events. A THREE.Scene is also created to host the objects and a light source is added to it.

To render a model, its position, dimensions and transform matrix are resolved by querying the CSSOM while walking down the DOM tree. The model is then placed in the scene using the resulting transform matrix and is rendered to the canvas in sync with the <x-model> element.

The scene is re-rendered every animation frame. If a <x-model> element has an active CSS animation or transition — or if JavaScript is used to modify the CSSOM — the model will automatically render in its new state when the next frame is painted. Here's an example of a model rotating around its Y axis using a CSS animation:

Positioning the model in the correct place was only part of the challenge. To render an object correctly, the renderer must also apply any CSS perspective values and honour any clipping areas defined by elements further up the DOM tree.

In addition to resolving the transform matrix of the model, the camera projection matrix and renderer scissor area (the clipping bounds) must also calculated. As with model transform matrix, these values are calculated by walking up the DOM tree.

The object can now be rendered to the canvas using either a perspective camera (if an ancestor specified a perspective or perspective-origin) or an orthographic camera. With perspective accounted for, the object will now correctly match the original <x-model> element projection and will be clipped where appropriate.

Here's an interactive demo of perspective in action:

For a more comprehensive example, please see the render test page.

Adding models to the CSSVR prototype

Using models in my CSSVR project was a pretty trivial exercise, I just needed to drop in the <x-model> script and its dependencies and I was set. To make things a little easier, I opted to use JavaScript to create the models and position them in my VR 'scene':

Here's what the test scene of 26 ducks looks like:

For the purposes of this article I've been using small models to demonstrate how <x-model> behaves, but large models work just as well. Here's a screenshot of an entire single-object scene, called Sleepy Town, rendered in CSSVR.

Larger scenes present a lighting challenge. Currently, the <x-model> element uses a single light source to light the entire scene, which isn't very flexible. In the case of these larger scenes the default light isn't powerful enough so the output is very dark. To capture the screenshot above, I had to manually hack in some extra lights.

Html Code For & Amp

So lighting is the next thing to tackle — but that's a problem for another day.

3d Animation Maker

In the meantime, if you'd like to experiment with <x-model>, you can find a full set of instructions in the github repo.