DEV Community: Nicholas Stimpson

"15 Puzzle" slider game in HTML and CSS

Nicholas Stimpson — Mon, 29 Jul 2024 06:16:28 +0000

Skip to puzzle

The other day, a recollection popped into my mind of a small puzzle toy from my childhood, a slider puzzle where 15 square tiles are placed in a frame in a 4 x 4 arrangement of cells leaving one free space. A set of ridges and grooves on the edges of each tile and the frame allows the tiles to slide past one another whilst holding the tiles in the frame. At any given time any tile adjacent to the free space can move into that space, and otherwise the tiles are prevented from moving. Moving a tile into the free space then leaves a new free space where the tile came from and another tile can then move into that new space. The idea is by repeated sliding of the tiles in this way to arrange the tiles into some predetermined order.

Apparently this is called a "15 Puzzle" and has been around since the 1870s. Searching the web returns a number of recreations written in a variety of programming languages and indeed there are several articles here on dev.to including https://dev.to/artydev/let-us-code-a-sliding-puzzle-9n, https://dev.to/xzanderzone/making-a-slider-puzzle-in-java-script-83m, and https://dev.to/claurcia/slide-puzzle-5c55 all in JavaScript and https://dev.to/mfbmina/building-a-sliding-puzzle-with-go-3bnj in Go. It's also presented as a good starter challenge for those learning JavaScript.

What piqued my interest though was the idea that it ought to be recreatable on the web using no programming language at all! That is, an implementation using just pure HTML and CSS. So I present it below. The one compromise I had to make was that the 10 games provided have fixed pre-shuffled starting positions.

For this, the predetermined order is to show a completed picture.

The basic principle of this implementation is that each tile retains a state record of where it is within the frame. There aren't many ways to change and hold state in HTML and CSS, but the most common is the "checkbox hack" and this implementation makes heavy use of it. For anyone unfamiliar with the checkbox hack, when a <label> element is clicked or tapped the activation behaviour of its associated form control, if it has one, is fired. When the associated control is a checkbox, the checkbox state is toggled, unchecked to checked and checked to unchecked. Similiarly, when the associated control is a radio button, that radio button is checked, and any other radio button in the same group that was checked is unchecked. Then a CSS selector can measure the checkedness of the control via the :checked pseudo-class and apply different CSS to other elements depending on that state.

So each tile has a pair of radio button groups each with four radio buttons. One of these groups retains the tile's position in the X-axis and the other its position in the Y-axis. (Or horizontal position and vertical position respectively, if you prefer.) The fifteen tiles are each initially given a different combination of X and Y coordinates via their radio buttons so that each one occupies a different cell in the frame.

The tiles are initially placed in the frame's top, left cell and are then moved within the frame via CSS measuring the state of the radio buttons by applying a translation transform to them:

/* "X" refers to the X-axis cell positions, "Y" to the Y-axis cell positions. 
 * 0, 1, 2, 3 refers to the position on that axis, 
 * 0 = left and top, 3 = right and bottom respectively.
 */

.tile:has(.X0:checked~.Y0:checked) {
     transform: translate(0%, 0%);
}
.tile:has(.X0:checked~.Y1:checked) {
     transform: translate(0%, 100%);
}
.tile:has(.X0:checked~.Y2:checked) {
     transform: translate(0%, 200%);
}
.tile:has(.X0:checked~.Y3:checked) {
     transform: translate(0%, 300%);
}
.tile:has(.X1:checked~.Y0:checked) {
     transform: translate(100%, 0%);
}
/* and so on for the remainder of the sixteen combinations */

The tile then also contains eight label elements, corresponding to the eight radio buttons. Each label is absolute positioned overlaying one another and each completely fills the tile. The labels are transparent, and are initially set up to not respond to clicks and taps by setting pointer-events:none on all of them.

The next step is for the CSS selectors to identify where the empty cell is. This is done by elimination, it's the cell for whose X,Y coordinates are not represented by the radio button group pair of any of the fifteen tiles.

For example, if this matches:

.frame:not(:has(.tile .X0:checked~.Y0:checked)) { .... }

then the empty cell must currently be in the top left hand corner cell. Repeat this for each of the sixteen cells and exactly one of them will match.

Once that is done, the cells of adjacent to the empty cell can be identified. If the empty cell is in a corner, then there are exactly two tiles that can move into that cell, otherwise, if the empty cell is against one of the frame's sides, there are three tiles that can move into the cell, otherwise the empty cell must be one of the four middle cells, and there are four tiles that can move to it. For each of those tiles, exactly one of the tiles' eight labels will activate the correct radio button necessary to move the tile to the empty cell. That label is enabled by setting itspointer-events value back to auto. So as examples:

