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

FileUploader shadows TextInput's borders #1581

Closed
pot-code opened this issue Dec 21, 2022 · 2 comments · Fixed by #1587
Closed

FileUploader shadows TextInput's borders #1581

pot-code opened this issue Dec 21, 2022 · 2 comments · Fixed by #1587
Labels

Comments

@pot-code
Copy link

pot-code commented Dec 21, 2022

When both <FileUploader> and <TextInput> present, TextInput's border would disappear.

Reproduction link: https://codesandbox.io/s/evergreen-ui-shadow-input-border-vveww1

@brandongregoryscott
Copy link
Contributor

brandongregoryscott commented Dec 21, 2022

Ah, good catch - I think this is from the style leaking issue in ui-box 5.2.0 - 5.3.0 (segmentio/ui-box#126). Upgrading our version to 5.4.0 should solve this.

Edit: I'm actually seeing this behavior as far back as 6.9.0, so my original hunch around the ui-box issue doesn't seem to hold. Going to dig into how those selectors were setup originally.

@brandongregoryscott
Copy link
Contributor

brandongregoryscott commented Jan 3, 2023

I put together a minimal reproduction sandbox using Box components only, which is where I think this problem lies:

https://codesandbox.io/s/fileuploader-textinput-border-minimal-reproduction-g0hk6l?file=/src/App.tsx

I believe we've had similar issues with the flex shorthand prop and the separate flex sizing props (flexGrow, flexShrink, flexBasis):

📢 Hey team, if you're using combo of flex and flexBasis props, make sure to not set them separately and use a shorthand version: flex="[flexGrow] [flexShrink] [flexBasis]" otherwise there's a risk your layout will not look as expected due to a complicated bug in ui-box (which is a base for all Evergreen components). For example, flex="none" flexBasis={100} => flex="0 0 100px".

Brief description of the bug: ui-box generates a separate class name for each rule and inserts it into a <style> in and applies these classes to your element in the order you've specified them, e.g. flex="none" flexBasis={100} => class="flex-none flex-basis-100". Problem is, browsers work differently and they apply classes ordered by specificity and order in which they were declared in the stylesheet. Here's when problem occurs:

  1. <Pane flex="0" flexBasis={100}/> - adds flex-0 and flex-basis-100 classes and browser applies them in this order: flex-0 flex-basis-100
  2. <Pane flex="none" flexBasis={100}/> - adds only flex-none class, because flex-basis-100 was already generated and added. Because flex-basis-100 was defined earlier than flex-none, browser applies classes in this order: flex-basis-100 flex-none, which will result in flex-none overriding flex-basis-100

In the short term, I think we can workaround this issue by using either separate border props for both of the theme objects, or by using the shorthand for both of these component's theme objects.

Additionally, I'm not sure the 'default' border for the TextInput should be 1px solid transparent - that seems like it should only be the case for the none appearance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants