Creating UI Components in SVG
Sarah wrote about all the exciting possibilities that open up when you learn about the intricacies of SVG:
Truly, once you learn SVG, you can draw anything, and have it scale on any device. Even this very site uses SVG for custom UI elements, such as my avatar, above (meta!)
Sarah then writes about how she built the Jamstack Explorers site where you can watch a video about a topic but then hop to different sections of the video and use a todo list interface to make that jump. Sarah walks through how to build this with SVG and also all of the accessibility things you need to know along the way.
There’s a lot of times when I sit down in front of a project and wonder whether something should be straight up HTML and CSS or SVG and I reckon I should spend a bit more time thinking that through. SVG is so gosh powerful that it’s easy to forget what it’s capable of at times.
Tailwind versus BEM
Eric Bailey wrote a great piece all about this controversy to end all controversies; which approach to CSS is better, Tailwind or BEM?
Well, Eric argues, it’s pretty complicated. He goes into a lot of details and the pros and cons of both techniques but there’s really no right answer here.
Here’s my take: my decision when it comes to CSS almost always comes down to scale. If I was building a relatively small website then I’d stick with BEM and maybe use Sass to help me do a few small things. If I was building something a bit more complicated then that and needed to churn out new little sites all the time without a close adherence to design mocks, then Tailwind would be a great solution there.
But anything more complicated and, well, both of them sort of breakdown in my experience. Tailwind doesn’t give you the customization needed to tweak design things just right (as it should’t) and BEM makes things complicated because you have this enormous global namespace where eight developers have created their own doodad called
My point here is that there isn’t one tried and trusted way of writing CSS that works in all circumstances for everyone. And that’s ok!
The Pens of Jackie Zen
Earlier today I was faffing about on CodePen, looking for inspiration, and I stumbled upon some of the animations that Jackie Zen has been making. Like this incredibly beautiful day/night cycle:
Or this wonderful Thanksgiving animation, where the subtle movement persists after the illustration has finished loading and animating:
Jackie’s work reminds me that animation on the web doesn’t just have to be about loading. We can add animations in all sorts of subtle ways that make the UI really pop and isn’t distracting. We just have to put a tiny bit more care and attention into these things to make them stand out. The smallest details can sometimes make the biggest difference.
DRY-ing up styled-components
Speaking of ideal CSS approaches, Allie Stehney just wrote about one of my biggest pet peeves when using styled-components. She writes:
[…] as I continue down the path of using styled-components, I have started to realize that, while it is great to separate out CSS styles to be specific to singular components, I am starting to repeat myself a lot for the sake of organizing my styles on a per component basis. I’ve been creating new CSS declarations, and thus, new styled-components, for every component, and am seeing a great deal of duplication in my CSS. No, the styled-components aren’t always exactly the same, but two of the three lines of CSS would match two of the three lines of CSS in another component. Do I really need to repeat this code every place I need these styles?
styled-components are great because you don’t need to worry about the naming conventions of regular ol’ BEM and CSS — if two engineers have the same
.nav class in two different files then it just doesn’t matter at all. But! The problem that styled-components creates is just as Allie says above, it creates this incentive not to reuse styles across components.
I feel like what this is all leading to is making the equivalent of Sass mixins and extends for styled-components. Maybe. Perhaps.
Making a Dynamically-Sized Sticky Sidebar
Ryan Mulligan made this really great demo where he created a checkout page where the selected items stick to the right hand side of the screen and you can add multiple items. That’s all pretty straight forward. But notice the pink part below, that’s potentially where the content might get cut off. And crucially, the two most important buttons on this page would then be hidden in the process.
And what happens when you add, say, fifty items to the cart? How to make sure that the bottom part — the checkout buttons especially — are visible at all times and on all screens? That’s the problem that Ryan tackles in this post.
Not so long ago, Léonie Watson wrote about the wonders of Web Monetization: a W3C standard that would let browsers pay for content and which “enables content creators to choose how to respond — by taking down a paywall, removing advertising, or revealing additional content for example.”
Léonie even goes as far to say that this stuff is “the vanguard of a quiet revolution.”
So this sure is exciting stuff! And there are services out there like Coil that are already taking advantage of this stuff. For example, with Coil, you can subscribe for $5 a month and that gets portioned out to the websites that have setup an account with Coil that you visit.
Chris wrote up his own thoughts about this stuff and what he finds so exciting about it all:
With the APIs, a site could say, “You’ll see no ads on this site if you pay us $1/month,” and then write code to make that happen all anonymously. That’s so cool. Removing ads is the most basic and obvious use case, and I hope some people give that a healthy try. I don’t do that on this site, because I think the tech isn’t quite there yet. I’d want to clearly be able to control the dollar-level of when you get that perk (you can’t control how much you give sites on Coil right now), but more importantly, in order to really make good on the promise of not delivering ads, you need to know very quickly if any given user is supporting you at the required level or not. For example, you can’t wait 2600 milliseconds to decide whether ads need to be requested. Well, you can, but you’ll hurt your ad revenue. And you can’t simply request the ads and hide them when you find out, lest you are not really making good on a promise, as trackers’n’stuff will have already done their thing.
Being able to turn features on and off if someone’s subscribed is certainly a neat idea. I can also see this being as helpful as something, like Substack, is to indie writers, too.
Exploring what the details and summary elements can do
The other day I had a hunch that the
<details> elements are actually much more useful than I had originally given them credit for, so I started making notes about how to use them.
One idea I had was to use them as footnotes, but that didn’t work out so well. But! One idea I had that did work out was using them to create tooltips, like this:
<details class="tooltip"> <summary>3 days ago</summary> <p>January 27th, 2020</p> </details>
That’s pretty nifty! I had always considered these elements to be used to create accordions but the next time I want to make a tooltip I’ll be sure to reach for these elements instead.
In this post about the spectrum of rendering websites, Chris breaks down the big categories into Client, Static, and Server and describes them like this:
- Client: ship a
- Static: pre-render the HTML.
- Server: let a live server process requests and generate the HTML response.
For a while now it seems like all performance advice has been to make everything static: during build time we should create a bunch of HTML files that the browser then requests. However, this means we have to forego the app-ness quality of a Single Page Application (SPA). But on this point, Chris writes:
There are a few interesting developments here that Chris points to that are worth reading about. And I get the feeling that if I could get that app-quality feeling of an SPA without having to use Gatsby or some other rather complicated setup then I’d happily do that.
Our digital learning platform offers digestible, on-demand courses. Develop makes it easy to learn the tech skills you need to build your career. Start today with our free courses – no credit card needed.
TODAY IS THE LAST DAY OF THIS HUGE SALE! Jetpack has a ton of amazing features for your self-hosted WordPress site. Extremely important stuff like a backup and restore system, a powerful instant search system, a CRM, and much more.
[Chris]: A comic from Rakhim Davletkaliyev:
There is no
alt text on it, so lemme try: a chart with a Y-axis of number of blog posts and an X-axis of number of blog posts about elaborate blog setups. The blogs with the most posts (and least posts about elaborate setups) is some 2004 WordPress blog and a weird dude who writes raw HTML. The blogs with the least posts (but most posts about elaborate blogging setups) are from authors of custom static site generators and the “my mobile git workflow” guy.
I used to poke Dave about this on ShopTalk Show sometimes (since I know he runs a Jekyll blog). While I find static site generators super cool, I (completely anecdotally) observe that people who use them to blog seemingly don’t blog that often. And I pair that with my own enjoying the WordPress publishing experience and how I think it helps me write more because it’s so easy, and this hits home for me.
But it’s not entirely fair. Dave actually blogs quite a bit. And since the comic specifically posts about static site generator creators, Zach, Eleventy’s creator, blogs quite a bit as well. Josh Comeau is on Gatsby and blogs quite a bit, even hands-free! Heck, Smashing Magazine is static. There are loads of counter examples.