Die WCAG 2.2 Technik G65 „Providing a breadcrumb trail“ für das Erfolgskriterium 2.4.8 „Position“ (Stufe AAA) wird ein Update erfahren. Ergänzt wird die Information, dass man eine Breadcrumb-Navigation am besten möglichst am Anfang der Seite integrieren sollte. > Placing the breadcrumb high on the page, typically after the header, is a best practice and helps users quickly understand their location within the site. Quelle: Github G65-breadcrumb position – Änderung Auch das APG-Pattern für den Breadcrumb merkt an, dass die Breadcrumb-Navigation häufig horizontal und vor dem eigentlichen Hauptinhalt integriert wird. Mozillas Breadcrumb-Information ist noch etwas genauer. Die Breadcrumb-Navigation sollte typischerweise zwischen dem Kopfbereich der Seite und dem Hauptinhalt platziert werden. Diese Empfehlung findet sich auch in den meisten UX-Pattern. > Place the breadcrumb at the top of the page, below the global navigation and above the page title. Vitaly Friedman gibt auch eine kurze Erklärung in „Designing better breadcrumbs UX“ dazu. Die Breadcrumb-Navigation direkt nach der Hauptnavigation oder zumindest vor der Hauptüberschrift zu platzieren, gibt den Nutzenden eine sofort erkennbare Verbindung zwischen dem Breadcrumb und der aktuellen Seite. Weil sich der Breadcrumb im Kontext der Hauptnavigation befindet, können Nutzende den Breadcrumb gut verstehen. Nutzende können dadurch mehrere Möglichkeiten erkennen, wie sie sich auf den Seiten bewegen können. # Breadcrumb-Navigation auf Mobile Wichtig wäre auch, den Fokus auf Mobile nicht zu vergessen. Darauf gehen die WCAG-Techniken ja kaum ein. Eine Breadcrumb-Navigation auf einer mobilen Ansicht ist schon aufgrund der Länge der Links eine Herausforderung. In „Mobile Breadcrumbs: 8 Best Practices in UX“ werden verschiedene Möglichkeiten diskutiert, wie man mit einem Breadcrumb auf Mobile umgehen kann: den Breadcrumb auf Mobile ganz wegzulassen, ihn zu vereinfachen, auf keinen Fall mehrzeilig werden zu lassen oder die Inhalte zum Aufklappen zu integrieren. Aber wie steht es wirklich mit der Breadcrumb-Navigation aktuell noch? Oder ist es bereits so, wie das Web Designer Depot voraussagt „Breadcrumbs are dead in web design„, dass der Breadcrumb-Bereich schon nicht mehr zu unserem aktuellen Nutzungsverhalten passt?

