内容简介:There have been problems with theSo let’s say you simply added aThe problem arises when the user interacts with this element on a touchscreen: after the tap has been done, the hover effect is stuck on the element. This also occurs when the element is not e
There have been problems with the :hover
pseudo-class ever since the first web browser was installed on a touchscreen device. Of course there were solutions, but none of those were
the
solution. With the new Level 4 Media Queries, this issue seems like it’s solved for good.
‘Uhm… what’s the problem again?’
So let’s say you simply added a :hover
styling to an element of your webpage, so it gets some styling when the mouse hovers over it. Easy.
The problem arises when the user interacts with this element on a touchscreen: after the tap has been done, the hover effect is stuck on the element. This also occurs when the element is not even activated by the tapping, for instance if it was touched during scrolling.
If the dragging starts on the element, the hover effect is applied, because technically the pointer object (this is your finger most of the time) is over the styled element. This is a problem in itself: on a touch device, this translates as some unwanted interaction to the user.
However, it gets worse: after the dragging has stopped, the hover effect stays activated!
This will definitely confuse some of your users, and that is never a good thing. Something needs to be done.
‘There must’ve been a solution already…’
Well, there are some, most of them are covered in this excellent article
. The best one of those includes using JavaScript to detect whether the screen has touch capabilities, applying a class to the body
based on that and then explicitly referring to this class every time a :hover
effect is added to any element.
body.nontouch nav a:hover {
background: yellow;
}
This has a few issues from the beginning:
- A developer can create the detection script that works well today, but what about in two months, when some new tech pops up? Laptops with touchscreens? Detachable touchscreens? Apple Pencil? I’d rather not worry about this during development.
- One would think that the JS community has a package ready and armed for just this problem, but that is not the case.
- When employing a component-based JS framework with encapsulated styles, this solution just throws a huge wrench in it. Any time hover effects are used, that component’s styles must reference this global class. Inconvenient.
- Not two projects that use this solution will be exactly the same. Maybe one works well on a special device, but not the other. There should be a standardized way to solve this.
Enter Level 4 Media Queries
Media queries are great. They singlehandedly enabled responsive web design, and are a cornerstone in today’s mobile first web development. As an excellent initiative, the W3C added Interaction Media Features as a candidate recommendation for L4 Media Queries, which we can use to distinguish touchscreen devices.
The four media queries included are hover
, any-hover
, pointer
and any-pointer
. These provide information about the hovering capability and the type of the user inputs. The info can be about just the primary input, or about any input that is available. For instance @media(hover: hover)
will be true if the primary input can hover (e.g. a mouse cursor), and @media(any-pointer: coarse)
will be true if any input is of limited accuracy (such as a touch input). These media features provide enough information to handle :hover
properly.
One issue is that these queries are just a candidate recommendation at the moment, meaning that they could change or even be removed any time. Keep this in mind when working with them, and decide if it works for your project. This definitely works for us at the moment, and we have high hopes for these specifications. The fact that all major browsers have implemented these queries (except IE of course), makes us even more optimistic for the future.
‘So what to do exactly?’
From a developer’s view, we are looking for a solution that is the easiest to use and maintain. From a UX perspective, we are looking for a solution that is the least confusing and the most enjoyable for the user.
This means no hover effects on touchscreen only devices, and using them everywhere else. The special case here is laptops with touchscreens, but there we can expect that the mouse/touchpad is used most of the time. Even if there is a stuck hover effect, the user can easily use the mouse/touchpad to double-check the problem and dismiss it. Fortunately laptops with detachable touchscreens will go into a tablet mode when detached, which the media query correctly handles.
Here’s a test site
where you can test your own device to see which of these media queries apply to it, and also see some of the most popular devices’ settings. Browsers on Android have some inconsistencies, but the other devices seem to have these sorted out. Checking these different devices, he bottom line is that targeting laptops is possible with the query @media(hover: hover) and (pointer: fine) {}.
@media(hover: hover) and (pointer: fine) {
nav a:hover {
background: yellow;
}
}
Did I miss something? What do you usually use in these cases? I’m quite happy with this solution, but let me know if there’s a better one out there!
The cover picture is from here .
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Ruby原理剖析
[美] Patrick Shaughnessy / 张汉东、秦凡鹏 / 华中科技大学出版社 / 2016-12-1 / 78.80元
《Ruby原理剖析》解开Ruby编程语言的魔法面纱。全书图文并茂、深入浅出地剖析了Ruby编程语言的核心工作原理。作者本着科学实证的精神,设计了一系列实验,帮助读者轻松了解这门编程语言的工作奥秘,包括Ruby如何用虚拟机执行代码,Ruby的垃圾回收算法,以及类和模块在Ruby内部的关系等。一起来看看 《Ruby原理剖析》 这本书的介绍吧!