Baseline Status in a WordPress Block - Related to baseline, wordpress, goodies, 133, chrome

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 capabilities.", "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 aspects 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 revision 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:

Adam’s such a mad scientist with CSS. He’s been putting together a series of “notebooks” that make it easy for him to demo code. He’s got one for grad......

In January, we experienced three incidents that resulted in degraded performance across GitHub services.

January 09 1:26 UTC (lasting 31 minutes).

In this article, we will explore building a highly scale distributed[1] messaging system like whatsapp.

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.

Ben and Ryan chat with Babak Behzad, senior engineering manager at Verkada, about running a pipeline that vectorizes 25,000 images per second into a c......

In this article, we'll walk through how to provision Amazon Web Services (AWS) Relational Database Service (RDS) instances for both MySQL and PostgreS......

If you’re looking to improve your productivity, there’s a metaphorical ton of apps you can try. For those who prefer using open source software, the s......

Functions in CSS?!

A much-needed disclaimer: You (kinda) can use functions now! I know, it isn’t the most pleasant feeling to finish reading about a new feature just for the author to say “And we’ll hopefully see it in a couple of years”. Luckily, right now you can use an (incomplete) version of CSS functions in Chrome Canary behind an experimental flag, although who knows when we’ll get to use them in a production environment.

I was drinking coffee when I read the news on Chrome prototyping functions in CSS and… I didn’t spit it or anything. I was excited, but thought “functions” in CSS would be just like mixins in Sass — you know, patterns for establishing reusable patterns. That’s cool but is really more or less syntactic sugar for writing less CSS.

But I looked at the example snippet a little more closely and that’s when the coffee nearly came shooting out my mouth.

Arguments?! Return values?! That’s worth spitting my coffee out for! I had to learn more about them, and luckily, the spec is clearly written, which you can find right here. What’s crazier, you can use functions right now in Chrome Canary! So, after reading and playing around, here are my key insights on what you need to know about CSS Functions.

Custom functions allow authors the same power as custom properties, but parameterized.

They are used in the same places you would use a custom property, but functions return different things depending on the argument we pass. The syntax for the most basic function is the @function at-rule, followed by the name of the function as a + ().

@function --dashed-border() { /* ... */ }.

A function without arguments is like a custom property, so meh… To make them functional we can pass arguments inside the parenthesis, also as s.

@function --dashed-border(--color) { /* ... */ }.

We can use the result descriptor to return something based on our argument:

@function --dashed-border(--color) { result: 2px dashed var(--color); } div { border: --dashed-border(blue); /* 2px dashed blue */ }.

We can even use defaults! Just write a colon ( : ) followed by the default value for that argument. @function --dashed-border(--color: red) { result: 2px dashed var(--color); } div { border: --dashed-border(); /* 2px dashed red */ } CodePen Embed Fallback This reminds me of Adam Argyle’s experiment on a functional CSS concept.

Functions can have type-checking for arguments and return values, which will be useful whenever we want to interpolate a value just like we do with variables created with @property , and once we have inline conditionals, to make different calculations depending on the argument type.

To add argument types, we pass a syntax component. That is the type enclosed in angle brackets, where color is and length is , just to name a couple. There are also syntax multipliers like plus ( + ) to accept a space-separated list of that type.

@function --custom-spacing(--a ) { /* ... */ } /* [website] 10px */ @function --custom-background(--b ) { /* ... */ } /* [website] hsl(50%, 30% 50%) */ @function --custom-margin(--c +) { /* ... */ } /* [website] 10px 2rem 20px */.

If instead, we want to define the type of the return value, we can write the returns keyword followed by the syntax component:

@function --progression(--current, --total) returns { result: calc(var(--current) / var(--total) * 100%); }.

Just a little exception for types: if we want to accept more than one type using the syntax combinator (|), we’ll have to enclose the types in a type() wrapper function:

@function --wideness(--d type( | )) { /* ... */ }.

While it doesn’t currently seem to work in Canary, we’ll be able in the future to take lists as arguments by enclosing them inside curly braces. So, this example from the spec passes a list of values like {1px, 7px, 2px} and gets its maximum to perform a sum.

@function --max-plus-x(--list, --x) { result: calc(max(var(--list)) + var(--x)); } div { width: --max-plus-x({ 1px, 7px, 2px }, 3px); /* 10px */ }.

