feat(Hero): added Hero component from compasshero - #7980
Conversation
|
Preview: https://pf-pr-7980.surge.sh A11y report: https://pf-pr-7980-a11y.surge.sh |
| id: 'Hero' | ||
| beta: true | ||
| section: components | ||
| cssPrefix: pf-v5-c-hero |
There was a problem hiding this comment.
| cssPrefix: pf-v5-c-hero | |
| cssPrefix: pf-v6-c-hero |
|
|
||
| ## Examples | ||
| ### Basic | ||
| ```hbs |
There was a problem hiding this comment.
Even though the component is beta, I'd mark the example, too, for extra, heavy duty messaging
| ```hbs | |
| ```hbs isBeta |
| | Class | Applied to | Outcome | | ||
| | -- | -- | -- | | ||
| | `.pf-v6-c-hero` | `<div>` | Initiates the hero. **Required** | | ||
| | `.pf-v6-c-hero__body` | `<div>` | Initiates the hero body. **Required** | No newline at end of file |
There was a problem hiding this comment.
| | `.pf-v6-c-hero__body` | `<div>` | Initiates the hero body. **Required** | | |
| | `.pf-v6-c-hero__body` | `<div>` | Initiates the hero body. | |
The __body element isn't required. The deal with that is, if you pass a background-image that's attached to the right side, you can put your text in that element and it has a width/max-width by default that keeps the text from going over the right side of the container, and the width/max-width are adjustable if you need to tweak it. If you don't use __body, you'd get the full width of the component for your text content and could manage the way it shows yourself. You wouldn't use __body, for example, if you didn't use a background image or gradient or whatever and wanted the text to span the full width of the container.
| padding-block-start: 32px; | ||
| padding-block-end: 32px; | ||
| padding-inline-start: 72px; |
There was a problem hiding this comment.
Can you see if we have any semantic spacer tokens that work for these padding values?
| background-position: right center; | ||
| background-size: contain; |
There was a problem hiding this comment.
Having vars for these would be great so people can change the background image properties to fit whatever image they use.
| background-repeat: no-repeat; | ||
| background-position: right center; | ||
| background-size: contain; | ||
| border-radius: 24px 72px; |
There was a problem hiding this comment.
I would probably create vars for these, too.
| padding-block-end: 32px; | ||
| padding-inline-start: 72px; | ||
| padding-inline-end: 0; | ||
| background-image: var(--#{$hero}--BackgroundImage, var(--#{$hero}--BackgroundImage--light)), |
There was a problem hiding this comment.
I would add glass styles to this component - a background-color set to --pf-t--global--background--color--glass--default (sauce and backdrop-filter set to --pf-t--global--background--color--glass--filter (extra sauce). That-a-way if you don't pass a gradient or background image (or if your gradient is semi-transparent), it will have a glass background by default when glass theme is enabled. That matches the pill drawer if you want a reference - exhibit A and exhibit 2
| background-repeat: var(--#{$hero}--BackgroundRepeat); | ||
| background-position: var(--#{$hero}--BackgroundPosition); | ||
| background-size: var(--#{$hero}--BackgroundSize); | ||
| border-radius: var(--#{$hero}--BorderRadiusTopLeftBottomRight) var(--#{$hero}--BorderRadiusTopRightBottomLeft); |
There was a problem hiding this comment.
Sorry I missed these in my previous review. The "glass" style, at least for what we've built so far has these properties:
- transparent-ish background color (
--pf-t--global--background--color--glass--default) - backdrop-filter (blur) (
--pf-t--global--background--color--glass--filter) - border-radius (
--large, unless it's pill) - box-shadow (
--md) - border-color (
--alt)
I think this box is going to need shadow in glass theme and a border in both glass theme and non-glass. For now I'd add the default/non-glass border using the normal border token, then write a :root:where(.pf-v6-theme-glass) block where you change it to the --alt token. That way the special curvy border-radiiii(?) are visible in light and dark theme. And for the shadow, I would just add that in the :root:where(.pf-v6-theme-glass) block and not have a box-shadow in non-glass theme.
I imagine in the future once the design sorts, we'll have global glass tokens for the border and box-shadow
| --#{$hero}--PaddingBlockStart: var(--pf-t--global--spacer--xl); | ||
| --#{$hero}--PaddingBlockEnd: var(--pf-t--global--spacer--xl); | ||
| --#{$hero}--PaddingInlineStart: var(--pf-t--global--spacer--3xl); | ||
| --#{$hero}--PaddingInlineEnd: 0; |
| --#{$hero}--m-glass--BackgroundColor: var(--pf-t--global--background--color--glass--default); | ||
| --#{$hero}--m-glass--BackdropFilter: var(--pf-t--global--background--color--glass--filter); |
There was a problem hiding this comment.
You shouldn't need --m-glass in these vars. They're regular vars, and they change at the global level when the glass theme is turned on.
| --#{$hero}--BorderRadiusTopLeftBottomRight: 24px; | ||
| --#{$hero}--BorderRadiusTopRightBottomLeft: 72px; |
There was a problem hiding this comment.
Can you create 4 vars for this? Since these are probably part of the style API, if design decides a third unique radius needs to be used, we'd want to then update the var names but that would be breaking.
There was a problem hiding this comment.
Yeah as i typed the vars out I was like "Boy that's an ugly var name" 😆
| | `.pf-m-inline{-on-[lg, xl, 2xl]}` | `.pf-v6-c-drawer` | Modifies the drawer so the content element and panel element are displayed side by side. `.pf-m-inline` used without a [breakpoint](/tokens/all-patternfly-tokens) will default to the `md` breakpoint. | | ||
| | `.pf-m-pill` | `.pf-v6-c-drawer` | Modifies the drawer for pill styles. | | ||
| | `.pf-m-no-glass` | `.pf-v6-c-drawer__panel.pf-m-pill` | Modifies the drawer panel remove glass styling when using glass theme. | | ||
| | `.pf-m-no-glass` | `.pf-v6-c-drawer__panel.pf-m-pill` | Modifies the drawer panel to remove glass styling when using glass theme. | |
| border-end-start-radius: var(--#{$hero}--BorderEndStartRadius); | ||
| border-end-end-radius: var(--#{$hero}--BorderEndEndRadius); | ||
|
|
||
| :root:where(.pf-v6-theme-dark) & { |
There was a problem hiding this comment.
| :root:where(.pf-v6-theme-dark) & { | |
| :root:where(.#{$pf-prefix}theme-dark) & { |
| --#{$hero}--gradient--stop-3: var(--#{$hero}--gradient--stop-3--dark); | ||
| } | ||
|
|
||
| :root:where(.pf-v6-theme-glass) & { |
There was a problem hiding this comment.
| :root:where(.pf-v6-theme-glass) & { | |
| :root:where(.#{$pf-prefix}theme-glass) & { |
|
🎉 This PR is included in version 6.5.0-prerelease.21 🎉 The release is available on: Your semantic-release bot 📦🚀 |
* feat(Hero): added Hero component from compasshero * Added styles to index * Coker feedback * Additional Coker feedback * Fixed lint errors * Old man yells at Michael * Added missing border style --------- Co-authored-by: Eric Olkowski <[email protected]>

Closes #7935
Would we want the Hero to be inside a CompassPanel still? If so, would we want to have the border radius (and/or any other styles) live inside CompassPanel when it has a pf-m-hero class? Right now I just moved all hero styles from Compass to the new PF level Hero component, so putting the Hero inside a CompassPanel results in the CompassPanel sticking out like a sore thumb: