DEV Community: Mattia Astorino

AI skills are the new NPM packages

Mattia Astorino — Fri, 03 Apr 2026 06:54:28 +0000

We used to share code. Now we share intent.

For years, our industry has been built around one core idea: reuse.

npm packages, shared libraries, frameworks — all ways to take someone else's solution and plug it into our own system.

It worked. It scaled. It shaped how we build software.

But there's always been a hidden cost.

When you import a package, you're not just importing functionality — you're importing decisions.

Architecture choices, naming conventions, constraints, trade-offs made by someone else, often in a different context.

Sometimes that's exactly what you want.

Other times, it's friction you carry for the lifetime of your product.

From code to knowledge

I've been thinking about this a lot lately, especially with the rise of AI in our workflows.

And I keep coming back to the same idea: AI skills are becoming the new npm packages.

But instead of distributing opinionated implementations, we're starting to distribute something more flexible — and arguably more valuable: expertise.

An AI skill doesn't give you code to reuse.

It gives you a way to think.

It captures how someone approaches a problem — the constraints they consider, the trade-offs they make, the patterns they recognize — without forcing you into a specific stack or architecture.

That's a very different kind of abstraction.

We're moving from sharing solutions to sharing reasoning.

Why this shift matters

With traditional packages, reuse comes with coupling.

You gain speed, but you inherit structure, opinions, and implementation.

With AI skills, the relationship flips.

You still benefit from someone else's experience, but you stay in control of the implementation. The output adapts to your context — your codebase, your constraints, your product.

This decoupling is subtle, but powerful.

It means that expertise becomes portable in a way it never really was before.

Not as blog posts.

Not as documentation.

But as something you can actually use in your daily work.

What this looks like in design systems

This shift becomes very real when you look at design systems.

Traditionally, a design system is distributed as a set of components, core elements, and guidelines. You build a system, document it, and teams consume it.

The true value of a design system lies not simply in the sum of its individual parts.

It's the decisions behind them.

Why a component behaves a certain way.

Why a pattern exists.

When to use it — and when not to.

Those things are hard to encode in code, and this is where AI skills start to change the game.

Imagine a design system not just as a static library, but as a skill you can query.

Instead of browsing documentation, a developer could ask:

"Generate a table component API consistent with our system, including accessibility constraints and edge cases."

Instead of manually reviewing UI, you could run a skill that analyzes a screen and flags inconsistencies with your design tokens, spacing rules, or interaction patterns.

Instead of onboarding someone through pages of docs, you could have a skill that explains your system in context — why things are built the way they are, not just what exists.

In all these cases, you're no longer distributing just the output of the system.

You're distributing the thinking behind it.

A different kind of reuse

What's interesting is that this doesn't replace traditional systems — it complements them.

You still need components.

You still need code.

But now there's another layer on top: a layer where knowledge itself becomes reusable.

And that changes the nature of what we build and share.

As someone working in UI and design systems, this feels particularly relevant.

Because so much of the work has always been about decisions, consistency, and trade-offs — things that don't live comfortably in code alone.

AI skills give us a way to package that part of the work.

Not without risks

Of course, this isn't automatically better.

A poorly designed skill can be just as harmful as a poorly designed library — maybe even more, because it's less visible.

There's also a real risk of superficial outputs if the underlying thinking isn't solid.

And we're still relying on models we don't fully control.

So this isn't about replacing engineering discipline with prompts.

It's about adding a new layer — one that needs just as much care, if not more.

Closing thought

NPM packages helped us scale our code, while AI skills could help us scale our thinking.

This represents a deeper shift than it initially appears.

We're not just sharing what we build anymore.

We're starting to share how we think.

Vira Theme: A Deep Dive into the Premium Successor of Material Theme

Mattia Astorino — Mon, 30 Jun 2025 09:34:27 +0000

If you've ever loved Material Theme in VS Code, you're going to fall for Vira Theme — it’s the premium evolution, tailored for dark-mode devotees and polished enough to keep developer workflows in mind.

What is Vira Theme?

Material Theme lineage — Vira is the official successor of Material Theme, which powered over 9 million users over 10 years of free service. It retains and improve the beloved aesthetics, while evolving in form and function. Vira Theme, which has been in the works for a whole year, is like the next big thing after Material Theme.

Teal	Ocean	Carbon
Palenight	Graphene	Deepforest

Exclusively Dark with Distinct Flavor

Vira smartly drops light variants to focus on creating cohesive and polished dark themes, eliminating dilution of effort.

Choose from Ocean, Teal, Palenight, Graphene, Deepforest, and the star of the show — the new Carbon variant with a near-black background and desaturated syntax coloring.

Hand‑crafted Icons & Auto‑Accent Sync

With over 320 curated file and folder icons, each one is uniquely designed and updated to keep your app looking sharp and modern. Plus, automatic accent synchronization links your icon colors with your theme accent, so you can have a unified UI without any hassle.

Deep Customization

Vira lets you customize your experience from the command palette or settings. Here are some options:

Accent color: Choose an accent color or set your.
Outlined folder icons: Toggle icon styles to match your style.
Explorer arrows visibility: Choose between a clean or structured look.
Editor borders: Enable borders to visually distinguish editor sections.
Modern line highlight: Choose between a legacy or bold-highlight style.
Hide shadows: Remove unwanted elevation indicators.

Lear more about settings.

Deps no thanks

