Goal

While we're pleased the component APIs for v3 and the recent Zag.js integration, @Hugos68 has identified a few things that could be improved that would provide a number of quality of live benefits. Unfortunately these are breaking changes, and as such would need to be reserved to a major release.

Proposals

The following are based on Hugo's suggestions.

1. Single Entry Point for Classes

This would utilize either the base: variant strategy -or- Tailwind Merge, to replace base/property style props with only a single entry point. This would be similar to the v3 classes (plural) prop, but likely resolve to the nature class (singular) attribute name. Essentially ALL inherent styles would be implemented in such a way that user styles always take precedence and either overwrite existing classes, or if new, extend the class list.

2. More Modular and Composed Components

Components would now be composed of more/smaller child components, ala Bits UI. This means components are composed of smaller pieces in a template-driven manner, rather than relying on fewer/larger components that implement features such as named slots and snippets. This more closely matches the HTML template structure, which not only benefits Zag.js integration, but also minimizes the "depth" of elements/classes assigned per component.

3. Improved Support for "Rest" Props/Attributes

The other advantage of more modular/composed components is it would be easier to provide and spread restProps. This can include a number of common props like style attributes, lazy load attributes for images, plus tons of input-related attributes.

4. Container Queries for Responsive Sizing

I think this would be a great time to convert to container-based queries instead of the media query breakpoints we use now. Work with Chris if you need help getting started on this.

https://tailwindcss.com/docs/responsive-design#what-are-container-queries

Prototype ASAP In Public

Rather than writing up a length proposal and gathering community comments, @ryceg has suggested a novel approach. Which is to implement this for one, singular, new component. Ideally a clone of an existing component to compare to. That way users test drive this in practice right away. This component would be marked with an alpha or experimental tag to make it clear it's subject to changes. If the majority of the community agrees with these changes, then this would become the focus of the v4/Next release, spearheaded by @Hugos68

Additional Information

Here's an example of what the changes might look like from user-land...

Before (v3.0)

<Avatar src="..." background="bg-primary-500" imageClasses="greyscale" border="border border-surface-50-950" />

After (v4/Next)

<Avatar class="bg-primary-500 border border-surface-50-950">
    <Avatar.Image src="..." class="greyscale" lazy></Avatar.Image>
</Avatar>

• More piecemeal component structure to more closely match the HTML template structure (ala Bits UI)
• All style props are collapsed to the singular class entry point prop
• The class doesn't care what or how many classes you pass, they always take precedence
• Functional props like src are moved relative to usage - so Avatar.Image in this case
• Demos restProps such as lazy ton the <img> tag (a native HTML attribute)