Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove named opacity support for color opacity modifiers #14278

Merged
merged 2 commits into from
Sep 2, 2024

Conversation

philipp-spiess
Copy link
Member

Right now if you have a custom opacity theme value configured like this…

@theme {
  --opacity-disabled: 50%;
}

…then you can use that named opacity value as a color opacity modifier like this:

<div class="bg-red-500/disabled">

We think this behavior is confusing. The color opacity modifier is not setting opacity but the alpha value of a color. Opacity is for setting the opacity of an element, so the custom names you'd come up with are named after those situations, which makes them not seem appropriate for color modifiers.

@philipp-spiess philipp-spiess changed the title Remove named opacity support for color opacity modifier Remove named opacity support for color opacity modifiers Aug 28, 2024
@philipp-spiess philipp-spiess merged commit c6e4dab into next Sep 2, 2024
2 checks passed
@philipp-spiess philipp-spiess deleted the change/remove-named-opacity-for-modifiers branch September 2, 2024 14:41
thecrypticace added a commit that referenced this pull request Sep 4, 2024
We removed named opacity modifier support in #14278 but we (read: me
lol) totally forgot about the suggestions in intellisense. So we need to
make sure that we don't suggest those either.
@emmbm
Copy link

emmbm commented Nov 1, 2024

Is there any chance we could see support for named alpha values, maybe under a different theme key like --alpha-foo?

philipp-spiess added a commit that referenced this pull request Nov 15, 2024
This PR reverts #14278
to bring back support for using named opacity values in color opacity
modifiers:

```css
@theme {
  --opacity-myOpacity: 50%;
}
```

```html
<div class="bg-red-500/myOpacity"></div>
```

We briefly discuss to restructure the code so that we avoid adding a
`theme` argument to the call sites but I do still prefer the current
approach for the following reasons: The way to avoid this is to a) put
something in either the `Theme` class scope, where it feels grossly out
of place, or b) put it into the shared closure in the utilities file
which is already very large and hard to reason. Furthermore, there's a
second call site in the compile function where we would need to
duplicate the namespace lookup.

Every caller of the current `asColor` value already has access to the
`Theme` so passing that as an argument seems like the least intrusive
way.

## Test Plan

Brought back the unit tests but I also tested it with the Vite
extension:

<img width="744" alt="Screenshot 2024-11-15 at 11 15 05"
src="https://github.com/user-attachments/assets/63923b80-767e-4104-b7eb-f71fc815b51e">

---------

Co-authored-by: Adam Wathan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants