Feature request: option to remove `=""` from generated selectors (or additional selectors for non valued attributes)

Attributify is working very well, but we’re running into some semi-minor inconveniences. There are two parts to our problem:

The generated selectors are too specific for our needs

<div bg-red>123</div>

<style>
/* layer: default */
[bg-red=""]{--un-bg-opacity:1;background-color:rgba(248,113,113,var(--un-bg-opacity));}
</style>

We do not need the empty value check (="") in our selectors because we only use boolean attributes.

We are now forced to fallback to classes in svelte due to a limitation in the framework.

Svelte does not support dynamic boolean attributes. It only supports dynamically changing values of attributes (from true to false for example). Due to the empty value check in the generated css selectors, styles do not get applied to attributes when svelte automatically adds a value.

Because of this, we currently fallback to using classes quote often.

example svelte code we use now:

<a href="/planning/gantt" flex-1 rounded-l border border-r-0 transition-all class="{ !$page.url.pathname.includes( '/gantt' ) ? 'border-light-400' : 'border-color-theme-primary bg-theme-primary text-white' }">open view</a>

code we want to be able to write…

{ highlight = !$page.url.pathname.includes( '/gantt' ) }
<a href="/planning/gantt" flex-1 rounded-l border border-r-0 transition-all border-light-400={highlight} border-color-theme-primary={highlight} bg-theme-primary={highlight} text-white={highlight}>open view</a>

… which svelte turns into…

<a href="/planning/gantt" flex-1 rounded-l border border-r-0 transition-all border-light-400="false" border-color-theme-primary="false" bg-theme-primary="false" text-white="false">open view</a>

As you can see in the snippet above svelte sets text-white="false", which right now does not get matched by unocss generated css selectors.

Requested solution:

~Add an option to disable the empty value part of the generated selector. Something like anyValue or booleanOnlyMode would be great.~

EDIT: see https://github.com/unocss/unocss/issues/1372#issuecomment-1205552913

[antfu]

automatically encodes/transforms the non-exact-match attribute selector to a class selector

I guess it’s related to https://github.com/unocss/unocss/blob/2180281ba36fab75b395330bf76c89f845c4e8df/packages/core/src/utils/helpers.ts#L8

[UltraCakeBakery]

we only use boolean attributes.

I am not sure about this, as the HTML attributes do not allow some characters to be used, which will mean you are not able to use some attributes like w-1/2 h-[calc(100vw-2px)] etc. ="" is required to make an exact match.

Before we even knew utilities like w-1/2 were a thing, we already decided on our boolean-attribute-only approach. We do use them utility classes with special characters very rarely now we’ve got more experience using unocss. When we do we get around the character limitations by utilizing our own custom rules and a preprocess step that replaces emoji’s with strings to fill the gaps. With our config we can now do things like:

w-1-divide-by-2, top-1_4th, h-[🧮100vw-2px🧮] etc.

If we wanted to we could’ve just done w="1/2" for these rare occasions instead, and our current approach is less than ideal for sure, but what we’ve got going now works and is still intuitive enough for our team members to understand. Our codebase also looks very satisfying due to the absence of all the ="" characters, but that is just luck on our end that we didn’t have to work around character limitations as much as you might expect. Our config is also not very complex (maybe 60 lines of code, most of which are white lines), so it is still justifiable on our end.

anyways…

valuedBooleanAttributeFallbacks

Yeah I think it’s possible. But I’d consider the motivation to be a bit niche, maybe it’s better for you to fork preset-attrubutify (it’s quite short) to serve your custom needs.

The motivation is a bit niche yes. I already started working on a PR/fork of preset attribute, but I ran into a problem where presetUno (or unocss core, not sure) automatically encodes/transforms the non-exact-match attribute selector to a class selector. For example, It converts [width-12] {} to .\[width-12\] {} without there being any instruction to do…

I might make a separate issue for that if needed once i’ve figured out exactly what is going wrong and push my fork to git to make it more clear what i’m talking about. For now I’ll close my issue here.

Thanks for the response!