152 - CSS-Tricks - CSS-Tricks

[Robin]: This week I read a post by Pete Lambert about how HTML is the Web and I think he captured a ton of thoughts that have been floating around in my noggin’ over the past couple of months:

My big concern is at the bottom of that technology pyramid. The lowest common denominator of the Web. The foundation. The rhythm section. The ladyfingers in the Web trifle. It’s the HTML. And it is becoming increasingly clear to me that there’s a whole swathe of Frontend Engineers who don’t know or understand the frontend-est of frontend technologies.

I’ve experienced the same level of anxiety on a lot of teams over the years where I’ve come across a distinct lack of front-end experience which leads to problems in the future, whether that’s performance, accessibility, or design quality. And a couple of months ago that frustration led me to question why so many folks see front-end development as a problem to be solved. Instead, I argued, front-end development is a series of misunderstood skills that won’t go away because of tool X, Y, or Z:

I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.

That’s not to say that I think we should write HTML well because we’re artisans or crafts-folk, but because it means the difference between someone being able to use our websites and someone who is effectively cut off from great expanses of the web. And I think Andy Bell said it best when he argued that whenever we’re working on a project we should remember to keep things simple:

One thing that is often forgotten about accessibility is that keeping things simple and utilising semantic HTML gets you most of the way towards providing a fully accessible experience for everyone. ARIA, CSS and JavaScript are great for enhancing what we already get with semantic HTML and you don’t have to use much of it at all if you do use well-structured, semantic HTML as your base. Even when you apply CSS and JavaScript, keeping the code as simple as possible will reduce risk that is very often created by complexity.
Throwing ARIA roles and heaps of JavaScript at non-semantic HTML (read: div soup) might well make your site or app technically accessible—especially in terms of automatic testing, but you must ask yourselves at what cost? Also ask yourselves who are you prioritising? Is it the developers or the users?

There’s a common thread between all these posts and it’s this: writing good HTML is really a form of kindness. Caring about small chunks of markup and arguing over whether we should use a p tag or a div isn’t technical infighting or political jousting. We’re arguing about these details because they matter.

We write HTML because we care for the people that use our websites. And the more we care for the markup the better our websites will become, sure. They’ll be faster and easier to read. They’ll be used by more folks and it might increase our revenue.

We should write good HTML because it’s the kindest thing to do – not because it is economically better for us all, but because it is kind.

On a similar note, there’s another piece that had me thinking through this stuff too – Kelly Sutton’s wonderful and heart-breaking note about empathy in software design. Kelly describes how an edge-case in a dorm-room assignment system led to this enormous amount of pain that he finds difficult to describe. It’s worth reading that post in its entirety as I don’t really want to spoil it.

But all of these folks writing about HTML and empathy in software design got me thinking that when folks like Andy or Pete or Rachel or Jeremy or Lindsey or Ire talk about accessibility, and HTML specifically, what they’re all arguing for is for us all to be kind.

They’re arguing that writing bad HTML is a failure of empathy; it’s a failure to see what the web is truly capable of – and that by writing good HTML we care for everyone on the web, regardless of what browser, device, situation or environment they might happen to be in.

And so taking five minutes out of our day to think about whether something should be a div or another property is not going to change the world, sure. Okay. That’s fine. But it’s a mark of how we can care for other people.

Even if it’s a tiny component or a single line of HTML, every line of semantic markup adds up to something much bigger and more beautiful than we could possibly expect to see; a kinder web, made for us all.

SPONSOR

Bugherd

Spend less time discussing bugs and changes. BugHerd pins feedback and bugs directly to the page you’re working on. It’s like using sticky notes on a website. Try free today.

From the Blog

Daniel Tonon has written a blockbuster of a piece called How to Section your HTML which expertly documents a lot of HTML patterns that we should most certainly learn about if we want to ensure that our interfaces are as accessible as possible.

There’s a lot of great Do’s and Don’ts in here that were new and interesting to me. Take this note about the use of the nav element for instance:

…adding “navigation” to the label of a <nav> element only results in a screen reader saying “navigation” twice.

<nav aria-label="primary navigation">
  <!-- Screen reader: "primary navigation navigation landmark" -->
</nav>

<nav aria-label="primary">
  <!-- Screen reader: "primary navigation landmark" -->
</nav>

Huh! I’ve never used aria-label="primary" before and so this is pretty dang useful stuff as I get started work on a big accessibility project soon.

Stay tuned for an update on this article as well. Based on some on-going feedback we’re going to revise it a bit and make it the best it can be.

.matches()

Šime Vidas has his weekly breakdown of platform news and the one thing that piqued my interest was that DOM elements have a .matches method that can be used like this:

el.classList.contains('foo')  /* becomes */ el.matches('.foo');
el.hasAttribute('hello')      /* becomes */ el.matches('[hello]');
el.id === 'bar'               /* becomes */ el.matches('#bar');

SPONSOR

Buddy

Automate website delivery with the fastest deployment tool ever made. Compile CSS, run Gulp tasks, bundle assets with webpack, build Docker images, and deploy to server – all on a single push to Git. We like to think of it as 15 minutes to automation nirvana.

Try Buddy today for free →

Reduced Motion <picture> Technique, Take Two

First, you might as well take advantage of video-as-img if the browser supports it:

Then, rather than force someone who has indicated the prefer reduced motion to never be able to see the animation ever, we can add a button to toggle the animation on as necessary. See the whole writeup here.

Gutenberg is a React application

We write this very newsletter you’re reading in Gutenberg, so we’re always keen on staying up to date with Gutenberg-related news. We have a whole guide on building custom blocks, ya know. When you build blocks yourself in Gutenberg, you’ll be working with React and dealing with the WordPress data store. Ali Alaa talked about that this week in the article Managing WordPress Metadata in Gutenberg Using a Sidebar Plugin. The WordPress data store is apparently very Redux-like, so you’ll be dispatching data updates and such.

Data or application states in this React application are stored in centralized JavaScript objects, or “stores.” These stores are managed by WordPress’ data module. This module shares a lot of core principles with Redux. So, concepts like stores, reducers, actions, action creators, etc., also exist in this module.

Speaking of managing state in React, Kingsley wrote about doing it with Unstated-Next.

At a higher level, the whole idea of working with components is just a damn fine idea and seems to have locked itself in as the way to build for the web.