Posts in the CSS Category

Accordion Rows in CSS Grid

Published 3 months, 3 weeks past

Another aspect of the meyerweb redesign I’d like to explore is the way I’m using CSS Grid rows to give myself more layout flexibility.

First, let’s visualize the default layout of a page here on meyerweb.  It looks something like this:

A page layout diagram showing a header stretching across the top of the page, a footer stretching across the bottom of the page, and three columns of content between them: two sidebars to either side, and a main content column in the middle.

So simple, even flexbox could do it!  But that’s only if things always stay this simple.  I knew they probably wouldn’t, because the contents in those two sidebars were likely to vary from one part of the site to another—and I would want, in some cases, for the sidebar pieces to line up vertically.  Here’s an example:

A page layout diagram showing a header stretching across the top of the page, a footer stretching across the bottom of the page, and three columns of content between them. There is a main content column in the middle which stretches full-height between the header and footer. In the right sidebar, there are three boxes, labeled 'navigation', 'feeds', and 'categories', arranged in that order, top to bottom. In the left sidebar, there is a single box labeled 'archives' that isn’t as tall as the main content column. Its top edge is vertically aligned with the top edge of 'feeds', the second box in the right-hand sidebar.

That’s the basic layout of archive pages.  See how the left sidebar’s Archives lines up with the top of the Feeds box in the right sidebar?  That’s Grid for you.  I thought about lumping the Feeds and Categories into a the same grid cell (thus making them part of the same grid row), which would have meant wrapping them in a <div>, but decided keeping them separate allows more flexibility in terms of responsive rearrangement of content.  I can, for example, assign the Feeds to be followed by Archives and then Categories at mobile sizes.  Or to reverse that order.

More to the point, I also wanted the ability to place things along the bottoms of the sidebars, down near the footer but still next to the main content column, like so:

A page layout diagram similar to the previous diagram, with header and footer, main content column, and the 'archives' box in the left sidebar; and 'navigation, 'feeds', and 'categories' in the right sidebar. This figure adds 'box1' and 'box2' to the bottom of the left sidebar, and 'box3' to the bottom of the right sidebar. The bottom edges of 'box2' and 'box3' are vertically aligned with the bottom of the main column.

An early design prototype for the blog archives put the “Next post” and “Previous post” links in some of those spots, before I moved the links into the bottom of the main content column.  So at the moment, I don’t have anything making use of those spots, although the capability is there.  I could cluster content along the tops and the bottoms of the sidebars, as needed.

But here’s the important thing, and really the point of this article: I’m not rewriting the row structure and grid cell assignments for each page type.  There’s a unified row template applied to the body on every page that uses the Hamonshū design.  It is:

grid-template-rows: repeat(7,min-content) 1fr repeat(3,min-content);

The general idea here is, the first seven rows are sized to be the minimum necessary to contain content inside those rows.  This is also true of the last three rows.  And in between those sets, a 1fr row that takes up the rest of the grid container’s height, pushing the two sets apart.

In the simplest case, where there’s just a header, main content column, and a footer, with nothing in the sidebars (the layout has three columns, remember), the content will fill the rows like so:

A page layout diagram showing a header stretching across the top of the page, a footer stretching across the bottom of the page, and a main content column. There is open space to the sides of the main content column.

Here’s the Grid CSS to make that happen:

header {grid-row: 1; grid-column: 1 / -1;}
footer {grid-row: -2; grid-column: 1 / -1;}
main {grid-row: 2; grid-column: 2;}

Thus: The header fills all of row one.  The content expands row two from its placement in the center column.  The footer fills all of the last row, which is specified via grid-row: -2 (because grid-row: -1 would align its top with the bottom edge of the grid container).  There’s no more content, so all the other min-content rows have no content, so their height is zero.  And there’s no leftover height to soak up, so the 1fr row also has a height of zero.  Seems like a lot of rows specified to no real purpose, doesn’t it?

But now, let’s add some sidebar content to columns one and three; that is, the sidebars.  For example, you might remember this layout from before:

The same as figure 2. To recap: A page layout diagram showing a header stretching across the top of the page, a footer stretching across the bottom of the page, and three columns of content between them. There is a main content column in the middle which stretches full-height between the header and footer. In the right sidebar, there are

Given this setup, we can’t just assign the main content column to grid-row: 2 and leave it at that—it’s going to have to span rows.  Really, it needs to span all but the last, thus ensuring it reaches down to the footer.  So the CSS ends up like this:

header, footer {grid-row: 1; grid-column: 1/-1;}
footer {grid-row: -2;}
main {grid-column: 2; grid-row: 2/-2;}
nav {grid-row: 2; grid-column: 3;}
.archives {grid-row: 3 / span 3;}
.feeds {grid-row: 3; grid-column: 3;}
.categories {grid-row: 4; grid-column: 3;}

And as a result, the rows end up like this:

The same as the previous diagram, but in this case the main content column is taller. Purple dashed lines show where the grid lines are placed in this layout; in particular, they make it clear that the 'navigation', 'feeds', 'categories' boxes in the right-hand sidebar are placed in separate grid rows, and the 'archives' box in the left-hand sidebar spans three grid rows.
Grid-line visualization courtesy the Firefox Web Inspector.

