DEV Community: Alvaro Montoro

10 Cool CodePen Demos (August 2026)

Alvaro Montoro — Mon, 21 Sep 2026 14:19:26 +0000

sibling-index staggered animations

sibling-count() and sibling-index() got support on Firefox this month of August, and Josh Collinsworth used them to create this animation in which squares rotate and turn into circles (and vice versa). Something that would have required highly specific CSS rules can now be achieved with 40 lines of code. Nice.

Wave header

Ana Tudor used the shape() function to create wavy patterns in the header and its pseudo-elements, which combined with different colors and the header content positioning creates a beautiful experience. Also, the code for the shape has many comments making this a great demo for learning about that function.

Analog Email Alert

As part of a CodePen Challenge, Zerde Turdybek created this interactive animation with ThreeJS. Move the mouse around to see the letter follow the pointer, then click on the mailbox to drop the letter, and the mailbox will animate. I really like how the demo and the shadow details.

Elastic macOS Traffic Lights

Bálint Ferenczy reimagines the MacOS window buttons and crafts a new interactive version using vanilla HTML, CSS, and JavaScript. Play around with them: move mouse over, click, pull them (yes, pull them). The micro-interactions it has are really smooth. I enjoyed the bounce effects.

Div Shuffling

If you've worked drawing with CSS and doing 3D with CSS, you know how difficult it is to simulate a curved shape without looking weird or fake. But this demo with cards shuffling does exactly that and in such a easy-looking way (just using a ton of divs). Of course, it had to be Amit Sheen, who does magic with 3D CSS, who did it. Amazing!

Banana - Peel Study

An interesting infinite cycle with the word "banana" getting carved and uncarved from a three-dimensional banana. Scan, carve, dissolve, loop. Daniel Muñoz is the author of this original (and a little bit weird) animation with ThreeJS and GreenSock.

Plant Shop - a 3D game about growing and selling plants

I had fun playing this game by Joshua van Boxtel, although I must admit that I didn't go beyond level 2 (and a half). Grow your greenhouse and your business by taking care of the plants and buying newer/better seeds at the market. The 3D is impressive, I wish the transitions were a bit smoother (having to reset the camera each time, ouch!)

Evil Eye

I haven't seen many Lord of the Rings demos lately, so this one by Andry Zirka caught my attention. The tower is a WebP image, but the fiery eye that follows the mouse is coding into a canvas. Really impressive result. Time to so stop messing around and get back to work... but first, two more demos.

Your Package Could Not Be Delivered

