Journal

From 2015: Alla Kholmatova reflects on the difficulty in choosing between molecule or organism when categorising components using atomic design at FutureLearn. She also provides some handy insights into how they handled it.

When thinking about complexity of elements, it helps viewing molecules as “helpers” and organisms as “standalone” modules.

Whereas helpers can’t really exist on their own, standalone modules can.

Alla also recommends than in cases where an element doesn’t clearly fall into either group, asking the following questions may help:

• Is this more of a supporting element or a standalone one?
• Would it normally be part of something else and be reused within various components? (if so it’s probably a molecule)
• Is it a well defined and relatively independent part or section of a page? (if so it’s probably an organism)

(via @jamesmockett)

Kicking off with an unreleased interlude by yours truly, it covers various shades of techno and electro from artists including @tapesjamaican, @pearsonsound, @reedalerise, @datashat, @legowelt-official, @cygnus and more.

Lovely mix of mellow electro and techno vibes by my friend Tom.

Last time I tried Source Code Pro as my monospaced typeface for code examples in blog posts, it didn’t work out. When viewed in Firefox it would only render in black meaning that I couldn’t display it in white on black for blocks of code. This led to me conceding defeat and using something simpler.

It now looks like I can try Source Code Pro again because the issue has been resolved. This is great news!

So, I should grab the latest release and give it another go. Actually, for optimum subsetting and performance I reckon in this case I can just download the default files from Source Code Pro on Google Webfonts Helper and that’ll give me the lightweight woff2 file I need.

I’d also mentioned the other day that I was planning to give Source Serif another bash so if everything works out, with these two allied to my existing Source Sans Pro I could have a nice complimentary set.

An excellent article from Brad Frost in which he gives us some vocabulary for separating context-agnostic components intended for maximal use from specific variants and one-offs.

In light of some recent conversations at work, this was in equal measure interesting, reassuring, and thought-provoking.

On the surface, a design system and process can seem generally intuitive but in reality every couple of weeks might throw up practical dilemmas for engineers. For example:

• this new thing should be a component in programming terms but is it a Design System component?
• is everyone aware that component has a different meaning in programming terms (think WebComponent, ViewComponent, React.Component) than in design system terms? Or do we need to talk about that?
• With this difference in meaning, do we maybe need to all be more careful with that word component and perhaps define its meaning in Design Systems terms a bit better, including its boundaries?
• should we enshrine a rule that even though something might be appropriate to be built as a component in programming terms under-the-hood, if it’s not a reusable thing then it doesn’t also need to be a Design System component?
• isn’t it better for components to be really simple because the less opinionated one is, the more reusable it is, therefore the more we can build things by composition?

When I read Brad’s article last night it kind of felt like it was speaking to many of those questions directly!

Some key points he makes:

• If in doubt: everything should be a component
• The key thing is that the only ones you should designate as “Design System Components” are the ones for maximal reuse which are content and context-agnostic.
• After that you have 1) Recipes—specific variants which are composed of existing stuff for a specific purpose rather than being context-agnostic; and 2) Snowflakes (the one-offs).

Then there was this part that actually felt like it could be talking directly to my team given the work we have been doing on the technical implementation details of our Card recently:

This structure embraces the notion of composition. In our design systems, our Card components are incredibly basic. They are basically boxes that have slots for a CardHeader, CardBody, and CardFooter.

We’ve been paring things back in exactly the same way and it was nice to get this reassurance we are on the right track.

(via @jamesmockett)

Chris Coyier takes the new CSS aspect-ratio property for a spin and tests how it works in different scenarios.

Note that he’s applying it here to elements which do not have an intrinsic aspect-ratio. So, think a container element (div or whatever is appropriate) rather than an img. This is line with a Jen’s Simmons’ recent replies to me when I asked her whether or not we should apply aspect-ratio to an img after she announced support for aspect-ratio in Safari Technical Preview 118.

