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

Idiomatic hover states #21

Open
s3ththompson opened this issue Jan 7, 2018 · 5 comments
Open

Idiomatic hover states #21

s3ththompson opened this issue Jan 7, 2018 · 5 comments

Comments

@s3ththompson
Copy link
Contributor

Is the the most idiomatic way to generate rules for hover states?

var textTransformHover = {
  prop: 'text-decoration',
  vals: {
    'u-hover': 'underline',
    'o-hover': 'overline',
    'lt-hover': 'line-through',
    'n-hover': 'none'
  },
  tail: ':hover'
}

It seems like something like this might be a little cleaner...

var textTransformHover = {
  prop: 'text-transform',
  vals: [
    'uppercase',
    'lowercase',
    'capitalize',
    'none'
  ],
  tail: ':hover',
  tailSuffix: '-hover' // or tailModifier: '-hover'
}
@jongacnik
Copy link
Owner

I wonder if we could solve this by accepting an object as tail:

{
  prop: 'text-transform',
  vals: [
    'uppercase',
    'lowercase'
  ],
  tail: {
    '-hover': ':hover'
  }
}

The key is appended to the className, the value is appended to the entire selector. If only a string is provided, it works as-is.

💡 But... Now that I'm seeing it, this brings up an interesting option of a slight api change. Where tail is actually just embraced as a pseudo-class option:

{
  prop: 'text-transform',
  vals: [
    'uppercase',
    'lowercase'
  ],
  pseudo: ':hover'
}

With this, we could assume we'll want a modifier to the classname, so we could generate that from the selector. e.g: -h from :hover so classNames end up looking like:

.ttu-h:hover{}
.ttl-h:hover{}

And of course we'd still accept object syntax to allow custom modifier, like -hover.

This is a breaking change, but tbh I've not been totally happy with the gr8-util api, so I'm open to this conversation about what the object could look like.

@s3ththompson
Copy link
Contributor Author

oh yeah, these are both pretty clean. Wouldn't you still need tail for clearfixes? in that case, pseudo could be an addition rather than a breaking change.

I think it could also be nice to be able to do something like this:

{
  prop: 'text-transform',
  vals: [
    'uppercase',
    'lowercase'
  ],
  pseudo: [ 'hover', 'active', 'focus']
}

Nit, but it seems slightly unnecessary (although maybe it reads clearer?) to include the colon on the arguments to pseudo.

And then the convention would be first dash comes from join, second dash comes from pseudoclass?

@jongacnik
Copy link
Owner

pseudo as addition and dropping the colon are both good calls.

Yes, I think the pseudo modifiers should always be appended with a - for clarity. The join option would specifically apply to how the property and value abbreviations are joined. So you could imagine something like:

{
  prop: { fc: 'color' },
  vals: {
    red: '#f00',
    blue: '#00f'
  },
  join: '-',
  pseudo: 'hover'
}
.fc-red-h:hover { color: #f00 }
.fc-blue-h:hover { color: #00f }

Gonna try to schedule myself to make these changes to gr8-util this weekend.

@jongacnik
Copy link
Owner

@s3ththompson opened jongacnik/gr8-util#2 in gr8-util for this. Maybe you can take a peek before we merge this over here

@jongacnik
Copy link
Owner

Adding a prefix option will make the pseudo option extra handy jongacnik/gr8-util#3

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

No branches or pull requests

2 participants