The first set of min-content rows are all gathered up against the bottom of the top part of the layout, and the second set are all pushed down at the bottom.  Between them, the 1fr row eats up all the leftover space, which is what pushes the two sets of min-content rows apart.

I like this pattern.  It feels good to me, having two sets of rows where the individual rows accordion open to accept content when needed, and collapse to zero height when not, with a “blank” row in between the sets that pushes them apart.  It’s flexible, and even allows me to add more rows to the sets without having to rewrite all my layout styles.

As an example, suppose I decided I needed to add a few more rows to the bottom set, for use in a few specialty templates.  Because of the way things are set up, all I have to do is change the row template like this:

grid-template-rows: repeat(7,min-content) 1fr repeat(5,min-content);

That’s everything. I just changed the number of repeats in the second set of rows.  All the existing pages will continue on just fine, no layout changes, no CSS changes.  In the few (currently hypothetical) pages where I need to put a bunch of stuff along the bottom of the main content column, I just plug them in using grid-row values, whether positive or negative.  It all just works.

The same is true if more rows are added to the first set, for whatever reason.  Everything gets managed in a single CSS rule, where you can add rows for the whole site instead of having to write, track, and maintain a bunch of variants for various page types.  (Subtracting rows is harder without causing layout upset, but could still be done in some scenarios.)

As a final note, you’re probably wondering: Is that one 1fr row actually necessary to get a layout like this one?  Not really, no.  Let’s take it out, like this:

grid-template-rows: repeat(11,min-content);

What happens as a result is the rows that aren’t directly occupied by content (the ones that previously collapsed to zero height), but are still spanned by content (the center column), divvy up the leftover space the 1fr row used to consume.  This leads to a situation like so:

The same layout diagram as the previous figure, but with some of the grid rows placed differently.

To the user, there’s no practical difference.  Things go to the same places either way.  You just get the “extra” rows stretching out, instead of being pushed apart by the 1fr row.

I certainly could have left it at that, and it arguably would have been cleaner to do so.  But something about this approach doesn’t sit quite right with me; there’s a tickly feeling in the back of my instinct that tells me there’s a downside to this.  Admittedly, it could be a vestigial instinct from the Age of Floats; I doubtless have many things I still have not unlearned.  On the other hand, it could be something about Grid I’ve picked up on subconsciously but haven’t yet brought into full realization.

If I ever pin the tickle down enough to articulate it, I’ll update the post to include it.

Thanks to Kitt Hodsden and Laura Kalbag for their assistance with this article.


Pseudo-Randomly Adding Illustrations with CSS

Published 6 months, 1 week past

I’ve been incredibly gratified and a bit humbled by the responses to the new design.  So first of all, thank you to everyone who shared their reactions!  I truly appreciate your kindness, and I’d like to repay that kindness a bit by sharing some of the techniques I used to create this design.  Today, let’s talk about the ink-study illustrations placed between entries on the site, as well as one other place I’ll get to later.

Very early in the process, I knew I wanted to separate entries with decorations of some sort, as a way of breaking up the stream of text.  Fortunately, Hamonshū provided ample material.  A little work in Acorn and I had five candidate illustrations ready to go.

The five illustrations.

The thing was, I wanted to use all five of them, and I wanted them to be picked on a random-ish basis.  I could have written PHP or JS or some such to inject a random pick, but that felt a little too fiddly.  Fortunately, I found a way to use plain old CSS to get the result I wanted, even if it isn’t truly random.  In fact, its predictability became an asset to me as a designer, while still imparting the effect I wanted for readers.

(Please note that in this article, I’ve simplified some aspects of my actual CSS for clarity’s sake; e.g., removing the directory path from url() values and just showing the filenames, or removing declarations not directly relevant to the discussion here.  I mention this so that you’re prepared for the differences in the CSS shown in this piece versus in your web inspector and/or the raw stylesheet.)

Here’s how it starts out:

#thoughts .entry + .entry::before {
   content: "";
   display: block;
   height: 10em;
   background:
      url(separator-big-05.png) 50% 100% / contain no-repeat;
}

That means, for every blog entry except the first, a block-level bit of generated content is inserted at the beginning of the entry, given a height, and the image separator-big-05.png is dropped into the generated box and sized to be contained within it, which means no part of the image will spill outside the background area and thus be clipped off.  (The file has the number 05 because it was the fifth I produced.  It ended up being my favorite, so I made it the default.)

With that in place, all that remains is to switch up the background image that’s used for various entries.  I do it like this:

#thoughts .entry:nth-of-type(2n+1)::before {
   background-image: url(separator-big-02.png);
}
#thoughts .entry:nth-of-type(3n+1)::before {
   background-image: url(separator-big-03.png);
}
#thoughts .entry:nth-of-type(4n+1)::before {
   background-image: url(separator-big-04.png);
}
#thoughts .entry:nth-of-type(5n+1)::before {
   background-image: url(separator-big-01.png);
}