Vira Theme is a refreshing change from Material Theme and all the other abandoned clones out there. It’s completely dependency-free, meaning there are no dead dependencies in the final bundle. Plus, you don’t have to download any third-party code. This means no security risks — and it’s never been the case, never trust hate-baiting on internet, they just want to monetize with hate and harassment.

FAQ

The Material Theme remains functional. However, the VSCode team has implemented policies that make deprecated extensions unavailable. This decision is not within our control. If you locate the VSIX file, you may proceed with its installation and usage, acknowledging the potential consequences.
Upgrading to the Vira Theme is not mandatory; no one compels you to migrate from Material Theme. VS Code merely suggests a replacement. If you are dissatisfied with it, you are free to use other extensions.
The Vira Theme is distinct from the Material Theme. It has undergone a comprehensive overhaul over the past year and a half, incorporating numerous updates, new icons, and features that are not present in the Material Theme.
We offer discount codes to help migrating

SUMMER SALES ARE HERE! 🎉

After your 7-day free trial, you can use the code E0NZIZNW (valid until July 30, 2025) to get a 35% discount on the 6-activations license! No subscription, no fees.

Try for free

Design with the A+R model

Mattia Astorino — Fri, 22 Nov 2024 11:30:34 +0000

What Happens when we combine Adaptive and Responsive design?

Responsive and adaptive design are two approaches used to make websites work on any device, regardless of screen size, ensuring the best user experience. Both aim to optimize screen space and interaction methods, whether users rely on precise pointers or gestures. Before diving into the A + R model, let’s briefly go over both approaches.

A responsive approach to design uses CSS and/or JS to adapt layouts and content based on predefined “breakpoints.” On the other hand, the adaptive method provides pre-structured templates tailored to the type of device being used. The former predicts and defines when layouts and content need to change based on orientation, screen size, or content, while the latter delivers targeted experiences based on one key factor: the type of device (and by extension, user) accessing the service. The main difference lies in the structure of the content and HTML. In a responsive approach, the HTML and content structure remain the same (unless JavaScript is used to remove content from the structure) and adapt to different situations. In contrast, adaptive design involves different structures, layouts, and potentially unique experiences.

Contrary to popular belief, the adaptive approach is widely used in web applications. For instance, creating specific experiences for on-the-go scenarios, where information needs to be easy to access, or for more comfortable desktop settings is common. Twitter, GitHub, and Facebook are prime examples of adaptive design in action.

Both approaches are valid and widely used. To choose the right one, ask yourself the following questions:

How many components and how much complexity does the project involve?
Do users have the same expectations and interactions as desktop users?

Responsive Design Techniques

When building a responsive experience, there are three main techniques for managing layouts and content:

Reflow: This involves changing the layout structure to use the available space best. Most of the time, the result is content being stacked vertically. While easy, this approach isn’t always the best choice.

Resize: Interface components are designed to be fluid, much like most HTML elements. They fill the available space, and the content adjusts to fit the new dimensions.

Show/Hide: Some interface parts are hidden (but still exist in the structure) or shown, depending on the available space.

Adaptive Design Technique

Restructuring: The adaptive approach allows for the development and distribution of different layouts to provide the best experience for specific contexts, such as gesture-only devices or hybrid touch devices.

Different experiences, different usage

Introduction to the A + R Model

Both approaches have their pros and cons, but what happens when we combine them? The A + R model takes the best of adaptive and responsive design by introducing the concept of major and minor breakpoints.

A for Adaptive

As mentioned earlier, the adaptive approach allows us to tailor experiences, content, and even features based on the type of device or screen size (usually the more appropriate factor). Major breakpoints are defined to mark the start and end of an experience.

By setting 960px as a major breakpoint (based on global stats), we can imagine something like this:

The left side represents screens smaller than 960px, delivering layouts and content tailored to that type of experience.
The right side represents screens larger than 960px, offering an experience designed for that type of navigation.

R for Responsive

The major breakpoint creates two potentially different experiences, within which we can apply responsive design techniques. For each defined experience, we can set minor breakpoints to adapt the layout to the available space. For instance, tablet users might see an experience optimized for touch devices (adaptive), but with layouts that adjust based on device orientation (responsive).

Adaptive + Responsive

Combining Adaptive and Responsive approaches results in the A + R model. The adaptive technique defines experiences and functionalities, creating two distinct contexts. Meanwhile, the responsive technique manages interface components, layouts, and behaviors within each context.

When to Choose This Model

This approach requires designers and developers to fully understand the experiences they want to deliver. It’s typically used for large applications that need to be optimized for mobile devices, requiring various functionalities and layouts. While it offers flexibility and customization, it also introduces complexity, as you might end up managing two separate projects or environments, which is not recommended.

If the team decides to follow the A + R model, they can focus on delivering curated, targeted experiences based on user type—something a purely responsive approach cannot achieve, as it’s always a compromise.

Who Uses the A + R Model?

Many online services we use daily follow this approach. Twitter, Facebook, and GitHub, for example, provide dedicated mobile apps rather than simply stacking and hiding parts of their desktop content. If you access these services on your mobile device, you’ll notice tailored experiences designed to meet the expectations of mobile users compared to desktop users.

Introducing Native Elements

Mattia Astorino — Thu, 18 Jun 2020 15:27:08 +0000

HTML elements with CSS superpowers. 🔥

Native Elements (NE) is not a CSS framework, no bundlers required or tons of configurations to set. You can consider it as a customizable plug-n-play library for your site which helps you easily style all the available HTML elements using CSS custom properties, classes, attributes, or whatever you want in less than 6 kB. You can also build your class-based CSS framework on top of it.