Vanessa Victorino coded the template for this "deceptive" demo. It is a realistic-looking Amazon email that tries to trick the viewer to perform an action. The main elements of phishing are present and a short description of them pops up (when you fail and end up clicking what you shouldn't).

Creative login robot

Itay haephrati coded this robot-login form that interacts with the user as they enter the information. I like this type of high micro-interactions demos that are practical enough to be put on a website even if they are a big goofy. This is fun and friendly.

La Liga's Web Accessibility Table: How Do Clubs Actually Score?

Alvaro Montoro — Sun, 06 Sep 2026 20:13:44 +0000

I should start by saying that I'm not a web accessibility expert. I work in web development and deal with accessibility features regularly, but I've never had formal training in the field.

To practice and learn, I ran a series of accessibility audits, and at the same time explored whether there's any correlation between digital quality and success on the soccer field (though I presumed superior finances would drive both). And honestly, analyzing the web standards of top‑level clubs just sounded like a fun challenge.

All of this is to say: take this article with a grain of salt. It's one person running tests, with the level of scientific rigor you'd expect from that. And yes, just like AI, I can make mistakes.

Each team has a card like the one shown below, providing the core results at a glance. The surrounding text includes commentary and a short summary of what the card reveals.

All numbers are rounded to keep things readable.

I started with automated tools (the criteria and process are described at the end of the article), but those results felt incomplete. So I added a more "human" layer by manually testing and scoring accessibility features. These may not be the criteria everyone uses, but they're the ones I followed. If you prefer different ones, I encourage you to run your own tests and write about them. I'd genuinely love to read it.

Here are the results…

Alavés

If I recall correctly, this was the only home page with a form in it (not counting the search box), and that introduced some new issues that took points from them. Automated accessibility tests gave a high score (e.g., all images had alt attribute) but manual test proved things were not what they seemed (e.g., all images had alt attribute with "null" as value). Using the screenreader there were a lot of "link, image, null" messages.

Site: https://deportivoalaves.com/es/

Athletic

Athletic's site relies heavily on images that contain text (many of them with alt=""), including several inside links that have no other content. Combine that with long, non‑skippable sections that seem to go on forever, plus a menu that remains reachable even when hidden, and the accessibility score takes a predictable hit. On the positive side, the site handles zoom surprisingly well.

Site: https://www.athletic-club.eus/

Atlético

The language menu on Atlético's site is confusing when using a keyboard. You can open it normally, but then you're forced to tab through the entire main menu before reaching the popup with alternative languages (this happened with several teams). It's not a feature people use often, but the one time you need it, the experience shouldn't be disorienting. The site follows the reduced‑motion setting strictly, which is rare: if reduced motion is enabled, all animations and transitions stop completely.

Site: https://www.atleticodemadrid.com/

Barcelona

Overall, Barcelona's site performed reasonably well compared to the rest of La Liga… but given the club's history, resources, and global reach, the results feel underwhelming. Especially considering the types of issues that surfaced: a poor heading hierarchy, a sticky header that consumes half the screen when zoomed, and focus indicators that clip or jump to hidden elements creating confusion.

Site: https://www.fcbarcelona.es/es/

Betis

Betis' homepage presents several accessibility challenges: carousels that animate and slide even with reduced‑motion enabled, menus that open but can't be reached until you tab through a sea of unrelated items, and a noticeable amount of text with low contrast against its background. In their defense, green is a notoriously tricky color when it comes to contrast… but still. I expected more from a team like Betis.

Site: https://www.realbetisbalompie.es/

Celta

I liked the grid in the header of Celta's website, and the page performed decently in automated tests. But manual testing quickly brought the score down: no level‑1 heading, and only a single level‑2 heading (buried at the bottom in the merchandise store)? The page is in Spanish, yet somehow the button labels appear in English (the risks of copy‑paste)? And videos in the video carousel that aren't reachable via keyboard navigation?

Site: https://rccelta.es/

Deportivo

The 95 in structure can be misleading. The site earned it thanks to strong automated test results and only three HTML errors. Unfortunately, structure is the metric with the least weight, and the manual tests (which carry the most weight) yielded the lowest score of any team. Issues included faint or missing outlines, images with alt attributes equal to the file name (ouch!), or components that only worked with a mouse. And that's just to name a few; the list goes on.

Site: https://www.rcdeportivo.es/es

Elche

Elche's landing page is so minimal that it earns points almost by default because many of the tested metrics simply don't apply (note to self: revise grading criteria for next year). There are some nice touches: gradients used to boost contrast, and a carousel that respects reduced‑motion settings (the same widget many other teams use). But there are also questionable choices; most notably, the page doesn't contain a single heading!

Site: https://www.elchecf.es/

Espanyol

Espanyol was the only team to score below 50 overall (a failing grade in Spain). From missing outlines to menus accessible only by mouse, to images without alt attributes and a broken navigation that traps the keyboard, the site struggled across the board. It failed every automated test except Lighthouse… which brought the scores up!

Site: https://www.rcdespanyol.com/es/

Getafe

There are a few teams that use the same white‑labeled web template, customized only with club colors. Out of the box, it delivers solid SEO results and decent accessibility. But it also serves as a reminder that content and authoring choices can break even the most accessible template. Getafe seems to be one of the clubs using it, and fortunately, they handled their content reasonably well apart from some things: no proper headings (none at all, to be precise) and a handful of related screen‑reader issues… but little beyond that.

Site: https://www.getafecf.com/

Levante

Levante's landing page is a good example of how my scoring criteria can favor simpler pages with limited content. With little text, few images, and only a handful of widgets and components, the site is easy to use largely because of its simplicity. Still, there's room for improvement: making proper use of HTML landmarks and hierarchical elements (the page has only a single heading!) and ensuring that outlines don't break would improve accessibility.

Site: https://www.levanteud.com/

Málaga

Another example of a template that could be far more accessible if the content followed suit… but it doesn't. The homepage suffers from missing headings, clipped outlines, and poor image labeling. Still, Malage homepage's simplicity and low volume of content worked in its favor during scoring, landing the site in a respectable second place

Site: https://www.malagacf.com/

Osasuna

The disappearance of outlines across most elements on Osasuna's site dealt a major blow in manual testing. And that wasn't the only issue: carousels autoplay without pause or focus control, ignore reduced‑motion settings, and oddly mix Spanish content with English controls. These problems compounded to drag the score down. Overall, Osasuna's homepage has significant room for improvement, placing the team in the lower half of the accessibility rankings.

Site: https://www.osasuna.es/es

Racing

Racing de Santander's homepage earned the highest score in manual testing, despite getting average or below‑average results in automated checks. "It's not easy being green" proved true here: the club's colors didn't help with contrast, and issues like missing headings, questionable alternative text values, and animated micro‑interactions that ignored reduced‑motion settings all dragged the score down. Yet, the site's simple structure and limited content balanced things out.

Site: https://www.realracingclub.es/

Rayo Vallecano

These results weren't terrible (compared to other teams), but given the club's history and background, I expected more. Accessibility testing showed solid scores in both manual and automated checks, and SEO management was strong. The weaknesses came from structural issues: too many HTML errors, no headings, and most images with empty alt attributes (many of them decorative, though). As with other template‑based sites, many of these shortcomings are content‑related and could be fixed with closer attention to detail.

Site: https://www.rayovallecano.es/

Real Madrid

The low score in structure came from numerous invalid HTML errors (a metric weighted heavily in that category.) Beyond that, the results were strong: only minor focus issues with inconsistent or missing outlines, tabbing sequences that didn't match the visual order, and minimal overlapping when zooming in. Despite having one of the most content-heavy homepages, Real Madrid's accessibility scores outperformed those of clubs with simpler sites. While there's still room to grow, that is commendable.

Site: https://www.realmadrid.com/es-ES

Real Sociedad

Real Sociedad's score could have been higher (up to 60), but a grading decision brought it down: the site blocks automated requests, so a couple of my tests couldn't run and therefore couldn't get points for them. To keep things consistent, I used the lowest score recorded by any team in both blocked metrics.

Visually, the site looks polished and neat, but digging deeper, many problems arise. The tabbing experience was problematic to the point of being partly unusable: outlines disappearing or clipped, inconsistent focus styles for similar elements, and components breaking when tabbing through them (looking at you, carousel). Add to that animations and transitions running even with reduced‑motion enabled, or the use of <div> elements as buttons, and the score speaks for itself.

Site: https://www.realsociedad.eus/es

Sevilla

Sevilla FC's site stood out for its handling of modals and panels (e.g., the Esc key actually closed them, and the focus looped in them avoiding wandering around.) The font choice is artistic and full of character, but readability suffers, and text can feel confusing at times. Still, Sevilla earns an honorable 5th place overall.

Site: https://sevillafc.es/

Valencia

Valencia's website has far more content than most teams, and while that doesn't automatically mean more issues, it does create more opportunities for error… which is exactly what happened here. But not always! Some of the issues were independent of content: not a single element showed an outline when focused, tab order didn't match the visual order, and headings were used for styling rather than defining the document hierarchy. Also, carousels and components animate and autoplay even when reduced‑motion settings are enabled. The result is a messy homepage that needs some major updates.

Site: https://www.valenciacf.com/

Villarreal

Villarreal achieved some of the best overall results, finishing in third place(just hundredths of a point behind the second team.) Valid HTML, excellent performance scores, and solid manual test results helped offset weaker outcomes in automated accessibility checks. Still, issues with color contrast, empty buttons, and inconsistent focus and outline strategies held the site back. Addressing these areas could lift Villarreal into the first place.

Site: https://villarrealcf.es/es/

And the winner is…

As an Atlético de Madrid supporter, it pains me to admit that the winner is Real Madrid. They ousted Málaga and Villarreal by just 1.1 points each.

Although Real Madrid came out on top and remains a serious contender for the title, I didn't find any meaningful correlation between web accessibility scores and on‑field performance. That would have been surprising anyway (about as logical as claiming that the decline of pirates causes global warming.)

One detail did catch my attention: the top four teams from the previous season all ranked within the top seven for SEO. Coincidence, or a hint that digital visibility matters more than we think? (At least, to bring fans and money with them, that can be used to sign better players?)

Overall, the results weren't terrible, but La Liga teams still have plenty of room to grow in the web accessibility department. Many of the issues were straightforward to detect and, more importantly, relatively easy to fix. So, what happened?

As a final thought, web accessibility may not decide championships, but it does decide who gets to join the game and enjoy the teams. Build accessible websites, everyone!

Grading and Weighting Criteria

This study evaluates the web accessibility of La Liga's first‑division soccer teams, focusing exclusively on the homepage, on desktop, and in Spanish‑language versions.

To generate metrics, I used a mix of automated, semi‑automated, and manual tools:

WebAIM Wave (extension): accessibility feedback and scoring.
Lighthouse (in‑browser): accessibility, performance, usability, SEO, and structure data.
GTMetrix: performance and structure analysis, combining Lighthouse with proprietary scoring.
Accessibility Insights for Web (extension): manual accessibility testing guidance.
Axe DevTools (extension): manual accessibility testing guidance.
VoiceOver: screen reader evaluation.
W3C HTML Validator: HTML error counts.

All tests were performed in Chromium on a Mac, except for VoiceOver, for which I used Safari as the browser.

Scoring Framework

The evaluation was divided into four weighted categories:

Manual accessibility testing: 50%
Automated accessibility testing: 25%
Performance testing: 15%
Structure & SEO testing: 10%

Performance impacts usability and accessibility, while proper structure and best practices boost accessibility by default. That's why these categories are included, even at lower weights.

I initially weighted the categories as 35–30–20–15, but later adjusted to 50–25–15–10 to prioritize accessibility testing (especially manual checks) in order to emphasize the "human side" of the user experience. This update in weights changed the ranking, but not by much.

The following sections explain how each category was scored.

Manual Accessibility Testing (50%)

My initial weight for manual accessibility testing was 35%, so I created 35 distinct metrics: 1 metric, 1 point. Later, I adjusted the weighting (after testing the sites), but I kept the 35 metrics and simply pro‑rated them.

Within this category, I tested seven different groups. Each site began with 35 points, and for every issue identified on the page, I deducted one point (only once per issue). There were a few exceptions to this rule, which I'll explain later.

Outline/Focus (5 points)

Missing (some): -1
Inconsistent Outline: -1
Clipped: -1
Outline overlaps text/content: -1
Hidden elements get focus: -1

If outlines are missing across all elements (or for a considerable number of them), this section automatically receives a score of 0.

Tabbing (5 points)

Not in order: -1
CTAs not tababble: -2
Cannot exit modal/dialog: -2

This is the only section in which a metric has a value larger than 1.

Typography (5 points)

Low line height/Text lines too close: -1
Wide paragraphs: -1
Difficult to identify links/CTAs: -1
Justified text/Wall of text: -1
Use headings for styling: -1

Color (5 points)

Low contrast on image (text or CTAs): -1
Low contrast on video (text or CTAs): -1
Use colors for status: -1
Missing visual label in form: -1
Missing high contrast: -1

I defined the metrics before starting the tests. I had in mind high‑contrast mode as implemented in Windows, but I couldn't replicate it on Mac. As a result, this metric became a free point for each team, ensuring that no site ended up with a score of zero.

Low motion (5 points)

Video autoplay: -1
Auto carousel: -1
Parallax effect: -1
Micro-interactions movement: -1
Marquee/Ticker: -1

Zoom at 200% (5 points)

Horizontal scroll: -1
Elements overlap: -1
Unreadable text (no change): -1
Clipped/broken menus: -1
Sticky header/footer fill most of the screen: -1

Screen reader (5 points)

Live regions not updating: -1
Read more button/links (or similar): -1
Landmark navigation: -1
Update/error announcement: -1
Proper alts/labels: -1

Automated Accessibility Testing (25%)

For automated accessibility testing, I used two tools: WebAIM Wave and the Lighthouse A11Y results. Wave scores accessibility on a scale of 0–10, while Lighthouse uses a scale of 0–100. To normalize the results, I multiplied Wave scores by 10 and then averaged them with Lighthouse scores, giving each tool an equal 50% weight in the calculation.

Performance Testing (15%)

For performance evaluation, I used two tools: GTMetrix and the Lighthouse Performance results. I averaged both scores, giving each tool an equal 50% weight.

GTMetrix results tended to be lower than Lighthouse's, largely because GTMetrix loaded the page fresh each time, while Lighthouse (running in‑browser) preserved my cookie settings, language selection, and other modes. In practice, GTMetrix measured a first‑load experience, while Lighthouse reflected a page already loaded with user context.

Structure & SEO Testing (10%)

For this category, I combined several elements and weighted them differently. On one side, I averaged the GTMetrix structure score, Lighthouse best practices, and Lighthouse SEO results. Together, these accounted for 50% of the category.

The remaining 50% came from the W3C HTML Validator, worth 5 points in total, awarded as follows:

0-5 errors: 5 points
6-10 errors: 4 points
11-20 errors: 3 points
21-30 errors: 2 points
31-50 errors: 1 point
50 or more errors: 0 points

Perhaps the weight for valid HTML was too high, but many accessibility and usability features depend on proper markup. For that reason, I chose to emphasize it.

I liked combining different tools to avoid relying on a single source of truth. In some cases, this approach backfired: certain teams blocked specific tools, or sites were tested with a fresh reload each time, producing lower scores and a worse user experience. Still, I think that ultimately helped balance the results.

To be honest, I expect to hear criticism of my method and the metrics I tested, and that's a good thing. I will learn better methods and metrics, adopt better practices, and improve the grading and weighting criteria for next year.

The 4 Hs of HTML

Alvaro Montoro — Wed, 26 Aug 2026 02:05:52 +0000

There are a few web concepts that appear in every webpage, and they are a recurring source of confusion among designers and developers. Maybe it is because their names are really similar, maybe it is because some have overlapping roles... but they are always causing trouble.

I am talking about the 4 Hs of HTML: Head, Header, Heading, and Headline. Sometimes these names are used interchangeably, but nothing could be further from the truth. Each of them is its own thing and needs to be treated and called appropriately.

It may seem trivial, but clarity is important because semantics, maintainability, and accessibility depend on it... and having a clear definition for them facilitates communication and helps people understand each other faster (and move projects forward just as quickly.)

So, what are the 4 Hs of HTML?

Head: The Document's Brain

The head of a document is the <head> element. It contains machine-readable information about the document itself (metadata) and, because it is designed for machines and not humans, it is not part of the layout and it is not visible on the browser.

A common misunderstanding happens when designers and developers talk about the head of the document to refer to the header of the page or the hero section above the fold. That's not what the head is.

Among other things, the head contains information like:

The page title in the <title> tag.
Links to scripts and style files.
Meta tags with browser instructions and directions.
Social media and SEO tags for web crawlers.

Although some of that information may be visible to the user (the title is displayed on the tab name, or a social media image is shown on posts), generally the data in the <head> is invisible to the site's visitors.

Header: Introductions and Banners

The header of a page is an introduction section usually located at the top that contains things like the title, a short description, navigation, a hero banner, or a search box. It can be represented by the <header> semantic HTML element, and it is very much visible.

While normally every page has a "main header," there can be multiple headers on a page: an <article> may have a header, so may a <section> or the <main> content of the page, as well as an <aside>. So a single page may have several headers, or none at all.

Maybe because designers don't usually deal with the <head> code, or because "head" is a shorter way of saying "header" (and after all, it usually sits on top of the page, but not always), they often use the terms interchangeably. That can be a bit confusing for developers.

Heading: The Content Hierarchy

In essence, a heading is the title of the page or a section. The <h1>-<h6> family of HTML elements represent headings.

They are sometimes called headers, other times called headlines... and they are neither! A header may contain a heading, but doesn't have to (see the feed header in the picture above); And headlines may use a heading, but they are not defined by it, they tend to have other elements too (more about this on the next section).

We use headings to define the outline of the content, providing hierarchy both for humans (text is larger and more identifiable) and machines (labeling each section for better accessibility and SEO results.)

One important thing: use headings for structure, not for layout. Do not use a <h1>-<h6> tag to make text look bigger or bolder. By doing that, we break the hierarchy of the page and it can be really confusing for assistive technology users.

Headline: Editorial Content

Usually, the headline is the big eye-catching text that introduces the page or section... just like on a newspaper! A headline is not an HTML concept, it is an editorial one; but developers often try to interpret it as a header or even just a heading.

And that is where confusion starts: a headline is for message delivery while headers and headings are for structure and hierarchy, respectively. Yes, headlines may contain headings, but they are not defined by the headings. There's more to them: titles, subtitles, calls to action...

There isn't a direct semantic HTML equivalent to a headline. The closest thing would be the <hgroup> element, but it has gone through many semantic changes over time and would only represent a really basic version of a headline (with a heading and a paragraph)

Some designers use "headline" as shorthand for "the big text at the top," even when it's a UI component instead of editorial content. Those cases are more of a combination of a heading and multiple buttons, which in my opinion would follow more into the header category... but I'm just a developer.

Conclusion

And that's it! Those are the 4 Hs of HTML: Head, Header, Heading, and Headline, and what each of them represents.

Here's a quick summary table with all of them:

As you may have noticed, their names are really close, and their functionality, while different, intertwines. They often go together or are combined in some manner.

But it is really important to understand their differences and have clear naming conventions to avoid miscommunications (and extra work) between the design and the development teams.

How about you? Have you ever "argued" or run into miscommunications with a designer or a developer who called a head a header?

comiCSS #255: Yellow

Alvaro Montoro — Mon, 24 Aug 2026 23:10:34 +0000

comiCSS is a side project I've been running for a while. I code (yes, code) comics about HTML and CSS in HTML and CSS. Every week, I publish a new cartoon (or at least I try).

This week's cartoon was inspired by a Jim Benton's cartoon from 20 years ago. It is goofy, it is absurd, but it is funny... or at least I found it funny enough to make a CSS-themed version (actually, two!)

The original hand-drawn version has more character, but I am also fond of like the childish kawaii version I did... even when it doesn't fully make sense in CSS (the yellows are actually the values indicated by the bottles, but #pee isn't a color, and making it #fee wouldn't be obvious as a joke).

I did a second version that I'm putting on the website as alternative. It is more CSS-oriented:

This version came second, but I like it more than the first one. Still goofy and a bit of a potty joke, but not as childish as the other one. And it uses more modern CSS too. So that’s nice.

What do you think? Do you like any of the two versions?

RGB is dead, long live RGB!

Alvaro Montoro — Fri, 21 Aug 2026 18:05:59 +0000

Wait a second! The original sentence is "The king is dead, long live the king!" But in that case, the first king is not the same as the second king. So wouldn't it be better to say something like:

RGB is dead, long live OKLCH!

That's much better. It is clearer that RGB –and the "RGB-based" colors like HEX and even HSL– are no longer the things to use in CSS. There's a new sheriff in town, that's OKLCH, and it's the color format that should be used moving forward.

Except... is that really the case?

OKLCH has many positive features that make it an ideal candidate:

It supports more colors: 50% more displayable colors than standard RGB! And that's a lot.
It handles the lightness in a more consistent way than RGB: two colors with the same L value will have a similar perceived darkness/lightness.
It is more human-readable: definitely true for lightness (refer to previous point), but debatable for hue and chroma.
It is more focused in human perception than in the machine: the way it represents colors is closer to how the human eye perceives them.
More natural transformations between colors: no more unexpected jumps in colors or gray in-betweens.

In summary, OKLCH is amazing. More available colors, better perception, better transformations... It beats RGB in almost any aspect that we compare the two. But does that mean you should ditch RGB and update all your projects into OKLCH?

Well... the answer is "it depends." RGB is not being removed from the standard and will always work in CSS. OKLCH provides brighter and more vibrant colors, but not all designs will require them.

But it also comes with some baggage:

It is widely supported... except by not-so-old browsers: this problem will die down with old browsers but, at this moment, around 7% of the browsers online don't support OKLCH. It is small number, but big enough to consider fallbacks.
It requires heavier calculations than RGB: color spaces like LCH have been around for decades, but they weren't implemented on the web earlier due to hardware limitations. OKLCH was created in late 2020 to solve some of those limitations and rendering issues, but still requires more computation than other color spaces.

The support is changing rapidly as browsers get deprecated, and the heavier computational cost is not a big deal as modern browsers are optimizing this instantly, so it is a low price to pay.

And you may be using OKLCH without knowing! Some browsers use OKLCH to interpolate transition colors because, as mentioned above, the transition between colors is more natural. So, it doesn't matter if you use OKLCH, RGB, Lab, HEX, or HSL... behind the scenes, they'll be converted to OKLCH for color transitions.

In summary, OKLCH is a superior format in many aspects and should be the favorite choice moving forward, especially if you want to get vibrant colors, precise control, and more natural gradient interpolations.

But don't feel obligated to drop the color format that you love to jump into OKLCH! RGB (and all the other color formats in CSS) are here to stay. As with all things in web development, use the tool that you need. And in some cases, OKLCH may not be needed.

I plan to still use RGB and hex in many of my sites to define font or background colors. They may seem old and rusty, but that's just #FFA500 for you! And it just works nicely.

Fancy Clipping with CSS

Alvaro Montoro — Mon, 17 Aug 2026 05:03:03 +0000

I have been using clip-path for ages, especially for CSS Art, but I was today years old when I learned some of the features that are available for the polygon() function in clip-path.

The other day, Temani Afif shared a demo that included some weird (to me) syntax for the polygon() function that allowed creating rounded shapes. It included the keyword round and a length. Something like this:

clip-path: polygon(round 10px, 100% 55%, 0 71%, 71% 0, 55% 100%, 10% 10%);

I have always used polygon() specifying a series of points that were used to clip the element that ended with really sharp edges. So, the first thing I thought was "This must be some Chrome-only experiment or something." And I was partially correct. Yes, it only works on Chrome at the moment, but the rounded behavior is defined in the CSS specification.

If you have code that specifies roundness in the polygon, for example:

div {
  width: 300px;
  height: 300px;
  background: red;
  clip-path: polygon(round 10px, 100% 55%, 0 71%, 71% 0, 55% 100%, 10% 10%);
}

You will get a rounded figure with clip-path. For the code above, it would be this (only on Chrome):

A rounded star in Chrome using clip-path :)

