Expose CSS variables for button and link colors #177
Conversation
## Description
This is an ask from some embed clients. This change is narrowly scoped
to just specific UI elements; I think it's best to keep customization
points limited to concrete use cases, to avoid complexity.
I made new CSS variables for the specific UI elements, to allow
customizing them separately. (There are plausible colors for the
button that look bad when used as the link text color.) Another reason
not to make `color-action-primary` (and other color aliases) into
customization points is to give us the freedom to use them on other
components (or _stop_ using them on existing components) without
worrying about breaking a supposedly-stable public interface.
The submit button and links are the most obvious purple-500
components, but note that there are still some others: the triangle in
the dropdown button, and the icon in the project selector. If needed,
we can allow customizing those (or maybe just make them
non-customizable and go back to grayscale); we'll see what embed
clients say.
### Followup
Once this is landed, document the customizable variables in the readme
and in the embed docs on Zuplo.
## Test Plan
Without overriding any variables, look at the form and results in all
widths; make sure it looks exactly the same as before.
Add some CSS in index.html:
```css
rewiring-america-state-calculator {
--color-background-button: 0 255 0;
--color-text-button: 255 255 0;
--color-text-link: 255 0 255;
}
```
Make sure the submit button is green with yellow text, and the links
(the two in the form, plus the "learn more" links in the incentive
cards, on narrow and wide layouts) are magenta.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| @@ -28,7 +29,6 @@ export const PrimaryButton: FC< | |||
| 'focus-visible:from-color-shadow-primary/25 focus-visible:from-0%', | |||
| 'focus-visible:via-color-shadow-primary/25 focus-visible:via-100%', | |||
| )} | |||
| onClick={onClick} | |||
There was a problem hiding this comment.
Removing this as a drive-by; it's not used anymore.
src/state-calculator.tsx
Outdated
| @@ -238,7 +238,7 @@ const StateCalculator: FC<{ | |||
| <div className="text-color-text-secondary text-[0.75rem] leading-tight pb-[0.1875rem]"> | |||
| {msg('We’re dedicated to safeguarding your privacy.')}{' '} | |||
| <a | |||
| className="text-color-action-primary font-medium" | |||
| className="text-color-text-link font-medium hover:underline" | |||
There was a problem hiding this comment.
adding hover:underline as a drive-by; all the other link-looking things in the embed have that.
src/tailwind.css
Outdated
| @@ -55,6 +55,11 @@ | |||
| --color-text-primary: var(--grey-700); | |||
| --color-text-secondary: var(--grey-400); | |||
| --color-text-tertiary: var(--yellow-800); | |||
|
|
|||
| /* SPECIFIC UI ELEMENTS */ | |||
| --color-background-button: var(--color-action-primary); | |||
There was a problem hiding this comment.
Wondering if these should be prefixed --ra- to avoid them being overridden accidentally by the host page if they also use this naming convention? That’s what I did in the original IRA embed CSS but it was defensive and not based on any specific evidence that there was clobbering in the wild. Open to trying this and then revising if needed.
There was a problem hiding this comment.
The shadow DOM prevents definitions in the host page from reaching here, so I don't think that's a concern.
There's another possible justification for prefixing, though, which is to distinguish supported and non-supported customization points (both for ourselves as embed developers, and for embed clients). We can document "you can override any variable that starts with --ra-; override anything else at your own risk".
Description
This is an ask from some embed clients. This change is narrowly scoped
to just specific UI elements; I think it's best to keep customization
points limited to concrete use cases, to avoid complexity.
I made new CSS variables for the specific UI elements, to allow
customizing them separately. (There are plausible colors for the
button that look bad when used as the link text color.) Another reason
not to make
color-action-primary(and other color aliases) intocustomization points is to give us the freedom to use them on other
components (or stop using them on existing components) without
worrying about breaking a supposedly-stable public interface.
The submit button and links are the most obvious purple-500
components, but note that there are still some others: the triangle in
the dropdown button, and the icon in the project selector. If needed,
we can allow customizing those (or maybe just make them
non-customizable and go back to grayscale); we'll see what embed
clients say.
Followup
Once this is landed, document the customizable variables in the readme
and in the embed docs on Zuplo.
Test Plan
Without overriding any variables, look at the form and results in all
widths; make sure it looks exactly the same as before.
Add some CSS in index.html:
Make sure the submit button is green with yellow text, and the links
(the two in the form, plus the "learn more" links in the incentive
cards, on narrow and wide layouts) are magenta.