DEV Community: Barsukov Nikita

What's New in Taiga UI v5: A Modern Angular UI Kit

Barsukov Nikita — Fri, 03 Apr 2026 07:30:49 +0000

Taiga UI is an Open Source Angular UI library that helps developers build modern, reliable user interfaces. We recently shipped the fifth major release, bringing a ton of architectural improvements and new capabilities. In this article, we'll take a deep dive into the highlights of version 5.0.0 and explain why you should plan your upgrade as soon as possible.

Fresh Minimum: Angular 19+

In this new major version of our libraries, we raised the minimum supported Angular version to 19 and above. This means we can take advantage of all the new features and improvements added since Angular 16 (the minimum supported version in the previous Taiga UI major). And the paradigm shift toward a signal-based style has changed a lot in our codebase.

Signal Inputs

All our hundreds of components and directives said goodbye to classic properties decorated with @Input() and switched to their signal-based counterpart — input. Previously, our code had a lot of getters that internally used a private class method decorated with @tuiPure for memoization. Here's a simplified example of that approach:

@Input({required: true})
fileName: string;

// Used in the template
// (potentially recalculated on every re-render)
get type(): string {
   return this.getType(this.file);
}

@tuiPure
private getType(file: string): string {
   const dot = file.lastIndexOf('.');

   return dot > 0 ? file.slice(dot) : '';
}

Now, with signal-based computed, getters are no longer needed, and we can write cleaner, more readable code without extra optimizations. computed takes care of memoization automatically.

file = input.required<string>();

type = computed(() => {
   const dot = file.name.lastIndexOf('.');

   return dot > 0 ? file.name.slice(dot) : '';
});

We're sending the @tuiPure decorator off into honorable retirement: you were a good friend and helper for many years — thank you!

Signal viewChild(-ren) / contentChild(-ren)

In Taiga components, we frequently used the @ViewChild(‑ren) and @ContentChild(‑ren) decorators. You decorate a property in a component — and the requested DOM element gets automatically assigned to it. A significant limitation of this approach was that these elements only became available in the AfterViewInit and AfterContentInit lifecycle hooks. As a result, constructs like this could pop up in our codebase:

@Component(...)
export class AnyComponent {
   private contentReady$ = new ReplaySubject<boolean>(1);

   children$ = this.contentReady$.pipe(
       switchMap(() => this.childrenQuery.changes),
   )

   @ContentChildren('ref')
   childrenQuery!: QueryList<any>;

   ngAfterContentInit() {
       this.contentReady$.next(true);
   }
}

The contentReady$ stream notifies all its observers that it's safe to proceed. The trick of creating such a stream made the code slightly more declarative compared to directly manipulating all observers inside a hook. But it still produced its fair share of boilerplate.

Signal-based viewChild(-ren) and contentChild(-ren) are a real game-changer. You can practically forget about the AfterViewInit and AfterContentInit hooks, because signals created via viewChild and contentChild know when to update on their own, and all their subscribers automatically recalculate reactively. All those lines from the old approach are replaced by a single built-in one-liner.

Signals Over RxJS

Even though our team deeply respects RxJS and is confident it'll be around for a long time, we genuinely fell in love with signals. We decided to make them the priority in our public API — not just because of their growing popularity in the Angular community, but because for many reactive tasks they're a much better fit than RxJS, letting us provide better support and write more optimal, understandable code.

Here are just a few examples of changes from the new major version — the updated TUI_NUMBER_FORMAT and TUI_DATE_FORMAT.

// Before
inject(TUI_NUMBER_FORMAT) // Observable<TuiNumberFormatSettings>
inject(TUI_DATE_FORMAT) // Observable<TuiDateFormatSettings>

// After 
inject(TUI_NUMBER_FORMAT) // Signal<TuiNumberFormatSettings>
inject(TUI_DATE_FORMAT) // Signal<TuiDateFormatSettings>

To sum up the thought about the dawn of the "signal era" in the Taiga codebase: we don't resist the new trends set by the Angular team. And most importantly, we don't prevent our users from seamlessly harnessing the full power of signals when building applications with Taiga UI!

We've already seen the benefits of the signal-based style firsthand. Less boilerplate, better performance, dramatically fewer Change Detection bugs, and improved support for Zoneless applications!

New Esbuild + Vite Build Engine

Another important change driven by raising the minimum Angular version is the switch to the modern Esbuild + Vite build engine. This move not only improved our own Developer Experience (build time during local development was significantly reduced), but also allowed us to catch bugs in YOUR Esbuild applications (the default for all new Angular apps) before we even release our libraries.

