The Blog Pros

Native Web Components are still enjoying something of a moment lately. Lots of chatter, and a good amount of it positive. Other sentiment may be critical, but hopeful. Even more important, we’re seeing people actually use Web Components more and more. Like make them and share them proudly. Here are some recently:

• David Darnes made a <storage-form> component. Here’s an example that happens to me regularly enough that I really notice it. Have you ever been on GitHub, typing up a PR description or something, but then accidentally navigated away or closed the tab? Then you go back, and everything you typed was still there. Phew! They are using the localStorage API to help there. They save the data you type in the form behind the scenes, and put it back if they need to.
• Dave Rupert made <wobbly-box>, which draws a border around itself that is every so slightly kittywampus. It uses border-image which is nigh unlearnable so I’d be happy to outsource that. Also interesting that the original implementation was a Houdini paint worklet thing, but since that’ll never be cross-browser compatible, this was the improvement.
• Ryan Mulligan made a <target-toggler>, which wraps a <button> and helps target some other element (anywhere in DOM) and hides/shows it with the hidden attribute. Plus toggles the aria-expanded attribute properly on the button. Simple, handy, probably catches a few more details that you would crafting it up quick, and is only like 1KB.
• Hasan Ali made a <cruk-textarea> that implements Stephen’s trick on auto-growing text areas automatically. Probably isn’t needed for too much longer, but we’ll see.
• Jake Lazaroff made <roving-tabindex> component such that you can put whatever DOM stuff inside to create a focus trap on those things (as it required for things like modal implementations). I think you get this behavior “for free” with <dialog> but that assumes you want to and can use that element. I also thought inert was supposed to make this easier (like inert the entire body and un-inert the part you want a focus trap on), but it doesn’t look like that’s as easily possible as I thought. Just makes this idea all the more valuable. Part of the success story, as it were.

Interesting point here: every single one of these encourages, nay requires, useful HTML inside of them to do what they do. Web Components in that vein have come to be called HTML Web Components. Scott Jehl took a moment to codify it:

They are custom elements that

1. are not empty, and instead contain functional HTML from the start,
2. receive some amount of progressive enhancement using the Web Components JavaScript lifecycle, and
3. do not rely on that JavaScript to run for their basic content or functionality

He was just expanding on Jeremy Keith’s original coining and the excitement that followed.

Speaking of excitement, Austin Crim has a theory that there are two types of Web Components fants:

1. The source-first fans. As in, close to the metal, nothing can break, lasts forever…
2. The output-first fans. As in, easy to use, provide a lot of value, works anywhere…

I don’t know if I’m quite feeling that distinction. They feel pretty similar to me, really. At least, I’m a fan for both reasons. We could brainstorm some more fan types maybe! There’s This is the Best Way to Make a Design System group. There’s the This is Progressive Enhancement at its Finest group. There’s the If Chrome Says it’s Good, Then I Say it’s Good group. There’s the Ooooo Something New To Play With group. Your turn.

Let’s end here with two things related to the technology of Web Components you might want to know about.

One of the reasons people reach for JavaScript frameworks is essentially data binding. Like you have some variable that has some string in it (think: a username, for example) and that needs to make it’s way into HTML somewhere. That kind of thing has been done a million times, we tend to think about putting that data in braces, like {username}. But the web platform doesn’t have anything like that yet. Like Rob Eisenberg says:

One of the longest running requests of the Web Platform is the ability to have native templating and data binding features directly in HTML. For at least two decades innovative developers have been building libraries and frameworks to make up for this platform limitation.

The Future of Native HTML Templating and Data Binding

DOM Parts is maybe the closest proposal so far, but read Rob’s article for more in-depth background.

Another thing I’m interested in, forever, is the styling of Web Components. I think it’s obnoxious we can’t reach into the Shadow DOM with outside CSS, even if we know fully what we’re doing. The options for styling within Web Components all suck if you ask me. Who knows if we’ll ever get anything proper (the old /deep/ stuff that had a brief appearance in CSS was removed apparently for good reason). But fortunately Brian Kardell has a very small and cool library that looks entirely usable.

Let’s say you are totally fine with making a request for a stylesheet from within a Web Component though, how does that work? Well there is a such thing as a Constructable StyleSheet, and if you have one of those on hand, you can attach it to a Shadow Root via adoptedStyleSheets. How do you get one of those from requesting a CSS file? The trick there is likely to be import assertions for CSS, which look like:

import sheet from './styles.css' assert {type: 'css'};

Now sheet is a Constructable StyleSheet and usable. I like that. But let’s say you’re bundling your CSS, which is generally a smart thing to do. Does that mean you need to start breaking it apart again, making individual component styles individually importable? Maybe not! There is a proposal that looks solid for declaring individually importable chunks of CSS within a @sheet block. Then, just like non-default exports in JavaScript, you can pluck them off by name.

