Interactive elements – the building blocks of websites and applications – share the same illusory property. If you look at any of them sites , Repositories, social media posts, and blogs on the 'checklist' might give the impression that everything is just an arrangement of frames, icons, and text. This would lose most of the complexity.

In this post (part 1) I will show some examples of the divergence between how code and visual design tools treat interactive elements and components in general.

Interestingly, the root of the problem often remains hidden from both designers and developers, only becoming apparent when you try to compare and communicate about it. This post is an example of such an effort.

Simple, but with peculiarities.

As an example, let's look at three very simple elements — a checkbox, an option button, and a selector switch:

Since the web version of all these elements was created at the very beginning of the web itself, over 30 years ago, there were many standards that were decided upon for general use, so even today, if you want to style a checkbox or an end-to-end radio button in a custom way that differs greatly from browser standards, you would have to do some surprising things:

1. You would need to use a container (usually one to house everything you want to activate).
2. To hide the actual default appearance of [input-type=radio] from users, you may be forced to do one of two things: reduce the opacity and size to 0 when you need to create a new div with content instead of the actual input; or in simpler cases use 'appearance: none' (the appearance property controls the default style set of browsers on different operating systems Chrome/Firefox, macOS/Windows will affect it) if you only need to reshape the input itself (this may be sufficient for radio buttons, but not checkboxes).
3. Restyle if you're using 'appearance:none' or recreate the desired design with a div and a custom icon.

Only then will your design be branded, personalized, and persistent across all devices, browsers, and operating systems. You would have to use the input node itself only for its embedded functionality that browsers automatically recognize and allow the user to interact with.

It's even less trivial to use toggle buttons, since they don't exist as an independent web element. Using practically the same hiding tactics – every time you toggled something online, you pressed a hidden [input-type=checkbox] inside. Yes, all the options are, in fact, checkboxes redesigned with respect to the browser.

The states of these basic elements are specific and are incorporated into the functionality of the web itself (checked/unchecked). Their names are defined and permanent and are not variants of the same checkbox, as would be the size and color.

Compare this to how a designer approaches these 3 elements in a vector-based design tool. What is a checkbox visually? A frame with an icon. The different states are just variants, indistinguishable from other potential visual variants. To add labels and auxiliary text, you probably want to group them in a frame, use the 2-stage auto-layout, and you're done.

An option button is even easier — you don't even need a vector icon inside, just the border.

A toggle switch doesn't have an internal checkbox, just a toggle frame and a button. You can forget about states like focus and off, and most designers forget to include the 'indeterminate' state when designing them.

There are even more complications: for the actual product code, you would really have to decide what is placed inside or outside the container , as this will affect where the actual 'click' will affect the state of the checkbox/radio box/toggle so that the layout itself is guided by functionality, not by how comfortable it is to express something using automatic layout..

In our example here, it's more convenient to place the label and the auxiliary text in the same frame, but in terms of functionality you may not want your auxiliary text to also trigger the checkbox state, so you'll have to rearrange the layout to transform the auxiliary text into a checkbox and therefore not affect the selection..

It usually happens that a designer structures the element. which makes sense in a visual design tool. and then delivers the designs to the developers. The developers will likely look at the final visual result, inspect the measurements, download relevant assets if necessary, look at the layer structure, see what is not useful to them, disregard it and create their own correct structure and try their best to make it visually identical.

More complex – more problems!

To customize the style of any element that is a bit more complex, such as a select, You would have to hide many more native HTML nodes to style your own instead of them, and you can't get away with just CSS; you would have to employ JS to make it work. You also need to be careful with a number of interaction design decisions, such as how the options box will be positioned on top of the select itself, what the condition would be when it flips if it couldn't be opened to the default side, whether it's a single or multiple selection dropdown menu, how it's sorted, what the autocomplete looks like, whether the box automatically focuses on some condition, whether the options box has a maximum height or number of items, etc.

And it's not just me saying this; take a look at this quote from Mozilla's MDN web documentation (which is probably one of the most comprehensive and reliable sources documenting web platform technologies and is open source and collaborative). In the section '‘ Style with CSS ‘from the page selected .[Emphasis mine]:

