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

Overriding responsive array syntax #1105

Closed
ntaylor89 opened this issue Aug 6, 2020 · 2 comments
Closed

Overriding responsive array syntax #1105

ntaylor89 opened this issue Aug 6, 2020 · 2 comments

Comments

@ntaylor89
Copy link

ntaylor89 commented Aug 6, 2020 •
edited
Loading

Describe the bug
Sorry if this has been reported (I did a little search, didn't find anything).

If you use responsive array values for a prop in the theme object, but then
don't use them when you override it with the sx prop, then the default theme value
is applied.

To Reproduce
I'm on version 0.3.1. Can reproduce in Chrome and Safari.

If in my theme, I can provide a default height value as a responsive array, like so

variants: {
  forms: {
    input: {
      height: [3, 4, 5]
    }
  }
}

But if I override it in an instance like this

<Input
  sx={{
    height: 2
  }}
/>

Then all of those breakpoints are still applied, and the height of 2 doesn't get applied.

Expected behavior

From a JSX syntax perspective, I expect the height given to completely override the height
in the default. I get that what's happening under the hood with CSS is a bit differnet though.

If this is a wontfix, I'd suggest maybe adding a note to the docs?

Additional context
From what I can tell, this is happening because the media queries are appended to the end of the stylesheet.

i.e.

<head>
  <style data-emotion="css">
    .classA { height: 3rem }
  </style>
  <style data-emotion="css">
    @media screen and (min-width: 50em) { .classA {width: 32em }
  </style>
</head>
@jxnblk
Copy link
Member

jxnblk commented Aug 10, 2020

I think this has been discussed in #43 and #720. It's something I'd like to address for v1, but haven't seen a good solution yet from the implementation side

@ntaylor89
Copy link
Author

Thanks. I'll go ahead and close this then, and follow along on those.

Really big fan of the lib BTW.

@lachlanjc lachlanjc mentioned this issue Feb 12, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jxnblk @ntaylor89