Fuel Your Blog

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.

A while back, we started a blog in the marketing realm. When we first started out, our traffic was flat. But …

How to Grow Your Blog Traffic by 20,000 Visitors a Month Read More »

The post How to Grow Your Blog Traffic by 20,000 Visitors a Month appeared first on .

Lately, I’ve been thinking about the basics of web development. Actually, I’ve been thinking about them for some time now, at least since I started teaching beginning web development in 2020.

I’m fascinated by the basics. They’re an unsung hero, really, as there is no developer worth their salt who would be where they are without them. Yet, they often go unnoticed.

The basics exist in some sort of tension between the utmost importance and the incredibly banal.

You might even think of them as the vegetable side on your dinner plate — wholesome but perhaps bland without the right seasoning.

Who needs the basics of HTML and CSS, some say, when we have tools that abstract the way they’re written and managed? We now have site builders that require no technical knowledge. We have frameworks with enough syntactic sugar to give your development chops a case of cavities. We have libraries packed with any number of pre-established patterns that can be copy-pasted without breaking a sweat. The need to “learn” the basics of HTML and CSS is effectively null when the number of tools that exist to supplant them is enough to fill a small galaxy of stars.

Rachel Andrew wrote one of my all-time favorite posts back in 2019, equating the rise of abstractions with an increase in complexity and a profound loss of inroads for others to enter the web development field:

“We have already lost many of the entry points that we had. We don’t have the forums of parents teaching each other HTML and CSS, in order to make a family album. Those people now use Facebook or perhaps run a blog on wordpress.com or SquareSpace with a standard template. We don’t have people customising their MySpace profile or learning HTML via Neopets. We don’t have the people, usually women, entering the industry because they needed to learn HTML during that period when an organisation’s website was deemed part of the duties of the administrator.”

— Rachel Andrew, “HTML, CSS and our vanishing industry entry points”

There’s no moment more profound in my web development career than the time I changed the background color of a page from default white to some color value I can’t remember (but know for a fact it would never be dodgerblue). That, and my personal “a-ha!” moment when realizing that everything in CSS is a box. Nothing guided me with the exception of “View Source,” and I’d bet the melting Chapstick in my pocket that you’re the same if you came up around the turn of the 21st century.

Where do you go to learn HTML and CSS these days? Even now, there are few dedicated secondary education programs (or scholarships, for that matter) to consider. We didn’t have bootcamps back in the day, but you don’t have to toss a virtual stone across many pixels to find one today.

There are excellent and/or free tutorials, too. Here, I’ll link a few of ’em up for you:

• Learn HTML / Learn CSS by web.dev
• Getting Start With the Web by MDN
• HTML & CSS Crash Course by Kevin Powell
• Introduction to HTML and CSS by The Odin Project
• Learn HTML / Learn CSS by W3Docs

Let’s not even get into the number of YouTube tutorials. But if you do, no one beats Kevin’s incredible archive of recorded gems.

Anyway, my point is that there are more resources than ever for learning web development, but still painfully few entry points to get there. The resources we have for learning the basics are great, but many are either growing stale, are quick hits without a clear learning path, or assume the learner has at least some technical knowledge. I can tell you, as someone who has hit the Publish button on thousands of front-end tutorials, that the vast majority — if not all — of them are geared toward those who are already on the career path.

It was always a bit painful when someone would email CSS-Tricks asking where to get started learning CSS because, well, you’d imagine CSS-Tricks being the perfect home for something like that, and yet, there’s nothing. It’s just the reality, even if many of us (myself included) cut our chops with sites like CSS-Tricks, Smashing Magazine, and A List Apart. We were all learning together at that time, or so it seemed.

What we need are more pathways for deep learning.

Learning Experience Design (LXD) is a real thing that I’d position somewhere between what we know as UX Design and the practice of accessibility. There’s a focus on creating delightful experiences, sure, but the real aim of LDX is to establish learning paths that universally account for different types of learners (e.g., adults and children) and learning styles (e.g., visual and experiential). According to LDX, learners have a set of needs not totally unlike those that Maslow’s hierarchy of needs identifies for all humans, and there are different models for determining those needs, perhaps none more influential than Bloom’s Taxonomy.

These are things that many front-end tutorials, bootcamps, videos, and programs are not designed for. It’s not that the resources are bad (nay, most are excellent); it’s that they are serving different learners and learning types than what a day-one beginner needs. And let’s please not rely on AI to fill the gaps in human experiences!

Like I said, I’ve been thinking about this a lot. Like, a lot a lot. In fact, I recently published an online course purely dedicated to learning the basics of front-end development, creatively named TheBasics.dev. I’d like to think it’s not just another tutorial because it’s a complete set of lessons that includes reading, demonstrations, videos, lab exercises, and assessments, i.e., a myriad of ways to learn. I’d also like to think that this is more than just another bootcamp because it is curricula designed with the intention to develop new knowledge through reflective practices, peer learning, and feedback.

Anyway, I’m darn proud of The Basics, even if I’m not exactly the self-promoting type, and writing about it is outside of my comfort zone. If you’re reading this, it’s very likely that you, too, work on the front end. The Basics isn’t for you exactly, though I’d argue that brushing up on fundamentals is never a bad thing, regardless of your profession, but especially in front-end development, where standards are well-documented but ever-changing as well.

• Visit The Basics

The Basics is more for your clients who do not know how to update the website they paid you to make. Or the friend who’s learning but still keeps bugging you with questions about the things they’re reading. Or your mom, who still has no idea what it is you do for a living. It’s for those whom the entry points are vanishing. It’s for those who could simply sign up for a Squarespace account but want to actually understand the code it spits out so they have more control to make a site that uniquely reflects them.

If you know a person like that, I would love it if you’d share The Basics with them.

Long live the basics! Long live the “a-ha!” moments that help us all fall in love with the World Wide Web.