[Chris]: Less than a year from now we’ll be celebrating the 10-year anniversary of responsive web design (RWD). The article that started it, from Ethan, was May 25, 2010.
A lot of stuff has had to shake out as a result. Technologically, responsive design has its fair share of challenges. Ways of building things that we had to re-learn. But we don’t think of them as burdens anymore, because a media query over here and a mustard cut over there might mean being able to delete an entire “mobile” codebase.
The bigger story with RWD was more institutional than technological. A fact not lost on the RWD podcast (RIP). RWD is just the standard way of building sites now, but a sea of people had to be convinced to get here, the organization of a slew of digital teams tossed into the blender along the way.
A side-effect was loads of conferences talking about what was going on. Some even entirely dedicated to that concept. One of which was Artifact Conference, put on by Jennifer Robbins and friends. We had to get together and think it all out. But now that RWD is all but locked in, what is a conference like Artficat to talk about? Well, we haven’t exactly solved all the problems on the web. I asked Jennifer to talk about Artficat from this perspective, and the result was a kind of advertorial for Artifact that tries to answer what does the web need now?
Is our work making the web better done? Not by a long shot! Now that we’ve got a handle on the low-bar requirement of getting something readable on all those screens, we can focus our energy on higher-order challenges. How do we make our sites work easier for people of all abilities? How do we make our content, products, and services welcoming to everyone? Does our code need to be so bloated and complicated? How can we make our sites simpler and faster? How can I put new tools like CSS Grid, Progressive Web Apps, static sites, and animation to good use?
? Links from around the web
- The Guardian Design System is certainly pretty neat. In this microsite about the team’s work, they show typesetting and color rules and how the grid can be used in a variety of interesting ways. This should make for inspiration for any design systems team.
- Here’s a dang good post by Brad Frost about React and front-end design. I especially like the bit where he argues that:
I’ve now worked in multiple React codebases that (to my eyes) are a tangle of business logic, presentational code, data-manipulating code, and other terrifying-looking forms of code wrapped up in an opaque file structure. Squint your eyes and you might find some HTML sprinkled in there somewhere. This is no doubt due to the implementation, but it’s overwhelming nonetheless.
- Rachel Andrew writes about CSS Lists, Markers, and Counters and how in browsers pretty soon we’ll be able to control the list marker (the bit that sits to the left of the list item itself):
The ::marker pseudo-element allows you to target the list marker — separately from the content of the list item. This was not possible in previous versions of CSS, therefore, if you changed the color or font size of the ul or li, this would also change the color and font size of the markers.
- Scott Jehl looks at the simplest way to load CSS asynchronously and I think it’s preposterously smart. Why should we load our CSS async and what does that really mean? Well, Scott explains it all like this:
One of the most impactful things we can do to improve page performance and resilience is to load CSS in a way that does not delay page rendering. That’s because by default, browsers will load external CSS synchronously—halting all page rendering while the CSS is downloaded and parsed—both of which incur potential delays. Of course, at least a portion of a site’s CSS should be loaded before the page should be allowed to start rendering, and to get that initial CSS to the browser immediately, we recommend inlining (or HTTP2 server-pushing) the CSS. For sites with a small amount of overall, that alone might be enough, but if the CSS is large (say, bigger than 15 to 20kb), it can help performance to split it up by priority. Once split, less-critical CSS should be loaded in the background—AKA asynchronously.
? From the Blog
Micro-frontends
This whole micro-frontend concept is kind of wild and experimental to me – in this post Chris takes a look at all the hubbub surrounding that term:
The idea really is that you might build a React app and I build a Vue app and we’ll slap ’em together on the same page. I definitely come from an era where we laughed-then-winced when we found sites that used multiple versions of jQuery on the same page, plus one thing that loaded all of MooTools and Prototype thrown on there seemingly by accident. We winced because that was a bucket full of JavaScript, mostly duplicated for no reason, causing bugs and slowing down the page. This doesn’t seem all that much different.
Lately I’ve struggled with a codebase that’s broken up into TypeScript, React, and Backbone and I’ve found that the advantages of having a cool new thing are lost entirely when compared to the complexity of having three competing codebases in the same environment. It causes a ton of confusion and so although I’ve never worked on a micro-frontend it sort of sounds like a complete nightmare to me at this point.
A Little Reminder that Pseudo Elements are Children, Kinda
Pseudo-elements are perhaps one of the most flexible wonderful tools we have as web designers and Chris reminds us that we can treat pseudo-elements as children. And by adding a pseudo-element Chrome’s DevTools will show it as if it was a child HTML element and Chris’s demo he shows how renders just like this:
But! There’s a lot of edge cases that are worth checking out because there are a lot of differences between magical pseudo-elements and HTML child elements.
Color Inputs: A Deep Dive into Cross-Browser Differences
When Ana Tudor says deep dive she truly means it because oh boy this post goes into everything about color inputs and all the difficulty you might have with them:
While it may seem exhaustive to dig this deep into one specific element, this is the sort of exercise that illustrates how difficult cross-browser support can be. We have our own styles, user agent styles and operating system styles to traverse and some of those are always going to be what they are. But, as we discussed at the very top, this winds up being an accessibility issue at the end of the day, and something to really consider when it comes to implementing a practical, functional application of a color input.
If you ever use the color input then it is most certainly worth checking out this post.
Netlify
Wow, Netlify is quickly becoming an indispensable part of the front-end stack. Just this past week, we announced the addition of Netlify Analytics, which provides useful (and not to mention gorgeous) traffic reports, and a beginner shared his journey getting a website live using Netlify as the host in place of traditional Apache-style servers. We even used it for our front-end conferences and serverless sites. We highly recommend checking it out for your own projects!
GraphQL Playgrounds
When I think of tools for playing with GraphQL, I immediately think of GraphiQL. It’s like the default “in-browser IDE for exploring GraphQL”. It’s useful as heck. But as you might suspect, it’s not the only kid on the block. Adebiyi Adedotun talks about GraphQL Playground, and using it with Gatsby. It does have a cleaner aesthetic for sure:
Also just recently came across FireQL which looks perhaps even nicer yet.
I particularly like how you can check checkboxes along the left to build your queries. The others have typeahead, which is nice, but sometimes it’s nice to just to see everything available in a list.
An Event Apart
What’s your career worth to you? If you’re like most of us, you’re too busy working to think about your career. But while you’re heads-down getting stuff done, the web races forward. How you can keep up and stay inspired? That’s where we come in. Level up your skills while learning from 17 brilliant speakers over 3 days of delightfully curated sessions.
- Washington DC (July 29-31)
- Chicago (August 26-28)
- Denver (October 28-30)
- San Francisco (December 9-11)
Check out the website for lots more information about this unmissable conference. Seattle was the last one I went to and there was so much to think about.