/* Top, left corner */
.frame:not(:has(.tile .X0:checked ~ .Y0:checked)) {
  :is(
      .tile:has(.X0:checked ~ .Y1:checked) label.Y0,
      .tile:has(.X1:checked ~ .Y0:checked) label.X0
    ) {
    pointer-events: auto;
  }
}

/* right most cell of row two */
.frame:not(:has(.tile .X1:checked ~ .Y3:checked)) {
  :is(
      .tile:has(.X1:checked ~ .Y2:checked) label.Y3,
      .tile:has(.X0:checked ~ .Y3:checked) label.X1,
      .tile:has(.X2:checked ~ .Y3:checked) label.X1
    ) {
    pointer-events: auto;
  }
}

/* second cell from left on row three */
.frame:not(:has(.tile .X2:checked ~ .Y1:checked)) {
  :is(
      .tile:has(.X2:checked ~ .Y0:checked) label.Y1,
      .tile:has(.X2:checked ~ .Y2:checked) label.Y1,
      .tile:has(.X1:checked ~ .Y1:checked) label.X2,
      .tile:has(.X3:checked ~ .Y1:checked) label.X2
    ) {
    pointer-events: auto;
  }
}

The last step of the game is to identify when the puzzle is solved. This is simply a case of checking that the 15 tiles all have their expected X and Y axis radio buttons set to their "solved" position.

/* Each tile is assigned a letter "a" to "o". 
 * The puzzle is solved when the tiles are in alphabetical order
 * reading left to right and top to bottom
*/
.frame:has(.a .X0:checked ~ .Y0:checked):has(.b .X1:checked ~ .Y0:checked):has(
    .c .X2:checked ~ .Y0:checked
  ):has(.d .X3:checked ~ .Y0:checked):has(.e .X0:checked ~ .Y1:checked):has(
    .f .X1:checked ~ .Y1:checked
  ):has(.g .X2:checked ~ .Y1:checked):has(.h .X3:checked ~ .Y1:checked):has(
    .i .X0:checked ~ .Y2:checked
  ):has(.j .X1:checked ~ .Y2:checked):has(.k .X2:checked ~ .Y2:checked):has(
    .l .X3:checked ~ .Y2:checked
  ):has(.m .X0:checked ~ .Y3:checked):has(.n .X1:checked ~ .Y3:checked):has(
    .o .X2:checked ~ .Y3:checked
  )
  ~ .options
  .success {
  display: block;
}

The rest is cosmetic. The sliding is done with a simple transition of the transform described above

.tile {
  transition: 0.5s transform;
  @media (prefers-reduced-motion) {
    transition: none;
  }
}

and each tile shows a portion of the game's image using background-size and background-position

.tile {
  background-size: 400%;
}
#board1 .tile {
  background-image: url("https://alohci.net/image/dev.to/slidergame/mullermarc-k7bQqdUf954-unsplash.webp");
}
.a {
  background-position: 0% 0%;
}
.b {
  background-position: 33.333% 0%;
}
.c {
  background-position: 66.667% 0%;
}
.d {
  background-position: 100% 0%;
}
.e {
  background-position: 0% 33.333%;
}
/* and so on for the remaining tiles */

and there's a single set of radio buttons to choose which of the ten games to play.

To play the game, simply click or tap on the tile you want to slide to the empty cell.

I've also provided a "barebones" mode to show the tile letters and radio buttons which might help with the understanding of how the HTML and CSS works.

So here's the completed puzzle game. Please let me know any feedback you have.

Hot Cross Buns

Nicholas Stimpson — Fri, 29 Mar 2024 17:29:34 +0000

This is a submission for DEV Challenge v24.03.20, CSS Art: Favorite Snack.

Inspiration

Easter is a time for Hot Cross Buns

Demo

(Note that codepen is quite slow in displaying this image)

OK, here's the thing. While I consider myself competent at CSS, my artistic skill is close to zero. So I cheated.

While the image created in the codepen above is formed in CSS, the text-shadow was not hand written. I photographed some real hot cross buns, loaded it in a canvas

const canvas = document.getElementById("canvas");
const ctx = canvas.getContext("2d");

