Keeping the page interactive while a View Transition is running - Related to wordpress, running, transition, baseline, 133

Baseline Status in a WordPress Block

You know about Baseline, right? And you may have heard that the Chrome team made a web component for it.

Of course, we could simply drop the HTML component into the page. But I never know where we’re going to use something like this. The Almanac, obs. But I’m sure there are times where embedded it in other pages and posts makes sense.

That’s exactly what WordPress blocks are good for. We can take an already reusable component and make it repeatable when working in the WordPress editor. So that’s what I did! That component you see up there is the web component formatted as a WordPress block. Let’s drop another one in just for kicks.

Pretty neat! I saw that Pawel Grzybek made an equivalent for Hugo. There’s an Astro equivalent, too. Because I’m fairly green with WordPress block development I thought I’d write a bit up on how it’s put together. There are still rough edges that I’d like to smooth out later, but this is a good enough point to share the basic idea.

I used the @wordpress/create-block package to bootstrap and initialize the project. All that means is I cd ‘d into the /wp-content/plugins directory from the command line and ran the install command to plop it all in there.

The command prompts you through the setup process to name the project and all that.

The [website] file is where the plugin is registered. And yes, it’s looks completely the same as it’s been for years, just not in a [website] file like it is for themes. The difference is that the create-block package does some lifting to register the widget so I don’t have to:

The create-block package also did some filling of the blanks in the block-json file based on the onboarding process:

{ "$schema": "[website]", "apiVersion": 2, "name": "css-tricks/baseline-status", "version": "[website]", "title": "Baseline Status", "category": "widgets", "icon": "chart-pie", "description": "Displays current Baseline availability for web platform functions.", "example": {}, "supports": { "html": false }, "textdomain": "baseline-status", "editorScript": "file:./[website]", "editorStyle": "file:./[website]", "style": "file:./[website]", "render": "file:./[website]", "viewScript": "file:./[website]" }.

Going off some tutorials -Tricks, I knew that WordPress blocks render twice — once on the front end and once on the back end — and there’s a file for each one in the src folder:

Handles the front-end view [website] : Handles the back-end view.

Cool. I started with the web component’s markup:

I’d hate to inject that '; } return $tag; } add_filter( 'script_loader_tag', 'csstricks_add_type_attribute', 10, 3 ); // Enqueues the scripts and styles for the back end function csstricks_enqueue_block_editor_assets() { // Enqueues the scripts wp_enqueue_script( 'baseline-status-widget-block', plugins_url( '[website]', __FILE__ ), array( 'wp-blocks', 'wp-element', 'wp-editor' ), false, ); // Enqueues the styles wp_enqueue_style( 'baseline-status-widget-block-editor', plugins_url( '[website]', __FILE__ ), array( 'wp-edit-blocks' ), false, ); } add_action( 'enqueue_block_editor_assets', 'csstricks_enqueue_block_editor_assets' );

The final result bakes the script directly into the plugin so that it adheres to the WordPress Plugin Directory guidelines. If that wasn’t the case, I’d probably keep the hosted script intact because I’m completely uninterested in maintaining it. Oh, and that csstricks_add_type_attribute() function is to help import the file as an ES module. There’s a wp_enqueue_script_module() action available to hook into that should handle that, but I couldn’t get it to do the trick.

With that in hand, I can put the component’s markup into a template. The [website] file is where all the front-end goodness resides, so that’s where I dropped the markup:

That get_block_wrapper_attibutes() thing is recommended by the WordPress docs as a way to output all of a block’s information for debugging things, such as which capabilities it ought to support.

[FEATURE] is a placeholder that will eventually tell the component which web platform to render information about. We may as well work on that now. I can register attributes for the component in [website] :

