When using View Transitions you’ll notice the page becomes unresponsive to clicks while a View Transition is running. […] This happens because of the
::view-transitionpseudo element – the one that contains all animated snapshots – gets overlayed on top of the document and captures all the clicks.
::view-transition /* 👈 Captures all the clicks! */
└─ ::view-transition-group(root)
└─ ::view-transition-image-pair(root)
├─ ::view-transition-old(root)
└─ ::view-transition-new(root)The trick? It’s that sneaky little pointer-events property! Slapping it directly on the :view-transition allows us to click “under” the pseudo-element, meaning the full page is interactive even while the view transition is running.
::view-transition {
pointer-events: none;
}I always, always, always forget about pointer-events, so thanks to Bramus for posting this little snippet. I also appreciate the additional note about removing the :root element from participating in the view transition:
:root {
view-transition-name: none;
}He quotes the spec noting the reason why snapshots do not respond to hit-testing:
Elements participating in a transition need to skip painting in their DOM location because their image is painted in the corresponding
::view-transition-new()pseudo-element instead. Similarly, hit-testing is skipped because the element’s DOM location does not correspond to where its contents are rendered.
Keeping the page interactive while a View Transition is running originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
I often wonder what it’s like working for the Chrome team. You must get issued some sort of government-level security clearance for the latest browser builds that grants you permission to bash on them ahead of everyone else and come up with these rad demos showing off the latest features. No, I’m, not jealous, why are you asking?
Totally unrelated, did you see the release notes for Chrome 133? It’s currently in beta, but the Chrome team has been publishing a slew of new articles with pretty incredible demos that are tough to ignore. I figured I’d round those up in one place.
attr() for the masses!We’ve been able to use HTML attributes in CSS for some time now, but it’s been relegated to the content property and only parsed strings.
<h1 data-color="orange">Some text</h1>h1::before {
content: ' (Color: ' attr(data-color) ') ';
}Bramus demonstrates how we can now use it on any CSS property, including custom properties, in Chrome 133. So, for example, we can take the attribute’s value and put it to use on the element’s color property:
h1 {
color: attr(data-color type(<color>), #fff)
}This is a trite example, of course. But it helps illustrate that there are three moving pieces here:
data-color)type(<color>))#fff)We make up the attribute. It’s nice to have a wildcard we can insert into the markup and hook into for styling. The type() is a new deal that helps CSS know what sort of value it’s working with. If we had been working with a numeric value instead, we could ditch that in favor of something less verbose. For example, let’s say we’re using an attribute for the element’s font size:
<div data-size="20">Some text</div>Now we can hook into the data-size attribute and use the assigned value to set the element’s font-size property, based in px units:
h1 {
color: attr(data-size px, 16);
}The fallback value is optional and might not be necessary depending on your use case.
This is a mind-blowing one. If you’ve ever wanted a way to style a sticky element when it’s in a “stuck” state, then you already know how cool it is to have something like this. Adam Argyle takes the classic pattern of an alphabetical list and applies styles to the letter heading when it sticks to the top of the viewport. The same is true of elements with scroll snapping and elements that are scrolling containers.
In other words, we can style elements when they are “stuck”, when they are “snapped”, and when they are “scrollable”.
Quick little example that you’ll want to open in a Chromium browser:
The general idea (and that’s all I know for now) is that we register a container… you know, a container that we can query. We give that container a container-type that is set to the type of scrolling we’re working with. In this case, we’re working with sticky positioning where the element “sticks” to the top of the page.
.sticky-nav {
container-type: scroll-state;
}A container can’t query itself, so that basically has to be a wrapper around the element we want to stick. Menus are a little funny because we have the <nav> element and usually stuff it with an unordered list of links. So, our <nav> can be the container we query since we’re effectively sticking an unordered list to the top of the page.
<nav class="sticky-nav">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Blog</a></li>
</ul>
</nav>We can put the sticky logic directly on the <nav> since it’s technically holding what gets stuck:
.sticky-nav {
container-type: scroll-state; /* set a scroll container query */
position: sticky; /* set sticky positioning */
top: 0; /* stick to the top of the page */
}I supposed we could use the container shorthand if we were working with multiple containers and needed to distinguish one from another with a container-name. Either way, now that we’ve defined a container, we can query it using @container! In this case, we declare the type of container we’re querying:
@container scroll-state() { }And we tell it the state we’re looking for:
@container scroll-state(stuck: top) {If we were working with a sticky footer instead of a menu, then we could say stuck: bottom instead. But the kicker is that once the <nav> element sticks to the top, we get to apply styles to it in the @container block, like so:
.sticky-nav {
border-radius: 12px;
container-type: scroll-state;
position: sticky;
top: 0;
/* When the nav is in a "stuck" state */
@container scroll-state(stuck: top) {
border-radius: 0;
box-shadow: 0 3px 10px hsl(0 0 0 / .25);
width: 100%;
}
}It seems to work when nesting other selectors in there. So, for example, we can change the links in the menu when the navigation is in its stuck state:
.sticky-nav {
/* Same as before */
a {
color: #000;
font-size: 1rem;
}
/* When the nav is in a "stuck" state */
@container scroll-state(stuck: top) {
/* Same as before */
a {
color: orangered;
font-size: 1.5rem;
}
}
}So, yeah. As I was saying, it must be pretty cool to be on the Chrome developer team and get ahead of stuff like this, as it’s released. Big ol’ thanks to Bramus and Adam for consistently cluing us in on what’s new and doing the great work it takes to come up with such amazing demos to show things off.
Chrome 133 Goodies originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
Surely you have seen a CSS property and thought “Why?” For example:
Why doesn’t
z-indexwork on all elements, and why is it “-index” anyways?
Or:
Why do we need
interpolate-sizeto animate toauto?
You are not alone. CSS was born in 1996 (it can legally order a beer, you know!) and was initially considered a way to style documents; I don’t think anyone imagined everything CSS would be expected to do nearly 30 years later. If we had a time machine, many things would be done differently to match conventions or to make more sense. Heck, even the CSS Working Group admits to wanting a time-traveling contraption… in the specifications!
NOTE: If we had a time machine, this property wouldn’t need to exist.
CSS Values and Units Module Level 5, Section 10.4
If by some stroke of opportunity, I was given free rein to rename some things in CSS, a couple of ideas come to mind, but if you want more, you can find an ongoing list of mistakes made in CSS… by the CSS Working Group! Take, for example, background-repeat:
Not quite a mistake, because it was a reasonable default for the 90s, but it would be more helpful since then if
background-repeatdefaulted tono-repeat.Right now, people are questioning if CSS Flexbox and CSS Grid should share more syntax in light of the upcoming CSS Masonry layout specifications.
Why not fix them? Sadly, it isn’t as easy as fixing something. People already built their websites with these quirks in mind, and changing them would break those sites. Consider it technical debt.
This is why I think the CSS Working Group deserves an onslaught of praise. Designing new features that are immutable once shipped has to be a nerve-wracking experience that involves inexact science. It’s not that we haven’t seen the specifications change or evolve in the past — they most certainly have — but the value of getting things right the first time is a beast of burden.
The Mistakes of CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
Have you ever stumbled upon something new and went to research it just to find that there is little-to-no information about it? It’s a mixed feeling: confusing and discouraging because there is no apparent direction, but also exciting because it’s probably new to lots of people, not just you. Something like that happened to me while writing an Almanac’s entry for the @view-transition at-rule and its types descriptor.
You may already know about Cross-Document View Transitions: With a few lines of CSS, they allow for transitions between two pages, something that in the past required a single-app framework with a side of animation library. In other words, lots of JavaScript.
To start a transition between two pages, we have to set the @view-transition at-rule’s navigation descriptor to auto on both pages, and that gives us a smooth cross-fade transition between the two pages. So, as the old page fades out, the new page fades in.
@view-transition {
navigation: auto;
}That’s it! And navigation is the only descriptor we need. In fact, it’s the only descriptor available for the @view-transition at-rule, right? Well, turns out there is another descriptor, a lesser-known brother, and one that probably envies how much attention navigation gets: the types descriptor.
types?Cross-Documents View Transitions are still fresh from the oven, so it’s normal that people haven’t fully dissected every aspect of them, especially since they introduce a lot of new stuff: a new at-rule, a couple of new properties and tons of pseudo-elements and pseudo-classes. However, it still surprises me the little mention of types. Some documentation fails to even name it among the valid @view-transition descriptors. Luckily, though, the CSS specification does offer a little clarification about it:
The
typesdescriptor sets the active types for the transition when capturing or performing the transition.
To be more precise, types can take a space-separated list with the names of the active types (as <custom-ident>), or none if there aren’t valid active types for that page.
@view-transitionnone | <custom-ident>+So the following values would work inside types:
@view-transition {
navigation: auto;
types: bounce;
}
/* or a list */
@view-transition {
navigation: auto;
types: bounce fade rotate;
}Yes, but what exactly are “active” types? That word “active” seems to be doing a lot of heavy lifting in the CSS specification’s definition and I want to unpack that to better understand what it means.
The problem: A cross-fade animation for every page is good, but a common thing we need to do is change the transition depending on the pages we are navigating between. For example, on paginated content, we could slide the content to the right when navigating forward and to the left when navigating backward. In a social media app, clicking a user’s profile picture could persist the picture throughout the transition. All this would mean defining several transitions in our CSS, but doing so would make them conflict with each other in one big slop. What we need is a way to define several transitions, but only pick one depending on how the user navigates the page.
The solution: Active types define which transition gets used and which elements should be included in it. In CSS, they are used through :active-view-transition-type(), a pseudo-class that matches an element if it has a specific active type. Going back to our last example, we defined the document’s active type as bounce. We could enclose that bounce animation behind an :active-view-transition-type(bounce), such that it only triggers on that page.
/* This one will be used! */
html:active-view-transition-type(bounce) {
&::view-transition-old(page) {
/* Custom Animation */
}
&::view-transition-new(page) {
/* Custom Animation */
}
}This prevents other view transitions from running if they don’t match any active type:
/* This one won't be used! */
html:active-view-transition-type(slide) {
&::view-transition-old(page) {
/* Custom Animation */
}
&::view-transition-new(page) {
/* Custom Animation */
}
}
I asked myself whether this triggers the transition when going to the page, when out of the page, or in both instances. Turns out it only limits the transition when going to the page, so the last bounce animation is only triggered when navigating toward a page with a bounce value on its types descriptor, but not when leaving that page. This allows for custom transitions depending on which page we are going to.
The following demo has two pages that share a stylesheet with the bounce and slide view transitions, both respectively enclosed behind an :active-view-transition-type(bounce) and :active-view-transition-type(slide) like the last example. We can control which page uses which view transition through the types descriptor.
The first page uses the bounce animation:
@view-transition {
navigation: auto;
types: bounce;
}The second page uses the slide animation:
@view-transition {
navigation: auto;
types: slide;
}You can visit the demo here and see the full code over at GitHub.
types descriptor is used more in JavaScriptThe main problem is that we can only control the transition depending on the page we’re navigating to, which puts a major cap on how much we can customize our transitions. For instance, the pagination and social media examples we looked at aren’t possible just using CSS, since we need to know where the user is coming from. Luckily, using the types descriptor is just one of three ways that active types can be populated. Per spec, they can be:
startViewTransition(callbackOptions)types descriptor.The first option is when starting a view transition from JavaScript, but we want to trigger them when the user navigates to the page by themselves (like when clicking a link). The third option is using the types descriptor which we already covered. The second option is the right one for this case! Why? It lets us set the active transition type on demand, and we can perform that change just before the transition happens using the pagereveal event. That means we can get the user’s start and end page from JavaScript and then set the correct active type for that case.
I must admit, I am not the most experienced guy to talk about this option, so once I demo the heck out of different transitions with active types I’ll come back with my findings! In the meantime, I encourage you to read about active types here if you are like me and want more on view transitions:
What on Earth is the `types` Descriptor in View Transitions? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
Honestly, it’s difficult for me to come to terms with, but almost 20 years have passed since I wrote my first book, Transcending CSS. In it, I explained how and why to use what was the then-emerging Multi-Column Layout module.
Hint: I published an updated version, Transcending CSS Revisited, which is free to read online.
Perhaps because, before the web, I’d worked in print, I was over-excited at the prospect of dividing content into columns without needing extra markup purely there for presentation. I’ve used Multi-Column Layout regularly ever since. Yet, CSS Columns remains one of the most underused CSS layout tools. I wonder why that is?
For a long time, there were, and still are, plenty of holes in Multi-Column Layout. As Rachel Andrew — now a specification editor — noted in her article five years ago:
“The column boxes created when you use one of the column properties can’t be targeted. You can’t address them with JavaScript, nor can you style an individual box to give it a background colour or adjust the padding and margins. All of the column boxes will be the same size. The only thing you can do is add a rule between columns.”
She’s right. And that’s still true. You can’t style columns, for example, by alternating background colours using some sort of :nth-column() pseudo-class selector. You can add a column-rule between columns using border-style values like dashed, dotted, and solid, and who can forget those evergreen groove and ridge styles? But you can’t apply border-image values to a column-rule, which seems odd as they were introduced at roughly the same time. The Multi-Column Layout is imperfect, and there’s plenty I wish it could do in the future, but that doesn’t explain why most people ignore what it can do today.
Legacy browsers simply ignored the column properties they couldn’t process. But, when Multi-Column Layout was first launched, most designers and developers had yet to accept that websites needn’t look the same in every browser.
Early on, support for Multi-Column Layout was patchy. However, browsers caught up over time, and although there are still discrepancies — especially in controlling content breaks — Multi-Column Layout has now been implemented widely. Yet, for some reason, many designers and developers I speak to feel that CSS Columns remain broken. Yes, there’s plenty that browser makers should do to improve their implementations, but that shouldn’t prevent people from using the solid parts today.
Maybe the main reason designers and developers haven’t embraced Multi-Column Layout as they have CSS Grid and Flexbox isn’t in the specification or its implementation but in its usability. Rachel pointed this out in her article:
“One reason we don’t see multicol used much on the web is that it would be very easy to end up with a reading experience which made the reader scroll in the block dimension. That would mean scrolling up and down vertically for those of us using English or another vertical writing mode. This is not a good reading experience!”
That’s true. No one would enjoy repeatedly scrolling up and down to read a long passage of content set in columns. She went on:
“Neither of these things is ideal, and using multicol on the web is something we need to think about very carefully in terms of the amount of content we might be aiming to flow into our columns.”
But, let’s face it, thinking very carefully is what designers and developers should always be doing.
Sure, if you’re dumb enough to dump a large amount of content into columns without thinking about its design, you’ll end up serving readers a poor experience. But why would you do that when headlines, images, and quotes can span columns and reset the column flow, instantly improving readability? Add to that container queries and newer unit values for text sizing, and there really isn’t a reason to avoid using Multi-Column Layout any longer.
Let’s run through a refresher. There are two ways to flow content into multiple columns; first, by defining the number of columns you need using the column-count property:
Second, and often best, is specifying the column width, leaving a browser to decide how many columns will fit along the inline axis. For example, I’m using column-width to specify that my columns are over 18rem. A browser creates as many 18rem columns as possible to fit and then shares any remaining space between them.
Then, there is the gutter (or column-gap) between columns, which you can specify using any length unit. I prefer using rem units to maintain the gutters’ relationship to the text size, but if your gutters need to be 1em, you can leave this out, as that’s a browser’s default gap.
The final column property is that divider (or column-rule) to the gutters, which adds visual separation between columns. Again, you can set a thickness and use border-style values like dashed, dotted, and solid.
These examples will be seen whenever you encounter a Multi-Column Layout tutorial, including CSS-Tricks’ own Almanac. The Multi-Column Layout syntax is one of the simplest in the suite of CSS layout tools, which is another reason why there are few reasons not to use it.
When I wrote Transcending CSS and first explained the emerging Multi-Column Layout, there were no rem or viewport units, no :has() or other advanced selectors, no container queries, and no routine use of media queries because responsive design hadn’t been invented.
We didn’t have calc() or clamp() for adjusting text sizes, and there was no CSS Grid or Flexible Box Layout for precise control over a layout. Now we do, and all these properties help to make Multi-Column Layout even more relevant today.
Now, you can use rem or viewport units combined with calc() and clamp() to adapt the text size inside CSS Columns. You can use :has() to specify when columns are created, depending on the type of content they contain. Or you might use container queries to implement several columns only when a container is large enough to display them. Of course, you can also combine a Multi-Column Layout with CSS Grid or Flexible Box Layout for even more imaginative layout designs.
My challenge was to implement a flexible article layout without media queries which adapts not only to screen size but also whether or not a <figure> is present. To improve the readability of running text in what would potentially be too-long lines, it should be set in columns to narrow the measure. And, as a final touch, the text size should adapt to the width of the container, not the viewport.
<figure> element. What would potentially be too-long lines of text are set in columns to improve readability by narrowing the measure.
<figure> element. No column text is needed for this narrower measure.The HTML for this layout is rudimentary. One <section>, one <main>, and one <figure> (or not:)
<section>
<main>
<h1>About Patty</h1>
<p>…</p>
</main>
<figure>
<img>
</figure>
</section>I started by adding Multi-Column Layout styles to the <main> element using the column-width property to set the width of each column to 40ch (characters). The max-width and automatic inline margins reduce the content width and center it in the viewport:
main {
margin-inline: auto;
max-width: 100ch;
column-width: 40ch;
column-gap: 3rem;
column-rule: .5px solid #98838F;
}Next, I applied a flexible box layout to the <section> only if it :has() a direct descendant which is a <figure>:
section:has(> figure) {
display: flex;
flex-wrap: wrap;
gap: 0 3rem;
}This next min-width: min(100%, 30rem) — applied to both the <main> and <figure> — is a combination of the min-width property and the min() CSS function. The min() function allows you to specify two or more values, and a browser will choose the smallest value from them. This is incredibly useful for responsive layouts where you want to control the size of an element based on different conditions:
section:has(> figure) main {
flex: 1;
margin-inline: 0;
min-width: min(100%, 30rem);
}
section:has(> figure) figure {
flex: 4;
min-width: min(100%, 30rem);
}What’s efficient about this implementation is that Multi-Column Layout styles are applied throughout, with no need for media queries to switch them on or off.
Adjusting text size in relation to column width helps improve readability. This has only recently become easy to implement with the introduction of container queries, their associated values including cqi, cqw, cqmin, and cqmax. And the clamp() function. Fortunately, you don’t have to work out these text sizes manually as ClearLeft’s Utopia will do the job for you.
My headlines and paragraph sizes are clamped to their minimum and maximum rem sizes and between them text is fluid depending on their container’s inline size:
h1 { font-size: clamp(5.6526rem, 5.4068rem + 1.2288cqi, 6.3592rem); }
h2 { font-size: clamp(1.9994rem, 1.9125rem + 0.4347cqi, 2.2493rem); }
p { font-size: clamp(1rem, 0.9565rem + 0.2174cqi, 1.125rem); }So, to specify the <main> as the container on which those text sizes are based, I applied a container query for its inline size:
main {
container-type: inline-size;
}Open the final result in a desktop browser, when you’re in front of one. It’s a flexible article layout without media queries which adapts to screen size and the presence of a <figure>. Multi-Column Layout sets text in columns to narrow the measure and the text size adapts to the width of its container, not the viewport.
Almost every article I’ve ever read about Multi-Column Layout focuses on its flaws, especially usability. CSS-Tricks’ own Geoff Graham even mentioned the scrolling up and down issue when he asked, “When Do You Use CSS Columns?”
“But an entire long-form article split into columns? I love it in newspapers but am hesitant to scroll down a webpage to read one column, only to scroll back up to do it again.”
Fortunately, the column-span property — which enables headlines, images, and quotes to span columns, resets the column flow, and instantly improves readability — now has solid support in browsers:
h1, h2, blockquote {
column-span: all;
}But the solution to the scrolling up and down issue isn’t purely technical. It also requires content design. This means that content creators and designers must think carefully about the frequency and type of spanning elements, dividing a Multi-Column Layout into shallower sections, reducing the need to scroll and improving someone’s reading experience.
Another prior problem was preventing headlines from becoming detached from their content and figures, dividing their images and captions between columns. Thankfully, the break-after property now also has widespread support, so orphaned images and captions are now a thing of the past:
figure {
break-after: column;
}Open this final example in a desktop browser:
Multi-Column Layout isn’t a shiny new tool. In fact, it remains one of the most underused layout tools in CSS. It’s had, and still has, plenty of problems, but they haven’t reduced its usefulness or its ability to add an extra level of refinement to a product or website’s design. Whether you haven’t used Multi-Column Layout in a while or maybe have never tried it, now’s the time to take a fresh look at Multi-Column Layout.
Revisiting CSS Multi-Column Layout originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
When it comes to positioning elements on a page, including text, there are many ways to go about it in CSS — the literal position property with corresponding inset-* properties, translate, margin, anchor() (limited browser support at the moment), and so forth. The offset property is another one that belongs in that list.
The offset property is typically used for animating an element along a predetermined path. For instance, the square in the following example traverses a circular path:
<div class="circle">
<div class="square"></div>
</div>@property --p {
syntax: '<percentage>';
inherits: false;
initial-value: 0%;
}
.square {
offset: top 50% right 50% circle(50%) var(--p);
transition: --p 1s linear;
/* Equivalent to:
offset-position: top 50% right 50%;
offset-path: circle(50%);
offset-distance: var(--p); */
/* etc. */
}
.circle:hover .square{ --p: 100%; }A registered CSS custom property (--p) is used to set and animate the offset distance of the square element. The animation is possible because an element can be positioned at any point in a given path using offset. and maybe you didn’t know this, but offset is a shorthand property comprised of the following constituent properties:
offset-position: The path’s starting pointoffset-path: The shape along which the element can be movedoffset-distance: A distance along the path on which the element is movedoffset-rotate: The rotation angle of an element relative to its anchor point and offset pathoffset-anchor: A position within the element that’s aligned to the pathThe offset-path property is the one that’s important to what we’re trying to achieve. It accepts a shape value — including SVG shapes or CSS shape functions — as well as reference boxes of the containing element to create the path.
Reference boxes? Those are an element’s dimensions according to the CSS Box Model, including content-box, padding-box, border-box, as well as SVG contexts, such as the view-box, fill-box, and stroke-box. These simplify how we position elements along the edges of their containing elements. Here’s an example: all the small squares below are placed in the default top-left corner of their containing elements’ content-box. In contrast, the small circles are positioned along the top-right corner (25% into their containing elements’ square perimeter) of the content-box, border-box, and padding-box, respectively.
<div class="big">
<div class="small circle"></div>
<div class="small square"></div>
<p>She sells sea shells by the seashore</p>
</div>
<div class="big">
<div class="small circle"></div>
<div class="small square"></div>
<p>She sells sea shells by the seashore</p>
</div>
<div class="big">
<div class="small circle"></div>
<div class="small square"></div>
<p>She sells sea shells by the seashore</p>
</div>.small {
/* etc. */
position: absolute;
&.square {
offset: content-box;
border-radius: 4px;
}
&.circle { border-radius: 50%; }
}
.big {
/* etc. */
contain: layout; /* (or position: relative) */
&:nth-of-type(1) {
.circle { offset: content-box 25%; }
}
&:nth-of-type(2) {
border: 20px solid rgb(170 232 251);
.circle { offset: border-box 25%; }
}
&:nth-of-type(3) {
padding: 20px;
.circle { offset: padding-box 25%; }
}
}Note: You can separate the element’s offset-positioned layout context if you don’t want to allocated space for it inside its containing parent element. That’s how I’ve approached it in the example above so that the paragraph text inside can sit flush against the edges. As a result, the offset positioned elements (small squares and circles) are given their own contexts using position: absolute, which removes them from the normal document flow.
This method, positioning relative to reference boxes, makes it easy to place elements like notification dots and ornamental ribbon tips along the periphery of some UI module. It further simplifies the placement of texts along a containing block’s edges, as offset can also rotate elements along the path, thanks to offset-rotate. A simple example shows the date of an article placed at a block’s right edge:
<article>
<h1>The Irreplaceable Value of Human Decision-Making in the Age of AI</h1>
<!-- paragraphs -->
<div class="date">Published on 11<sup>th</sup> Dec</div>
<cite>An excerpt from the HBR article</cite>
</article>article {
container-type: inline-size;
/* etc. */
}
.date {
offset: padding-box 100cqw 90deg / left 0 bottom -10px;
/*
Equivalent to:
offset-path: padding-box;
offset-distance: 100cqw; (100% of the container element's width)
offset-rotate: 90deg;
offset-anchor: left 0 bottom -10px;
*/
}As we just saw, using the offset property with a reference box path and container units is even more efficient — you can easily set the offset distance based on the containing element’s width or height. I’ll include a reference for learning more about container queries and container query units in the “Further Reading” section at the end of this article.
There’s also the offset-anchor property that’s used in that last example. It provides the anchor for the element’s displacement and rotation — for instance, the 90 degree rotation in the example happens from the element’s bottom-left corner. The offset-anchor property can also be used to move the element either inward or outward from the reference box by adjusting inset-* values — for instance, the bottom -10px arguments pull the element’s bottom edge outwards from its containing element’s padding-box. This enhances the precision of placements, also demonstrated below.
<figure>
<div class="big">4</div>
<div class="small">number four</div>
</figure>.small {
width: max-content;
offset: content-box 90% -54deg / center -3rem;
/*
Equivalent to:
offset-path: content-box;
offset-distance: 90%;
offset-rotate: -54deg;
offset-anchor: center -3rem;
*/
font-size: 1.5rem;
color: navy;
}As shown at the beginning of the article, offset positioning is animateable, which allows for dynamic design effects, like this:
<article>
<figure>
<div class="small one">17<sup>th</sup> Jan. 2025</div>
<span class="big">Seminar<br>on<br>Literature</span>
<div class="small two">Tickets Available</div>
</figure>
</article>@property --d {
syntax: "<percentage>";
inherits: false;
initial-value: 0%;
}
.small {
/* other style rules */
offset: content-box var(--d) 0deg / left center;
/*
Equivalent to:
offset-path: content-box;
offset-distance: var(--d);
offset-rotate: 0deg;
offset-anchor: left center;
*/
transition: --d .2s linear;
&.one { --d: 2%; }
&.two { --d: 70%; }
}
article:hover figure {
.one { --d: 15%; }
.two { --d: 80%; }
}Whether for graphic designs like text along borders, textual annotations, or even dynamic texts like error messaging, CSS offset is an easy-to-use option to achieve all of that. We can position the elements along the reference boxes of their containing parent elements, rotate them, and even add animation if needed.
offset-path property: CSS-Tricks, MDNoffset-anchor property: CSS-Tricks, MDN@property at-rule: CSS-Tricks, web.devPositioning Text Around Elements With CSS Offset originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
Chris wrote about “Likes” pages a long while back. The idea is rather simple: “Like” an item in your RSS reader and display it in a feed of other liked items. The little example Chris made is still really good.
There were two things Chris noted at the time. One was that he used a public CORS proxy that he wouldn’t use in a production environment. Good idea to nix that, security and all. The other was that he’d consider using WordPress transients to fetch and cache the data to work around CORS.
I decided to do that! The result is this WordPress block I can drop right in here. I’ll plop it in a <details> to keep things brief.
In my post Brief Note on Figure and Figcaption Support I demonstrate how, when encountering a figure with a screen reader, you won’t hear everything announced at once:
No screen reader combo treats the caption as the accessible name nor accessible description, not even for an…
One of the running jokes and/or discussion I am sick and tired of is people belittling HTML. Yes, HTML is not a programming language. No, HTML should not just be a compilation target. Learning HTML is a solid investment and not hard to do.
I am not…
Presenting Open Props UI!…
I’m playing with making cross-document view transitions work on this blog.
Nothing fancy. Mostly copying how Dave Rupert does it on his site where you get a cross-fade animation on the whole page generally, and a little position animation on the page title specifically.
We can use the :empty pseudo-class as a way to style elements on your webpage that are empty.
You might wonder why you’d want to style something that’s empty. Let’s say you’re creating a todo list.
You want to put your todo items in a list, but what about when you don’t…
Back in 2023, I belatedly jumped on the bandwagon of people posting their CSS wish lists for the coming year. This year I’m doing all that again, less belatedly! (I didn’t do it last year because I couldn’t even. Get it?)
I started this post by looking at what I…
It does, actually. In Firefox. Sometimes.
A major risk of using ARIA to define text content is it typically gets overlooked in translation. Automated translation services often do not capture it. Those who pay for localization services frequently miss content in ARIA attributes when sending text strings to localization vendors.
Content buried…
6 years back I posted the Simplest Way to Load CSS Asynchronously to document a hack we’d been using for at least 6 years prior to that. The use case for this hack is to load CSS files asynchronously, something that HTML itself still does not support, even though…
I’ve been excited by the potential of text-box-trim, text-edge and text-box for a while. They’re in draft status at the moment, but when more browser support is available, this capability will open up some exciting possibilities for improving typesetting in the browser, as well as giving us more…
It’s a little different. For one, I’m only fetching 10 items at a time. We could push that to infinity but that comes with a performance tax, not to mention I have no way of organizing the items for them to be grouped and filtered. Maybe that’ll be a future enhancement!
The Chris demo provided the bones and it does most of the heavy lifting. The “tough” parts were square-pegging the thing into a WordPress block architecture and then getting transients going. This is my first time working with transients, so I thought I’d share the relevant code and pick it apart.
function fetch_and_store_data() {
$transient_key = 'fetched_data';
$cached_data = get_transient($transient_key);
if ($cached_data) {
return new WP_REST_Response($cached_data, 200);
}
$response = wp_remote_get('https://feedbin.com/starred/a22c4101980b055d688e90512b083e8d.xml');
if (is_wp_error($response)) {
return new WP_REST_Response('Error fetching data', 500);
}
$body = wp_remote_retrieve_body($response);
$data = simplexml_load_string($body, 'SimpleXMLElement', LIBXML_NOCDATA);
$json_data = json_encode($data);
$array_data = json_decode($json_data, true);
$items = [];
foreach ($array_data['channel']['item'] as $item) {
$items[] = [
'title' => $item['title'],
'link' => $item['link'],
'pubDate' => $item['pubDate'],
'description' => $item['description'],
];
}
set_transient($transient_key, $items, 12 * HOUR_IN_SECONDS);
return new WP_REST_Response($items, 200);
}
add_action('rest_api_init', function () {
register_rest_route('custom/v1', '/fetch-data', [
'methods' => 'GET',
'callback' => 'fetch_and_store_data',
]);
});Could this be refactored and written more efficiently? All signs point to yes. But here’s how I grokked it:
function fetch_and_store_data() {
}The function’s name can be anything. Naming is hard. The first two variables:
$transient_key = 'fetched_data';
$cached_data = get_transient($transient_key);The $transient_key is simply a name that identifies the transient when we set it and get it. In fact, the $cached_data is the getter so that part’s done. Check!
I only want the $cached_data if it exists, so there’s a check for that:
if ($cached_data) {
return new WP_REST_Response($cached_data, 200);
}This also establishes a new response from the WordPress REST API, which is where the data is cached. Rather than pull the data directly from Feedbin, I’m pulling it and caching it in the REST API. This way, CORS is no longer an issue being that the starred items are now locally stored on my own domain. That’s where the wp_remote_get() function comes in to form that response from Feedbin as the origin:
$response = wp_remote_get('https://feedbin.com/starred/a22c4101980b055d688e90512b083e8d.xml');Similarly, I decided to throw an error if there’s no $response. That means there’s no freshly $cached_data and that’s something I want to know right away.
if (is_wp_error($response)) {
return new WP_REST_Response('Error fetching data', 500);
}The bulk of the work is merely parsing the XML data I get back from Feedbin to JSON. This scours the XML and loops through each item to get its title, link, publish date, and description:
$body = wp_remote_retrieve_body($response);
$data = simplexml_load_string($body, 'SimpleXMLElement', LIBXML_NOCDATA);
$json_data = json_encode($data);
$array_data = json_decode($json_data, true);
$items = [];
foreach ($array_data['channel']['item'] as $item) {
$items[] = [
'title' => $item['title'],
'link' => $item['link'],
'pubDate' => $item['pubDate'],
'description' => $item['description'],
];
}“Description” is a loaded term. It could be the full body of a post or an excerpt — we don’t know until we get it! So, I’m splicing and trimming it in the block’s Edit component to stub it at no more than 50 words. There’s a little risk there because I’m rendering the HTML I get back from the API. Security, yes. But there’s also the chance I render an open tag without its closing counterpart, muffing up my layout. I know there are libraries to address that but I’m keeping things simple for now.
Now it’s time to set the transient once things have been fetched and parsed:
set_transient($transient_key, $items, 12 * HOUR_IN_SECONDS);The WordPress docs are great at explaining the set_transient() function. It takes three arguments, the first being the $transient_key that was named earlier to identify which transient is getting set. The other two:
$value: This is the object we’re storing in the named transient. That’s the $items object handling all the parsing.$expiration: How long should this transient last? It wouldn’t be transient if it lingered around forever, so we set an amount of time expressed in seconds. Mine lingers for 12 hours before it expires and then updates the next time a visitor hits the page.OK, time to return the items from the REST API as a new response:
return new WP_REST_Response($items, 200);That’s it! Well, at least for setting and getting the transient. The next thing I realized I needed was a custom REST API endpoint to call the data. I really had to lean on the WordPress docs to get this going:
add_action('rest_api_init', function () {
register_rest_route('custom/v1', '/fetch-data', [
'methods' => 'GET',
'callback' => 'fetch_and_store_data',
]);
});That’s where I struggled most and felt like this all took wayyyyy too much time. Well, that and sparring with the block itself. I find it super hard to get the front and back end components to sync up and, honestly, a lot of that code looks super redundant if you were to scope it out. That’s another story altogether.
Enjoy reading what we’re reading! I put a page together that pulls in the 10 most recent items with a link to subscribe to the full feed.
Creating a “Starred” Feed originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
My previous article warned that horizontal motion on Tinder has irreversible consequences. I’ll save venting on that topic for a different blog, but at first glance, swipe-based navigation seems like it could be a job for Web-Slinger.css, your friendly neighborhood experimental pure CSS Wow.js replacement for one-way scroll-triggered animations. I haven’t managed to fit that description into a theme song yet, but I’m working on it.
In the meantime, can Web-Slinger.css swing a pure CSS Tinder-style swiping interaction to indicate liking or disliking an element? More importantly, will this experiment give me an excuse to use an image of Spider Pig, in response to popular demand in the bustling comments section of my previous article? Behold the Spider Pig swiper, which I propose as a replacement for captchas because every human with a pulse loves Spider Pig. With that unbiased statement in mind, swipe left or right below (only Chrome and Edge for now) to reveal a counter showing how many people share your stance on Spider Pig.
The crackpot who invented Web-Slinger.css seems not to have considered horizontal scrolling, but we can patch that maniac’s monstrous creation like so:
[class^="scroll-trigger-"] {
view-timeline-axis: x;
}This overrides the default behavior for marker elements with class names using the Web-Slinger convention of scroll-trigger-n, which activates one-way, scroll-triggered animations. By setting the timeline axis to x, the scroll triggers only run when they are revealed by scrolling horizontally rather than vertically (which is the default). Otherwise, the triggers would run straightaway because although they are out of view due to the container’s width, they will all be above the fold vertically when we implement our swiper.
My steps in laying the foundation for the above demo were to fork this awesome JavaScript demo of Tinder-style swiping by Nikolay Talanov, strip out the JavaScript and all the cards except for one, then import Web-Slinger.css and introduce the horizontal patch explained above. Next, I changed the card’s container to position: fixed, and introduced three scroll-snapping boxes side-by-side, each the height and width of the viewport. I set the middle slide to scroll-align: center so that the user starts in the middle of the page and has the option to scroll backwards or forwards.
Sidenote: When unconventionally using scroll-driven animations like this, a good mindset is that the scrollable element needn’t be responsible for conventionally scrolling anything visible on the page. This approach is reminiscent of how the first thing you do when using checkbox hacks is hide the checkbox and make the label look like something else. We leverage the CSS-driven behaviors of a scrollable element, but we don’t need the default UI behavior.
I put a div marked with scroll-trigger-1 on the third slide and used it to activate a rejection animation on the card like this:
<div class="demo__card on-scroll-trigger-1 reject">
<!-- HTML for the card -->
</div>
<main>
<div class="slide">
</div>
<div id="middle" class="slide">
</div>
<div class="slide">
<div class="scroll-trigger-1"></div>
</div>
</main>It worked the way I expected! I knew this would be easy! (Narrator: it isn’t, you’ll see why next.)
<div class="on-scroll-trigger-2 accept">
<div class="demo__card on-scroll-trigger-2 reject">
<!-- HTML for the card -->
</div>
</div>
<main>
<div class="slide">
<div class="scroll-trigger-2"></div>
</div>
<div id="middle" class="slide">
</div>
<div class="slide">
<div class="scroll-trigger-1"></div>
</div>
</main>After adding this, Spider Pig is automatically ”liked” when the page loads. That would be appropriate for a card that shows a person like myself who everybody automatically likes — after all, a middle-aged guy who spends his days and nights hacking CSS is quite a catch. By contrast, it is possible Spider Pig isn’t everyone’s cup of tea. So, let’s understand why the swipe right implementation would behave differently than the swipe left implementation when we thought we applied the same principles to both implementations.
This bug drove home to me what view-timeline does and doesn’t do. The lunatic creator of Web-Slinger.css relied on tech that wasn’t made for animations which run only when the user scrolls backwards.
This visualizer shows that no matter what options you choose for animation-range, the subject wants to complete its animation after it has crossed the viewport in the scrolling direction — which is exactly what we do not want to happen in this particular case.
Fortunately, our friendly neighborhood Bramus from the Chrome Developer Team has a cool demo showing how to detect scroll direction in CSS. Using the clever --scroll-direction CSS custom property Bramus made, we can ensure Spider Pig animates at the right time rather than on load. The trick is to control the appearance of .scroll-trigger-2 using a style query like this:
:root {
animation: adjust-slide-index 3s steps(3, end), adjust-pos 1s;
animation-timeline: scroll(root x);
}
@property --slide-index {
syntax: "<number>";
inherits: true;
initial-value: 0;
}
@keyframes adjust-slide-index {
to {
--slide-index: 3;
}
}
.scroll-trigger-2 {
display: none;
}
@container style(--scroll-direction: -1) and style(--slide-index: 0) {
.scroll-trigger-2 {
display: block;
}
}That style query means that the marker with the .scroll-trigger-2 class will not be rendered until we are on the previous slide and reach it by scrolling backward. Notice that we also introduced another variable named --slide-index, which is controlled by a three-second scroll-driven animation with three steps. It counts the slide we are on, and it is used because we want the user to swipe decisively to activate the dislike animation. We don’t want just any slight breeze to trigger a dislike.
As mentioned at the outset, measuring how many CSS-Tricks readers dislike Spider Pig versus how many have a soul is important. To capture this crucial stat, I’m using a third-party counter image as a background for the card underneath the Spider Pig card. It is third-party, but hopefully, it will always work because the website looks like it has survived since the dawn of the internet. I shouldn’t complain because the price is right. I chose the least 1990s-looking counter and used it like this:
@container style(--scroll-trigger-1: 1) {
.result {
background-image: url('https://counter6.optistats.ovh/private/freecounterstat.php?c=qbgw71kxx1stgsf5shmwrb2aflk5wecz');
background-repeat: no-repeat;
background-attachment: fixed;
background-position: center;
}
.counter-description::after {
content: 'who like spider pig';
}
.scroll-trigger-2 {
display: none;
}
}
@container style(--scroll-trigger-2: 1) {
.result {
background-image: url('https://counter6.optistats.ovh/private/freecounterstat.php?c=abtwsn99snah6wq42nhnsmbp6pxbrwtj');
background-repeat: no-repeat;
background-attachment: fixed;
background-position: center;
}
.counter-description::after {
content: 'who dislike spider pig';
}
.scroll-trigger-1 {
display: none;
}
}This hack turned out more complex than I expected, mostly because of the complexity of using scroll-triggered animations that only run when you meet an element by scrolling backward which goes against assumptions made by the current API. That’s a good thing to know and understand. Still, it’s amazing how much power is hidden in the current spec. We can style things based on extremely specific scrolling behaviors if we believe in ourselves. The current API had to be hacked to unlock that power, but I wish we could do something like:
[class^="scroll-trigger-"] {
view-timeline-axis: x;
view-timeline-direction: backwards; /* <-- this is speculative. do not use! */
}With an API like that allowing the swipe-right scroll trigger to behave the way I originally imagined, the Spider Pig swiper would not require hacking.
I dream of wider browser support for scroll-driven animations. But I hope to see the spec evolve to give us more flexibility to encourage designers to build nonlinear storytelling into the experiences they create. If not, once animation timelines land in more browsers, it might be time to make Web-Slinger.css more complete and production-ready, to make the more advanced scrolling use cases accessible to the average CSS user.
Web-Slinger.css: Across the Swiper-Verse originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.
With a high of F and a low of 48F. Currently, it's 66F and Clear outside. Current wind speeds: 11 from the West Pollen: 0 Sunris...
