? A Note on Responsible JavaScript from Robin
Jeremy Wagner’s first post for A List Apart all about responsible JavaScript is wonderful and I think the whole article is quote-worthy, but this part, in particular, had me applauding on the train this morning:
What we tend to forget is that the environment websites and web apps occupy is one and the same. Both are subject to the same environmental pressures that the large gradient of networks and devices impose. Those constraints don’t suddenly vanish when we decide to call what we build “apps”, nor do our users’ phones gain magical new powers when we do so.
It’s our responsibility to evaluate who uses what we make, and accept that the conditions under which they access the internet can be different than what we’ve assumed. We need to know the purpose we’re trying to serve, and only then can we build something that admirably serves that purpose—even if it isn’t exciting to build.
That means reassessing our reliance on JavaScript and how the use of it—particularly to the exclusion of HTML and CSS—can tempt us to adopt unsustainable patterns which harm performance and accessibility.
I think this sort of thinking has even started to bleed into my own way of talking about websites. At Gusto, I care much more about performance on our website than I do the performance of our giant web app and I wonder how much of this is because of what I’ve picked up from others in the community.
As Jeremy argues, the difference doesn’t really exist for our users; they’re accessing both giant monolith web apps and tiny websites on the very same devices. The difference between them is one that we’ve created.
There are two more points that I’d like to highlight here. The first is when Jeremy points out that “there’s a certain amount of code you can never optimize away” when you choose to build a single page web app. I really love this idea – that you basically have to be willing to make that sacrifice when making that decision. The second point is where Jeremy writes specifically about CSS:
Most layout issues JavaScript packages attempt to solve, like box placement, alignment, and sizing, managing text overflow, and even entire layout systems, are solvable with CSS today. Modern layout engines like Flexbox and Grid are supported well enough that we shouldn’t need to start a project with any layout framework. CSS is the framework.
Gosh, I love this so much. But I think it’s important to note just how much CSS has changed recently – and it appears to be accelerating each year, too. The sheer number of CSS features that we now have at our fingertips is baffling, even compared to just a few years ago. The framework expands.
Rachel Andrew has argued consistently that we need to stop treating CSS like a joke. CSS is a language that’s stood the test of the time and so many of its early flaws or gaps in its design have been fixed. I think the way we start writing responsible JavaScript is by caring deeply about, and standing up for, CSS as a language.
? Highlights from the Blog
CSS Houdini Could Change the Way We Write and Manage CSS: Yangguang Li is super excited about Houdini and this post dives deep into all of the reasons why. From how easy it is to use to making us write code efficiently , there’s a lot to get excited about:
CSS Houdini may be the most exciting development in CSS. Houdini is comprised of a number of separate APIs, each shipping to browsers separately, and some that have already shipped (here’s the browser support). The Paint API is one of them. I’m very excited about it and recently started to think about how I can use it in my work.
One way I’ve been able to do that is to use it as a way to avoid reinventing the wheel.
Yangguang thinks a possible future for Houdini is almost like npm packages. Need specific styling? Import it.
A Gutenberg-Powered Newsletter: Chris shows how we publish this very email newsletter with the new WordPress editor (aka Gutenberg) and how we get that to sync up with Mailchimp via our RSS feed.
Robin: I can’t speak for the accessibility issues around Gutenberg but I think it’s one of the easiest and intuitive interfaces I’ve ever used to write with on the web. There’s an awful lot of competition for “best interface to write with on the web” and yet Gutenberg is right up there with the best of them for me.
Chris: One feature that I love that Gutenberg has, that I’ve gotten used to with Dropbox Paper as well: when you have a URL on your
Breaking CSS Custom Properties out of :root Might Be a Good Idea: This one is super interesting because I’ve almost always set custom properties on the :root before I start using them in my CSS. However, Kevin Powell argues that using the global scope for our custom properties could be a bad idea:
With CSS pre-processors, like Sass and Less, most of us keep variables tucked away in a partial dedicated to them. That works great, so why should we consider locally scoping variables all of a sudden?
One reason is that some people might find themselves doing something like this
:root {
--clr-light: #ededed;
--clr-dark: #333;
--clr-accent: #EFF;
--ff-heading: 'Roboto', sans-serif;
--ff-body: 'Merriweather', serif;
--fw-heading: 700;
--fw-body: 300;
--fs-h1: 5rem;
--fs-h2: 3.25rem;
--fs-h3: 2.75rem;
--fs-h4: 1.75rem;
--fs-body: 1.125rem;
--line-height: 1.55;
--font-color: var(--clr-light);
--navbar-bg-color: var(--clr-dark);
--navbar-logo-color: var(--clr-accent);
--navbar-border: thin var(--clr-accent) solid;
--navbar-font-size: .8rem;
--header-color: var(--clr-accent);
--header-shadow: 2px 3px 4px rgba(200,200,0,.25);
--pullquote-border: 5px solid var(--clr-light);
--link-fg: var(--clr-dark);
--link-bg: var(--clr-light);
--link-fg-hover: var(--clr-dark);
--link-bg-hover: var(--clr-accent);
--transition: 250ms ease-out;
--shadow: 2px 5px 20px rgba(0, 0, 0, .2);
--gradient: linear-gradient(60deg, red, green, blue, yellow);
--button-small: .75rem;
--button-default: 1rem;
--button-large: 1.5rem;
}Sure, this gives us one place where we can manage styling with custom properties. But, why do we need to define my
--header-coloror--header-shadowin my:root? These aren’t global properties, I’m clearly using them in my header and no where else.
Although I’ve typically
An Illustrated (and Musical) Guide to Map, Reduce, and Filter Array Methods: Una Kravets walks through some of the most useful JavaScript methods to get started manipulating and transforming data. Una’s illustrations are a pretty nifty way of helping us get a good understanding of what’s going on:
Or take this one that shows how the filter method works:
Jetpack
Jetpack brings a whole range of features to your self-hosted WordPress site. From realtime backups that keep your site safe (and make it easy to move!) to improved search results. From related posts to social media integration – it’s a no-brainer plugin for people serious about making their sites better.
Seriously, we love Jetpack here at CSS-Tricks and rely on it for lots of stuff. Heck, this newsletter is powered by the Gutenberg block editor in WordPress and Jetpack has a number of Gutenberg blocks at the ready, from map embeds and markdown editing to form elements and PayPal integrations, among many, many others. Give Jetpack a try and take advantage of everything it offers to make content management in WordPress even easier!