Interessante Debatte im WCAG-Repository „Make ARIA11, ARIA13 and H101 advisory techniques“, ob der Einsatz von ARIA `landmark roles` oder HTML Regionen nur noch eine Empfehlung sein soll (advisory technique) und nicht mehr eine hinreichende Technik (sufficient technique), um das Erfolgskriterium WCAG 1.3.1 „Info und Beziehungen“ zu erfüllen. Genauer gesagt sollen gleich drei hinreichende Techniken heruntergestuft werden auf eine Empfehlung (advisory technique): * ARIA11: Using ARIA landmarks to identify regions of a page * H101: Using semantic HTML elements to identify regions of a page * ARIA13: Using aria-labelledby to name regions and landmarks Denn Semantik ist wohl nicht mehr wichtig. Es gäbe, so in der Github-Diskussion, ja sicherlich Seiten, auf denen es schwierig sein könnte, etwa die HTML-Regionen (`main` ‚ `nav`, `banner`, `footer`, `aside`, `search`) sinnvoll einzubinden in HTML. Aha. Seit Jahren nutzen wir in HTML diese wunderbaren HTML-Regionen, um sowohl Semantik als auch Unterstützung für Nutzende mit Screenreader zur Verfügung zu stellen. Und nun wäre das nur eine Möglichkeit unter vielen, das Erfolgskriterium zu erfüllen? Dann sollte man aber auch im Erfolgskriterium 2.4.1 „Bereiche überspringbar“ die Technik ARIA11 nur unter Empfehlung (advisory technique) aufführen und nicht unter hinreichend (sufficient). Und vor allem sollte man auch mal die Techniken ergänzen um HTML-Regionen und die ARIA-Techniken überdenken. Schließlich waren ARIA `landmarks` nur solange wichtig, wie es noch keine entsprechenden HTML-Regionen in HTML gab. Und wie auch ganz richtig angemerkt wurde, wird bei einem Test auf Barrierefreiheit – im BIK BITV-Test Web etwa im Prüfschritt „2.4.1 Bereiche überspringbar“ – geprüft, ob eine generelle Struktur für die Seiten mit HTML-Regionen vorhanden ist – also Kopf-, Navigation-, Haupt- und Fußbereich und im Einzelfall auch Seitenbereich – und korrekt integriert ist. Wenn die generelle Struktur nicht verständlich ist, also etwa der Hauptbereich (`main`) fehlt und die Hauptnavigation nicht als Navigation (`nav`) ausgezeichnet ist, kann das nicht konform sein. ## HTML-Regionen in WCAG ACT-Rules und axe-core Sieht man sich die WCAG Test-Regeln (ACT-Rules) an, findet sich dort zwar eine Test-Regel „Document has a landmark with non-repeated content“, aber auch wenn diese Test-Regel bestanden ist, ist diese Regel für Konformität nicht nötig. Im Übrigen sind die angeführten positiven Beispiele immerhin aktueller, weil sie auch HTML-Regionen enthalten. Aber ein Beispiel enthält gleich mehrere Hauptregionen (`main`), was weder sinnvoll noch gemäß HTML-Spezifikation gewünscht ist: > A document must not have more than one main element that does not have the hidden attribute specified. Sieht man sich die Test-Regeln von axe-core im Hinblick auf HTML-Regionen an, ist es nicht konform für das Erfolgskriterium 2.4.1 „Bereiche überspringbar“, wenn es nicht wenigstens für den Hauptinhalt der Seite eine HTML Region `main` gibt oder einen Sprunglink zum Hauptinhalt oder eine Hauptüberschrift. Die Frage ist, ob nicht auch die Technik H101 (HTML-Regionen) besser zusätzlich im Erfolgskriterium 2.4.1 „Bereiche überspringbar“ als hinreichend integriert werden sollte. Und wenn ich meine Nutzung der Techniken in WCAG betrachte, habe ich Techniken als Empfehlungen immer nur so wahrgenommen: Entweder waren die Techniken bisher nicht realisierbar, weil zu zukünftig, oder sie waren einfach eine Empfehlung, die man oft nicht wirklich für die konkrete Umsetzung in HTML anwenden konnte. So wichtige Semantik wie HTML-Regionen als Empfehlung in den Techniken herunterzustufen, wird – so befürchte ich – dazu führen, dass der Einsatz von HTML-Regionen wieder zurückgehen wird und wir dann wieder eine Div-Suppe oder eine `section`-nitis haben werden.

Animated example First, let’s define caret. For the scope of this post, I am not talking about the ^ symbol, which evolved from the circumflex. I’m also not talking about the proofreader mark, sometimes rendered as ‸, ⁁, or ⎀. I am talking about the navigation symbol (or insertion caret),…

In Belgium, accessibility compliance is regulated by multiple government agencies. This guide brings together, obligations, procedures, and enforcement measures

Truly independent web browser. Contribute to LadybirdBrowser/ladybird development by creating an account on GitHub.

