Tech News

Named Element IDs Can Be Referenced as JavaScript Globals

Css Tricks - Tue, 09/27/2022 - 2:58am

Did you know that DOM elements with IDs are accessible in JavaScript as global variables? It’s one of those things that’s been around, like, forever but I’m really digging into it for the first time.

If this is the first time you’re hearing about it, brace yourself! We can see it in action simply by adding an ID to an element in HTML:

Normally, we’d define a new variable using querySelector("#cool") or getElementById("cool") to select that element:

var el = querySelector("#cool");

But we actually already have access to #cool without that rigamorale:

CodePen Embed Fallback

So, any id — or name attribute, for that matter — in the HTML can be accessed in JavaScript using window[ELEMENT_ID]. Again, this isn’t exactly “new” but it’s really uncommon to see.

As you may guess, accessing the global scope with named references isn’t the greatest idea. Some folks have come to call this the “global scope polluter.” We’ll get into why that is, but first…

Some context

This approach is outlined in the HTML specification, where it’s described as “named access on the Window object.”

Internet Explorer was the first to implement the feature. All other browsers added it as well. Gecko was the only browser at the time to not support it directly in standards mode, opting instead to make it an experimental feature. There was hesitation to implement it at all, but it moved ahead in the name of browser compatibility (Gecko even tried to convince WebKit to move it out of standards mode) and eventually made it to standards mode in Firefox 14.

One thing that might not be well known is that browsers had to put in place a few precautionary measures — with varying degrees of success — to ensure generated globals don’t break the webpage. One such measure is…

Variable shadowing

Probably the most interesting part of this feature is that named element references don’t shadow existing global variables. So, if a DOM element has an id that is already defined as a global, it won’t override the existing one. For example:

<head> <script> window.foo = "bar"; </script> </head> <body> <div id="foo">I won't override window.foo</div> <script> console.log(window.foo); // Prints "bar" </script> </body>

And the opposite is true as well:

<div id="foo">I will be overridden :(</div> <script> window.foo = "bar"; console.log(window.foo); // Prints "bar" </script>

This behavior is essential because it nullifies dangerous overrides such as <div id="alert" />, which would otherwise create a conflict by invalidating the alert API. This safeguarding technique may very well be the why you — if you’re like me — are learning about this for the first time.

The case against named globals

Earlier, I said that using global named elements as references might not be the greatest idea. There are lots of reasons for that, which TJ VanToll has covered nicely over at his blog and I will summarize here:

If the DOM changes, then so does the reference. That makes for some really “brittle” (the spec’s term for it) code where the separation of concerns between HTML and JavaScript might be too much.
Accidental references are far too easy. A simple typo may very well wind up referencing a named global and give you unexpected results.
It is implemented differently in browsers. For example, we should be able to access an anchor with an id — e.g. <a id="cool"> — but some browsers (namely Safari and Firefox) return a ReferenceError in the console.
It might not return what you think. According to the spec, when there are multiple instances of the same named element in the DOM — say, two instances of <div class="cool"> — the browser should return an HTMLCollection with an array of the instances. Firefox, however, only returns the first instance. Then again, the spec says we ought to use one instance of an id in an element’s tree anyway. But doing so won’t stop a page from working or anything like that.
Maybe there’s a performance cost? I mean, the browser’s gotta make that list of references and maintain it. A couple of folks ran tests in this StackOverflow thread, where named globals were actually more performant in one test and less performant in a more recent test.

Additional considerations

Let’s say we chuck the criticisms against using named globals and use them anyway. It’s all good. But there are some things you might want to consider as you do.

Polyfills

As edge-case-y as it may sound, these types of global checks are a typical setup requirement for polyfills. Check out the following example where we set a cookie using the new CookieStore API, polyfilling it on browsers that don’t support it yet:

<body> <img id="cookieStore"></img> <script> // Polyfill the CookieStore API if not yet implemented. // https://developer.mozilla.org/en-US/docs/Web/API/CookieStore if (!window.cookieStore) { window.cookieStore = myCookieStorePolyfill; } cookieStore.set("foo", "bar"); </script> </body>

This code works perfectly fine in Chrome, but throws the following error in Safari.:

TypeError: cookieStore.set is not a function

Safari lacks support for the CookieStore API as of this writing. As a result, the polyfill is not applied because the img element ID creates a global variable that clashes with the cookieStore global.

JavaScript API updates

We can flip the situation and find yet another issue where updates to the browser’s JavaScript engine can break a named element’s global references.

For example:

<body> <input id="BarcodeDetector"></input> <script> window.BarcodeDetector.focus(); </script> </body>

That script grabs a reference to the input element and invokes focus() on it. It works correctly. Still, we don’t know how long it will continue to work.

You see, the global variable we’re using to reference the input element will stop working as soon as browsers start supporting the BarcodeDetector API. At that point, the window.BarcodeDetector global will no longer be a reference to the input element and .focus() will throw a “window.BarcodeDetector.focus is not a function” error.

Conclusion

Let’s sum up how we got here:

All major browsers automatically create global references to each DOM element with an id (or, in some cases, a name attribute).
Accessing these elements through their global references is unreliable and potentially dangerous. Use querySelector or getElementById instead.
Since global references are generated automatically, they may have some side effects on your code. That’s a good reason to avoid using the id attribute unless you really need it.

At the end of the day, it’s probably a good idea to avoid using named globals in JavaScript. I quoted the spec earlier about how it leads to “brittle” code, but here’s the full text to drive the point home:

As a general rule, relying on this will lead to brittle code. Which IDs end up mapping to this API can vary over time, as new features are added to the web platform, for example. Instead of this, use document.getElementById() or document.querySelector().

I think the fact that the HTML spec itself recommends to staying away from this feature speaks for itself.

Named Element IDs Can Be Referenced as JavaScript Globals originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

How to Create Wavy Shapes & Patterns in CSS

Css Tricks - Mon, 09/26/2022 - 3:13am

The wave is probably one of the most difficult shapes to make in CSS. We always try to approximate it with properties like border-radius and lots of magic numbers until we get something that feels kinda close. And that’s before we even get into wavy patterns, which are more difficult.

“SVG it!” you might say, and you are probably right that it’s a better way to go. But we will see that CSS can make nice waves and the code for it doesn’t have to be all crazy. And guess what? I have an online generator to make it even more trivial!

If you play with the generator, you can see that the CSS it spits out is only two gradients and a CSS mask property — just those two things and we can make any kind of wave shape or pattern. Not to mention that we can easily control the size and the curvature of the waves while we’re at it.

Some of the values may look like “magic numbers” but there’s actually logic behind them and we will dissect the code and discover all the secrets behind creating waves.

This article is a follow-up to a previous one where I built all kinds of different zig-zag, scoped, scalloped, and yes, wavy border borders. I highly recommend checking that article as it uses the same technique we will cover here, but in greater detail.

The math behind waves

Strictly speaking, there isn’t one magic formula behind wavy shapes. Any shape with curves that go up and down can be called a wave, so we are not going to restrict ourselves to complex math. Instead, we will reproduce a wave using the basics of geometry.

Let’s start with a simple example using two circle shapes:

We have two circles with the same radius next to each other. Do you see that red line? It covers the top half of the first circle and the bottom half of the second one. Now imagine you take that line and repeat it.

We already see the wave. Now let’s fill the bottom part (or the top one) to get the following:

Tada! We have a wavy shape, and one that we can control using one variable for the circle radii. This is one of the easiest waves we can make and it’s the one I showed off in th is previous article

Let’s add a bit of complexity by taking the first illustration and moving the circles a little:

We still have two circles with the same radii but they are no longer horizontally aligned. In this case, the red line no longer covers half the area of each circle, but a smaller area instead. This area is limited by the dashed red line. That line crosses the point where both circles meet.

Now take that line and repeat it and you get another wave, a smoother one.

I think you get the idea. By controlling the position and size of the circles, we can create any wave we want. We can even create variables for them, which I will call P and S, respectively.

You have probably noticed that, in the online generator, we control the wave using two inputs. They map to the above variables. S is the “Size of the wave” and P is the “curvature of the wave”.

I am defining P as P = m*S where m is the variable you adjust when updating the curvature of the wave. This allows us to always have the same curvature, even if we update S.

m can be any value between 0 and 2. 0 will give us the first particular case where both circles are aligned horizontally. 2 is a kind of maximum value. We can go bigger, but after a few tests I found that anything above 2 produces bad, flat shapes.

Let’s not forget the radius of our circle! That can also be defined using S and P like this:

R = sqrt(P² + S²)/2

When P is equal to 0, we will have R = S/2.

We have everything to start converting all of this into gradients in CSS!

Creating gradients

Our waves use circles, and when talking about circles we talk about radial gradients. And since two circles define our wave, we will logically be using two radial gradients.

We will start with the particular case where P is equal to 0. Here is the illustration of the first gradient:

CodePen Embed Fallback

This gradient creates the first curvature while filling in the entire bottom area —the “water” of the wave so to speak.

.wave { --size: 50px; mask: radial-gradient(var(--size) at 50% 0%, #0000 99%, red 101%) 50% var(--size)/calc(4 * var(--size)) 100% repeat-x; }

The --size variable defines the radius and the size of the radial gradient. If we compare it with the S variable, then it’s equal to S/2.

Now let’s add the second gradient:

CodePen Embed Fallback

The second gradient is nothing but a circle to complete our wave:

radial-gradient(var(--size) at 50% var(--size), blue 99%, #0000 101%) calc(50% - 2*var(--size)) 0/calc(4 * var(--size)) 100%

If you check the previous article you will see that I am simply repeating what I already did there.

I followed both articles but the gradient configurations are not the same.

That’s because we can reach the same result using different gradient configurations. You will notice a slight difference in the alignment if you compare both configurations, but the trick is the same. This can be confusing if you are unfamiliar with gradients, but don’t worry. With some practice, you get used to them and you will find by yourself that different syntax can lead to the same result.

Here is the full code for our first wave:

.wave { --size: 50px; mask: radial-gradient(var(--size) at 50% var(--size),#000 99%, #0000 101%) calc(50% - 2*var(--size)) 0/calc(4 * var(--size)) 100%, radial-gradient(var(--size) at 50% 0px, #0000 99%, #000 101%) 50% var(--size)/calc(4 * var(--size)) 100% repeat-x; }

Now let’s take this code and adjust it to where we introduce a variable that makes this fully reusable for creating any wave we want. As we saw in the previous section, the main trick is to move the circles so they are no more aligned so let’s update the position of each one. We will move the first one up and the second down.

Our code will look like this:

.wave { --size: 50px; --p: 25px; mask: radial-gradient(var(--size) at 50% calc(var(--size) + var(--p)), #000 99%, #0000 101%) calc(50% - 2*var(--size)) 0/calc(4 * var(--size)) 100%, radial-gradient(var(--size) at 50% calc(-1*var(--p)), #0000 99%, #000 101%) 50% var(--size) / calc(4 * var(--size)) 100% repeat-x; }

I have introduced a new --p variable that’s used it to define the center position of each circle. The first gradient is using 50% calc(-1*var(--p)), so its center moves up while the second one is using calc(var(--size) + var(--p)) to move it down.

A demo is worth a thousand words:

CodePen Embed Fallback

The circles are neither aligned nor touch one another. We spaced them far apart without changing their radii, so we lost our wave. But we can fix things up by using the same math we used earlier to calculate the new radius. Remember that R = sqrt(P² + S²)/2. In our case, --size is equal to S/2; the same for --p which is also equal to P/2 since we are moving both circles. So, the distance between their center points is double the value of --p for this:

R = sqrt(var(--size) * var(--size) + var(--p) * var(--p))

That gives us a result of 55.9px.

CodePen Embed Fallback

Our wave is back! Let’s plug that equation into our CSS:

.wave { --size: 50px; --p: 25px; --R: sqrt(var(--p) * var(--p) + var(--size)*var(--size)); mask: radial-gradient(var(--R) at 50% calc(var(--size) + var(--p)), #000 99%, #0000 101%) calc(50% - 2*var(--size)) 0 / calc(4 * var(--size)) 100%, radial-gradient(var(--R) at 50% calc(-1*var(--p)), #0000 99%, #000 101%) 50% var(--size)/calc(4 * var(--size)) 100% repeat-x; }

This is valid CSS code. sqrt() is part of the specification, but at the time I’m writing this, there is no browser support for it. That means we need a sprinkle of JavaScript or Sass to calculate that value until we get broader sqrt() support.

This is pretty darn cool: all it takes is two gradients to get a cool wave that you can apply to any element using the mask property. No more trial and error — all you need is to update two variables and you’re good to go!

Reversing the wave

What if we want the waves going the other direction, where we’re filling in the “sky” instead of the “water”. Believe it or not, all we have to do is to update two values:

.wave { --size: 50px; --p: 25px; --R: sqrt(var(--p) * var(--p) + var(--size) * var(--size)); mask: radial-gradient(var(--R) at 50% calc(100% - (var(--size) + var(--p))), #000 99%, #0000 101%) calc(50% - 2 * var(--size)) 0/calc(4 * var(--size)) 100%, radial-gradient(var(--R) at 50% calc(100% + var(--p)), #0000 99%, #000 101%) 50% calc(100% - var(--size)) / calc(4 * var(--size)) 100% repeat-x; }

All I did there is add an offset equal to 100%, highlighted above. Here’s the result:

CodePen Embed Fallback

We can consider a more friendly syntax using keyword values to make it even easier:

.wave { --size: 50px; --p: 25px; --R: sqrt(var(--p)*var(--p) + var(--size) * var(--size)); mask: radial-gradient(var(--R) at left 50% bottom calc(var(--size) + var(--p)), #000 99%, #0000 101%) calc(50% - 2 * var(--size)) 0/calc(4 * var(--size)) 100%, radial-gradient(var(--R) at left 50% bottom calc(-1 * var(--p)), #0000 99%, #000 101%) left 50% bottom var(--size) / calc(4 * var(--size)) 100% repeat-x; }

We’re using the left and bottom keywords to specify the sides and the offset. By default, the browser defaults to left and top — that’s why we use 100% to move the element to the bottom. In reality, we are moving it from the top by 100%, so it’s really the same as saying bottom. Much easier to read than math!

With this updated syntax, all we have to do is to swap bottom for top — or vice versa — to change the direction of the wave.

CodePen Embed Fallback

And if you want to get both top and bottom waves, we combine all the gradients in a single declaration:

.wave { --size: 50px; --p: 25px; --R: sqrt(var(--p)*var(--p) + var(--size)*var(--size)); mask: /* Gradient 1 */ radial-gradient(var(--R) at left 50% bottom calc(var(--size) + var(--p)), #000 99%, #0000 101%) left calc(50% - 2*var(--size)) bottom 0 / calc(4 * var(--size)) 51% repeat-x, /* Gradient 2 */ radial-gradient(var(--R) at left 50% bottom calc(-1 * var(--p)), #0000 99%, #000 101%) left 50% bottom var(--size) / calc(4 * var(--size)) calc(51% - var(--size)) repeat-x, /* Gradient 3 */ radial-gradient(var(--R) at left 50% top calc(var(--size) + var(--p)), #000 99%, #0000 101%) left calc(50% - 2 * var(--size)) top 0 / calc(4 * var(--size)) 51% repeat-x, /* Gradient 4 */ radial-gradient(var(--R) at left 50% top calc(-1 * var(--p)), #0000 99%, #000 101%) left 50% top var(--size) / calc(4 * var(--size)) calc(51% - var(--size)) repeat-x; } CodePen Embed Fallback

If you check the code, you will see that in addition to combining all the gradients, I have also reduced their height from 100% to 51% so that they both cover half of the element. Yes, 51%. We need that little extra percent for a small overlap that avoid gaps.

What about the left and right sides?

It’s your homework! Take what we did with the top and bottom sides and try to update the values to get the right and left values. Don’t worry, it’s easy and the only thing you need to do is to swap values.

If you have trouble, you can always use the online generator to check the code and visualize the result.

Wavy lines

Earlier, we made our first wave using a red line then filled the bottom portion of the element. How about that wavy line? That’s a wave too! Even better is if we can control its thickness with a variable so we can reuse it. Let’s do it!

We are not going to start from scratch but rather take the previous code and update it. The first thing to do is to update the color stops of the gradients. Both gradients start from a transparent color to an opaque one, or vice versa. To simulate a line or border, we need to start from transparent, go to opaque, then back to transparent again:

#0000 calc(99% - var(--b)), #000 calc(101% - var(--b)) 99%, #0000 101%

I think you already guessed that the --b variable is what we’re using to control the line thickness. Let’s apply this to our gradients:

CodePen Embed Fallback

Yeah, the result is far from a wavy line. But looking closely, we can see that one gradient is correctly creating the bottom curvature. So, all we really need to do is rectify the second gradient. Instead of keeping a full circle, let’s make partial one like the other gradient.

CodePen Embed Fallback

Still far, but we have both curvatures we need! If you check the code, you will see that we have two identical gradients. The only difference is their positioning:

.wave { --size: 50px; --b: 10px; --p: 25px; --R: sqrt(var(--p)*var(--p) + var(--size)*var(--size)); --_g: #0000 calc(99% - var(--b)), #000 calc(101% - var(--b)) 99%, #0000 101%; mask: radial-gradient(var(--R) at left 50% bottom calc(-1*var(--p)), var(--_g)) calc(50% - 2*var(--size)) 0/calc(4*var(--size)) 100%, radial-gradient(var(--R) at left 50% top calc(-1*var(--p)), var(--_g)) 50% var(--size)/calc(4*var(--size)) 100%; }

Now we need to adjust the size and position for the final shape. We no longer need the gradient to be full-height, so we can replace 100% with this:

/* Size plus thickness */ calc(var(--size) + var(--b))

There is no mathematical logic behind this value. It only needs to be big enough for the curvature. We will see its effect on the pattern in just a bit. In the meantime, let’s also update the position to vertically center the gradients:

.wave { --size: 50px; --b: 10px; --p: 25px; --R: sqrt(var(--p)*var(--p) + var(--size)*var(--size)); --_g: #0000 calc(99% - var(--b)), #000 calc(101% - var(--b)) 99%, #0000 101%; mask: radial-gradient(var(--R) at left 50% bottom calc(-1*var(--p)), var(--_g)) calc(50% - 2*var(--size)) 50%/calc(4 * var(--size)) calc(var(--size) + var(--b)) no-repeat, radial-gradient(var(--R) at left 50% top calc(-1 * var(--p)), var(--_g)) 50% 50%/calc(4 * var(--size)) calc(var(--size) + var(--b)) no-repeat; }

Still not quite there:

CodePen Embed Fallback

One gradient needs to move a bit down and the other a bit up. Both need to move by half of their height.

CodePen Embed Fallback

We are almost there! We need a small fix for the radius to have a perfect overlap. Both lines need to offset by half the border (--b) thickness:

CodePen Embed Fallback

We got it! A perfect wavy line that we can easily adjust by controlling a few variables:

.wave { --size: 50px; --b: 10px; --p: 25px; --R: calc(sqrt(var(--p) * var(--p) + var(--size) * var(--size)) + var(--b) / 2); --_g: #0000 calc(99% - var(--b)), #000 calc(101% - var(--b)) 99%, #0000 101%; mask: radial-gradient(var(--R) at left 50% bottom calc(-1 * var(--p)), var(--_g)) calc(50% - 2*var(--size)) calc(50% - var(--size)/2 - var(--b)/2) / calc(4 * var(--size)) calc(var(--size) + var(--b)) repeat-x, radial-gradient(var(--R) at left 50% top calc(-1*var(--p)),var(--_g)) 50% calc(50% + var(--size)/2 + var(--b)/2) / calc(4 * var(--size)) calc(var(--size) + var(--b)) repeat-x; }

I know that the logic takes a bit to grasp. That’s fine and as I said, creating a wavy shape in CSS is not easy, not to mention the tricky math behind it. That’s why the online generator is a lifesaver — you can easily get the final code even if you don’t fully understand the logic behind it.

Wavy patterns

We can make a pattern from the wavy line we just created!

Oh no, the code of the pattern will be even more difficult to understand!

Not at all! We already have the code. All we need to do is to remove repeat-x from what we already have, and tada. 🎉

CodePen Embed Fallback

A nice wavy pattern. Remember the equation I said we’d revisit?

/* Size plus thickness */ calc(var(--size) + var(--b))

Well, this is what controls the distance between the lines in the pattern. We can make a variable out of it, but there’s no need for more complexity. I’m not even using a variable for that in the generator. Maybe I’ll change that later.

Here is the same pattern going in a different direction:

CodePen Embed Fallback

I am providing you with the code in that demo, but I’d for you to dissect it and understand what changes I made to make that happen.

Simplifying the code

In all the previous demos, we always define the --size and --p independently. But do you recall how I mentioned earlier that the online generator evaluates P as equal to m*S, where m controls the curvature of the wave? By defining a fixed multiplier, we can work with one particular wave and the code can become easier. This is what we will need in most cases: a specific wavy shape and a variable to control its size.

Let’s update our code and introduce the m variable:

.wave { --size: 50px; --R: calc(var(--size) * sqrt(var(--m) * var(--m) + 1)); mask: radial-gradient(var(--R) at 50% calc(var(--size) * (1 + var(--m))), #000 99%, #0000 101%) calc(50% - 2*var(--size)) 0/calc(4 * var(--size)) 100%, radial-gradient(var(--R) at 50% calc(-1 * var(--size) * var(--m)), #0000 99%, #000 101%) 50% var(--size) / calc(4 * var(--size)) 100% repeat-x; }

As you can see, we no longer need the --p variable. I replaced it with var(--m)*var(--size), and optimized some of the math accordingly. Now, If we want to work with a particular wavy shape, we can omit the --m variable and replace it with a fixed value. Let’s try .8 for example.

--size: 50px; --R: calc(var(--size) * 1.28); mask: radial-gradient(var(--R) at 50% calc(1.8 * var(--size)), #000 99%, #0000 101%) calc(50% - 2*var(--size)) 0/calc(4 * var(--size)) 100%, radial-gradient(var(--R) at 50% calc(-.8 * var(--size)), #0000 99%, #000 101%) 50% var(--size) / calc(4 * var(--size)) 100% repeat-x;

See how the code is easier now? Only one variable to control your wave, plus you no more need to rely on sqrt() which has no browser support!

CodePen Embed Fallback

You can apply the same logic to all the demos we saw even for the wavy lines and the pattern. I started with a detailed mathmatical explanation and gave the generic code, but you may find yourself needing easier code in a real use case. This is what I am doing all the time. I rarely use the generic code, but I always consider a simplified version especially that, in most of the cases, I am using some known values that don’t need to be stored as variables. (Spoiler alert: I will be sharing a few examples at the end!)

Limitations to this approach

Mathematically, the code we made should give us perfect wavy shapes and patterns, but in reality, we will face some strange results. So, yes, this method has its limitations. For example, the online generator is capable of producing poor results, especially with wavy lines. Part of the issue is due to a particular combination of values where the result gets scrambled, like using a big value for the border thickness compared to the size:

For the other cases, it’s the issue related to some rounding that will results in misalignment and gaps between the waves:

That said, I still think the method we covered remains a good one because it produces smooth waves in most cases, and we can easily avoid the bad results by playing with different values until we get it perfect.

Wrapping up

I hope that after this article, you will no more to fumble around with trial and error to build a wavy shape or pattern. In addition to the online generator, you have all the math secrets behind creating any kind of wave you want!

The article ends here but now you have a powerful tool to create fancy designs that use wavy shapes. Here’s inspiration to get you started…

CodePen Embed Fallback CodePen Embed Fallback CodePen Embed Fallback CodePen Embed Fallback CodePen Embed Fallback CodePen Embed Fallback CodePen Embed Fallback CodePen Embed Fallback

What about you? Use my online generator (or write the code manually if you already learned all the math by heart) and show me your creations! Let’s have a good collection in the comment section.

How to Create Wavy Shapes & Patterns in CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

How To Customize WordPress Block Theme Cover Templates with Dynamic Post Feature Images

Css Tricks - Fri, 09/23/2022 - 6:15am

If we browse the WordPress theme directory, a majority of themes showcase cover images. It is a feature in popular demand. The cover page trend is true even in the block theme directory screenshots as well.

Let’s consider the following example from Twenty Twenty (a classic theme) which includes a cover template that can be used to display both in single post and page, where the post’s featured image displays at the top that stretches across the browser screen, with post title and other desired meta data below. Cover templates allow creating content that stands out from the traditional constraints of displaying content.

Screenshot showing a single post with Twenty Twenty cover template.

Creating cover templates currently requires writing PHP code as captured here in the Twenty Twenty default theme’s cover template. If we look at the template-parts/content-cover.php file, it contains the code for displaying content when the cover-template is used.

Thus, it is not possible to create a customized cover page if you do not possess a deep knowledge of PHP. For many ordinary WordPress users, the only option is to use plugin like Custom Post Type UI as described in this short video.

Cover sections in block themes

Since WordPress 5.8, theme authors could create custom templates (like single post, author, category, and others) with a top hero section using block editor cover block and bundled into their themes with minimal or no code.

Before diving into how top large cover sections are created in block themes templates, let’s briefly look at the two block themes Twenty Twenty-Two and Wabi by Rich Tabor (full review here).

Screenshot showing cover page thumbnails of Twenty Twenty-Two (left) and Wabi (right) themes.

Behind-the-scenes, Twenty Twenty-Two implements a large header by adding a hidden image stored as a pattern in the header-dark-large parts. Whereas, in the Wabi theme, the large header background color in a single post is implemented with accent background colors and a 50px height spacer block (lines: 5-9). The accent colors are managed by the assets/js/accent-colors.js file.

Many others chose to create a top cover section by using cover block, which allowed users to change the background color and add a static image from Media Library or upload from media devices – without writing any code. With this approach, images from the post featured image block had to be added manually to each single post if you wanted to have the post featured image as the background image in single posts.

Cover Blocks with dynamic post featured image

WordPress 6.0 made available another cool featured image cover blocks feature, which allows use of the featured image of any post or page as the background image in the cover block.

In the following short video, Automattic engineers discuss adding featured images to cover blocks with an example from Archeo theme:

The image block including post featured image block can be further customized using duotone color in theme.json as discussed in this short Connecting The Dots YouTube video (Automattic’s Anne McCarthy).

Use case examples (Wei, Bright Mode)

If we browse the thumbnail images in the block theme directory, we see a majority of them include large cover header sections. If we dig into their template files, they make use of cover blocks with static image background.

Some recently developed themes are using cover blocks with the dynamic post featured image background (e.g., Archeo, Wei, Frost, Bright Mode, etc.). A brief overview of the new feature is available in this short GitHub video.

Screenshot showing cover page thumbnails of Wei (left) and Bright-mode (right) themes.

Combining dynamic accent colors features of Wabi theme with cover and post featured image blocks, Rich Tabor further expands his creativity in his new Wei theme (full review available here) to display dynamic cover images from a single post.

In his Wei announcement post, Rich Tabor writes: “Behind-the-scenes, the single.html template is using a Cover block that leverages the post’s featured image. Then the duotone is applied by the color scheme assigned to the post. This way, just about any image will look fine”.

If you would like to dig deeper into the Wei theme’s header cover block and learn how to create your own, here is a short video from Fränk Klein (WP Development Courses) who explains step-by-step how it was created.

Similar to the Wei theme, Brian Gardner also makes use of cover block with post featured image block in his recent Bright Mode theme to display standout contents with vibrant colors.

Brian told WPTavern: “he loves most about the theme is the way the Cover Block is used on single pages. It pulls the featured image into the Cover block and also offers custom block styles for shadows and full-height options. […] I feel as though this really presents what’s possible with modern WordPress.”

For more detail, here is its demo site and full review of Brian’s Bright Mode theme.

Designing complex layouts with block editor

Recently, WordPress launched a new block editor designed landing homepage and a download page. The announcement attracted mixed reactions from its readers, including from Matt Mullenweg (Automattic) who commented on the 33-days taken to design and launch such a “simple page”. You can find additional behind the scene discussions here.

In response, Jamie Marsland of Pootlepress created this YouTube video where he reproduces a nearly identical homepage in nearly 20 minutes.

Commenting on Marsland video, Sarah Gooding of WP Travern writes: “He is what one might describe as a power user with the block editor. He can quickly shuffle rows, columns, and groups around, adjusting padding and margins as necessary, and assign each section the corresponding color for the design. At this point, this is not something most average WordPress users could do.”

Though the block editor has come a long way, there are still growing pain points to most theme developers and ordinary users to create and design complex layouts with it.

Adding enhancement to TT2 Gopher blocks

In this section, I will walk you through how I added enhancements to the TT2 Gopher Blocks theme that I referenced in my previous article. Inspired by cover blocks from themes that I described earlier, I wanted to add three cover templates (author, category, and single-cover) to the theme.

While browsing websites, we notice two types of cover headers. The mostly observed header is cover section blended with the site header (site title and top navigation) into the cover block (e.g., Twenty Twenty, Twenty Twenty-Two, Wei, Wabi, Frost, Bright Mode, etc.). We also find header cover section which is not blended with site header and positioned just underneath, such as this BBC Future website. For TT2 Gopher blocks theme, I opted for the latter.

Creating cover header patterns

First, let’s create cover header patterns for author, single, and others (categories, tags) templates using cover blocks. Then we will convert them into patterns (as described here previously) and call the respective header cover patterns into the templates.

If you are familiar to working with the block editor, design your header section using cover blocks in the site editor and then convert the cover header code into patterns. However, if you are not familiar with FSE editor, then the easiest way is to copy patterns from the patterns directory in a post, make necessary modification and convert it into a pattern.

In my previous CSS-Tricks article, I discussed in detail on creating and using block patterns. Here is a brief overview of the workflow that I am using to create the single post cover header pattern:

Single post cover header pattern

Step 1: Using FSE interface, let’s create a new blank file and start building block structure as shown on the left panel.

Screenshot of the WordPress UI with the Full Site Editor. A block is being assembled with post date, categories, and post title.

Alternatively, this could be done in a post or page first, and then copy and paste the markup into a pattern file, later.

Step 2: Next, to covert the above markup into a pattern, first we should copy its code markup and paste into a new /patterns/header-single-cover.php in our code editor. We should also add required pattern file header markup (e.g., title, slug, categories, inserter, etc.).

Here is the entire code of the /patterns/header-single-cover.php file:

<?php /** * Title: Header cover single * Slug: tt2gopher/header-cover-single * Categories: tt2gopher-header * Block Types: core/template-part/header * inserter: yes */ ?>  <div class="wp-block-cover alignfull is-light" style="margin-top:0px;margin-bottom:0px;min-height:50vh"><span aria-hidden="true" class="wp-block-cover__background has-foreground-background-color has-background-dim-0 has-background-dim"></span><img class="wp-block-cover__image-background wp-image-100" alt="" src="https://pd.w.org/2022/08/15062ed5f5707b5c5.85694718-2048x1536.jpg" style="object-position:40% 37%" data-object-fit="cover" data-object-position="40% 37%"/><div class="wp-block-cover__inner-container"> <div class="wp-block-group has-base-color has-text-color has-link-color"> <div class="wp-block-group has-primary-color has-text-color has-small-font-size">  <p>|</p>  </div>  </div> </div></div>

Step 3: For this demo, I have used this image from photos directory as a filler background image, and applied the Midnight duotone color. To use post featured image dynamically, we should add "useFeaturedImage":true in the cover block by replacing the above filler image link just before the "dimRatio":50 such that the line 10 should look like the following:

Alternatively, the filler image could also be changed by clicking Replace and selecting Use featured image option:

Screenshot of the WordPress UI with ‘Replace’ and ‘Use featured image’ selected.

Now, the header cover patterns should be visible in the patterns inserter panel for use anywhere in the templates, posts, and pages.

Archive cover headers

Inspired by this WP Tavern post and a step-by-step walkthrough to create an author template header, I wanted to create a similar cover header and add to TT2 Gopher theme, too.

First, let’s create the archive cover header pattern for author.html the template as well, following the above workflow. In this case, I am creating this in a new blank page, by adding blocks (as shown below in list view):

Screenshot of the WordPress UI for an Author page using a single post header cover.

In the background for the cover, I used the same image used in the single post header cover.

Because we would like to display a short author biography on the author block, a biographical statement should also be added to the user profile page, or else a blank space will be displayed in the front-end.

The following is the markup code of the header-author-cover, that we will use pattern, in the next step:

<div class="wp-block-cover alignfull is-light" style="min-height:200px"><span aria-hidden="true" class="wp-block-cover__background has-background-dim-10 has-background-dim"></span><img class="wp-block-cover__image-background wp-image-226" alt="" src="https://pd.w.org/2022/03/8256241eff74ef542.61868565.jpeg" style="object-position:50% 75%" data-object-fit="cover" data-object-position="50% 75%"/><div class="wp-block-cover__inner-container"> <div class="wp-block-group"> <div class="wp-block-group" style="padding-top:1rem;padding-right:2rem;padding-bottom:1rem;padding-left:2rem">  <div class="wp-block-group"> <div class="wp-block-group has-large-font-size"> <p class="has-foreground-color has-text-color has-large-font-size">Published by:</p>  </div>    <hr class="wp-block-separator has-text-color has-foreground-color has-alpha-channel-opacity has-foreground-background-color has-background"/> </div> </div> </div> </div></div>

To covert the markup into a header-author-cover pattern, we should add the required pattern file header markup as described earlier. By editing the header-author-cover.php pattern, we can create similar header covers for tags, taxonomy, and other custom templates.

The header-category-cover.php pattern for my category.html template is available on GitHub.

Creating Templates with header cover blocks

WordPress 6.0 and the recent Gutenberg 13.7 extended template creating features into the block editor, thus making it possible for many WordPress users, without deep knowledge of coding, to create their customized templates.

For more detailed information and use cases, here is a thorough customization note by Justin Tadlock.

Block editor allows creating various types of templates, including cover templates. Let’s briefly overview how combining cover block and post featured image block with new template UI makes easy to create various types of cover custom templates even with no or low coding skills.

Screenshot of the WordPress UI displaying available templates provided by TT2 Gopher Blocks – Single, Page, Index, Home, 404, Blank, and Archive.

Creating templates has been made much easier with Gutenberg 13.7. How to create block templates with codes and in site editor is described in the Theme handbook and in my previous article.

Author template with cover block

Top (header section) markup of the author.html template is shown below (line 6):

<main class="wp-block-group site-content" style="margin-top:0;margin-bottom:0px;padding-bottom:80px">  ... ... ...  ...

Here are screenshots of cover headers for the author.html and category.html templates:

Screenshot of Author Page header (left) with author name, avatar, and biography. And screenshot of Category Page header (right).

The entire code for both templates is available on GitHub.

Single post with cover block

To display cover block in our single post, we have to call the header-cover-single pattern below the header section (line 3):

<div style="height:32px" aria-hidden="true" class="wp-block-spacer"></div>  .... .... ....

Here is a screen capture showing the front-end view of the single post with the header cover section:

Screenshot of TT2 Gopher Blocks Single Post with Header Cover Section Pattern.

The entire single-cover.html template is available on GitHub.

You can find additional step-by-step walkthrough tutorials on creating a hero header post section and using post featured image background cover blocks on WP Tavern and Full Site Editing website.

There you have it!

Helpful Resources Featured image cover block

Post Featured Image Block (WordPress Support)
Using the Post Featured Image with the Cover Block YouTube (Dave on WP)
Cover Block Step by Step tutorial (WordPress Support)
Featured Cover Blocks and the Future of Binding Data to Generic WordPress Blocks (WP Tavern)
Custom Single Post Layouts with WordPress Gutenberg (Pootlepress)
Makes cover block dynamic and adds featured image binding #39658 (GitHub)

Blog posts

Featured Cover Blocks and the Future of Binding Data to Generic WordPress Blocks (WPTavern)
Making an Impression: How To Build a Post Hero Header With Blocks (WPTavern)
Core Editor Improvement: Deeper customization with more template options (Make WordPress Core)

Even though the block themes, in general, are getting lots of pushback from WordPress community members, in my opinion, they are the future of WordPress, too. With block themes, amateur theme authors, without the deep coding skills and mastery of PHP and JavaScript languages, can now create themes with complex layouts with a hero cover section as described in this article combined with patterns and style variations.

As an early Gutenberg user, I couldn’t be more excited with the new theming tools like create block theme plugin and others which allow theme authors to achieve the following directly from block editor UI without writing any code:

(i) create
(ii) overwrite theme files and export
(iii) generate blank or a child theme, and
(iv) modify and save style variation of the current theme

Additionally, the recent iterations of the Gutenberg plugin allow enabling fluid typography and layout alignments and other stylistic controls using only theme.json file without JavaScript and a line of CSS rules.

Thank you for reading and share your comments and thoughts below!

How To Customize WordPress Block Theme Cover Templates with Dynamic Post Feature Images originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

The Web is Good Now

Css Tricks - Thu, 09/22/2022 - 12:07pm

The video of Chris Coyier’s talk at CascadiaJS 2022 is now available. It’s his first in-person talk in more than two years, so it’s great to see our good friend back on stage slinging gems on what makes the web good these days.

Container Queries! WAAPI! Scroll Timelines! offset-path! FLIP! Variable fonts! Fluid type! We really are all-powerful front-end developers these days.

Chris really packs a bunch into a 25-minute slot. It feels good to pause for that brief amount of time to reflect on the great new things for building websites and celebrate the fact that we get to use them.

And there’s nothing better than watching Chris greet the enture room as a bunch of “web nerds”. 🤓

To Shared Link — Permalink on CSS-Tricks

The Web is Good Now originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

How I Made an Icon System Out of CSS Custom Properties

Css Tricks - Thu, 09/22/2022 - 5:17am

SVG is the best format for icons on a website, there is no doubt about that. It allows you to have sharp icons no matter the screen pixel density, you can change the styles of the SVG on hover and you can even animate the icons with CSS or JavaScript.

There are many ways to include an SVG on a page and each technique has its own advantages and disadvantages. For the last couple of years, I have been using a Sass function to import directly my icons in my CSS and avoid having to mess up my HTML markup.

I have a Sass list with all the source codes of my icons. Each icon is then encoded into a data URI with a Sass function and stored in a custom property on the root of the page.

TL;DR

What I have for you here is a Sass function that creates a SVG icon library directly in your CSS.

The SVG source code is compiled with the Sass function that encodes them in data URI and then stores the icons in CSS custom properties. You can then use any icon anywhere in your CSS like as if it was an external image.

This is an example pulled straight from the code of my personal site:

.c-filters__summary h2:after { content: var(--svg-down-arrow); position: relative; top: 2px; margin-left: auto; animation: closeSummary .25s ease-out; } Demo CodePen Embed Fallback Sass structure /* All the icons source codes */ $svg-icons: ( burger: '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0...' ); /* Sass function to encode the icons */ @function svg($name) { @return url('data:image/svg+xml, #{$encodedSVG} '); } /* Store each icon into a custom property */ :root { @each $name, $code in $svg-icons { --svg-#{$name}: #{svg($name)}; } } /* Append a burger icon in my button */ .menu::after { content: var(--svg-burger); }

This technique has both pros and cons, so please take them into account before implementing this solution on your project:

Pros

There are no HTTP requests for the SVG files.
All of the icons are stored in one place.
If you need to update an icon, you don’t have to go over each HTML templates file.
The icons are cached along with your CSS.
You can manually edit the source code of the icons.
It does not pollute your HTML by adding extra markup.
You can still change the color or some aspect of the icon with CSS.

Cons

You cannot animate or update a specific part of the SVG with CSS.
The more icons you have, the heavier your CSS compiled file will be.

I mostly use this technique for icons rather than logos or illustrations. An encoded SVG is always going to be heavier than its original file, so I still load my complex SVG with an external file either with an <img> tag or in my CSS with url(path/to/file.svg).

Encoding SVG into data URI

Encoding your SVG as data URIs is not new. In fact Chris Coyier wrote a post about it over 10 years ago to explain how to use this technique and why you should (or should not) use it.

There are two ways to use an SVG in your CSS with data URI:

As an external image (using background-image,border-image,list-style-image,…)
As the content of a pseudo element (e.g. ::before or ::after)

Here is a basic example showing how you how to use those two methods:

CodePen Embed Fallback

The main issue with this particular implementation is that you have to convert the SVG manually every time you need a new icon and it is not really pleasant to have this long string of unreadable code in your CSS.

This is where Sass comes to the rescue!

Using a Sass function

By using Sass, we can make our life simpler by copying the source code of our SVG directly in our codebase, letting Sass encode them properly to avoid any browser error.

This solution is mostly inspired by an existing function developed by Threespot Media and available in their repository.

Here are the four steps of this technique:

Create a variable with all your SVG icons listed.
List all the characters that needs to be skipped for a data URI.
Implement a function to encode the SVGs to a data URI format.
Use your function in your code.

1. Icons list /** * Add all the icons of your project in this Sass list */ $svg-icons: ( burger: '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24.8 18.92" width="24.8" height="18.92"><path d="M23.8,9.46H1m22.8,8.46H1M23.8,1H1" fill="none" stroke="#000" stroke-linecap="round" stroke-width="2"/></svg>' ); 2. List of escaped characters /** * Characters to escape from SVGs * This list allows you to have inline CSS in your SVG code as well */ $fs-escape-chars: ( ' ': '%20', '\'': '%22', '"': '%27', '#': '%23', '/': '%2F', ':': '%3A', '(': '%28', ')': '%29', '%': '%25', '<': '%3C', '>': '%3E', '\\': '%5C', '^': '%5E', '{': '%7B', '|': '%7C', '}': '%7D', ); 3. Encode function /** * You can call this function by using `svg(nameOfTheSVG)` */ @function svg($name) { // Check if icon exists @if not map-has-key($svg-icons, $name) { @error 'icon “#{$name}” does not exists in $svg-icons map'; @return false; } // Get icon data $icon-map: map-get($svg-icons, $name); $escaped-string: ''; $unquote-icon: unquote($icon-map); // Loop through each character in string @for $i from 1 through str-length($unquote-icon) { $char: str-slice($unquote-icon, $i, $i); // Check if character is in symbol map $char-lookup: map-get($fs-escape-chars, $char); // If it is, use escaped version @if $char-lookup != null { $char: $char-lookup; } // Append character to escaped string $escaped-string: $escaped-string + $char; } // Return inline SVG data @return url('data:image/svg+xml, #{$escaped-string} '); } 4. Add an SVG in your page button { &::after { /* Import inline SVG */ content: svg(burger); } }

If you have followed those steps, Sass should compile your code properly and output the following:

button::after { content: url("data:image/svg+xml, %3Csvg%20xmlns=%27http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%27%20viewBox=%270%200%2024.8%2018.92%27%20width=%2724.8%27%20height=%2718.92%27%3E%3Cpath%20d=%27M23.8,9.46H1m22.8,8.46H1M23.8,1H1%27%20fill=%27none%27%20stroke=%27%23000%27%20stroke-linecap=%27round%27%20stroke-width=%272%27%2F%3E%3C%2Fsvg%3E "); } CodePen Embed Fallback Custom properties

The now-implemented Sass svg() function works great. But its biggest flaw is that an icon that is needed in multiple places in your code will be duplicated and could increase your compiled CSS file weight by a lot!

To avoid this, we can store all our icons into CSS variables and use a reference to the variable instead of outputting the encoded URI every time.

We will keep the same code we had before, but this time we will first output all the icons from the Sass list into the root of our webpage:

/** * Convert all icons into custom properties * They will be available to any HTML tag since they are attached to the :root */ :root { @each $name, $code in $svg-icons { --svg-#{$name}: #{svg($name)}; } }

Now, instead of calling the svg() function every time we need an icon, we have to use the variable that was created with the --svg prefix.

button::after { /* Import inline SVG */ content: var(--svg-burger); } Optimizing your SVGs

This technique does not provide any optimization on the source code of the SVG you are using. Make sure that you don’t leave unnecessary code; otherwise they will be encoded as well and will increase your CSS file size.

You can check this great list of tools and information on how to optimize properly your SVG. My favorite tool is Jake Archibald’s SVGOMG — simply drag your file in there and copy the outputted code.

Bonus: Updating the icon on hover

With this technique, we cannot select with CSS specific parts of the SVG. For example, there is no way to change the fill color of the icon when the user hovers the button. But there are a few tricks we can use with CSS to still be able to modify the look of our icon.

For example, if you have a black icon and you want to have it white on hover, you can use the invert() CSS filter. We can also play with the hue-rotate() filter.

CodePen Embed Fallback Bonus #2: Updating the icon using CSS mask-image property

Another trick to be able to change the color of your icon, is to use it as a mask on your pseudo-element with a background. Set your pseudo-element as inline-block with a background-color and define a width & height for the size needed.

Once you have a rectangle with the color needed, apply those four values to only keep the shape of the SVG needed:

mask-image: var(--svg-burger): The reference to our icon.
mask-repeat: no-repeat: To prevent the mask to be duplicated.
mask-size: contain: To make the icon fit perfectly in the rectangle.
mask-position: center: To center our icon in the pseudo-element.

Don’t forget that all CSS mask properties still need to be prefixed with -webkit- for most browsers as of September 2022.

CodePen Embed Fallback

Thanks to Christopher and Mike for letting me know about this trick in the comments!

That’s it!

I hope you find this little helper function handy in your own projects. Let me know what you think of the approach — I’d be interested to know how you’d make this better or tackle it differently!

How I Made an Icon System Out of CSS Custom Properties originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

CSS Rules vs. CSS Rulesets

Css Tricks - Wed, 09/21/2022 - 11:53am

The latest spec:

A style rule is a qualified rule that associates a selector list with a list of property declarations and possibly a list of nested rules. They are also called rule sets in CSS2.

Louis Lazaris:

As the above quote from W3C indicates, it seems like the W3C considers “rule set” to be a bit of an outdated term, preferring the term “style rule” (or possibly “rule” for short).

I never noticed that! “Rule set” is so gosh darned branded on my brain that it’s gonan take losing a lot of muscle memory to start using “style rule” instead. I didn’t see a specific note in the spec’s Changes section, but you can see the change in the table of contents between versions:

Louis nicely sums up the parts of a style rule as well:

/* Everything below is a style rule (or rule set, or just rule) */ section { /* Everything between the braces is a declaration block */ margin: 0 20px; /* This line is an individual declaration */ color: #888; /* Another declaration */ }

I know nothing of the context and, at first, I was gonna poo-poo the change, but “style rule” really makes sense the more I sit with it. If the property:value pairs are declarations that sit in a declaration block, then we’ve got something less like a set of rules and more like one rule that defines the styles for a selector with a block of style declarations. 👌

Once again, naming things is hard.

To Shared Link — Permalink on CSS-Tricks

CSS Rules vs. CSS Rulesets originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

Featured Fonts

Typography - Wed, 09/21/2022 - 2:25am

Read the book, Typographic Firsts

These font families might have flown under your radar: Six must-have font families. All available from the ILT store.

The post Featured Fonts appeared first on I Love Typography.

Categories: Front End Web Development

Making a Real-Time Clock With a Conic Gradient Face

Css Tricks - Mon, 09/19/2022 - 2:58am

Gradients have been a part of the CSS spectrum for quite some time now. We see a lot of radial and linear gradients in a lot of projects, but there is one type of gradient that seems to be a bit lonely: the conic gradient. We’re going to make a watch face using this type of gradient.

Working with conic gradients

What we’re making consists of a gradient with color transitions rotated around a center point and can have multiple color values. For this clock to work, we will also be using the angle value of a conic gradient which defines the rotation or starting point. The angle is defined by using a from value.

background-image: conic-gradient(from 45deg, #6e7dab, #5762d5);

What is interesting about this, is that a starting angle can have a negative value in CSS, which will come in handy later.

A simple elegant example of a conical gradient:

CodePen Embed Fallback Building our basic clock

Let’s start by adding some HTML for the clock and the hands:

Let’s create some default styling for our clock. For this to work properly, we will update CSS variables with JavaScript later on, so let’s scope these variables inside our .clock selector. For easy tweaking, let’s add the colors of the hands as well.

.clock { /* general clock vars */ --hour-hand-color: #000; --hour-hand-degrees: 0deg; --minute-hand-color: #000; --minute-hand-degrees: 0deg; --second-hand-color: hotpink; --second-hand-degrees: 0deg; position: relative; min-width: 320px; width: 25vw; height: 25vw; min-height: 320px; border-radius: 50%; margin: 0 auto; border: 7px solid #000; } /* clock hands */ .hand { position: absolute; left: 50%; bottom: 50%; height: 45%; width: 4px; margin-left: -2px; background: var(--second-hand-color); border-radius: 6px; transform-origin: bottom center; transition-timing-function: cubic-bezier(0.1, 2.7, 0.58, 1); } .second-hand { transform: rotate(var(--second-hand-degrees)); } .hour-hand { height: 35%; border-radius: 40px; background-color: var(--hour-hand-color); transform: rotate(var(--hour-hand-degrees)); } .minute-hand { height: 50%; background: var(--minute-hand-color); transform: rotate(var(--minute-hand-degrees)); }

This sets us up with the general styling we need for the clock. We’ve set transform-origin on the hands so that they properly rotate around the face of the clock. There are also a few custom properties in there to set angles on the hands that we’ll update with JavaScript to get the timing just right so that each hand maps to seconds, minutes, and hours accordingly.

Here’s what we have so far:

CodePen Embed Fallback

Alright, let’s move on to updating those custom properties!

Adding the JavaScript for our basic clock

First off, we’re going to target our clock and create a function:

const clock = document.getElementById("clock"); function setDate() { // Code to set the current time and hand angles. } setDate();

Inside of our function we’re going to fetch the current time using the Date() function to calculate the correct angle of the hands:

const now = new Date(); const secondsAngle = now.getSeconds() * 6; const minsAngle = now.getMinutes() * 6 + secondsAngle / 60; const hourAngle = ((now.getHours() % 12) / 12) * 360 + minsAngle / 12;

Here is how this calculation works:

Seconds: We take 60 seconds and multiply it by 6, which happens to be 360, the perfect number of angles in a full circle.
Minutes: Same as seconds, but now we add the seconds angle and divide it by 60 to increase the angle just a little bit within the minute for a more accurate result.
Hours: First, we calculate the remainder of the hour and divide it by 12. Then we divide that remainder by 12 again to get a decimal value we can multiply by 360. For example, when we’re at the 23rd hour, 23 / 12 = remain 11. Divide this by 12 and we get 0.916 which then gets multiplied by 360 for a grand total of 330. Here, we will do the same thing we did with the minutes and add the minutes angle, divided by 12, for a more accurate result.

Now that we have our angles, the only thing left to do is to update the variables of our clock by adding the following at the end of our function:

clock.style.setProperty("--second-hand-degrees", secondsAngle + "deg"); clock.style.setProperty("--minute-hand-degrees", minsAngle + "deg"); clock.style.setProperty("--hour-hand-degrees", hourAngle + "deg");

Last, but not least, we will trigger the function with an interval of a second to get a working clock:

const clock = document.getElementById("clock"); function setDate() { // etc. } // Tick tick tick setInterval(setDate, 1000); setDate();

See the working demo of our basic clock:

CodePen Embed Fallback Applying this to a conical gradient

OK, so the hands of our clock are working. What we really want is to map them to a conical gradient that updates as the time changes. You may have seen the same effect if you have an Apple Watch with the “Gradient” face active:

Credit: Macworld

To do this, let’s start by updating our .clock element with a conic gradient and two custom properties that control the starting and ending angles :

.clock { /* same as before */ /* conic gradient vars */ --start: 0deg; --end: 0deg; /* same as before */ background: conic-gradient( from var(--start), rgb(255 255 255) 2deg, rgb(0 0 0 / 0.5) var(--end), rgb(255 255 255) 2deg, rgb(0 0 0 / 0.7) ); }

You can play around with this a bit to style it just the way you like it. I added some extra colors in the gradient to my liking, but as long as you have a starting point and an ending point, you’re good to go.

CodePen Embed Fallback

Next up, we will update our setDate() function so that it updates the variables for our starting and ending points on the conic gradient. The starting point will be our seconds hand, which is easy to find because it will be the same as the angle of our minutes. To make this end at the hours hand, we should make our ending point the same as the hourAngle variable in the script, but subtract our starting point from it.

let startPosition = minsAngle; let endPosition = hourAngle - minsAngle;

Now we can update our variables with JavaScript again:

clock.style.setProperty("--start", startPosition + "deg"); clock.style.setProperty("--end", endPosition + "deg");

It looks like we could be done at this point, but there is a catch! This calculation works fine as long as the minutes hand has a smaller angle than the hours hand. Our conic gradient will get messy the moment when the minutes hand has moved past it. To fix this, we will use a negative value as a starting point. Luckily, it’s easy to spot when this happens. Before updating our variables we’ll add the following:

if (minsAngle > hourAngle) { startPosition = minsAngle - 360; endPosition = hourAngle - startPosition; }

By subtracting 360 from our minutes angle, we are able to set a negative value for our startposition variable. Because of this negative starting point, our end position should be updated by the hour angle, subtracted by the starting position.

There we go — now the hour and minute hands are set to gradient angles:

CodePen Embed Fallback

That’s it! But don’t let that stop you from taking this even further. Create your own styles and share them with me in the comments so I can check them out.. Here is a little inspiration to get you going:

CodePen Embed Fallback

Making a Real-Time Clock With a Conic Gradient Face originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

More Details on `details`

Css Tricks - Thu, 09/15/2022 - 3:12am

A lot of chatter around the ol’ <details> and <summary> elements lately! I saw Lea Verou recently tweet an observation about the element’s display behavior and that sorta splintered into more observations and usage notes from folks, including a revived discussion on whether <summary> should be allowed to contain interactive elements or not.

There are a lot of dots to connect and I’ll do my best here to do exactly that.

Can we change the display of elements nested in the <details> element?

In the app I’m building, I’m using <details> for panels but ran into some sizing weirdness.
Flexbox: https://t.co/noZvxAN35G
Grid: https://t.co/pis0lPjvXk
At first I thought it was a bug, but all three engines agree. Nothing in the UA stylesheet for <details> seems to explain it.

— Lea Verou (@LeaVerou) August 28, 2022

Super weird! If we crack open DevTools, the user agent stylesheet tells us <details> is a displayed as a block element.

Notice the required <summary> element and the two additional <div>s in there. We can override the display, right?

What we might expect is that <details> now has an explicit height of 40vh and three rows where the third row takes up the remaining space leftover from the first two. Like this:

Ugh, but the third row doesn’t… do… that.

Apparently what we’re dealing with is a grid container that is unable to apply grid behavior to its grid items. But the HTML spec tells us:

The details element is expected to render as a block box. The element is also expected to have an internal shadow tree with two slots.

(Emphasis mine)

And a little later:

The details element’s second slot is expected to have its style attribute set to “display: block; content-visibility: hidden;” when the details element does not have an open attribute. When it does have the open attribute, the style attribute is expected to be removed from the second slot.

(Emphasis mine, again)

So, the spec says the second slot — the two additional <div>s from the example — are only coerced into being block elements when <details> is closed. When it’s open — <details open> — they should conform to the grid display that overrides the user agent styling… right?

That’s the debate. I get that slots are set to display: contents by default, but jamming nested elements into slots and removing the ability to style them seems off. Is it a spec issue that the contents are slots, or a browser issue that we cannot override their display even though they are in the box tree? Smarter people can enlighten me but it seems like an incorrect implementation.

Is <details> a container or an interactive element?

Lots of folks are using <details> to toggle menus open and closed. It’s a practice popularized by GitHub.

Seems reasonable. The spec sure allows it:

The details element represents a disclosure widget from which the user can obtain additional information or controls.

(Emphasis mine)

Alright, so we might expect that <details> is the container (it has an implicit role=group) and <summary> is an interactive element that sets the container’s open state. Makes sense since <summary> has an implcit button role in some contexts (but no corresponding WAI-ARIA role).

But Melanie Sumner did some digging that not only seems to contradict that, but leads to the conclusion that using <details> as a menu probably ain’t the best thing. See what happens when <details> is rendered without the <summary> element:

CodePen Embed Fallback

It does exactly what the spec suggests when it’s missing a <summary> — it makes its own:

The first summary element child of the element, if any, represents the summary or legend of the details. If there is no child summary element, the user agent should provide its own legend (e.g. “Details”).

(Emphasis mine)

Melanie ran that through an HTML validator and — surprise! — it’s invalid:

So, <details> requires the <summary>. And when <summary> is missing, <details> creates it’s own, though it’s relayed as invalid markup. It’s all hunky-dory and valid when <summary> is there:

All of which leads to a new question: why is <summary> given an implcit button role when <details> is what appears to be the interactive element? Perhaps this is another case where the browser implementation is incorrect? Then again, the spec does categorize both as interactive elements. You can see how utterly confusing all of this becomes.

Either way, Melanie’s ultimate conclusion that we ought to avoid using <details> for menus is based on how assistive tech reads and announces <details> that contain interactive elements. The element is announced, but there is no mention of interactive controls beyond that until you, er, interact with <details>. Only then will something like a list of links be announced.

Besides, content inside a collapsed <details> is excluded from in-page searching (except in Chromium browsers, which can access the collapsed content at the time of writing), making things even more difficult to find.

Should <summary> allow interactive elements?

That’s the question posed in this open thread. The idea is that something like this would be invalid:

<details> <summary><a href="...">Link element</a></summary> </details>  <details> <summary><input></summary> </details>

Scott O’Hara sums up nicely why this is an issue:

The link is not discoverable at all to JAWS when navigating with its virtual cursor. If navigating to the summary element via the Tab key, JAWS announces “example text, button” as the name and role of the element. If hitting Tab key again, JAWS again announces “example text, button” even though keyboard focus is on the link.

[…]

There is more I could go on about with the various problems different AT have with the content model for summary… but that would just extend this comment out beyond what is necessary. tldr; the summary content model produces very inconsistent and sometimes just flat out broken experiences for people using AT.

Scott opened tickets to correct this behavior in Chromium and WebKit. Thanks, Scott!

Yet, it’s valid HTML:

Scott goes further in a separate blog post. For example, he explains how slapping role=button on <summary> might seem like a reasonable fix to ensure it is consistently announced by assistive tech. That would also settle the debate over whether <summary> should allow interactive elements because buttons cannot contain interactive elements. The only problem is that Safari then treats <summary> as a standard button, which loses its expanded and collapsed states. So, the correct role is announced, but now its state is not. 🙃

Where do we go now?

Are you scared to use <details>/<summary> with all of these issues and inconsistencies? I sure am, but only insofar as to make sure that what’s in it provides the right sort of experience and expectations for users.

I’m just glad these conversations are happening and that they’re taking place in the open. Because of that, you can comment on Scott’s three proposed solutions for how the content model for <summary> is defined, upvote his tickets, and report your own issues and use cases while you’re at it. Hopefully, the better we understand how the elements are used and what we expect them to do, the better they are implemented.

More Details on `details` originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

When is it OK to Disable Text Selection?

Css Tricks - Wed, 09/14/2022 - 3:03am

Using CSS, it’s possible to prevent users from selecting text within an element using user-select: none. Now, it’s understandable why doing so might be considered “controversial”. I mean, should we be disabling standard user behaviors? Generally speaking, no, we shouldn’t be doing that. But does disabling text selection have some legitimate (albeit rare) use-cases? I think so.

In this article we’ll explore these use cases and take a look at how we can use user-select: none to improve (not hinder) user experiences. It’s also worth nothing that the user-select property has other values besides none that can be used to alter the behavior of text selection rather than disable it completely, and another value that even enforces text selection, so we’ll also take a look at those.

Possible user-select values

Let’s kick things off by running through the different user-select values and what they do.

Applying user-select: none; to an element means that its text content and nested text content won’t be functionally selectable or visually selectable (i.e. ::selection won’t work). If you were to make a selection that contained some non-selectable content, the non-selectable content would be omitted from the selection, so it’s fairly well implemented. And the support is great.

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

DesktopChromeFirefoxIEEdgeSafari4*2*10*12*3.1*Mobile / TabletAndroid ChromeAndroid FirefoxAndroidiOS Safari1051042.1*3.2*

Conversely, user-select: text makes the content selectable. You’d use this value to overwrite user-select: none.

user-select: contain is an interesting one. Applying it means that if a selection begins within the element then it must end within it too, containing it. This oddly doesn’t apply when the selection begins before the element, however, which is probably why no browser currently supports it. (Internet Explorer and earlier versions of Microsoft Edge previously supported it under the guise of user-select: element.)

With user-select: all, selecting part of the element’s content results in all of it being selected automatically. It’s all or nothing, which is very uncompromising but useful in circumstances where users are more likely to copy content to their clipboard (e.g. sharing and embedding links, code snippets, etc.). Instead of double-clicking, users will only need to click once for the content to auto-select.

Be careful, though, since this isn’t always the feature you think it is. What if users only want to select part of the content (e.g. only the font name part of a Google Fonts snippet or one part of a code snippet)? It’s still better to handle ”copy to clipboard” using JavaScript in many scenarios.

A better application of user-select: all is to ensure that quotes are copied entirely and accurately.

The behavior of user-select: auto (the initial value of user-select) depends on the element and how it’s used. You can find out more about this in our almanac.

Now let’s turn to exploring use cases for user-select: none…

Stripping non-text from the selection

When you’re copying content from a web page, it’s probably from an article or some other type of long-form content, right? You probably don’t want your selection to include images, emoji (which can sometimes copy as text, e.g. “:thinkingface:”), and other things that you might expect to find wrapped in an <aside> element (e.g. in-article calls to action, ads, or something else that’s not part of the main content).

To prevent something from being included in selections, make sure that it’s wrapped in an HTML element and then apply user-select: none to it:

<p>lorem <span style="user-select: none">🤔</span> ipsum</p> <aside style="user-select: none"> <h1>Heading</h1> <p>Paragraph</p> <a>Call to action</a> </aside>

In scenarios like this, we’re not disabling selection, but rather optimizing it. It’s also worth mentioning that selecting doesn’t necessarily mean copying — many readers (including myself) like to select content as they read it so that they can remember where they are (like a bookmark), another reason to optimize rather than disable completely.

Preventing accidental selection

Apply user-select: none to links that look like buttons (e.g. <a href="/whatever" class="button">Click Me!</a>).

It’s not possible to select the text content of a <button> or <input type="submit"> because, well, why would you? However, this behavior doesn’t apply to links because traditionally they form part of a paragraph that should be selectable.

Fair enough.

We could argue that making links look like buttons is an anti-pattern, but whatever. It’s not breaking the internet, is it? That ship has sailed anyway, so if you’re using links designed to look like buttons then they should mimic the behavior of buttons, not just for consistency but to prevent users from accidentally selecting the content instead of triggering the interaction.

I’m certainly prone to selecting things accidentally since I use my laptop in bed more than I care to admit. Plus, there are several medical conditions that can affect control and coordination, turning an intended click into an unintended drag/selection, so there are accessibility concerns that can be addressed with user-select too.

Interactions that require dragging (intentionally) do exist too of course (e.g. in browser games), but these are uncommon. Still, it just shows that user-select does in fact have quite a few use-cases.

Avoiding paywalled content theft

Paywalled content gets a lot of hate, but if you feel that you need to protect your content, it’s your content — nobody has the right steal it just because they don’t believe they should pay for it.

If you do want to go down this route, there are many ways to make it more difficult for users to bypass paywalls (or similarly, copy copyrighted content such as the published work of others).

Blurring the content with CSS:

article { filter: blur(<radius>); }

Disabling the keyboard shortcuts for DevTools:

document.addEventListener("keydown", function (e) { if (e.keyCode == 123) e.preventDefault(); else if ((e.ctrlKey || e.metaKey) && e.altKey && e.keyCode == 73) e.preventDefault(); else if ((e.ctrlKey || e.metaKey) && e.altKey && e.keyCode == 74) e.preventDefault(); else if ((e.ctrlKey || e.metaKey) && e.altKey && e.keyCode == 85) e.preventDefault(); });

Disabling access to DevTools via the context menu by disabling the context menu itself:

document.addEventListener("contextmenu", e => e.preventDefault())

And of course, to prevent users from copying the content when they’re not allowed to read it at the source, applying user-select: none:

<article style="user-select: none"> Any other use cases?

Those are the three use cases I could think of for preventing text selection. Several others crossed my mind, but they all seemed like a stretch. But what about you? Have you had to disable text selection on anything? I’d like to know!

When is it OK to Disable Text Selection? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

WebKit Features in Safari 16.0

Css Tricks - Tue, 09/13/2022 - 6:14am

Whew boy, Safari 16 is officially out in the wild and it packs in a bunch of features, some new and exciting (Subgrid! Container Queries! Font Palettes!) and others we’ve been waiting on for better cross-browser support (Motion Path! Overscroll Behavior! AVIF!). I imagine Jen Simmons typing cheerfully writing out all of the new goodies in the roundup announcement.

Source: WebKit.org

Just gonna drop in the new CSS features from the release notes:

Added size queries support for Container Queries. Chrome started supporting it in Version 105, so all we need is Firefox to join the party to get The Big Three™ covered.
Added support for Container Query Units. These units go hand-in-hand with Container Queries. Once again, we need Firefox.
Added support for Subgrid. Now it’s Safari and Firefox with support coverage. The good news is that Chrome is currently developing it as well.
Added support for animatable Grids. Very cool! Chrome has always had some implementation of this and Firefox started supporting it back in 2019.
Added support for Offset Path. This is also known as Motion Path, and we’ve had broad browser support since 2020. It’s nice to see Safari on board.
Added support for Overscroll Behavior. Now we can modify “scroll chaining” and overflow affordances with the overscroll-behavior property.
Added support for text-align-last. Now we’re all set with cross-browser support for this property!
Added support for the resolution media query. All set here as well!

There are quite a few nice updates to Safari’s developer tools, too. We’ve got a Flexbox inspector, a Timelines tab (with an experimental screenshots timeline), and Container Queries info, to name a few. There’s a full 32-minute video that walks through everything, too.

I thought Safari 15 was a pretty killer release, but 16 is pretty epic in comparison. I know there’s a “Safari is the new Internet Explorer” vibe in some circles, but I’m happy to see big jumps like this and appreciate all the forward momentum. Go Safari Team!

To Shared Link — Permalink on CSS-Tricks

WebKit Features in Safari 16.0 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

How I Made a Pure CSS Puzzle Game

Css Tricks - Fri, 09/09/2022 - 3:21am

I recently discovered the joy of creating CSS-only games. It’s always fascinating how HTML and CSS are capable of handling the logic of an entire online game, so I had to try it! Such games usually rely on the ol’ Checkbox Hack where we combine the checked/unchecked state of a HTML input with the :checked pseudo-class in CSS. We can do a lot of magic with that one combination!

In fact, I challenged myself to build an entire game without Checkbox. I wasn’t sure if it would be possible, but it definitely is, and I’m going to show you how.

In addition to the puzzle game we will study in this article, I have made a collection of pure CSS games, most of them without the Checkbox Hack. (They are also available on CodePen.)

Want to play before we start?

I personally prefer playing the game in full screen mode, but you can play it below or open it up over here.

CodePen Embed Fallback

Cool right? I know, it’s not the Best Puzzle Game You Ever Saw™ but it’s also not bad at all for something that only uses CSS and a few lines of HTML. You can easily adjust the size of the grid, change the number of cells to control the difficulty level, and use whatever image you want!

We’re going to remake that demo together, then put a little extra sparkle in it at the end for some kicks.

The drag and drop functionality

While the structure of the puzzle is fairly straightforward with CSS Grid, the ability to drag and drop puzzle pieces is a bit trickier. I had to relying on a combination of transitions, hover effects, and sibling selectors to get it done.

CodePen Embed Fallback

If you hover over the empty box in that demo, the image moves inside of it and stays there even if you move the cursor out of the box. The trick is to add a big transition duration and delay — so big that the image takes lots of time to return to its initial position.

img { transform: translate(200%); transition: 999s 999s; /* very slow move on mouseout */ } .box:hover img { transform: translate(0); transition: 0s; /* instant move on hover */ }

Specifying only the transition-delay is enough, but using big values on both the delay and the duration decreases the chance that a player ever sees the image move back. If you wait for 999s + 999s — which is approximately 30 minutes — then you will see the image move. But you won’t, right? I mean, no one’s going to take that long between turns unless they walk away from the game. So, I consider this a good trick for switching between two states.

Did you notice that hovering the image also triggers the changes? That’s because the image is part of the box element, which is not good for us. We can fix this by adding pointer-events: none to the image but we won’t be able to drag it later.

That means we have to introduce another element inside the .box:

CodePen Embed Fallback

That extra div (we’re using a class of .a) will take the same area as the image (thanks to CSS Grid and grid-area: 1 / 1) and will be the element that triggers the hover effect. And that is where the sibling selector comes into play:

.a { grid-area: 1 / 1; } img { grid-area: 1 / 1; transform: translate(200%); transition: 999s 999s; } .a:hover + img { transform: translate(0); transition: 0s; }

Hovering on the .a element moves the image, and since it is taking up all space inside the box, it’s like we are hovering over the box instead! Hovering the image is no longer a problem!

Let’s drag and drop our image inside the box and see the result:

Did you see that? You first grab the image and move it to the box, nothing fancy. But once you release the image you trigger the hover effect that moves the image, and then we simulate a drag and drop feature. If you release the mouse outside the box, nothing happens.

Hmm, your simulation isn’t perfect because we can also hover the box and get the same effect.

True and we will rectify this. We need to disable the hover effect and allow it only if we release the image inside the box. We will play with the dimension of our .a element to make that happen.

CodePen Embed Fallback

Now, hovering the box does nothing. But if you start dragging the image, the .a element appears, and once released inside the box, we can trigger the hover effect and move the image.

Let’s dissect the code:

.a { width: 0%; transition: 0s .2s; /* add a small delay to make sure we catch the hover effect */ } .box:active .a { /* on :active increase the width */ width: 100%; transition: 0s; /* instant change */ } img { transform: translate(200%); transition: 999s 999s; } .a:hover + img { transform: translate(0); transition: 0s; }

Clicking on the image fires the :active pseudo-class that makes the .a element full-width (it is initially equal to 0). The active state will remain active until we release the image. If we release the image inside the box, the .a element goes back to width: 0, but we will trigger the hover effect before it happens and the image will fall inside the box! If you release it outside the box, nothing happens.

There is a little quirk: clicking the empty box also moves the image and breaks our feature. Currently, :active is linked to the .box element, so clicking on it or any of its children will activate it; and by doing this, we end up showing the .a element and triggering the hover effect.

We can fix that by playing with pointer-events. It allows us to disable any interaction with the .box while maintaining the interactions with the child elements.

.box { pointer-events: none; } .box * { pointer-events: initial; } CodePen Embed Fallback

Now our drag and drop feature is perfect. Unless you can find how to hack it, the only way to move the image is to drag it and drop it inside the box.

Building the puzzle grid

Putting the puzzle together is going to feel easy peasy compared to what we just did for the drag and drop feature. We are going to rely on CSS grid and background tricks to create the puzzle.

Here’s our grid, written in Pug for convenience:

- let n = 4; /* number of columns/rows */ - let image = "https://picsum.photos/id/1015/800/800"; g(style=`--i:url(${image})`) - for(let i = 0; i < n*n; i++) z a b(draggable="true")

The code may look strange but it compiles into plain HTML:

I bet you’re wondering what’s up with those tags. None of these elements have any special meaning — I just find that the code is much easier to write using <z> than a bunch of <div class="z"> or whatever.

This is how I’ve mapped them out:

<g> is our grid container that contains N*N <z> elements.
<z> represents our grid items. It plays the role of the .box element we saw in the previous section.
<a> triggers the hover effect.
<b> represents a portion of our image. We apply the draggable attribute on it because it cannot be dragged by default.

Alright, let’s register our grid container on <g>. This is in Sass instead of CSS:

$n : 4; /* number of columns/rows */ g { --s: 300px; /* size of the puzzle */ display: grid; max-width: var(--s); border: 1px solid; margin: auto; grid-template-columns: repeat($n, 1fr); }

We’re actually going to make our grid children — the <z> elements — grids as well and have both <a> and <b> within the same grid area:

z { aspect-ratio: 1; display: grid; outline: 1px dashed; } a { grid-area: 1/1; } b { grid-area: 1/1; }

As you can see, nothing fancy — we created a grid with a specific size. The rest of the CSS we need is for the drag and drop feature, which requires us to randomly place the pieces around the board. I’m going to turn to Sass for this, again for the convenience of being able to loop through and style all the puzzle pieces with a function:

b { background: var(--i) 0/var(--s) var(--s); } @for $i from 1 to ($n * $n + 1) { $r: (random(180)); $x: (($i - 1)%$n); $y: floor(($i - 0.001) / $n); z:nth-of-type(#{$i}) b{ background-position: ($x / ($n - 1)) * 100% ($y / ($n - 1)) * 100%; transform: translate((($n - 1) / 2 - $x) * 100%, (($n - 1)/2 - $y) * 100%) rotate($r * 1deg) translate((random(100)*1% + ($n - 1) * 100%)) rotate((random(20) - 10 - $r) * 1deg) } }

You may have noticed that I’m using the Sass random() function. That’s how we get the randomized positions for the puzzle pieces. Remember that we will disable that position when hovering over the <a> element after dragging and dropping its corresponding <b> element inside the grid cell.

z a:hover ~ b { transform: translate(0); transition: 0s; }

In that same loop, I am also defining the background configuration for each piece of the puzzle. All of them will logically share the same image as the background, and its size should be equal to the size of the whole grid (defined with the --s variable). Using the same background-image and some math, we update the background-position to show only a piece of the image.

That’s it! Our CSS-only puzzle game is technically done!

CodePen Embed Fallback

But we can always do better, right? I showed you how to make a grid of puzzle piece shapes in another article. Let’s take that same idea and apply it here, shall we?

Puzzle piece shapes

Here’s our new puzzle game. Same functionality but with more realistic shapes!

CodePen Embed Fallback

This is an illustration of the shapes on the grid:

If you look closely you’ll notice that we have nine different puzzle-piece shapes: the four corners, the four edges, and one for everything else.

The grid of puzzle pieces I made in the other article I referred to is a little more straightforward:

CodePen Embed Fallback

We can use the same technique that combines CSS masks and gradients to create the different shapes. In case you are unfamiliar with mask and gradients, I highly recommend checking that simplified case to better understand the technique before moving to the next part.

First, we need to use specific selectors to target each group of elements that shares the same shape. We have nine groups, so we will use eight selectors, plus a default selector that selects all of them.

z /* 0 */ z:first-child /* 1 */ z:nth-child(-n + 4):not(:first-child) /* 2 */ z:nth-child(5) /* 3 */ z:nth-child(5n + 1):not(:first-child):not(:nth-last-child(5)) /* 4 */ z:nth-last-child(5) /* 5 */ z:nth-child(5n):not(:nth-child(5)):not(:last-child) /* 6 */ z:last-child /* 7 */ z:nth-last-child(-n + 4):not(:last-child) /* 8 */

Here is a figure that shows how that maps to our grid:

Now let’s tackle the shapes. Let’s focus on learning just one or two of the shapes because they all use the same technique — and that way, you have some homework to keep learning!

For the puzzle pieces in the center of the grid, 0:

mask: radial-gradient(var(--r) at calc(50% - var(--r) / 2) 0, #0000 98%, #000) var(--r) 0 / 100% var(--r) no-repeat, radial-gradient(var(--r) at calc(100% - var(--r)) calc(50% - var(--r) / 2), #0000 98%, #000) var(--r) 50% / 100% calc(100% - 2 * var(--r)) no-repeat, radial-gradient(var(--r) at var(--r) calc(50% - var(--r) / 2), #000 98%, #0000), radial-gradient(var(--r) at calc(50% + var(--r) / 2) calc(100% - var(--r)), #000 98%, #0000);

The code may look complex, but let’s focus on one gradient at a time to see what’s happening:

CodePen Embed Fallback

Two gradients create two circles (marked green and purple in the demo), and two other gradients create the slots that other pieces connect to (the one marked blue fills up most of the shape while the one marked red fills the top portion). A CSS variable, --r, sets the radius of the circular shapes.

The shape of the puzzle pieces in the center (marked 0 in the illustration) is the hardest to make as it uses four gradients and has four curvatures. All the others pieces juggle fewer gradients.

For example, the puzzle pieces along the top edge of the puzzle (marked 2 in the illustration) uses three gradients instead of four:

mask: radial-gradient(var(--r) at calc(100% - var(--r)) calc(50% + var(--r) / 2), #0000 98%, #000) var(--r) calc(-1 * var(--r)) no-repeat, radial-gradient(var(--r) at var(--r) calc(50% - var(--r) / 2), #000 98%, #0000), radial-gradient(var(--r) at calc(50% + var(--r) / 2) calc(100% - var(--r)), #000 98%, #0000); CodePen Embed Fallback

We removed the first (top) gradient and adjusted the values of the second gradient so that it covers the space left behind. You won’t notice a big difference in the code if you compare the two examples. It should be noted that we can find different background configurations to create the same shape. If you start playing with gradients you will for sure come up with something different than what I did. You may even write something that’s more concise — if so, share it in the comments!

In addition to creating the shapes, you will also find that I am increasing the width and/or the height of the elements like below:

height: calc(100% + var(--r)); width: calc(100% + var(--r));

The pieces of the puzzle need to overflow their grid cell to connect.

Final demo

Here is the full demo again. If you compare it with the first version you will see the same code structure to create the grid and the drag-and-drop feature, plus the code to create the shapes.

CodePen Embed Fallback Play it online Possible enhancements

The article ends here but we could keep enhancing our puzzle with even more features! How about a a timer? Or maybe some sort of congratulations when the player finishes the puzzle?

I may consider all these features in a future version, so keep an eye on my GitHub repo.

Wrapping up

And CSS isn’t a programming language, they say. Ha!

I’m not trying to spark some #HotDrama by that. I say it because we did some really tricky logic stuff and covered a lot of CSS properties and techniques along the way. We played with CSS Grid, transitions, masking, gradients, selectors, and background properties. Not to mention the few Sass tricks we used to make our code easy to adjust.

The goal was not to build the game, but to explore CSS and discover new properties and tricks that you can use in other projects. Creating an online game in CSS is a challenge that pushes you to explore CSS features in great detail and learn how to use them. Plus, it’s just a lot of fun that we get something to play with when all is said and done.

Whether CSS is a programming language or not, doesn’t change the fact that we always learn by building and creating innovative stuff.

How I Made a Pure CSS Puzzle Game originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

What’s New With Forms in 2022?

Css Tricks - Thu, 09/08/2022 - 3:12am

Browsers are constantly adding new HTML, JavaScript and CSS features. Here are some useful additions to working with forms that you might have missed…

requestSubmit()

Safari 16 will be the final browser to add support for requestSubmit.

Before we look at how .requestSubmit() works, let’s remind ourselves how programmatically submitting a form with JavaScript works when using the .submit() method. Submitting a form with submit() does not trigger a submit event. So in the following code, the form is submitted, preventDefault() has no effect, and nothing is logged to the console:

const form = document.forms[0]; form.addEventListener('submit', function(event) { // code to submit the form goes here event.preventDefault(); console.log('form submitted!'); }); document.querySelector('.btn').addEventListener('click', function() { form.submit(); })

.submit() will also ignore any HTML form validation. Given the following markup, the form will be submitted when the input is empty even though the input has a required attribute:

.requestSubmit() is an alternative way to submit a form using JavaScript, but in contrast to .submit(), HTML form validation will prevent the form from being submitted. If all the data entered in the form passes validation, the submit event will be fired, meaning “form submitted!” would be logged to the console in the following example:

form.addEventListener('submit', function(event) { event.preventDefault(); console.log('form submitted!'); }); document.querySelector('.btn').addEventListener('click', function() { form.requestSubmit(); })

You could already achieve this by programmatically clicking the form’s submit button, but requestSubmit is perhaps a more elegant solution.

submitter property of submit event

The SubmitEvent.submitter property gained full cross-browser support with the release of Safari 15.4. This read-only property specifies the <button> or <input type="submit"> element that caused a form to be submitted.

When you have multiple submit buttons or inputs, each with a different value, only the value of the button or input that was clicked on to submit the form will be sent to the server, rather than both values. That’s nothing new. What is new is that the event listener for the submit event now has access to the event.submitter property. You can use this to add a class to the button or input that triggered the form submission, for example, or to obtain its value or any other of its HTML attributes.

document.forms[0].addEventListener('submit', function(event) { event.preventDefault(); console.log(event.submitter.value); console.log(event.submitter.formaction); event.submitter.classList.add('spinner-animation'); }) formdata event

This isn’t particularly new, but only achieved cross-browser support with the release of Safari 15. The main use case for the formdata event is enabling custom elements to take part in form submissions. Outside of web components, though, it can still be useful.

You add a formdata event listener to the form you want to interact with:

document.querySelector('form').addEventListener('formdata', handleFormdata);

The event is fired both by a regular HTML form submission and also by an occurrence of new FormData(). event.formData holds all of the data being submitted.

function handleFormdata(event) { for (const entry of event.formData.values()) { console.log(entry); } }

The callback function for the formdata event listener runs before the data is sent to the server, giving you a chance to add to or modify the data being sent.

function handleFormdata(event) { event.formData.append('name', 'John'); }

You could have modified or appended the FormData inside the submit event handler but formdata allows you to separate out the logic. It’s also an alternative to using hidden inputs in the markup of your form in cases where you are submitting the form “the old fashioned way” — i.e. relying on the built-in functionality of HTML to submit the form rather than doing it with fetch.

showPicker() for input elements

showPicker() has been supported since Chrome 99, Firefox 101, and in the upcoming Safari 16. For an input element whose type attribute is either Date, Month, Week, Time, datetime-local, color, or file, showPicker() provides a programmatic way to display the selection UI. For color and file inputs, it’s always been possible to programmatically show the picker by calling .click on the input:

document.querySelector('input[type="color"]').click();

That approach doesn’t work on date inputs, which is why this new API was added. .showPicker() will also work with color and file inputs but there’s no real advantage to using it over .click().

Inert attribute

It’s always been possible to disable multiple inputs at once by wrapping them in a HTML fieldset and disabling the fieldset:

CodePen Embed Fallback

Inert is a new HTML attribute. It isn’t only for forms, but forms are certainly a key use-case. Unlike the disabled attribute, inert can be applied to a form element itself. Everything within the form will be non-focusable and non-clickable. When it comes to assistive technologies, inert is similar to setting aria-hidden="true". Unlike the disabled attribute, inert does not apply any styling by default, but it’s easy to add your own:

form[inert] { opacity: .2; } CodePen Embed Fallback There’s more to come…

The big one is styling <select> elements, something developers have wanted for decades. It looks set to finally become a reality sometime soon with the introduction of selectmenu.

But that’s it for now! The recent updates bring full browser support to form features we’ve been waiting for, making them prime for production use.

What’s New With Forms in 2022? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

Overlapping Bar Charts

Css Tricks - Wed, 09/07/2022 - 3:46am

As the name suggests, overlapping charts visualize two different sets of data in a single diagram. The idea is that the overlapping bars allow us to compare data, say, year-over-year. They are also useful for things like tracking progress for a goal where one bar represents the goal and the other shows the current amount.

But they’re beautiful too!

Your mind is probably like mine and is already starting to figure out how you’d go off and code that. Here’s how I tackled it.

CodePen Embed Fallback The HTML

We’re going to start with markup because, well, that’s how we know what needs styling.

We will be using description lists (<dl>) as it is a much more semantic approach as compared to standard ordered and unordered lists. Another reason is that we are including a label within each bar. Normal lists do not have a tag within them to add a title or description unlike definition lists. In simple terms, it just makes more sense and is more readable too.

The first description list, .numbers, is the y-axis. The .bars is where the data is visualized and I’ve made a definition list to build the x-axis as well. Each list item contains a .bar and the label as a description term (dt).

And what’s up with the data attribute? The data-percentage is being used to specify the height of the bar, which ultimately represents its value on the y-axis. We could manually set it in CSS for each bar, but that is repetitive and a lot of extra code that can be replaced with a few lines of CSS.

The basic chart styles

We’re working with a lot of two-dimensional directions, so flexbox is going to be our friend for getting everything lined up. We can make the .chart element a flexible container that positions the y-axis labels and the chart beside one another in the row direction.

.chart { display: flex; }

We don’t even need to specify the direction since flexbox defaults to row. Let’s do that and then add flexbox to the list of labels along the y-axis while we’re at it since we know those will run in the column direction.

.numbers { display: flex; flex-direction: column; list-style: none; margin: 0 15px 0 0; padding: 0; } CodePen Embed Fallback

Believe it or not, we can use flexbox again for the bars since, they too, are running in a row direction.

.bars { display: flex; flex: auto; /* fill up the rest of the `.chart` space */ gap: 60px; }

I’ve set this up so that the .bars automatically take up whatever space is leftover by the y-axis .numbers.

You probably noticed it in the HTML, but “bar” is actually two bars where one overlaps the other. I wrapped those in a generic <div> that we can use as yet another flexible container that holds the definition term (<dt>) we’re using as a label and the description details (<dd>) that holds both bar values:

.bars > div { align-items: center; display: flex; flex-direction: column; flex: 1; position: relative; }

Each bar is going to be the same width, hence flex: 1. We’re relatively positioning the element while we’re at it because we’re about to absolutely position each bar and we want to make sure they stay in their containers.

CodePen Embed Fallback

Each bar has a percentage height that corresponds to the values along the vertical y-axis. You may also remember that we gave each bar a data-percentage attribute — we’re going to sprinkle in a little JavaScript that sets the height of each bar using those values.

var bars = document.querySelectorAll("dd .bar"); bars.forEach((bar) => { var height = bar.getAttribute("data-percentage"); bar.style.height = height + "%"; });

That’s our basic chart!

CodePen Embed Fallback

We want to get this to where we can see the bars overlapping one another. That’s next!

Overlapping bars

The trick to get one bar to overlap another is funny because we’re often trying to prevent things from overlapping visually in CSS. But in this case, we actually want that to happen.

The bars are already overlapping; it’s just tough to tell. Notice in the HTML that the second .bar in each set has an additional .overlap class. Let’s use that to differentiate the bars. You’re totally free to choose your own styling for this. I’m adding a little padding to the .overlap bars so that they are wider than the other bars. Then I’m tweaking the stacking order using z-index so that the .overlap bars sit below the other bars.

CodePen Embed Fallback Let’s add a legend

Legend. Such a great word, isn’t it? Packed with all kinds of meaning. In this case, it’s a more than a nice touch because, visually, we’re jamming two bars in spaces that are typically reserved for one bar. A legend provides context that explains what each bar represents.

<figure class="legend"> <div class="type1">Estimate</div> <div class="type2">Actual</div> </figure>

Using a <figure> feels correct to me. They’re often used to wrap images, but the spec says they’re used “to annotate illustrations, diagrams, photos, code listings, etc.” and we’re working with a diagram. We could probably use an unordered list to hold the items, but I went with an unsemantic <div>. If anyone has an opinion on the best way to mark this up, I’m all ears in the comments!

Once again, styling is totally up to you:

CodePen Embed Fallback Accessibility considerations

We’ve spent a bunch of our effort on making decisions for the markup and styling of our overlapping bar chart. It’s great so far, but we’re definitely not done because there’s more we can do to make this a more accessible experience. Not everyone is a sighted web surfer, so there’s some additional work to do to convey the content in those contexts.

Specifically, we need to:

check that our colors have plenty of contrast between them,
allow keyboard users to tab to each overlapping bar, and
make sure screen readers announce the content.

Color contrasts

We need enough contrast between:

the overlapping bars
the bars and the chart background
the label text and background

I did a little homework in advance on the colors I used in the examples we’ve look at so far, making sure that there is enough contrast between the foregrounds and backgrounds to achieve WCAG AA compliance.

Here’s what I’m using:

Overlapping bars: (#25DEAA and #696969: 3.16:1 ratio)
Bars and chart background (#696969 and #111: 3.43:1 ratio)
Y-axis label text and background (#fff and #333: 12.63: 1 ratio)

Tabbing between bars

To get this where keyboard users can select each individual bar with the Tab key, we can reach for the HTML tabindex attribute. We can use the following JavaScript inside the for-each function to add this property to each bar (both of them). We will set the tab index to 0:

bar.setAttribute("tabindex", 0);

We can also add some CSS to improve the outline when the bar is selected while we’re at it:

.bar:focus { outline: 1.5px solid #f1f1f1; } Announcing content on screen readers

Another important aspect of accessibility is making sure screen readers can announce the bars and their percentages.

We’re working with two different charts in one: a chart that shows “Estimated” values and another that shows “Actual” values. It’d be great if the user knew which bar was being announced, so let’s label them with the aria-label attribute:

Notice that we have the bar’s value directly in the HTML as well. That will get announced, but we still want to visually hide it. We could use transparent text for that, but another way is to use the classic .visually-hidden trick by wrapping the value in span:

<div class="bar" data-percentage="50" aria-label="Estimate"> <span class="visually-hidden">50%</span> </div> .visually-hidden { clip: rect(0 0 0 0); clip-path: inset(50%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; }

While we’re talking about announcing content, we can probably prevent the y-axis labels from being read. It’s not like the user is missing information, as the actual percentages for each bar are already available and announced. We can use the aria-hidden attribute for that:

I also think it’s OK for screen readers to ignore the legend since it’s a visual aid:

<figure class="legend" aria-hidden="true"> <div class="type1">Estimate</div> <div class="type2">Actual</div> </figure> The final demo CodePen Embed Fallback That’s a wrap!

There we go, a chart with overlapping bars! It’s a nice way to compare data and I hope you can find a use for it on some project.

Are there other ways we could have approached this? Of course! Everything we covered here is merely walking you through my thought process. I imagine some of you would have taken a different approach — if that’s you, please share! It’d be great to see other CSS layout techniques and perspectives on nailing the accessibility.

Overlapping Bar Charts originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

Steven Heller’s Font of the Month: Farandole & Lustik

Typography - Tue, 09/06/2022 - 9:33pm

Read the book, Typographic Firsts

This month it's Font of the Month with an s! Yes, Steve heller takes a look at two unorthodox layer font families from rising French star Francis Chouquet. Vive la play!

The post Steven Heller’s Font of the Month: Farandole & Lustik appeared first on I Love Typography.

Categories: Front End Web Development

Hacking CSS Animation State and Playback Time

Css Tricks - Tue, 09/06/2022 - 8:00am

CSS-only Wolfenstein is a little project that I made a few weeks ago. It was an experiment with CSS 3D transformations and animations.

Inspired by the FPS demo and another Wolfenstein CodePen, I decided to build my own version. It is loosely based on Episode 1 – Floor 9 of the original Wolfenstein 3D game.

CodePen Embed Fallback

Editor: This game intentionally requires some quick reaction to avoid a Game Over screen.

Here is a playthrough video:

In a nutshell, my project is nothing but a carefully scripted long CSS animation. Plus a few instances of the checkbox hack.

:checked ~ div { animation-name: spin; }

The environment consists of 3D grid faces and the animations are mostly plain 3D translations and rotations. Nothing really fancy.

However, two problems were particularly tricky to solve:

Play the “weapon firing” animation whenever the player clicks on an enemy.
When the fast-moving boss got the last hit, enter a dramatic slow motion.

At a technical-level, this meant:

Replay an animation when the next checkbox is checked.
Slow down an animation, when a checkbox is checked.

In fact, neither was properly solved in my project! I either ended up using workarounds or just gave up.

On the other hand, after some digging, eventually I found the key to both problems: altering the properties of running CSS animations. In this article, we will explore further on this topic:

Lots of interactive examples.
Dissections: how does each example work (or not work)?
Behind-the-scene: how do browsers handle animation states?

Let me “toss my bricks”.

Problem 1: Replaying Animation The first example: “just another checkbox”

My first intuition was “just add another checkbox”, which does not work:

CodePen Embed Fallback

Each checkbox works individually, but not both together. If one checkbox is already checked, the other no longer works.

Here’s how it works (or “does not work”):

The animation-name of <div> is none by default.
The user clicks on one checkbox, animation-name becomes spin, and the animation starts from the beginning.
After a while, the user clicks on the other checkbox. A new CSS rule takes effect, but animation-name is still spin, which means no animation is added nor removed. The animation simply continues playing as if nothing happened.

The second example: “cloning the animation”

One working approach is to clone the animation:

#spin1:checked ~ div { animation-name: spin1; } #spin2:checked ~ div { animation-name: spin2; } CodePen Embed Fallback

Here’s how it works:

animation-name is none initially.
The user clicks on “Spin!”, animation-name becomes spin1. The animation spin1 is started from the beginning because it was just added.
The user clicks on “Spin again!”, animation-name becomes spin2. The animation spin2 is started from the beginning because it was just added.

Note that in Step #3, spin1 is removed because of the order of the CSS rules. It won’t work if “Spin again!” is checked first.

The third example: “appending the same animation”

Another working approach is to “append the same animation”:

#spin1:checked ~ div { animation-name: spin; } #spin2:checked ~ div { animation-name: spin, spin; } CodePen Embed Fallback

This is similar to the previous example. You can actually understand the behavior this way:

#spin1:checked ~ div { animation-name: spin1; } #spin2:checked ~ div { animation-name: spin2, spin1; }

Note that when “Spin again!” is checked, the old running animation becomes the second animation in the new list, which could be unintuitive. A direct consequence is: the trick won’t work if animation-fill-mode is forwards. Here’s a demo:

CodePen Embed Fallback

If you wonder why this is the case, here are some clues:

animation-fill-mode is none by default, which means “The animation has no effect at all if not playing”.
animation-fill-mode: forwards; means “After the animation finishes playing, it must stay at the last keyframe forever”.
spin1’s decision always override spin2’s because spin1 appears later in the list.
Suppose the user clicks on “Spin!”, waits for a full spin, then clicks on “Spin again!”. At this moment. spin1 is already finished, and spin2 just starts.

Discussion

Rule of thumb: you cannot “restart” an existing CSS animation. Instead, you want to add and play a new animation. This may be confirmed by the W3C spec:

Once an animation has started it continues until it ends or the animation-name is removed.

Now comparing the last two examples, I think in practice, “cloning animations” should often work better, especially when CSS preprocessor is available.

Problem 2: Slow Motion

One might think that slowing an animation is just a matter of setting a longer animation-duration:

div { animation-duration: 0.5s; } #slowmo:checked ~ div { animation-duration: 1.5s; }

Indeed, this works:

CodePen Embed Fallback

… or does it?

With a few tweaks, it should be easier to see the issue.

CodePen Embed Fallback

Yes, the animation is slowed down. And no, it does not look good. The dog (almost) always “jumps” when you toggle the checkbox. Furthermore, the dog seems to jump to a random position rather than the initial one. How come?

It would be easier to understand it if we introduced two “shadow elements”:

CodePen Embed Fallback

Both shadow elements are running the same animations with different animation-duration. And they are not affected by the checkbox.

When you toggle the checkbox, the element just immediately switches between the states of two shadow elements.

Quoting the W3C spec:

Changes to the values of animation properties while the animation is running apply as if the animation had those values from when it began.

This follows the stateless design, which allows browsers to easily determine the animated value. The actual calculation is described here and here.

Another Attempt

One idea is to pause the current animation, then add a slower animation that takes over from there:

div { animation-name: spin1; animation-duration: 2s; } #slowmo:checked ~ div { animation-name: spin1, spin2; animation-duration: 2s, 5s; animation-play-state: paused, running; }

So it works:

CodePen Embed Fallback

… or does it?

It does slow down when you click on “Slowmo!”. But if you wait for a full circle, you will see a “jump”. Actually, it always jumps to the position when “Slowmo!” is clicked on.

The reason is we don’t have a from keyframe defined – and we shouldn’t. When the user clicks on “Slowmo!”, spin1 is paused at some position, and spin2 starts at exactly the same position. We simply cannot predict that position beforehand … or can we?

A Working Solution

We can! By using a custom property, we can capture the angle in the first animation, then pass it to the second animation:

div { transform: rotate(var(--angle1)); animation-name: spin1; animation-duration: 2s; } #slowmo:checked ~ div { transform: rotate(var(--angle2)); animation-name: spin1, spin2; animation-duration: 2s, 5s; animation-play-state: paused, running; } @keyframes spin1 { to { --angle1: 360deg; } } @keyframes spin2 { from { --angle2: var(--angle1); } to { --angle2: calc(var(--angle1) + 360deg); } } CodePen Embed Fallback

Note: @property is used in this example, which is not supported by all browsers.

The “Perfect” Solution

There is a caveat to the previous solution: “exiting slowmo” does not work well.

Here is a better solution:

CodePen Embed Fallback

In this version, slow motion can be entered or exited seamlessly. No experimental feature is used either. So is it the perfect solution? Yes and no.

This solution works like “shifting” “gears”:

Gears: there are two <div>s. One is the parent of the other. Both have the spin animation but with different animation-duration. The final state of the element is the accumulation of both animations.
Shifting: At the beginning, only one <div> has its animation running. The other is paused. When the checkbox is toggled, both animations swap their states.

While I really like the result, there is one problem: it is a nice exploit of the spin animation, which does not work for other types of animations in general.

A Practical Solution (with JS)

For general animations, it is possible to achieve the slow motion function with a bit of JavaScript:

CodePen Embed Fallback

A quick explanation:

A custom property is used to track the animation progress.
The animation is “restarted” when the checkbox is toggled.
The JS code computes the correct animation-delay to ensure a seamless transition. I recommend this article if you are not familiar with negative values of animation-delay.

You can view this solution as a hybrid of “restarting animation” and the “gear-shifting” approach.

Here it is important to track the animation progress correctly. Workarounds are possible if @property is not available. As an example, this version uses z-index to track the progress:

CodePen Embed Fallback

Side-note: originally, I also tried to create a CSS-only version but did not succeed. While not 100% sure, I think it is because animation-delay is not animatable.

Here is a version with minimal JavaScript. Only “entering slowmo” works.

CodePen Embed Fallback

Please let me know if you manage to create a working CSS-only version!

Slow-mo Any Animation (with JS)

Lastly, I’d like to share a solution that works for (almost) any animation, even with multiple complicated @keyframes:

CodePen Embed Fallback

Basically, you need to add an animation progress tracker, then carefully compute animation-delay for the new animation. However, sometimes it could be tricky (but possible) to get the correct values.

For example:

animation-timing-function is not linear.
animation-direction is not normal.
multiple values in animation-name with different animation-duration’s and animation-delay’s.

This method is also described here for the Web Animations API.

Acknowledgments

I started down this path after encountering CSS-only projects. Some were delicate artwork, and some were complex contraptions. My favorites are those involving 3D objects, for example, this bouncing ball and this packing cube.

In the beginning, I had no clue how these were made. Later I read and learned a lot from this nice tutorial by Ana Tudor.

As it turned out, building and animating 3D objects with CSS is not much different from doing it with Blender, just with a bit different flavor.

Conclusion

In this article we examined the behavior of CSS animations when an animate-* property is altered. Especially we worked out solutions for “replaying an animation” and “animation slow-mo”.

I hope you find this article interesting. Please let me know your thoughts!

Hacking CSS Animation State and Playback Time originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

Flutter For Front-End Web Developers

Css Tricks - Mon, 09/05/2022 - 10:10am

I started as a front-end web developer and then became a Flutter developer. I think there were some concepts that helped me adopt Flutter easier. There were also some new concepts that were different.

In this article, I want to share my experience and inspire anyone feeling paralyzed with choosing one ecosystem over the other by showing how concepts transfer over and any new concepts are learnable.

Concepts That Transferred Over

This section shows places where front-end web development and Flutter resemble. It explains skills that you already have that are an advantage to you if you start Flutter.

1. Implementing User Interfaces (UIs)

To implement a given UI in front-end web, you compose HTML elements and style them with CSS. To implement UIs in Flutter, you compose widgets and style them with properties.

Like CSS, the Color class in Dart works with “rgba” and “hex”. Also like CSS, Flutter uses pixels for space and size units.

In Flutter, we have Dart classes and enums for almost all CSS properties and their values. For example:

Flutter also has Column and Row widgets. These are the Flutter equivalent for display: flex in CSS. To configure justify-content and align-items styles, you use MainAxisAlignment and CrossAxisAlignment properties. To adjust the flex-grow style, wrap the affected child(ren) widget(s) of the Column/Row, in an Expanded or Flexible.

For the advanced UIs, Flutter has the CustomPaint class – it is to Flutter what the Canvas API is to web development. CustomPaint gives you a painter to draw any UI as you wish. You will usually use CustomPaint when you want something that is really complex. Also, CustomPaint is the go-to way when a combination of widgets doesn’t work.

2. Developing For Multiple Screen Resolutions

Websites run on browsers and mobile apps run on devices. As such, while developing for either platform, you have to keep the platform in mind. Each platform implements the same features (camera, location, notifications, etc.) in different ways.

As a web developer, you think about your website’s responsiveness. You use media queries to handle what your website looks like in smaller and wider screens.

Coming over from mobile web development to Flutter, you have the MediaQuery helper class. The MediaQuery class gives you the current device orientation (landscape or portrait). It also gives you the current viewport size, the devicePixelRatio, among other device info. Together, these values give you insights about the mobile device’s configuration. You can use them to change what your mobile app looks like at various screen sizes.

3. Working with Debuggers, Editors, and Command Line Tools

Desktop browsers have developer tools. These tools include an inspector, a console, a network monitor, etc. These tools improve the web development process. Flutter too has its own DevTools. It has its widget inspector, debugger, network monitor, among other features.

IDE support is also similar. Visual Studio Code is one of the most popular IDE for web development. There are many web-related extensions for VS Code. Flutter too supports VS Code. So while transitioning, you don’t need to change IDE. There are Dart and Flutter extensions for VS Code. Flutter also works well with Android Studio. Both Android Studio and VS Code support Flutter DevTools. These IDE integrations make Flutter tooling complete.

Most front-end JavaScript frameworks come with their command-line interface (CLI). For example: Angular CLI, Create React App, Vue CLI, etc. Flutter also comes with an exclusive CLI. The Flutter CLI permits you to build, create, and develop Angular projects. It has commands for analyzing and testing Flutter projects.

Concepts That Were New

This section talks about Flutter-specific concepts that are easier or non-existent in web development. It explains ideas you should keep in mind as you enter Flutter.

How To Handle Scrolling

When developing for the web, default scrolling behavior is handled by web browsers. Yet, you are free to customize scrolling with CSS (using overflow).

This is not the case in Flutter. Widget groups don’t scroll by default. When you sense that widget groups might overflow, you have to proactively configure scrolling.

In Flutter, you configure scrolling by using peculiar widgets that permit scrolling. For example: ListView, SingleChildScrollView, CustomScrollView, etc. These scrollable widgets give you great control over scrolling. With CustomScrollView, you can configure expert and complex scroll mechanisms within the application.

On Flutter’s side, using ScrollViews is inevitable. Android and iOS have ScrollView and UIScrollView to handle scrolling. Flutter needs a way to unify the rendering and developer experience by using its ScrollViews, too.

It may help to stop thinking about the flow of document structure and instead consider the application as an open canvas for a device’s native painting mechanisms.

2. Setting Up Your Development Environment

To create the simplest website, you can create a file with a .html extension and open it in a browser. Flutter is not that simple. To use Flutter, you need to have installed the Flutter SDK and have configured Flutter for a test device. So if you want to code Flutter for Android, you need to set up the Android SDK. You will also need to configure at least one Android device (an Android Emulator or a physical device).

This is the same case for Apple devices (iOS and macOS). After installing Flutter on a Mac, you still need to set up Xcode before going further. You will also need at least an iOS simulator or an iPhone to test Flutter on iOS. Flutter for desktop is also a considerable setup. On Windows, you need to set up the Windows Development SDK with Visual Studio (not VS Code). On Linux, you will install more packages.

Without extra setup, Flutter works on browsers. As a result, you could overlook the extra setup for target devices. In most cases, you would use Flutter for mobile app development. Hence, you would want to setup at least Android or iOS. Flutter comes with the flutter doctor command. This command reports the status of your development setup. That way, you know what to work on, in the setup, if need be.

This doesn’t mean that development in Flutter is slow. Flutter comes with a powerful engine. The flutter run command permits hot-reloading to the test device while coding. But then you will need to press R to actually hot-reload. This is not an issue. Flutter’s VS Code extension permits auto-hot-reload on file changes.

3. Packaging and Deployment

Deploying websites is cheaper and easier compared to deploying mobile applications. When you deploy websites, you access them through domain names. These domain names are usually renewed annually. However, they are optional.

Today, many platforms offer free hosting.

For example: DigitalOcean gives you a free subdomain on .ondigitalocean.com.

You can use these domains if you are building a documentation website. You can also use them when you are not worried about branding.

In Flutter’s world with mobile applications, you usually in most cases deploy your app to two places.

App Store (for iOS devices)
Google Play (for Android devices)

You have to register a developer account on each of these platforms. Registering a developer account requires a fee or subscription and identity verification.

For App Store, you need to enroll for the Apple Developer program. You need to maintain an annual subscription of $99. For Google Play, you need to make a one-time $25 payment for the account.

These stores review every app reviewed before it goes live.

Also bear in mind that users don’t easily consume app updates. Users must explicitly update installed applications. This is in contrast to the web where everyone just gets to see the latest deployed version of a website.

Managing deployed applications is relatively more demanding than managing deployed websites. However, this shouldn’t scare you. After all, there are millions of apps deployed on either stores so you can add yours, too.

Additional Thoughts On Flutter

Flutter is a cross-platform tool to build desktop, mobile, or web applications. Flutter apps are pixel-perfect. Flutter paints the same UI on each app irrespective of the target platform. This is because each Flutter app contains the Flutter engine. This engine renders the Flutter UI code. Flutter provides a canvas for each device and allows you to paint as you want. The engine communicates with the target platform to handle events and interactions.

Flutter is efficient. It has high-performance levels. This is because it is built with Dart and it leverages Dart’s features.

With these many benefits, Flutter is a good choice for many applications. Cross-platform apps save money and time during production and maintenance. However, Flutter (and cross-platform solutions) might not be an optimum choice in some cases.

Don’t use Flutter if you want users to use platform developer tools with your application. Platform developer tools here mean device-specific tools like Android developer options. It also includes browser developer tools.

Don’t use Flutter for web if you expect browser extensions to interact with the website.

Also, don’t use Flutter for content-heavy websites.

Conclusion

This was a review of skills that carry over from front-end web development to working with Flutter. We also discussed app development concepts that you have to learn as a web developer.

Flutter is simpler for web developers because they both involve implementing UIs. If you start Flutter, you will find out that it gives you a good developer experience. Give Flutter a try! Use it to build mobile apps and of course, showcase what you build.

Cheers!

Flutter For Front-End Web Developers originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

Behind the CSScenes, September 2022

Css Tricks - Thu, 09/01/2022 - 10:06am

Those of you who have been reading CSS-Tricks for a while may remember that we used to publish a little thing we called CSS-Tricks Chronicles. Our friend Chris Coyier would write up a reflection from the past couple of months or so, and it was a great way to get a pulse on what’s happening around CSS-Tricks, the site, and what the team is doing.

We like that and want to keep it going. It’s a new era, though! So what we’re going to do is welcome you back to what we’re now calling Behind the CSScenes. You’re going to meet some new and familiar faces in these updates, starting with Haley Mills, who is kicking off the very first issue.

How’s the transition going?

[Haley Mills:] Before we dive in, let me start by introducing myself! My name is Haley, and I’m the manager of Content Integration here at DigitalOcean. I’ve been at DigitalOcean for 5 years and previously worked on our editorial team, helping authors publish all sorts of topics through our Write For DOnations program.

Many folks here at DigitalOcean (including myself) are avid readers of CSS-Tricks, and we still have to pinch ourselves for how lucky we are to be entrusted with this community. We recognize that CSS-Tricks is a critical free resource for devs across the world, and my goal is to keep it that way.

Since the acquisition, we have published 95 pieces of new content and look forward to growing that number.
In the month of August, we performed maintenance on 6 existing pieces of content.

That said, change is to be expected when passing a torch.

I think we all know that no one can replace Chris’ voice — it’s a big reason why CSS-Tricks is, well, CSS-Tricks. His ability to have you laughing while learning something new is a skill that few can compete with. I know many of you miss his writing because you told us so in a survey (which we’ll get to in a bit), but it also opens up a huge opportunity for us all to take the torch and continue doing what CSS-Tricks does best:

Find creative solutions to problems and share them with the world. Chris brought people together this way on CSS-Tricks — and you can give back, too.

Your blossoming idea could turn out to be what the Flexbox Guide is for me and so many other people, so I humbly encourage you to reach out in our Guest Writing Form and talk to us about your topic ideas. We have two awesome editors, Geoff and Brad, to help you shape and bring your ideas to life to share with the CSS-Tricks community. In addition to paying you for your contribution, we will now also make a matching donation to a tech-focused charity of your choice.

Next up, we have Product Manager Karen Degi with some survey result highlights.

The results are in…

[Karen Degi:] In June, we shared a survey to collect feedback to help shape the future of CSS-Tricks. We received almost 900 responses, including some great written responses that helped us understand what CSS-Tricks means to the larger community.

Many of you also volunteered to talk to us directly, which has us thinking about the best way to gather those thoughts. If you’re one of those folks, know that we haven’t forgotten about you and still want to hear from you. We just want to make sure we approach this in the most effective way!

The survey confirmed some things we already suspected and brought new things to our attention. The top few things that grabbed our attention are:

Engaging, high-quality content is at the heart of CSS-Tricks. We’re working to make sure that we continue investing in in-depth guides on front-end topics, as well as providing short articles about quick tricks and tutorials with embedded demos.
You love RSS! As we continue investing in CSS-Tricks and bringing new functionality, we’ll make sure we keep an eye on how our changes affect the RSS feed.
You come to CSS-Tricks to learn, to be entertained, and to do your jobs better. You do not come to CSS-Tricks because you’re excited about being sold…well, anything, really. Although we think DigitalOcean is pretty great, and we’ll probably continue to talk about ourselves where it makes sense, we understand that we need to do so in a way that is honest, trustworthy, and connected to your needs as a front-end enthusiast.

Next up is Logan Liffick, Senior Digital Experience Designer, with redesign updates.

A redesign is in the works!

[Logan Liffick:] If you’ve worked on the front end — or really anywhere on the web, you’re bound to know CSS-Tricks. It’s where I, and many others, started the journey. So, when I was asked to spearhead a redesign for the site, it was nothing short of an honor. Without a doubt, undertaking a brand update for something so familiar to so many is a challenge of incredible magnitude

If I were to do justice to this project, I’d need to pay tribute to the original. That mentality became the underlying theme of my work, and any effort to rejuvenate took inspiration from existing patterns and styles from the site.

Upon first glance, you’ll notice the fresh coat of paint. Past that, you’ll recognize the site reads more “editorial” than before. This was a purposeful decision to accentuate existing type stylings and, more importantly, to pay homage to the essence of CSS-Tricks as an informational resource.

Preserving the element of “fun” was also top of mind. Sprinkled throughout the site are various snippets from the actual CSS “tricks” shared on this site — for example, there’s going to be a little Easter egg tucked inside a sticky footer using Preethi’s slide-out effect that’s my personal favorite, a fantastic suggestion from Geoff himself. Gradients are now a core color-way in the system, and border-radii have been rounded out.

We wanted to give ourselves permission and space to explore an open-ended and malleable system far into the future, which lines up nicely with the overall mission and goal of CSS-Tricks: to explore what’s possible with CSS. This is just the beginning, there’s so much more to see, do, and learn with CSS-Tricks living in our (digital) ocean.

Next is Geoff with author highlights!

New authors!

[Geoff:] We’ve added a few new faces to our growing list of guest authors who have contributed to CSS-Tricks:

You may have also seen our editor Bradley Kouchi’s name pop up a couple of times, and you can expect to continue seeing him on a semi-regular basis.

That’s 16 new authors! You can be one, too, by filling out our guest writing form.

On a related note, I’m pleased as punch that we still get regular contributions from a large band of familiar faces from before the DigitalOcean acquisition. Just look at all the fine folks who’ve continued to share their great ideas with us:

Big shake-ups like the one we’re going through today can be scary. Seeing these familiar names in article bylines has helped me a ton as far as continuity and consistency go. CSS-Tricks still seems very CSS-Tricks-y to me, and that’s a big deal.

Until next time…

We hope you’ve enjoyed this little peek behind the CSScenes! We’ll do it again… and again and again. As you can tell, there’s a lot of activity happening around here, which means we’ll have lots to share in the next edition.

Oh, and if you’re one of the many who’ve told us just how much you miss the newsletter, it’s still here! We’re sending it just once a month while we get back in the swing of things, and you may very well need to re-subscribe to get it (we had to do a lot of scrubbing after the keys to the site were handed over).

Thanks for reading!

Behind the CSScenes, September 2022 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

A Brief Introduction to JAWS, NVDA, and VoiceOver

Css Tricks - Thu, 09/01/2022 - 7:47am

A screen reader is an important accessibility tool for people with no or limited vision. People who are blind or those with low vision can use a screen reader to navigate the computer. Screen readers will read contents on the screen and explain to the user what is on the page. Screen readers allow people to use the computer for daily tasks.

There are many screen reader software available for people through their operating system or through open source projects.

A 2021 research by WebAim found that from 1568 responders, more than 53.7 percent of people surveyed used JAWS on Windows, more than 30.7 percent of people used NVDA on Windows and little over 6.5 percent of people used VoiceOver on macOS.

JAWS and NVDA for Windows and VoiceOver for macOS are the most popular screen readers people use.

First, I should clarify that this article will be written from my point of view. To give background, I have been a front-end developer at a non-profit for people with learning differences for over three years. I, along with my colleagues, seek to make our projects more accessible every day. I am not visually impaired and do not use these tools on a regular basis. For work, I have a Mac machine and test accessibility using VoiceOver.

Here is my planned testing methodology:

Navigate the page by heading, until “Accessibility APIs” section.
- Reason for this step: A 2016 survey by Heydon Pickering found that most people who use screen readers navigate new pages by headings
In the “Accessibility APIs” section, read the content and the unordered list inside.
TAB to hear focusable items in the unordered list.
Jump to the Search field.
TAB to hear a few items in the navigation section

To find similarities and differences between them, I decided to test a set of steps with each screen reader on a Wikipedia page about screen readers. I will browse the web with Chrome for my tests. Testing all screen readers on the same page and browser will reduce the amount of variables and keep the tests consistent.

JAWS

JAWS is an acronym for Job Access With Speech and is the most widely used screen reader in the world. It is only available on Windows. Depending on the plan and features, JAWS can be purchased anywhere from $90 yearly license all the way to $1605 for perpetual license.

JAWS has predefined keyboard commands to navigate the web. Full list of keyboard commands can be found on their website.

Demonstration JAWS Demo

In the beginning of the demo, I am clicking on H key on my keyboard to go to the next heading. JAWS is moving down the page, reading me the headings along with their level.

Later in the video, I am clicking on number 2 and number 3 on my keyboard to have JAWS read Heading Levels 2s then later Heading Levels 3s. This is a great feature because we can move down the page and sections by heading level and get a better sense of the page layout.

When I reach the “Accessible APIs” section, I press the DOWN ARROW key until the third item in the unordered list.

Later in the demo, I am clicking on the TAB key for JAWS to read to me the next focusable item on the page, which is inside this list. I click TAB until I reach a focusable element in another section.

Then I press F key to focus on the search field, which JAWS reads to me.

Then I click on TAB and JAWS focuses on the navigation elements that are on the side of the page.

Pros & Cons

Pros:

JAWS is more customizable than other screen readers.
There are more options to navigate through the page.
JAWS is industry standard.
Widely used, which means there are lots of user to user support.

Cons:

JAWS is more complicated to use than NVDA or VoiceOver.
Some commands are not intuitive.
There are a lot more commands for the user to learn.
More learning curve for users.
JAWS is also not available on the Mac, which limits its users.
Costs anywhere between $90 – $1605 for the user.
JAWS has different key commands for desktop and laptop which may make it harder for users to transfer knowledge and may cause confusion.

NVDA

NVDA, or NonVisual Digital Access, is available on Windows only. Users need to download the software from NVDA’s website, NVAccess. This software is free to download but does not come already installed on Windows machines. NVDA is the second most popular screen reader in the world according to WebAim’s 2021 survey.

Like other screen readers, NVDA has defined keyboard commands to navigate the web. NVDA’s full keyboard commands can be found on their website.

Demonstration NVDA Demo

In the demo I am clicking on H key on the keyboard to go to the next heading. First, NVDA reads me Heading Level 1, which is “Screen reader”. Then NVDA goes to read Heading Level 2s and 3s.

When I reach “References” I begin to click on TAB on my keyboard for NVDA to focus on next focusable items.

After focusing on a few items on the list, I click ENTER and go to the New York Times page.

Pros & Cons

Pros:

Overall, I found NVDA was able to provide me with information on the screen.
The out-of-the-box keyboard commands were easy to use and easy to learn.
NVDA is open source, which means the community can update and fix.
NVDA is free, which makes it an affordable option to Windows users.

Cons:

NVDA is not available on the Mac, which limits its users.

VoiceOver

VoiceOver is the screen reader used in Mac. VoiceOver is only available on Mac not available in Windows. VoiceOver is free and is already installed on the computer, which removes barriers because this is part of the computer setup and the user does not have to download or purchase any additional software.

VoiceOver has defined keyboard commands to navigate the web. VoiceOver’s full keyboard commands can be found on their website.

Demonstration VoiceOver Demo

In the demo, I am on a Wikipedia page and I am clicking on the VoiceOver Command (which is Control+Option) along with Command+H to navigate through the headings. VoiceOver reads the headings in order, starting from Heading Level 1, “Screen Reader”, to Heading Level 2, “Contents”, to Heading Level 3, and so on.

When I reach the “Accessibility APIs” section, I click on VoiceOver Command plus the RIGHT ARROW, to tell VoiceOver that I want it to read this section. Later I am clicking on the VoiceOver Command plus the RIGHT ARROW on my keyboard, to navigate the section.

When I get on to the third item on the unordered list, I press TAB on my keyboard to focus on the next focusable element.

I press TAB a few times, then I press VoiceOver Command plus U, to open the Form Control Menu. In the menu, I press DOWN ARROW until I hear the “Search Wikipedia” option. When I hear it, I click ENTER and the screen reader focuses on the form field. In the form field, I press TAB to navigate to the navigation section.

Pros & Cons

Pros:

VoiceOver is easy to use and learn.
VoiceOver’s commands are intuitive.
Free tool that comes installed in every macOS device.

Cons:

VoiceOver is also not available on Windows, which limits its users.
VoiceOver is not an app and can only be updated when Apple releases macOS update.

Key Takeaways

A screen reader is an important accessibility tool for people with no or limited vision. Screen readers allow people to use the computer for daily tasks.

There are many screen reader softwares available. In this article I compared JAWS, NVDA, and VoiceOver.

Here is a comparison chart overview of the three screen readers:

JAWSNVDAVoiceOverOperating SystemWindowsWindowsmacOSPrice$90 – $1695FreeFree# of users50%30%6%Ease of Use (subjective)HardEasyEasy

I found that for basic screen reader testing, most screen readers follow a similar keystroke pattern and knowledge from one screen reader can be used for others.

All screen readers have their pros and cons. Ultimately, it’s up to user preference and also the operating system they use to determine which screen reader software is best for them.

Previously: “Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility” (2018), and “Why, How, and When to Use Semantic HTML and ARIA” (2019), “15 Things to Improve Your Website Accessibility” (2020), “5 Accessibility Quick Wins You Can Implement Today” (2022).

A Brief Introduction to JAWS, NVDA, and VoiceOver originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

iShadeed’s Container Queries Lab

Css Tricks - Thu, 09/01/2022 - 4:29am

Ahmad Shadeed got an early jump on container queries and has a growing collection of examples based on everyday patterns.

And, if you missed it, his latest post on container queries does a wonderful job covering how they work since landing in Chrome 105 this month (we’ll see them in Safari 16 soon). Some choice highlights and takeaways:

Containers are defined with the container-type property. Previous demos and proposals had been using contain instead.
Container queries are very much like the media queries we’ve been writing all along to target the viewport size. So, rather than something like @media (min-width: 600px) {}, we have @container (min-width: 600px) {}. That should make converting many of those media queries to container queries fairly straightfoward, minus the work of figuring out the new breakpoint values.
We can name containers to help distinguish them in our code (e.g. container-name: blockquote).

Great job, Ahmad! And thanks for sharing!

To Shared Link — Permalink on CSS-Tricks

iShadeed’s Container Queries Lab originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Categories: Developer News, Front End Web Development, Web Standards

Tech News

Named Element IDs Can Be Referenced as JavaScript Globals

How to Create Wavy Shapes & Patterns in CSS

How To Customize WordPress Block Theme Cover Templates with Dynamic Post Feature Images

The Web is Good Now

How I Made an Icon System Out of CSS Custom Properties

CSS Rules vs. CSS Rulesets

Featured Fonts

Making a Real-Time Clock With a Conic Gradient Face

More Details on `details`

When is it OK to Disable Text Selection?

WebKit Features in Safari 16.0

How I Made a Pure CSS Puzzle Game

What’s New With Forms in 2022?

Overlapping Bar Charts

Steven Heller’s Font of the Month: Farandole & Lustik

Hacking CSS Animation State and Playback Time

Flutter For Front-End Web Developers

Behind the CSScenes, September 2022

A Brief Introduction to JAWS, NVDA, and VoiceOver

iShadeed’s Container Queries Lab

Services

Navigation

Tech News