This is a nifty visualisation by Hui Jing. It’s really handy to have elements categorised like this:
A few common gotchas when using BEM, and how to deal with them.
This is a really interesting approach that isn’t quite a CSS reset or a normalisation. Instead, it’s an experiment to reimagine what a default browser stylesheet would be like if it were created today, without concerns about backwards compatibility:
Applies basic styling to form elements and controls, getting you started with custom styling. We want to find the balance between providing a base for implementing a custom design, and allowing OS-level control over how form inputs work (like how a number pad works on iOS).
Provides a very lightweight starter file, with generic visual styling that you will want to replace. This isn’t as robust or opinionated as a starter-theme or framework. We’ve leaned toward specifying less, so you have less to override. (We haven’t defined any font families, for example.)
You can contribute by adding issues.
A good reminder from Chris—prompted by Scott O’Hara’s article—that the figcaption element and the alt attribute do different things. If you use an empty alt attribute on an img inside a figure, then your figcaption element is captioning nothing …and no, using the same text for both is not the solution.
A good look at the (over)use of the aria-label attribute that confirms the first rule of ARIA.
An ode for every element in the periodic table, in the form of a haiku.
This great post by Mandy ticks all my boxes! It’s a look at the combinatorial possibilities of some of the lesser-known HTML elements: abbr, cite, code, dfn, figure, figcaption, kbd, samp, and var.
You really don’t need jQuery any more …and that’s thanks to jQuery.
Here, the Github team talk through their process of swapping out jQuery for vanilla JavaScript, as well as their forays into web components (or at least the custom elements bit).
I love, love, love all the little details of HTML that Aaron offers up here. And I really like how he positions non-visual user-agents like searchbots, screen readers, and voice assisants as headless UIs.
HTML is a truly robust and expressive language that is often overlooked and undervalued, but it has the incredible potential to nurture conversations with our users without requiring a lot of effort on our part. Simply taking the time to code web pages well will enable our sites to speak to our customers like they speak to each other. Thinking about how our sites are experienced as headless interfaces now will set the stage for more natural interactions between the real world and the digital one.
I encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
A good explanation of web components, complete with some code examples.
Web Components are not a single technology. Instead, they are series of browser standards defined by the W3C allowing developers to build components in a way the browser can natively understand. These standards include:
- HTML Templates and Slots – Reusable HTML markup with entry points for user-specific markup
- Shadow DOM – DOM encapsulation for markup and styles
- Custom Elements – Defining named custom HTML elements with specific behaviour
Andy Bell is documenting is journey of getting to grips with web components. I think it’s so valuable to share like this as you’re learning, instead of waiting until you’ve learned it all—the fresh perspective is so useful!
I really like this month’s CodePen challenge, all about HTML elements that go well together. First up: del and ins.
A really deep dive into display: contents from Ire.
The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.
I love these kinds of deep dives into one seemingly simple pattern; in this case it’s a download link with the humble A element.
Move over, JavaScript alerts; HTML dialogs are here.
Ana goes into exhaustive detail on all the differences in the shadow DOM and styling of input type="range" across browsers.
I’m totally fine with browsers providing different styling for complex UI elements like this, but I wish they’d at least provide a consistent internal structure and therefore a consistent way of over-riding the default styles. Maybe then people wouldn’t be so quick to abandon native elements like this in favour building their own UI components from scratch—the kind of over-engineering that inevitably ends up being under-engineered.
In which Brian takes a long winding route through an explanation of why the is attribute for custom elements is dead before he demonstrates the correct way to use web components:
<!-- instead of writing this -->
<input type="radio" is="x-radio">
<!-- you write this -->
<x-radio>
<input type="radio">
</x-radio>
Sadly, none of the showcase examples I’ve seen for web components do this.