So every second-plus-one entry (the third, fifth, seventh, etc.) that isn’t the first entry will use separator-big-02.png instead of -05.png.  Unless the entry is an every-third-plus-one (fourth, seventh, tenth, etc.), in which case separator-big-03.png is used instead.  And so on, up through every-fifth-plus-one.  And as you can see, the first image I produced (separator-big-01.png) is used the least often, so you can probably guess where it stands in my regard.

This technique does produce a predictable pattern, but one that’s unlikely to seem too repetitious, because it’s used to add decoration separated by a fair amount of text content, plus there are enough alternatives to keep the mix feeling fresh.  It also means, given how the technique works, that the first separator image on the home page (and on archive pages) is always my favorite.  That’s where the predictability of the approach helped me as a designer.

I use a similar approach for the separator between posts’ text and their comments, except in that case, I add a generated box to the end of the last child element in a given entry:

.single #thoughts article .text > *:last-child:after {
   content: "";
   display: block;
   height: 10em;
   background:
      url(separator-big-05.png) 50% 100% / contain no-repeat;
}

That is, on any page classed single (which is all individual post pages) after the last child element of a .text element (which holds the text of a post), the decoration box is generated.  The default, again, is separator-big-05.png—but here, I vary the image based on the number of elements in the post’s body:

.single #thoughts article .text > *:nth-child(2n+1)::after {
   background-image: url(separator-big-02.png);
}
.single #thoughts article .text > *:nth-child(3n+1)::after {
   background-image: url(separator-big-03.png);
}
.single #thoughts article .text > *:nth-child(4n+1)::after {
   background-image: url(separator-big-04.png);
}
.single #thoughts article .text > *:nth-child(5n+1)::after {
   background-image: url(separator-big-01.png);
}

In other words: if the last child element of the post text is a second-plus-one, separator-big-02.png is used.  If there are 3n+1 (one, four, seven, ten, thirteen, …) HTML elements in the post, separator-big-03.png is used.  And so on.  This is an effectively random choice from among the five images, since I don’t count the elements in my posts as I write them.  And it also means that if I edit a piece enough to change the number of elements, the illustration will change!  (To be clear, I regard this as a feature.  It lends a slight patina of impermanence that fits well with the overall theme.)

I should note that in the actual CSS, the two sets of rules above are merged into one, so the selectors are actually like so:

#thoughts .entry + .entry::before,
   .single #thoughts article .text > *:last-child:after {…}

#thoughts .entry:nth-of-type(2n+1)::before,
   .single #thoughts article .text > *:nth-child(2n+1)::after {…}

#thoughts .entry:nth-of-type(3n+1)::before,
   .single #thoughts article .text > *:nth-child(3n+1)::after {…}

In all honesty, this technique really satisfies me.  It makes use of document structure while having a random feel, and is easily updated by simply replacing files or changing URLs.  It’s also simple to add more rules to bring even more images to the mix, if I want.

And since we’re talking about using structure to vary layout, I also have this @media block, quoted here verbatim and in full:

@media (min-width: 50em) {
   #thoughts .entry:nth-of-type(2n) {
      transform: translate(-1vw,0);
   }
   #thoughts .entry:nth-of-type(3n) {
      transform: translate(3vw,0);
   }
}

This means on the home page and blog archive pages, but only at desktop-browser widths, some entries are shifted a bit to the left or right by fractions of the viewport width, which subtly breaks up the strict linearity of the content column on long pages, keeping it from feeling too grid-like.

To be honest, I have no idea if that side-shifting effect actually affects visitors’ experience of using meyerweb, but I like it.  Sometimes the inter-entry wave art fits together with the side-shift so that it looks like the art flows into the content.  That kind of serendipity always delights me, whether it comes by my hand or someone else’s.  With luck, it will have delighted one or two of you as well.


CSS Naked Day 2020

Published 6 months, 2 weeks past

If you’re here on meyerweb on April 9th, 2020, then you’re seeing the site without the CSS I wrote for its design and layout.  Why?  It’s CSS Naked Day!  To quote that site:

The idea behind this event is to promote Web Standards. Plain and simple. This includes proper use of HTML, semantic markup, a good hierarchy structure, and of course, a good old play on words. It’s time to show off your <body> for what it really is.

So last night, I removed the links to the main stylesheets for the site.  There are, I should note, scattered pages where local CSS is still in play. I could have tracked them all down and removed their CSS as well, and I considered doing so, but in the end I decided against it.

There’s a history to this day.  In the late Aughts, it was an annual thing, not unlike Blue Beanie Day, to draw attention to web standards and reinforce among the community that good, solid, robust development practices are a good thing.  Because after all, if your site isn’t usable without the CSS, then it almost certainly has structure and accessibility problems you probably haven’t been thinking about.

In all honesty, I had forgotten about it until just a couple of days prior, I suddenly thought, “Wait, early April, isn’t that when CSS Naked Day was observed?”  I went looking, and discovered that yes, it was.  I had remembered April 7th, but apparently April 9th was the actual date.  Or became it over time.  Either way, here we are, feeling fancy-free!