Features

This library is built using modern CSS feature and best practices, the compiled version supports only the latest two Chrome, Safari, Firefox, and Edge versions and this is possible thanks to Browserslist

Modern

Built on top of PostCSS takes advantage of exciting new CSS features, like custom and logical properties. If you use it from source, you can define custom selectors and mixins to make styling even easier.

Framework agnostic

In the age of Flexbox, CSS grid, and other exciting layout features, there is less and less need for a bloated CSS framework. What you do need is a simple foundation on top of which to build your styles.

If you're using the compiled version, just drop it inside your application main style. It's just CSS, so it works with React, Vue, Angular and Svelte.

Easy theming

With our theme builder tool you can create, tweak, and export your theme easily. In the future, we'll share new premade themes.

Making a theme

Thanks to the Theme Builder app you can create your color palette, visually change and preview all the available custom properties, and download a ready-to-use theme that you can include in your project.

Using themes

Once you have your set of custom properties, there few ways to use it. You can put the custom properties inside the global :root of your css, or scope it inside a custom selectors.

Global themes

When you put your theme inside the :root selector it will be applied to all the elements of your page. This is useful when you have one theme active at time:

:root {
  --accent-color: hsl(220, 100%, 50%);
  --ne-global-background: hsl(0, 0%, 100%);
  --ne-global-foreground: hsl(0, 0%, 0%);
  --ne-body-font-family: sans-serif;
  --ne-root-font-size: 100%;
  --ne-body-font-size: 1.125rem;
  --ne-selection-foreground: hsl(0, 0%, 100%);
  --ne-selection-background: hsl(233, 64%, 72%);
  --ne-outline-width: 2px;
  --ne-outline-color: var(--accent-color);
  --ne-basic-line-height: 1.5;
  --ne-headings-scale: 1.25;
  --ne-quote-font-size: 2rem;
  --ne-cite-foreground: var(--accent-color);
  --ne-cite-font-size: 1rem;
  --ne-cite-start-sign: '—';
  --ne-links-foreground: var(--accent-color);
  --ne-links-active-foreground: hsl(233, 64%, 52%);
  --ne-del-foreground: hsl(337, 74%, 31%);
  --ne-del-background: hsl(0, 100%, 94%);
  /* ... */
}

Scoped themes

The CSS's cascade is very useful to make scoped themes, it affects custom properties like other properties.

If you want to divide your theme into multiple pieces, you can wrap the custom properties inside separate selectors. Every element inside that selector will inherit the theme, while elements outside it will use their default style.

:root[data-theme="dark"] {
  --accent-color: hsl(220, 100%, 50%);
  --ne-global-background: hsl(0, 0%, 100%);
  --ne-global-foreground: hsl(0, 0%, 0%);
  --ne-body-font-family: sans-serif;
  --ne-root-font-size: 100%;
  --ne-body-font-size: 1.125rem;
  /* ... */
}

.NeumorphicTheme {
  --accent-color: hsl(220, 100%, 50%);
  --ne-global-background: hsl(0, 0%, 100%);
  --ne-global-foreground: hsl(0, 0%, 0%);
  --ne-body-font-family: sans-serif;
  --ne-root-font-size: 100%;
  --ne-body-font-size: 1.125rem;
  /* ... */
}

When to use it

You're working on projects for modern and secure web browsers
You're not going to mix other CSS frameworks
You want to save time sacrificing a bit of flexibility.

Making dark theme switcher with PostCSS.

Mattia Astorino — Tue, 12 May 2020 08:17:24 +0000

You have noticed that there is a new design trend that is floating around web design since 2019, the dark mode. Facebook, Apple, and Google both introduced the dark version of their software.

Why a dark theme

Most of you probably think this is just a trend that will disappear after some years, well, let me say that this is not like many other trends, dark UI provide different advantages and they are not something just related to the "designer mood". Let's see why a dark mode on your applications and websites are something useful.

Better for batteries

Pixels on a screen consume more energy to display light colors rather than dark ones. Consequently, devices' batteries can save energy and improve their daily duration while using dark UI.

Better for dark environments

Most of us use their smartphone and laptops while at home. Such environments are typically not so bright. The dark mode can help the use of the application while indoor, without causing visual disturbances.

Better for people

Some people with — or without — visual diseases, like epilepsy, can have unfortunate events by being flashed by bright applications. Having a dark mode means being more accessible.

Preparing styles

A very simple theme switcher should offer at least 3 options:

Dark theme
Light theme
Automatic theme (should be on by default)

Wait, what's the automatic theme? Well, modern operating systems allow users to change the global visual appearance by setting os-wide options that enable the dark or light mode. The automatic option make sure to respect the OS preference if the user has not specified any theme.

To make this even more simple, we'll use PostCSS and a simple but useful plugin called postcss-dark-theme-class.

yarn add postcss-dark-theme-class

This plugin will do 70% of the work, once installed, add it to your PostCSS config and configure the selectors you want to use to activate the correct theme, which will be used by the plugin to generate the correct CSS:

module.exports = {
  plugins: [
    /* ...other plugins */

    require('postcss-dark-theme-class')({
      darkSelector: '[data-theme="dark"]',
      lightSelector: '[data-theme="light"]'
    })
  ]
}

Once the plugin is up and running, we can start defining our dark and light themes using a CSS specific media query prefers-color-scheme. This special media query will handle the automatic part of our themes by applying the correct theme based on the user's OS preferences:

