Skip to content
This repository was archived by the owner on Oct 1, 2019. It is now read-only.

Treatment of hover state on devices without hover capability #65

Closed
triblondon opened this issue Nov 21, 2013 · 14 comments
Closed

Treatment of hover state on devices without hover capability #65

triblondon opened this issue Nov 21, 2013 · 14 comments

Comments

@triblondon
Copy link
Contributor

Currently the standard says:

Consider iOS's emulated-hover behaviour on elements whose :hover style changes display or visibility

At Labs our preferred option is to prevent hovering on devices that lack hover capability, by adding a .hoverable selector prefix to all hover pseudoclass selectors:

.hoverable a:hover { color: blue }

and then only adding it to the <body> element if the input device has hover capability. This also means that hovering can trivially be disabled when it would get in the way, eg during scrolling or animation. This would however require product developers to add the hoverable class to their body element if they wanted any of the origami components on the page to support hover. Thoughts?
@kavanagh
Copy link
Member

I use this approach too.

Also for things like navigation I use something like:

.ig-hoverable .navbar a:hover,
.ig-touch .navbar a.active { color: blue }

And some things like Chrome Pixel could get either/both classes.

I think it would be good to agree on something like this and get the product dev to add the classes to the body. It's essentially extending the idea of having agreed feature classes (alla Modernizr) on the root node.

@triblondon
Copy link
Contributor Author

Ideally rather than specifying classes you'd use a variable with documented configurable selectors, so the product could combine several into one if they didn't need the granularity.

@richard-still-ft could you review this, as I think you wrote the line I quoted in the issue description.

@triblondon
Copy link
Contributor Author

Nudging @richard-still-ft

@richard-still-ft
Copy link
Contributor

Actually I think it was @dansearle-ft who wrote the quoted line. Personally I would prefer not to introduce a dependency on script to make components behave. For responsive articles the mantra is to design touch friendly components without designing in pointer specific functionality, hover states should only be used where they have no impact. It remains to be seen though how practical that is.

@triblondon
Copy link
Contributor Author

Agreed that this should be approach, on the basis that from the perspective of a product developer:

  • Out of the box, modules give you no hover functionality
  • Adding .o-hover-on to <body> will give you standard hover functionality, unconditionally, from all modules (with no javascript)
  • Adding the o-hover module JS to your JS bundle will also give you smart enabling and disabling of hover based on the following logic:
    • Page is loaded with hover ON
    • If touch events exist, hover is turned OFF and an event handler is bound to mousemove
    • If that event hander fires, hover is turned ON and the event is unbound
    • While/when hover is ON, an event handler is bound to the scroll event. When the page is scrolled, if the hover is ON, it's disabled during the scroll and reenabled afterwards.

I'll implement a module to do this.

@ghost ghost assigned triblondon Jan 9, 2014
@wheresrhys
Copy link
Contributor

Is it worth turning this on its head

  • no class on html = hover events turned on
  • no-hover class on html = turn off hover effects

Then if we go forward with @kavanagh's suggestion #86 and #88 (comment) this could be put in a Modernizr plugin

Modernizr.add('hover', function(){

  if (initial test for touch) {
     on('mousemove', function () {
        html.className = html.className.replace('no-hover', 'hover');
        Modernizr.hover = true;
     })
     return false;
  } else {
     return true;
  }
});

@triblondon
Copy link
Contributor Author

The problem with modernizr is that it doesn't have a commonJS interface, so we can't build it in as a dependency of components. Feel free to open a new issue to discuss how we might use Modernizr, because I don't see a robust way of including it in Origami right now.

@kavanagh
Copy link
Member

I'm not sure that Modernizr test callbacks are executed in a predictable order. i.e the touch test might not have been evaluated before this test.

@dan-searle
Copy link
Contributor

I like the idea of :hover working by default, but doing that would result in more verbose CSS, as you'd have to override the hover state when the no-hover class was present, and you wouldn't necessarily know what to override with:

.thing:hover {
    color: red;
}

.no-hover .thing:hover {
    color: ?; // what was its color in its non :hover state? 
}

Also, Modernizr could do the initial test, but could it do the ongoing mousemove/touch event handling?

@kavanagh
Copy link
Member

Also a window can be moved between a non-touch and touch screen.

I think I like the idea. I'm not sure yet.

@triblondon
Copy link
Contributor Author

Doesn't really matter if the screen supports touch or not - we're not proposing to turn touch off. If you loaded the page on a device that didn't have a mouse and then plugged one in, it would immediately acquire hover effects as soon as you moved your mouse over the page.

@wheresrhys
Copy link
Contributor

@kavanagh Any test callbacks you add using Modernizr.add must surely be run after synchronous internal modernizr tests, and https://github.com/Modernizr/Modernizr/blob/master/feature-detects/touchevents.js is synchronous

@dansearle-ft Good point. It could still support the normal way around, with the need for the product developer to hard code hoverable into the html tag's class and then Modernizr woudl take care of toggling the class. I'm pretty sure listeners for the ongoing tests can be wrapped in a Modernizr test

@kavanagh
Copy link
Member

@triblondon I meant that the event listener is added only if touch is supported. At the time the Modernizr test is evaluated in the code above touch might not be supported but might be in the future of the page's lifespan, hence the hover class would never get added.

I think I dont like the idea.

@triblondon
Copy link
Contributor Author

I've published my lib here:
https://github.com/Financial-Times/o-hoverable

Still concerned that there's no safe way to rely on Modernizr in a component, so if you want to pursue that, could you make the case in a new issue?

triblondon added a commit that referenced this issue Jan 10, 2014
@triblondon
Add docs for hoverable, see #65
768d68a
@triblondon triblondon removed their assignment Feb 25, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@wheresrhys @kavanagh @triblondon @richard-still-ft @dan-searle