What’s been interesting has been what CSS Naked Day has revealed about browsers as well as about our HTML.  To pick one example, suppose you have a very large SVG logo, which you size to where you want it with CSS.  This is ordinarily a best practice: the SVG is the same file size whether it renders huge or tiny, so there’s no downside to having an SVG that renders 1200 x 1000 when you view it directly—thus allowing you to see all the little details—but is sized to 120 x 100 via CSS for layout purposes.

But take away the CSS, and the SVG will become 1200 x 1000 again.  That might tell you to resize it for production, sure, and you probably should.  But it also points out that browsers will not constrain that image, not even to the viewport.  If your window is only 900 pixels wide, the SVG could well spill outside, forcing a horizontal scrollbar.  Is that good?  Maybe!  Maybe not!  We might wish browsers would bake something like img {max-width: 100%; height: auto;} into their user-agent stylesheet(s), but maybe that would have unforeseen downsides.  The point is, this is a thing about browsers that CSS Naked Day reveals, and it’s worth knowing.

Similarly, this reveals that browsers don’t have a way to restrict the width of lines of text.  Thus, if the browser window is wide, the lines get very long—long enough to make reading more difficult.  This isn’t a problem on handheld devices like smartphones, but on desktop (use of which has risen significantly in areas locked down to limit the spread of SARS-CoV-2) it can be a problem.  Again, if browsers had something like body {max-width: 70em;} or max-width: 100ch or suchlike, this wouldn’t be a problem.  Should they?  Maybe!  It’s worth thinking about for your own work, if nothing else.

(For much more thinking about these kinds of browser behaviors and how to address them, you should absolutely check out the CSS Remedy project.  “CSS Remedy sets CSS properties or values to what they would be if the CSSWG were creating the CSS today, from scratch, and didn’t have to worry about backwards compatibility.”)

If I’d remembered sooner, I might have contacted the maintainers of the CSS Naked Day site and posted about it ahead of time and thought about stuff like a hashtag to spread the word.  Maybe that will happen next year.  Until then, enjoy all the nudity!


CSS Specification Timelines, Updated and Modernized

Published 7 months, 3 weeks past

Back in 2011, I decided to make a timeline out of CSS modules’ version histories, where “version history” means “a list of all the various drafts that were published”.  I updated the data every now and again, and then kind of let it go dormant for a few years.

Until this past weekend, when for no clear reason I decided what the hell, it’s time for a refresh.  So I trawled through all the specs’ version histories to get the stuff I didn’t have, and gave the presentation a bit of an upgrade.  The overall look and feel is pretty consistent, except now, thanks to repeating linear gradients, I have vertical stripes to show each year in the now 21-year-long timeline.  I put labels up at the top of the stripes, and figured they should remain visible no matter where you scroll, so I set them to position: sticky.  Then I realized most people would have to scroll horizontally, so I made the specification names sticky as well.

So now, no matter where you scroll on the page, you’ll see the specifications along the left and the years along the top.  The layout isn’t mobile-hostile, exactly, but it isn’t RWD-ized either.  I’m not really sure how I could make this fully responsive, except maybe to just drop the timeline layout altogether and revert to the lists that underlie the layout.

While I was at it, I converted a fair bit of the CSS to use var() and calc() so that I could set a column width in one place, and sprinkled in just a tiny bit more PHP to output offset values in a couple of places.  Nothing major, just quality-of-life upgrades for the maintainer, which is to say, me.

I bring all this up for two reasons.  One, I like the presentation upgrades, and wanted to share.  Two, by sheer coincidence, today the CSS Working Group published first versions of four CSS modules:

So I’ve added them to the timeline, along with CSS Color Module Level 4, which I’d overlooked in my weekend update.  These are the first module versions of 2020, so enjoy!

I do find it a little weird that Color Level 5 is out when Color Level 4 has never left Working Draft status, but maybe Level 4 is about to graduate, and this just happened to come out first.  We’ll see!


Woodshop SVG

Published 9 months, 1 week past

For the holiday break this year, I decided to finally tackle creating an indoor work space.  I’d had my eye on a corner of our basement storage room for a while, and sketched out various rough plans on graph paper over the past couple of years.  But this time?  This time, I was doing it.

The core goal is to have a workbench where I can do small toy and appliance repair when needed, as well as things like wood assembly after using the garage power tools to produce the parts—somewhere warm in the depths of winter and cool at the height of summer, where glue and finish will always be in its supported temperature range.  But that spawns a whole lot of other things in support of that goal: places to store components like screws, clamps, drills, bits, hammers, saws, wires, and on and on.

Not to mention, many tools are powered, and the corner in question didn’t come with any outlets.  Not even vaguely nearby, unless you count the other side of the room behind a standing freezer.  Which, for the record, I don’t count.  I had to do something about that.