This post is an excerpt from our comprehensive online course, Subatomic: The Complete Guide To Design Tokens. The course digs into _everything_ that goes into creating design token systems and themeable user interfaces to help Multi All-The-Things organizations meet the multifarious needs of their digital products. Design tokens may be the latest incarnation, but software creators have been creating themeable user interfaces for quite a long time! As with all things, we can study history to learn from our past to inform our future. So let’s dig in! ## 1970s: The first commercial GUIs The history of the graphical user interface (GUI) is fascinating and naturally involved a lot of research, iteration, and development before being unleashed upon the world. The first commercial computer featuring a GUI was the Xerox Alto in 1973. Behold it in all its glory: GUIs ultimately hit the market in 1981 in the form of the Xerox Star. The Star was similar to bands like CAN and Fugazi in that sense that it wasn’t a commercial hit, but was massively influential to everything that followed. The 70s also saw the rise of video games, especially with the runaway success of Pong. Galaxian by Atari was released in 1979 and was the first successful game that made use of a full-color RGB display. Game & computer designers were contending with extremely limited processing/memory resources, so they were forced to get extremely creative in order to support full-color screens. Sprites were used to manage the graphics and different states for UI elements, and color themes cleverly transformed the same shapes into different characters. Themed UI elements! ## 1980s: Color, games, and the PC age The 1980s ushered in an era of full-color displays, which opened many new opportunities and challenges for designers. Just look at this glorious sprite showcasing from Nintendo’s 1985 era-defining video game, Super Mario Brothers: **It’s _wild_ that two of the most iconic characters in the history of pop culture — red-clad Mario and green-clad Luigi — are themeable UI elements born from pragmatic ingenuity to overcome technological challenges**. Freaking amazing. **This ingenious sprite theming is a masterclass in creative constraints.** One thing you absolutely can’t unsee once you know is learning that **the clouds and the bushes in Super Mario Bros are the exact same shape, just themed differently!** To put a finer point on this: the creators established the game’s structure and functionality and understood that **duplicating all of that structure & functionality merely to achieve different aesthetic results would be wasteful, expensive, and imprudent.** **So instead they created a themeable design system toachieve this critical separation of concerns between structure/functionality & aesthetics.** Incredible! ### The PC Era Naturally, full-color displays found their way into personal computer operating systems in the 1980s. Several full-color computers hit the market in the mid-80s, and the iconic Apple II released its first full-color display in 1987. ## 1990s: OS-level theming, The Web, and CSS Microsoft introduced color schemes with the release of Windows 3.1 in 1992. Users (including a young me!) could go into their preferences, choose a theme for the Windows UI, and even customize the colors. Easily the best theme was named “Hotdog Stand“: This was**one of the most sophisticated, large-scale theming implementations that truly introduced the concept of real user preference and customization to the masses**. This UI customization and themeability became even more robust with the release of Windows 95. These new operating systems unlocked new opportunities for software like Winamp to give users the ability to create their own music player skins, truly putting the “personal” in “personal computer.” A glorious collection of Winamp skins courtesy of the Winamp Skin Museum Of course, the World Wide Web also exploded onto the scene in the 1990s. 1993 saw the release of Mosaic, the world’s first commercial internet browser, but it was really the introduction of Netscape Navigator in late 1994 that made the web an absolute phenomenon. The browser opened a portal into a million worlds, with **each website providing its own unique user experience and interface.** It was during this era that I found myself with my best friend making Dragonball Z fan websites on Geocities. I’ve been in love ever since. Note: check out the brilliantly-curated and thoughtful Web Design Museum for more web history! An example of a Dragonball Z Geocities fan website. I wish I could find my own; I remember tiled background images, Goku and Vegeta animated GIFs, fire graphics, hit counter, and a guestbook Accomplishing custom designs in the early web relied on hard coding styling information into the HTML using elements like `<font>` tag. Thankfully, **CSS hit the scene in late 1996**, which provided a dedicated language for styling and revolutionized how we create for the web. ## 2000s: The Web Grows and Native Hits The Scene The web continued to take off and the technologies to create it continued to improve. Books like Jeffrey Zeldman‘s _Designing with Web Standards_ and CSS books by pioneers like Molly Holzschlag and Eric Meyer helped the world’s emerging web community create beautiful and expressive web experiences. In 2003, Dave Shea created the CSS Zen Garden, which beautifully demonstrated the concept of separation of concerns as it applies to the languages of the web. Using the exact same HTML file, designers could use CSS to design radically different aesthetics. For me and countless others, the CSS Zen Garden drove home the importance of the separation of concerns and unlocked the real creative potential for the web as a design medium. The web field marched into the Web 2.0 era bursting with creative expression, which was put on full display on websites like MySpace. This customization started entering into more functional software, like then-new tools like Google Personalized Homepages (later renamed iGoogle). Up until this point, authoring CSS to achieve sophisticated theming was extremely laborious, hard-coded, and fraught. Adding to the complexity was that the whole industry was thrust into a brand-new mobile era as soon as Steve Jobs muttered “and one more thing…” in 2007. ## 2010s: Sass, Design Systems, Design Tokens CSS pre-processors like Sass and Less hit the scene in the mid-2000s, and Sass 2.0 introduced this wild little idea called variables in 2010. This was embraced by designers and developers who finally had a DRY way of defining a design language. $primary-color: #3498db; button { background-color: $primary-color; } This unlocked new opportunities for themeability and more dynamic styling on the web. These new capabilities coincided with the emergence of responsive web design, modular CSS methodologies like OOCSS, SMACSS, BEM, and others. In May of 2013 I introduced a thing called Atomic Design. A few months later, React was introduced. The zeitgeist was flexibility, modularity, and component-driven design/dev, which ultimately coalesced under the label “**design systems.”** Design systems like Google’s Material Design emerged in 2014-2015 and had themeability in mind right out of the gate. These design systems demonstrated to the world how its possible to deliver a unified design language to multiple products, platforms, and businesses. Holy crap was it ambitious! Still is! In order to support these vast and multifarious product UIs, the concepts, technology, and tooling around theming needed to evolve. ### Design tokens origin story While Sass variables gave designers & developers a great way to define and use a design language, Jina Anne and Jon Levine at Salesforce delivered a talk that gave the concept of these low-level design decisions a more potent name: **design tokens**. > Design tokens are the sub atoms — the smallest pieces — of the design system. They’re an abstraction of our UI visual design and store style properties as variables. > > Jina Anne There are a number of definitions and explainers about what design tokens are, which can be summarized like this. **Design tokens are:** * **The smallest (subatomic) elements of a design system** * **Design decisions for a design language** * **Design properties stored as variables** * **Implementation/technology agnostic source of truth** that can be converted into any format * **A common language for design** used to connect people, disciplines, tools, and systems * **The engine of themeable user interfaces** In the mid 2010, code tools like Theo from Salesforce and Style Dictionary from Amazon emerged to transform implementation-agnostic JSON or YAML token definitions into technology-specific formats like Sass variables, iOS & Android formats, JS objects, and an important new native web technology called CSS custom properties. Our Subatomic design tokens course introduces core concepts for creating token systems, provides sample architecture, and detailed walkthroughs for how to set up a token system in Figma & code then successfully adopt it in your org’s product ecosystem. CSS custom properties give the web theming superpowers — and to do it live! Seriously, check out this amazing website by Abban Dunne: There’s a whole lot to design tokens! And a whole lot of opportunity Perhaps that’s why a Design Tokens W3C Community Group was established in 2019 to help wrangle and standardize some of the structure, naming, and architecture around design tokens. ## 2020s: Multi-All-The-Things, AI, and beyond ### Tokens in Figma Achieving elegant theming in design tools like Adobe Photoshop/Illustrator/XD, Sketch, and Figma has been elusive until very recently. Styles existed in tools like Sketch and Figma, but were insufficient for the level of customization digital orgs had to account for. In 2022, Tokens Studio was released to help bring more sophisticated theming to Figma, and in the summer of 2023, Figma released Figma Variables, a tool-native way to define and wield design tokens. This created the opportunity to design UIs that can more easily support multiple themes. The magic trick is really cool! ### The rise of AI and themeability on demand Of course, at the time of this writing, generative AI exploded onto the scene and is introducing a brand-new paradigm that will influence the world, including how to support themeable user interfaces. These tools are still emerging, but already we’ve found many ways AI tooling can help in the creation and adoption of design token systems (we get into all of it in our course!). It’s also easy to imagine that thes new technologies can help usher in a new era of hyper-personalized user experiences. My user experience may look and behave wildly differently than yours, which introduces all sorts of fascinating opportunities and challenges. ### Our Multi-All-The-Things Reality It’s been a hell of a journey that’s gotten us here, but we are here. We are alive in a moment where we’re responsible for designing and building for a Multi All-The-Things reality. We have more websites, apps, screens, flows, products, ecosystems, technologies, and paradigms than at any other moment in human history. And it doesn’t show any sign of slowing down anytime soon. No one can predict the future, but **I strongly feel that organizations that have sturdy foundations, infrastructure, and systems in place will be in a better place to navigate whatever the future may bring.** ## Consider checking out our design tokens course **There’s SO MUCH technology, architecture, tooling, cross-disciplinary collaboration, orchestration, and gold old-fashioned human processes involved in creating robust, successful, and themeable UI systems.** Achieving balance in these systems is truly an art form: constrained-yet-expressive, systematic-yet-extensible, considered-yet-customizable. We’ve devoted the last 12 years of our lives to helping teams establish these systems, and spent 6 months distilling all of these concepts, best practices, hard-earned lessons into a comprehensive online course called Subatomic: The Complete Guide To Design Tokens. Our course covers everything your team needs to create & maintain a successful themeable design systems at your organization. Order our course and you’ll get: * Over 13 hours of in-depth video * Figma & code sample architecture * Naming & governance workflows * PDF slides with over 150 resources * Access to our Slack community * Certificate of completion * Free updates WHEW! I suppose this post is a history lesson slash infomercial for our course. But walking through this history, I’m struck by the fact that my personal journey on this Earth coincides with much of the history of themeable user interfaces. I am so incredibly grateful that I’m on this planet during such a time of technological innovation and convergence between technology, design, and art. I’ve now spent literally half of my life professionally designing cool-looking things for the World Wide Web. And I think that’s pretty badass.