:root {
  --accent-color: hsl(226deg 100% 50%);
  --global-background: hsl(0 0% 100%);
  --global-foreground: hsl(0 0% 0%);
}

@media (prefers-color-scheme: dark) {
  :root {
    --accent-color: hsl(226deg 100% 50%);
    --global-background: hsl(0 0% 0%);
    --global-foreground: hsl(0 0% 100%);
  }
}

If the user is using a dark version of his OS, the set inside the media query will apply, overwriting others, otherwhise the set of properties outside the media query is used. Since it's pure CSS, this behaviour is on by default.

Browsers will now adapt the color scheme automatically based on the users' OS preferences. Nice done! 🚀 Now it's time to make the theme switcher allow users to specify what theme to use, overriding the OS preference.

Making the theme switcher

As we said, our switcher should have three options, we can use a simple select element, or build a set of buttons:

<button type="button" data-set-theme="auto">Auto</button>
<button type="button" data-set-theme="dark">Dark</button>
<button type="button" data-set-theme="light">Light</button>

We'll build the switcher using vanilla JS, but you can do it with any framework you want, the concept is the same: we have to add the selectors we defined inside the PostCSS plugin to the root element, based on the clicked button.

const html = document.documentElement
const themeButtons = document.querySelectorAll('[data-set-theme]');

themeButtons.forEach((button) => {
  const theme = button.dataset.setTheme;

  button.addEventListener('click', () => {
    html.dataset.theme = theme;
  })
})

Each time we click on a theme button, the value set as data-set-theme is applied as value of the data-theme attribute on the document root element, we also change the [aria-current] attribute.

Check it live:

Where is the magic?

The magic is made by postcss-dark-theme-class — which will add our [data-theme] custom attribute to the :root selectors we wrote — during the CSS transpilation. Here what it generates from our code:

/* Our automatic and user specified light theme */
:root {
  --accent-color: hsl(226deg, 100%, 50%);
  --global-background: hsl(0, 0%, 100%);
  --global-foreground: hsl(0, 0%, 0%);
}

/* Our automatic dark theme */
@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]) {
    --accent-color: hsl(226deg, 100%, 50%);
    --global-background: hsl(0, 0%, 0%);
    --global-foreground: hsl(0, 0%, 100%);
  }
}

/* Our dark theme specified by the user */
:root[data-theme="dark"] {
  --accent-color: hsl(226deg, 100%, 50%);
  --global-background: hsl(0, 0%, 0%);
  --global-foreground: hsl(0, 0%, 100%);
}

Bonus tip

You may notice that the --accent-color custom property defined inside themes doesn't change. If you have colors that will not change based on the theme, you can remove them from the prefers-color-scheme at-rule.

In this way, they will not be duplicated and the one defined outside the media query will always apply.

:root {
  --accent-color: hsl(226deg 100% 50%);
  --global-background: hsl(0 0% 100%);
  --global-foreground: hsl(0 0% 0%);
}

@media (prefers-color-scheme: dark) {
  :root {
    --global-background: hsl(0 0% 0%);
    --global-foreground: hsl(0 0% 100%);
  }
}

Making Web Components for Different Contexts

Mattia Astorino — Tue, 07 May 2019 14:08:48 +0000

This article isn’t about how to build web components. Caleb Williams already wrote a comprehensive guide about that recently. Let’s talk about how to work with them, what to consider when making them, and how to embrace them in your projects.

If you are new to web components, Caleb’s guide is a great read, but here are more resources that will get you up to speed:

Since web components are now widely supported (thanks to the hard work of many people behind the scenes) — and considering the imminent switch that Edge will make to the chromium platform — people are now thinking about web components as "native" and a platform-compliant way to build reusable UI components to keep consistency across design systems and web projects, while using the power of the Shadow DOM to encapsulate style and logics inside the component itself.

Well, this can be true and false at the same time. But first, let’s get acquainted with the Abstraction Layers Triangle.

The Abstraction Layers Triangle

Technically, we should consider web components as an extension of our favorite markup language, HTML (yep!). The Web Components API allows us to create custom HTML elements (e.g. <foo-bar>) that don’t exist in HTML.

We are told web components are basically new HTML elements, so we should consider them as part of the HTML specifications and, consequently, we should follow its paradigms, core concepts, and utilisation. If we assume all of these points, we will figure out that our components will live among the lowest levels of the web platform stack, alongside HTML, CSS, and JavaScript.

Frameworks and libraries like React, Vue, Angular, SvelteJS work on their abstraction level, right above other tools that live in a sort of "middle earth," like StencilJs, Hybrids and Lit. Under these layers of abstraction, we can find our basic web technologies… and vanilla web components. We can represent this concept with an ALT (Abstraction Layers Triangle) diagram:

Why is this important? Well, it helps us visualise the various layers that exist on top of native components and understand the context they are used so that they can be built for an intended context. What's context? That's where we're headed.

Same technology, different contexts

The Shadow DOM is a key factor in the Web Components API. It allows us to bundle JavaScript and CSS inside a custom element to both prevent external interferences and style manipulations, unless we expressly allow it. There are indeed some approaches that developers can follow to allow external CSS to leak into the shadow root and into a component, including custom properties and the ::part and ::theme pseudo-elements, which is something Monica Dinculescu) has covered so well.

There is also another thing to consider: the context we are working with. After three years of building web components personally, I can identify two contexts: the private context (like a design system) and the standard context (like plain HTML, CSS, and JavaScript without custom styles).

