Subscribe: Thoughts From Eric
Added By: Feedage Forager Feedage Grade A rated
Language: English
book  content  css  design  edition  element  it’s  i’ll  i’m  layout  make  navigation  new  page  pages  that’s 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Thoughts From Eric

Thoughts From Eric

Things that Eric A. Meyer, CSS expert, writes about on his personal Web site; it's largely Web standards and Web technology, but also various bits of culture, politics, personal observations, and other miscellaneous stuff

Updated: 2018-02-27T17:16:26Z


Displaying CSS Breakpoint Information with Generated Content


A quick-and-dirty way to keep track of which breakpoint is in force as you test a design’s responsiveness.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


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.

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.

My Contribution to “Modern Loss”


A few words about my essay “The Second Third Child”, included in the new book from Modern Loss.



My wife Kat and I tell ourselves we’d love another child for who they are, not for who they replace. We even believe it. But we can’t be sure of it—and that keeps us from shutting our eyes, jumping back into the adoption process, and hoping it will turn out okay. We know all too horribly well that sometimes, it doesn’t.

That’s the opening of my essay “The Second Third Child”, included in the new book from Modern Loss titled Modern Loss: Candid Conversation About Grief. Beginners Welcome, published this week.

I’m deeply honored to be one of the 40+ contributors to the book, some of whom you may know—Dresden Dolls co-founder Amanda Palmer, CNN’s Brian Stelter, author Lucy Kalanithi, Dear Evan Hansen director Michael Greif, Stacy London of What Not To Wear—and many of whom you may not, as I will be unknown to the vast majority of the book’s readers. I’ve written articles for Modern Loss in the past, but to be entrusted with a part of their first book was humbling.

Several of the essays in the book are intentionally funny, but mine is not one of them. It’s quiet, reflective, and elegiac in more than one way, but never anything but honest. It appears in the first section of the book, titled “Collateral Damage”.

As Stephen Colbert put it: “Talking about loss can feel scary. This book isn’t. It’s about grieving deeply over the long term, and the reassurance that you’re far from broken because of it.” I hope my essay, and the book as a whole, helps readers to come to terms with their own grief, by seeing that they are not alone, and that they did the best they could even if it doesn’t feel that way at all.

All my thanks to Rebecca Soffer and Gabrielle Birkner for making me a part of their incredible, inspiring work.

Headings and Labels


Following on my last two posts about accessibility improvements to meyerweb, I’ve made two more adjustments: better heading levels and added ARIA labels.

Following on my last two posts about accessibility improvements to meyerweb, I’ve made two more adjustments: better heading levels and added ARIA labels.

For the heading levels, the problem I face is one familiar to many authors: what makes sense as an

in some situations needs to be an

in others.  The most common example is the titles of blog posts like this one.  On its permalink page, the title of the page is the title of the post.  There, it should be an

.  On archive pages, including the home page of meyerweb, there are a number of posts shown one after the other.  In those situations, each post title should be an


Part of the redesign’s changes were to write a single PHP routine that generated posts and their markup, which I could then simply call from wherever.  So I added an optional function parameter that allowed me to indicate the context in which a post was being placed.  It goes something like this:

