[Robin]: I stumbled upon this nifty VS Code plugin called TabOut this week that lets you hit the tab key and jump between quotes in a line of code. It’s a brilliant plugin because I think it does precisely what the tab button should do by default: let you navigate between words within quotes and brackets and what not. I only want to indent the line when I’m at the beginning of the line, but at all other times, it makes sense to jump to the next bit of important information.
Of all the blogs and websites and places that I could have found out about this trick, I least expected it to have come from the @vscode TikTok account.
I know that this solidifies my public persona as a cool teen influencer—but!—this account is great because it’s showed me a bunch of VSCode optimizations that I wasn’t aware of. Like this great setting that folds imports. Once it’s activated you’ll notice that at the top of your files there won’t be a sea of @import declarations. Now they’re all hidden away, available with just a click.
It even works in this little Astro project that I’m working on right now:
See, mom? Doom scrolling through TikTok is useful for my job. So there.
🙌
Josh Comeau reminded me this week that :focus-within is a nifty CSS feature that I often forget about. In this example, he shows us how a form can animate ever so slightly when you’re focused on the form elements inside, like this:
So :focus-within is pretty darn handy, and I like this effect a lot. Focus elements FTW!
But this also reminded me that there’s a somewhat similarly named :focus-visible CSS pseudo-class which is a nifty CSS trick that we’ve written about before and it can be used like so:
```
/* Focusing the button with a keyboard will show a dashed black line. */
button:focus-visible {
outline: 4px dashed black;
}
/* Focusing the button with a mouse, touch, or stylus will show a subtle drop shadow. */
button:focus:not(:focus-visible) {
outline: none;
box-shadow: 1px 1px 5px rgba(1, 1, 0, .7);
}
```The idea here being that sometimes you want to have a particular focus style for a certain device. I have to say that the line button:focus:not(:focus-visible) makes my head spin a bit, but it’s very useful nonetheless.
⌨️
My only true nemesis in life is scroll bar reflowing. It always hoodwinks me and in the past, I’ve caused gnarly visual problems on a website when I’ve forgotten that at one point or another that I disabled the scrollbars in macOS. This is why some folks recommend keeping the scrollbar always on:
This is a bit of advice for developers on Macs I’ve heard quite a few times, and I’ll echo it: go into System Preferences > General > Show scroll bars and set to always. This isn’t about you, it’s about the web. See, the problem is that without this setting on, you’ll never experience scrollbar-triggered layout shifts, but everyone else with this setting on will. Since you want to design around not causing this type of jank, you should use this setting yourself.
Layout shifts are real bad and annoying, and our job as web developers is to prevent them as much as we can (I am saying this to myself out loud so I remember to keep shifts in mind in the future).
In the post above, Chris then links to a blog post by Bramus Van Damme from earlier this year (which I happened to miss) where he writes about the upcoming scrollbar-gutter CSS property which hopes to fix these sorts of problems:
A side-effect when showing scrollbars on the web is that the layout of the content might change depending on the type of scrollbar. The
scrollbar-gutterCSS property —which will soon ship with Chromium — aims to give us developers more control over that.
So if we were to write the following CSS in the future…
.element {
overflow: auto;
scrollbar-gutter: stable;
}…then the element will keep the space for the scrollbar available, even if no text is overflowing the container and no scrollbar is shown.
Here’s Bramus’s diagram that shows this (see the right-hand side of the first image):
It’s neat to me that this is getting fixed in the future but it seems really weird to me that viewport units don’t take scrollbars into consideration. That seems to be a bug that ought to be fixed, rather than a future improvement that should be added to CSS itself.
👌
Charlie Gerard wrote a great intro to the Solid JavaScript library:
Solid is a reactive JavaScript library for creating user interfaces without a virtual DOM. It compiles templates down to real DOM nodes once and wraps updates in fine-grained reactions so that when state updates, only the related code runs.
This way, the compiler can optimize initial render and the runtime optimizes updates. This focus on performance makes it one of the top-rated JavaScript frameworks.
Charlie walks through building an app with Solid and how it works avoids wastefully recreating DOM nodes on every update with template helpers like For and Show:
<For each={todos.list} fallback={<div>Loading...</div>}>
{(item) => <div>{item}</div>}
</For>
<Show when={todos.list[0].completed} fallback={<div>Loading...</div>}>
<div>1st item completed</div>
</Show>These template helpers look neat as heck and I love how at the end of the post Charlie builds a starter project that you can deploy to Netlify with just a click to mess around with the code she wrote. Great stuff.
🤩
Brian Kardell wrote about bringing tabs to HTML and even though we all know what tabs are, there’s a real difficulty here in making sure that they’re accessible and useful for everyone. Brian’s thought process sure is interesting.
He also mentions how the Open UI project is trying to do this for a range of other things which I think is the most important takeaway from this whole blog post:
There are lots of efforts around adding new elements to HTML – many of which are being coordiated through an effort in WICG called “Open UI”. This effort involves browser implementers, developers, UI Toolkit makers, etc, and I think that’s great. I really want the web to have a better set of tools for making basic UI and I hope that Open UI can show us a better way forward than we’ve done in the past.
Their goal is a mighty big one:
Today, component frameworks and design systems reinvent common web UI controls to give designers full control over their appearance and behavior. We hope to make it unnecessary to reinvent built-in UI controls, but for those who choose to do so, we expect that these design systems will benefit from Open UI’s specifications and test suites.
YES! Whenever I switch front-end jobs I realize that I have to redo tons of work over and over again. For example: I wonder how many custom tab components exist on the web that could replaced with a standardized and native HTML solution? I know it’s not as simple as browsers shipping a <tab> component, but there’s a ton of front-end work that feels like we’re duplicating all our time and attention unnecessarily and we desperately need groups like the Open UI to show us where that work is happening and how we get to a better place in the future.
I think this work is thoroughly exciting and I’ll be keeping my eye on this stuff in the future.
🌔
I enjoyed this post from Robin Marx all about setting the right expectations for HTTP3. It explains a lot of the very dense and verbose technical problems with HTTP2 in a clear and accessible way.
Also, unrelatedly, I adore Smashing Magazine’s dark mode and typographic styles.
⭐️
:where is a weird selector because it has 0 specificity, which Mojtaba Seyedi explains in this great post about using :where as a CSS reset.
He explains how sometimes you might want to override the browser’s styles for certain elements in specific circumstances. But what if we want to only override styles that have a CSS class on them? Here’s his example:
ul[class] {
padding: 0;
margin: 0;
list-style-type: none;
}As Seyedi describes, this is grand and all but what happens when you want to override these styles? With something like this…
ul[class] {
padding: 0;
margin: 0;
list-style-type: none;
}
.list {
list-style-type: square;
}…this won’t work though because ul[class] has higher specificity than .list. But! This is where you can use the :where selector:
:where(ul[class]) {
list-style: none;
}
.list {
list-style: square; /* Now this works like a charm! */
}This is extremely neat to me because it gives us a lot more control when it comes to writing CSS. Although, I can’t think of many circumstances where I’d want to do this.
Actually, Chris gave a good example a while ago where you want to style a selector by its ID, but without the specificity.
h3:where(#specific-header) {
outline: 1px solid yellow;
}This could be very useful indeed!
Sponsor
Create a paid newsletter subscription with WooCommerce
Manage your website, blog, customers, transactions, and email content all in one place. All the tools that you need live comfortably within WordPress and your WooCommerce store.
[Chris]: I like it when developer technology runs ahead of consumer technology when it can. For example, multi-screen mobile devices are emerging a bit, but haven’t exactly made it big yet. But maybe they will! I had a really weird dream recently where I had a folding mobile device with multiple screens and I was super into it. But say everyone had one next month… what tools do we have for that in CSS? How do we manage multiple screen layout?
Stephanie Stimac of Microsoft is all over it. See her video Dual Screen Web Development from Build 2021. Imagine we’re looking at a mobile device where it’s “hinge” is verticle and there are two sides (like a typical print book). We’re gonna have something like:
@media (horizontal-viewport-segments: 2)
and
(vertical-viewport-segements: 1) {
}Great. Now we can make smart decisions. Another way of putting that: make less mistakes, like centering something smack dab in the middle, split across the hinge, making it hard to read. And it’s not just the media queries, we have values we can tap into. So we could lay out a grid layout to match exactly what is going on.
@media (horizontal-viewport-segments: 2)
and
(vertical-viewport-segements: 1) {
display: grid;
grid-template-columns: env(fold-left) 1fr;
gap: env(fold-width);
}The working drafts for all this even have JavaScript APIs that give you information about the window “segments”.
While I started this by saying that multi-screen devices haven’t quite made it big, it’s not that they don’t exist. Microsoft literally sells the Surface Duo.
Allow me to snag some photos from The Verge:
Look at all that data loss right down the middle. I would guess a lot of owners of these things don’t actually browse the web this way exactly for that reason. Probably makes more sense to be multi-tasking and have the browser only open on half the screen, or flip the device 90-degrees so you scan scroll content past the hinge and not outright lose it.
I imagine if multi-screen devices get a lot more popular, we web devs are going to spend a lot more time talking about layout strategies to accommodate. That’s what we’ve spent the last decade doing already, this is just yet another element of the unknown to toss on the pile.