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 --bs-headings-color CSS variable due to backward compatibility issues #36509

Merged
merged 1 commit into from Jul 11, 2022

Conversation

mdo
Copy link
Member

@mdo mdo commented Jun 6, 2022

Fixes #36365.

The null value breaks existing styling where hyperlinks with a heading helper class no longer appear blue. This will have to be resolved most likely in v6 I'd think to avoid any other BC issues.

@mdo mdo added this to In progress in v5.2.0-stable via automation Jun 6, 2022
@mdo mdo requested a review from a team as a code owner June 6, 2022 02:27
@ffoodd
Copy link
Member

ffoodd commented Jun 6, 2022

Cannot check right now but couldn't a fallback value be a better fix? Something like var(--bs-heading-color, inherit) — to be tested, could be currentcolor or explicitly using body color too.

@mdo
Copy link
Member Author

mdo commented Jun 8, 2022

Any fallback like that presents the same issue unfortunately—links with .h1 would appear dark gray instead of Bootstrap blue as it'd be inheriting from the body.

@mdo
Copy link
Member Author

mdo commented Jun 13, 2022

@ffoodd @julien-deramond Thoughts on maybe adding a new --bs-heading-link-color and adding some new a.h1, a.h2, etc rules? As of right now, any fallback keyword value like inherit, currentcolor, initial, etc would result in the same behavior. The intent is to preserve the blue link colors on heading utilities (and not, fwiw, on children elements like h1 a to be clear). This might still then be a breaking change, but it preserves a new CSS variable and adds even more customization later (e.g., the ability to make heading links custom from body paragraph links which lots of sites do).

@ffoodd
Copy link
Member

ffoodd commented Jun 13, 2022

Usually not in favor of using element and class selectors together, but not sure to have a better solution.

There're at least two ways I can think of:

  • using the :any-link pseudo-class which would feel a bit more elegant than element selector—but wouldn't differ that much;
  • using a custom cascade based on custom properties, e.g. var(--bs-link-color, var(--bs-heading-color)) which would ensure the first get applied (props to Miriam Suzanne for the technique).

I can't find any other way around for now. Any thought?

@mdo
Copy link
Member Author

mdo commented Jun 13, 2022

Hmm... for the second option, both values are always set (globally), so not sure a custom cascade would help much?

@ffoodd
Copy link
Member

ffoodd commented Jun 13, 2022

Uh, you're right. I don't think it's safe to move --bs-link-color to links reboot, sadly, since it could be used on other elements than links.

I can't find any other way. Let's go for a.hn then?

@mdo
Copy link
Member Author

mdo commented Jul 10, 2022

For now, going to outright remove this one. We can circle back on a new variable when we're able.

@mdo mdo force-pushed the rm-headings-color-css-var branch from e2c181a to 34b5f4f Compare July 10, 2022 23:39
@mdo mdo merged commit 270344a into main Jul 11, 2022
v5.2.0-stable automation moved this from In progress to Done Jul 11, 2022
@mdo mdo deleted the rm-headings-color-css-var branch July 11, 2022 07:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
v5.2.0-stable
  
Done
Status: Done
Development

Successfully merging this pull request may close these issues.

.h-* classes change color of anchor
2 participants