O The `<div>` element is notoriously difficult to style productively with CSS. You can affect certain aspects like any other element – for example, manipulating the... box model , a source displayed , etc., and you can use the appearanceproperty to remove the default system appearance.However, these properties do not produce a consistent result across all browsers, and it is difficult to do things like align different types of form elements with each other in a column. The internal structure of the element It is complex and difficult to control.

Compare this to how a designer typically treats checkboxes in design tool systems? Just a frame with text in a few variants to specify states (interactive, open, closed) and visual variants (size, style, importance perhaps). Designers will compose the checkbox as a simple frame of another 'option' component with various states – and that's it. It's all pretty much 'what you see is what you get' here.

How do we actually define an element?

The taxonomy of web elements is not completely resolved. There are many common components that were invented long after the web began, so they haven't managed to secure a very well-defined place in it. w3c list of HTML element tags .

Unlike input-type elements, such as text input, checkboxes, etc., think of more complicated things like a time picker, date picker components, or even a wizard or carousel. Definitely components, complex, but are they elements? If so – why? If not, on what basis? I mean, it's easy to draw an arbitrary boundary wherever we want, but the point here is that we don't want that boundary to be arbitrary, as much as possible.

To try and draw a more precise line on this – perhaps I need to call on Brad Frost to remind us of atomic design :

If atoms are the basic building blocks of matter, then... The atoms of our interfaces serve as the fundamental building blocks that make up all of our user interfaces. .These atoms include basic HTML elements , such as form labels, entries, buttons, and others that cannot be broken down without losing functionality.

Note the rule – “it cannot be subdivided further.” without ceasing to be functional ”"That's Brad's rule, to be elementary enough. The question that can be misleading here is what constitutes a..." function here?

If we take a date selector – I can easily split it into a bunch of buttons, a carousel to switch between months, so that should disqualify it from being an element – but the function of a date selector is... to register a date, or a date range, in the system , and that it will be interrupted If you start separating the date selector component, then if we allow treating elements not as nouns but as verbs, an element becomes – the minimum necessary to execute that verb, that function that defines it.

For these reasons, a date selector is actually an element, and the mind-boggling realization is that an element can contain other elements, if they are simpler!

Furthermore, by examining the HTML tags themselves, you'll see that it's always been this way. What is a tag?

An unordered list—one element. And what's always inside it?
• — List items. Other elements. So, elements within elements, from the very beginning of the web.

  Like oil and water?

  All these differences are just a small example illustrating why, to begin with, it was basically a fraudulent game. Design tools developed to optimize intuitive expressiveness , ease of ad-hoc manipulation, even at the cost of control, robust modularity, and binding rules that mimic web standards. HTML, CSS, and later React and other JS frameworks developed to achieve effective methods – sometimes customized and sometimes generic – to express elements and manipulate them as needed .These are completely different properties to optimize, so it's no wonder that these distinct evolutionary processes have produced very different ways of rendering the structure of interactive elements.

  The more I delve into this, the simple fact that we managed to deliver projects and build something worthwhile with such initial conditions – it seems more and more like a small miracle to me!

The 'Delta debt'‘

At this point, you might be thinking to yourself – so what's the problem – isn't that the developers' job? Well, of course it is, but it's precisely at this point that the components start to diverge between design and development. And this is a huge problem on a massive scale because if you have more than 30 elementary components and more than 60 complex components in your design system, and most of them aren't really synchronized with the code at the level of what each layer represents – when you start implementing big changes, using tokens and perhaps accessibility decisions (what is clicked and triggers the interaction, what area of impact, what is focusable and how, etc.) a nasty debt starts to build up. I call this "Delta debt." You know what I'm talking about if you're a product designer with a few years of experience.

This little 'let go' when you do your visual quality control, the test/production versions don't map 1:1 with the design, and when you ask the developers – you get a 'that's how browsers render things, it's not up to me, and making a custom patch is dangerous and will hurt our speed, didn't you want this other feature?' or maybe something more intriguing like 'what do you mean by it's exactly according to your specifications, down to the pixel, I followed Figma perfectly'.

So you make a tactical move and give up, promising yourself you'll let it go; it's probably just you and your keen eye for design details that this thing is bothering you. We have more important things to do now, and you'll know that later when there's more time. Unfortunately, there will never be more time. Just more misaligned components.