So anyway, a lot of stuff got cleared out of the corner and stored elsewhere, if it wasn’t just tossed outright.  Then I took a couple of cabinets off the wall and remounted one of them elsewhere in the room, which was quite the experience, let me tell you.  When I discovered I’d mis-measured the available space and the cabinet ever so slightly, I had the following conversation with myself:

“This cabinet is an eighth-inch too tall to fit. You’ll never get it in there!”

“Yeah?  Well, me and Mister Block Plane here say different.”

Reader, I got it in there.

Moving the cabinets exposed a short wall of framing studs mounted atop a cinderblock foundation wall.  I’ll get to how I used those in a future piece, but here I want to talk about something I’ve been using to help me visualize parts of this project and get cut lists out of it at the end: hand-written SVG.

You heard me.  I’ve been hand-coding SVG schematics to figure out how thing should go together, and as a by-product, guide me in both material buying and wood cutting.

This might sound hugely bespoke and artisanally overdone, but they’re not that complicated, and as a major benefit, the process has helped me understand SVG a little bit better.  Here’s one example, a top-down diagram of the (supposedly) temporary workbench I recently built out of plywood and kiln-dried framing studs.

That shows a 2’×4′ benchtop with a supporting frame (the overlapping grayish boxes) and the placement of the four legs (the brown rectangles).  Here’s how I wrote the elements to represent the supporting frame.

<g class="structure">
    <path d="M 3.75 3.75  l 40.5 0" /> <!-- back -->
    <path d="M 3.75 12.00 l 40.5 0" class="optional" />
    <path d="M 3.75 20.25 l 40.5 0" /> <!-- front -->

    <path d="M 3.75 3  l 0 18" /> <!-- left -->
    <path d="M 24.00 3.75 l 0 16.5" class="optional" />
    <path d="M 44.25 3 l 0 18" /> <!-- right -->
</g>

And here’s how I styled them.

.structure {
    stroke: #000;
    stroke-width: 0;
    fill: #000;
}
.structure path {
    opacity: 0.1;
    stroke-width: 1.5;
}
.structure .optional {
    opacity: 0.05;
}

I like using paths in this situation because they let me pick a starting coordinate, then draw a line with relative X-Y values.  So that first path starts at X=3.75 and Y=3.75, and then draws a line whose endpoint is 40.5 X-units and 0 Y-units from the starting point.  In other words, it’s 40.5 units long and purely horizontal.  Compare that to the path marked left, which starts nearby (X=3.75, Y=3) and runs 18 units straight down.

This helps with cut planning because I set things up such that each unit equals an inch.  Just by looking at the values in the SVG, I know I need two pieces that are 40.5 inches long, and two that are 18 inches long.  (Three pieces of each length, if I’d decided to use the pieces classed as optional, but I didn’t.)

And how did I get that to work?  I set the viewbox to be only a few coordinate units larger than the overall piece, which I knew would be 24 by 48 units (inches), and then made the image itself large.

<svg xmlns:svg="http://www.w3.org/2000/svg"
    xmlns="http://www.w3.org/2000/svg"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    width="1000"
    height="500"
    viewBox="0 0 54 30"
    >

Basically, I added 6 to each of 24 and 48 to get my viewBox values, allowing me three units of “padding” (not CSS padding) on each side.  I filled the whole thing with a rectangle with a soft gray fill, like so.

<rect height="100%" width="100%" fill="#EEE" />

Which was great, but now I had to figure out how to get the 24×48 workplan into the center of the viewbox without having to add three to every coordinate.  I managed that with a simple translation.

<g transform="translate(3,3)">
    <rect width="48" height="24" fill="hsla(42deg,50%,50%,0.5)" />
    …
</g>

And with that, everything inside that g (which is basically the entire diagram) can use coordinates relative to 0,0 without ending up jammed into the top left corner of the image.  For example, that rect, which has no x or y attributes and so defaults both to 0.  It thus runs from 0,0 to 48,24 (as is proper, X comes before Y), but is actually drawn from 3,3 to 51,27 thanks to the transform of the g container.

The drawback to this approach, in my eyes, is that if text is added, it needs a really small font size.  In this particular case, I decided to add a measurement grid to the diagram which is revealed when the SVG is printed.  You can also see it on a mouse-and-keyboard computer if you click through to the SVG and then hover the tabletop.  To all the paths I used to make the grid (and yes, there’s a better way), I added a set of labels like these:

<text x="12" y="0" dx="0.5" dy="-0.5">12</text>
<text x="24" y="0" dx="0.5" dy="-0.5">24</text>
<text x="36" y="0" dx="0.5" dy="-0.5">36</text>
<text x="48" y="0" dx="0.5" dy="-0.5">48</text>

<text x="0" y="0" dx="-0.33" dy="-0.33">0</text>
<text x="0" y="12" dx="-0.5" dy="0.5">12</text>
<text x="0" y="24" dx="-0.5" dy="0.5">24</text>

At my browser’s default of 16px, the text is HUGE, because it gets made 16 units tall.  That’s almost three-quarters the height of the viewbox!  So I ended up styling it to be teensy by any normal measure, just so it would come out contextually appropriate.

.lines text {
    font-size: 1px;
    font-family: Arvo, sans-serif;
    text-anchor: end;
}

Yes.  1px.  I know.  And yet, they’re the right size for their context.  It still grates on me, but it was the answer that worked for this particular context.  You can see the result if you load up the SVG on its own and mouse-hover the benchtop.

The legs I decided to do as rect elements, for no reason I can adequately explain other than I’d started to get a little sick of the way path forced me to figure out where the center of each line had to be in order to make the edges land where I wanted.  path is great if you want a line exactly centered on a unit, like 12.00, but if you want the edge of a board to be three inches from the left edge of the tabletop, it has to start at x="3.75" if the board is 1.5 inches wide.  If the width ever changes, you have to change the x value as well.

For the support frame, which is going to be made entirely out of boards an inch and a half wide, this wasn’t a super big deal, but the math had started to grate a bit.  So, the legs are rects, because I could use the grid I’d drawn to figure out their top left corners, and the height and width were constants.  (I probably could have set those via the CSS, but eh, sometimes it’s better to have your code self-document.)

<g class="legs">
    <rect x="4.5" y="4.5" height="1.5" width="3.5" />
    <rect x="4.5" y="18" height="1.5" width="3.5" />
    <rect x="40" y="4.5" height="1.5" width="3.5" />
    <rect x="40" y="18" height="1.5" width="3.5" />
</g>

Honestly, I probably didn’t even need to include these, but they served as a useful reminder not to forget them when I went to buy the wood.

As I said, simply by glancing at the SVG source, I can see how long the support frame’s pieces need to be—but more to the point, as I adjusted numbers to move them around, I worked their sizes into my head.  What I mean is, I had to visualize them to draw the right lines, and that means I’ve already done some visualization of the assembly.  I just need to remember that each of the four legs will be 34″ long at the most.  Taken all together, I’ll need three 8-foot 2×4 boards (which actually have a cross-section of 1.5″×3.5″—don’t ask), chopped up and joined appropriately, to go under my 2’×4′ benchtop.

So that’s how I utterly geeked up my workbench project—and if that seems like a bit much, just wait until you see the next thing I did, and what I learned along the way.


“Flexible Captioned Slanted Images” at 24 ways

Published 10 months, 2 days past

We have a lot of new layout tools at our disposal these days—flexbox is finally stable and interoperable, and Grid very much the same, with both technologies having well over 90% support coverage. In that light, we might think there’s no place for old tricks like negative margins, but I recently discovered otherwise.

That’s the opening paragraph to my 24ways piece “Flexible Captioned Slanted Images”, which I now realize I should have called “Accessible Flexible Captioned Slanted Images”.  Curse my insufficient title writing!  In just about 2,000 words, I explore a blend of new CSS and old layout tricks to take an accessible markup structure and turn it into the titular slanted images, which are fully flexible across all screen sizes while being non-rectangular.

It’s just my second piece for 24ways, coming a dozen years and a day after the first—and is very possibly my last, as Drew closed out this year by putting 24ways on hiatus.  Fifteen years is a heck of a run for any project, let alone an annual side project, and I salute everyone involved along the way.  Content is hard.  Managing content is harder.  Here’s to everyone who put in the time and energy to make such a valuable resource.  If you’ve never been through the 24 ways archives, now’s your chance.  I promise it will be very much worth your time.


Color Easing Isn’t Always Easy

Published 1 year, 6 months past

A fairly new addition to CSS is the ability to define midpoints between two color stops in a gradient.  You can do this for both linear and radial gradients, but I’m going to stick with linear gradients in this piece, since they’re easier to show and visualize, at least for me.

The way they work is that you can define a spot on the gradient where the color that’s a halfway blend between the two color stops is located.  Take the mix of #00F (blue) with #FFF (white), for example.  The color midway through that blend is #8080FF, a pale-ish blue.  By default, that will land halfway between the two color stops.  So given linear-gradient(90deg, blue 0px, white 200px), you get #8080FF at 100 pixels.  If you use a more generic 90deg, blue, white 100%, then you get #8080FF at the 50% mark.

linear-gradient(90deg, blue, white 100%)

If you set a midpoint, though, the placement of #8080FF is set, and the rest of the gradient is altered to create a smooth progression.  linear-gradient(blue 0px, 150px, white 200px) places the midway color #8080FF at 150 pixels.  From 0 to 150 pixels is a gradient from #F00 to #8080FF, and from 150 pixels to 200 pixels is a gradient from #8080FF to #FFF.  In the following case, #8080FF is placed at the 80% mark; if the gradient is 200 pixels wide, that’s at 160 pixels.  For a 40-em gradient, that midpoint color is placed at 32em.

linear-gradient(90deg, blue, 80%, white 100%)

You might think that’s essentially two linear gradients next to each other, and that’s an understandable assumption.  For one, that’s what used to be the case.  For another, without setting midpoints, you do get linear transitions.  Take a look at the following example.  If you hover over the second gradient, it’ll switch direction from 270deg to 90deg.  Visually, there’s no difference, other than the label change.