The W3C Membership approved the 2025 W3C Process Document, which documents the organizational structure of W3C and processes, responsibilities and functions that enable W3C to accomplish its mission..

Web Components are more than just Custom Elements. Shadow DOM, HTML Templates, and Custom Elements each play a role. In this article, Russell Beswick demonstrates how Shadow DOM fits into the broader picture, explaining why it matters, when to use it, and how to apply it effectively.

The customizable select has entered Chrome 134, allowing us to style this form element to our hearts' content. I decided to write a series about this feature because there are so many cool things we can do with CSS these days to create some really unique and fun experiences. In this first article of the series, I want to talk a bit about the history, while also giving an in-depth guide on how you can start creating your first customizable select as a progressive enhancement, today. This article could probably be read a 10-fold if I just named it: “10 ways to style your customizable select with CSS”. But I don’t want to do that. Instead I’m going to write a little series, starting with a bit of history and basic workings behind this new capability, and just follow it up with some in-depth examples and trickery. I do encourage you to read a bit about the history as it might be some good food for thought, but since this is quite the long article, I added a few anchors: * The History * Styling the Customizable Select * Adding Images in the Select * The Selected Content Element ## The history The customizable select has been in the works for quite some time. Following the evolution of ideas on how we could solve the styling capabilities for developers was something I could witness close by. I’ve learned much about legacy, trade-offs and “naming things” by following along with Open UI for a few years. Even if it was just giving my opinion during Open UI meetings, early adoption, and reporting bugs by creating demos for each iteration of “customizable select”, it puts a big smile on my face to see this feature land in Chrome as of version 134. The amount of work this costs is not to be underestimated, and so many people had a part in this. I, for one, am just really happy I could see it all take shape. More often than not when I give presentations about new UI capabilities, people ask me if I participate in these W3C community groups as a part of my job, or they wonder if I make some money doing it. The answer to that question is: “no, and I’m not the only one”. Same as in open source projects, some people do this kind of thing out of a passion. Maybe in some cases it’s about frustration as well? Eg: ”I’ve been doing this job for over 10 years, why can’t I style a select already?” ### From new - to progressively enhanced element A lot had been done for this already, but the first iteration (end 2022) I witnessed and based demos on was a new element called the `<selectmenu>`. There was even a moment when I thought it would be: “the final version”! So, I did what I usually do: I created a fancy article/demo and was convinced that this would be released in stable browsers (oh boy, was I wrong…). The months after, new names were bikeshedded and in about two months, there was a completely different name for this element: the `<selectlist>`. Ok, just a minor change, so I updated all my demos, feeling confident that this was just a little pre-release change for better naming, as a select isn’t a “menu”. Even after name changes and other adjustments, the proposals still lacked a bit of clarity, specifically about progressive enhancements and accessibility. A new element does make things a lot more complicated for accessibility: Keyboard controls need to be specified correctly, screen readers would need to be updated to recognize the new element, and users would have to update their screen reader software to even notice that new element for what it is. It could become a real hassle. One thing became clear during that period, there is a thin line on where you want to block authors for doing certain things. Do we give developers full control? Where should we block things? By default, everything should be accessible in HTML, let’s not forget that. It’s a thin line to which degree you want to give developers a pair of scissors and let them run with it. Please don’t take that the wrong way, I’m just as equally guilty in creating some shady stuff. But where and how could you avoid this, that’s the question. Let’s fast forward a little bit. In the end, what Open UI does, is write explainers. This kind of research goes on to be presented to the HTML and CSS working groups, and a lot of feedback can come from those steps. One thing that started to happen was collaborative meetings. Mostly due to bad hours for me to follow those, I only joined a few of them, to listen. But I did notice that a lot of handy feedback came from those meetings and things started to move forward at an inclined pace. Everyone loved the capability and the work by Open UI, the things we could do, but the new element idea, it just didn’t sit right. And that’s when a new idea was born… **Let’s re-use the select, and create an opt-in via CSS.** Can we? Shall we? This is where I got lost so many times, this is where talk started to happen on parsing HTML and what is and isn’t possible due to the browser engine and even OS differences. Because a select does differ based on OS as well, especially from an accessibility standpoint. Here is a party trick to do with your colleague: Create a select, “colleague one” views that select on Windows, the other one on macOS. Use your keyboard to access the select, focus on an option using arrow keys, press the `ESC` button, which colleague selected the focused option? Who still has the previous selected option? I’ll let you figure out the answer 😉 Anyway, a lot of thought went to this progressive enhanced select, and I don’t know all the details on the browser engineering perspective. However, I did learn that implementing this kind of behavior was difficult. There is a huge collection on GitHub by Joseph that if you want to dive deep on the amount of work, I can highly recommend it. The most baffling thing is that someone noticed that when you put a `<button>` inside of a `<select>`, it just gets completely ignored by browsers and that became the window to truly progressively enhance the `<select>` and open up a variety of styling possibilities. **Do not put an input element in there, for example**. (I might get back on that one in a future article) It’s only the `<button>` element that gets ignored, you can not put an `<input>` element in there without breaking the backwards compatibility. Another benefit is that it would ignore unknown elements, which allowed the `<selectedcontent>` (first named: selectedoption) element to be nested inside of a `<select>`. I did spare out some details, conversations about keyboard navigation, the timing of cloning `<selectedcontent>`, naming (a lot of) things, pseudo-element choices and names, how the checkmark should be defined, etc. A lot is going on here, and that’s exactly why I at least wanted to write up a little bit of history. There are so many little choices, that we take for granted when new things get added to the web platform. People are excited for this, me being one of them. So many hours went into getting this to the platform. Every engineer, accessibility expert, developer, contributor, is doing a little part in moving this forward. I’ve at least learned to be a little less ignorant, by understanding why these things take time. All that time, sometimes frustratingly re-creating demos due to changed (pseudo-) element names or behavior - I believe the wait was certainly worth it. A lot of people will use the word “finally” when podcasting, writing, and video tutorialing the customizable select. But just as we forget with open source, there was a lot of work, for the better. So from me, to all those involved, whether you get paid to do these groups or not: thank you. Now let’s get styling! ## Styling the customizable select Remember that this is a beginner tutorial so we’re going to keep things as easy as possible for now and create something like this: ### The opt-in via CSS and the anatomy of a customizable select First thing we need to do is to create our `<select>` using HTML and do the opt-in via CSS, for this demo, I do want to progressively enhance this `<select>` a bit, because I believe this is where a lot of the power lies, so let’s start with some HTML: <select> <option value="first">First option</option> <option value="second">Second option</option> <option value="third">Third option</option> </select> Now let’s opt-in via CSS: select { appearance: none; @supports (appearance: base-select) { &, &::picker(select) { appearance: base-select; } } } So, let’s explain this small CSS snippet a bit. First of all, I set my select to have `appearance: none;`, this was already possible, and I’m doing this because I do want a bit of styling for my select for browsers that do not support this new feature. Which brings me to the feature query: @supports (appearance: base-select) { &, &::picker(select) { appearance: base-select; } } This ensures that when the feature is supported, the select and the picker appear as `base-select`, opting into that customizable select capability. Let’s quickly compare side-by-side. On the left, you have Chrome 134, which supports this new behavior. On the right, you have another browser that falls back to the default `appearance: none`. But what happened when we opted in with CSS? Well, a lot of things became available to us, here is an image highlighting things we can target (explainer below): There are a few things that we can select with CSS directly: * `::picker-icon` : Allows us to change the little icon indicating the select (arrow-down) * `::checkmark` : allows us to alter the check icon that is next to the checked option * `:checked` : A pseudo-class to select our checked option * `::picker(select)` : The bounding box that surrounds/lists our options ### Styling our select Let’s start with the basic look and feel of our select, we’re going to set `display: flex` to get the arrow positioned next to the text, give it a bit of `border-radius` and just some basic styling, it’s all good here, do something you like for this step: select { display: flex; justify-content: space-between; align-items: center; color: white; border-radius: 5px; border: 2px solid plum; cursor: pointer; font-weight: 700; padding: 10px; background-color: hotpink; } Next up, we’re going to make sure that we still have a good experience for browsers that don’t have the new support. Inside of my select, let’s add a little arrow by updating the background and paddings: select { /* Previous properties, but updated the padding */ padding-block: 10px; padding-inline: 10px 30px; background: hotpink url("arrow.svg") right 10px center / 20px no-repeat; } This gives the padding at the end bit more room and provides a `background-image` of an arrow to clarify this is a select element. And there you have it, we have a perfectly styled select for browsers that don’t support this new feature: ### Progressive enhancing our customizable select Now that we have set a good basis, let’s dive a bit deeper. According to the anatomy, we can now access the `::picker-icon` pseudo-element to update our arrow, let’s do this right away. We will remove the `background-image` on our select itself and reset the `padding` in favor of using the pseudo-element as a progressive enhancement: select { /* Previous properties with background-image */ @supports (appearance: base-select) { padding-inline: 10px; background-image: none; &::picker-icon { content: ""; width: 20px; height: 20px; background-image: url("arrow.svg"); transition: rotate 0.2s ease-out; } } } Noticed that I added a transition on the `::picker-icon`? We also get an `:open` pseudo-class with this new feature, let’s put that in action and rotate our icon when the select is open: select { /* ... */ @supports (appearance: base-select) { /* ... */ &::picker-icon { /* ... */ } &:open::picker-icon { rotate: 180deg; } } } This is our current state when the select is open: ### Styling the select picker and options Now is the time to finally style what we came here for: styling the picker and options. With the `::picker(select)` pseudo-element we can style the box that contains our selects. For this part, let’s keep building it up inside of that `@supports` query: select { /* ... */ @supports (appearance: base-select) { &:open::picker-icon { /* ... */ } &::picker(select) { padding: 0; margin-top: 5px; border: 2px solid hotpink; background: white; border-radius: 5px; font-weight: 400; } } } This allowed us to style the listbox and this is the result: Wonderful! All that is left for us to do is to style the options themselves, in a nutshell, this is what I’ll be doing here: * Remove the checked icon by setting the `::checkmark` pseudo-element to `display: none` * Create my own checked state with the `:checked` pseudo-class * Add a bit of beautiful styling and some transitions option { padding: 10px; border-top: 1px solid plum; cursor: pointer; transition-property: color, background; transition-duration: 0.2s; transition-timing-function: ease-out; &:where(:hover, :focus, :active) { background: plum; color: white; } &:checked { background: violet; color: white; } &::checkmark { display: none; } &:first-child { border: 0; } } And there you have it, a beautifully styled select: ### Animations I am going to keep the animation part for another articles as I’m planning to go a bit wild with animations for those. Do not forget that the picker is inside of the top-layer, so you will need to animate with that in mind. However, I don’t want to keep you hanging completely, so for this example you could do something such as animate the `height` and `opacity`: select { /* ... */ @supports (appearance: base-select) { &:open::picker-icon { /* ... */ } &::picker(select) { /* ... */ opacity: 0; height: 0; overflow: clip; transition: height 0.5s ease-out, opacity 0.5s ease-out, overlay 0.5s, display 0.5s; transition-behavior: allow-discrete; } &:open::picker(select) { opacity: 1; height: calc-size(auto, size); overflow: auto; @starting-style { opacity: 0; height: 0; } } /* ... */ } } ### Final note on the first example In contrast to the non-customizable-select, the width of the select is fluid, meaning that it does not take the size of the largest option by default. So you will need to provide something for this. In the final example I added a `min-width`. Here is the full CodePen: <p>See the Pen <a href="https://codepen.io/utilitybend/pen/GgRrLWb"> A customizable select with only pseudo-elements</a> by utilitybend (<a href="https://codepen.io/utilitybend">@utilitybend</a>) on <a href="https://codepen.io">CodePen</a>.</p> ## Adding images in the select’s options! Now that we know the foundation of the customizable select, it might be interesting to know that this new feature allows us to add images or icons inside of the options. Re-using the same select (but with a bit of different styling), this is an example where I just added some SVGs inside of the options: You could do something like this: <select> <option value="pokeball"> <img src="..." alt="" /> Pokeball </option> <option value="greatball"> <img src="..." alt="" /> Great ball </option> <option value="ultraball"> <img src="..." alt="" /> Ultra ball </option> </select> And in my CSS, I updated my options a bit: option { display: flex; align-items: center; padding: 10px; gap: 10px; } The result is that inside of my options the images are visible: <p>See the Pen <a href="https://codepen.io/utilitybend/pen/mydBgNx"> A customizable select with images inside of the options</a> by utilitybend (<a href="https://codepen.io/utilitybend">@utilitybend</a>) on <a href="https://codepen.io">CodePen</a>.</p> This is great, no harm done for non-supported browsers as they don’t get rendered for those, but wouldn’t it be nice if we were able to see that image inside of our select when it’s closed? ## The selectedcontent element One of the great things is that buttons and new elements get ignored in browsers that don’t support this feature. Taking the same poké-adventure, let’s make that Pokéball pop up in the selected content. This is how I updated the HTML: <select> <button> <selectedcontent></selectedcontent> </button> <option value="pokeball"> <img src="https://assets.codepen.io/159218/pokeball.svg" alt="" /> Pokeball </option> <option value="greatball"> <img src="https://assets.codepen.io/159218/great-ball.svg" alt="" /> Great ball </option> <option value="ultraball"> <img src="https://assets.codepen.io/159218/ultra-ball.svg" alt="" /> Ultra ball </option> </select> The `<selectedcontent>` will clone the content of our selected option inside of it. We do need to style it a bit with CSS: selectedcontent { display: flex; align-items: center; gap: 10px; } This is our final result: <p>See the Pen <a href="https://codepen.io/utilitybend/pen/ByawgNN"> A customizable select with images inside of the options and the selectedcontent</a> by utilitybend (<a href="https://codepen.io/utilitybend">@utilitybend</a>) on <a href="https://codepen.io">CodePen</a>.</p> In case you were wondering, if this feature is not supported, it is still a perfectly beautiful and usable select: ### One more step The last thing I want to address is that we can visually hide some text inside of that `<selectedcontent>`, thus really manipulate the look and feel between the select itself and the options. I am not going to go in detail on this right now, but this means you could do something like this: More on that later, but if you can’t wait to dig in, you can find that CodePen here. ## Much more to come In the next few articles, I’m going to focus on some specific demos and techniques to create some really cool gamified experiences. I’m really happy this feature landed in Chrome and I just love playing around with it. It gives the ability to create some fun experiences, never forget to have some fun with the web. What’s more, I will be talking about this in depth at CSS Day this year! I know this was a long article, I promise the next ones will be a bit shorter. But here is the foundation for you to start creating those awesome customizable selects as a progressive enhancement! Happy selecting! ### Other articles on Select: * The customizable select - Part two: Potions, anchoring, and radial shenanigans in CSS * The customizable select - Part three: Sticky Options * The customizable select - Part four: Scroll snapping, state queries, monster hunter, and gamification * The customizable select - Part five: Optgroup, creating a true select menu Article by Brecht De Ruyte in css , html , ux