"attributes": { "showBaselineStatus": { "featureID": { "type": "string" } },.

Now we can improvement the markup in [website] to echo the featureID when it’s been established.

There will be more edits to that markup a little later. But first, I need to put the markup in the [website] file so that the component renders in the WordPress editor when adding it to the page.

useBlockProps is the JavaScript equivalent of get_block_wrapper_attibutes() and can be good for debugging on the back end.

At this point, the block is fully rendered on the page when dropped in! The problems are:

It’s not passing in the feature I want to display.

I’ll work on the latter first. That way, I can simply plug the right variable in there once everything’s been hooked up.

One of the nicer aspects of WordPress DX is that we have direct access to the same controls that WordPress uses for its own blocks. We import them and extend them where needed.

I started by importing the stuff in [website] :

import { InspectorControls, useBlockProps } from '@wordpress/block-editor'; import { PanelBody, TextControl } from '@wordpress/components'; import './[website]';

InspectorControls are good for debugging.

are good for debugging. useBlockProps are what can be debugged.

are what can be debugged. PanelBody is the main wrapper for the block settings.

is the main wrapper for the block settings. TextControl is the field I want to pass into the markup where [FEATURE] currently is.

is the field I want to pass into the markup where currently is. [website] provides styles for the controls.

Before I get to the controls, there’s an Edit function needed to use as a wrapper for all the work:

export default function Edit( { attributes, setAttributes } ) { // Controls }.

First is InspectorTools and the PanelBody :

export default function Edit( { attributes, setAttributes } ) { // React components need a parent element <> // Controls }.

Then it’s time for the actual text input control. I really had to lean on this introductory tutorial on block development for the following code, notably this section.

export default function Edit( { attributes, setAttributes } ) { <> // Controls setAttributes( { featureID: value } ) } /> }.

Oh yeah! Can’t forget to define the featureID variable because that’s what populates in the component’s markup. Back in [website] :

In short: The feature’s ID is what constitutes the block’s attributes. Now I need to register that attribute so the block recognizes it. Back in [website] in a new section:

"attributes": { "featureID": { "type": "string" } },.

Pretty straightforward, I think. Just a single text field that’s a string. It’s at this time that I can finally wire it up to the front-end markup in [website] :

I struggled with this more than I care to admit. I’ve dabbled with styling the Shadow DOM but only academically, so to speak. This is the first time I’ve attempted to style a web component with Shadow DOM parts on something being used in production.

If you’re new to Shadow DOM, the basic idea is that it prevents styles and scripts from “leaking” in or out of the component. This is a big selling point of web components because it’s so darn easy to drop them into any project and have them “just” work.

But how do you style a third-party web component? It depends on how the developer sets things up because there are ways to allow styles to “pierce” through the Shadow DOM. Ollie Williams wrote “Styling in the Shadow DOM With CSS Shadow Parts” for us a while back and it was super helpful in pointing me in the right direction. Chris has one, too.

First off, I knew I could select the element directly without any classes, IDs, or other attributes:

I peeked at the script’s source code to see what I was working with. I had a few light styles I could use right away on the type selector:

baseline-status { background: #000; border: solid 5px #f8a100; border-radius: 8px; color: #fff; display: block; margin-block-end: [website]; padding: .5em; }.

I noticed a CSS color variable in the source code that I could use in place of hard-coded values, so I redefined them and set them where needed:

baseline-status { --color-text: #fff; --color-outline: var(--orange); border: solid 5px var(--color-outline); border-radius: 8px; color: var(--color-text); display: block; margin-block-end: var(--gap); padding: calc(var(--gap) / 4); }.

Now for a tricky part. The component’s markup looks close to this in the DOM when fully rendered:

Anchor positioning Limited availability This feature is not Baseline because it does not work in some of the most widely-used [website] more.

This feature is not Baseline because it does not work in some of the most widely-used browsers.

I wanted to play with the idea of hiding the element in some contexts but thought twice about it because not displaying the title only really works for Almanac content when you’re on the page for the same feature as what’s rendered in the component. Any other context and the heading is a “need” for providing context as far as what feature we’re looking at. Maybe that can be a future enhancement where the heading can be toggled on and off.

This is freely available in the WordPress Plugin Directory as of today! This is my very first plugin I’ve submitted to WordPress on my own behalf, so this is really exciting for me!

This is far from fully baked but definitely gets the job done for now. In the future it’d be nice if this thing could do a few more things:

This week we did a revision of the previous class, talking about why web and cloud, HTML, CSS, JavaScript and so on… You can go through the previous c......

GitHub in recent times presented the public preview of Linux arm64 hosted runners for GitHub Actions. Free for public repositories, this modification provides deve......

In modern application development, the need for real-time data processing and reactive programming has become increasingly key. Reactive program......

Chrome 133 Goodies

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 attributes. 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.

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::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(), #fff) }.

This is a trite example, of course. But it helps illustrate that there are three moving pieces here:

the attribute ( data-color ) the type ( type() ) the fallback value ( #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:

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:

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 element and usually stuff it with an unordered list of links. So, our can be the container we query since we’re effectively sticking an unordered list to the top of the page.

We can put the sticky logic directly on the 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:

And we tell it the state we’re looking for:

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 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: [website]; } } }.

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.

Concurrency has always been a cornerstone of modern software development, enabling applications to handle multiple tasks simultaneously. In Java, trad......

Shell scripting is a powerful tool for automation, system administration, and software deployment. However, as your shell scripts grow in size and com......

Ubuntu est supporté par le sous-système Linux de Windows, ou WSL. Pour aller plus loin, Ubuntu annonce le support d'un nouveau modèle de distribution ......

Keeping the page interactive while a 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:

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.

When I began my journey into the field of AI and large language models (LLMs), my initial aim was to experiment with various models and learn about th......

Look Closer, Inspiration Lies Everywhere (February 2025 Wallpapers Edition).