Button

What you just scrolled through

Cutaway pulls one HTML button through the four stages a browser runs to get it on screen. The button at the top of this page is a real, focusable <button>, not a picture of one, and every plane that separates out of it is measured from that same element.

1. 01 · structure

   The parser turns markup into a tree before anything is drawn. The button starts as one node among its parents and siblings, which is the only reason a selector like .toolbar > button can find it.

2. 02 · layout

   Layout resolves that node into four nested rectangles: content, padding, border, margin. They pull apart in 3D so you can see that the space a button claims on the page is bigger than the rectangle it paints.

3. 03 · paint

   Painting produces an ordered list of drawing operations rather than a button: shadow, background, border, then text. They float apart in spec order, which is why a background can never cover its own text.

4. 04 · composite

   Those drawings are rasterised into layers and handed to the compositor. Flip the promote toggle to lift the button onto a texture of its own, which is what will-change and transforms actually buy you.

Questions

What does a browser actually do with a button?

Four things, in order. It parses the markup into a DOM node, runs layout to resolve that node into content, padding, border, and margin boxes, paints those boxes into an ordered list of drawing operations, then hands the result to the compositor as one or more layers. Cutaway scrubs through each step against a real button as you scroll.

What is the CSS box model?

The four nested rectangles layout resolves for every element. Content holds the text, padding surrounds it, the border wraps that, and the margin holds neighbours away. Only the border box gets drawn, so the room an element takes up is larger than the shape you actually see.

What does promoting an element to its own GPU layer mean?

The compositor keeps most of a page on a single layer. Give an element a transform, an opacity animation, or will-change, and the browser may hand it a texture of its own, which it can then move on the GPU without repainting anything.

Is promoting a layer always faster?

No. Every promoted layer costs GPU memory for its texture. Promote enough elements and you get a layer explosion that burns more memory than the repaints it was meant to avoid. It pays off for a few moving elements and costs you when applied to everything.

Do I need to know any of this to write CSS?

No, and that is rather the point. You can ship buttons for years without it. It starts paying rent the first time you need to know why a margin moved something you did not touch, or why one transform animates smoothly and another stutters.

View the source on GitHub