@sheet sheet1 {
  :host {
    display: block;
    background: red;
  }
}

@sheet sheet2 {
  p {
    color: blue;
  }
}

import {sheet1, sheet2} from './styles1and2.css' assert {type: 'css'};

Pretty solid solution I think. I’d be surprised if it didn’t make it into the platform. If it doesn’t, I promise I’ll go awww sheet.

There are plenty of very legit reasons you’d want to have a scrolling element start out scrolled to the bottom, and stay scrolled to the bottom (as long as a user hasn’t scrolled back up). As ever, you could do this with JavaScript, as JavaScript can adjust scroll positions of elements. There is a way to do this primarily with CSS now that the anchor-overflow property exists, and I think it’s an extremely great CSS trick.

There is another way though! Kitty Giraudel covers it in CSS-only bottom-anchored scrolling area. The base of the trick is quite simple and requires no additional elements. You just set flex-direction: column-reverse; and then put the HTML inside in reverse order. So the stuff you want pinned at the bottom visually you put at the top of the element. In a way, this makes sense to me, as the thing you want to read first is at the top.

But there is an accessibility concern that Kitty notes. It “creates a disconnect between the visual order and the DOM order, which can be confusing for screen-reader users.” I’d want to verify that with a screen reader user I think (probably applies mostly to people who use a screen reader and have some vision). But it’s a good point and a classic problem that comes up any time you use CSS to position things in such a way they appear visually differently than the source order suggests. I’m sure you can imagine the akwardness of focus states jumping around the screen unpredictably.

The thing that makes all this so news-worthy to me is that CSS is working on a solution for this that I didn’t know about:

reading-order: normal | flex-visual | flex-flow | grid-rows | grid-columns | grid-order

In our case, we could use reading-order: flex-visual to align the way sighted users and screen-reader users consume our feed.

So we’ve reversed the order using flexbox, but we can make the elements still read top-to-bottom (visual order) by forcing it with this property. I might argue, again, that in this case, users might want to read bottom-to-top. But at least you’ve got options now.

And this reader-order stuff is generally interesting. Like if you use flexbox and totally mess with where the flex items are placed with the order property, placing, for instance, the 7th item in the 2nd place, and the 19th item in the 1st place, updating the reading order to flex-visual will be great. I notice there is no grid-visual though, which is curious, since you can mess with the order of grid just the same.

Jonathan Snook has a play with the idea of lenticular cards. Those are those ridged plastic novelty cards that have two different images you can see depending on the angle you look at it from. Or more!

Since Apple released Live Photos, I’ve always felt like they could be used to create a similar effect and yet, no photo app that I’ve seen has implemented it, from what I’ve come across.

I enjoyed playing with the demo on mobile (where the DeviceOrientation API is a thing):

I love the experimentation spirit here. Like thinking of something you think should exist, but doesn’t seem to in an obvious way, then building it anyway.

Yair Even Or had the idea that a box-shadow could be cool if it… wasn’t actually a shadow, but was a blur instead.

The implementation is that perfect tornado of cleverness that appeals to me. It’s not incredibly complicated, but it requires usage of a number of different CSS features that you not think about immediately. In the end, it’s:

• Place a pseudo element behind the element, a specified amount larger than the original element.
• Blur the background with that pseudo element using backdrop-filter.
• This doesn’t “fade out” the effect like a box-shadow would naturally, so instead, two masks are used to fade out the effect (vertical and horizontal).
• Mask compositing is used to combine the masks.

I think the two masks are needed because of the rectangular nature of the element. I’d be tempted to try it with a single radial-gradient, but I think you’d lose blurring near the corners.

Dan Wilson always does a good job looking at new CSS features and the possibilities they unlock. Particularly the new features that are a bit esoteric, or seem to be at first glance, like math functions.

In The New CSS Math: pow(), sqrt(), and exponential friends, Dan looks at those new CSS functions (and a few more), and point out some somewhat practical things they can do. For example, a typographical system where the header sizes aren’t a straight multiple of one another, but are grown on a curve. Or simulating an easing effect by animating a number linearly, but having the movement distance calculated by a pow() on that number. There is even a function now that makes quick work of the Pythagorean theorem.

If you’re into this stuff, Dan looked at rem() and mod() here, which are similar methods for determining what is left over when you divide a number into another number. Is 9 divisible by 3? Yes, and you can know if the remainder is 0. But in web design, you could do things like figure out how many 125px grid columns could fit into 693px of space, if you needed to.

Dan has looked at trig functions as well, and shortly after that, Hypersphere looked at simulating randomness in CSS with those functions. The sin() function, for example, modulates from -1 to 1. So by farting around with that and incorporating a seed value, you can build pretty darn random looking CSS output:

The can’t-miss link recently is Ahmad Shadeed’s An Interactive Guide to CSS Container Queries. His interactive guides are always outstanding. This one is full of practical examples of where container queries are useful.