Posts in the CSS Category

CSS4 Color Keyword Distribution Visualization

Published 1 year, 5 months past

Long, long ago—not quite seven years ago, in fact—I built a canvas-based visualization of the distribution of CSS3/SVG color keywords and released it.  And there it’s sat, static and inert (despite being drawn with a whooooole lotta JS) ever since.

I’ve always meant to get back to it and make it more interactive.  So over the past several evenings, I’ve rebuilt it as an SVG-based visualization.  The main point of doing this was so that when you hover the mouse pointer over one of the little color boxes, it will fill the center of the color wheel with the hovered color and tell you its name and HSL values.  Which it does, now.  It even tries to guess whether the text should be white or black, in order to contrast with the underlying color.  Current success rate on that is about 90%, I think.  Calculating perceived visual brightness turns out to be pretty hard!

Other things I either discovered, or want to do better in the future:

  • Very nearly half the CSS4 (and also CSS3/SVG) color keywords are in the first 90 degrees of hue.  More than half are in the first 120 degrees.
  • There are a lot of light/medium/dark variant names in the green and blue areas of the color space.
  • I wish I could make the color swatches bigger, but when I do that the adjacent swatches overlap each other and one of them gets obscured.
  • Therefore, being able to zoom in on parts of the visualization is high on my priority list.  All I need is a bit of event monitoring and some viewbox manipulation.  Well, that and a bit more time. Done, at least for mouse scroll wheels.
  • I’d like to add a feature at some point where you type text, and a list is dynamically filtered to show keywords containing what you typed.  And each such keyword has a line connecting it to the actual color swatch in the visualization.  I have some ideas for how to make that work.
  • I’d love to create a visualization that placed the color swatches in a 3D cylindrical space summarizing hue, lightness. and saturation.  Not this week, though.
  • I’m almost certain it needs accessibility work, which is also high on my priority list.
  • SVG needs conic gradients.  Or the ability to wrap a linear gradient along/inside/around a shape like a circle, that would work too.  Having to build a conic gradient out of 360 individual <path>s is faintly ridiculous, even if you can automate it with JS.
  • And also z-index awareness.  C’mon, SVG, get it together.

Anyway, here it is: CSS4 Color Keyword Distribution.  I hope you  like it!


“Stacked ‘Borders’” Published at CSS-Tricks

Published 1 year, 6 months past

I toyed with the idea of nesting elements with borders and some negative margins to pull one border on top of another, or nesting a border inside an outline and then using negative margins to keep from throwing off the layout. But none of that felt satisfying.

It turns out there are a number of tricks to create the effect of stacking one border atop another by combining a border with some other CSS effects, or even without actually requiring the use of any borders at all. Let’s explore, shall we?

That’s from the introduction to my article “Stacked ‘Borders’”, which marks the first time I’ve ever been published at the venerable upstart CSS-Tricks.  (I’m old, so I can call things both venerable and an upstart.  You kids today!)  In it, I explore ways to simulate the effect of stacking multiple element borders atop on another, including combining box shadows and outlines, borders and backgrounds, and even using border images, which have a much wider support base than you might have realized.

And yes, as per my usual, the images in the piece are all double-dpi :screenshot captures directly from Firefox.

Many thanks to Chris Coyier for accepting the piece, and Geoff Graham for his editorial assistance.  I hope you’ll find at least some part of it useful, or better still, interesting.  Share and enjoy!


Variable Font Support

Published 2 years, 2 weeks past

Firefox 62 ships today, bringing with it some real CSS goodness.  For one: float shapes!  Which means now, mainline Firefox users will see the text flow past the blender in “Handiwork” the same way Chrome users have for a long time now.

But an even bigger addition is support for variable fonts.  The ability to have one font file that mathematically describes variants on the base face means that all kinds of fine-grained typography is possible with far less bandwidth overhead and a major reduction in page weight.

However: bear in mind that like Safari, but unlike Chrome, Firefox’s variable-font support is dependent on the operating system on which is runs.  If you have Windows 10, or Max OS X 10.13, then you have variable font support in Firefox and Safari.  Earlier versions of those operating systems don’t support variable fonts, and so Safari and Firefox don’t either.  Chrome rolls its own variable-font support, so it can extend support backwards in the OS timeline.

(I don’t know how things stand in the Linux world.  Hopefully someone can clear things up in the comments!)

I say this not to chastise Firefox (nor Safari), because I tend to think leaning on the OS for this sort of thing is reasonable.  I feel the same way about form elements like <select> dropdowns, to be clear, which I know likely places me in the minority.  The point here is to give you a heads-up: if you get reports that a font isn’t doing the variable thing you styled, but it’s working fine for you, keep “check their operating system version” on your list of diagnostic tests.


What is the CSS ‘ch’ Unit?

Published 2 years, 2 months past

I keep seeing authors and speakers refer to the ch unit as meaning “character width”.  This leads to claims that you can “make your content column 60 characters wide for maximum readability” or “size images to be a certain number of characters!”

Well… yes and no.  Specifically, yes if you’re using fixed-width fonts.  Otherwise, mostly no.

This is because, despite what the letters ch might imply, ch units are not “character” units.  They are defined as:

Equal to the used advance measure of the “0” (ZERO, U+0030) glyph found in the font used to render it. (The advance measure of a glyph is its advance width or height, whichever is in the inline axis of the element.)

So however wide the “0” character is in a given typeface, that’s the measure of one ch.  In monospace (fixed-width) fonts, where all characters are the same width, 1ch equals one character.  In proportional (variable-width) fonts, any given character could be wider or narrower than the “0” character.

To illustrate this, here are a few example elements which are set to be exactly 20ch wide, and also contain exactly 20 characters.

Courier

Look, 20 characters. abcdefghijklmnopqrst 12345678901234567890 iiiiiiiiiiiiiiiiiiii mmmmmmmmmmmmmmmmmmmm

Helvetica

Look, 20 characters. abcdefghijklmnopqrst 12345678901234567890 iiiiiiiiiiiiiiiiiiii mmmmmmmmmmmmmmmmmmmm

Georgia

Look, 20 characters. abcdefghijklmnopqrst 12345678901234567890 iiiiiiiiiiiiiiiiiiii mmmmmmmmmmmmmmmmmmmm

It’s probably no surprise that in Courier, all the elements are the exact same width as their text contents.  In Helvetica, by contrast, this is mostly not the case except for numbers, which appear to be fixed-width.  In Georgia, by contrast, none of the text contents fit the boxes, not even the numbers.

What I’ve found through random experimentation is that in proportional typefaces, 1ch is usually wider than the average character width, usually by around 20-30%.  But there are at least a few typefaces where the zero symbol is skinny with respect to the other letterforms; in such a case, 1ch is narrower than the average character width.  Trajan Pro is one example I found where the zero was a bit narrower than the average, but I’m sure there are others. Conversely, I’m sure there are typefaces with Big Fat Zeroes, in which case the difference between ch and the average character width could be around 50%.

So in general, if you want an 80-character column width and you’re going to use ch to size it, aim for about 60ch, unless you’re specifically working with a typeface that has a skinny zero.  And if you’re working with multiple typefaces, say one for headlines and another for body copy, be careful about setting ch measures and thinking they’ll be equivalent between the two fonts.  The odds are very, very high they won’t be.

It would be interesting to see the Working Group take up the idea of average character width as a unit of measure—say, 1acw or possibly just 1cw—which actually uses all the letterforms in a typeface to calculate an average value.  That would get a lot closer to “make your columns 60 characters wide!” in a lot more cases than ch does now.


Specificity in :not(), :has(), and :matches()

Published 2 years, 3 months past

A few years back, I wrote a short post on specificity, element proximity, and the negation pseudo-class.  Everything in it is still accurate and relevant, but I have some updates to share.

First off, I’d like to clarify something that some people may have found confusing.  In that post, I said:

But it turns out that the negation pseudo-class isn’t counted as a pseudo-class.

That might leave some people with the idea that the entire negation portion of the selector is ignored for the purposes of specificity, especially if you don’t speak spec.

So consider the following:

div:not(.one) p

In order from left to right, that’s an element selector (div), a negation pesudo-class (:not) a class selector (.one), and another element selection (p).  Two element selectors and one class selector are counted towards the specificity, yielding a total of 0,0,1,2.  That’s the same specificity as div.one p, though the two selectors select very different things.

In Ye Olden Days, that was easy enough to work out, because :not() could only ever contain a simple selector.  Things are looking to get more complicated, however—:not() is set to accept grouped selectors.  So we will at some point be able to say:

div:not(.one, .two, #navbar) p

So any p element that is not descended from a div that has a class containing either one or two (or both), or that has an id of navbar, will be selected.

But how do we calculate the specificity of that whole selector?  Just add up all the pieces?  No.  The Working Group recently decided that the specificity contributed from inside a :not() will be equal to the single selector with the highest specificity.  So given div:not(.one, .two, #navbar) p, the #navbar will contribute 0,1,0,0 to the overall specificity of the selector, yielding a total of 0,1,0,2.  The specificities of .one and .two are ignored.

This same approach will be taken with the :has() and :matches() pseudo-classes.  Thus we get the following:


:matches(nav, header, footer#pageend) a[href] {color: silver;}  /* 0,1,1,2 */
article:has(a.external, a img)  /* 0,0,1,2 */
input:not([type="radio"], [type="checkbox"])  /* 0,0,1,1 */

In the first instance, the bits that are added together are footer#pageend and a[href], so that’s one ID, one attribute, and two elements.  In the second, it’s article and a.external for one class and two elements.  And last, we add up input and either of the [type=""] attribute selectors, since their specificities are equal, which means we add up one attribute and one element.

There is still, so far as I’m aware, no concept of DOM-tree proximity in CSS.  I would still continue to wager that will remain true, though I’d put a fair bit less money down now than I would have six years ago.


Displaying CSS Breakpoint Information with Generated Content

Published 2 years, 7 months past

In the course of experimenting with an example design for my talks at An Event Apart this year, I came up with a way to keep track of which breakpoint was in force as I tested the design’s responsiveness.  I searched the web to see if anyone else had written about this and didn’t come up with any results, so I’ll document it here.  And probably also in the talks.

What I found was that, since I was setting breakpoints in ems instead of pixels, the responsive testing view in browsers didn’t really help, because I can’t maintain realtime mapping in my head from the current pixel value to however many rems it equals.  Since I don’t think the browser has a simple display of that information, I decided I’d do it myself.

It starts with some generated content:

body::before {content: "default";
   position: fixed; top: 1px; right: 1px; z-index: 100; padding: 1ch;
   background: rgba(0,0,0,0.67); color: rgba(255,255,255,0.75);
   font: bold 0.85rem Lucida Grande, sans-serif;}

You can of course change these to some other placement and appearance.  You can also attach these styles to the html element, or your page wrapper if you have one, or honestly even the footer of your document—since the position is fixed, it’ll be viewport-relative no matter where it originates.  The real point here is that we’re generating a bit of text we can change at each breakpoint, like so:

@media (max-width: 38em) {
   body::before {content: "<38em";}
   /* the rest of the breakpoint styles here */
}
@media (max-width: 50em) {
   body::before {content: "<50em";}
   /* the rest of the breakpoint styles here */
}
@media (min-width: 80em) {
   body::before {content: ">80em";}
   /* the rest of the breakpoint styles here */
}

The labels can be any string you want, so you can use “Narrow”, “Wide”, and so on just as easily as showing the measure in play, as I did.

The downside for me is that we automatically can’t make the labels cumulative in native CSS.  That means the order the @media blocks appear will determine which label is shown, even if multiple blocks are being applied.  As an example, given the styles above, at a width of 25em, the label shown will be <50em even though both the 38em and 50em blocks apply.

There are ways around this, like switching the order of the max-width blocks so the 38em block comes after the 50em block.  Or we could play specificity games:

@media (max-width: 38em) {
   html body::before {content: "<38em";}
   /* the rest of the breakpoint styles here */
}
@media (max-width: 50em) {
   body::before {content: "<50em";}
   /* the rest of the breakpoint styles here */
}

That’s not a solution that scales, sadly.  Probably better to sort the max-width media blocks in descending order, if you think you might end up with several.

The upside is that it’s easy to find and remove these lines once the development phase moves to QA.  Even better, before that point, you get a fully customizable in-viewport indication of where you are in the breakpoint stack as you look at the work in progress.  It’s pretty trivial to take this further by also changing the background color of the little box.  Maybe use a green for all the block above the “standard” set, and a red for all those below it.  Or toss in little background image icons of a phone or a desktop, if you have some handy.

So that’s the quick-and-dirty little responsive development hack I came up with this morning.  I hope it’s useful to some of you out there—and, if so, by all means share and enjoy!


Addendum: Emil Björklund proposes a variant approach that uses CSS Custom Properties (aka CSS variables) to implement this technique.


“CSS Pocket Reference, 5th Edition” to Production

Published 2 years, 7 months past

Just over an hour before I started writing this post, I handed off CSS Pocket Reference, 5th Edition to the Production department at O’Reilly.  What that means, practically speaking, is that barring any changes that the editors find need to be made, I’m done.

Besides all the new-new-NEW properties included in this edition (flexbox and grid being just two of the most obvious examples), we put a lot into improving the formatting for this edition.  Previous editions used a more sprawling format that led to the 4th edition getting up to 238 pages, which cast serious shade on the word “Pocket” there in the title.  After all, not all of us live in climates or cultures where 24/7 cargo pants are a viable option.

So with a few ideas from me and several more from the production team, we managed to add in all the new properties and still bring the page count down below 200.  My guess is the final copy will come in about 190 pages, but much will depend on how crazy the indexer gets, and how much the formatting gets changed in the final massaging.

We don’t have a firm release date yet; I’m pulling for April, but it’s really not up to me.  I’ll make announcements via all the usual channels when pre-order is available, and of course when publication day arrives.

For now, for the first time in many years, I don’t have a book project on my to-do list.  I don’t even have a book proposal on my to-do list.  It’s a slightly weird feeling, but not an unwelcome one.  I’ll be putting the extra time into my content for An Event Apart: I’m giving a talk this year on using the new CSS tools to make our jobs easier, and doing Day Aparts in Boston and San Francisco where I spend six hours diving deep into guts of stuff like flexbox Grid, writing modes, features queries, and a whole lot more.

So my time will continue to be fully spoken for, is what I’m saying.  It’ll all be fun stuff, though, and it’s hard to ask for more out of my work.


Generating Wireframe Boxes with CSS and HTML5

Published 2 years, 9 months past

I was recently noodling around with some new layout ideas for An Event Apart’s speaker pages (e.g., Chris Coyier’s or Jen Simmons’) and wanted to share the ideas with other members of the team.  But what I really wanted to show was wireframes to convey basic arrangement of the pieces, since I hadn’t yet done any time polishing details.

I thought about taking screenshots and Photoshopping wireframe boxes over the various layout pieces, but then I wondered: could I overlay boxes on the live page with CSS?  Or perhaps even create and overlay them with nothing but some declarations and a wanton disregard for the sensibilities of god or man?

And that’s when I realized…I could.

“Your scientists were so preoccupied with whether they could they didn’t stop to think if they should.” —Dr. Ian Malcolm (Jurassic Park, 1993)

Now I’m going to share my discovery with you.

Before I get started, I want to make one thing clear: this isn’t backward compatible.  I don’t care.  It doesn’t need to be.  It does work in the latest versions of Firefox and Chrome, within reasonable tolerances—Chrome falls a bit short on one aspect, which I’ll point out when we get there.

All good?  Then let’s go.

The goal was creating X-filled boxes that wireframers love so very, very much.  I figured, any container element that needs to have a box stuck over it gets a class of wireframe.

<div class="wireframe">…(content goes here)…</div>

(Don’t get too attached to that class, by the way: it doesn’t survive the article.  Foreshadowing!)

The easy part was drawing a box around any element with that class.  I decided to use outlines, because they’re rarely employed for box edging and they don’t affect the layout even if your box-sizing is set to content-box.  (Mine usually is, by dint of not setting box-sizing at all.  But, you know, you do you.)

.wireframe {outline: 2px solid gray;}
Adding simple boxes (to a redesigned local copy of Rachel Andrew’s speaker page)

The boxes overlap each other because the layout pieces on the right are, at least for the moment, floated.  They’re laid out that way so that if the right-hand content is short and the bio and articles run long, they can wrap around below the ‘sidebar’.  It’s generally useful to have the outlines showing the actual limits of the element boxes to which they’re attached.

There is a potential drawback here: if your layout involves using negative margins to pull some elements out of their parents, and those parent elements are designated as wireframe boxes, outlines will stretch around the outhanging elements in Firefox, though not in Chrome.  Borders do not act the same way in Firefox.  I can’t rightly call this a bug, because I’m honestly not sure what outlines should do here.  Just be aware of it, is what I’m saying.

Anyway, drawing rectangles with outlines, that’s the easy part.  Now I needed two diagonal lines, going from corner to corner.  But how?

Linear gradients, that’s how.  See, if you use quadrant-based directions for your gradients, special magic math happens under the hood such that at the exact midpoint of the gradient, the color-line that extends perpendicularly off the gradient ray shoots precisely into the corners of the two quadrants adjacent to the quadrant into which the gradient ray is pointing.  Okay, that was probably hard to follow.  For example, set the gradient direction as to top right and the 50% color line of the gradient will run into the top left to the bottom right corners.

That’s exactly what I needed!  Thus:

.wireframe {outline: 2px solid gray;
   background:
      linear-gradient(to top right,
         transparent 49.9%, gray 49.9%,
         gray 50.1%, transparent 50.1%);
}

Okay, that’s one diagonal line.  The other is literally a copy of the first, except for having it go toward a different quadrant.

.wireframe {outline: 2px solid gray;
   background:
      linear-gradient(to top right,
         transparent 49.9%, gray 49.9%,
         gray 50.1%, transparent 50.1%),
      linear-gradient(to bottom right,
         transparent 49.9%, gray 49.9%,
         gray 50.1%, transparent 50.1%);
}
Diagonal lines!

Bingo: an X.  But not one that scales terribly well.  Using percentages there means that the gray lines will be as thick as 0.2% the total length of the gradient ray.  Small boxes get thin, sometimes broken diagonals.  Great big boxes get thick honkin’ lines.

So I fixed it with calc().

.wireframe {outline: 2px solid gray;
   background:
      linear-gradient(to top right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      linear-gradient(to bottom right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px));
}
Properly sized diagonal lines!

And there you go: two-pixel-thick diagonal lines.

There are two things to note here, before we move on.  First is that the spaces around the operators in the calc() values are intentional and, more to the point, necessary.  If you remove one or both of those spaces, calc() will simply fail to work.  In other words, calc(50%-1px) will fail—no background for you!  This is as designed, and there are reasons for it I don’t want to go into here, but suffice to say they exist and are arguably sensible.  calc(50% - 1px), on the other hand, works as intended.

Well, mostly: this is where Chrome comes up a bit short.  In large boxes, Chrome creates fuzzy lines thicker than 2 pixels.  I’m not sure what it’s doing to fudge the numbers here, but it sure seems like it’s fudging something.  The lines also don’t go into the corners quite as precisely as they should.  Firefox’s lines, on the other hand, come out correctly sized no matter what box size I set up, even if they are a bit jagged at times, and they go exactly into the corners of all the boxes I tested.  Chrome’s sloppiness here isn’t a deal-breaker, as far as I’m concerned, but it’s there and you should know about it.

So that’s an element with an outer edge and two diagonal lines.  This is great as long as the box contains no actual content, which will sit on top of the diagonals, as you can see with the “hero image” in the top right.  Maybe that’s what you want, in which case great, but I specifically wanted overlays.  That way I could stick them on a live page and sort of fade out the contents while sticking wireframe boxes on top, to make the boxes the focus while still showing the stuff inside them.

Enter generated content.  If I create a pseudo-element and attach the diagonal background gradients to that, they can sit on top of all the content.  That’ll also let me throw in a translucent background color to fill the box and fade out the contents.  Like so:

.wireframe {outline: 2px solid gray;
   position: relative; z-index: 1;}
.wireframe::before {
   position: absolute; z-index: 8675309;
   top: 0; bottom: 0; right: 0; left: 0;
   background:
      linear-gradient(to top right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      linear-gradient(to bottom right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      #FFF9;
      content: "";
}
Placing the diagonals, and a translucent color, over the elements

I used ::before mostly because hey, why not, but also because clearfix is usually an ::after and I hear people are still using clearfix, more’s the pity.  So this avoids it.  If you’ve moved beyond the need for clearfix, then you can use ::after just as easily.  Whatever floats your fancy.  (Get it?  Floats?  Yeah?  Clearfix?  Floats?  Ah, I kill me.)

The stupidly large z-index on the ::before is there to put the box overlay above any gridded, flexed, or positioned content that has an automatic z-index, or at least a sensible one.  You can raise it as high as you’d like (and your browser’s bit-depth will allow).  The small z-index on the elements themselves, on the other hand, makes sure they get an explicit stacking placement instead of an automatically-assigned place on the Z axis.  I find this generally settles a number of odd behaviors in various browsers.  Your experience may vary.

It was at this point that I realized there was a whole other level here.  I mean, wireframe boxes stretched over content is pretty nifty all by itself.  That could have been enough.  But it wasn’t.

Because what I realized was that I didn’t just want wireframe boxes, I wanted labeled wireframe boxes.  If a box was being applied to a list of articles, then I wanted a great big “Articles” label sitting in the middle of it, to make it obvious what was being placed there.

Well, there was already a content property just sitting there, waiting to throw in actual content instead of an empty string, but how to fill it?  And that’s when I knew that .wireframe’s days were numbered.

That’s because the easiest way to label each box was to use an HTML data attribute to attach the label I wanted to display.  And once that attribute was there, why not apply the wireframe styles based on the presence of the attribute, instead of adding class names that might get in the way of some unexpected DOM script?  So I changed the markup and CSS like this:

<div data-wf="Articles">…(content goes here)…</div>
[data-wf] {outline: 2px solid gray;
   position: relative; z-index: 1;}
[data-wf]::before {
   position: absolute; z-index: 8675309;
   top: 0; bottom: 0; right: 0; left: 0;
   background:
      linear-gradient(to top right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      linear-gradient(to bottom right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      #FFF9;
      content: "";
}

(True story: I almost called it data-wtf instead.  Almost.)

Having done that, I could modify the CSS to insert the attribute value, style the inserted text to look nice, and use flexbox properties to center it in the box.  So I did.

[data-wf] {outline: 2px solid gray;
   position: relative; z-index: 1;}
[data-wf]::before {
   position: absolute; z-index: 8675309;
   top: 0; bottom: 0; right: 0; left: 0;
   background:
      linear-gradient(to top right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      linear-gradient(to bottom right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      #FFF9;
      content: attr(data-wf);
      font: bold 2em Jubilat, Georgia, serif;
      color: gray;
      display: flex; justify-content: center; align-items: center;
}
Adding centered labels

That yielded big beautiful bold Jubilat labels (Jubilat is one of AEA’s brand font faces), sitting right on top of the center of the box, the crossing of the two diagonal lines behind them.

Which actually turned out to be a small problem for me.  That text is certainly readable, but I wanted it to stand out a bit more from the diagonals.  I decided to stack text shadows in order to semi-simulate outside text stroking.

[data-wf] {outline: 2px solid gray;
   position: relative; z-index: 1;}
[data-wf]::before {
   position: absolute; z-index: 8675309;
   top: 0; bottom: 0; right: 0; left: 0;
   background:
      linear-gradient(to top right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      linear-gradient(to bottom right,
         transparent calc(50% - 1px), gray calc(50% - 1px),
         gray calc(50% + 1px), transparent calc(50% + 1px)),
      #FFF9;
      content: attr(data-wf);
      font: bold 2em Jubilat, Georgia, serif;
      color: gray;
      text-shadow:
         0 0 0.25em #FFF9, 0 0 0.25em #FFF9,
         0 0 0.25em #FFF9, 0 0 0.25em #FFF9,
         0 0 0.25em #FFF9;
      display: flex; justify-content: center; align-items: center;
}
“Stroking” the box labels

It’s possible to use just four offset shadows with minimal or zero blur, but I find it sometimes creates weird jags on serif fonts, so I like stacking blurred shadows better.  But, again, you do you.

As I looked over the results, it slowly dawned on me that the white-on-gray box scheme works well enough for a starting wireframe setup with no branding applied, but I was planning to drop these on pages with actual design and colors and that sort of thing.  I didn’t want the boxes to fill with translucent white; I wanted them to be translucent versions of the page background color.  And, furthermore, I wanted a way to be able to easily alter that color, when applied to different designs.

Custom properties to the rescue!  Which is to say, native CSS variables to the rescue!

Our page background color at An Event Apart is #F7F6F1, a combo I actually have memorized at this point.  Since I wanted to fill the boxes with a roughly three-quarters-opaque variant, I settled on #F7F6F1BB.  (Actual 75% is BF, if you care.)  So I defined a custom property for it:

html {
   --fill: #F7F6F1BB;
}

I could have assigned the variable to the [data-wf] rule instead of html, but I felt like setting them globally.  Because that’s how I roll, yo—Wulf & Shaw have no strings on me.  If you want to bring the variables in closer, go for it.

While I was there, I figured, why not, let’s also define a variable for the shared color of the outlines, diagonals, and label text.

html {
   --fill: #F7F6F1BB;
   --wire: gray;
}

Then all I needed was to sprinkle variable calls where the colors were sitting.  I ended up here:

html {
   --fill: #F7F6F1BB;
   --wire: gray;
}
[data-wf] {outline: 2px solid var(--wire);
   position: relative; z-index: 1;}
[data-wf]::before {
   position: absolute; z-index: 8675309;
   top: 0; bottom: 0; right: 0; left: 0;
   background:
      linear-gradient(to top right,
         transparent calc(50% - 1px), var(--wire) calc(50% - 1px),
         var(--wire) calc(50% + 1px), transparent calc(50% + 1px)),
      linear-gradient(to bottom right,
         transparent calc(50% - 1px), var(--wire) calc(50% - 1px),
         var(--wire) calc(50% + 1px), transparent calc(50% + 1px)),
      var(--fill);
      content: attr(data-wf);
      font: bold 2em Jubilat, Georgia, serif;
      color: var(--wire);
      text-shadow:
         0 0 0.25em var(--fill), 0 0 0.25em var(--fill),
         0 0 0.25em var(--fill), 0 0 0.25em var(--fill),
         0 0 0.25em var(--fill);
      display: flex; justify-content: center; align-items: center;
}
The final product, with color themes and everything

The label could be broken out to use its own variable (e.g., --text or --label) easily enough, but I wanted a minimum of things to change.  I know myself too well to set up a bunch of controls to fiddle with, especially where color is concerned.

And with that, I had a ready-to-hand, easily theme-able wireframing style block that I can drop into any development page and invoke simply by adding a few data attributes to the markup.  Data attributes, I might add, that would be trivially easy to later find and remove with regular expressions.  It’s a quick way to make it clear to stakeholders that a work in progress is, in fact, in progress, as well as a handy way to visualize which pieces of a prototype layout are going where.

Now that we’ve come to the end and you’re still hanging in there with me, let me just say that I hope you’ve enjoyed this little trip through various parts of CSS.  If you have any questions, feel free to drop them in the comments below.  I’ll do my best to respond in reasonable amounts of time, travel and such permitting.


P.S. And one final note, as Kai Ryssdal would say: every bit of CSS I used here is covered in CSS: The Definitive Guide, 4th Edition.  I turned to my print copy twice in the process of working all this out, as it happens, to remind myself of specific syntax (for custom properties) and whitespace requirements (for calc() operators).  It really feels good to have a thing I made be useful to me!


Browse the Archive

Earlier Entries

Later Entries