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

Should we add a "Scoped Hover" mixin as a default #33

Open
ReneDrie opened this issue Jan 29, 2018 · 4 comments
Open

Should we add a "Scoped Hover" mixin as a default #33

ReneDrie opened this issue Jan 29, 2018 · 4 comments

Comments

@ReneDrie
Copy link
Collaborator

ReneDrie commented Jan 29, 2018

In "seng-scss" we have a "hover" mixin. But unfortunately this isn't working the way it's supposed to work from within the node-module.
The idea is to use a global class (most of the time a touch check from modernizr) as a prefix to the element. And then add :hover to the rule before displaying all content.
I think this is a nice solution to easily maintain hover states for supported devices only.

The problem with this is that we're working with CSS modules, where the local classes will interfere with the global classes. And also, by default, the modernizr isn't set-up to add the notouch class.

For the last couple of projects @larsvanbraam and myself used an adaptation from the hover mixin within our projects where we put the mixin in the global scope, and add the local selector to the mixin.
We've put this in asset/style/util/mixin/ and I think this would be a good idea to keep it by default there.
This will make sure the target is targeted correctly and we are easily able to update the check for when you want to support this custom hover functionality.

The mixin is as following:

@mixin scoped-hover($selector: null, $extraSelector: null) {
	// Add the no-touchevents to the global scope and locally use the provided selector
	:global .no-touchevents {
		:local {
			#{$selector}:hover {
				@content;
			}
		}
	}
	// When we have an extra selector like 'is-hover' we want to use that in the global selector
	@if $extraSelector {
		:global .no-touchevents #{$extraSelector} {
			:local {
				#{$selector} {
					@content;
				}
			}
		}
	}
}

Usage of this would be to put outside of the :local scope the following code:

@include scoped-hover('.link') {
	color: red;
}

We could remove the .no-touchevent, because the Modernizr set-up is empty by default. Or keep it as an option somehow.

Very curious on more ideas about this, and what you think.

@jesse-mm
Copy link
Collaborator

jesse-mm commented Jan 29, 2018

I think the approach makes perfectly sense for CSS module based approach 👍 . One suggestion is maybe to change the naming of the vars $selector and $extraSelector. Maybe naming them $localSelector, $globalSelector is more descriptive. As $extraSelector is a string you could also default it to '.no-touchevents'.

@pigeonfresh
Copy link
Contributor

+1 for the mixin!
Perhaps an option to remove seng-scss from the dev-dependencies and add the most used mixins and functions to the project itself? In that case we can call it hover too.

@larsvanbraam
Copy link
Collaborator

@jesse-mm If we would set the default value to '.no-touchevents' that would mean that every time we use the $extraSelector we would have to provide the 'no-touchevents' as well.

this would result in something like this:

@include scoped-hover('.link', '.no-touchevents .is-active') {
	color: red;
}

Personally i'm not a big fan of this! Renaming them to $localSelector and $globalSelector could be helpful though!

@ReneDrie we could leave out the no-touchevents by default and add a little bit of documentation at the top of the mixin on how to enable it? We do not want to add to much default configuration to a skeleton right?

@ThaNarie
Copy link

What if we move .no-touchevents to a scss variable that can be set in your project, this way the mixin is generic again (and could even be moved to seng-scss if that makes sense).

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

No branches or pull requests

5 participants