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.

Sign up for GitHub

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

Jump to bottom

Fixed padding issues in the toolbar #18570

Merged
merged 1 commit into from
Oct 31, 2023
Merged

Fixed padding issues in the toolbar #18570

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion packages/core/admin/admin/src/content-manager/components/BlocksEditor/Toolbar/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,9 @@ const SelectWrapper = styled(Box)`
div[role='combobox'] {
border: none;
cursor: pointer;
min-height: unset;
padding-top: 6px;
padding-bottom: 6px;
Comment on lines +50 to +52
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this necessary? 🤔 please don't say to match the mock-ups 😂 I'm more asking – why isn't the design-system working in this case and why does this toolbar have to break it – you break one rule somewhere and every rule can be broken at some point === chaos.

Is something not implemented in the DS correctly?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was already custom modifications made on the components in the ToolBar for 2 main reasons (making it as small as possible so it doesn't waste to much space on the editing area and removing the borders around the IconButtons to avoid having multiple borders at the same place separated by small spacings). With the current Select, the Toolbar is bigger so it goes against the first point, and we end up with elements with multiple sizes in it. The cleanest thing would be of course to have more input sizes in the DS (I think we already discussed it), but in the meantime I'm sure it's easier to add another small override.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in my opinion this is fine, we already have small style overrides here, I don't see why we'd block this one. Currently we have the worst of both worlds (style overrides and it doesn't look great)

what do you think @joshuaellis?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the reminder @remidej.

It's a shame we have to do this, but it shows another limitation of the DS imo. I agree, at least this is a consistent way of styling it, it'll be interesting to see if V2 is more flexible and i think this is a good case to feedback on when we get to it 👍🏼


&[aria-disabled='false']:hover {
cursor: pointer;
Expand Down Expand Up @@ -660,7 +663,7 @@ const BlocksToolbar = ({ disabled }) => {
<BlocksDropdown disabled={disabled} />
<Separator />
<Toolbar.ToggleGroup type="multiple" asChild>
<Flex gap={1} marginLeft={1}>
<Flex gap={1}>
{Object.entries(modifiers).map(([name, modifier]) => (
<ToolbarButton
key={name}
Expand Down
Loading