patternfly / patternfly/patternfly-org

Docs - how to customize global and component styles

Open
#4,499 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

PF Team
Dominant language
JavaScript
Stars
74
Forks
147
Avg merge
4d 11h
Merged PRs (30d)
2

Description

Goal is to create documentation around how to customize patternfly styles. This would like cover something like:

Components
  • Vars are the API for styling components. They're protected from breaking changes.
  • Try to write all overrides like the following
.pf-v6-c-component {
  --pf-v6-c-component--BackgroundColor: var(--pf-t--global--[semantic color var]);
  --pf-v6-c-component__element--Gap: var(--pf-t-global--[semantic spacer var]);
  ...
}
  • Be mindful of specificity/loading order
  • Avoid writing out nested property styles with regular property declarations. If users need to do this, they should bring their override back to PF and we can consider adding vars to support it. If we don't add vars, suggest not making that kind of override.
  • ...
Global/tokens
:where(:root) {
  --pf-t--global--[token]: var(--pf-t--global--[other token);
}

:where(.pf-v6-m-theme-dark) {
  // same as above but for dark theme
}

...
+ any other stuff that seems appropriate

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No file, test, or documentation entry point is named; start by locating where PatternFly styling and token guidance belongs. Done means documenting component variable overrides, specificity and loading order, global and dark-theme token overrides, and when nested property overrides should be avoided or proposed as new variables.

Written by the indexing model from the issue text.

Assessment

Tech stack
scss
Domain
documentation
Issue type
Documentation
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.