const image = new Image();
image.src = "...";
image.addEventListener("load", () => {
  ctx.drawImage(image, 0, 0, 100, 100);

  const imageData = ctx.getImageData(0, 0, 100, 100);
  ...;
});

I then looped over the image data pixel by pixel, and wrote it back out as a text-shadow.

  const data = imageData.data;
  let fs = 1;
  let d = 0;
  let ts = [];
  for (let y = 0; y < imageData.height; y++) {
    for (let x = 0; x < imageData.width; x++, d+=4) {
      ts.push((x * fs - 50) + 'vmin ' + (y * fs - 50) + 'vmin ' 
         + '0vmin rgba('
         + data[d] + ', ' 
         + data[d + 1] + ', ' 
         + data[d + 2] + ', ' 
         + data[d + 3] / 255 + ')');
    }
  }
  console.log(ts.join());

The text-shadow is of a single character - the Unicode Character 'BLACK SQUARE' “■” (U+25A0) with a transparent colour.

Licence: CC-BY

Questions From The New Cascade

Nicholas Stimpson — Sat, 05 Mar 2022 02:28:31 +0000

Cascade layers is probably the biggest upgrade the CSS cascade has had since its inception. Now that Chrome has joined Firefox in having cascade layers enabled by default, and there's various articles available describing them, it's time to start thinking about how to use them. Have you grokked them yet?

To test yourself, here's three small questions about them, plus explanations of the answers. Let's get started.

Question One

What colours are used for the foreground text and the page background in the following

<!DOCTYPE html>
<html lang="en-gb">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Question One</title>
  <style>@import url("data:text/css, \
    body.myBody { \
       background-color:blue; \
       font-size:4em; \
    } \
    * { \
       color:yellow !important; \
    } \
    ") layer; 
  </style>
  <style>
    body { 
      background-color: red;
      color: white !important;
    }
  </style>
</head>
<body class="myBody">
Hello World
</body>
</html>

