Garrett talks through some handy HTML attributes: spellcheck, autofocus, autocapitalize, autocomplete, and autocorrect:
While they feel like small details, when we set these attributes on inputs, we streamline things for visitors while also guiding the browser on when it should just get out of the way.
Here’s a nice HTML web component that uses structured data in the markup to populate a Leaflet map.
Personally I’d probably use microformats rather than microdata, but the princple is the same: progressive enhancement from plain old HTML to an interactive map.
This looks like a handy collection of HTML web components for common interface patterns.
drab does not use the shadow DOM, so you can style content within these elements as usual with CSS.
Scott has written a perfect description of HTML web components:
They are custom elements that
- are not empty, and instead contain functional HTML from the start,
- receive some amount of progressive enhancement using the Web Components JavaScript lifecycle, and
- do not rely on that JavaScript to run for their basic content or functionality.
The main reason I’m so hot on Light DOM is that I find the styling story of Web Components using Shadow DOM annoying.
I’ve written quite a bit about how I’d like to see a declarative version of the Web Share API. My current proposal involves extending the type attribute on the button element to support a value of “share”.
Well, maybe a different attribute will end up accomplishing what I want! Check out the explainer for the “invokers” proposal over on Open UI. The idea is to extend the button element with a few more attributes.
The initial work revolves around declaratively opening and closing a dialog, which is an excellent use case and definitely where the effort should be focused to begin with.
But there’s also investigation underway into how this could be away to provide a declarative way of invoking JavaScript APIs. The initial proposal is already discussing the fullscreen API, and how it might be invoked like this:
button invoketarget="toggleFullsceen"
They’re also looking into a copy-to-clipboard action. It’s not much of a stretch to go from that to:
button invoketarget="share"
Remember, these are APIs that require a user interaction anyway so extending the button element makes a lot of sense.
I’ll be watching this proposal keenly. I’d love to see some of these JavaScript cowpaths paved with a nice smooth coating of declarative goodness.
Here’s a good walkthrough of adding microformats to your site, starting with h-card and moving on to h-entry.
This is an interesting idea from Scott—a templating language that doesn’t just replace variables with values, but keeps the original variable names in there too.
Not sure how I feel about using data- attributes for this though; as far as I know, they’re intended to be site-specific, not for cross-site solutions like this.
Huh! I did not know this. Good to know!
This is a really interesting proposal, and I have thoughts.
Remember when I wrote about sizes="auto"? Well, it’s coming to Chrome! Hallelujah!
This is an excellent step-by-step walkthrough by Tess of creating a web component, with real thought given to what should be in the HTML (which will act as a fallback) and what’s better generated in the Shadow DOM (like buttons for interactivity).
This perfectly mirrors something Chris was saying in a recent episode of the Shop Talk Show:
I think of the image comparison one. That’s a classic example in Web component. What’s inside is just two IMG tags. That’s it. When it fails, you don’t want a weird div with little arrows on it being rendered on the page. That’s not doing anything because it has failed to load the JavaScript.
As well as her personal site, wordridden.com, Jessica also has a professional site, lostintranslation.com.
Both have been online for a very long time. Jessica’s professional site pre-dates the Sofia Coppola film of the same name, which explains how she was able to get that domain name.
Thanks to the internet archive, you can see what lostintranslation.com looked like more than twenty years ago. The current iteration of the site still shares some of that original design DNA.
The most recent addition to the site is a collection of images on the front page: the covers of books that Jessica has translated during her illustrious career. It’s quite an impressive spread!
I used a combination of CSS grid and responsive images to keep the site extremely performant. That meant using a combination of the picture element, source elements, srcset attributes, and the sizes attribute.
That last part always feels weird. I have to tell the browser what sizes the images will displayed at, which can change depending on the viewport width. But I’ve already given that information in the CSS! It feels weird to have to repeat that information in the HTML.
It’s not just about the theoretical niceties of DRY: Don’t Repeat Yourself. There’s the very practical knock-on effects of having to update the same information in two places. If I update the CSS, I need to remember to update the HTML too. Those concerns no longer feel all that separate.
But I get it. Browsers use a look-ahead parser to start downloading images as soon as possible, so I understand why I need to explicitly state what size the images will be displayed at. Still, it feels like something that a computer should be calculating, not something for a human to list out by hand.
But wait! Most of the images on that page also have a loading attribute with a value of “lazy”. That tells browsers they don’t have to download the images immediately. That sort of negates the look-ahead parser.
That’s why the HTML spec now includes a value for the sizes attribute of “auto”. It’s only supposed to be used in conjunction with loading="lazy" (otherwise it means 100vw).
Browser makers are on board with this. You can track the implementation progress for Chromium, WebKit, and Firefox.
I would very much like to see this become a reality!
Web components have been around for quite a while, but it feels like they’re having a bit of a moment right now.
It turns out that the best selling point for web components was “wait and see.” For everyone who didn’t see the benefit of web components over being locked into a specific framework, time is proving to be a great teacher.
It’s not just that web components are portable. They’re also web standards, which means they’ll be around as long as web browsers. No framework can make that claim. As Jake Lazaroff puts it, web components will outlive your JavaScript framework.
At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to build on React are doing it largely out of habit.
Others are making more sensible judgements and, having been bitten by lock-in in the past, are now giving web components a go.
If you’re one of those people making the move from React to web components, there’ll certainly be a bit of a learning curve, but that would be true of any technology change.
I have a suggestion for you if you find yourself in this position. Try not to bring React’s mindset with you.
I’m talking about the way React components are composed. There’s often lots of props doing heavy lifting. The actual component element itself might be empty.
If you want to apply that model to web components, you can. Lots of people do. It’s not unusual to see web components in the wild that look like this:
<my-component></my-component>The custom element is just a shell. All the actual power is elsewhere. It’s in the JavaScript that does all kinds of clever things with the shadow DOM, templates, and slots.
There is another way. Ask, as Robin does, “what would HTML do?”
Think about composibility with existing materials. Do you really need to invent an entirely new component from scratch? Or can you use HTML up until it reaches its limit and then enhance the markup?
I don’t think we should see web components like the ones you might find in a huge monolithic React app: your Button or Table or Input components. Instead, I’ve started to come around and see Web Components as filling in the blanks of what we can do with hypertext: they’re really just small, reusable chunks of code that extends the language of HTML.
Dave talks about how web components can be HTML with superpowers. I think that’s a good attitude to have. Instead of all-singing, all-dancing web components, it feels a lot more elegant to use web components to augment your existing markup with just enough extra behaviour.
Where does the shadow DOM come into all of this? It doesn’t. And that’s okay. I’m not saying it should be avoided completely, but it should be a last resort. See how far you can get with the composibility of regular HTML first.
Eric described his recent epiphany with web components. He created a super-slider custom element that wraps around an existing label and input type="range":
You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever.
When you wrap some existing markup in a custom element and then apply some new behaviour with JavaScript, technically you’re not doing anything you couldn’t have done before with some DOM traversal and event handling. But it’s less fragile to do it with a web component. It’s portable. It obeys the single responsibility principle. It only does one thing but it does it well.
Jim created an icon-list custom element that wraps around a regular ul populated with li elements. But he feels almost bashful about even calling it a web component:
Maybe I shouldn’t be using the term “web component” for what I’ve done here. I’m not using shadow DOM. I’m not using the templates or slots. I’m really only using custom elements to attach functionality to a specific kind of component.
I think what Eric and Jim are doing is exemplary. See also Zach’s web components.
At the end of his post, Eric says he’d like a nice catchy term for these kinds of web components. In Dave’s catalogue of web components, they’re called “element extensions.” I like that. It’s pretty catchy.
Or we could call them “HTML web components.” If your custom element is empty, it’s not an HTML web component. But if you’re using a custom element to extend existing markup, that’s an HTML web component.
React encouraged a mindset of replacement: “forgot what browsers can do; do everything in a React component instead, even if you’re reinventing the wheel.”
HTML web components encourage a mindset of augmentation instead.
You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever.
I think Eric’s approach here should be the default for most web components: you probably don’t need to mess around with the shadow DOM, and you should definitely be wrapping your web component around existing HTML instead of witing opening and closing tags with nothing in between.
Augment, don’t replace.
Vasilis gives the gist of his excellent talk at the border:none event that just wrapped up in Nuremberg. The rant at the end chimed very much with my feelings on this topic:
I showed a little interaction experiment that one of my students made, with incredible attention to detail. Absolutely brilliant in so many ways. You would expect that all design agencies would be fighting to get someone like that into their design team. But to my amazement she now works as a react native developer.
I have more of these very talented, very creative designers who know how to code, who really understand how the web works, who can actually design things for the web, with the web as a medium, who understand the invisible details, who know about the UX of HTML, who know what’s possible with modern HTML and CSS. Yet when they start working they have to choose: you either join our design team and are forced to use a tool that doesn’t get it, or you join the development team and are forced to use a ridiculous framework and make crap.
The slides from Hidde’s presentation at Paris Web—a great overview of using and misusing ARIA.
Now, this is how you design a web component. It’s a progressive enhancement.
Wrap your existing table element inside table-saw and it will behave responsively. If anything goes wrong with the JavaScript, the fallback is the regular table that’s already in your markup.
I just wish the installation didn’t assume that you’re using npm …it’s not really “zero dependency” if it depends on that.
Bruce raises an interesting question with media playing in popovers—shouldn’t the media pause when the popover is closed? I agree with Bruce that this is a common use case that should be covered declaratively.
Gosh! And I thought I had strong opinions about markup!