CSS Container Queries are still gaining traction and many of us are getting our hands wet with them, even if it’s for little experiments or whatnot. They’ve got great, but not quite full, browser support — enough to justify using them in some projects, but maybe not to the extent where we might be tempted to start replacing media queries from past projects with shiny new container size queries.
They sure are handy though! In fact, I’ve already run into a few situations where I really wanted to reach for them but just couldn’t overcome the support requirements. If I had been able to use them, this is how it would have looked in those situations.
All of the following demos will be best viewed in Chrome or Safari at the time of this writing. Firefox plans to ship support in Version 109.
Case 1: Card grid
You kind of had to expect this one, right? It’s such a common pattern that all of us seem to run into it at some point. But the fact is that container size queries would have been a huge time-saver for me with a better outcome had I been able to use them over standard media queries.
Let’s say you’ve been tasked with building this card grid with the requirement that each card needs to keep it’s 1:1 Aspect ratio:
It’s tougher than it looks! The problem is that sizing a component’s contents on the viewport’s width leaves you at the mercy of how the component responds to the viewport — as well the way any other ancestor containers respond to it. If, for example, you want the font size of a card heading to reduce when the card hits a certain inline size there’s no reliable way to do it.
You could set the font size in vw units, I suppose, but the component is still tied to the browser’s viewport width. And that can cause problems when the card grid is used other in contexts that may not have the same breakpoints.
In my real-world project, I landed on a JavaScript approach that would:
Listen for a resize event.
Calculate the width of each card.
Add an inline font size to each card based on its width.
Style everything inside using em units.
Seems like a lot of work, right? But it is a stable solution to get the required scaling across different screen sizes in different contexts.
Container queries would have been so much better because they provide us with container query units, such as the cqw unit. You probably already get it, but 1cqw is equal to 1% of a container’s width. We also have the cqi unit that’s a measure of a container’s inline width, and cqb for a container’s block width. So, if we have a card container that is 500px wide, a 50cqw value computes to 250px.
If I had been able to use container queries in my card grid, I could have set up the .card component as a container:
.card {
container: card / size;
}
Then I could have set an inner wrapper with padding that scales at 10% of the .card‘s width using the cqw unit:
.card__inner {
padding: 10cqw;
}
That’s a nice way to scale the spacing between the card’s edges and its contents consistently no matter where the card is used at any given viewport width. No media queries required!
Another idea? Use cqw units for the font size of the inner contents, then apply padding in em units:
.card__inner {
font-size: 5cqw;
padding: 2em;
}
5cqw is an arbitrary value — just one that I settled on. That padding is still equal to 10cqw since the em unit is relative to the .card__inner font size!
Did you catch that? The 2em is relative to the 5cqw font size that is set on the same container. Containers work different than what we’re used to, as em units are relative to the same element’s font-size value. But what I quickly noticed is that container query units relate to the nearest parent that is also a container.
For example, 5cqw does not scale based on the .card element’s width in this example:
Rather, it scales to whatever the nearest parent that’s defined as a container. That’s why I set up a .card__inner wrapper.
Case 2: Alternating layout
I needed yet another card component in a different project. This time, I needed the card to transition from a landscape layout to a portrait layout… then back to landscape, and back to portrait again as the screen gets smaller.
I did the dirty work of making this component go to portrait at those two specific viewport ranges (shout out to the new media query range syntax!), but again, the problem is that it is then locked to the media queries set on it, its parent, and anything else that might respond to the viewport’s width. We want something that works in any condition without worrying about wondering where the content is going to break!
Container queries would have made this a breeze, thanks to the @container rule:
But hold on! There’s something you might want to watch out for. Specifically, it could be difficult to use a container query like this within a prop-based design system. For example, this .info-card component could contain child components that rely on props to change their appearance.
Why’s that a big deal? The card’s portrait layout might require the alternate styling but you can’t change JavaScript props with CSS. As such, you risk duplicating the required styles. I actually touched on this and how to work around it in another article. If you need to use container queries for a significant amount of your styling, then you may need to base your entire design system around them rather than trying to shoehorn them into an existing design system that’s heavy on media queries.
Case 3: SVG strokes
Here’s another super common pattern I’ve recently used where container size queries would have resulted in a more polished product. Say you have an icon locked up with a heading:
It’s pretty straightforward to scale the icon with the title’s size, even without media queries. The problem, though, is that the SVG’s stroke-width might get too thin to be noticed all that well at a smaller size, and perhaps catch too much attention with a super thick stroke at a larger size.
I’ve had to create and apply classes to each icon instance to determine its size and stroke width. That’s OK if the icon is next to a heading that’s styled with a fixed font size, I guess, but it’s not so great when working with fluid type that constantly changes.
The heading’s font size might be based on the viewport’s width, so the SVG icon needs to adjust accordingly where its stroke works at any size. You could make the stroke width relative to the heading’s font-size by setting it in em units. But if you have a specific set of stroke sizes that you need to stick to, then this wouldn’t work because it otherwise scales linearly — there’s no way to adjust it to a specific stroke-width value at certain points without resorting to media queries on the viewport width.
But here’s what I would have done if I had the luxury of container queries at that time:
Compare the implementations and see how the container query version snaps the SVG’s stroke to the specific widths I want based on the container’s width.
Bonus: Other types of container size queries
OK, so I haven’t actually run into this on a real project. But as I was combing through information on container queries, I noticed that there are additional things we can query on a container that are related to the container’s size or physical dimensions.
Most examples I’ve seen query the width, max-width, and min-width, height, block-size, and inline-size as I’ve been doing throughout this article.
But MDN outlines two more things we can query against. One is orientation which makes perfect sense because we use it all the time in media queries. It’s no different with container queries:
Here’s an editable demo to play around with both examples:
I haven’t really found a good use case for either of these yet. If you have any ideas or feel like it could’ve helped you in your projects, let me know in the comments!
Nothing but ear-to-ear smiles as I was watching this video from @quayjn on YouTube. (No actual name in the byline, though I think it’s Brian Katz if my paper trail is correct).
The best is this Pen you can use to sing along…
The little song Una did for memorizing for JavaScript’s map(), filter(), and reduce()methods at the end of this article comes to mind for sure.
Do you want to use video for featured thumbnails in WordPress?
By replacing a post or product’s featured image with a featured video, you can make your website much more vibrant and dynamic. Visitors can view these videos from nearly anywhere including your blog archives, homepage, and WooCommerce product pages.
In this article, we will show you how you can add featured video thumbnails in WordPress.
These are the primary images, and they often appear at the top of the page and other areas of your site such as your website’s archive pages. Search engines and social media sites may also display a page’s featured image.
A good featured image can get you a lot of user engagement. However, you may be able to get more clicks, pageviews, and even sales by using a featured video thumbnail instead.
If you’ve created an online store, then showing a video at the top of the product page is a great way to make shoppers want to scroll and learn more about that product.
With that being said, let’s see how you can add featured video thumbnails in WordPress.
How to Add Featured Video Thumbnails in WordPress
The easiest way to use videos as featured thumbnails is by using Really Simple Featured Video. This plugin lets you embed videos from popular video hosting websites such as YouTube or Vimeo and use them as featured video thumbnails.
It also works perfectly with WooCommerce and will show the featured video at the top of the product page.
However, just be aware that WooCommerce will show the featured video on the product page only. The featured image thumbnail will still be used in other places, including your WooCommerce store page.
First, you’ll need to install and activate the plugin. If you need help, then please see our guide on how to install a WordPress plugin.
After activation, there are a few settings to configure. To get started, go to Settings » Really Simple Featured Video.
On this screen, you can select whether you want to add featured video thumbnails to pages, posts, or WooCommerce products.
To do this, simply click on the ‘Posts,‘ ‘Pages’ or ‘Products’ switches to turn them from grey (disabled) to purple (active). In the following image, we’ve enabled the featured video feature for products, plus posts and pages.
After that, click on the ‘Save changes’ button.
Next, click on the ‘Controls’ tab. Here, you’ll find a ‘Self-hosted videos’ section where you can configure the settings for the videos in your WordPress media library.
While the plugin does support self-hosted videos, this can take up a lot of storage space and bandwidth so we don’t recommend it. To learn more, check out why you should never upload a video to WordPress.
Instead, scroll to the ‘Embed Videos’ section. This is where you will find settings for any videos you embed from third-party video platforms such as YouTube.
When you embed videos from YouTube or Vimeo, Really Simple Featured Video will show the playback controls for that platform.
For example, if you’re embedding a YouTube video then visitors will have access to YouTube’s specific playback features.
However, the ‘Embed videos’ section does have an ‘Autoplay’ switch that you can click to enable, too.
By default, the plugin will play videos with sound turned on. To mute your videos by default, click on the ‘Mute sound’ toggle.
You can also set the featured video thumbnails to play on loop.
Looping videos can be annoying to many visitors, particularly if the video is short and has sound. It’s a good idea to only activate the ‘Loop’ switch if replaying the video over and over improves the visitor experience in some way. For example, you might create a video showing a 360 degree view of a product and then set that clip to loop.
After working your way through the different settings, make sure you click on the ‘Save Changes’ button.
Adding Featured Video Thumbnails to Posts, Pages, and WooCommerce Products
Once you’ve configured how the plugin will show embedded videos, you’re ready to add featured video thumbnails to your WordPress website.
To do this, simply open the post, page, or WooCommerce product where you want to add a featured video thumbnail.
If you’re adding a featured video to a page or post, then you’ll find the ‘Featured Video’ section in the right-hand menu underneath the ‘Discussion’ section.
Want to add a featured video to a WooCommerce product instead?
Then you’ll find the ‘Featured Video’ section underneath the ‘Product gallery‘ section.
In the new field, you’ll need to paste the URL of the video that you want to embed.
Just make sure that you add the video’s URL in the right format. In the right-hand menu, you’ll see some examples for YouTube, Vimeo, and Dailymotion.
For YouTube, the plugin gives us the following example URL: https://www.youtube.com/embed/vbLgiRQ0Moo
This means you’ll need to use https://www.youtube.com/embed/ as the first part of your URL and then add the ID of the video that you want to embed.
To find the video ID, simply open a new tab in your browser, then go to the YouTube video that you want to embed. Now, take a look at the browser’s address bar.
The video ID is the value that comes after v=. In the following image, we can see that the video ID is DvbFBxKcORA.
After adding the video ID to the first part of the URL, we get the following: https://www.youtube.com/embed/DvbFBxKcORA
You can now go back to the tab with the WordPress block editor and just paste the URL into the ‘Embed’ field. That will add a featured video thumbnail to the post, and then you’re ready to click on either the ‘Update’ or ‘Publish’ button.
You can now add featured video thumbnails to more posts, pages, and WooCommerce products by following the same process described above.
On your blog archive or similar page you’ll see that WordPress is now using the videos as the featured thumbnail for your posts and pages.
If you open any page, post, or WooCommerce product, then you’ll see that the featured video also appears at the top of the page, just like a featured image would.
In this article we will be diving into the world of scrollbars. I know, it doesn’t sound too glamorous, but trust me, a well-designed page goes hand-in-hand with a matching scrollbar. The old-fashioned chrome scrollbar just doesn’t fit in as much.
We will be looking into the nitty gritty details of a scrollbar and then look at some cool examples.
Components of a scrollbar
This is more of a refresher, really. There are a bunch of posts right here on CSS-Tricks that go into deep detail when it comes to custom scrollbar styling in CSS.
To style a scroll bar you need to be familiar with the anatomy of a scrollbar. Have a look at this illustration:
The two main components to keep in mind here are:
The track is the background beneath the bar.
The thumb is the part that the user clicks and drags around.
We can change the properties of the complete scrollbar using the vendor-prefixed::-webkit-scrollbar selector. We can give the scroll bar a fixed width, background color, rounded corners… lots of things! If we’re customizing the main scrollbar of a page, then we can use ::-webkit-scrollbar directly on the HTML element:
html::-webkit-scrollbar {
/* Style away! */
}
If we’re customizing a scroll box that’s the result of overflow: scroll, then we can use ::-webkit-scrollbar on that element instead:
.element::-webkit-scrollbar {
/* Style away! */
}
Here’s a quick example that styles the HTML element’s scrollbar so that it is wide with a red background:
What if we only want to change the scrollbar’s thumb or track? You guessed it — we have special prefixed pseudo-elements for those two: ::-webkit-scrollbar-thumb and ::-webkit-scrollbar-track, respectively. Here’s an idea of what’s possible when we put all of these things together:
Enough brushing up! I want to show you three degrees of custom scrollbar styling, then open up a big ol’ showcase of examples pulled from across the web for inspiration.
Simple and classy scrollbars
A custom scrollbar can still be minimal. I put together a group of examples that subtly change the appearance, whether with a slight color change to the thumb or track, or some light styling to the background.
As you can see, we don’t have to go nuts when it comes to scrollbar styling. Sometimes a subtle change is all it takes to enhance the overall user experience with a scrollbar that matches the overall theme.
But let’s admit it: it’s fun to go a little overboard and exercise some creativity. Here are some weird and unique scrollbars that might be “too much” in some cases, but they sure are eye-catching.
That outer <div> gives you an opportunity to make embeds resizeable or do whatever other styling you might want. You could also put your own wrapper around it, whatever floats your boat.
The very easiest bit of CSS to apply to your page to make the embed resizble:
Gutenberg 14.5 was released today with a modest set of enhancements and dozens of bug fixes and code quality improvements. The highlight of this release is the new “Document Overview” panel, which combines what was previously found under separate icons in the Editor toolbar under “List View” and “Details.” This popup was where information like words, characters, headings, time to read, paragraphs, and blocks used to be found:
Details view prior to Gutenberg 14.5
The new Document Outline panel can be opened using the List View icon in the toolbar. Characters, words, and “time to read” have been moved to the bottom of the panel. This makes the entire panel cleaner, as the document stats were overly prominent before and the details popup had become even more crowded after the addition of the “time to read” stats.
This release also improves block spacing controls to make them more visual so that users can immediately see how changing the controls will impact the surrounding blocks. Gutenberg contributor Nick Diego demonstrated this update in a video:
A few other notable additions to this release include the following:
Comment Template, Post Comment Count, Post Comments Form, Post Comments Link nowhavespacingsupport
Having focus styles for any interactive element is crucial on a website. Hidde de Vries:
Focus indicators make the difference between day and night for people who rely on them. […]
Focus outlines help users figure out where they are on a page. They show which form field is currently filled in, or which button is about to be pressed. People who use a mouse, might use their cursor for this, but not everyone uses a mouse. For instance, there are many keyboard users: a person with a baby on one arm, people with chronic diseases that prevent the use of a mouse, and of course… developers and other power users.
You don’t have to create your own :focus styles in CSS, although you can. By default, browsers apply their own styles to interactive elements. But if you don’t like that look, the temptation is to style your own. So if you do something like this, boom, we’ve got focus styles under our control:
But by doing this, we’ve also done something else: we’ve made it so when you click (like with a mouse on a desktop computer, otherwise known as a fine pointer) those :focus styles apply to the element. This can be highly undesirable, leading to the CEO being all like why does the button change looks when I click it??? Fair enough, CEO, let’s fix it.
The trick is using :focus-visible which is relatively new but has pretty solid browser support. The whole point of it is applying focus styles that apply at all times an element takes focus, except when a fine pointer clicks it. Which is kinda perfect really. But if you’re nervous about going all-in on only using :focus-visible, a way to continue to use :focus styles too is to wrap them in an @supports block like:
@supports not selector(:focus-visible) {
button:focus {
}
}
Fortunately, the browser support for @supports and the selector() function is a bit better than :focus-visible, so this buys some additional browser support .
Gutenberg 14.4 was released today with long-awaited support for distraction-free editing, to the delight of content editors around the world. It hides all non-essential UI and clears the canvas for a focus on text-based content creation.
The mode can be toggled on in the options menu in the top toolbar. Distraction-free mode hides the top toolbar, any open sidebars, along with the insertion point indicator and the block toolbar.
The project to improve the editing experience for text-based content began with early explorations in February, which progressed into a PR that contributors have been refining for the last few months. This distraction-free mode is a monumental improvement over the days when users struggled to write with various UI elements popping in and out of view.
Another major update in 14.4 is the redesigned pattern inserter. It has been updated to show the categories before rendering the patterns, giving users a more fluid visual preview as they browse the pattern library. Patterns can be dragged and dropped from the preview pane into the canvas.
Performance benchmarks show an improvement in loading time for both the post and site editors. Check out the release post to see the full list of all the changes and bug fixes included in 14.4. This release will not be included in the upcoming WordPress 6.1 release next week, but users who are eager to adopt these new features can get them right now in the Gutenberg plugin.
Gutenberg 14.3 was released this week with drag-and-drop improvements for both the block editor and the site editor. Automattic-sponsored contributor Aaron Robertshaw published a video, illustrating how the block editor now supports dropping an image onto an empty paragraph block to replace it with a new Image block.
The site editor has also added drag-and-drop capabilities for blocks and patterns in the new zoomed-out view, which was added in Gutenberg version 14.1. It zooms out to focus on building and composing patterns, allowing users to move sections around without affecting the inner blocks. It can be enabled under “Experiments.” In 14.3, users can drag blocks and patterns right onto the canvas with an overhead view that makes it easy to place in between existing blocks.
This version also introduces new support for alt + arrow keyboard combinations for navigating blocks. Robertshaw explained how they work:
For example, if your cursor is towards the end of a long paragraph, you can quickly press alt + up arrow to move to the beginning of that paragraph. If you are already at the beginning of a text block, you’ll move to the start of the previous paragraph. Similarly, alt + down arrow will move you to the end of a block of text.
The Styles typography controls have been updated to include the Tools Panels that users have available in the Block Settings interface. This makes the experience more consistent and expands the capabilities to allow for resetting the values.
This release includes dozens of fixes and improvements to design tools, components, the Block API, and more. Check out the changelog in the announcement post for the full list of updates.
Gutenberg 14.3 will not be included in the upcoming WordPress 6.1 release but will be rolled into core the next time around. If you want these features now, you can install the Gutenberg plugin.
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 thisprevious 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:
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:
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.
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.
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:
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.
Our wave is back! Let’s plug that equation into our CSS:
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:
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.
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;
}
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:
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:
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.
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:
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. 🎉
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:
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:
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.
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!
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…
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.
WordPress’ design team has announced the winners of the challenge to create a style variation for the upcoming Twenty Twenty-Three (TT3) default theme. Organizers received 38 submissions from 19 contributors (some submitted multiple variations) hailing from eight countries.
Given the wide range of colors and typography combinations, TT3 is gearing up to be a vehicle for a diverse set of styles from WordPress’ community of designers. Submissions included creative variations for all kinds of design moods – dark with high contrast, bright yellow with a smaller universal type size, a gradient aubergine background, and many more.
Automattic design director Channing Ritter published the selections that made the cut to be shipped with Twenty Twenty-Three:
“These variations were selected in an effort to feature the most drastically different set of variations possible — so in many ways, we were looking at what would work best as a collection versus selecting our favorite standalone submissions,” Ritter said.
The selections are not in their final form. Contributors will continue iterating on them, under the direction of design team leaders, until the WordPress 6.1 beta period begins on September 20.
“Some of the changes suggested may be a bit aspirational, but let’s continue pushing to see how opinionated we can make each of these variations,” Ritter said.
Submissions that were not chosen to ship with TT3 may still have a path towards inclusion via an official child theme of the default theme. Contributors discussed how this might work and have closed the issue in favor of creating a separate project for it after TT3 has launched.
“I particularly like the idea of continuing to create style variations beyond those that are bundled with TT3,” Automattic-sponsored contributor Sarah Norris said. “I think this is a great opportunity to introduce people to block themes and building variations, with the help of the community and experienced block-themers. It also provides a space to test Gutenberg PRs, in a similar way to how emptytheme is currently used, but with more opinionated settings enabled.
“I’m not sure about this being part of the current TT3 project, and in my opinion, it would be best to start this initiative soon after TT3 has launched.”
In the meantime, contributors plan to refine the selected variations, and the child theme project can proceed without affecting the theme’s current timeline.
Check out the announcement to see each of the selected variations in more detail.
Do you want to use the More block on your WordPress website?
WordPress gives you several different ways to show a preview of your posts on the archive and homepage. This can help catch the visitor’s attention and get them to read the full post.
In this article, we will show you how you can properly use the More block in WordPress. We’ll also show you how to create an excerpt, just in case you’re using a theme that ignores the More block.
When to Use the More Block in WordPress
Many websites use post previews to encourage visitors to check out the full version.
By default, most modern WordPress themes automatically show a preview of your posts on the homepage and blog archives instead of the full post. For example, on our blog page we show a few words and then a ‘Read More’ link to see the full blog post.
This preview text helps visitors to see more of what topics are available on your blog without having to scroll through every post. It also helps to increase pageviews since your visitors will have to click through to finish reading a post.
You can control exactly what WordPress shows in these previews by using either the More block or an excerpt.
The best choice for your site will vary depending on your WordPress theme. Some themes will ignore any More blocks you create, so you’ll need to use an excerpt instead.
To help you show an engaging preview no matter what theme you’re using, we’ll be covering both More blocks and excerpts.
If you prefer to jump straight to a particular method then you can use the links below.
The WordPress block editor has a built-in More block that allows you to specify the exact cut off point for the preview text of any WordPress post. In the classic editor, it was previously known as the More tag.
You can add the More block anywhere in the post, including mid sentence or in the middle of a paragraph.
All of the content above the More block will appear on your blog archive pages and wherever else your posts are listed on your WordPress site. WordPress will also add a ‘Read More’ link to the preview, so visitors can click to read the full version of the post.
Note: Every WordPress theme is different and some may override the default ‘Read More’ label. With that in mind, you may see different text on your ‘Read More’ button.
Before you add a More block to your post, it’s important to check that your site is set up to show the latest posts on the homepage. If you are using a static page as your custom homepage, then your theme may ignore the More blocks and use its own settings instead.
Not sure if you’re using a static front page as your homepage? To check, simply go to Settings » Reading in the WordPress dashboard.
At the top of this screen, you’ll see a ‘Your homepage displays’ section. If ‘Your latest posts’ is selected, then you should have no problems using the More block.
To get started, simply open the post where you want to add a More block. Then, find the spot where you want to create the cut off point for your preview, and click on the + icon to add a new block.
You can then type in ‘More’ and select the right block to add it to your page.
Some themes have a limit on how many words they will show on their homepage and archive pages. There’s a chance your theme may override the More block if you try to include a very large number of words in your preview. With that in mind, it’s a good idea to create the cut off point early in the post.
You can now carry on writing the rest of your post as normal.
You’ll be able to see the More block when editing your post in the block editor, but your visitors won’t see it when they’re reading the post on your WordPress blog.
Just like any other block, WordPress has some settings that you can use to configure the More block. To see these settings, simply click to select your More block.
In the right-hand menu, you can now choose whether to hide or show the excerpt on the full content page, which is the page you’re currently looking at.
By default, all of the content above the More block will appear on the full content page, as you can see in the following image.
However, you may want to write a custom excerpt that will only appear on your homepage and archive page, and not in the full post itself.
To do this, simply click the ‘Hide the excerpt….’ slider to turn it from white to blue.
Now, everything above the More block will appear on the archive page and homepage only.
Once you’re finished, you can go ahead and save your changes by clicking on the Update or Publish button.
Now if you visit your homepage or blog archive page, you’ll see the preview you just created for this post.
Some themes are designed to show excerpts and will override all of your More blocks. If your homepage and blog archives aren’t showing the preview you created using the More block, then you may need to use excerpts instead.
How to Change the More Block’s ‘Read More’ text
By default, the More block will show a Read More link on your archive and homepage.
There are a few different ways to change this text, but you may get slightly different results depending on your WordPress theme. Some themes will override your changes with their own default settings.
To start, it’s worth checking whether you can change the Read More text using the WordPress post editor.
To do this, simply open any post that has a More block. You can then click on the default ‘READ MORE’ text and type in the text that you want to use instead.
After that, either update or publish the page as normal. You can then visit your homepage or blog archive to see whether the Read More text has changed.
If you’re still seeing the original Read More link, then you may need to override your theme’s settings using code.
function modify_read_more_link() {
return '<a class="more-link" href="' . get_permalink() . '">Check out the full post</a>';
}
add_filter( 'the_content_more_link', 'modify_read_more_link', 999 );
This replaces the default ‘Read More’ text with ‘Check out the full post,’ as you can see in the following image.
You can use any text you want by replacing ‘Check out the full post’ in the code snippet.
How to Properly Use Excerpts in WordPress
WordPress has two different ways to show a post preview. We’ve already covered the More block, but you can also create a preview using excerpts.
For the people who visit your WordPress blog or website, previews created using excerpts and the More block look exactly the same. However, some themes are coded to use excerpts, which means they will ignore your More blocks and show an excerpt instead.
If you don’t add an excerpt to a post manually, then WordPress will create one automatically based on the excerpt length defined by your theme. This can lead to previews that cut off mid sentence.
With that in mind, you can choose to create an excerpt manually instead. To do this, simply open a post and then click to expand the ‘Excerpt’ section in the right-hand menu.
In the ‘Write an excerpt box’ you can then either type in or paste the excerpt that you want to use for the post.
Don’t see an ‘Excerpt’ box in the right-hand menu? Then you can enable this setting by clicking on the three-dotted icon in the upper-right corner.
Once you’ve done that, click on Preferences.
In the popup that appears, simply click on ‘Panels.’
You’ll now see all the settings that you can add to the right-hand menu. Simply find ‘Excerpt’ and give it a click to turn it from white (disabled) to blue (enabled).
Then, simply close this popup. You should now have access to the ‘Excerpt’ settings in your right-hand menu.
Now, you can create an excerpt following the same process described above.
Once you’ve done that, simply save your changes and visit your site. You will now see your custom excerpt on the homepage and blog archive.
Automattic-sponsored designer James Koster has a vision for taking WordPress’ Site Editor from its beta awkwardness and transforming it to become a more visual and user-friendly design tool. In a recent post titled Revising the presentation of key Site Editor features, Koster identifies unbalanced feature weighting as a critical design flaw that is negatively impacting users’ experience with the editor:
The Site Editor is a powerful tool, but the user experience lacks some coherence and a sense of hierarchy.
Template management and editing has central focus, despite the fact that it’s a product area that has proven difficult for some users to interpret.
Impactful features like style and menu management are hierarchically relegated, and consequently deliver a sub-optimal UX.
This week I’ve been ideating on how we might present site editor features with more appropriate weighting, so that the overall experience feels more like a design tool.
Instead of dropping users directly into editing the homepage, Koster contends that the Site Editor’s design should be updated to become a “navigable frame” where users can select from a menu of features and styles on the left. This is a radical improvement over the current experience, which feels like walking into a room with all the lights on and multiple features competing for attention.
“The combination of the site frame (Browse mode) and one-click editing helps to obfuscate some of the aforementioned confusion around template editing,” Koster said. “Now you simply browse to the page you want to update, and click ‘Edit’.”
Another idea Koster explored is a view that makes it easier to understand the interaction of styles and templates. The UI is much cleaner and drastically reduces the cognitive load for users who are struggling to grasp the concept of templates in the first place.
Identity and homepage configuration options haven’t found a place in the site editor yet. Koster proposed bringing them into the editor in a similar fashion to how it was previously presented in the Customizer, with live previews.
Koster also proposes organizing features like templates, template parts, reusable blocks, and patterns in a “Design Library” section, presented via a grid of thumbnails that would open the edit view. This would bring a new level of organization to a set of tools that are currently scattered throughout the site editor interface.
These are just a few highlights from his explorations. Although Koster articulates many of the Site Editor’s current pain points, his designs present an elegant solution for each. Check out the full post to see all the videos and other ideas for organizing features in the site editor.
The disparity between the current experience and Koster’s mockups is like a night and day Cinderella style transformation. It’s a powerful example of how thoughtful design can really solve problems. His explorations received positive feedback from those eager to see these designs implemented in Gutenberg. Koster said his next step is to prepare some simpler prototypes for collaboration on GitHub.
“The ideas are still formative, but with some pruning we can get things into a shippable state,” Koster said. “My next step is to refine and prototype a more stripped-back version, and take that to GitHub for wider thoughts and feedback.”
Alright, so the last time we checked in, we were using CSS Grid and combining them with CSS clip-path and mask techniques to create grids with fancy shapes.
Here’s just one of the fantastic grids we made together:
Ready for the second round? We are still working with CSS Grid, clip-path, and mask, but by the end of this article, we’ll end up with different ways to arrange images on the grid, including some rad hover effects that make for an authentic, interactive experience to view pictures.
And guess what? We’re using the same markup that we used last time. Here’s that again:
<div class="gallery">
<img src="..." alt="...">
<img src="..." alt="...">
<img src="..." alt="...">
<img src="..." alt="...">
<!-- as many times as we want -->
</div>
Like the previous article, we only need a container with images inside. Nothing more!
Nested Image Grid
Last time, our grids were, well, typical image grids. Other than the neat shapes we masked them with, they were pretty standard symmetrical grids as far as how we positioned the images inside.
Let’s try nesting an image in the center of the grid:
We start by setting a 2✕2 grid for four images:
.gallery {
--s: 200px; /* controls the image size */
--g: 10px; /* controls the gap between images */
display: grid;
gap: var(--g);
grid-template-columns: repeat(2, auto);
}
.gallery > img {
width: var(--s);
aspect-ratio: 1;
object-fit: cover;
}
Nothing complex yet. The next step is to cut the corner of our images to create the space for the nested image. I already have a detailed article on how to cut corners using clip-path and mask. You can also use my online generator to get the CSS for masking corners.
What we need here is to cut out the corners at an angle equal to 90deg. We can use the same conic-gradient technique from that article to do that:
We could use the clip-path method for cutting corners from that same article, but masking with gradients is more suitable here because we have the same configuration for all the images — all we need is a rotation (defined with the variable --_a) get the effect, so we’re masking from the inside instead of the outside edges.
Now we can place the nested image inside the masked space. First, let’s make sure we have a fifth image element in the HTML:
The inset property allows us to place the image at the center using a single declaration. We know the size of the image (defined with the variable --s), and we know that the container’s size equals 100%. We do some math, and the distance from each edge should be equal to (100% - var(--s))/2.
You might be wondering why we’re using clip-path at all here. We’re using it with the nested image to have a consistent gap. If we were to remove it, you would notice that we don’t have the same gap between all the images. This way, we’re cutting a little bit from the fifth image to get the proper spacing around it.
Now, many of you might also be wondering: why all the complex stuff when we can place the last image on the top and add a border to it? That would hide the images underneath the nested image without a mask, right?
That’s true, and we will get the following:
No mask, no clip-path. Yes, the code is easy to understand, but there is a little drawback: the border color needs to be the same as the main background to make the illusion perfect. This little drawback is enough for me to make the code more complex in exchange for real transparency independent of the background. I am not saying a border approach is bad or wrong. I would recommend it in most cases where the background is known. But we are here to explore new stuff and, most important, build components that don’t depend on their environment.
Let’s try another shape this time:
This time, we made the nested image a circle instead of a square. That’s an easy task with border-radius But we need to use a circular cut-out for the other images. This time, though, we will rely on a radial-gradient() instead of a conic-gradient() to get that nice rounded look.
All the images use the same configuration as the previous example, but we update the center point each time.
The above figure illustrates the center point for each circle. Still, in the actual code, you will notice that I am also accounting for the gap to ensure all the points are at the same position (the center of the grid) to get a continuous circle if we combine them.
Now that we have our layout let’s talk about the hover effect. In case you didn’t notice, a cool hover effect increases the size of the nested image and adjusts everything else accordingly. Increasing the size is a relatively easy task, but updating the gradient is more complicated since, by default, gradients cannot be animated. To overcome this, I will use a font-size hack to be able to animate the radial gradient.
If you check the code of the gradient, you can see that I am adding 1em:
It’s known that em units are relative to the parent element’s font-size, so changing the font-size of the .gallery will also change the computed em value — this is the trick we are using. We are animating the font-size from a value of 0 to a given value and, as a result, the gradient is animated, making the cut-out part larger, following the size of the nested image that is getting bigger.
Here is the code that highlights the parts involved in the hover effect:
.gallery {
--s: 200px; /* controls the image size */
--g: 10px; /* controls the gaps between images */
font-size: 0; /* initially we have 1em = 0 */
transition: .5s;
}
/* we increase the cut-out by 1em */
.gallery > img {
mask:
radial-gradient(farthest-side at var(--_a),
#0000 calc(50% + var(--g)/2 + 1em), #000 calc(51% + var(--g)/2 + 1em));
}
/* we increase the size by 2em */
.gallery > img:nth-child(5) {
width: calc(var(--s) + 2em);
}
/* on hover 1em = S/5 */
.gallery:hover {
font-size: calc(var(--s) / 5);
}
The font-size trick is helpful if we want to animate gradients or other properties that cannot be animated. Custom properties defined with @property can solve such a problem, but support for it is still lacking at the time of writing.
This time we clipped the nested image into the shape of a rhombus. I’ll let you dissect the code as an exercise to figure out how we got here. You will notice that the structure is the same as in our examples. The only differences are how we’re using the gradient to create the shape. Dig in and learn!
Circular Image Grid
We can combine what we’ve learned here and in previous articles to make an even more exciting image grid. This time, let’s make all the images in our grid circular and, on hover, expand an image to reveal the entire thing as it covers the rest of the photos.
The HTML and CSS structure of the grid is nothing new from before, so let’s skip that part and focus instead on the circular shape and hover effect we want.
We are going to use clip-path and its circle() function to — you guessed it! — cut a circle out of the images.
That figure illustrates the clip-path used for the first image. The left side shows the image’s initial state, while the right shows the hovered state. You can use this online tool to play and visualize the clip-path values.
For the other images, we can update the center of the circle (70% 70%) to get the following code:
.gallery > img:hover {
--_c: 50%; /* same as "50% at 50% 50%" */
}
.gallery > img:nth-child(1) {
clip-path: circle(var(--_c, 55% at 70% 70%));
}
.gallery > img:nth-child(2) {
clip-path: circle(var(--_c, 55% at 30% 70%));
}
.gallery > img:nth-child(3) {
clip-path: circle(var(--_c, 55% at 70% 30%));
}
.gallery > img:nth-child(4) {
clip-path: circle(var(--_c, 55% at 30% 30%));
}
Note how we are defining the clip-path values as a fallback inside var(). This way allows us to more easily update the value on hover by setting the value of the --_c variable. When using circle(), the default position of the center point is 50% 50%, so we get to omit that for more concise code. That’s why you see that we are only setting 50% instead of 50% at 50% 50%.
Then we increase the size of our image on hover to the overall size of the grid so we can cover the other images. We also ensure the z-index has a higher value on the hovered image, so it is the top one in our stacking context.
.gallery {
--s: 200px; /* controls the image size */
--g: 8px; /* controls the gap between images */
display: grid;
grid: auto-flow var(--s) / repeat(2, var(--s));
gap: var(--g);
}
.gallery > img {
width: 100%;
aspect-ratio: 1;
cursor: pointer;
z-index: 0;
transition: .25s, z-index 0s .25s;
}
.gallery > img:hover {
--_c: 50%; /* change the center point on hover */
width: calc(200% + var(--g));
z-index: 1;
transition: .4s, z-index 0s;
}
.gallery > img:nth-child(1){
clip-path: circle(var(--_c, 55% at 70% 70%));
place-self: start;
}
.gallery > img:nth-child(2){
clip-path: circle(var(--_c, 55% at 30% 70%));
place-self: start end;
}
.gallery > img:nth-child(3){
clip-path: circle(var(--_c, 55% at 70% 30%));
place-self: end start;
}
.gallery > img:nth-child(4){
clip-path: circle(var(--_c, 55% at 30% 30%));
place-self: end;
}
What’s going on with the place-self property? Why do we need it and why does each image have a specific value?
Do you remember the issue we had in the previous article when creating the grid of puzzle pieces? We increased the size of the images to create an overflow, but the overflow of some images was incorrect. We fixed them using the place-self property.
Same issue here. We are increasing the size of the images so each one overflows its grid cells. But if we do nothing, all of them will overflow on the right and bottom sides of the grid. What we need is:
the first image to overflow the bottom-right edge (the default behavior),
the second image to overflow the bottom-left edge,
the third image to overflow the top-right edge, and
the fourth image to overflow the top-left edge.
To get that, we need to place each image correctly using the place-self property.
In case you are not familiar with place-self, it’s the shorthand for justify-self and align-self to place the element horizontally and vertically. When it takes one value, both alignments use that same value.
Expanding Image Panels
In a previous article, I created a cool zoom effect that applies to a grid of images where we can control everything: number of rows, number of columns, sizes, scale factor, etc.
A particular case was the classic expanding panels, where we only have one row and a full-width container.
We will take this example and combine it with shapes!
Before we continue, I highly recommend reading my other article to understand how the tricks we’re about to cover work. Check that out, and we’ll continue here to focus on creating the panel shapes.
First, let’s start by simplifying the code and removing some variables
We only need one row and the number of columns should adjust based on the number of images. That means we no longer need variables for the number of rows (--n) and columns (--m ) but we need to use grid-auto-flow: column, allowing the grid to auto-generate columns as we add new images. We will consider a fixed height for our container; by default, it will be full-width.
Once again, each image is contained in its grid cell, so there’s more space between the images than we’d like:
We need to increase the width of the images to create an overlap. We replace min-width:100% with min-width: calc(100% + var(--s)), where --s is a new variable that controls the shape.
Now we need to fix the first and last images, so they sort of bleed off the page without gaps. In other words, we can remove the slant from the left side of the first image and the slant from the right side of the last image. We need a new clip-path specifically for those two images.
We also need to rectify the overflow. By default, all the images will overflow on both sides, but for the first one, we need an overflow on the right side while we need a left overflow for the last image.
The final result is a nice expanding panel of slanted images!
We can add as many images as you want, and the grid will adjust automatically. Plus, we only need to control one value to control the shape!
We could have made this same layout with flexbox since we are dealing with a single row of elements. Here is my implementation.
Sure, slanted images are cool, but what about a zig-zag pattern? I already teased this one at the end of the last article.
All I’m doing here is replacing clip-path with mask… and guess what? I already have a detailed article on creating that zig-zag shape — not to mention an online generator to get the code. See how all everything comes together?
The trickiest part here is to make sure the zig-zags are perfectly aligned, and for this, we need to add an offset for every :nth-child(odd) image element.
Note the use of the --_p variable, which will fall back to 0% but will be equal to --_s for the odd images.
Here is a demo that illustrates the issue. Hover to see how the offset — defined by --_p — is fixing the alignment.
Also, notice how we use a different mask for the first and last image as we did in the previous example. We only need a zig-zag on the right side of the first image and the left side of the last image.
And why not rounded sides? Let’s do it!
I know that the code may look scary and tough to understand, but all that’s going on is a combination of different tricks we’ve covered in this and other articles I’ve already shared. In this case, I use the same code structure as the zig-zag and the slanted shapes. Compare it with those examples, and you will find no difference! Those are the same tricks in my previous article about the zoom effect. Then, I am using my other writing and my online generator to get the code for the mask that creates those rounded shapes.
If you recall what we did for the zig-zag, we had used the same mask for all the images but then had to add an offset to the odd images to create a perfect overlap. In this case, we need a different mask for the odd-numbered images.
The only effort I did here is update the second mask to include the gap variable (--g) to create that space between the images.
The final touch is to fix the first and last image. Like all the previous examples, the first image needs a straight left edge while the last one needs a straight right edge.
For the first image, we always know the mask it needs to have, which is the following:
That’s all! Three different layouts but the same CSS tricks each time:
the code structure to create the zoom effect
a mask or clip-path to create the shapes
a separate configuration for the odd elements in some cases to make sure we have a perfect overlap
a specific configuration for the first and last image to keep the shape on only one side.
And here is a big demo with all of them together. All you need is to add a class to activate the layout you want to see.
And here is the one with the Flexbox implementation
Wrapping up
Oof, we are done! I know there are many CSS tricks and examples between this article and the last one, not to mention all of the other tricks I’ve referenced here from other articles I’ve written. It took me time to put everything together, and you don’t have to understand everything at once. One reading will give you a good overview of all the layouts, but you may need to read the article more than once and focus on each example to grasp all the tricks.
Did you notice that we didn’t touch the HTML at all other than perhaps the number of images in the markup? All the layouts we made share the same HTML code, which is nothing but a list of images.
Before I end, I will leave you with one last example. It’s a “versus” between two anime characters with a cool hover effect.
What about you? Can you create something based on what you have learned? It doesn’t need to be complex — imagine something cool or funny like I did with that anime matchup. It can be a good exercise for you, and we may end with an excellent collection in the comment section.
Do you need to underline or justify text in WordPress?
WordPress used to have both justify and underline text buttons in the visual editor. However, they have been removed and are no longer available.
In this article, we’ll show you how to add underline and justify text buttons in WordPress.
Why Add Underline and Justify Text Buttons in WordPress?
Would you like to restore the missing underline and justify buttons when editing posts and pages on your WordPress website? These buttons were removed from the post editor in WordPress 4.7, but luckily there’s a way to bring them back.
However, there are a few reasons you should consider not underlining and justifying text on your website.
First, underlined text can look like links, and your users may become frustrated when what they think is a link doesn’t work. Also, justified text can make your content harder to read, especially on small screens.
With that being said, let’s take a look at how to add underline and justify text buttons in WordPress. We’ll show you how to do this for the block and classic editor. We’ll also show you how to underline and justify text using keyboard shortcuts, without the need for a button.
Underlining and Justifying Text Using Keyboard Shortcuts
You don’t need a plugin or toolbar icons to underline or justify text in WordPress. Instead, you can simply use a keyboard shortcut.
To underline text, just select the text you want to underline in WordPress and press Ctrl+U on Windows or Command+U on Mac. That’s it. This keyboard shortcut will work with both the block and classic editor.
There’s another keyboard shortcut for justifying text. Simply select the text and press Shift+Alt+J in Windows or Command+Option+J on Mac and your text will be justified.
However, the keyboard combination for justifying text will only work with the classic editor. If you use the block editor, then you will not be able to justify text with a keyboard shortcut and should use the plugin method below.
Adding Underline and Justify Text Buttons to the Block Editor
Upon activation, the plugin will make underline, justify, and other formatting features available when using the WordPress block editor.
These additional icons can’t be added directly to the block editor’s toolbar, but you will find the extra options when clicking the ‘Displays more block tools’ down arrow on the toolbar.
To underline text, you should first select the text, then click the ‘Displays more block tools’ down arrow, and then click on ‘Underline’ from the drop down menu.
To justify a paragraph, first make sure that your cursor is in that paragraph. Then click the ‘Displays more block tools’ down arrow and select ‘Justify’ from the drop down menu.
Adding Underline and Justify Text Buttons to the Classic Editor
Upon activation, you will need to navigate to Settings » Advanced Editor Tools (TinyMCE Advanced) in your admin menu. Next, you need to click on the ‘Classic Editor (TinyMCE)’ tab at the top of the page.
You will notice a preview of the WordPress classic editor. Below the preview, it will show you all the unused buttons.
Now you need to drag and drop underline and justify text buttons from ‘Unused Buttons’ box to the post editor.
When you have finished, make sure you click the ‘Save Changes’ button at the top of the screen to store the new settings.
Now when you are creating or editing a WordPress blog post or page, the new formatting buttons will be available on the classic editor’s toolbar.
Often while reading WordPress tutorials, you may be asked to add custom code snippets in your theme’s functions.php file or in a site-specific plugin.
The problem is that even the slightest mistake can break your website.
In this article, we will show you an easy way to add custom code in WordPress without breaking your site.
The Problem with Custom Code Snippets (And How to Fix It)
Often you’ll find code snippets in WordPress tutorials with instructions to add them into your theme’s functions.php file or a site-specific plugin.
The biggest problem is that even a tiny mistake in the custom code snippet can break your WordPress site and make it inaccessible.
Not to mention, if you update your WordPress theme, then all your customizations get removed.
The other problem is that if you add multiple code snippets in a site-specific plugin, it can become hard to manage the file.
Luckily, there is an easier way for users to add and manage custom code snippets in WordPress.
WPCode is the most popular code snippets plugin used by over 1 million WordPress websites. It makes it easy to add code snippets in WordPress without having to edit your theme’s functions.php file.
WPCode also makes it simple to add tracking codes for Google Analytics, Facebook Pixel, Google AdSense, and more to your site’s header and footer areas.
You’ll never have to worry about breaking your site because the smart code snippet validation helps you prevent common code errors.
In addition, WPCode comes with a built-in snippets library where you can find all of the most popular WordPress code snippets like disable REST API, disable comments, disable Gutenberg, allow SVG file uploads, and much more. This eliminates the need to install separate plugins for each feature request.
The best part is that you can manage all your code snippets from one central screen and add tags to organize them.
With that said, let’s take a look at how to easily add custom code snippets in WordPress with WPCode.
Adding Custom Code Snippets in WordPress
The first thing you need to do is install and activate the WPCode plugin on your website.
Upon activation, the plugin will add a new menu item labeled ‘Code Snippets’ to your WordPress admin bar. Clicking on it will show you a list of all the custom code snippets you have saved on your site.
Since you just installed the plugin, your list will be empty.
Go ahead and click on the ‘Add New’ button to add your first custom code snippet in WordPress.
This will bring you to the ‘Add Snippet’ page. Here you can choose a code snippet from the pre-made library or add your custom code.
To add custom code, click on the ‘Use snippet’ button underneath the ‘Add Your Custom Code (New Snippet)’ option.
You need to start by entering a title for your custom code snippet. This could be anything that helps you identify the code.
After that, you can copy and paste your code snippet into the code box. Be sure to also select the correct code type from the drop-down menu on the right.
function wpb_remove_version() {
return '';
}
add_filter('the_generator', 'wpb_remove_version');
Below the code box, you will see insertion options. There are two main insertion options: Auto Insert and Shortcode (Default).
If you chose the ‘Auto Insert’ method, the snippet will be automatically inserted and executed on your site.
You can automatically run the snippet only in the WordPress admin area, on the front-end of your site, or everywhere. If you are unsure, then select the default ‘Run snippet everywhere’ option.
With the ‘Shortcode’ method, the snippet is not automatically inserted. Once you save the snippet, you’ll get a shortcode specific to the snippet that you can use anywhere on your site.
When you scroll further down, you will see a ‘Basic info’ area. You can add anything here that helps you understand what this code does, where you found it, and why you are adding it to your website.
You can also assign tags to your code snippet. This will help you sort your code snippets by topic and functionality.
The priority field allows you to control the order in which the snippets are executed when you want to display multiple snippets in the same location. By default, all snippets get a priority of 10. If you want a snippet to display earlier than others, simply set the snippet priority to a lower number, like 5.
Lastly, you can use the powerful ‘Smart Conditional Logic’ section to either show or hide auto-inserted snippets based on a set of rules.
For example, you can show code snippets to logged-in users only, load code snippets only on specific page URLs, and more.
When you’re finished choosing options, you can click the ‘Save Snippet’ button in the top-right corner of the screen and toggle the switch from ‘Inactive’ to ‘Active.’
If you want to save the code snippet and not activate it, then simply click on the ‘Save Snippet’ button.
Once you have saved and activated the code snippet, it will be added to your site automatically, if that’s the insertion method you chose, or displayed as a shortcode.
Handling Errors in Custom Code
Often, if you make a mistake in adding the custom code in your site-specific plugin or theme file, then it would immediately make your site inaccessible.
The neat part about the WPCode plugin is that it will automatically detect a syntax error in the code and immediately deactivate it.
It will also show you a helpful error message, so you can debug the error.
WPCode’s smart code snippet validation will also detect any errors as you’re adding your custom code.
Hovering over the error will bring up instructions to help you fix it.
Managing Your Custom Code Snippets
WPCode plugin provides an easy user interface to manage your custom code snippets in WordPress.
You can save code snippets without activating them on your site, and then activate or deactivate the snippet at any time you want. It’s also possible to filter code snippets by type and location, and use tags to organize your code snippets easily.
You can also export specific code snippets or bulk export all of them.
Simply go to Code Snippets»Tools and click on the ‘Export’ tab.
Apple unveiled an expanded version of its San Francisco system font at WWDC 2022. Then, last month, Jim Nielsen zeroed in on the font’s variations, explaining how the font provides a spectrum of variations based on the width and weight. It’s a remarkable read if you haven’t checked it.
With all of these great new options, you might be tempted to use them in a web design. Chris was ogling over the expanded sets as well over on his personal blog and pondered:
But it’s not year clear how we might tap into the condensed, compressed, and expanded varieties in CSS, or if there is even a plan to allow that. I suppose we can peek around Apple.com eventually and see how they do it if they start using them there.
Doesn’t this make perfect sense to construct as a variable font and ship the whole kit and kaboodle that way?
Turns out, yes. It does make perfect sense. Chris follows up in a new post:
But just yesterday I randomly stumbled across the fact that the built-in San Francisco font (on the Apple devices that have it built-in) is already variable (!!). See, I was derping around with Roboto Flex, and had system-ui as the fallback font, and I was noticing that during the FOUT, the font-variation-settings I was using had an effect on the fallback font, which renders as San Francisco on my Mac. Which… unless I’m daft… means that San Francisco is a variable font.
So, as for using it? Chris has a demo, of course:
There are some gotchas to all this, the most significant being fallbacks for non-Apple devices. After all, that demo is simply calling system-ui for the font family — it’s not telling the browser to download a font file or anything and who knows if Apple is gonna ever ship a variable font file we can serve up as an actual custom web font.
The other interesting thing? Chris did some sleuthing and counted 35 layout featured included in that system font. Go read the rest of the post to see ’em all (and to get a good ol’ dose of Chris-isms — I know I miss them!).
Chris callsscroll shadows one his favorite CSS-Tricks of all time. Lea Verou popularized the pure CSS approach using four layered background gradients with some clever background-attachment magic. The result is a slick scrolling interaction that gives users a hint that additional content is available in a scrollable container.
Just one problem: it broke in Safari iOS 13. One day it was all good. The next, not so much. And that wasn’t the only thing affected. Keith Clark’s CSS-only parallax effect also stopped working right about then.
Well, reader Ronald wrote in to say that all is working once again! In fact, I’m writing this on my iPad (Safari 15.5) right now and Chris’s demo is looking sharp as ever. So is Keith’s original demo.
Added support for one-finger accelerated scrolling to all frames and overflow:scroll elements eliminating the need to set-webkit-overflow-scrolling: touch.
Changed the default behavior on iPad for wide web pages with responsive meta-tags that require horizontal scrolling. Pages are scaled to prevent horizontal scrolling and any text is resized to preserve legibility.
When was it fixed and what fixed it? Well, on the scroll shadow side, the Safari 15.4 included some work on background-attachment: local that may have done the trick. On the parallax side, Safari 14.1 added support for individual transform properties… so maybe that?
. 