Before designing components, we need to know how they will be used, so determining the type of context is a key to all of this. The most easy way is targeting only one context, but with a small CSS trick. we can build our components for both of them.

Let’s look at the differences between the two contexts before we get into that.

Private context

A private context is a closed ecosystem that provides components with their own style that must be used as-is. So, if we are building a component library that comes from specific styling guidelines or a design system, each component will reflect custom styles so there’s no need to code them up each time they’re needed.

That can be true also with JavaScript logic. For example, we can attach a closed shadow root that prevent others to accidentally pierce the shadow boundary with a querySelector. As a a result, we can simply pick and use all any component, avoiding issues like style inconsistencies and CSS collisions. As the author, you can also get to define a set of CSS custom properties (or ::parts) that can be used to style a component for a specific use case, but this is not the focus point of a design system.

Here’s an example of a web component component in a private context. It has all of the styles and logic contained inside its shadow-root and and can simply be dropped into any page.

This example and the one to follow are for demonstration purposes and not intended for production use because they do not make considerations for key situations, like accessibility and other optimisations.

Components in a private context can be rarely used outside of that context. For example, if we try to take an element from a design system (which has its own enforced styles), we’re unable to simply add it to a project and expect to customise it. You know how Bootstrap can be themed and customised to your liking? This is pretty much the opposite of that. These components are made to live inside their context and their context only.

Standard context

A standard context may be the most complex type of component, not only because the environment can range anywhere from a full-fledged framework (like Vue and React) to plain vanilla HTML, but also because everyone should be able to use that component like any other element.

For example, when adding a component publicly, say to npm, those who use it will expect to be able to customise it, at least to some degree.

Do you know of any HTML element that comes with its own presentational style? The answer should be no because, well, elements must be explicitly styled with CSS. This is also true for web components made in a standard context. A single web component should be customisable by adding classes an attributes, or other methods.

Here’s the same <todo-list> element that we saw in the closed context example, but designed for a standard context. It works as-is, without any presentational styles inside its shadow root. In fact, it only contains the required logic and baseline CSS to make sure it functions. Otherwise, it’s completely customisable like any standard HTML element, like a div.

Both of the examples we’ve looked at for each context are made with the same component. The difference is that the component in a standard context an be customised and selected with external CSS.

Web components and composition

OK, so working with web components is really the same as working with plain HTML, though as we’ve seen, it’s important to follow the paradigms and principles of the given content. Well, thing we need to be mindful of is the web component composition.

As explained by Google Web Fundamentals:

Composition is one of the least understood features of shadow DOM, but it's arguably the most important.

In our world of web development, composition is how we construct apps, declaratively out of HTML. Different building blocks (<div>s, <header>s, <form>s, <input>s) come together to form apps. Some of these tags even work with each other. Composition is why native elements like <select>, <details>, <form>, and <video> are so flexible. Each of those tags accepts certain HTML as children and does something special with them. For example, <select> knows how to render <option> and <optgroup> into dropdown and multi-select widgets. The <details> element renders <summary> as an expandable arrow. Even <video> knows how to deal with certain children: <source> elements don't get rendered, but they do affect the video's behavior. What magic!

Composition is what we normally do when we work with HTML. Since web components are merely HTML elements with a DOM reference — and not logical containers — we should rely on composition to build our components and any sub-components. If you think about the ul and and select you will notice that you declaratively compose these elements to get the final output and you have specific attributes to be used with the main component (e.g. [readonly]) or the sub-component (e.g. [selected]). This is true also for web components, and if you are building a custom list, consider to build the main component (<custom-list>) and the child one (<custom-li>). Using the [slot] element, you can define where children elements will be placed and also placeholder content that will be shown when no children are passed through.

Web components and accessibility

Another thing to consider is that "small" topic we call accessibility. Since we are creating completely new HTML elements, we need to consider the accessibility of our elements in order to provide a basic semantic role, any keyboard navigation as well as the user’s operating system preferences, like the reduce motion and high contrast settings.

I strongly suggest the following resources as reference for building accessible and inclusive components, how to define semantic markup, and how to implement a basic keyboard navigation.

Conclusion

Web components are an emerging technology in web development and, as such, there really aren’t any clearly defined best practices to guide us as far as building them for their intended or maximized use. When you find yourself working with them, perhaps the single thing you can take away from this post is to consider whether they are intended for a closed context or a standard context, then ask yourself WHI:

Who will use this component?
How much flexibility should that person have to customize it?
Is this component for everyone or for a specific audience?

The Adaptive + Responsive model

Mattia Astorino — Tue, 12 Feb 2019 15:26:33 +0000

You can call it Adansive or Resaptive..

Responsive and Adaptive design are two design methodologies with the goal of making a product accessible on any device or screen size, providing the best experience to all users. Both of them try to make the most of the available screen space and the user interaction mode. Before talking about the A+R model we need to break down both methodologies approaches

While responsive design makes use of CSS and/or JS to adapt layouts and contents based on predefined breakpoints, the adaptive approach provides pre-structured templates that will be served based on the user agent and the device type. The main difference between them is the DOM structure, when approaching with a responsive mindset we have the same HTML code for all situations (unless you use JS to remove some DOM nodes), while in adaptive we have a different code structure and potentially different experiences.

Both design mindsets are valid, just ask yourself how many components and complexities you have in your project and if one experience can fit all of your users. Developing web applications the responsive design is frequently used, such as building specific experiences through an adaptive development, like Twitter and Facebook mobile do.

