Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are:
Unsurprisingly, I completely and utterly agree with Ethan’s assessment here:
I’ve written some code that’s saying, “Once the screen is this size and the element appears in a different, smaller container, use a narrower layout on this element.”
But, well, that’s weird. Why can’t we apply styles based on the space available to the module we’re designing, rather than looking at the shape of the viewport?
I also share his frustration with the “math is hard; let’s go shopping” response from browser vendors:
There’s an incredible clamor for container queries, with folks from every corner of the responsive community asking for something that solves this problem. So personally, I’d love to see at least one browser vendor partner with the RICG, and get properly fired up about this.
We had to drag browser makers kicking and screaming to responsive images (to this day, Hixie maintains it’s not a problem that needs solving) and I suspect even more activism is going to be needed to get them to tackle container queries.
Dan describes his approach to maintainable CSS. It’s a nice balance between semantic naming and reusable styles.
Warning: the analogies used here might make you very, very hungry.
A comparison of a few different tools for generating pattern libraries.
In this particular case, Fractal comes out on top:
It has the features we need, and I’m happier than I should be with how simple the directory and file structure is. The documentation has also been super helpful thus far. We’ve customized it with our client’s branding and are ready to roll.
A look at the technical details behind Firefly’s pattern library. The tech stack includes Less, BEM, and some React, but it’s Anna and Danielle that really made it work.
Having spent half a decade encouraging people to make their pattern libraries public and doing my best to encourage openness and sharing, I find this kind of styleguide-shaming quite disheartening:
These all offer something different but more often than not they have something in common. They look ugly enough to have been designed by someone who enjoys configuring a router.
If a pattern library is intended to inspire, then make it inspiring. But if it’s intended to be an ever-changing codebase (made for and by the kind of people who enjoy configuring a router), then that’s where the effort and time should be concentrated.
But before designing anything—whether it’s a website or a pattern library—figure out who the audience is first.
Ethan has been thinking smarty-thinky thoughts about patterns and pattern libraries.
The styleguide, design principles, and pattern library for British Airways. It’s the “global experience language” for BA …so it’s called BAgel.
This quick dip into Fractal was in last month’s Net magazine.
It’s very gratifying to see how much Fractal is resonating with people—Mark has put so much hard work into it.
Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.
The video of Charlotte’s excellent pattern library talk that she presented yesterday in Berlin.
This is nice example of a web component that degrades gracefully—if custom elements aren’t supported, you still get the markdown content, just not converted to HTML.
<ah-markdown> ## Render some markdown! </ah-markdown>
A nicely-documented styleguide from Atlassian. It’s not a component library, though—there’s no code here.
I spoke my brains in this podcast episode, all about web components, progressive enhancement and backwards compatibility.
Alla looks at a few different ways of organising the contents of a pattern library, based on her experience with the FutureLearn team.