A couple of interesting points I took from Chris’s article:

• this simple new means of declaring aspect-ratio should soon hopefully supersede all the previous DIY techniques;
• if you apply a CSS aspect-ratio to an element which has no explicit width set, we still get the effect because the element’s auto (rendered) width is used, then by combining that with the CSS aspect-ratio the browser can calculate the required height, then apply that height;
• if the content would break out of the target aspect-ratio box, then the element will expand to accommodate the content (which is nice). If you ever need to override this you can by applying min-height: 0;
• if the element has either a height or a width set, the other of the two is calculated from the aspect ratio;
• if the element has both a height and width set, aspect-ratio is ignored.

Regarding browser support: at the time of writing aspect-ratio is supported in Chrome and Edge (but not IE), is coming in Firefox and Safari, but as yet there’s no word regarding mobile. So I’d want to use it as a progressive enhancement rather than for something mission critical.

Here’s Chris Ferdinandi’s curated list of organisations which use vanilla JS to build websites and web apps.

You don’t need a heavyweight JavaScript framework, and vanilla JS does scale.

At the time of writing the list includes Marks & Spencer, Selfridges, Basecamp and GitHub.

(via @ChrisFerdinandi)

Great DJ mix by one of my favourite electronic producers, Datassette.

This mix is all about that 160bpm+ energy that first inspired me to make music. Around 1996 — to me at least, with the advantages of teenage naîvety — it seemed like electronic music had burst into a whole new tempo range, where there were no rules and anything was possible - as long as it BELTS (which is still true). If you go beyond 200 BPM, you reach that zone where 16th notes start to dissolve into 32nds and your brain latches onto a whole new outer layer of rhythm, like a fractal or temporal shepard tone. There is still much to be discovered!

I listened to this one while walking through the Glasgow Necropolis during one of those eerily-quiet Covid-era days, and it provided a welcome shock to the system.

Here’s a nice demo page for Source Serif 4 which illustrates its versatility.

Source Serif is an open-source typeface for setting text in many sizes, weights, and languages. The design of Source Serif represents a contemporary interpretation of the transitional typefaces of Pierre-Simon Fournier. Additionally, Source Serif has been conceived as a friendly companion to Paul D. Hunt’s Source Sans.

Back when I first started using Source Sans Pro for text for my personal website, I tried pairing it with Source Serif for headings. It didn’t quite work for me then but the typeface seems to have undergone some changes in the interim and also now comes with a variable font option. I might give it another spin.

Being’s Broxburn Funk arrived in today’s post and it’s a thing of beauty.

Enjoying it now with a ☕️. Amazing work all round—music, sound, artwork, the lot. Big up @WeeDjs for the stellar tunes and if @firecracker_rec’s 50th is their last, then they’ve finished with a bang.

Grab a copy at Rubadub

Here’s Andy Bell recommending using CSS clamp() to control your wrapper/container width because it supports setting a preferred value in vw to ensure sensible gutters combined with a maximum tolerance in rem—all in a single line of code.

If we use clamp() to use a viewport unit as the ideal and use what we would previously use as the max-width as the clamp’s maximum value, we get a much more flexible setup.

The code looks like this:

.container {
  width: clamp(16rem, 90vw, 70rem);
  margin-left: auto;
  margin-right: auto;
}

This is pretty cool because I know from experience that coding responsive solutions for wrappers can be tricky and you can end up with a complex arrangement of max-width and media queries whilst still—as Andy highlights—not providing optimal readability for medium-sized viewports.

Using CSS Grid with minmax() is one possible approach to controlling wrappers however this article offers another (potentially better) tool for your kit.

It’s worth noting that Andy could probably have just used width: min(90vw, 70rem) here (as Christopher suggested) because setting the lower bound provided by clamp() is only necessary if your element is likely to shrink unexpectedly and a regular block-level element wouldn’t do that. The clamp approach might be handy for flex items, though.

(via @piccalilli_)