For a project I’m working at, we’re building in some carousels (aka content sliders). While building a scroll-snapping carousel in itself is no rocket science nowadays, there was an extra variation that made my eyes sparkle: a full-bleed carousel that spans the entire page, with its focussed slide anchored to the center column of the page, and with the other slides “overflowing” outside of that column.
~
To jump right in, let’s take a look at the final result:
The first carousel shown is a regular/typical one: all slide-wrappers (.slidewrapper) are as big as the carousel (.slider) itself. They slide-wrappers are laid out on one row using CSS Flexbox. Because they have the same size, the carousel will only show one slide after having scroll-snapped.
The second carousel is the variation I mentioned in the intro: it also visually aligns the focussed slide with the center column — just like the first carousel — but the carousel itself does span the entire width of the page. This leaves the non-centered slides of the carousel also visible, making it look like they’re overflowing outside of the center column.
The solution to this problem uses the same markup and CSS, but with some CSS additions. As it’s not as easy as simply adding overflow: visible; to the .slider — as that would remove the scroll container — I adjusted the CSS as follows:
There’s a gap between each .slidewrapper. This is done using margin-right instead of gap, as older browsers don’t support the property in combination with Flexbox.
And now, the key part:
The first .slidewrapper is given a padding on its left edge so that it appears centered on load. The last .slidewrapper is given a padding on its right edge so that it appears centered watching the last item. To make this work, the .slidewrapper elements need box-sizing: content-box; to be applied.
To grasp this padding-trick better and to see what’s going on, I’ve added a “Show Debug Outlines” option in the CodePen embed above. Take a close look at the green boxes that wrap the first and last slide contents.
Fabio Giolito explores three new CSS color features that landed in Safari Technology Preview:
Relative color syntax, e.g.
.bg-primary-100 {
background-color: hsl(from var(--theme-primary) h s 90%);
}
.bg-primary-200 {
background-color: hsl(from var(--theme-primary) h s 80%);
}
.bg-primary-300 {
background-color: hsl(from var(--theme-primary) h s 70%);
}
...
CSS color-contrast, e.g.
.text-contrast-primary {
color: color-contrast(var(--theme-primary) vs white, black);
}
CSS color-mix, e.g.
.text-primary-dark {
color: color-mix(var(--theme-primary), black 10%);
}
.text-primary-darker {
color: color-mix(var(--theme-primary), black 20%);
}
Container Queries allow authors to style elements according to the size of a container. This is similar to a @media query, except that it evaluates against a container instead of the viewport.
~
Unfortunately the polyfill is not a simple drop-in that will work with your existing CSS code. This is because rendering engines that don’t support Container Queries will discard those specific statements and declarations.
To work around this, the polyfill requires you to duplicate some CSS with an alternative syntax.
Duplicate the value for the contain property into a CSS Custom Property named --css-contain
Duplicate the @container rule as an @media rule bearing the text --css-container
Like so:
/* Create a Container Root */
.container {
contain: layout inline-size; /* For browsers that support Container Queries */
--css-contain: layout inline-size; /* For the polyfill to use */
}
/* Container Query */
@container (min-width: 700px) { /* For browsers that support Container Queries */
.contained {
/* … */
}
}
@media --css-container and (min-width: 700px) { /* For the polyfill to use */
.contained {
/* … */
}
}
As those duplicated rules are valid CSS, browsers won’t discard them and the polyfill can pick them up 🙂
⚠️ It’s very import to use the naming as used in the code above. The Custom Property must be named --css-contain and the Media Query must contain the text --css-container. If named differently, the polyfill won’t be able to pick them up.
~
Once your styles have been declared you can import the polyfill and call it:
import { cqfill } from "https://cdn.skypack.dev/cqfill";
cqfill();
If you want a local copy of CQFill, you can install it per NPM/Yarn.
npm install cqfill
☝️ When using Next.js or PostCSS you don’t even need to call the polyfill, as the CQFill repo includes plugins for those.
~
Here’s my original demo, adjusted to include the polyfill:
But what about other complex elements in the browser? How can we tweak individual parts of those? Take <audio> for example: is there a pseudo-element we can use to style the play button?
Before we answer the question above, let’s first take a look at the <input type="file" /> Stefan used. Below is screenshot of how it’s rendered in Chromium on Mac, with a few extra outlines added.
Even though we only type 1 element in our HTML code, we see it consists of two parts:
A “Choose File” button
A label reading “No file chosen”
Internally, this is also how the browser builds it. We type in:
(I’ll show you further down this post how I know this 😉)
The ::file-selector-button selector Stefan mentioned targets only the <input type="button" …> you see there. Using it you can style the button, like he did.
🧐 If you’re paying close attention you might notice that the pseudo-element used is ::file-selector-button, whilst the pseudo attribute of the button reads -webkit-file-upload-button. More on that further down the post 😉
~
# How to use DevTools to peek inside <input type="file" />
In the Chromium DevTools we don’t get to see the two elements that make up <input type="file" />. That’s because this information as is hidden in the Shadow DOM.
Thankfully there is a way to have DevTools show them. To do so, open DevTools’ Settings, and under Elements check the option that reads “Show user agent Shadow DOM”.
🦊 Firefox or 🧭 Safari user? The DevTools in Firefox/Safari have this option enabled out of the box.
Once enabled you’ll see #shadow-root (user-agent) appear in the Elements Tree for all elements that are built that way (and there quite a few!).
Winging back to our initial question “is there a pseudo-element we can use to style the play button?”, we can use the DevTools to see the underlying structure.
While the ::-webkit-media-controls-play-button selector above works, there’s a catch though: it only works in Chromium based browsers, and this for several reasons:
Every browser engine has its own implementation for what makes up an <audio> element. Shown below is a comparison of the UI for the <audio> as seen in Firefox, Chromium, and Safari.
Whilst all implementation contain a play button, not all — for example — contain an element that indicates the current time. Styling that wouldn’t be possible.
Not all browser expose the same parts of the UI using pseudo-elements. When it comes to <audio> for example, only Chromium exposes parts of its UI. Firefox and Safari don’t expose any pseudo-element for <audio>
And even if they would, the wouldn’t use ::-webkit-media-controls-play-button for it.
Another aspect to take into account is that ::-webkit-media-controls-play-button is something that Chromium decided to use. This wasn’t discussed with any other browser vendor. As Thomas Steiner warns:
It’s like coding against a private API, though. The internals can change without prior notice. (In practice, things have been quite stable, but worth calling out.)
To close off I still owe you an explanation to why Chromium lists ::-webkit-file-upload-button for the browse button of <input type="file" />, instead of ::file-selector-button.
Instead of resorting to faux underlines using injected content, Michelle Barker shares that we nowadays can animate the text-decoration-* properties to achieve similar (and better) results.
This approach however won’t work in Chromium, as only Firefox/Safari support animating text-underline-offset at the moment … but thankfully a tiny amount of CSS Houdini Magic can be sprinkled on top to make Chromium happy 🤩
Ahmad starts off with explaining the idea behind them, before digging into a ton of use-cases. I especially like the pagination use-case, something I hadn’t thought of yet myself.
~
In his post, Andy taps into a — not yet existent — cw unit, where 1cw equals 1% of the container. This comes in handy for tweaking the font-size based on the available space.
Lea Verou shows a method to implement dark mode, not by swapping entire colors, but by simply changing their lightness
The basic idea is to use custom properties for the lightness of colors instead of the entire color. Then, in dark mode, you override these variables with 100% - lightness. This generally produces light colors for dark colors, medium colors for medium colors, and dark colors for light colors, and still allows you to define colors inline, instead of forcing you to use a variable for every single color.
For best results she also taps into LCH colors.
LCH is a much better color space for this technique, because its lightness actually means something, not just across different lightnesses of the same color, but across different hues and chromas.
Over at CSS { In Real Life }, author Michelle Barker has detailed a clever way to style pseudo-elements (such as ::before and ::after) through JavaScript.
In Javascript we have a few ways of selecting elements, but we can’t directly target pseudo-elements. […] Luckily, CSS custom properties can help.
👉 If you set a custom property on the element that “owns” the pseudo-element the pseudo-element itself can pick it up, thus enabling a way to style it.
The Stacking Contexts Inspector is a DevTools extension for Google Chrome that allows you to analyse the stacking contexts available on a webpage. This extension will add a new panel to the DevTools and a new sidebar on the elements panel.
