-
Notifications
You must be signed in to change notification settings - Fork 91
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
feat(tables): new light/dark mode colors #1833
Conversation
getColor({ | ||
variable: 'background.emphasis', | ||
transparency: theme.opacity[100], | ||
light: { offset: -300 }, | ||
theme | ||
})}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the context and how background.subtle
is used in other components, wouldn't background.subtle
fit better semantically?
getColor({ | |
variable: 'background.emphasis', | |
transparency: theme.opacity[100], | |
light: { offset: -300 }, | |
theme | |
})}; | |
getColor({ | |
variable: 'background.subtle', | |
transparency: theme.opacity[100], | |
light: { offset: 300 }, | |
dark: { offset: -600 }, | |
theme | |
})}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would be good to understand Design's intent for using a custom color / opacity combo.
With Chrome's color-picker tool, I got the "flattened" HEX value for the stripped row background color. That value corresponds to the color a visual user perceives when the row color (neutral (400:600)/0.08%) is applied over our default light / dark background.
Using this tool, I compared their DeltaE:
Light
custom: #f9f9fa
background.subtle
: #f8f9f9
Dark
custom: #1e2328
background.subtle
: #1c2227
As you can see, the colors are nearly identical.
Typically, a Delta E of less than 1 is not perceptible to the human eye.
If Table
is always rendered on top of a backdrop with a background.default
, would it make more sense to reuse background.subtle
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, subtle
makes more sense 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And thank you for the detailed breakdown / comparison with other components in this use case. TIL!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something I'm thinking about is what it means for the color and its semantics when we need to do a 6 level offset (plus/minus 600
). Does the color respect its design intent by the time its shade is offset by this much? @lucijanblagonic perhaps a question for you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The backgrounds of both GroupRow and Row (when striped) are set to the below value, per Flo's suggestion, which is the reason for my inquiry/curiosity around color intent with major offsets:
getColor({
variable: 'background.subtle',
transparency: theme.opacity[100],
light: { offset: 300 },
dark: { offset: -600 },
theme
})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That value corresponds to the color a visual user perceives when the row color (neutral (400:600)/0.08%) is applied over our default light / dark background.
that is exactly the intent! we wanted a value that visually matches the v8 group/striped bg treatment. i've attached an image to visually describe the points below:
- at first glance,
background.subtle
was the first logical replacement, but that is intentionally a solid fill, and a solid fill would not respect the bg subtle, raised, and recessed treatments in both light and dark modes. - with that considered we opted for the existing neutral opacity, which targets 700 and 500 @ .8, but in light mode it was too dark of a bg (albeit dark mode bg was just fine)
- then opted for the grey-400 / grey-600 @ .08 as it was the closest match.
if there's a more efficient way to obtain that visual parity, then i'm all for it!
getColor({ | ||
variable: 'background.emphasis', | ||
transparency: DEFAULT_THEME.opacity[100], | ||
light: { offset: -300 }, | ||
theme: DEFAULT_THEME | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the context of tests, the preference would be to replace with rgba(PALETTE[color][shade], DEFAULT_THEME.opacity[amount])
rather than repeating getColor
code from the component implementation. It just makes the tests slightly more imperative and simpler to maintain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be outside the scope of this PR, but when Table.SortableCell
is in use, the header cells do not honor table sizing as expected. This bug exists in v8, but it would be nice if we can clean it up in v9.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, when you turn Table.SortableCell
off, they get placed in their correct positions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. I'll plan to see if that's addressable in a follow-on PR on main
so we can pull it over into next
after.
${colorStyles} | ||
|
||
${sizeStyles} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨
@@ -23,36 +23,79 @@ export interface IStyledRowProps { | |||
size?: ITableProps['size']; | |||
} | |||
|
|||
const baseRowColorStyles = ({ theme, isStriped }: IStyledRowProps & ThemeProps<DefaultTheme>) => { | |||
return css` | |||
border-bottom: ${theme.borders.sm} ${getColor({ variable: 'border.subtle', theme })}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nit] the preference is usually to separate border-bottom
from border-bottom-color
. And moving these values out to local variables makes the CSS more readable.
})}; | ||
`; | ||
}; | ||
|
||
export const StyledBaseRow = styled.tr<IStyledRowProps>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fwiw, this combined Styled...
components in one file is a bad code smell. Might be good to clean it up here.
There is an inconsistency with Not sure if there are any other implications to the border-color, @steue please take a look as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The dependency for @zendeskgarden/react-buttons
needs to be added to table's package.json
06aa20f
to
f17a9d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -16,7 +16,7 @@ const COMPONENT_ID = 'tables.cell'; | |||
|
|||
export interface IStyledCellProps | |||
extends Pick<ICellProps, 'isMinimum' | 'isTruncated' | 'hasOverflow' | 'width'> { | |||
size?: ITableProps['size']; | |||
$size?: ITableProps['size']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please note that the picked props above will continue to leak in styled-components
v6.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went ahead and converted the remaining props to transient props and I think captured all the remaining spreadable props as explicitly converted. Doing another self review now, as well.
packages/tables/src/elements/Row.tsx
Outdated
ref={ref} | ||
tabIndex={isReadOnly ? undefined : -1} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the element component move, but in order to match previous the tabIndex
should follow {...otherProps}
so that it wins.
${colorStyles} | ||
|
||
${sizeStyles} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
${colorStyles} | |
${sizeStyles} | |
${sizeStyles} | |
${colorStyles} |
[nit] per API docs, these should be switched .. although it shouldn't happen, color should hold the more significant position if there happens to be a cascade.
`; | ||
}; | ||
|
||
export const StyledRow = styled(StyledBaseRow).attrs<IStyledRowProps>({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export const StyledRow = styled(StyledBaseRow).attrs<IStyledRowProps>({ | |
export const StyledRow = styled(StyledBaseRow).attrs({ |
[nit] type should no longer be needed for the attrs
.
@jzempel think you found a limitation with how backgrounds/borders intermingle in cases of truncation re: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@steue In order to resolve the issue JZ reported above, we need a solid border as one with opacity will result in truncated rows hiding the border. 😅 |
😓 in light mode |
It's probably best to use colors that we have available within those 12 steps, and accept the technical limitations. A big change in saturation and lightness in dark mode (like using blue-800/700) doesn't look good, and it's OK to have a subtle border as the background is much more prominent.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this is an acceptable workaround for the limitation posed. thanks for the discussion @lucijanblagonic! sorry and thank you @geotrev for explaining the issue and patience with the back and forth!
Description
Adds
light
/dark
mode support for Table components.Detail
In addition to updating to light/dark compatibility, this PR also:
IconButton
forOverflowButton
(with height/width overrides)isHovered
,isFocused
, andisActive
props fromOverflowButton
Checklist
npm start
)?bedrock
)