Modern Web Magic: Building Sophisticated UI with Less Code

For too long, we have treated the browser as a mere runtime for our frameworks rather than a powerful UI engine in its own right. Frontend development has historically been plagued by two persistent headaches: “JavaScript fatigue” and “specificity hell.” We have grown accustomed to reaching for heavy third-party libraries to handle even the simplest UI patterns, such as modals or accordions, leading to bloated bundles and fragile codebases. Simultaneously, managing large CSS files frequently results in a constant battle against selector specificity, where every new style requires an increasingly complex selector to take effect.

However, the web platform has undergone a quiet revolution. Modern browsers have evolved to handle sophisticated UI patterns natively, moving logic that once required hundreds of lines of JavaScript directly into the HTML and CSS specifications. This shift toward “Platform-First Engineering” allows us to build faster, more accessible, and more resilient interfaces.

This guide is designed for beginner web developers looking to write cleaner code and senior-minded engineers aiming to reduce their technical debt. By embracing a native-first approach, we can modernise our workflow and significantly reduce the weight of our projects.

Writing DRY (Don’t Repeat Yourself) CSS has traditionally been difficult when dealing with shared styles across different sections of a site. The :is() and :where() pseudo-classes solve this by allowing us to group selectors into a single, manageable list.

A significant advantage of these selectors is the “forgiving selector list” nature of :is(). In traditional CSS, if a single selector in a comma-separated list is invalid, the browser discards the entire block of styles. Consider vendor-prefixed pseudo-elements: to style a fullscreen element in Chrome and Firefox, you need :fullscreen, but in Safari, you need :-webkit-full-screen. If you put those together in a standard list, most browsers will see the “invalid” prefixed version and ignore the whole rule. When using :is(:fullscreen, :-webkit-full-screen), the browser simply ignores the parts it does not recognise and applies the styles to the rest.

The :where() pseudo-class is a particular game-changer for CSS resets and UI libraries. While it functions identically to :is(), it has a specificity score of exactly (0,0,0). This allows library authors to provide default styles that users can easily override with a single class, without having to escalate a specificity war.

As specificity management remains a core challenge, consider this insight:

“The more you add to a CSS selector, the more precise it is, but also, the more specific it is, so the harder it will be to overwrite styles if you need to at a later point.” (Polypane, 2023).

The :has() selector is frequently referred to as the “parent selector,” but it is more accurately described as a relational pseudo-class. For decades, CSS could only style elements based on their ancestors; it could not look “down” or “sideways” to determine styling.

With :has(), we can style an element based on its descendants, its siblings, or even its “cousins.” For a beginner, the relational aspect means the CSS engine can now ask: “Does this container have a specific element inside it?” For example, you can style a card component differently only if it contains an image, or change a form’s border colour only if it contains an invalid input field.

This tool effectively eliminates the need for “state classes” in JavaScript. Previously, you might have used a script to toggle a .has-error class; now, you can re-implement logic like :focus-within or show “other” input fields entirely through CSS relations. While it fundamentally changes how we view the DOM tree, it does so with zero noticeable performance implications in modern engines.

Creating a modal box once required complex JavaScript to manage focus traps and ARIA attributes. The <dialog> element is now the standard, native way to create both modal and non-modal boxes.

When you invoke the native .showModal() method, the browser provides several high-end features automatically:

• The Top Layer: The dialog is promoted to a special “top layer,” ensuring it sits above other content regardless of z-index.

• Inert Content: The background content is automatically made “inert,” preventing users from interacting with or tabbing to elements behind the modal.

• Light-Dismiss: A cutting-edge 2026 enhancement is the closedby="any" attribute, which enables “light-dismiss” behaviour—allowing the user to close the dialog by simply clicking outside of it without a single line of custom event-listener logic.

From an architect’s perspective, we must respect the element’s built-in accessibility. For instance, the tabindex attribute must not be used on the <dialog> element itself, as it is not interactive and should not receive focus directly; focus should instead be directed to its internal contents.

As MDN Web Docs (2026) notes:

“While dialogs can be created using other elements, the native <dialog> element provides usability and accessibility features that must be replicated if you use other elements for a similar purpose.” (MDN Web Docs, 2026).

Accordions are a staple of modern web design, yet they almost always rely on JavaScript for class toggles. By using the <details> and <summary> elements, we create disclosure widgets natively. In 2026, these elements have been modernised with the name attribute.

By setting the same name attribute on a group of <details> elements, you create an “exclusive accordion.” In this pattern, opening one item automatically closes any other open item in the same named group, a behaviour handled entirely by the browser.

The simplicity of this approach is elegant:

“Set the same name attribute on every <details> element you want grouped. That’s the entire trick - no JavaScript, no event listeners, no class toggles.” (Judis & Abrams, 2026).

Developers should, however, consider the UX trade-offs. Exclusive accordions can frustrate users who wish to compare information across multiple sections simultaneously. Use this pattern judiciously, typically for marketing widgets rather than critical documentation.

A common frustration for beginners is the inability to transition an element from display: none. Standard CSS transitions do not trigger when an element first appears or when its display type changes.

The @starting-style at-rule and the transition-behavior: allow-discrete property solve this by allowing transitions on properties that are not typically animatable. To ensure a smooth exit from the “top layer,” architects must also include the overlay property in the transition list. This ensures the element remains in the top layer until the transition finishes, preventing it from vanishing instantly.

Furthermore, the interpolate-size property allows us to finally animate to intrinsic sizes like height: auto. While currently a Chromium-only enhancement, it serves as a perfect example of progressive enhancement: on other browsers, the accordion simply snaps open, maintaining full functionality while providing a premium experience for those with supported browsers.

Understanding these “discrete” flips is vital:

“By setting transition-behavior: allow-discrete we can tell the browser that it’s okay to also transition properties that aren’t based on numbers. If you allow discrete animations, the values won’t be flipped immediately but at the 50% transition mark.” (Judis & Abrams, 2026).

The introduction of advanced selectors, the <dialog> element, the Popover API, and discrete transitions represents a fundamental shift toward a more robust, standards-based web. We are moving away from treating the browser as a blank canvas and toward treating it as a sophisticated framework.

By leveraging these native features, you can shed significant “library weight,” resulting in faster load times and code that is easier to maintain. As the browser continues to take on more of the heavy lifting, the role of the developer shifts from managing complex scripts to mastering the nuances of the platform itself.

In an era where the browser does the heavy lifting, is it time to rethink our reliance on complex UI frameworks?

Thank you for reading… :D

Judis, S., & Abrams, M. (2026, May 7). Creating Animated Accordions with the Details Element and Modern CSS. Builder.io. https://www.builder.io/blog/animated-css-accordions

MDN Web Docs. (2026, July 2). : The HTML Dialog element. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/dialog

Polypane. (2023, January 2). :where() :is() :has()? New CSS selectors that make your life easier. https://polypane.app/blog/where-is-has-new-css-selectors-that-make-your-life-easier/