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.
Tuesday, July 6th, 2021
Monday, May 17th, 2021
It’s good to hear stories like this—makes me feel like the slow-burn of the theoretical benefits of web components is starting to spark and flame up.
Sunday, May 16th, 2021
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.
Tuesday, April 20th, 2021
A curated list of awesome framework-agnostic standalone web components.
Monday, April 19th, 2021
I really like the idea of a shared convention for styling web components with custom properties—feels like BEM meets microformats.
Tuesday, April 6th, 2021
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.
Sunday, March 7th, 2021
I’m very taken with Github’s tab-container element—this is exactly how I think web components should be designed!
Tuesday, December 15th, 2020
I was very inspired by something Terence Eden wrote on his blog last year. A report from the AMP Advisory Committee Meeting:
I don’t like AMP. I think that Google’s Accelerated Mobile Pages are a bad idea, poorly executed, and almost-certainly anti-competitive.
So, I decided to join the AC (Advisory Committee) for AMP.
Like Terence, I’m not a fan of Google AMP—my initially positive reaction to it soured over time as it became clear that Google were blackmailing publishers by privileging AMP pages in Google Search. But all I ever did was bitch and moan about it on my website. Terence actually did something.
So this year I put myself forward as a candidate for the AMP advisory committee. I have no idea how the election process works (or who does the voting) but thanks to whoever voted for me. I’m now a member of the AMP advisory committee. If you look at that blog post announcing the election results, you’ll see the brief blurb from everyone who was voted in. Most of them are positively bullish on AMP. Mine is not:
Jeremy Keith is a writer and web developer dedicated to an open web. He is concerned that AMP is being unfairly privileged by Google’s search engine instead of competing on its own merits.
The good news is that main beef with AMP is already being dealt with. I wanted exactly what Terence said:
My recommendation is that Google stop requiring that organisations use Google’s proprietary mark-up in order to benefit from Google’s promotion.
That’s happening as of May of this year. Just as well—the AMP advisory committee have absolutely zero influence on Google search. I’m not sure how much influence we have at all really.
This is an interesting time for AMP …whatever AMP is.
See, that’s been a problem with Google AMP from the start. There are multiple defintions of what AMP is. At the outset, it seemed pretty straightforward. AMP is a format. It has a doctype and rules that you have to meet in order to be “valid” AMP. Part of that ruleset involved eschewing HTML elements like
video in favour of web components like
That messaging changed over time. We were told that AMP is the collection of web components. If that’s the case, then I have no problem at all with AMP. People are free to use the components or not. And if the project produces performant accessible web components, then that’s great!
But right now it’s not at all clear which AMP people are talking about, even in the advisory committee. When we discuss improving AMP, do we mean the individual components or the set of rules that qualify an AMP page being “valid”?
The use-case for AMP-the-format (as opposed to AMP-the-library-of-components) was pretty clear. If you were a publisher and you wanted to appear in the top stories carousel in Google search, you had to publish using AMP. Just using the components wasn’t enough. Your pages had to be validated as AMP-the-format.
That’s no longer the case. From May, pages that are fast enough will qualify for the top stories carousel. What will publishers do then? Will they still maintain separate AMP-the-format pages? Time will tell.
I suspect publishers will ditch AMP-the-format, although it probably won’t happen overnight. I don’t think anyone likes being blackmailed by a search engine:
An engineer at a major news publication who asked not to be named because the publisher had not authorized an interview said Google’s size is what led publishers to use AMP.
The pre-rendering (along with the lightning bolt) that happens for AMP pages in Google search might be a reason for publishers to maintain their separate AMP-the-format pages. But I suspect publishers don’t actually think the benefits of pre-rendering outweigh the costs: pre-rendered AMP-the-format pages are served from Google’s servers with a Google URL. If anything, I think that publishers will look forward to having the best of both worlds—having their pages appear in the top stories carousel, but not having their pages hijacked by Google’s so-called-cache.
Does AMP-the-format even have a future without Google search propping it up? I hope not. I think it would make everything much clearer if AMP-the-format went away, leaving AMP-the-collection-of-components. We’d finally see these components being evaluated on their own merits—usefulness, performance, accessibility—without unfair interference.
So my role on the advisory committee so far has been to push for clarification on what we’re supposed to be advising on.
I think it’s good that I’m on the advisory committee, although I imagine my opinions could easily be be dismissed given my public record of dissent. I may well be fooling myself though, like those people who go to work at Facebook and try to justify it by saying they can accomplish more from inside than outside (or whatever else they tell themselves to sleep at night).
The topic I’ve volunteered to help with is somewhat existential in nature: what even is AMP? I’m happy to spend some time on that. I think it’ll be good for everyone to try to get that sorted, regardless about how you feel about the AMP project.
I have no intention of giving any of my unpaid labour towards the actual components themselves. I know AMP is theoretically open source now, but let’s face it, it’ll always be perceived as a Google-led project so Google can pay people to work on it.
That said, I’ve also recently joined a web components community group that Lea instigated. Remember she wrote that great blog post recently about the failed promise of web components? I’m not sure how much I can contribute to the group (maybe some meta-advice on the nature of good design principles?) but at the very least I can serve as a bridge between the community group and the AMP advisory committee.
After all, AMP is a collection of web components. Maybe.
Thursday, September 24th, 2020
A spot-on summary of where we’ve ended up with web components.
Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers.
Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.
Alas, that’s true. Lea wonders how this can be fixed:
I’m not sure if this is a design issue, or a documentation issue.
I worry that is a cultural issue.
Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.
Thursday, April 30th, 2020
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.
Wednesday, July 24th, 2019
This post was originally written in 2015, but upon re-reading it today, it still (just about) holds up, so I finally hit publish.
Tuesday, June 11th, 2019
A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):
I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?
Thursday, May 2nd, 2019
The bait’n’switch is laid bare. First, AMP is positioned as a separate format. Then, only AMP pages are allowed ranking in the top stories carousel. Now, let’s pretend none of that ever happened and act as though AMP is just another framework. Oh, and those separate AMP pages that you made? Turns out that was all just “transitional” and you’re supposed to make your entire site in AMP now.
I would genuinely love to know how the Polymer team at Google feel about this pivot. Everything claimed in this blog post about AMP is actually true of Polymer (and other libraries of web components that don’t have the luxury of bribing developers with SEO ranking).
Some alternative facts from the introduction:
AMP isn’t another “channel” or “format” that’s somehow not the web.
Weird …because that’s exactly how it was sold to us (as a direct competitor to similar offerings from Apple and Facebook).
It’s not an SEO thing.
That it outright false. Ask any company actually using AMP why they use it.
It’s not a replacement for HTML.
And yet, the article goes on to try convince you to replace HTML with AMP.
Tuesday, April 16th, 2019
Wednesday, April 10th, 2019
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.
Thursday, April 4th, 2019
This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).
Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset
Saturday, February 23rd, 2019
Saturday, December 29th, 2018
Sunday, September 9th, 2018
You really don’t need jQuery any more …and that’s thanks to jQuery.
Thursday, August 16th, 2018
A step-by-step guide to wrapping up a self-contained bit of functionality (a camera, in this case) into a web component.
Mind you, it would be nice if there were some thought given to fallbacks, like say:
<simple-camera> <input type="file" accept="image/*"> </simple-camera>