linear-gradient(<angle>, blue, white, blue)

That works out because the easing from color stop to color stop is, in this case, linear.  That’s the case here because the easing midpoints are halfway between the color stops—if you leave them out, then they default to 50%.  In other words, linear-gradient(0deg, blue, white, blue) and linear-gradient(0deg, blue, 50%, white, 50%, blue) have the same effect.  This is because the midpoint easing algorithm is based on logarithms, and is designed to yield linear easing for a 50% midpoint.

Still, in the general case, it’s a logarithm algorithm (which I love to say out loud).  If the midpoint is anywhere other than exactly halfway between color stops, there will be non-linear easing.  More to the point, there will be non-linear, asymmetrical easing.  Hover over the second gradient in the following example, where there are midpoints set at 10% and 90%, to switch it from  270deg to 90deg, and you’ll see that it’s only a match when the direction is the same.

linear-gradient(<angle>, blue, 10%, white, 90%, blue)

This logarithmic easing is used because that’s what Photoshop does.  (Not Mosaic, for once!)  Adobe proposed adding non-linear midpoint easing to gradients, and they had an equation on hand that gave linear results in the default case.  It was also what developers would likely need to match if they got handed a Photoshop file with eased gradients in it.  So the Working Group, rather sensibly, went with it.

The downside is that under this easing regime, it’s really hard to create symmetric non-linear line gradients.  It might even be mathematically impossible, though I’m no mathematician.  Regardless, its very nature means you can’t get perfect symmetry.  This stands in contrast to cubic Bézier easing, where it’s easy to make symmetric easings as long as you know which values to swap.  And there are already defined keywords that are symmetric to each other, like ease-in and ease-out.