function blogpostMarkup($type = "standalone") {
    if ($type == "archive") $titletag = "h2"; else $titletag = "h1";
    // …markup is all generated here…
    echo $output;

Or code to that effect.  (I did not go copy-paste from my actual code base.)

So now, heading levels are what they should be, at least on most pages (I may have missed updating some of my old static HTML pages; feel free to point them out in the comments if you find one).  As a part of that effort, I removed the

from the masthead except on the home page, being the one place it makes sense to be an


As for ARIA labels, that came about due to a comment from Phil Kragnes on my last post, where he observed that pages often have multiple elements with a role of navigation.  In order to make things more clear to ARIA users, I took Phil’s suggestion to add aria-label attributes with clarifying values.  So for the page-top skiplinks, I have:

Similarly, for the site-navigation bar, I have:

The idea is that screen readers will say “Page navigation region” and “Site navigation region” rather than just repeating “Navigation region” over and over.

Other than cleaning up individual pages’ heading levels and the occasional custom layout fix (e.g., the Color Equivalents Table needed a local widening of the content column’s maximum size), I think the redesign has settled into the “occasional tinkering” phase.  I may do something to spruce up my old Web Review articles (like the very first, written when HTML tags were still uppercase!) and I’m thinking about adding subnavigation in certain sections, but otherwise I think this is about it.  Unless I decide to go really over the top and model my Tools page after Simon St. Laurent’s lovely new Grid design, that is…

Of course, if you see something I overlooked, don’t hesitate to let me know!  I can’t guarantee fast response, but I can always guarantee careful consideration.

Increasing Accessibility


Thanks to the fantastic comments on my previous post, I’ve made some accessibility changes.

Thanks to the fantastic comments on my previous post, I’ve made some accessibility improvements.  Chief among them: adding WAI-ARIA role values to various parts of the structure.  These include:

  • role="banner" for the site’s masthead
  • role="navigation" added to the navigation links, including subnavigation links like previous/next posts
  • role="main" for the main portion of a page
  • role="complementary" for sidebars in the blog archives
  • role="article" for any blog post, whether there are several on a page or just one

In addition, I restored skip links to the masthead of most pages (the rest will get them soon).  The links are revealed on keyboard focus, which I’m not sure I like.  I feel like these aren’t quite where they need to be.  A big limitation is the lack of :matches() (or similar) support in browsers, since I’d love to have any keyboard focus in the masthead or navigation links bring up the skip links, which requires some sort of parent selection.  I may end up using a tiny bit of enhancing Javascript to make the links’ UX more robust in JS situations, but still obviously available if JS fails.  And I may replicate them in the footer, as a way to quickly jump back up the page, especially to the navigation.

Speaking of the navigation links, they’ve been moved in the source order to match their place in the visual layout.  My instincts with regard to source order and layout placement were confirmed to be woefully out of date: the best advice now is to put the markup where the layout calls for the content to be.  If you’re putting navigation links just under the masthead, then put their markup right after the masthead’s markup.  So I did that.

The one thing I didn’t change is heading levels, which suffer all the usual problems.  Right now, the masthead’s “” is always an

and the page title (or blog post titles) are all

.  If I demoted the masthead content to, say, a plain old
, and promoted the post headings, then on pages like the home page, there’d be a whole bunch of

s.  I’ve been told that’s a no-no.  If I’m wrong about that, let me know!

There’s still more to do, but I was able to put these into place with no more than a few minutes’ work, and going by what commenters told me, these will help quite a bit.  My thanks to everyone who contributed their insights and expertise!

How Do I Increase Accessibility?


I have an accessibility question. Okay, it’s a set of questions, but they’re really all facets of the same question.

I have an accessibility question.  Okay, it’s a set of questions, but they’re really all facets of the same question:

How do I make my site’s structure the most accessible to the most people?

Which sounds a bit broad.  Let me narrow it down.  Here’s the basic layout order of most pages on meyerweb:

  1. Masthead
  2. Navigation (in a
  3. Main page content (in a
    element), occasionally with a sidebar
  4. Footer (in a

But this is, at the moment, the source order of those pieces:

  1. Masthead
  2. Main page content (in a
    element), occasionally with a sidebar
  3. Navigation (in a
  4. Footer (in a

The difference is the navigation.  I put it later in the source order because I want those using speaking browsers to be able to get the content quickly, without having to tab through the navigation on every page.

But is that actually a concern, given my use of a

element for the main content of the page?  And the

The Newwwyear Design


Well, here it is—the first new design for meyerweb since February 2005 (yes, almost 13 years).Well, here it is—the first new design for meyerweb since February 2005 (yes, almost 13 years).  It isn’t 100% complete, since I still want to tweak the navigation and pieces of the footer, but it’s well past the minimum-viable threshold. My core goal was to make the site, particularly blog posts, more readable and inviting.  I think I achieved that, and I hope you agree.  The design should be more responsive-friendly than before, and I think all my flex and grid uses are progressively enhanced.  I do still need to better optimize my use of images, something I hope to start working on this week. Things I particularly like about the design, in no particular order: The viewport-height-scaled masthead, using a minimum height of 20vh.  Makes it beautifully responsive, always allowing at least 80% of the viewport’s height to be given over to content, without requiring media queries. The “CSS” and “HTML” side labels I added to properly classed pre elements.  (For an example, see this recent post.) The fading horizontal separators I created with sized linear gradients, to stand in for horizontal rules.  See, for example, between post content and metadata, or underneath the navlinks up top of the page.  I first did this over at An Event Apart last year, and liked them a lot.  I may start decorating them further, which multiple backgrounds make easy, but for now I’m sticking with the simple separators. Using string-based grid-template-areas values to rearrange the footer at mobile sizes, and also to make the rare sidebar-bearing pages (such as those relating to S5) more robust. There are (many) other touches throughout, but those are some high points. As promised, I did livestream most of the process, and archived copies of those streams are available as a YouTube playlist for those who might be interested.  I absolutely acknowledge that for most people, nine hours of screencasting overlaid with rambling monologue would be very much like watching paint dry in a hothouse, but as Abraham Lincoln once said: for those who like this sort of thing, this is the sort of thing they like. I was surprised to discover how darned easy it is to livestream.  I know we live in an age of digital wonders, but I had somehow gotten it into my head that streaming required dedicated hardware and gigabit upstream connections.  Nope: my five megabit upstream was sufficient to stream my desktop in HD (or close to it) and all I needed to broadcast was encoding software (I used OBS) and a private key from YouTube, which was trivial to obtain.  The only hardware I needed was the laptop itself.  Having a Røde Podcaster for a microphone was certainly helpful, but I could’ve managed without it. (I did have a bit of weirdness where OBS stopped recognizing my laptop’s camera after my initial tests, but before I went live, so I wasn’t able to put up a window showing me while I typed.  Not exactly a big loss there.  Otherwise, everything seemed to go just fine.) My thanks to everyone who hung out in the chat room as I livestreamed.  I loved all the questions and suggestions—some of which made their way into the final design.  And extra thanks to Jen Simmons, who lit the fire that got me moving on this.  I enjoyed the whole process, and it felt like a great way to close the books on 2017. [...]

A Newwwyear Livestream


After I announced my newwwyear plans, a couple of people pinged me to ask if I’d do a Google Hangout or some such so that people could follow along as I live-redesign meyerweb. And I thought, what the heck, why not?

After I announced my newwwyear plans, a couple of people pinged me to ask if I’d do a Google Hangout or some such so that people could follow along as I live-redesign meyerweb in production.  And I thought, that sounds like the nerdiest Twitch stream ever, but what the heck, why not?

So!  I’m going to livestream at least part of my process over on YouTube Live, spread over a few days.  I picked YTL over Twitch because YouTube will archive the streams to my channel, whereas Twitch only holds onto them for 14 days, and one of my weaknesses is that I’m a data hoarder—I hate to throw away anything digital.  So I’ll keep copies on someone else’s computer.

During the stream, I’ll keep up a running commentary on what I’m doing and why.  This sounds artificial, but honestly, I talk to myself a lot as I work anyway.  I’ll also have the YouTube Live chat window open so people can ask questions about why I do what I do, and I’ll do my best to answer.  Or, you know, we can talk about the latest Star Wars movie or whatever.  I’m not going to put too many limits on it other than A) keep the language professional, since kids starting out in web design might join in; and B) treat everyone in the chat with respect.

My guess is any given stream session will be two hours, tops.  My tentative schedule is:

  1. December 26th (today!) starting around 2000 UTC (3:00pm EST, 12:00n PST)
  2. December 27th, 1830 UTC (1:30pm EST, 10:30am PST)
  3. December 28th, 1900 UTC (2:00pm EST, 11:00am PST)1500 UTC (10:00am EST, 7:00am PST)
  4. December 29th, 1500 UTC (10:00am EST, 7:00am PST)

I don’t have a specific structure for how I’m going to approach this, other than: first I turn off all site-wide styling and put up a note about it, maybe add a few very minimal styles, rework the page structures to be sane without CSS, then start building up a new design.  I have no idea how long each part of that sequence will take (except the “remove site-wide styles” part, that’ll take a few seconds).  But there isn’t a scheduled “Typography Day” or what-have-you: I’ll probably go wandering off on tangents, riffing on happy accidents, fiddling with stuff as I notice it and it bugs me, etc., etc.  In other words, how I normally work.

If any of this sounds interesting to you, please join in!  I’ll do my best to announce start times with an hour or so lead over on Twitter, and as comments on this post.

A Meyerweb Makeover


This coming week, I’m going to redesign—which will be its first redesign in twelve and a half years.

This coming week, I’m going to redesign—which will be its first redesign in twelve and a half years.

I’m doing this as part of Jen Simmons’ #newwwyear initiative.  As Jen put it:

Ok, here’s the deal. Tweet your personal website plan with the hashtag #newwwyear (thanks @jamiemchale!): 1) When will you start? 2) What will you try to accomplish? 3) When is your deadline? Improve an existing site. Start a new one. Burn one down & start over. It’s up to you.

Many of us feel bad about our personal websites. Me included. We keep meaning to make one, improve what’s there, or burn it down and start over. We are busy. Afraid. Overwhelmed. Well, let’s do it. Maybe over the holidays. Maybe after, in the New Year. #newwwyear

On Friday, I announced my plan:

  1. I’ll start Wednesday, December 27th.
  2. I’ll redesign  for the first time in a dozen years, and I’ll do it live on the production site.
  3. My deadline is Wednesday, January 3rd, so I’ll have a week.

I won’t be redesigning all day every day—I still have paying work to do, after all—but I’ll do my best to put in a couple of hours each weekday.

When say I’ll do it live, I mean I’ll be making all my changes here on the production site, with minimal or no testing beforehand—literally opening the style sheet(s) into BBEdit via Transmit, and saving changes up to the server to see what happens.  Stuff will break, and then I’ll fix it, live in the public eye.  It’s possible I’ll try out new ideas and then junk them before moving on to others.  I’m hoping that accidents spark inspiration, as they often do.

(There will be a local copy of the site in case things go so badly that I need to reset to the starting point.  I’m not completely insane, after all.)

I have a vague plan with all this, which is: realign the site’s appearance to be more inviting, more readable, and more visually engaging.  I do have a few past experiments that I’ll fold in, like using relative times (e.g., “Two months ago”) on posts, but a lot of this will be me doing free-association design.  And hopefully a little markup cleanup and enhancement as well.

I’m sticking with WordPress to drive the blog, given that it contains close to two decades of posts and makes it easy to allow comments, a feature I still value; and my hand-built old-school-standards-punk mostly-static templating system for the rest of the site, which let the site be static(ish) way before static was cool.  (No, I will not consider migrating to other CMSes or template systems: with a week set aside for this, I won’t have the time.)

So, that’s the plan: a week for a meyerweb makeover.  I don’t know if I’ll keep up a running commentary on Twitter while I do, or if I’ll take breaks and blog short entries chronicling my progress, or what.  If someone sets up a #newwwyear Slack team, I’ll probably join in.  If the #newwwyear idea excites you, I hope you’ll join in too!

Book Review: “Create with Code: Build Your Own Website”


A review of an introduction-to-web-design book that’s one of the best I’ve seen, Create with Code: Build Your Own Website, written by Clyde Hatter of CoderDojo’s Dojo Bray in Ireland.A thing people ask me with some regularity is, “What’s a good book for someone who wants to get started in web design?”  I’m here to review a book that’s one of the best I’ve seen, Create with Code: Build Your Own Website, written by Clyde Hatter of CoderDojo’s Dojo Bray in Ireland.  I got my copy at my son’s elementary school Scholastic Book Fair earlier this year; it’s available from online booksellers and probably through local bookstores as well. I’ll go into some details of what’s in it and what I think, and there will be some complaints.  So I want to stress up front: this is an excellent book for people who want to learn web design, with the modifier if you’re available to help them out when they hit stumbling blocks.  You aren’t going to have to hold their hands through the whole thing by any stretch, but there are moments where, for example, the filenames used in the text will mislead.  (More on that anon.)  For all that, it’s still an excellent book, and I recommend it. The book is 94 pages, of which 88 pages are instructional, and none of it is filler—Mr. Hatter packs a surprising amount of good web design practice into those 88 pages.  The pages themselves are filled with colorful design, and the text is easily readable.  It’s aimed squarely at elementary-school readers, and it shows.  That’s a good thing, I hasten to add.  The tone is simple, uncomplicated, and stripped to the essentials.  At no point does it condescend.  It works well for any age, not just the suggested range of 7-17.  I enjoyed reading it, even though I knew literally everything the book covers. The organizing idea of the book is creating a small web site for a ninja band (!!!) called The Nanonauts.  In the course of the book, the reader sets up a home page, an About Us page, a page listing upcoming concerts, and a couple more.  Everything makes sense and interrelates, even if a couple of things feel ever so slightly forced. Here’s a page-number timeline of concepts’ first introductions: p. 6 Brainstorming site content and sketching a site map.  Bear in mind here that the actual instructional text starts on page 6. p. 10 Adding a style sheet to an HTML document via a link element. p. 14 A nice breakdown of how images are loaded into the page, what the various (common) image attributes are and mean, and the importance of good alt text.  On page 14. p. 17 The concept of an empty element and how it differs from other elements. pp. 20-24 An extended discussion of proper structure and good content for the web.  It shows how using headings and paragraphs breaks up large text walls, makes the distinction between ordered and unordered lists, and demonstrates the importance of proper element nesting. p. 25 Diving into CSS.  A style sheet was added to the document back on page 10, but this is where CSS starts to be discussed in detail. p. 28 Radial gradients!  They went there!  The syntax isn’t dissected and explained, but just showing working gradients clues readers in to their existence.  There’s also an example of styling html separately from body, without making a super big deal out of it.  This is a pattern throughout the rest of the book: many things are used without massively explaining them.  The author relies on the reader to repeat the example and see what happens. pp. 30-32 A really great explanation of hexadecimal color values.  I’ve never seen better, to be honest.  That’s followed by a similarly great breakdown of the uses for, and differences between, px, em, and % values for sizing. p. 36 The fi[...]

Generating Wireframe Boxes with CSS and HTML5


A method to create labeled wireframe-style boxes on top of existing page elements using a potpourri of CSS and tiny bits of HTML5.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. 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.
…(content goes here)…
(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[...]

Declining Complexity in CSS


Some thoughts on the complexity of CSS—or, more properly, the declining complexity of CSS.At the end of last week, I posted this picture to Twitter and Facebook, and on Twitter it kind of took off. On the left: the 2nd and 3rd editions of “CSS: The Definitive Guide”. On the right, a single copy of the fourth edition. My intent in posting it was to say, in not nearly so many words, “Look at how CSS has dramatically expanded its capabilities since the previous edition, and wow, I can’t believe Estelle and I did that much work!”  I know we have 280 characters now, but I try not to blog places other than, well, my actual blog.  (Welcome!) The Twitter reaction was…interesting.  And by interesting, I really do mean interesting.  There were the people who responded with excitement and anticipation—thanks to you all!—but a whole lot of people who said, in effect, “This is what’s wrong with front end, all this accelerating complexity.” Which was not what I was saying.  And which is not, I think, what’s actually happened here, but it depends on what you mean by ”complexity”. CSS has a great deal more capabilities than ever before, it’s true.  In the sense of “how much there potentially is to know”, yes, CSS is more of a challenge. But the core principles and mechanisms are no more complicated than they were a decade or even two decades ago.  If anything, they’re easier to grasp now, because we don’t have to clutter our minds with float behaviors or inline layout just to try to lay out a page.  Flexbox and Grid (chapters 12 and 13, by the way) make layout so much simpler than ever before, while simultaneously providing far more capability than ever before. “How?  How is that even possible?” you might ask, to which I would reply, “That’s what happens when you have systems that were designed from the outset to be used for layout.”  Floats weren’t; they were a necessary hack.  Inline-block wasn’t; that was a necessary hack.  People did ingenious, brilliant things to make those tools work, yes.  But they were always a perversion of original intent. Whereas with Grid and Flexbox, we have things that were always meant to handle layout.  That’s why, for example, they make vertical centering of elements a breeze.  A breeze, people.  I’ve been working with the new stuff long enough that I literally forget vertical centering is supposed to be difficult.  I have similar amnesia about the struggle to balance layout needs with accessible source order.  These problems are not 100% banished, but it’s to the point now that when I do run into these problems, it’s a surprise, and almost a personal affront.  Like how you feel when you’ve been zooming along a near-empty highway for hours, enjoying the rush of wind and power, and then you come around a curve and all of a sudden there’s a roadblock of two slow-moving cars side by side, doing exactly the speed limit of all things, each refusing to pass the other. I envy “the kids”, the ones just starting to learn front end now.  They’re likely never going to know the pain of float drop, or wrestling with inline blocks, or not being able to center along one axis.  They’re going to roll their eyes when we old-timers start grumbling about the old days and say, “Floats?!?  Who ever thought floats would be a good way to lay out a page? That’s totally not what they’re for, anyone can see that!  Were you all high as a kite, or just utterly stupid?”  You know, the way “the kids” talked ten years ago, except then it was about using tables for layout. So if you’ve written CSS in the past, CSS today is not significantly harder to understand, and probably a bit easier.  The[...]

“CSS: The Definitive Guide, 4th Edition” Release and Contents


CSS: The Definitive Guide, 4th Edition is wending its way to the reading public, and I have some updates on that.CSS: The Definitive Guide, 4th Edition is wending its way to the reading public, and I have some updates on that. The O’Reilly catalog still says October 2017, but for the physical copy, Barnes & Noble and Amazon are now listing a release date of November 5th, 2017, so we seem to have just missed that October release window I was hoping to hit.  But not by much!  The DRM-free version at eBooks is apparently available now, as are Nook and Kindle versions. For those of you with access to O’Reilly’s Safari subscription service, there’s an older version of the book currently available.  Apparently, so many people have joined the queue to get it that the content-update process breaks.  (Our production editor was impressed.)  O’Reilly’s engineering staff is aware of the problem and working on it, so hopefully by the time you read this, the problem will be resolved and the final copy online.  If not, our apologies, and thanks for your patience. If you’re wondering if this edition is for you, absolutely it is!  But I would say that, wouldn’t I?  As would my co-author Estelle.  To help you decide, here’s the Table of Contents with a few brief notes on the new things contained therein (chapters marked ALL NEW! are chapters that didn’t exist at all in the 3rd Edition): CSS and Documents – a brief overview of what CSS is for, how to apply it (including via HTTP headers!), basic syntax, media and feature queries Selectors – all the selectors as of mid-2017, including :not(), validity pseudo-classes, the case-insensitivity modifier in attribute selectors, and more Specificity and the Cascade – probably the least-changed chapter, this lays out the cascade in some detail Values and Units – adds viewport units, ch (which does not actually mean “one character”), calc(), and various new color syntaxes like HSL and #RRGGBBAA patterns Fonts – includes a lot about @font-face and the process of loading custom fonts, in addition to the classics like weight, style, variant, family, etc. Text Properties – adds a fair amount of material on non-horizontal writing and alignment, writing modes, hyphenation, and so forth Basic Visual Formatting – this is another chapter that didn’t change a huge amount from the 3rd Edition, though it does touch on the new values for display Padding, Borders, Outlines, and Margins – to all the existing details on those basic topics, we’ve added border-radius and all the properties that affect image borders Colors, Backgrounds, and Gradients – there are all the new background-related properties like background-size and background-clip, handling multiple background images, and the wonder world of linear and radial gradients, explained in more detail than anyone probably thought reasonable, plus there’s a section on box-shadow Floating and Shapes – floating hasn’t changed much, but the section on Float Shapes is all new and pretty nifty, if I do say so myself Positioning – this got a section on sticky positioning to go along with the classic positioning material Flexible Box Layout – ALL NEW! – the ins and outs, the nitty-gritty, the pros and cons of Flexbox Grid Layout – ALL NEW! – Grid is here and it’s hot; this chapter explores it in up-to-the-minute detail Table Layout in CSS – the third of the minimally-updated chapters, this discusses how data tables are laid out Lists and Generated Content – a surprisingly large amount of new material in this chapter, pretty much all centered around @counter-style and its capabilities and how you can create emoji counting systems Transform[...]

“CSS: The Definitive Guide, 4th Edition” Goes to Print


Yesterday afternoon, CSS: The Definitive Guide, 4th Edition went to the printers. Yesterday afternoon, CSS: The Definitive Guide, 4th Edition went to the printers.  Eighteen years after the First Edition hit shelves, eleven years after its predecessor came out, five years after I first started working on this edition, and thanks in no small part to Estelle Weyl and a parade of long-suffering editors at O’Reilly, the last changes were entered, the pages were locked, and the repository closed. It comes in at 1,088 pages: almost exactly twice the length of the Third Edition, with six new chapters and a lot of overhauling of old chapters.  Flexbox, Grid, filtering, blending, clipping and masking, float shapes, animations and transitions, transforms, image borders, counting systems, custom properties (a.k.a. CSS variables), media and feature queries—they’re all in there, and a whole lot more besides.  Gradients got a major new section in what used to be called just “Colors and Backgrounds” and is now “Colors, Backgrounds, and Gradients”.  And all the new background properties!  So many new background properties. We didn’t skimp on the visuals, either.  The book has, if I counted correctly, a total of 778 figures.  Almost all of them were captured in-browser, and you can download or clone all the files from GitHub.  If you’d rather just browse them online, you can do so thanks to GitHub Pages.  That’s also where to find the transition and animation examples that are referenced in the text, but not figures themselves (detailed animation being somewhat difficult to represent on paper).  If we add figures and animation examples together, there are 826 elements supporting the main text.  Which feels like a lot to me. The book will be available in both tree-wafer and glowing-display formats from your favorite supplier of such things; e.g., Amazon.  (If you’re going to buy through Amazon and are inclined to support another aspect of my life, please designate Rebecca’s Gift as your Amazon Smile recipient before buying the book.)  I also hear tell it will be available DRM-free from, and potentially in PDF form for those who prefer it.  O’Reilly doesn’t sell books directly any more, but I do believe it will be avialable to those with Safari subscriptions. I’ll have more to say about the book and its contents as the release date draws closer.  Last I heard, it should be out by the end of this month, but as always, release dates can slip for any number of reasons.  Even if this release does slip, it should still come out no later than early November. (Let’s hope I didn’t just jinx that.) This is always a tense and exhilarating time.  What if I got a huge piece completely wrong?  What if I made the wrong calls on what to include and what to defer to the next edition?  What if I missed egregious typos?  What if nobody likes it?  Basically, the same doubts that strike most any author.  But there’s also the incredible feeling of a project brought to its conclusion and the anticipation of getting it into readers’ hands.  This has been a longer-than-usual time coming, but as it usually does, the time has come at last.  I hope you’re looking forward to it half as much as I am.[...]

Adding Backgrounds to Directly Loaded SVGs


A quick explanation of how to add backgrounds to SVG files that have been loaded directly into a browser.

My primary SVG viewer is Firefox.  This is partly because it’s always running, so the startup time is essentially zero.  It also allows me to directly inspect and modify elements of the SVG element through the Web Inspector, which can be handy.

But I’ve run into a problem more than once, which is that if I load an SVG file in Firefox, the browser window’s background defaults to white, and a lot of times I’m trying to view images that are partially or entirely white.  I started thinking that if there were a way to make the window background medium gray, that would solve the problem with rare downsides, since I can’t remember trying to view an all-medium-gray SVG.

After a question on Twitter and some ideas from Tibor Martini, I realized I could use Stylish to give the SVG files a background through CSS.  I didn’t want to select all SVGs, only those I was loading directly, so I tried this:

svg:root {background: gray;}

And it worked!  So I decided to make it more robust by doing a multicolor gradient, and grayscaling it on hover.  I couldn’t use filter because that would grayscale the whole image, rather than just the background, but that was easy to work around.  I ended up with this:

svg:root {background: linear-gradient(135deg, hsl(0,50%,60%), hsl(180,50%,40%));}
svg:root:hover {background: linear-gradient(135deg, hsl(0,0%,60%), hsl(180,0%,40%));}

Which works great!  Except that I discovered Firefox applies it to all SVGs, even those loaded into HTML documents via img.  SVGs apparently define their own roots, which I hadn’t expected, but I can see how it might make sense.  So I poked around in MDN until I came up with this:

@-moz-document url-prefix(file:) {
    svg:root {background: linear-gradient(135deg, hsl(0,50%,60%), hsl(180,50%,40%));}
    svg:root:hover {background: linear-gradient(135deg, hsl(0,0%,60%), hsl(180,0%,40%));}

And that’s exactly what I wanted.  If it’s useful to you, have at it.  Just paste that into a new Stylish rule in Firefox, and you should be good to go.

If you’re on Chrome, you can import the above into Stylish and create a new rule, but it hasn’t worked for me, and I’m not sure why not.  Removing :root didn’t fix it when I tried, and that shouldn’t matter anyway: I can see in Chrome’s user styles that svg:root is used and applied.  And my Stylish toolbar icon shows the rule is being applied.  It just doesn’t do anything I can see.  If anyone can figure out how to make it work, or explain why it can’t work, I’d love to know in the comments!