I’m a fan of the componentization of the web. I think it’s a very nice way to build a website at just about any scale (except, perhaps, the absolute most basic). There are no shortage of opinions about what makes a good component, but say we scope that to third-party for a moment. That is, components that you just use, rather than components that you build yourself as part of your site’s unique setup.
What makes a third-party component good? My favorite attribute of a third-party component is when it takes something hard and makes it easy. Particularly things that recognize and properly handle nuances, or things that you might not even know enough about to get right.
Perhaps you use some component that does pop-up contextual menus for you. It might perform browser edge detection, such as ensuring the menu never appears cut off or off-screen. That’s a tricky little bit of programming that you might not get right if you did it yourself — or even forget to do.
I think of the <Link /> component that React Router has or what’s used on Gatsby sites. It automatically injects aria-current="page" for you on the links when you’re on that page. You can and probably should use that for a styling hook! And you probably would have forgotten to program that if you were handling your own links.
In that same vein, Reach UI Tabs have rigorous accessibility baked into them that you probably wouldn’t get right if you hand-rolled them. This React image component does all sorts of stuff that is relatively difficult to pull off with images, like the complex responsive images syntax, lazy loading, placeholders, etc. This is, in a sense, handing you best practices for „free.”
Here’s a table library that doesn’t even touch UI for you, and instead focuses on other needs you’re likely to have with tables, which is another fascinating approach.
Anyway! Here’s what y’all said when I was asking about this. What makes a third-party component awesome? What do the best of them do? (besides the obvious, like good docs and good accessibility)? Some of these might be at-odds. I’m just listing what people said they like.
Plug-and-play. It should „just work” with minimal config.
Lots of editable demos
Highly configurable
„White label” styling. Don’t bring too strong of design choices.
Styled via regular CSS so you can BYO own styling tools
NetNewsWire is one of the classic RSS apps, debuting in 2002. I was pretty stoked when it went 5.0 and was open-sourced in August 2019! You can snag it right here. (Sorry, Mac only.)
It’s super nice, is fast, and looks great. It has just the right features.
But… I thought, at least at first, that really prefer websites for reading RSS content. I have multiple machines. I have mobile devices. I don’t want my RSS to be limited to my laptop, I want an online service.
NetNewsWire on my Mac
Well! I found out that NetNewsWire syncs with my favorite website for RSS: Feedbin. The syncing works flawlessly. Both unread items and all the organization. In fact, the UI for organizing feeds is so nice in NetNewsWire that I managed everything there and was pleasantly surprised how it all synced perfectly with Feedbin.
Feedbin on the web
Who’s gonna read your personal blog because it has an RSS feed? I’m gonna read your personal blog because it has an RSS feed. pic.twitter.com/mtcyKhEVet
I know a lot of people miss Google Reader, but I think we’ve arrived at an even better place after all these years. The Google Reader UI for Google Reader was OK, but the main benefit was that it was the central place where everything synced together. That meant people could experiment by building readers and could use whatever they wanted. Feedbin clearly has APIs that can handle those types of things, so perhaps it could become that central hub service, which would be awesome.
I use Reeder on iOS, which also syncs with Feedbin. The central hub is real.
Reeder on iOS
I know a lot of people love Feedly too, which is also good. I just click with Feedbin better. I particularly like the Feedbin feature where it gives me an email address I can have newsletters sent to, letting me subscribe to a ton of them the same way I do with sites.
I edit a good amount of technical articles about the web, and there is a tendency for authors to be super broad in their opening sentence, like „What we’re able to do on the web has expanded greatly over the years.”
I tend to remove stuff like that because it usually doesn’t serve the article well, even though I understand the sentiment.
Just look at Luigi De Rosa’s list here. I’d bet a lot of you didn’t know the browser could do all that stuff — push notifications! Native sharing menus! Picture-in-picture!
It’s mostly JavaScript stuff, a little CSS, and notably absent: anything in HTML.
The answer used to be absolutely yes because, if you used px units, you prevented the text from being resized by the user at all.
But browser zoom is the default method for making everything bigger (including text) these days and it works great even if you use px.
But… Kathleen McMahon really digs into this and finds that it’s still worth setting all your type (both font-size and line-height) in relative units because:
setting type in px prevents browser settings from making font size adjustments (which some people definitely use) and
setting type in relative units maintains greater design fidelity as users use browser zoom (which a lot of people definitely use).
I’d like to think there is a lot to learn on CSS-Tricks. But we don’t really offer much by the way of courses. You’re probably reading this because you just generally read this site, and you land on CSS-Tricks otherwise mostly because you are looking for an answer to some front-end question.
Courses are a really great way to learn though. I’ve done many over my years as a developer, particularly when learning something fairly outside my bubble of things I already know. For example, I don’t reach for TypeScript yet because I don’t really know it and am definitely not comfortable with it. You better believe I’ll be taking a course on it when the time comes that I want to use it on a project.
Where will I find that course? Frontend masters, of course. They are clearly the most high-quality in-depth courses on all things front-end development. They’ve got a course on TypeScript, of course.
So I’m so so glad to announce that Frontend Masters is our official learning partner. I like having an official place to send people to when it’s clear their learning style is video courses, like so many people’s is.
One not-so-little aspect I love about Frontend Masters: the courses are taught in a live environment. So it’s not a head talking into a screen, the courses have the natural energy of a live teaching situation, because they are.
How you’ll see our course recommendations here on CSS-Tricks is through some contextual ads next to articles. Say you’re reading Geoff’s recent article about the dense keyword as part of CSS grid layout. Well, that article is about layout, and Frontend Masters has a comprehensive course on modern CSS layout from Jen Kramer. So as you scroll down that post, you’ll see our course recommendation there, as well as at the bottom of the article.
Try it free
Access to all of Frontend Masters is a paid membership. Access to literally everything they have is $39 a month or $390 a year, with special pricing for teams. But, they have some free stuff if you want to dip your toes and see for yourself if it’s any good.
I feel like this is worth mentioning too. Frontend Masters itself is a website you log into to watch the videos and that’s a great experience. But it’s not the only way. They also have great native mobile apps (iOS / Android), if you prefer that experience.
ol ol ul, ol ul ul, ol menu ul, ol dir ul,
ol ol menu, ol ul menu, ol menu menu, ol dir menu,
ol ol dir, ol ul dir, ol menu dir, ol dir dir,
ul ol ul, ul ul ul, ul menu ul, ul dir ul,
ul ol menu, ul ul menu, ul menu menu, ul dir menu,
ul ol dir, ul ul dir, ul menu dir, ul dir dir,
menu ol ul, menu ul ul, menu menu ul, menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir, menu ul dir, menu menu dir, menu dir dir,
dir ol ul, dir ul ul, dir menu ul, dir dir ul,
dir ol menu, dir ul menu, dir menu menu, dir dir menu,
dir ol dir, dir ul dir, dir menu dir, dir dir dir {
list-style-type: square;
}
Browser support is just starting to get there and polyfilling is hard, so we aren’t at day-to-day no-brainer use levels quite yet. I’d bet it’s not too far away.
I suspect it is not highly known that CSS can control how text is selected. You can do user-select: none; to prevent some text from being selected. That’s probably not terribly good UX in general, but perhaps you use some period (.) characters as decoration or something, I could see preventing those from being selected.
The exact opposite is user-select: all; which forces all the text to be selected in an element. Again, probably somewhat iffy UX. Forcing someone to select all the text is fairly rare on the web and to actively prevent someone from selecting a part of it feels like it’s trying too hard to be helpful to the point that it’s actually hurting.
If you wanted to implement a situation where you click once to highlight all then stop interfering, you could do that in JavaScript with an click handler than removes itself after the first click.
The word „microbrowser” clearly got my attention. Never heard that before. Colin Bendell defines them as the little parts of other software that do HTTP requests to a URL to generate a preview. Like the little URL preview in iOS messages, WhatsApp, or Slack.
I’m a tiny bit skeptical of the name, because what’s happening is the software making that HTTP request and parsing out a little data to use however it will. I’m not sure I’d call that a browser of any kind, but I take the point.
I agree that these things are mega important.
[…] the real gold for marketers is from word-of-mouth discussions. Those conversations with your friends when you recommend a TV show, a brand of clothing, or share a news report. This is the most valuable kind of marketing.
One of our yearly traditions here is to thank all y’all CSS-Tricks readers at the passing of a new year. It means a lot to me that people come here and read the words I write, and the words of all our staff and guest authors that contribute here as well.
Thank you!
Plus, we dig into the numbers this time of year. I’ve always tried to be open about the analytics on this site. Looking at them year after year always serves up a good reminder: niche blogging is a slow game. There’s no hockey-stick growth around here. Never has been, never will be. The trick is to build slowly over time, taking care of the site, investing in it, working hard, and with some luck, numbers trend upward. This year, overall traffic didn’t even do that. Sometimes you gotta fight for what you’ve got! Growth came in other areas though. Let’s take a gander.
It was January 1st, 2019 that the current design of this site (v17) debuted, so this entire year overlaps perfectly with that. I’ll certainly be tempted to release major iterations with that same timing in the future for comparison sake.
Overall numbers
Google Analytics is showing me 90.3 million pageviews, which is a bit of a decline from 2018 at over 91 million. A 1% decline. Not a big problem, but of course I’d way rather see a 1% increase instead. We’ll take that as a kick in the butt to produce a stronger year of content to hopefully more than win it back.
Looks like we published 726 articles over the year, which includes link posts and sponsored links. A good leap from 636 last year and 595 the year before that. Clearly quantity isn’t the trick to traffic for us.
I don’t know that we’ll slow down necessarily. I like the fact that we’re publishing multiple times a day with noteworthy links because I like to think of us as a timely industry publication that you can read like a daily or weekly newspaper in addition to being an evergreen reference. I don’t think we’ll invest in increasing volume, though. Quality moves the needle far more than quantity for this gang.
There is a bunch of numbers I just don’t feel like looking at this year. We’ve traditionally done stuff like what countries people are from, what browsers they use (Chrome-dominant), mobile usage (weirdly low), and things like that. This year, I just don’t care. This is a website. It’s for everyone in the world that cares to read it, in whatever country they are in and whatever browser they want to. We still track those numbers (because Google Analytics automatically does), so we can visit them again in the future and look historically if it gets interesting again. Taking a quick peak, however, it’s not much different than any other year.
Performance numbers are always fascinating. Google Analytics tells me the average page load time is 5.32s. On my fast home internet (even faster at the office), the homepage loads for me in 970ms, but it’s more like 30 seconds when throttled to „Slow 3G.” „Fast 3G” is 8 seconds. Sorta makes sense that most visitors are on faster-than-3G connections since the traffic is largely skewed toward desktop. No cache, we’re talking 54 requests (including ads) and 770KB (fits on a floppy). It’s good enough that I’m not itching to dig into a performance sprint.
Top posts of the year
You’d think we would do a section like this ever year, but because of our URL structure, I haven’t had easy access to figure this out. Fortunately, in March 2019, Jacob Worsøe helped us add some Custom Dimensions to our Google Analytics so we can track things like author and year with each pageview.
That means we can find things, like the most popular articles written in 2019, rather than just the most popular articles looked at in 2019 — regardless of when they were was written. Here’s a graph Jacob sent:
8.25% of traffic came from articles written this year. If you look at where these articles fall on the list of all URLs in 2019 (not just those published in 2019), the top article starts at #75! Hard to compete with older articles that have had time to gather SEO steam. This kind of thing makes me want to get re-focused on referential content even more.
Interesting that our top article was editorial, but everything else is referential. I like a little editorial here and there, but clearly our bread and butter is how-to technical stuff.
Search
There are two aspects of search that are interesting to me:
What do people search for right here on the site itself?
What search terms do people use on Google to find this site?
On-site search is handled by Jetpack’s Elasticsearch feature, which I’m still quite liking (they are a sponsor, but it’s very true). This also means we can track its usage pretty easily using the analytics on my WordPress.com dashboard. I also installed a Search Meter plugin to track search form entries. I can look at Google searches through the SiteKit plugin, which pulls from Google Search Console.
Here are all three, with duplicates removed.
Jetpack Search Data
Search Meter Search Data
Google Search Data
1
amazon (?!)
flexbox
flexbox
2
flexbox
grid
css grid
3
css tricks
flex
css tricks
4
flexbox guide
animation
css important
5
css grid
svg
css triangle
6
css flex
position
mailto link
7
grid guide
css grid
vertical align css
8
css important
css
css comment
9
the great divide
border
css shapes
10
css shapes
background
css background image opacity
There is a bit of a fat head of traffic here with our top 10 pages doing about 10% of traffic, which syncs up with those big searches for stuff like flexbox and grid and people landing on our great guides. If you look at our top 100 pages, that goes out to about 38% of traffic, and articles past that are about 0.1% of traffic and go down from there. So I’d say our long tail is our most valuable asset. That mass of articles, videos, snippets, threads, etc. that make up 62% of all traffic.
Social media
It’s always this time of year I realize how little social media does for our traffic and feel stupid for spending so much time on it. We pretty much only do Twitter and it accounts for 1% of the traffic to this site. We still have a Facebook page but it’s largely neglected except for auto-posting our own article links to it. I find value in Twitter, through listening in on industry conversations and having fun, but I’m going to make a concerted effort to spend less time and energy on our outgoing social media work. If something is worth tweeting for us, it should be worth blogging; and if we blog it, it can be auto-tweeted.
But by way of numbers, we went from 380k followers on @css to 430k. Solid growth there, but the rate of growth is the same every year, to the point it’s weirdly consistent.
I also picked up an Instagram account this year. Haven’t done much there, but I still like it. For us, I think each post on Instagram can represent this little opportunity to clearly explain an idea, which could ultimately turn into a nice referential book or the like someday. A paultry 1,389 followers there.
Newsletter
I quite like our newsletter. It’s this unique piece of writing that goes out each week and gives us a chance to say what we wanna say. It’s often a conglomeration of things we’ve posted to the site, so it’s an opportunity to stay caught up with the site, but even those internal links are posted with new commentary. Plus, we link out to other things that we may not mention on the site. And best of all, it typically has some fresh editorial that’s unique to the newsletter. The bulk of it is done by Robin, but we all chip in.
All that to say: I think it’s got a lot of potential and we’re definitely going to keep at it.
We had the biggest leap in subscribership ever this year, starting the year at 40k subscribers and ending at 65k. That’s 2.5× the biggest leap in year-over-year subscribers so far. I’d like to think that it’s because it’s a good newsletter, but also because it’s integrated into the site much better this year than it ever has been.
Comments
Oh, bittersweet comments. The bad news is that I feel like they get a little worse every year. There is more spam. People get a little nastier. I’m always teetering on the edge of just shutting them off. But then someone posts something really nice or really helpful and I’m reminded that we’re a community of developers and I love them again.
4,710 approved comments. Up quite a bit from 3,788 last year, but still down from 5,040 in 2017. Note that these are approved comments, and it’s notable that this entire year we’ve been on a system of hand-approving all comments before they go out. Last year, I estimated about half of comments make it through that, and this year I’d estimate it at more like 30-40%. So, the straight-up number of comments isn’t particularly interesting as it’s subject to our attitude on approval. Next year, I plan to have us be more strict than we’ve ever been on only approving very high-quality comments.
I’m still waiting for WordPress to swoon me with a recommitment to making commenting good again. 😉
Forums
There were a couple of weeks just in December where I literally shut down the forums. They’ve been teetering on end-of-life for years. The problem is that I don’t have time to tend to them myself, nor do I think it’s worth paying someone to do so, at least not now. Brass tacks, they don’t have any business value and I don’t extract enough other value out of them to rationalize spending time on them.
If they just sat there and were happy little forums, I’d just leave them alone, but the problem is spam. It was mostly spam toward the end, which is incredibly tedious to clean up and requires extra human work.
I’ve kicked them back on for now because I was informed about a spam-blocking plugin that apparently can do incredible work specifically for bbPress spam. Worth a shot!
Interestingly, over the year, the forums generated 7m pageviews, which is 7.6% of all traffic to the site. Sorta makes sense as they are the bulk of the site URLs and they are user-generated threads. Long tail.
Goal review
✅ Polish this new design. Mixed feelings. But I moved the site to a private GitHub repo half-way through the year, and there have been 195 commits since then, so obviously work is getting done. I’ll be leaving this design up all of 2020 and I’d like to make a more concerted effort at polish.
✅ Improve newsletter publishing and display. Nailed this one. In March, we moved authoring right here on the site using the new Gutenberg editor in WordPress. That means it’s easier to write while being much easier to display nicely on this site. Feels great.
☯️ Raise the bar on quality. I’m not marking it as a goal entirely met because I’m not sure we changed all that much. There was no obvious jump upward in quality, but I think we do pretty good in general and would like to see us continue to hold steady there.
❌ Better guides. We didn’t do all that much with guides. Part of the problem is that it’s a little confusing. For one thing, we have „guides” (e.g. our guide to flexbox) which is obviously useful and doing well. Then there are „Guide Collections” (e.g. our Custom Properties Guide) which are like hand-picked and hand-ordered selections of articles. I’m not entirely sure how useful those hand-curated guides are, especially considering we also have tag pages which are more sortable. The dudes with the biggest are the hand-written articles-on-steroids types, so that’s worth the most investment.
New goals
100k on email list. That would be a jump of 35k which is more than we’ve ever done. Ambitious. Part of this is that I’m tempted to try some stuff like paid advertising to grow it, so I can get a taste for that world. Didn’t Twitter have a special card where people could subscribe right from a Tweet? Stuff like that.
Two guides. The blog-post-on-steroids kind. The flexbox one does great for us, traffic-wise, but I also really enjoy this kind of creative output. I’ll be really sad if we can’t at least get two really good ones done this year.
Have an obvious focus on how-to referential technical content. This is related to the last goal, but goes for everyday publishing. I wouldn’t be mad if every darn article we published started with „How To.”
Get on Gutenberg. The new WordPress block editor. This is our most ambitious goal. Or at least I think it is. It’s the most unknown because I literally don’t know what issues we’re going to face when turning it on for more than a decade’s worth of content that’s been authored in the classic editor. I don’t think it’s going to hurt anything. It’s more a matter of making sure:
authoring posts has all the same functionality and conveniences as we have now,
editing old posts doesn’t require any manual conversion work, and
it feels worth doing.
But I haven’t even tried yet, so it’s a don’t-know-what-I-don’t-know situation.
Again, thanks so much!
I was thinking about how stage musicians do that thing where they thank their fans almost unfailingly. Across any genre. Even if they say hardly anything into a microphone during the performance, they will at least thank people for coming, if not absolutely gush appreciation at the crowd. It’s cliché, but it’s not disingenuous. I can imagine it’s genuinely touching to look out across a room of people that all choose to spend a slice of their lives listening to you do your thing.
I feel that way here. I can’t see you as easily as looking out over a room, but I feel it in the comments you post, the emails you send, the tweets you tagged us in, and all that. You’re spending some of your life with us and that makes me feel incredibly grateful. Cheers.
