Amber runs through some HTML elements that help you provide semantic information—and accessibility—for your website: headings, paragraphs, lists, and more:
You may be aware that ARIA roles are often used with HTML elements. I haven’t written about them here, as it’s good to see how HTML written without ARIA can still be accessible.
Some solid research here. Turns out that using input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using input type="number".
Chris takes two side-by-side deep dives; one into the a element, the other into the button element.
Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the button element can have form over-riding attributes like formaction, formenctype, formmethod, formnovalidate, and formtarget?
At the risk of being a broken record; HTML really needs
<accordion>,<tabs>,<dialog>,<dropdown>, and<tooltip>elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements.
Hear, hear!
I wish browsers would prioritize accessibility improvements over things like main thread scheduling optimization to unblock tracking pixels and the Sisyphean task of competing with native.
If we really want to win, let’s make it easy for everyone to access the Web.
A one-stop shop for all the metacrap you can put in the head of your HTML documents.
Test your knowledge of the original version of HTML—how many elements can you name?
Some very smart ideas in here for resetting default browser styles, like only resetting lists that have classes applied to them:
ul[class],
ol[class] {
padding: 0;
}
I select only lists that do have a
classattribute because if a plain ol’<ul>or<ol>gets used, I want it to look like a list. A lot of resets, including my previous ones, aggressively remove that.
Greg has done a lot of research into developer frustrations with customising form controls.
My current thinking in this space, and I know some folks will find this controversial, but I think we should completely standardize in-page form controls with no limitations on their styling capabilities. What do I mean by in-page controls? I am referring to any form control or component that is rendered within the content process. This standardization would include the sub-parts and their related states and how these are exposed (probably through CSS psuedo classes or HTML attributes). This will enable the shadow-dom to be encapsulated while providing web developers with a consistent experience to adjust to match their brand and needs of their site/application.
What you see really is what you get. I like this style!
I’ll be in my bunk.
I’ve often said that the goal of a good library should be to make itself redundant. jQuery is the poster child for that, and this article points to web components as the way to standardise what’s already happening in JavaScript frameworks:
Remember when
document.querySelectorfirst got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.
The article goes on to give a good technical overview of custom elements, templates, and the Shadow DOM, but I was surprised to see it making reference to the is syntax for extending existing HTML elements—I’m pretty sure that that is, sadly, dead in the water.
Cassie posted a neat tiny lesson that she’s written a reduced test case for.
Here’s the situation…
CSS custom properties are fantastic. You can drop them in just about anywhere that a property takes a value.
Here’s an example of defining a custom property for a length:
:root {
--my-value: 1em;
}
Then I can use that anywhere I’d normally give something a length:
.my-element {
margin-bottom: var(--my-value);
}
I went a bit overboard with custom properties on the new Patterns Day site. I used them for colour values, font stacks, and spacing. Design tokens, I guess. They really come into their own when you combine them with media queries: you can update the values of the custom properties based on screen size …without having to redefine where those properties are applied. Also, they can be updated via JavaScript so they make for a great common language between CSS and JavaScript: you can define where they’re used in your CSS and then update their values in JavaScript, perhaps in response to user interaction.
But there are a few places where you can’t use custom properties. You can’t, for example, use them as part of a media query. This won’t work:
@media all and (min-width: var(--my-value)) {
...
}
You also can’t use them in generated content if the value is a number. This won’t work:
:root {
--number-value: 15;
}
.my-element::before {
content: var(--number-value);
}
Fair enough. Generated content in CSS is kind of a strange beast. Eric delivered an entire hour-long talk at An Event Apart in Seattle on generated content.
But Cassie found a workaround if the value you want to put into that content property is numeric. The CSS counter value is a kind of generated content—the numbers that appear in front of ordered list items. And you can control the value of those numbers from CSS.
CSS counters work kind of like variables. You name them and assign values to them using the counter-reset property:
.my-element {
counter-reset: mycounter 15;
}
You can then reference the value of mycounter in a content property using the counter value:
.my-element {
content: counter(mycounter);
}
Cassie realised that even though you can’t pass in a custom property directly to generated content, you can pass in a custom property to the counter-reset property. So you can do this:
:root {
--number-value: 15;
}
.my-element {
counter-reset: mycounter var(--number-value);
content: counter(mycounter);
}
In a roundabout way, this allows you to use a custom property for generated content!
I realise that the use cases are pretty narrow, but I can’t help but be impressed with the thinking behind this. Personally, I would’ve just read that generated content doesn’t accept custom properties and moved on. I would’ve given up quickly. But Cassie took a step back and found a creative pass-the-parcel solution to the problem.
I feel like this is a hack in the best sense of the word: a creatively improvised solution to a problem or limitation.
I was trying to display the numeric value stored in a CSS variable inside generated content… Turns out you can’t do that. But you can do this… codepen.io/cassie-codes/p… (not saying you should, but you could)
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).