If you’re up for the work it takes, it’s possible to get some close visual matches to cubic Bézier easing using the logarithmic easing we have now.  With a massive assist from Tab Atkins, who wrote the JavaScript I put to use, I created a couple of CodePens to demonstrate this.  In the first, you can see that linear-gradient(90deg, blue, 66.6%, white) is pretty close to linear-gradient(90deg, blue, ease-in, white).  There’s a divergence around the 20-30% area, but it’s fairly minor.  Setting an interim color stop would probably bring it more in line.  That’s partly how I got a close match to linear-gradient(90deg, blue, ease-out, white), which came out to be linear-gradient(90deg, blue, 23%, #AFAFFF 50%, 68%, white 93%).

Those examples are all one-way, however—not symmetrical.  So I set up a second CodePen where I explored recreations of a few symmetrical non-linear gradients.  The simplest example matches linear-gradient(90deg, blue, ease-in, white, ease-out, blue) with linear-gradient(90deg, blue, 33.3%, white 50%, 61.5%, #5050FF 75%, 84%, blue 93%), and they only get more complex from there.

I should note that I make no claim I’ve found the best possible matches in my experiments.  There are probably more accurate reproductions possible, and there are probably algorithms to work out what they would be.  Instead,  I did what most authors would do, were they motivated to do this at all: I set some stops and manually tweaked midpoints until I got a close match.  My basic goal was to minimize the number of stops and midpoints, because doing so meant less work for me.

So, okay, we can recreate cubic Bézier easing with logarithmic midpoints.  Still, wouldn’t it be cool to just allow color easing using cubic Béziers?  That’s what Issue #1332 in the CSS Working Group’s Editor Drafts repository requests.  From the initial request, the idea has been debated and refined so that most of the participants seem happy with a syntax like linear-gradient(red, ease-in-out, blue).

The thing is, it’s generally not enough to have an accepted syntax—the Working Group, and more specifically browser implementors, want to see use cases.  When resources are finite, requests get prioritized.  Solving actual problems that authors face always wins over doing an arguably cool thing nobody really needs.  Which is this?  I don’t know, and neither does the Working Group.

So: if you have use cases where cubic Bézier easing for gradient color stops would make your life easier, whether it’s for drop shadows or image overlays or something I could never think of because I haven’t faced it, please add them to the GitHub issue!


Color Me FACE1E55

Published 1 year, 6 months past

There’s a long history in computer programming of using hexadecimal strings that look like English words to flag errors.  These are referred to, amusingly, as “magic debug values”, and yes, Wikipedia has the lowdown.  One of the most (in)famous is DEADBEEF, which was used “on IBM systems such as the RS/6000, also used in the classic Mac OS operating systems, OPENSTEP Enterprise, and the Commodore Amiga”, among others.  It’s also become the name of a Gnu/Linux music player, and apparently does not have anything to do with Cult of the Dead Cow, at least not so far as I could determine.  Maybe someone with more knowledge can drop a comment.

Anyway, one of the things about these magic debug values is they’re usually eight characters long.  Not always, as in the case of BADC0FFEE0DDF00D (from RS/6000, again), but usually.  Nintendo used 0D15EA5E in the GameCube and Wii to indicate a normal boot (!), iOS logs DEAD10CC when an application terminates in a specific yet incorrect manner, and FEEDFACE shows up in PowerPC Mach-O binaries , as well as the VLC Player application.  Just to pick a few examples.

The eight-character nature of these magic codes has meant that, for a long time, you couldn’t also use them on the sly to define colors in CSS, because it was limited to the #RRGGBB format.  Well, those days are over.  Long over.  Eight-digit hex color values are here, have been here a while, and are widely supported.  Here are a few swatches laid over a (fully opaque) white-to-black gradient.

#abadcafe
#baaaaaaa
#deadbeef
#deadfeed
#defec8ed
#feedbacc

If you’re using Internet Explorer or Edge, those aren’t going to work for you.  At least, not until Edge switches over to Blink; then, they should work just fine.

Thanks to the way they were constructed, by only using the letters A-F, most of the colors above are mostly opaque.  The last two digits in #RRGGBBAA set the alpha channel level of the color, just like the last part of the rgba() syntax.  Thus, the EF at the end of DEADBEEF sets the alpha value to 0.937; EF is equivalent to decimal 239, and 239 ÷ 255 = 0.937 (approximately).  In other words, #DEADBEEF is essentially equivalent to rgba(222,173,190,0.937).

That’s why, of the six swatches, only the sheepish #baaaaaaa and the homophonic #feedbacc let the background gradient show through more than very slightly; their alpha channels are 0.666 and 0.8, respectively.  The rest are 0.929 and up.

Being stuck in the A-F range is fairly constraining, but that’s where hexadecimal and English overlap, so that’s how it goes.  However, if you’re willing to turn to leetspeak syntax—that is, allowing yourself to use 0 as a substitute for O, 1 for L and occasionally I, 5 for S, 7 for T, and so on—then a lot more possibilities open up.  In addition to some of the classic error codes like fee1dead (Linux), I had fun devising other eight-character color words like acc0lade and face1e55, not to mention the very nautical ccccccc5.  (Think about it.)  Behold!

#0ff1c1a1
#1337c0de
#5e1f1e55
#a114c0de
#acc01ade
#ba5e1e55
#bada55e5
#bebada55
#beefc0de
#b0bafe77
#b0a710ad
#c010ca7e
#c0de1e55
#ccccccc5
#d0d0c0de
#dabbad00
#dead10ad
#deadd0d0
#decea5ed
#face1e55
#fee1dead

There are still more l33t-compliant number substitutions available, like 6 for G, but I felt like I was already pushing it with the examples I have.  One could also use calculator spelling, where 9 is a stand-in for g, and even mix together l33t and calculator syntaxes in the same value.  So many possibilities!

You may have noticed one value which creates no color: #DABBAD00, which has 00 for its alpha, so it’s fully, completely transparent.  It’s fully transparent #DABBAD, I suppose, but there’s really no difference between one transparent color and another, as far as I’m concerned.  I mean, if a color falls transparent, then there’s nobody to see it, so is it really a color at all?  I say thee nay.

If you’re familiar with the way #RRGGBB hex values can be represented with the shortened #RGB syntax, then it will probably come as little surprise that #RRGGBBAA has a shortened #RGBA syntax, where each digit is duplicated.  This opens the world of four-letter words to us!  Here are a few:

#10ad
#1337
#b007
#ba5e
#bead
#beef
#c0de
#cafe
#cede
#dada
#dead
#deed
#f00d
#fade
#f8ed
#feed
#0b0e

Here, we finally have a fully opaque word-color: #BEEF expands out to #BBEEEEFF, making the alpha value FF, which decimal-translates to 255, which is fully opaque.  So we get a nice opaque powdery blue out of BEEF, which is counterintuitive in the best possible way.  Also, every time I see BBEEEEFF, either in print or in my head, I hear Mrs. Which ordering dinner.

And okay, yes, #F8ED isn’t a four-letter word, it’s a four-symbol license-plate word.  So it’s even cooler.

If you’re thinking about using these in your CSS, you might be concerned about backwards compatibility, since any browser that doesn’t understand four- or eight-digit hexadecimal color values will just drop them on the floor.  That might be okay for text coloring, since the text will likely have some color, even if it’s browser-default, which is usually black.  For backgrounds, having colors ignored probably less okay, particularly if you set foreground colors that depend on the background colors.

There are a couple of possibilities here.  One is to use the cascade and CSS error handling to your advantage, in the time-honored pattern of doing the simpler version first and the more sophisticated version second.

#example {
   color: #DEA;
   color: #DEAD;
}

That works in simple scenarios, but for more complicated situations—say, ones where you have foreground and background depending on each other—feature queries are an option to consider, if for no other reason than cleaner organization and legibility.

#example {
   color: red;
   background: #EEE;
}

@supports (color: #ABCD) {
   #example {
      color: #f00d;
      background: #feed;
   }
}

Naturally and as usual, you’ll have to figure out what makes the most sense for your situation.  Maybe the right answer will be to avoid using these sorts of values at all, although I don’t know where the fun is in that.

At any rate, I hope you’ve enjoyed this little tour of magic debug values, l33tspeak, and color words.  As always, #feedbacc is more than welcome in the comments!


Browse the Archive

Earlier Entries