And these aren't just words — we've already fixed several esbuild incompatibility bugs related to circular dependencies (#12435 and #12438), as well as CSS selector specificity issues (#12544, #12543, #12553).

Control Flow

Before Control Flow appeared, the Taiga UI team had already been publishing the structural directive *tuiLet for many years, which allowed you to declare a local variable in a template. And as our company's codebase shows, this directive was used over 6,000 times. The local variable declaration approach was extremely popular. It has now been replaced by the new built-in @let syntax.

The Taiga *tuiLet directive is now gracefully retiring, making way for the built-in @let syntax — which, as a nice bonus, requires zero imports!

A Shiny New Component Showcase

We've significantly reworked the design and content of our documentation. It now features improved navigation and a more intuitive interface.

I'd also like to remind you that the engine behind our documentation is a reusable solution published as the npm package @taiga-ui/addon-doc. It's already actively used not only for Taiga UI docs, but also in other Taiga Family products: Maskito, Taiga Editor, Ng Morph, and Ng Draw Flow. This package keeps evolving and gaining new features (for example, a brand-new Table of Contents component was added in this release). You can always use @taiga-ui/addon-doc to build documentation for your own library!

Browser Bump

Here's a little secret: the favorite part of every major release for Taiga UI maintainers is bumping the minimum supported browser versions. It unlocks new capabilities and features that we happily use in our libraries to write even cleaner and more reliable code.

Already in Taiga UI v4, we set a course for adding RTL support to our libraries. That's right — we expanded our audience to include Middle Eastern and Central Asian products!
With the new browser support, we got access to an even wider list of logical CSS properties, such as inset, padding-inline, margin-inline, and many others.

RTL support has become even easier to maintain, and the code is more robust (since it's now handled by native logical CSS properties instead of our old fallbacks and workarounds).

We also got access to BigInt. It feels nice to finally have access to all JavaScript data types — at least by 2026! :D
We immediately put this to use and added BigInt support to our @maskito/kit library in the Number mask and in our Taiga InputNumber component.

Angular Animations — Goodbye!

Starting with Angular 20.2, the @angular/animations package has been marked as deprecated. And the official Angular documentation now reads as follows:

You can replace all animations based on @angular/animations with plain CSS or JS animation libraries. Removing @angular/animations from your application can significantly reduce the size of your JavaScript bundle. Native CSS animations generally offer superior performance, as they can benefit from hardware acceleration.

And we responded promptly. In Taiga UI v5, we completely dropped the @angular/animations package: all existing animations have been rewritten using pure native CSS, and @angular/animations has been entirely removed from the dependency list of our packages! No more mandatory provideAnimations() just to get Taiga UI up and running.

The trickiest part was natively rewriting the logic around the former :leave mechanism. Currently, there's no convenient CSS alternative for animating an element leaving the DOM without timers and boilerplate code. But my colleague found an elegant solution to this problem as well. The @taiga-ui/cdk library got a new Animated directive. Just slap this directive on any DOM element — when it appears or disappears, the element gets a CSS class tui-enter / tui-leave, and you can define any CSS animations for that class. All without code boilerplate and in the true Angular way!

It's also great that we're moving in the same direction as the Angular team. The Animated directive neatly anticipated the future syntax that the Angular team introduced very recently in their v21 announcement — animate.enter and animate.leave. Migrating from our solution to the built-in Angular syntax will be as simple as it gets — just replace the tuiAnimated directive on an element with animate.enter="tui-enter" and animate.leave="tui-leave" (and keep the CSS files unchanged).

A nice bonus: our Animated directive has been cherry-picked into the fourth major version of Taiga, so you can start gradually moving away from Angular animations in your app right now — even before you begin upgrading your Taiga UI version, and even if your app's Angular version is significantly older than 20.2. And when you upgrade Taiga to v5, @angular/animations will simply disappear from your node_modules.

Simplified Taiga UI Setup for Your Project

Inspired by the modern Angular naming conventions for DI utility functions (provideRouter, provideServerRendering, provideZoneChangeDetection, etc.), we decided to simplify the process of adding Taiga UI to your project. Now, to set up the DI tree, all you need is a single call to provideTaiga(), which automatically provides all the necessary dependencies and initial configurations for our components to work.

For you, it's just one function call, but under the hood it takes care of automatic font scaling, dark/light theme setup, and other internal configurations needed for Taiga UI components to function correctly!

New Text Fields Are Now a Stable API

We kicked off the large-scale text field refactoring back in the previous major version.
At that time, we moved all our old control versions into the @taiga-ui/legacy package (to ensure a smooth migration path for users to the new public API) and started rewriting each component from scratch using fresh design specs and modern Angular features (decomposition via host directives + signals).

The task turned out to be quite challenging and extremely labor-intensive, but the results will genuinely make you happy. The new text fields offer a declarative way to customize through HTML markup and a uniform public API across all types of controls. Once you understand the customization concepts for one type of text field, you can easily customize any other control — without even looking at the docs!

Another key feature of the new text fields is their openness. Everything you need is exposed, so you can bring even the wildest ideas to life. Just take a look at this InputDate example:

<tui-textfield>
  <label tuiLabel>Choose a date</label>
  <input tuiInputDate [formControl]="control" />

  <ng-container *tuiDropdown>
    <tui-calendar [markerHandler]="markerHandler" />

    <button
      tuiButton
      (click)="..."
    >
      Today
    </button>
  </ng-container>
</tui-textfield>

First, all the input parameters of the <tui-calendar /> component are fully at our disposal — no prop drilling like in the previous version of this control! Second, we can freely add any elements (even interactive ones!) to the calendar dropdown — for example, a "Today" button with a custom click handler!

And this applies to every type of text field (and there are over 15 of them!).
With the release of the fifth major version, our large-scale text field refactoring is officially complete. Their public API is fully stabilized, and the previous generation of these controls has been permanently removed from the @taiga-ui/legacy package.

For those who prefer gradual changes in life and code, we cherry-picked all important fixes for the new text fields into the fourth major version, making the migration to the new major as smooth as possible. Before upgrading to Taiga v5, you can iteratively update your codebase, mixing old and new text fields, so the upcoming migration is as comfortable and painless as it can be.

Improved Icon Component

In the previous major release announcement, I mentioned that for icons we moved away from the old approach of using <svg /> with the <use /> tag in favor of CSS masks.

Back then, the new approach was implemented in the Icon component and brought numerous benefits: the ability to store icons on a CDN and render them without DOM manipulations or a sanitizer, automatic browser caching, and a simplified way to scale icons.

But we didn't stop there and continued to develop this further.
Starting with the fifth major version, this component can do significantly more:

You can now control not only the icon size but also the stroke width of the icon's content. This capability is demonstrated really well in this interactive documentation example.
The updated component supports not only classic single-color icons but also multi-color and font-based icons! They're managed through the @tui, @img, and @font prefixes, and the component figures out under the hood how to render the icon based on its type: via CSS mask, background-image, or font + content on the :before pseudo-element. You can see it in action in this example.

And Much More!

Portals have been completely rewritten and streamlined into a single grid-based container. It's now even easier to customize dialogs, simpler to manage notifications and their subtypes (screen position, number of simultaneous instances), and easier to create your own custom portal entities through new abstract classes and services.
A new Popout service that simplifies displaying custom content in Picture-in-Picture mode or opening a piece of your application in an entirely new tab.
We stabilized the use of the CloseWatcher web API in Taiga dialogs. Now, when a dialog is open on an Android device and the user taps the browser's "Back" button, the dialog simply closes — instead of navigating to the previous route behind the open dialog.
A revamped Accordion. We're continuing the trend (that accompanies every Taiga major version) of minimal DOM element nesting in our components, which should make it easier for you to customize them and set native attributes like ARIA attributes or id — and now the accordion has joined the ranks of the "lucky ones."
Automatic font scaling is now enabled by default. Many users rely on iOS/Android system accessibility settings to increase the font size across all interfaces on their mobile devices — including web apps. Taiga components can read this system setting and adapt, making your interfaces comfortable for users with visual impairments.
We dropped the use of our custom decorators — you're free to build your application with any value of the TypeScript experimentalDecorators flag without worrying that Taiga UI components will stop working.
We're continuing to actively develop AI tooling support for working with Taiga UI components. Our MCP server now supports the new major version as well. We're also closely watching the development of WebMCP to integrate its support into our documentation when the time comes.

And a huge number of other improvements and new features that you can find in the release notes.

How to Upgrade?

We did our best to make the migration to the new version as smooth as possible. To that end, we've prepared a bunch of migration scripts that will automatically analyze your code and fix most breaking changes — all with a single console command! And anything that was too complex to fix automatically via AST manipulations has been annotated with comments right in the code — complete with hints and links so you can easily finish the migration on your own or with the help of AI agents.

Detailed instructions for running the migration schematics and the necessary preparation steps are available in our upgrade guide.

If you run into any issues or bugs during the upgrade, don't hesitate to open an issue or ask a question in our Telegram community. The Taiga team can't wait for your feedback!

See You Soon!

To wrap up, let me just give you a little sneak peek at our future plans.

Very soon you'll see revamped date picker components — our design team has already delivered fresh design specs with a more modern look for the calendars. During the rework, we plan to address the accumulated feature requests around their customization.

We're also keeping a close eye on the development of signal-based forms. As of this writing, the new API is still rough around the edges and continues to undergo changes. As soon as it fully stabilizes, we'll make sure Taiga controls support them.

Finally, one of our big goals for this year is to keep pushing the accessibility of our components forward! All Taiga components traditionally support keyboard navigation, screen readers, and other assistive technologies, but accessibility is a broader topic and we plan to dedicate even more attention to it this year.

See you in upcoming articles and releases!

And a reminder: the easiest way to say thank you is to give us a star on GitHub.

Taiga UI: Year of the Tiger

Barsukov Nikita — Thu, 22 Dec 2022 10:00:37 +0000

The year 2022 was extremely fruitful for our Taiga UI team and, what is more important, we picked up tiger speed in terms of updates and improvements of the library. Within this article, I would like to develop a habit of annual reports about the progress, which might be handy for us to recollect all achievements and failures in order to adjust our strategy for the upcoming years.

If you aren’t acquainted with Taiga and randomly stumbled upon this text, let me introduce Taiga UI — a powerful set of components for Angular, which is used in dozens of Tinkoff’s products and projects! In the following sections I will briefly unpack the overall achievements related to this multifaceted library.

One more year in Open Source

The development of the library has been going on for several years, two of which are in Open Source. We are happy to share our product with the community, and the source code is publically available. Despite the naming, we do not want to be the only people in our forest, hence we eagerly invite everyone else to join the development of the UI Kit!

Alex Inkin has already summed up the project’s results for the first year in Open Source. He described how we organized all processes so that the community could easily contribute to our project. Read more details about our last year's achievements in the article:

Taiga UI: A year in Open Source

Alex Inkin for Angular ・ Dec 24 '21

#angular #opensource #typescript #javascript

The Taiga UI library has a core team that hones and polishes the project's codebase. However, an impressive amount of the improvements come from external contributors. By the end of 2022, their number exceeded a hundred people! Our library is used by a variety of companies from various countries: most oftenly documentation is accessed from Russia, Vietnam, Belarus, USA, India and France. The geography of our users is pretty impressive!

In 2022, external contributors opened over two hundred Pull Requests, which is ~ 15% of all opened PRs for the entire year. Thank you very much to all our contributors for such an active participation in the project!

In October, it was a time for an international online festival devoted to Open Source — Hacktoberfest. Obviously, to stay in the loop and showcase our offspring, the team prepared Taiga UI for participation in this event.

One more major release

In the last days of summer, we introduced the third major release of the library.

We tried to postpone the introduction of breaking changes to our components as much as possible in order to cause little hassle to Taiga UI users. When there was a need to refactor the code and somehow change the public API of the components, we always keeped backward compatibility with the old interfaces.

Long-term efforts to maintain backward compatibility of the product have their costs — there is more and more legacy code, which increases the bundle of product applications. Another reason why breaking changes cannot be avoided is that it is getting harder to maintain the code with every new day. Sooner or later the moment of great changes comes.

More than a year and a half has passed since the last major release 2.0, and we decided that the moment had come. We were preparing the new release for the whole summer. The list of changes within the new version is enormous, and not to kill the vibe of the article, I will highlight the most curious ones:

Angular update. The Angular framework has a rule: if a library is published under any of the older versions of Angular, then it can be used in applications with more modern versions of the framework without problems. But not vice versa! If the library was published under a modern version of Angular (for example, 14.x.x), then it will no longer be possible to use it in applications with an older version of the framework (in our example, this is 13.x.x and less).

In Tinkoff, a plethora of projects use Taiga UI. Some of them use only the most modern versions of all technologies. However, there are some projects with a lower priority which can’t be updated so frequently and don’t use the most up-to-date versions of Angular.

Therefore, we were postponing the increasing the threshold of the minimum supported version of Angular and all this time Taiga UI used the 9th-version and published with the ViewEngine legacy engine. But in 3.0, we bumped Angular to the 12th version and also began publishing using the modern Ivy engine! Now users of our library can finally experience all the benefits of a modern engine.

Dropped support for ancient browsers. Every front-end developer knows what a great feeling that is! We already weren’t supporting Internet Explorer for a long time, but now it's time for those versions of Edge that are based on the ancient EdgeHTML engine. Maintenance for these browsers was extremely cumbersome, so it was more efficient to cut them off, than to keep them alive, and moreover, the demand for these browsers wasn’t there — the number of users is measured in tenths of a percent.

In addition, we bumped the minimum threshold for support for the problematic Safari browser — now it's 12.1+. If the benefit of these solutions is obvious to Taiga UI developers, is it good for our library users?

Definitely yes. Now during development we can use modern browser capabilities, introduce less extra code as polyfills, and drop many different workarounds from the code that existed only for outdated browsers. Our code occupies less storage and is much more stable!

Global styles have become optional. In the third version of Taiga UI, all global styles were moved into a separate package and became optional in usage. Taiga UI has become even more flexible!

Huge component refactoring. The new major release provides us with an opportunity to discard a large number of legacy components’ API and introduce a new one.

In 3.0, many old components got a fresh appearance — after refactoring they became more convenient to use and easier to maintain. The most remarkable examples are the Editor, InputFiles, all components with dropdowns and hints, and all components with sliders. You can read more about the latter in the article:

Sliders are like onions: three gradient layers of a single slider

Barsukov Nikita for Angular ・ Jul 5 '22

#angular #typescript #javascript #webdev

Migration schematics. The process of updating major versions of any dependencies is always a big headache for product teams. Firstly, developers need to figure out what needs to be changed in the code. Moreover, such updates require a complete regression of applications.

We desire that all teams migrate to up-to-date versions as soon as possible, so we paid great attention to the migration schematics to eliminate at least some of their concerns. Developer who has the second version of Taiga UI in their application just need to write ng update @taiga-ui/cdk in the console to update all Taiga UI packages to the third version. It will solve most of the breaking changes. Such schematic scripts automatically go through all HTML, TypeScript and style project files, find outdated API in it and replace it with a new alternative.

If you want to know more details about this major release, visit the page with its Changelog.

More outstanding features

Beside the new major release, our Taiga UI has been permanently improving. During the whole year, more than 500 issues and more than 1500 Pull Requests have been closed. The tasks were rather all over the place, I will tell you about the main directions.

Localization. Internationalization and localization of our libraries are very important to us. From the very get-go, Taiga UI has supported several languages, and thanks to the active help of the community, support has expanded to 13 languages by the end of 2022. For the convenience of their dynamic switching at runtime, we have added some utilities. Nevertheless, translation only is not enough, countries have much more distinctive features.

At the end of 2021, we set goals to expand the i18n of the product and added support for rtl‑languages for most inputs. Hands down, it wasn’t enough for us, so we continued to expand our localization capabilities in 2022. Now users of our library can set the desired date format, the first day of week (Sunday, Monday, or another day), which days in the calendar should be marked as holidays/weekends, the format for displaying numbers, and other important little things – the devil is in the details, and Taiga UI is all about nuances and tiny aspects!

More component customization. Many people love Angular for its flexible and convenient implementation of the Dependency Injection pattern. We try to use all power of DI in Taiga UI. We use Injection Tokens to customize the default behavior for the majority of our components. Such tokens have a naming consisting of the name of the component + the OPTIONS postfix (for example, TUI_EDITOR_OPTIONS). In 2022, the list of such available tokens has expanded significantly.

Projecting native outputs inside components. In early 2022, we added the ability to project native inputs via <ng-content /> inside Taiga UI input components. The concept is described in more detail in the "Best practices" section of the official Angular documentation.

Let's see an example. Previously, to create an Input with a placeholder and a specific type, you had to use this code:

<tui-input
    formControlName="email"
    tuiTextfieldType="email"
    tuiTextfieldExampleText="mail@mail.ru"
>
    Type an email
</tui-input>

And now you can do it like this:

<tui-input formControlName="email">
    Type an email
    <input
        tuiTextfield
        placeholder="mail@mail.ru"
        type="email"
    />
</tui-input>

Now users can set any available attribute on input and listen to any native event! For the user of our library, everything has become even more transparent. No more need to remember the names of our custom directives and find out which native attributes they map to. All this allowed us to drop a lot of unnecessary code from the TextfieldController.

Custom notifications. We have significantly refactored services for displaying notifications. Now the created abstractions make it easy to create custom notifications and use several types of notifications in the same project. The new Push component is a good demonstration of this new feature.

Improvements for Editor. All year we have been improving our new WYSIWYG, which is based on Tiptap's Open Source solution. Here is a full list of new useful extensions:

Accordion support. Now you can add collapsible content.
We added tools to create and edit anchor links.
Users can now create nested groups/blocks. And also make them draggable.
Our editor has image support: the user can upload an image, resize it, and control its position in the text. And now it is possible to add previews of uploaded images.
Dark Mode support.
Stabilization of editing tables.

Component Harnesses. With the help of the community, we began to actively develop a package for testing components with Harness. The first release of this package happened at the end of December.

Improving processes and DX. In addition to permanently improving the codebase, we are also trying to improve the process of its development. It is important for us that all members of the core team and all external contributors have a high level of Developer Experience. After all, the more comfortable the conditions for the developer, the faster the delivery of new features. In 2022, we achieved new successes in this direction:

We changed the test framework for unit testing: from Jasmine + Karma to Jest. Now it takes only a few seconds to prepare the test environment before running tests. Moreover, the failed tests generate more comprehensive reports. For integration and screenshot testing, we use the 11th version of Cypress, which allows us to test our components using the real DOM.
We solved the problem of long execution of tests. We have splitted all tests into many separate parallel Github-jobs: now, when opening a PR, 14 jobs with Cypress tests and 12 jobs with unit tests are launched.
We use the npm 8 features and workspaces.
We began to actively use Github Projects for planning and tracking tasks.
We added BundleMon and Codecov bots that allow you to control changes of the packages’ bundle-size and the code coverage by tests.

Stackblitz workflow. At the end of the year, we added the integration of our repository with a new feature from the StackBlitz team - Codeflow. Now our external contributors do not need to have a powerful computer with a pre-installed IDE. Now the developer can just click on the button from our root README:

And inside the browser an online IDE will be opened where you can serve demo application and open new PR. Now it becomes easier to contribute to Taiga UI!

Wrapping up

The year was rather challenging, but the Taiga UI team continues to develop the product. For the last several years we have achieved significant results, and much more is to come! It should be noted that the success of the library is partly attributed to the community, so, once again, thanks a lot for joining us in this adventure across the dense forest of Taiga!

If you still did not get aboard, we can ensure you that by choosing our library for your projects, you will get a convenient and modern UI Kit with the confidence that support and development will not suddenly stop, not only because Taiga UI is actively used in hundreds of products of our company, but also because we do care about the faith of project and its community.

Do you want to try it? Just write in console and enter the Taiga UI:

ng add taiga-ui

See you there!

Sliders are like onions: three gradient layers of a single slider

Barsukov Nikita — Tue, 05 Jul 2022 14:59:22 +0000

Our library Taiga UI contains hundreds of useful components, directives, and services. The code maintainability is a pivotal issue for our UI Kit library. That is why we always try to write as little code as possible and look for native solutions.

In the article, I will tell you about such example – the development of Angular-component Slider using built-in browser tools and as few lines of JavaScript as possible. You will read about accessibility, an interesting solution with multi-layer gradient background, and even a bit about Change Detection in Angular.

It cannot be this hard, right?

We have a task to develop a UI-element which helps users to select a number from an ordered range. Input consists of two parts:

thumb – the interactive element of the input. Users can move it horizontally to increase or decrease the selected number
track – the space along which the thumb moves

At first glance, the task seems simple. Listen to MouseMove / TouchMove events, calculate the distance how far from the beginning of the track they occurred, move the slider to there, and, finally, provide the user with a numerical value.

It could even mistakenly seem that there is no sense in devoting the article to this subject because of its simplicity. However, we have to look into all the in-depth details before making such a conclusion. Let’s kick it off by getting acquainted with W3C documentation.

W3C is a worldwide organization that maintains standards for the development of web applications and its primary goal is to make the Web accessible and understandable. To make things less abstract, imagine that one visits a website and opens a modal dialog. Which keyboard key would you intuitively like to press to close this dialog? It is an Esc button. In this sense, if a web application is developed by an experienced team, then the popup will close when you press this key.

This example illustrates one the W3C principles, let’s dive deeper into W3C guidelines about sliders:

Keyboard navigation. Pressed ArrowUp/ArrowDown and ArrowRight/ArrowLeft keys should increase/decrease (respectively) the value of the slider by one step. Pressing Home/End should set the slider to the first/last allowed value in its range. Also, there are recommendations about keys PageUp/PageDown: they should increase/decrease the slider value by an amount larger than the step change made by ArrowUp/ArrowDown. If you develop your own slider, you should be ready to write 8 event handlers for the mentioned keys with different behaviors.

Accessibility. Any website can be used by people with disabilities, for instance, a user may experience issues using the keyboard and mouse. In such cases, voice-recognition and other assistive technologies are used. The user pronounces to the computer what it should do on the screen, however, for that the website should be correctly marked up.

Moving back to our task, let’s see the requirements for an accessible slider:

The element serving as the focusable slider control has role="slider"
The slider element has the aria-valuenow property set to the current value of the slider
The slider element has the aria-valuemin / aria-valuemax property set to the minimum/maximum allowed value of the slider
If the value of aria-valuenow is not user-friendly, the aria-valuetext property is set to a string that makes the slider value understandable. A simple example from the W3C’s documentation: if you decide to use a slider to select the days of the week (from the first to the seventh), don't forget to provide the slider with a text description of the selected value (e.g., "Monday")
Finally, we should always keep aria-label in mind!

Possibility to configure the slider step. For instance, a developer can restrict to selecting only integer values. Also, they may allow the user to input values with 0.0001-precision.

Considering all the nuances and accessibility principles might be perceived as tons of extra work, that is why everything is not as simple as it might seem at first glance.

But the browser has already done it! There is a built-in <input type="range" /> slider that follows all mentioned standards. It is not surprising to anyone that such a built-in solution is not fancy, and even looks different in each browser. Therefore, I will show you how to customize the built-in slider to one’s needs to ensure cross-browser support.

We will write the component for Angular. But the solution contains so little Javascript code that you can easily transfer it to your favorite framework.

Anatomy of `<input type="range" />`

If you enable the shadow DOM in your DevTools (e.g., in Chrome’s settings, one can find option “Show user agent shadow DOM”), you can notice that the built-in <input type="range" /> is not a single tag. It contains other tags inside (but we did not add them!). Also, the internal structure of nested tags may vary in different browsers. Somewhere you can find a flat structure with 3 div-containers, and somewhere – additional depth of the structure.

Each browser engine has a different approach to writing its own slider, so they all have a different structure. But the basic concepts are the same: there is always a tag with a slider track and a container with a thumb. You just need to know how to access these nested tags.

You can't access the HTML tags inside an <input /> via combinator CSS selector (for instance, input[type="range"] > div). All slider markup is encapsulated inside the shadow DOM and is not accessible from the outside. But browsers provide API (pseudo-classes) via which you can reach the necessary tags.

All browsers with the WebKit/Blink engines (e.g., Safari and Chrome) have this anatomy:

Firefox gives more opportunities for customization: besides the pseudo-classes for the track and the thumb, there is an additional pseudo-class to customize the progress indicator of the slider.

That's all you need to know to write your own simple slider. However, if you need more flexibility, something more complex than tag coloring, you will face some problems. I'll tell you about possible problems and how to deal with them.

This’ll be fun: writing a basic slider

Firstly, let's use previous information to customize the basic version of our slider.

Declare some less-variables for self-documentation of the code:

Declare less-mixin to customize track of the slider. It will be simple for now, but it will be considerably extended in the following sections.

We also need mixin to customize the thumb of the slider:

If you don't quite understand how the &-symbol works, I advise you to read this Less-documentation section.

Finally, let’s create a special mixin only for webkit browsers. We need it if the slider’s thumb is larger/smaller than the height of the slider track. Webkit browsers don’t align it to the center. Multiple ways to vertically center the content won't help here, but the problem can be solved in this way:

Now you can create an Angular–component. Our component has no additional layout, but it has an attribute selector with the native element <input type="range" />. Using attribute selector is a good practice to augment the behavior of native elements. Official Angular documentation claims: "When authoring Angular components, you should re-use these native elements directly when possible, rather than re-implementing well-supported behaviors". You can find many such examples in our Taiga UI library.

The component uses a change-detection strategy OnPush. If you don’t know it or hesitate to use it, I recommend reading the article of my colleague:

OnPush — your new Default | by Alex Inkin | AngularWave

Alexander Inkin ・ Aug 5, 2021 ・
Medium

Typescript-file of our component contains:

Our component's selector forces the user to specify the input type (type="range"). You could suggest improving the developer experience and set this static property through host-property in the component's metadata. But unfortunately, this breaks the logic of the built-in controlValueAccessor from the Angular team, which is applied via the input[type=range] CSS selector.

In the Less file, we apply all previously created mixins to the :host – selector (just a reminder: in this case, it is <input type="range" />– element):

Voilà! We have got a basic cross-browser solution for customizing the built-in slider. But there are more nuances that are currently overlooked.

Webkit customization problems with the progress of the slider

Firefox takes care of the developer's desire to customize the progress indicator of the slider – the moz-range-progress pseudo-class. Unfortunately, there is no such functionality for WebKit/Blink browsers. But linear gradients can solve this problem.

Previously, we just filled the entire slider track in gray. And now, we will fill part of the track in the color of progress, and leave the rest of it gray.

We add some simple math to the class of the component. It will calculate how many percents the slider are filled, and save this value to the --slider-fill-percentage CSS-variable:

Now, we need to improve the previously created mixin customize-track:

Let's try the resulting component in action:

<input type="range" tuiSlider value="30" />

We're using changeDetectionStrategy.OnPush, so it's expected that the slider doesn’t recalculate the value of the --slider-fill-percentage CSS-variable while the user moves the slider's thumb. We need to tell Angular when to run the change detection. Achieving this is simple: we need to trigger change detection when the InputEvent fires. We set an empty event handler in the component metadata:

Now, the value of the --slider-fill-percentage CSS-variable is recalculated when the user interacts with the slider.

One problem less, and now our slider is completely identical in all modern browsers.

Adding ticks via multi-layer gradient

We have a working solution. Let's imagine that we wanted to use a slider with the following combination of native attributes:

<input type="range" tuiSlider min="0" max="100" step="20"/>

This combination means that the user can only move the slider by a step that is a multiple of 20. Users can only select five values in the range, or in other words, the slider consists of five segments. A popular practice for such a case is to highlight segments visually through ticks/marks on the slider track.

We can try to achieve this via additional (pseudo-)elements inside the input. But only webkit browsers support this behavior, because it's not a commonly accepted standard. Another option is to try to implement the ticks through a gradient, but in the last chapter, a gradient was already used to implement a progress indicator for webkit browsers (so the place seems to be already taken).

No worries! There is a solution: gradients can be stacked on each other in several layers. We can create a new layer using repeating-linear-gradient and apply it on top of the previous one.

Firstly, let's add these lines to the component code:

We have added new input-property segments, with which the developer can set the number of visual segments to be shown on the slider track. And the new getter of the component performs a simple math operation – it calculates how many percent of the total length each segment should occupy and saves the result in the --slider-segment-width CSS-variable.

It remains to upgrade the .customize-track() mixin. To apply several gradient layers to the same background, just separate them by commas in the background-image property. For example:

The main thing is not to get confused in what order the layers stack on each other. The first specified gradient will be layered on top of all others, and the last one will become the bottom layer of the background. In other words, the stacking of layers on top of each other begins at the end of the list enumeration.

All other background-* properties have a similar behavior. You can specify only one set of parameters for all layers, or you can list the parameters separated by commas (in the same order as in the background-image property) to set your own values for each layer.

Upgraded version of mixin customize-track:

An important feature of native sliders is that when the user moves the thumb to the start/end of the track, the thumb touches the end of the track not with its center, but with its edge. So, the thumb of the slider never goes beyond the visual boundaries of the slider track. Therefore, the first mark does not start at the very beginning of the track, but with a shift, which allows it to be in the center of the thumb (when it is in the leftmost position), and also correctly places the rest of the marks.

In addition to the background-image layers, we also set a value for background-color. The logic here is as follows: background-color acts as the last fallback layer. The entire surface of the track, which is not covered by any of the layers, will be filled in the color of this property’s value.

That's all. This solution is a good illustration of how sometimes a frontend-task can be solved without additional nested HTML tags.

Wrapping up

I reproduced the final version of the slider in StackBlitz example:

In the Taiga UI library, we use exactly the same solution with minor improvements. On the showcase of the Slider component, you can see examples of its usage.

It is not always necessary to invent your own solutions – sometimes, we can re-use native alternatives with little modifications. When you ignore a built-in solution, you expand your codebase, increasing the complexity of its support. No wonder one modern wisdom says: the code easiest to maintain is the code that was never written.

DEV Community: Barsukov Nikita

What's New in Taiga UI v5: A Modern Angular UI Kit

Fresh Minimum: Angular 19+

Signal Inputs

Signal viewChild(-ren) / contentChild(-ren)

Signals Over RxJS

New Esbuild + Vite Build Engine

Control Flow

A Shiny New Component Showcase

Browser Bump

Angular Animations — Goodbye!

Simplified Taiga UI Setup for Your Project

New Text Fields Are Now a Stable API

Improved Icon Component

And Much More!

How to Upgrade?

See You Soon!

Taiga UI: Year of the Tiger

One more year in Open Source

Taiga UI: A year in Open Source

Alex Inkin for Angular ・ Dec 24 '21

One more major release

Sliders are like onions: three gradient layers of a single slider

Barsukov Nikita for Angular ・ Jul 5 '22

More outstanding features

Wrapping up

Sliders are like onions: three gradient layers of a single slider

It cannot be this hard, right?

Anatomy of <input type="range" />

This’ll be fun: writing a basic slider

OnPush — your new Default | by Alex Inkin | AngularWave

Alexander Inkin ・ Aug 5, 2021 ・ Medium

Webkit customization problems with the progress of the slider

Adding ticks via multi-layer gradient

Wrapping up

Anatomy of `<input type="range" />`

Alexander Inkin ・ Aug 5, 2021 ・
Medium