And so this 'Delta debt' only grows with time, and like death by a thousand cuts – you increase your own dissatisfaction with the appearance and behavior of the actual product and prefer to return to your beloved, immaculate, and perfect design files, where your eyes are protected from this irritation. Sometimes, the inertia is so strong that there is nothing you can say that will convince stakeholders that this debt has to be paid. The only thing you promise yourself is that, whether it's the rebranding or the next project, you will be more assertive from the start to ensure that the design and the product are exactly aligned. Only for the same cycle to repeat itself again.

Although frequent, this problem can perhaps be avoided. And I see two paths that can help fill this gap. One—is easy to explain, but difficult to do in practice; the other—is more difficult to explain, but can solve the problem as a byproduct.

Possible paths to a solution.

1st path

Improve communication to a level where there are no silo problems; the designer and developer pass a 'hot potato' of a task far too often, until they both have a very similar mental model of what the design should look like, how it should behave, how it should be built, and perhaps how to animate it. This is probably the most frequent advice you see people give in podcast interviews about their success (of course), well-intentioned and inspiring talks on stage, and various YouTube videos. Unfortunately, what is easy to do to say It is terribly difficult to to do .Maintaining cohesive communication requires effort and friction, the fruits of which you don't always feel so vividly, and in a constantly optimized and measured work environment—that's the first thing to suffer. Especially as startups grow and expand, moving from a single room to spanning continents and time zones.

2nd path

Build tools and processes for designers and developers that will make it much more difficult. not to be On the same page. Suppose a design tool is made of real elements, with an already existing and verified structure, supported by underlying code. You mostly see web builders doing this today, like Webflow and Framer. When you use an element as a checkbox in those applications, it's a real, functional checkbox. Unfortunately, there's no developer to hand it all off to, because builders primarily cater to teams where one designer can handle the entire project end-to-end, without needing a developer in the loop. Now, imagine something like that for general product design, web applications, native apps, etc. Massive products that can't be solved by just one talented designer, but actually have a ton of business logic, state management, and back-end data to handle. Products that require many front-end and back-end developers. Most products for SaaS startups are like that today.

So, imagine that all these teams use a design + code process and a set of tools that, from the outset, encourages them to use pre-existing elements and style them as they wish, and then send the result to front-end developers who don't need to rebuild everything from scratch, but prefer to connect everything with extra non-trivial logic (in their own beloved IDE) and use it together with the back-end engineers.

When I think about the best product design, it's always better to prevent a problem than to try to deal with its consequences. It would come as no surprise that I prefer the latter approach.

Summary

It's a difficult problem to solve. And if you zoom out and look at the product design tools and methods industry from above, you'll see that, over time, there's been a growing thirst on the part of designers to fill this gap. That's why you see a plethora of plugins for Figma and Sketch that help 'translate' (guess) your visually optimized designs into some form of usable code. That's why design tools are increasingly adopting features and mechanics that resemble code capabilities (such as variables that can reference other variables, component APIs through the use of properties and variant groups, automatic layout and absolute positioning within it, text truncation, logical conditionals, etc.).

Some people believe it's still just a matter of communication skills, and the tools themselves don't matter; some believe that artificial intelligence embedded in design tools will help sprinkle some fairy dust on this problem and help designers cross this chasm; and some, like myself – believe it's just a matter of building better tools.

Meanwhile, the more we learn about the different peculiarities of each element in real, living products, the easier it becomes to fill that gap.

Here is a list of useful places where you can learn and delve into the details of the different interactive elements and improve your transfer:

Radix UI is a great repository of headless UI to use and explore.

The component gallery is a vast repository of components linked to their respective pages in various popular design systems.

This is a fantastically profound disambiguation of what people like to call a 'drop-down list'.

Of course, the most complete and reliable list of all HTML elements can be found on the MDN website.

Small but useful repository of real components — Headless UI

‘Brad Frost's 'Atomic Design' and general blog

Old but golden, there's 'The Web's Grain' by Frank Chimero, which delves into what the web naturally encourages you to do.

A very comprehensive guide on what one must not forget When preparing to hand off projects to developers. In my ideal world – most of this would be unnecessary, but until then – read on!

And this is an inspiring and informative article on how to structure communication so well that the transfer becomes almost risk-free. (However, good luck actually implementing this).

An excellent and growing list of researched components, with many details and links on how major design systems utilize them.