Save scroll position when users are likely to compare content in a long static list.

The new Figma plugin from BrowserStack helps UI/ UX designers build accessible products right from the start.

When I tried setting my browser font-size preferences, I found it broke more sites than it improved, and I quickly moved back to the default. So what went wrong, and how can we fix it?

I was thinking about something I wrote yesterday when I was talking about styling underlines on links: > For a start, you can adjust the distance of the underline from the text using `text-underline-offset`. If you’re using a generous line-height, use a generous distance here too. For some reason, I completely forgot that we’ve got a line-height unit in CSS now: `lh`. So if you want to make the distance of your underline proportional to the line height of the text that the link is part of, it’s easy-peasy: text-underline-offset: 0.15lh; The greater the line height, the greater the distance between the link text and its underline. I think this one is going into my collection of CSS snippets I use on almost every project.

Able Player version 4.7.0 beta 1 is now ready for testing - and your feedback is welcome! There are quite a few bug fixes in this release, a fair amount

The MDN Web Docs site provides information about Open Web technologies including HTML, CSS, and APIs for both Web sites and progressive web apps.

Baseline information is now available for CSS properties in the Elements panel of Chrome DevTools!

Take the State of HTML survey

After taking over Able Player, I received feedback from various sources about the kinds of problems people are having with the accessible media player.

Apple’s Opinionated Design principles are a thing of the past. Enter the world of reckless customization.