Codepen with answer
(Link, because it seems dev.to doesn't support embedding a codepen within a disclosure section.)

Reveal Answer Explanation

The text colour is yellow and the background colour is red.

The first thing to understand is the @import. Normally, this would link to an external style sheet, but here for the benefit of having everything in one place for demonstration purposes, I've used a data url.

The "layer" keyword at the end tells the browser to place all the contents of the imported resource into a layer. The layer is not named, so it is an "anonymous" layer. Anonymous layers work like named ones, except they can't be referenced so once defined they can't be added to, and they can't be manipulated in the layer order.

So in this case, the @import is exactly equivalent to

@layer {
    body.myBody {
       background-color:blue;
       font-size:4em;
    }
    * {
       color:yellow !important;
    }
}

Taking the background colour first where all the declarations are non-important, if the layer was not involved and specificity was the determining factor, the body.myBody { background-color:blue; } rule would beat the body { background-color: red; } rule and the background would be blue.

But for non-important declarations, rules in a layer are always lower precedence than rules not in a layer, so the body { background-color: red; } rule wins.

For !important declarations like the text colour, the opposite applies. Layered rules take precedence over unlayered rules regardless of specificity, so the * { color:yellow !important; } rule wins.

Question Two

This question looks similar. The unlayered styles have been moved to be inline styles of the body element. Again, what are the final text and background colours? Is it the same answer?

<!DOCTYPE html>
<html lang="en-gb">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Question Two</title>
  <style>@import url("data:text/css, \
    body.myBody { \
       background-color:blue; \
       font-size:4em; \
    } \
    * { \
       color:yellow !important; \
    } \
    ") layer; 
  </style>
</head>
<body class="myBody" style="background-color:red;color:white!important">
Hello World
</body>
</html>

Codepen with answer
Reveal Answer Explanation

The background is still red, but now the text color is white.

In the answer to question one, I explain that !important layered styles have precedence over !important unlayered styles regardless of specificity. Yet here the inline style wins.

In CSS 2, inline styles were unambiguously part of specificity. There any innumerous guides to specificity that will tell you that.

Yet in CSS 3 until now, the relationship between inline styles and specificity has had a distinctly ambiguous air. The specifications have neither wholly placed inline styles as part of specificity, nor provided any alternative.

With Cascade layers that ambiguity has finally been removed. Inline styles are no longer part of specificity! Instead they have their own precedence level in the cascade called "Element-Attached Styles". Element-Attached Styles have a precedence which is above both cascade layers and specificity. So an Element-Attached style wins over layered styles even when !important is used on both.

Question Three

Something different now. What are the rendered sizes of the three images? (For those not familiar with placeholder.com, the image supplied from http://via.placeholder.com/100 will have intrinsic dimensions of 100px x 100px.)

<!DOCTYPE html>
<html lang="en-gb">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Question Three</title>
  <style>
    img { 
      height: 200px; 
      width:200px; 
    }
    .beta { 
      height: revert; 
      width:revert; 
    } 
    .gamma { 
      height: revert-layer; 
      width:revert-layer; 
    } 
  </style>
</head>
<body>
  <img 
    class="alpha" 
    src="https://via.placeholder.com/100"
    height="150" width="150" 
    alt="100 pixel square placeholder">
  <img 
    class="beta" 
    src="https://via.placeholder.com/100"
    height="150" width="150" 
    alt="100 pixel square placeholder">
  <img 
    class="gamma" 
    src="https://via.placeholder.com/100"
    height="150" width="150" 
    alt="100 pixel square placeholder">
</body>
</html>

Codepen with answer
Reveal Answer Explanation

The image sizes are 200px x 200px, 100px x 100px & 150px x 150px respectively.

Image alpha is 200px x 200px. Until the introduction of cascade layers, the values of the HTML height and width attributes were treated as presentational hints at the start of the author origin style sheets with a specificity of 0, so any matching CSS rules would take precedence over them, and the HTML dimensions are only a resort to be used if CSS doesn't provide any. So the CSS provided dimensions win.

Image beta is 100px x 100px. Introducing cascade layers produces a slight problem though. Because non-important layered styles have lower precedence that unlayered styles, if the HTML attribute presentational hints were treated as unlayered styles, then they'd have precedence over any CSS in a layer. That not ideal. So a new origin has been created for them called the "author presentational hint origin". This has precedence lower than all layered and unlayered styles.

However, the "revert" keyword has well established behaviour. When effective in an author origin style sheet, it will revert the author origin matching styles including the presentational hints. So to maintain that behaviour, "revert" has been slightly redefined to include the reverting of the "author presentational hint origin".

As a result, the "revert" has the effect of taking the size of the image back to its intrinsic dimensions.

Image gamma is 150px x 150px. You might think that as there don't appear to be any cascade layers in use in the CSS, that "revert-layer" would either do nothing at all, or do the same as "revert". In fact, since it's in an unlayered style, it reverts the unlayered styles of the image dimensions.

But it is free from any backward-compatibility restrictions, so it doesn't revert the styles of the "author presentational hint origin", and so the image is displayed using the dimensions taken from the HTML attributes.

Mapping HTML to CSS boxes.

Nicholas Stimpson — Tue, 31 Dec 2019 18:27:49 +0000

Let’s start with a quick quiz. You know everything in CSS is a box, right? A box being one of those things with a content area, and padding, borders and margins around it. Of course you do. So in this simple HTML example below, starting from the outer div and including its descendants, how many block and inline boxes are used to render it?

Two? Well, there’s two elements, the inner div and the outer div. An HTML element becomes a box in CSS right? So just the two block boxes then. Sorry, no.

Four? All block boxes are block container boxes. Block container boxes contain as their children either (a) only block-level boxes or (b) only inline-level content. The inner div meets that requirement - it only contain inline-level content. But the outer div appears to be containing two inline-level text runs and one block box. When this happens, CSS automatically adds anonymous block boxes around the text runs. That way, the outer div contains only three block boxes and no inline-level content. And the two added anonymous block boxes contains only inline-level content, so now all the block boxes meet the requirement.

Seven? Block boxes cannot contain text runs directly though. Each one has a single child inline-level box called the "root inline box". So we have two block boxes for the divs, two anonymous block boxes, and three anonymous root inline boxes making a grand total of seven. Hurrah! we’re there.

The actual box tree arrangement looks like this…

DIV.outer block box (1)
  anonymous block box (2)
    anonymous root inline box (3)
      Text run: "The Vogons prepare to destroy the earth to make way for a hyperspace bypass."
  DIV.inner block box (4)
    anonymous root inline box (5)
      Text run "The dolphins depart."
  anonymous block box (6)
    anonymous root inline box (7)    
      Text run "So long and thanks for all the fish."

So what’s the point of this? It’s just a reminder that the relationship between HTML elements and CSS boxes is rather more subtle than it may seem at first glance.

More Boxes than Elements

The display property has a profound effect on both the type and number of boxes to which an element maps. Here’s some more examples of situations where elements generate either more than a single box.

The generation of anonymous block boxes described above applies for all block containers. So computed display values of inline-block, table-cell and list-item can all generate those boxes when necessary.
display:list-item and the proposed but only currently implemented in Firefox display:inline list-item also generate at least two boxes, a principal box and a marker box.
(The marker box is always a child of the principal box, even when it’s positioned "outside".)
display:table and display:inline-table elements also generate at least two boxes. A table-wrapper box and inside that, a table grid box. When CSS properties are assigned to an element with display:table, some of the properties are assigned to the table-wrapper box and some to the table box, but never both. For all the properties not assigned, the values used are the default ones for the property.

For example, any specified margin is applied to the table-wrapper box, so the margin of the table box is 0px all round. But any specified value of overflow is applied to the table box, so the overflow value for the table-wrapper box is always “visible”. As well as the table box, the table-wrapper box contains any boxes generated by the caption element if one exists.
Table layouts can also result in anonymous table objects. The structure for HTML tables is table – tbody – tr – td, which maps to the CSS display values table - table-row-group - table-row - table-cell. How each of these works within the layout depends on both their context and content.

So what happens if a div element is assigned display:table-row on its own in the CSS? It generates three boxes: an anonymous table or inline-table box, which surrounds the table-row box of the element, which in turn contains an anonymous table-cell box, which contains the div’s contents. So if the HTML is:
<div style="display:table-row">Lorem ipsum dolor sit amet</div>

the box structure is

Anonymous table box (1)
  DIV table row box (2)
    anonymous table cell box (3)
      anonymous root inline box (4)
        Text run: "Lorem ipsum dolor sit amet"

Similarly, if a lone display:table-cell element is present, it is wrapped in anonymous table-row and table boxes. Sufficient anonymous inside or outside boxes will always be generated to meet either the pattern table - table-row - table-cell or table - table-row-group - table-row - table-cell.

So for another example, suppose we had:
<div class="outer" style="display:table"> <span class="inner" style="display:table-row-group"> lorem ipsum dolor sit amet </span> </div>

that would form:

DIV.outer table wrapper box (1)
  DIV.outer table grid box (2)
    SPAN.inner table row group box (3)
      anonymous table row box (4)
        anonymous table cell box (5)
          anonymous root inline box (6)
            Text run: "Lorem ipsum dolor sit amet"

Fewer Boxes than Elements

On the other hand, there are a couple of display values that cause no box to be generated at all. display:none and display:contents do that. display:none affects descendant elements as well so they do not generate boxes either, while the descendants of display:contents elements generate boxes normally.

Why Boxes Matter

So can we make use of knowing this? It can help us understand why CSS doesn't always do what we expect it to, and it can help us spot solutions to particular layout problems.

For example, let’s suppose we have

we might have expected that the .cell element would be 200px tall and the text "Hello World" vertically centered in it, since that's how table cell vertical alignment normally works. But it’s at the top. That's because the table-cell’s height isn’t 100% of the .outer element, but 100% of the anonymous table box. And because it’s anonymous, it can’t be styled to be anything other than the default height:auto, and auto means that it's the height of its content. Which is just the height of the text.

As a second example, suppose we have some nicely semantic HTML like this.

The default styling for displaying on a desktop might be just what we want. But on a mobile, we might want to compress it down a bit and for good responsiveness lay the title and list items using a flexbox layout. Now if we just give the div element display:flex, it'll have two flex items, the first created by the h1 element and the second created by the ul element. Evening up the fonts and spacing, we get something like this:

That's not compressed it much. If we wanted the list items to follow on from the heading horizontally we could try making the ul element display:flex as well. However, doing that the items won't wrap under the heading, so we still get this:

Which hasn't helped. If we want the items to wrap under the heading, we need the list items themselves to participate in the same flexbox as the heading. Fortunately, if we realise that the flex items are the boxes created by the elements rather than the elements themselves, then we can simply remove the box created by the ul element, and the boxes created by the li elements will become the flex items. The div flex container will then have six items instead of two. All we have to do to remove the box created by the ul element id to apply display:contents to it. And the result is this:

This article is a revised version. The original article described the boxes that would be generated according to the CSS 2.1 specification. The CSS Inline Module Level 3 specification makes some changes to that. Most notibly, if we have this markup <div>The <span>dolphins</span> depart</div> (with default styling), in CSS 2.1 "The" and "depart" would each be contained in their own dedicated inline box. In CSS 3, there's a single root inline box which surrounds "the", the inline box generated by the span, and "depart". So in total, CSS 3 defines there to be one fewer box than CSS 2.1 does.

In addition, CSS 2.1 says that each rendered line contains a "strut" which is described as "as if" it were a zero width inline box. CSS 3 instead clarifies that, saying that the strut is a zero width glyph and only exists at all if there's no existing glyph that can do the job of applying a minimum height to the line.

CSS3 also makes clearer that when text breaks across lines, the inline box does not become two inline boxes, but is still one box, fragmented.

Comments, corrections and follow-up questions are most welcome. Even tl;dr.

Is this element visible?

Nicholas Stimpson — Sat, 13 Jul 2019 15:30:37 +0000

The sample couldn't be much simpler. The question is, is the div element containing the text "Hello World" visible or hidden?

Visible right? Well maybe. jQuery begs to differ!

The problem lies is jQuery's (and widely copied) definition and implementation of its check for visibility. The definition is

Elements are considered visible if they consume space in the document. Visible elements have a width or height that is greater than zero.

The implementation is

!! (el.offsetWidth || el.offsetHeight || el.getClientRects().length)

The div in question has a CSS property display value of "contents", which means that it creates no layout box of its own. Its child elements' layout boxes are instead directly connected to its parent layout box. The CSSOM specifications say that offsetWidth, offsetHeight and getClientRects().length must all return zero for such an element

For both offsetWidth and offsetHeight If the element does not have any associated CSS layout box return zero and terminate this algorithm.

for getClientRects() If the element on which it was invoked does not have an associated layout box return an empty DOMRectList object and stop this algorithm.

So in the light of this, what should be done? The intuitive answer clearly doesn't tally with the technical details. And it's not clear to me from a developer perspective whether an element with no layout box really should be considered visible, just because its contents are. Yet from a user perspective it seems obvious that it should. Do we need a third state beyond "visible" and "hidden"?

CSS concepts questions

Nicholas Stimpson — Mon, 10 Jun 2019 16:45:23 +0000

By the time I started creating web pages, CSS had been invented, but browser support was in its infancy. So I started styling in HTML at the same time as I was learning my HTML, approaching both largely with a suck-it-and-see attitude.

Want to bold my text? Umm... <B>...</B>. Well, that seems easy enough. Italics? <I>...</I>. Check. Make my text red? Ah that's slightly trickier. I need to use <font> with a color attribute, but OK, not too bad, and Ooh, there's a couple of other cute things I can do with that tag too.

Then browser support starts to improve, and I'm told that I should be using CSS instead. Initial reaction was resentment. Give up these nice simple tags for some new, strange syntax? But I've got to do it, apparently.

OK. So let's see. We've got a style attribute, and we can put it on any element. OK. So.. style="color:red". Maybe that's not so bad. What about a light grey background colour? Let's try style="color:red background-color:lightgrey"... Huh, well that didn't work, the text's not even red anymore. Ah, it needs a semicolon. Try style="color:red; background-color:lightgrey"... Yes that's got it. But the background's a bit tight to the text. Need to expand out the background a bit. Ah padding! Yes, that looks better.

And so it goes on. Practically everyone learns CSS more or less this way. We learn more and more properties and how they interact and conflict, we learn about CSS rule sets, selectors, the cascade, inheritance, and gain a fuller grasp of the box model. And these are all learnt from cookbooks and, these days, how-to-do-X questions and answers from venues like Stack Overflow.

Eventually though, I started to get frustrated. Some things I just couldn't get to work the way I expected them to, and the cookbooks didn't help. Many CSS devs hit this when they get to vertical alignment, and so did I, but there are other curiousities too. So I started reading the CSS specification. After several goes the words began to make sense, and I realised that I had missed out on learning practically all the CSS concepts that underpin the properties.

To explain what I mean, here's ten questions about CSS concepts, rather than how-to-do-X. The answers can all be found in the CSS 2.x specification which is now more than two decades old and has excellent browser support. Given its age, there really should be no reason for anyone who works regularly with CSS not to know the answers. So, how many can you answer?

How big is the canvas?
What is the subject of a selector?
What is !important's place in the cascade?
What are the location and dimensions of the initial containing block?
What vertical alignment does the strut have?
When does clear:left cause clearance to occur, and how does that affect margins?
When the width of an non-replaced block-level element in normal flow is over-constrained and does not total exactly 100% of its containing block's width, which property's used value differs from its computed value?
When does an anonymous table-row object get generated?
When does a single element establish both a block formatting context and an inline formatting context at the same time?
What is an inline element's aligned subtree?