I wonder then, will it be possible to select a specific element from a list? And also define how long should the list should be? Say we want to only accept lists that contain four elements, then select each individually to perform some calculation and return it. Many questions here!

That’s correct, early returns aren’t possible. This isn’t something defined in the spec that hasn’t been prototyped, but something that simply won’t be allowed. So, if we have two returns, one enclosed early behind a @media or @supports at-rule and one outside at the end, the last result will always be returned:

@function --suitable-font-size() { @media (width > 1000px) { result: 20px; } result: 16px; /* This always returns 16px */ }.

We have to change the order of the returns, leaving the conditional result for last. This doesn’t make a lot of sense in other programming languages, where the function ends after returning something, but there is a reason the C in CSS stands for Cascade: this order allows the conditional result to override the last result which is very CSS-y is nature:

@function --suitable-font-size() { result: 16px; @media (width > 1000px) { result: 20px; } }.

Here I wanted everyone to chip in and write about the new things we could make using functions. So the team here at CSS-Tricks put our heads together and thought about some use cases for functions. Some are little helper functions we’ll sprinkle a lot throughout our CSS, while others open new possibilities. Remember, all of these examples should be viewed in Chrome Canary until support expands to other browsers.

Here’s a basic helper function from Geoff that sets fluid type:

@function --fluid-type(--font-min, --font-max) { result: clamp(var(--font-min), 4vw + 1rem, var(--font-max)); } h2 { font-size: --fluid-type(24px, 36px); }.

This one is from Ryan, who is setting the width with an intrinsic container function — notice the default arguments.

@function --intrinsic-container(--inline-margin: 1rem, --max-width: 60ch) { result: min(100% - var(--inline-margin), var(--max-width)); }.

And check out this second helper function from Ryan to create grid layouts: @function --layout-sidebar(--sidebar-width: 10ch) { result: 1fr; @media (width > 640px) { result: fit-content(var(--sidebar-width)) minmax(min(50vw, 30ch), 1fr); } } This is one of those snippets I’m always grabbing from Steph Eckles’ smolcss site, and having a function would be so much easier. Actually, most of the snippets on Steph’s site would be awesome functions. CodePen Embed Fallback.

This one is from moi. When I made that demo using tan(atan2()) to create viewport transitions, I used a helper property called --wideness to get the screen width as a decimal between 0 to 1 . At that moment, I wished for a function form of --wideness . As I described it back then:

You pass a lower and upper bound as pixels, and it will return a 0 to 1 value depending on how wide the screen is. So for example, if the screen is 800px , wideness(400px, 1200px) would return [website] since it’s the middle point.

I thought I would never see it, but now I can make it myself! Using that wideness function, I can move an element through its offset-path as the screen goes from 400px to 800px :

.marker { offset-path: path("M 5 5 m -4, 0 a 4,4 0 1,0 8,0 a 4,4 0 1,0 -8,0"); /* Circular Orbit */ offset-distance: calc(--wideness(400, 800) * 100%); /* moves the element when the screen goes from 400px to 800px */ }.

’s issue on CSS Functions, we are in a super early stage since we cannot:

…use local variables. Although I tried them and they seem to work.

…enhancement a function and let the appropriate styles change,.

…use @function in cascade layers, or in the CSS Object Model (CSSOM),.

in cascade layers, or in the CSS Object Model (CSSOM), …use “the Iverson bracket functions … so any @media queries or similar will need to be made using helper custom properties (on :root or similar).”.

After reading what on earth an Iverson bracket is, I understood that we currently can’t have a return value behind a @media or @support rule. For example, this snippet from the spec shouldn’t work:

@function --suitable-font-size() { result: 16px; @media (width > 1000px) { result: 20px; } }.

Although, upon testing, it seems like it’s supported now. Still, we can use a provisional custom property and return it at the end if it isn’t working for you:

@function --suitable-font-size() { --size: 16px; @media (width > 600px) { --size: 20px; } result: var(--size); }.

What about mixins? Soon, they’ll be here. :

At this time, this specification only defines custom functions, which operate at the level of CSS values. It is expected that it will define “mixins” later, which are functions that operate at the style rule level.

Why Calling [website] is Not Allowed in Java.

Java follows a strict object-oriented approach with a well-defined inheritance model. Unlike ......

Interacting with date pickers in web applications can be challenging due to their different implementations. Some date pickers allow direct text input......

The world of NPM is massive. Over 2 million packages, and yet, most developers end up using the same 20-30 over and over again.