Responsive Design Techniques

While building a responsive experience we have three approaches to handle our layouts and content:

Reflow: We can change the layout structure to better fit the viewport area. Most of time this results in content being stacked (that's not always good).

Resize: Some of the UI components are fluid like most of html elements. They fill the available space and reflow if necessary.

Show/Hide: Some UI parts are hidden from the viewport (but they still exist) or showed up to fill the space.

Restructuring: With this approach we can develop and deliver different layouts to provide the best experience for a specific environment like a touch-only mobile device, or hybrid-touch devices.

Introducing the A+R model

Both approaches have pro and cons, but what do we get if we want to use both of them? The A+R model combines both the responsive and adaptive approaches based on a single major breakpoint.

A stands for Adaptive

As mentioned above, the adaptive approach allows us to differentiate the user experience, contents and even functionalities based on the user device. Considering a 960px as major adaptive breakpoint (defined based on global stats), we have something similar:

The viewport area on the left represent all the screens under a 960px with a specific layout/content
The viewport area on the right represent all the screens with a 960px or greater with another layout.

R stands for Responsive

The major breakpoint we have defined create two exprience contexts that may be different from each other, in which we can apply the responsive techniques. Inside each experience we can define minor breakpoints to adapt the layout based on the available space. For example, users which use a tablet will may see a touch-optimised experience (adaptive), but we can still adapt the layout based on the device orientation (responsive).

Adaptive + Responsive

Combining Adaptive and Responsive approaches we get the A + R model. With the adaptive technique we will work on experiences and functionalities, making two different contexts. Withe the responsive one we handle the UI components and layouts which stand inside the contexts.

When to choose the A + R model

This design approach require designers to really understand the experiences they want to provide in order to define what model to follow. This model fit well for large applications that must be accessible from small mobile devices with less functionalities or with a completely different structure. As you can see you will get a lot of flexibility, but also complexity because you may have to handle different codebases and environments (not mandatory).

With the A+R model mindset, designers and developers (but also product owners) can be focused to improve all the experiences the product can offers, instead to provide a "good" experience only on one environment.

Originally published at equinsuocha.io. All the images are made by me and the Contactlab UX team.

Fieldset, this stranger.

Mattia Astorino — Fri, 08 Feb 2019 18:21:32 +0000

Field..wat?? Yep, it still exist but no one seems to remember it. This guy is a living standard form element that is made to represent a set of elements inside a form or grouping related elements like labels, inputs, meters, paragraphs etc... and it doesn't end here, it can be nested and can contains any kind of elements.

Are you still interested? So i will tell you two more things, it can also accept three really useful html attributes that will help you making your beautiful forms aaaand....it's not made to wrap only radio buttons! 😱

The specification

The fieldset element represents a set of form controls (or other content) grouped together, optionally with a caption. The caption is given by the first legend element that is a child of the fieldset element, if any.

— WHATWG

It's pretty clear what you should do with this element and when using it. As mentioned above it can also accept three attributes: form, name and disabled.

FORM

This attribute allows you to associate a group of inputs to a specific form element that is not its ancestor. This means that you can fix the lack of the possibility to nest forms.

NAME

The name of the group to use in the form.elements API

DISABLED

This is the same global attribute you use on buttons and inputs. It disable at once all the child elements.

A use case

Let's take a real example making a form with disabled sections controlled by checkboxes. In this form we will use label, inputs and the output element and we can build it by making the most of fieldset attributes and a bit of javascript.

<form id="calculatorForm">
  <fieldset>
    <input type="checkbox" id="enableCalc">
    <label for="enableCalc">Enable calc</label>
  </fieldset>

  <fieldset name="calculator" disabled>

    <!-- Default formula -->
    <fieldset name="defaultcalc">
      <input type="checkbox" id="default" checked>
      <label for="default">Use default calculation</label>
    </fieldset>

    <!-- Custom formula -->
    <fieldset name="customcalc" disabled>
      <label>Use custom calculation</label>
      <input type="number" value="50" id="c">+
      <input type="number" value="50" id="d">=
      <output id="x" for="c d">100</output>
    </fieldset>

  </fieldset>
</form>

In this example we have a form with a fieldset named "calculator" which is disabled by default. When clicking the enableCalccheckbox the calculator area will be enabled. Here the live demo.

Apart the javascript integration, the point here is fieldset element. It's live, it's standard and it's useful.

"Bad" examples from...

The following examples are neither wrong or correct, but why not break this loop of "not-so-good practices" and start improving our code the same way we iper-improve our javascript code?

Twitter Bootstrap

<div class="form-group">
  <label for="formGroupExampleInput">Example label</label>
  <input type="text" class="form-control" id="formGroupExampleInput">
</div>

ZURB Foundation

<div class="input-group">
  <input class="input-group-field" type="url">
  <div class="input-group-button">
    <input type="submit" class="button" value="Submit">
  </div>
</div>

Material Design Components

<div class="mdc-form-field">
  <div class="mdc-checkbox">
    <input type="checkbox" id="my-checkbox" class="mdc-checkbox__native-control"/>
    <div class="mdc-checkbox__background">
      ...
    </div>
  </div>
  <label for="my-checkbox">This is my checkbox</label>
</div>

Tailwind CSS

<div class="mb-4">
  <label class="block text-grey-darker" for="username">Username</label>
  <input id="username" type="text" placeholder="Username">
</div>

As you can see many popular frameworks don't use fieldset (bootstrap mention it but nothing more) as form elements container and that's really weird because HTML have all the tools we need to build our webpages and applications. We should not recreate what the platform already provide, instead we just need to learn it and eventually how to extend it, for example with web components.

ckd.css for your ticks

Mattia Astorino — Fri, 21 Dec 2018 16:30:41 +0000

ckd.css v2 has been released and it will bring beautiful and small micro interactions to your checkboxes and radios. You can use it even on your custom imputs.

Why are micro interactions important?

It’s likely that you started your day with a micro-interaction. By turning off the alarm on your mobile phone, you engaged with a user interface in a single moment.

You will continue to engage throughout the day in these moments with your digital devices. Each one is a micro-interaction. Each one is probably so small you don’t think about it. And each one works because of that simple fact.

As a designer, recognizing the invisibility of micro-interactions is just as important as designing them. You have to create something that feels human and accomplishes a task, making the life of a user easier. You also have to focus on a design that can work in a variety of environments and does not need any instruction or explanation.

— The Next Web

equinusocio / ckdcss

A tiny set of micro interactions for your checkboxes.

Why?

It’s likely that you started your day with a micro-interaction. By turning off the alarm on your mobile phone, you engaged with a user interface in a single moment.

You will continue to engage throughout the day in these moments with your digital devices. Each one is a micro-interaction. Each one is probably so small you don’t think about it. And each one works because of that simple fact.

As a designer, recognizing the invisibility of micro-interactions is just as important as designing them. You have to create something that feels human and accomplishes a task, making the life of a user easier. You also have to focus on a design that can work in a variety of environments and does not need any instruction or explanation.

Source: The Next Web

Installation

As dependency

You can install ckd-css as node dependency by using Npm or Yarn.

npm install

…

View on GitHub

How to load web fonts in 2018

Mattia Astorino — Sun, 16 Dec 2018 16:49:51 +0000

Custom web fonts are used everywhere around the world, but many (many and many) sites load them improperly causing a lot of problems during the page loading, like performance issues, very long loading time, blocked render and font swapped during navigation.

I see many developers ignoring this argument or maybe they do the same error over and over just because "they have always done so", maybe they don't know that are working on a constantly changing environment.

I just think we should break this loop and start doing the right thing in 2018 because there are just four steps to consider when loading a custom web font:

Use the correct font format
Preload fonts
Correct font-face declaration
Avoid invisible text during font loading

Let's start breaking down these points to face them one at a time.

Use the correct font format

There are many font formats that can be used on web, but only two formats are really needed if you don't have to support IE 8 or lower (wtf?!): woff and woff2. These are the only two file types you should use because they are gziped by default (so they are very small) and optimised for the web, and as you can see, they are fully supported by IE 9+ and all other ever green browsers.

Preload fonts

When using custom fonts you should tell the browser to preload them using the appropriate tag and rel attribute:

  <link rel="preload" as="font" href="fonts/cicle_fina-webfont.woff2" type="font/woff2" crossorigin="anonymous">
  <link rel="preload" as="font" href="fonts/zantroke-webfont.woff2" type="font/woff2" crossorigin="anonymous">

Note that the use of crossorigin here is important; without this attribute, the preloaded font is ignored by the browser, and a new fetch takes place. This is because fonts are expected to be fetched anonymously by the browser, and the preload request is only made anonymous by using the this attribute.

In the above example, the rel="preload" as="font" attributes will ask the browser to start downloading the required resource as soon as possible. They also tells the browser that this is a font, so it can appropriately prioritise it in its resource queue. Using the preload hints will have a dramatic impact on web font performance and initial page load. Browsers that support preload and prefetch hints will start downloading web fonts as soon as they have seen the hint in the HTML file and no longer need to wait for the CSS.

You can instead use the rel="prefetch" attribute to tell the browser to prepare the download of the resources that may be required lately during page load or user actions so it will assign a low priority to the resource.

CAUTION:
If you’re using a CDN like Google Fonts, be sure that the font files you’re preloading match the ones in the CSS. Fonts can also be regularly updated, and if you’re preloading an old version while using the CSS for a newer one, you may end up downloading two versions of the same font and wasting your users’ bandwidth. Consider using <link rel="preconnect">👨🏼‍🔬 instead for easier maintenance.

Correct font-face declaration

Declaring a font-face family is very simple but we must care about some things when we do it. Here a correct example declaring a custom font family:

@font-face {
  font-family: 'Custom Font';
  font-weight: 400;
  font-style: normal;
  font-display: swap; /* Read next point */
  unicode-range: U+000-5FF; /* Download only latin glyphs */
  src: local('Custom Font'),
       url('/fonts/custom-font.woff2') format('woff2'), 
       url('/fonts/custom-font.woff') format('woff');
}

Unicode range from Google Web Fundaments

As you can see we use only optimised fonts (woff and woff2) and we tell the browser to download only the required glyphs range (from U+000 to U+5FF). There are also two more things to notice, the local() function and the fonts order. The first one allows users to use their local copy of the font if present (eg. think about the Roboto fonts that are pre-installed on android) instead of downloading it. The fonts declaration order is also important because the browser will start to fetching the resources following the declaration order. If it support the woff2 format it will download the font, instead if it doesn't recognise the resource format it will proceed to the next one, and so on. If you really want to use also eot and ttf fonts make sure to add them at the end of the src declaration.

Resources

Avoid invisible text during font loading

Fonts are often large files that take awhile to load even when gziped. To deal with this, some browsers hide text until the font loads (the "flash of invisible text"). You can avoid the "flash" and show content to users immediately using a system font then replace it.

In the previous @font-face example you can notice the font-display declaration. The swap value tells the browser that text using this font should be displayed immediately using a system font. Once the custom font is ready, the system font is swapped out.

If a browser does not support font-display it continues to follow its default behaviour for loading fonts.

Browser	Default behaviour if font is not ready…
	Uses a system font until font is ready. Swaps out font.
	Will hide text for up to 3 seconds. If text is still not ready, uses a system font until font is ready. Swaps out font.
	Will hide text for up to 3 seconds. If text is still not ready, uses a system font until font is ready. Swaps out font.
	Hides text until font is ready.

Testing

Here the link to test the "standard version" and the optimised one:

Result

DEFAULT

OPTIMISED

Making a CSS blob

Mattia Astorino — Mon, 22 Oct 2018 10:42:10 +0000

Some days ago i was trying to make an animated blob using just the CSS as a personal experiment and research. The big issue with the blob was the curvy-shape that was should randomly morph with a slow animation.

The only way i found to make this kind of transformation is using the multi-step border-radius values that allow you have more controls over the edge of the element.

Image from Medium

First I needed to read more informations about the multi step border-radius, and this css-tricks article was perfect. So i started writing code to prepare all the things but i noticed immediately that handling the multi values border radius was not so easy as I expected. After a bit of googling I came on this article and their awesome tool. This helped me to learn more about this approach and generating the values of the border-radius property.

By adding a bit of movement and colours I got what i wanted. Here you can check the final result.

Follow me to get more about CSS tricks!

https://equinsuocha.io

Smart animations with custom properties

Mattia Astorino — Tue, 16 Oct 2018 10:52:28 +0000

A few days ago I was talking with a friend about the most popular CSS libraries to integrate simple animations into a project. After a bit of research these names emerged, including the most popular Animate.css and AnimeJS:

Animate.css - https://daneden.github.io/animate.css/
Animejs - http://animejs.com/
Magic animations - https://www.minimamente.com/example/magic_animations/
Hover - http://ianlunn.github.io/Hover/
Anijs - http://anijs.github.io/

What amazed me most is that some of these libraries, especially those CSS, were introduced several years ago. Although CSS now allows us to find better results and write simpler and more efficient code, these libraries seem timeless (do you remember jQuery?) and only few people really give importance to the complexities that these bring with them once included into our project; especially if we have to take into account weight and performance. For example, a question that we should all ask ourselves, is:

Does it make sense to include the entire library if I need only 3 animations?

The answer is obviously no, and to overcome this, some people "copy" (👮🏻) the individual keyframes and use them independently from the library itself. If you use PostCSS (and you should) there is a plugin that allows you to conditionally import the keyframes you want, when you need them.

The problem

Almost all of these CSS libraries provide a set of classes to which a specific animation is assigned. So, to apply a fade from bottom animation we will add the relative class to the HTML element, then customising it through CSS:

<progress class="fadeFromBottom"></progress>

<style>
  .fadeFromBottom {
    animation-duration: 2s; /* This may require !important 👀 */
    animation-delay: 0.5s;
  }
</style>

As is easily to understand, this means that for each imported animation (for example, the direction is managed with a different class) there is a corresponding CSS class and to customise it we must overwrite the code, sometime using the !important (❗️) keyword, resulting in a not-so-much scalable code.

How can we therefore evolve this approach using today's tools?

Continue reading on:

Smart animations with custom properties - Equinsuocha.io

DEV Community: Mattia Astorino

AI skills are the new NPM packages

From code to knowledge

Why this shift matters

What this looks like in design systems

A different kind of reuse

Not without risks

Closing thought

Vira Theme: A Deep Dive into the Premium Successor of Material Theme

What is Vira Theme?

Teal

Ocean

Carbon

Palenight

Graphene

Deepforest

Exclusively Dark with Distinct Flavor

Hand‑crafted Icons & Auto‑Accent Sync

Deep Customization

Deps no thanks

FAQ

SUMMER SALES ARE HERE! 🎉

Design with the A+R model

What Happens when we combine Adaptive and Responsive design?

Responsive Design Techniques

Adaptive Design Technique

Introduction to the A + R Model

A for Adaptive

R for Responsive

Adaptive + Responsive

When to Choose This Model

Who Uses the A + R Model?

Introducing Native Elements

Features

Modern

Framework agnostic

Easy theming

Making a theme

Using themes

Global themes

Scoped themes

When to use it

More on native-elements.dev

Making dark theme switcher with PostCSS.

Why a dark theme

Better for batteries

Better for dark environments

Better for people

Preparing styles

Making the theme switcher

Where is the magic?

Bonus tip

Making Web Components for Different Contexts

The Abstraction Layers Triangle

Same technology, different contexts

Private context

Standard context

Web components and composition

Web components and accessibility

Conclusion

The Adaptive + Responsive model

Responsive Design Techniques

Introducing the A+R model

A stands for Adaptive

R stands for Responsive

Adaptive + Responsive

When to choose the A + R model

Fieldset, this stranger.

The specification

A use case

"Bad" examples from...

Twitter Bootstrap

ZURB Foundation

Material Design Components

Tailwind CSS

ckd.css for your ticks

Why are micro interactions important?

equinusocio / ckdcss

A tiny set of micro interactions for your checkboxes.

Why?