I have to admit, for me this was a mind-blown type of moment. Getting rounded edges before this required masking with SVG, or coming up with relatively complex native CSS, including masks and gradients. (Although thee the shape() function makes this considerably easier now.)

This feature is amazing, especially for the CSS Art that I like coding, but there's a big issue.

Support and Progressive Enhancement

As I have mentioned a few times before, this rounded feature is in the specs but at the moment it is only supported by Chrome. So... what happens when it runs on other browsers like Firefox or Safari?

Unfortunately, the answer is not good: the function is considered invalid and it is completely ignored. Which means that not only do we not get a rounded polygon, we don't get a polygon at all!

The same rounded star on Safari and Firefox :(

In the future we could use the CSS @if and @function at rules to have a rounded-polygon() function that would do this for us, but for now we need to find an alternative to progressively enhance the feature or gracefully degrade if it is not supported.

But there is something that we can currently do: use the @supports at-rule combined with custom properties.

:root {
  --round-clip:;

  @supports (clip-path: polygon(round 1px, 0 0, 0 0)) {
    --round-clip: round 10px,; /* notice the comma! */
  }
}

div {
  ...
  clip-path: polygon(var(--round-clip) 100% 55%, 0 71%, 71% 0, 55% 100%, 10% 10%);
}

Now, by default the variable will be empty, so we will get the "classic" clip-path with pointy edges. But, if rounded clipping is supported, the custom property will have a value that makes the clip-path have rounded edges:

Pointy star by default (left), and rounded star if supported (right) :D

I will not get into the weeds of how the roundness is calculated, but the CSS specification has a section with an explanation and many details on that.

But wait... there's more!

While the rounded paths are not supported by all browsers, there is another feature that I didn't know about and it is actually widely supported, even by Safari and Firefox: fill rules.

When you define a clip-path, all the area inside the path will be selected and visible, but developers can specify different keywords to have some control over that:

nonzero (default): the points inside the path will not be clipped.
evenodd: everything outside the path will be clipped, but within the path, it will depend on the count of lines and path edges around each point. If it's even, it will be clipped; if it's odd, it won't and it will be visible.

This is an oversimplification. The SVG specification has a more detailed explanation of how both keywords work, and I encourage you to read it.

Here's the example of the star from before using nonzero (default, could be omitted) and evenodd fill rules:

.div1 {
  ...
  clip-path: polygon(nonzero, 100% 55%, 0 71%, 71% 0, 55% 100%, 10% 10%);
}

.div2 {
  ...
  clip-path: polygon(evenodd, 100% 55%, 0 71%, 71% 0, 55% 100%, 10% 10%);
}

nonzero clipping (left) vs evenodd clipping (right)

The nonzero and evenodd fill rules would go before the round keyword if we are applying rounded clip paths. No comma separating the two. For example:

div {
  ...
  clip-path: polygon(nonzero round 10px, 100% 55%, 0 71%, 71% 0);
}

The fill-rules syntax not only works for polygon(). It also works with shape() and path(), so it's nice to get acquainted with it.

One of the fascinating things about CSS is how complete (and sometimes complex) it can be. You think you know about it and, boom! There's something different, and not necessarily new that you learn about it... even when you have used it continuously. You have to love that.

Here's an interactive demo that lets you play with the values described above: roundness, fill rules, and fallbacks (will only make a difference on Safari and Firefox). Tweak the controls and see how the star changes.

Don't Use A Class For That!

Alvaro Montoro — Fri, 07 Aug 2026 15:08:14 +0000

Developers love classes. They sprinkle them everywhere: .hidden, .loading, .active... But HTML already gives us attributes that do the job better. Attributes that are semantic, standardized, and supported across browsers. So, why reinvent the wheel? Let the browser handle the heavy lifting, and improve SEO and accessibility in the process.

Instead of adding more and more custom classes, embrace the platform and its versatility: use native attributes. Some times they may seem a little more verbose, but that's not always the case and the benefits justify it.

Here are some common native HTML attributes that can be used instead of classes.

[hidden]

Why defining a .hidden class (globally or per component), when you can just use the hidden attribute? It's built into HTML, supported across browsers, and doesn't need extra CSS. The browser knows exactly what you mean.

In some scenarios, you may need to redefine what [hidden] will do in CSS, but even on those cases, using the native attribute is more semantic and provides additional context than a custom class.

[required]

Form validation is the perfect ground for over-engineering. It is tempting to add a .required class in a label or input; instead, rely on the required attribute. The browser enforces it, screen readers announce it, and you don't need JavaScript to validate it! An element with the required attribute can be easily targeted with CSS using [required] so there's no need to duplicate attribute and class.

If you added the required class to the label associated with the required control, you can still style everything using combinators or the :has() pseudo-class.

[disabled]

Buttons, inputs, and other form controls often get a .disabled class, but the disabled attribute already exists. It prevents interaction, signals state to assistive technologies, and is baked into the platform.

Again, why duplicate efforts and specify that a control is disabled using a non-semantic (class) and a semantic (attribute) option? Simplify the code, and keep only the semantic one.

...or [inert]

If you want to "disable" more than just single controls, the inert attribute is a powerful way to remove interactivity from entire regions. It's cleaner than disabling every child element manually, and easier to style, just using [inert] to target the element.

[switch] or [role="switch"]

Another way to target elements without needing to use classes is relying on roles. For example, instead of creating your own .switch class, use the ARIA "switch" role that can be targeted doing [role="switch"] (or the switch attribute once it's widely supported). Easy to style and it communicates semantics to assistive technologies. A win-win.

Note: As with everything related to accessibility, tread carefully. If done properly, it has many benefits for users and developers; but it can be a pain when not. This applies to roles and ARIA attributes like the ones we'll see next.

[aria-current]

A component that every website has is a main navigation menu. And usually, that menu has a highlighted item that is the current page or section. Many times, developers use an .active class to be able to target that element, but there's an ARIA attribute that could be used to do the same: aria-current. It's semantic, accessible, and works across contexts.

...or [aria-selected="true"]

If you are coding some tabs, instead of using aria-current you can do aria-selected="true" for the current element. It signals which tab is active without relying on random class names.

[aria-busy="true"]

Skeleton loaders and "loading" states often rely on .loading or .skeleton classes. But aria-busy="true" can be used for this. It tells assistive technologies the element is updating, and you can target it directly with [aria-busy="true"] and style it.

[aria-invalid]

Validation errors often get an .error class, But aria-invalid exists for a reason. It communicates the error state to assistive technologies and gives you a styling hook with [aria-invalid="true"]. Why not take advantage of it? This may be useful in radio fieldsets or groups of controls.

Conclusion: Use Native Attributes

Using attributes instead of classes isn't just cleaner, it's more semantic, more accessible, and more future-proof. Classes are arbitrary labels that change from project to project; attributes are part of the language. When you use them, you're speaking HTML fluently instead of hacking around it. And the browser and assistive technologies will thank you for it.

Stop overusing classes. Let the platform do the work.

These are but a sample of all the native attributes that could be used to replace classes. There are many more out there. Do you use attributes like these in your projects to simplify code or improve accessibility? Share them in a comment.

10 Cool CodePen Demos (July 2026)

Alvaro Montoro — Sun, 02 Aug 2026 13:06:08 +0000

Cut Squares Tessellated Pattern - No Div - Pure CSS

Josetxu used some conic and linear gradients along with custom properties to craft this three-dimensional pattern. It's simple and CSS-only. A nice way to practice backgrounds, sizes and positioning.

WindowsXP Files

As part of a CodePen challenge, Zerde Turdybek created this web version of a Windows XP folder in which you can open files. A demo for the nostalgic crew :)

Inversive Geometry

Another demo by Zerde Turdybek. This time using P5.js to create something more interactive: pull the dots around to move the shapes and change the drawing.

A love letter to Pachinko

Liam Egan developed a Pachinko arcade game, but instead of balls falling into slots, it is letters, and you can control how many by clicking a button... even create some chaos by pressing multiple times quickly. And it is fun an entertaining seeing the letters fall and collide with the dots.

Monkey in the water

A minimalist CSS Art by Cassidy. This animated monkey relaxing in water was drawn using only three HTML elements and some CSSS, which is pretty impressive.

SKYDREAMS: A 3D 1K FEVER DREAM

This 90s style game reminds of the classic Sonic mini-games. Frank Forece coded it using just 1024 bytes of JavaSCript! Use the mouse to move right and left and click to jump. Have fun! It's not as easy as it seems.

Line Shadows (CSS)

This animation is fully created with HTML and CSS. Figuring out timings, paths, and layers sounds complicated, but the code is incredibly simple. Although that's not surprising as Amit Sheen is world-class at creating 3D CSS animations.

Water - WebGL Shader

This interactive shader (mouse over to "disturb" the water) by Tamino Martinius feels incredibly realistic. The liquid texture and the waves when moving around seem so natural and smooth. Great job.

testing text-fit

Right now, if you want text to expand and grow its size to occupy the whole line width, you need to do some math or resort to hacks (that generally include math or unnecessary animations). In this demo, Temani Afif showcases a new CSS feature landing on the latest Chrome that will simplify considerably that work: text-fit.

file drawer carousel

Vivi Tseng created this three-dimensional carousel/image gallery that performs really nicely. The transitions are smooth, the code is simple and small, and it can be customized and expanded to fit multiple purposes. I'm not a big fan of carousel, but this is a well-done component.

It's always...

Alvaro Montoro — Thu, 23 Jul 2026 14:48:10 +0000

Back after vacation and a short hiatus. Trying to get into speed and back into the routine of drawing comics and cartoons with CSS.

I like this cartoon, I may put it on a t-shirt and wear it at conferences 😄

The Sword of Damocles at Work: The Human Cost of Delayed Layoffs

Alvaro Montoro — Fri, 10 Jul 2026 19:50:17 +0000

Over a decade ago, my employer announced layoffs that would happen in waves. Every few months another round arrived. Nobody knew the criteria, who would be affected next, or when. The uncertainty was exhausting and took a toll on everyone. This week, Xbox announced a similar plan, and it brought those memories back.

Fifteen years ago, the company I worked at announced 38,000 layoffs that would happen in different stages. That was a nerve-wracking experience. They started with 10,000, then months later another 8,000, then months later another 9,000... You never knew the criteria, how or when they would happen.

What I remember from then was the angst of not knowing what was going to happen. The figurative sword of Damocles hanging over our heads, and the helplessness of it all. I don't wish that feeling on anyone.

At one point, adding layoffs, early retirements, and turnover, they reached the magic number of 38,000. When asked if layoffs would stop then, the explanation we received was that the target referred to layoffs, not overall headcount reduction. So layoffs continued while hiring accelerated.

During that period, many teams were involved in onboarding and training new employees and contractors, even as layoffs continued. Two weeks after training the new contractors, nearly my entire department was laid off, including myself. Only one person per project remained.

It was the last batch of layoffs from the original 38,000 they had announced.

My wife was 6-7 months pregnant. We lost our main source of income and the health insurance right at the moment we needed it the most. The company gave me a severance and offered $2,000 for not coming back in two years. I was interviewing internally so I rejected it. In hindsight, that was a mistake.

The internal process was rejected after going through a few good interviews. I never received an explanation. So my only option was taking a severance that was shorter than what it could have been, and looking for a new job.

But that was then.

It was a hot job market for software developers, and I was lucky to get interviews within weeks, a couple of offers in a matter of a month, and start a new job in 2 months.

Today, the situation is different.

This week, Xbox announced 3,200 layoffs. About half took effect immediately, while the remaining cuts are expected to happen over the next 12 months. No one knows when, who, why, or how. And, from experience, delayed layoffs like this are tough. An unnecessary burden.

The current job market for software engineers is... "interesting." While during my layoff I wasn't especially worried about finding a job (it was more of a matter of "when" than "if", and we had a baby waiting around the corner), the Xbox layoffs (as many of the current layoffs) come at a time in which "when" or "if" are blurry. There are jobs... but they are tougher to get and come with many conditions and changes.

Layoffs are always painful. But spreading them over months, creates a different kind of burden: uncertainty. It builds angst and stress that no one should have to endure, and that doesn't help anyone. Not the people who leave, and not the people who stay.

To all impacted, I'm sorry you're going through this. Best of luck to everyone.

10 Cool CodePen Demos (June 2026)

Alvaro Montoro — Sun, 05 Jul 2026 15:29:27 +0000

Sand bottle - WebGPU

Remember those bottles filled with colored sand that you can find in many souvenir stores? Liam Egan created a digital version using JavaScript WebGPU API. Click to drop sand, use the arrows to tilt and shake the bottles, and relax while enjoying this sandy demo.

Button State Builder

Margarita shared this button builder that allows to customize a control with icons, text, color, shape... even all the behavior in the different states of the button. Then you can easily get the HTML, CSS, and JS code to put it on any website. Pretty cool.

WebGL Switch Button

In this demo, the whole page turns into a giant three-dimensional toggle switch that can be activated clicking anywhere on the viewport. Explore the component: mouse over to make the component tilt or scroll to zoom in and out. A nice job by Toc.

Animated radial gradient mask over text

This demo is exactly what the title says: a radial gradient applied as a mask to some text. Cassidy aligned it perfectly with the hole in the O from "Hello" that makes this effect chef's kiss. You will need to uncomment the animation property in CSS to see the demo in action.

221.

ycw always creates impressive and original content. And this demo delivers. It's not only the effect in itself, but the use of light and shadows, and the perfecto choice of color that adds a timeless atmosphere. Beautiful.

vRLbdoSAIsoSQvisac

Mustafa Enes created different versions of this idea over the past month, all of them are great, but I picked this one as it is more interactive. Click on the screen to regenerate the pattern and move the mouse around to animate the colors. I don't know why, but there's a feeling of peace and joy while doing it.

beach sunset

I saw several demos by Vivi Tseng that caught my attention this month. Really enjoyed the general minimalistic style they all had and finally picked this animated one because it feels simple and pure, almost like a drawing a child would do during a vacation. I really enjoyed it.

Color Name Wheel

Mixing real CSS color names with invented ones (I'd fight for Tangerine Tango to be included in the specs), David Aerne sorts colors based on hue (angle) and lightness (radius) to create this colorful spinning spiral.

Wiggly/Wavy Range Slider

Temani Afif always comes with impressive CSS-only components, and this is an example of them. This demo ingeniously combines view transitions with shapes, offsets, and some properties to generate this squiggly component that should be, at least in theory, impossible. Note: this component only looks like this on Chromium.

Fun, animated link effects using paths and GSAP

If these colors and effects look familiar, that's because you've probably seen some of Josh Dillon's work with toggles before (and if you haven't, check them out!). Interactive and fun text effects that can be easily created with GSAP.

10 Cool CodePen Demos (May 2026)

Alvaro Montoro — Tue, 23 Jun 2026 20:10:37 +0000

Rheinturm Lichtzeitpegel Clock

Niklas Knaack drew this clock using HTML and CSS: gradients, paths, animations... and added a little JavaScript to change the lights so the clock is always in time. An impressive drawing.

Bioluminescent Tree

This virtual tree changes colors and shapes every time it is generated (and you can click on it to generate it faster). The game the colors pop up and illuminate the tree are mesmerizing. Great job by Mustafa Enes.

theSymmetrishQuality

Another generative art piece, this time by Sophia (fractal kitty), that is often in these lists with her demos. This time, the lines that form the spiral move hypnotically and peacefully... they kind of remind me of the wind lines in the news weather forecast on TV. Relaxing.

The Never Ending Story

This infinite scroll experience was crafted by Joe Ben Taylor using Lenis and GSAP. It is interesting because the parallax effect is not just a very high page, it really goes forever and snaps perfectly as you scroll.

Light card

Amit Sheen crafted this floating card using HTML and CSS only (the demo includes a little JS, but it is for updating a CSS custom property). The result is stunning, especially considering that all the lights and shadows are achieved using CSS.

The Witching Hour

More CSS art! This time it is Gemma Croad who coded this peaceful night scene with purple lilies. It is amazing what she can achieve by combining shapes and gradients.

Infinite Animation Speed Control

By using custom properties and the turn unit instead of hardcoded values, Temani Afif is able to spin these figures smoothly in either direction. Try it, mouse over them and check how the spinning changes naturally.

shape() generator

This demo is from a testing account by Miss Fox. It is a simple to use shape generator for the experimental shape() function in CSS. It is easy to use and convenient, and it can be used also to learn and understand the different possibilities of this feature.

FLIP text

Steve Gardner creates amazing things with code. This animated words is an example of that. He expands, collapse, removes, and attaches letters to transform words smoothly with GSAP in this looping animation.

Another world

A fantasy world from a the large windows of a castle or palace, that is as beautiful as it is dark. Created with WebGL, this demo by Liam Egan is impressive and evocative. I wish there was a way to move the camera to see more of the landscape.