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.
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 <h1> in some situations needs to be an <h2> 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 <h1>. 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 <h2>.
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:
<?php blogpostMarkup("archive"); ?>
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 <h1> from the masthead except on the home page, being the one place it makes sense to be an <h1>.
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:
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.
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 “meyerweb.com” is always an <h1> and the page title (or blog post titles) are all <h2>. If I demoted the masthead content to, say, a plain old <div>, and promoted the post headings, then on pages like the home page, there’d be a whole bunch of <h1>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!
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:
Masthead
Navigation (in a <nav> element)
Main page content (in a <main> element), occasionally with a sidebar
Footer (in a <footer> element)
But this is, at the moment, the source order of those pieces:
Masthead
Main page content (in a <main> element), occasionally with a sidebar
Navigation (in a <nav> element)
Footer (in a <footer> element)
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 <main> element for the main content of the page? And the <nav> and <footer> elements, do those also help with jumping around the page? If not, what’s the best-practice structural order for those pieces?
If so, does that mean it’s okay to put the navigation back up there in the source order, and stop doing wacky things with the order element to place it visually where it isn’t, structurally?
I have the same questions for those who use keyboard tabbing of the visual layout, not speaking browsers. What’s the best way to help them? If it’s tabindex, how should I order the tabbing index?
And in either case, do I need skip links to get people around quickly? Do I want skip links? Do my assistive-technology users want skip links?
Maybe the real question is “Given this layout, and my desire to make getting to main content and other pieces of the page as easy as possible for those who rely on assistive technology, how should I structure and annotate the content to raise the fewest barriers for the fewest people?”
Unless, of course, the real question is one I don’t know enough to ask.
Can you help me out, accessibility hivemind? I’d really appreciate some expert insight. All my instincts are more than a decade out of date.
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:
December 26th (today!) starting around 2000 UTC (3:00pm EST, 12:00n PST)
December 27th, 1830 UTC (1:30pm EST, 10:30am PST)
December 28th, 1900 UTC (2:00pm EST, 11:00am PST)1500 UTC (10:00am EST, 7:00am PST)
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.
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:
I’ll start Wednesday, December 27th.
I’ll redesign http://meyerweb.com for the first time in a dozen years, and I’ll do it live on the production site.
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!
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.
(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.)
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.
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.
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:
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:
(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.
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.
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:
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!
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. There’s just a lot more of it. You might not be able to remember every single property and value, but that’s okay. Neither can I. I don’t think many (or any) of us can hold every last tiny piece of a serious programming language in our heads, either. We know the core things, and the patterns we learned, and some cool techniques, and there are the things we always have to look up because we don’t often use them.
I also think people saw the books in the picture and forgot about the time component. I checked the page number at the end of the last chapter for each book (thus omitting appendices and the index) and came up with the following chart.
Editions of CSS: The Definitive Guide
Whoa, right? But let’s chart those numbers again, this time taking date of publication into account.
Editions of CSS: The Definitive Guide over 18 years
Rather less crazy, I would say. It’s still an apparent upward trend, but think about all the new features that have come out since the 3rd Edition, or are coming out right now: gradients, multiple backgrounds, sticky positioning, flexbox, Grid, blending, filters, transforms, animation, and media queries, among others. A lot of really substantial capabilities. They don’t make CSS more convoluted, but instead extend it into new territories.
Speaking of which, a few people asked how I got the books to line up so neatly. I admit they’re being supported by a table there, but the real secret? Grid. So easy. Here, have a set of three “book spines” (each one a cite element) gridded out in supporting browsers, and still laid out just fine in older browsers.
See what I mean? That took me about 20 minutes all told, even though I’m using internal markup that’s probably not ideal, by putting grids in my grid so I can grid while I grid. I rearranged the 2nd-3rd-4th source order into the visual arrangement seen in the photo, and centered the text blocks vertically without using margins or padding or line height to fake it, just because I could. The grid layout is an enhancement: in older browsers, the spines render as a vertical stack, one atop the other, in chronological order.
Another five minutes, and I could neaten that rendering up further so the spines looked more consistent between grid-capable and grid-incapable browsers. Five to ten more minutes could get the O’Reilly logo and fish graphics into the black areas. Five more, and it would be neatly responsive. Maybe I’ll come back and fix it up to do those things, but for now, as far as I’m concerned, this will do nicely.
The other common response I got was, “Well, looks like it’s time for ‘CSS: The Good Parts’!” Fam, we already have “CSS: The Good Parts”. Estelle and I just wrote it. You can see it on the right side of the picture up above. Available now on paper or in electronic form!
