I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.
A great introduction to structuring your content well:
The point of this post is to show how nicely container queries can play with web components, but I want to also point out how nice the design of the web component is here: instead of just using an empty custom element, Max uses progressive enhancement to elevate the markup within the custom element.
A curated list of awesome framework-agnostic standalone web components.
This is a great HTML boilerplate, with an explanation of every line.
I remember discussing this with Tantek years ago:
There are a few elements who need to be placed inside of another specific element in order to function properly.
If I recall, he was considering writing “HTML: The Good Parts”.
Anyway, I can relate to what Eric is saying here about web components. My take is that web components give developers a power that previous only browser makers had. That’s very liberating, but it should come with a commensurate weight of responsibility. I fear that we will see this power wielded without sufficient responsibility.
Receive one email a day for 30 days, each featuring at least one HTML element.
Right up my alley!
I’m very taken with Github’s tab-container element—this is exactly how I think web components should be designed!
A thorough deep dive into generated content in CSS.
A minimal style sheet that applies some simple rules to HTML elements so you can take a regular web page and drop in this CSS to spruce it up a bit.
You’re not going to get a Webby Award or thousands of views on Codepen for how amazingly crafted your HTML is. You’ll need to be OK going unrecognized for your work. But know that every time I use a screen reader or keyboard on a site and it works correctly, I have a little spark of joy.
Standardizing `select` And Beyond: The Past, Present And Future Of Native HTML Form Controls — Smashing Magazine
While a handful of form controls can be easily styled by CSS, like the button element, most form controls fall into a bucket of either requiring hacky CSS or are still unable to be styled at all by CSS.
Despite form controls no longer taking a style or technical dependency on the operating system and using modern rendering technology from the browser, developers are still unable to style some of the most used form control elements such as
select. The root of this problem lies in the way the specification was originally written for form controls back in 1995.
Stephanie goes back in time to tell the history of form controls on the web, and how that history has led to our current frustrations:
The current state of working with controls on the modern web is that countless developer hours are being lost to rewriting controls from scratch, as custom elements due to a lack of flexibility in customizability and extensibility of native form controls. This is a massive gap in the web platform and has been for years. Finally, something is being done about it.
I think this is quite beautiful—no need to view source; the style sheet is already in the document.
A really great one-page guide to HTML from Bruce. I like his performance-focused intro:
If your site is based on good HTML, it will load fast. Browsers incrementally render HTML—that is, they will display a partially downloaded web page to the user while the browser awaits the remaining files from the server.
Here, Brian proposes a kind of minimum viable web component that handles logic like keyboard control and accessibility, but leaves the styling practically untouched. Check out his panel-set demo of a tabbed interface.
I really, really like the way that it wraps existing content. If the web component fails for any reason, the content is still available. So the web component is a progressive enhancement:
An experimental custom element that wraps plain-old HTML (view the source) and decorates function, keyboard handling, accessibility information.
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct
autocompleteattributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
This is an excellent deep dive with great advice:
You may think that you are familiar with the basic
autocompleteoptions, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!
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
Chris takes two side-by-side deep dives; one into the
a element, the other into the
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
At the risk of being a broken record; HTML really needs
<tooltip>elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements.
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.