Integrating UI components is too damn hard!

[LeaVerou]

Session description

The vision of authors being able to drop components and UI libraries into their pages and have things Just Work™ and look right (at least to a first order approximation) is still largely unrealized. Integrating any UI component is incredibly laborious, as it requires manually communicating fine grained design tokens to every single component.

This Web Awesome tutorial illustrates the problem perfectly:

https://youtu.be/JhfYeXLfWdI?si=vF3xRai2QrjabVFv&t=277

And this is just for assigning a certain hue as the primary color of a whole page — the effort is duplicated for every third-party UI component that uses colors, fonts, measurements, font sizes, etc. Same-party components can use the same naming convention to reduce effort, but that doesn't work for components from different entities.

To reduce integration effort, we need to reduce the amount of information the host page needs to communicate about its design to each individual component. Some avenues are:

1. standardized ways to set design tokens (e.g. the page’s primary color or serif font) in a way that can be read by other components
2. ways to derive tokens from core tokens (e.g. a light tint from a primary color, or the next smaller font size in a scale) to minimize how many tokens need to be communicated.
3. Ways for components to adopt and repurpose page styles of existing (standard) elements
4. ???

Session goal

Flesh out ideas for potential directions, see which are most viable in terms of I/E

Additional session chairs (Optional)

@keithamus

Who can attend

Anyone may attend (Default)

IRC channel (Optional)

#design-integration

Other sessions where we should avoid scheduling conflicts (Optional)

#59, #28, #68, #30, #27, #31, #26, #29

Instructions for meeting planners (Optional)

Co-chair if conflict can be resolved. List of conflicts is a prioritized list.

Agenda for the meeting.

1. Discuss requirements and potential directions
2. Discuss relevant proposals:
   • Proposal: CSS Variable Groups (as a solution to several design systems pain points) csswg-drafts#9992
   • Making design systems first-class citizens csswg-drafts#9999
   • [css-fonts] Allow authors to redefine generic font families csswg-drafts#10452
   • [css-color-adjust] Allow authors to define custom color-scheme values. csswg-drafts#9660
   • [css-mixins] Proposal: @like rule for repurposing page default styles csswg-drafts#10222
   • [css-color] [css-ui-4] Authors should have access to accent-color value to use in their code csswg-drafts#5900

Links to calendar

• 2024-09-25, 14:45 - 15:45

Meeting materials

• Minutes

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular. Bots and W3C meeting organizers may also update the description, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C meeting organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.

[justinfagnani]

This is an important topic and I would love to attend, but I need to be at #28. Hopefully there are good notes!

[sorvell]

There's some potential overlap with #27. Just wanted to point that out in the hopes of being efficient with time an consolidating appropriate discussion.

[sorvell]

Not sure I'll be able to attend this as I have the same overlap with #28 as @justinfagnani, so just capturing a few thoughts...

This Web Awesome tutorial illustrates the problem perfectly:

A lot of this customization API seems ok to me as it's trying to expose a lot of power, but I totally agree that doing something simple is pretty clearly way too hard.

If we start with .some-element { background: #ccc; } making a general design system that can connect the ability to customize that color with that specific element is... complex, and I think it's fair to say that best practices are still evolving here. For example, having component (button), role (surface, primary), and reference (palette) level tokens probably makes some. Some problems stand out as cumbersome:

• palette colors --wa-color-blue...gray-05,10...95: addressed by good color functions and custom css functions/mixins.
• related colors, --wa-surface-raised,default,lowered,border: addressed by custom mixins/functions and better built-in functions like contrast or light-dark (e.g. see --wa-border-width-base combined with calc to produce sizes)
• part based theming: falls over with composition, hoping to address via Open styleable shadow tree and theming #27 (comment)

[LeaVerou]

@sorvell @justinfagnani All of these were listed as explicit conflicts, yet this breakout was scheduled at the same time as them, defeating the point of listing conflicts. 😣 When I pointed it out, the response was basically "scheduling is hard".

---

WRT design tokens, having spent some time knee deep in the math for generating tints and shades, I can say that it won’t be anytime soon we get functions that generate tints and shades in CSS — there is no color space to automatically do what designers expect (OKLCH just makes it easier, but you still need to adjust multiple components).

But I agree being able to at least communicate main colors and have components derive the tints is a huge step.

And there is a lot that can be done to make it less painful to pass multiple values around (see some of the linked proposals).

[sorvell]

@LeaVerou Just wanted to say thanks for raising this issue. It'll be great to make some progress on it.

What I was trying to say above (and as you hint at with the complexities of color), we probably want/need all the dials that the web awesome video shows, but ideally there's a much better ramp to the use case shown there from the "I just want this UI template to be more blue instead of purple-y" use case. And I suppose this is pretty much what is motivating this session?

This is why I linked the Material Theme Builder. If we can get to a place in raw CSS where we can do that without a tool, it seems like we've moved the ball forward a good bit. For example, from simplest to most custom, I could specify: 1 color, a set of role colors, a full palette, component specific settings, any of those conditionally applied to a subtree.

If we do move forward on some of the important work in progress: custom functions/mixins and better built-in functions, this might get us most of the way there. I do also think that variable groups and improved shadow theming are also important to throw into the mix. Hopefully, we can think the use cases through to see if it feels like this work is converging towards a good solution here.

[LeaVerou]

@sorvell Even variable groups by themselves don't solve the problem, as there is no shared convention.

Reading this comment makes me think I may not have explained the issue well.

Suppose you’re making a WC for e.g. a calendar widget.

• When you want to highlight the current date with an accent color, you want it to be the accent color the page uses already.
• When you want a lighter version of the accent color for e.g. a date range, you want that to be an existing tint the page uses.
• When you want to display some grayed out help text, you want it to be a neutral shade already present on the page
• When you want to add a badge that says "today" on the current date, you want to pull in the sans serif font the page already uses and one of the font sizes that already exist on the page.
• When you want to draw borders between dates, you want to use existing colors and border widths.

Right now, each component needs to reinvent all of these, and simply provide customization hooks via dozens, sometimes hundreds of CSS variables that page authors painfully need to override one by one. Adding functionality via web components should not be so tightly coupled with how you do your styling.

[sorvell]

Adding functionality via web components should not be so tightly coupled with how you do your styling.

Crafting a good styling API that's both easy to use and powerful enough is a challenge for any author vending a reusable UI element or component or template. Without encapsulation it's possible to completely punt on, but even then the user must at least know what elements are rendered to style them properly.

Unfortunately, built-in elements themselves do not really provide a good model to follow. From <select> !@#$ to <input type="date"> not handling any of the cases you mention, we don't have a good starting point. But of course there's ongoing outstanding work to improve this.

Design systems have shown the power of leveraging tokens and that maps pretty well to css custom properties. We don't have a standard set of browser "tokens" that are helpful, more things like accent-color. I wonder if such an effort makes sense to grow out of projects like open-props or open-ui...

[LeaVerou]

Minutes