Css media touch screen

@media (hover: hover) — CSS Media Query

This article was first published and hosted at jackdomleo.dev/blog/2020/hover-css-media-query. «The hover CSS media feature can be used to test whether the user’s primary input mechanism can hover over elements.» — MDN web docs Not to be confused with the :hover psuedo selector, this is a media query you may have never used or never considered using. Let’s look at an example and see how it could be improved using the hover media query. Let’s assume we’re using this HTML for the below demonstration.

Showing an icon on hover

This is a typical feature request. It’s not very detailed, but as front-end developers, it’s enough for us to work with and create a prototype button at the least. For this to work, we may jump to do something like this:

.button  background: darkorange; color: white; border: none; padding: 1rem; text-align: center; position: relative; cursor: pointer; > .button svg  height: 2rem; width: 2rem; position: absolute; top: 50%; right: 0.6rem; fill: currentColor; opacity: 0; > .button:hover  padding-right: 3rem; > .button:hover svg  opacity: 1; > 

This would for sure show the icon when the button is hovered! 💪 But it doesn’t work on my mobile. It doesn’t know I’m hovering the button. So, how do we cater for touch screen devices that can’t hover? A common solution would be to always display the icon on mobile devices (take note of this, I will come back to it later) and add the hovering functionality for larger screens by using a min-width media query, typically these are screens that are 768px or wider:

.button  background: darkorange; color: white; border: none; padding: 1rem; padding-right: 3rem; text-align: center; position: relative; > .button svg  height: 2rem; width: 2rem; position: absolute; top: 50%; right: 0.6rem; fill: currentColor; opacity: 1; > @media (min-width: 768px)  .button  padding-right: 1rem; cursor: pointer; > .button svg  opacity: 0; > .button:hover  padding-right: 3rem; > .button:hover svg  opacity: 1; > > 

Great! We now have a button that always shows the icon on devices with a screen width less than 768px and will initially hide the icon on devices with a screen width of 768px wide or wider. Chances are, this works for most cases and has been an acceptable solution for many years. However, we can’t assume a device doesn’t have a hover input mechanism just because of its screen width, and vice-versa. This is where our hover media query comes in. Let’s take a look at how we can refactor our min-width to use hover instead.

.button  background: darkorange; color: white; border: none; padding: 1rem; padding-right: 3rem; text-align: center; position: relative; > .button svg  height: 2rem; width: 2rem; position: absolute; top: 50%; right: 0.6rem; fill: currentColor; opacity: 1; > @media (hover: hover)  .button  padding-right: 1rem; cursor: pointer; > .button svg  opacity: 0; > .button:hover  padding-right: 3rem; > .button:hover svg  opacity: 1; > > 

Outside any media query, we define our base styles that apply to everything. Inside our hover media query, we define styles that are specific to devices that have a hover input mechanism. Can you see how this is better than determining hover specific styles based on screen size? It’s also a cleaner method because we define our hover styles in our hover media query, it’s grouped them nicely for us. These hover styles would be harder to identify in the stylesheet if they were encapsulated in a min-width media query. For a working example, I created a CodePen below (with a few extra CSS properties) that I hope will help 🙂.

Источник

Обнаружение сенсорного ввода для touchscreen или hover для мыши

Ещё совсем недавно информации о размерах экрана было достаточно для предположения, например, что мобильные устройства будут использовать сенсорный ввод для touchscreen, а пользователи устройств с экраном большего размера, вероятнее всего, используют для управления курсором мышь. Разнообразие устройств с помощью которых можно просматривать веб-сайт не позволяет полагаться только на размеры области просмотра (viewport), как на фактор, определяющий выбор CSS и отдельное поведение страницы для touch-устройств.

Когда-то можно было спокойно обходиться только получением размеров экрана:

.some-component < /* Устройства с сенсорным вводом */ >@media screen and (min-width: 1024px) < .some-component < /* Вероятно тут будет работать hover */ /* Наверное, это устройство с мышью */ >>

Сегодня это уже не очень помогает. У хорошего планшета разрешение экрана может быть сильно выше, чем у недорогого ноутбука. А кто-то может подключить свой планшет в качестве дополнительного монитора и таким образом получить возможность использовать наведение курсора (hover) на элементы веб-страницы с помощью мыши.

Медиа-запрос из примера выше не несёт никакой полезной информации о способах ввода и управления курсором. Поэтому для определения, как пользователь просматривает сайт и какой тип устройства ввода использует, следует анализировать что-нибудь кроме размеров экрана. Для этого можно воспользоваться некоторыми новыми медиа-запросами.

Level 5 Media Queries

Спецификация CSS Level 5 Media Queries, помимо уже знакомых для определения размеров области просмотра, предоставляет набор новых медиа-запросов.

Один из них – hover feature поможет определить, есть ли у пользователя возможности наведения основного указателя на элементы страницы с помощью мыши.

Возможные для применения этого медиа-запроса значения: hover (для устройства с мышью) или none (например, для планшета или смартфона с сенсорным вводом).

Медиа-запрос hover можно использовать следующим образом:

.some-component < /* Устройства с сенсорным вводом */ >@media (hover: hover) < .some-component < /* Тут будет работать hover */ /* Это устройство с мышью */ >>

Функции hover и pointer на самом деле являются частью спецификации Level 4 Media Queries, но лишь недавно стали поддерживаться большинством браузеров.

Это всё хорошо работает в большинстве браузеров, но в некоторых версиях Android есть функция, при которой долгое нажатие имитирует наведение (hover) и тогда этот медиа-запрос вернёт true . Чтобы предоставить этим пользователям те же стили, что и для других сенсорных устройств с touchscreen, следует обратиться к другой медиа-функции.

Pointer

Функция pointer проверяет, есть ли на устройстве указатель и точность указательного устройства. Возможные значения: coarse (грубое для, например, пальца на сенсорном экране), fine (точное, например, мышь) или none (отсутствие, устройство без указателя).

Добавление проверки pointer в медиа-запрос успешно обнаруживает сенсорный ввод и на Android-устройствах:

.some-component < /* Устройства с сенсорным вводом, в т.ч. Android */ >@media (hover: hover) and (pointer: fine) < .some-component < /* Тут будет работать hover и pointer===fine */ /* Это устройство с мышью */ >>

any-hover и any-pointer

Предыдущие методы использовали для определения основные устройства ввода. Когда недостаточно определять сенсорный ввод только по основному устройству ввода, можно использовать в медиа-запросах функции any-hover и any-pointer , которые проверяют любой тип ввода.

Таким образом, если используется устройство, которое реагирует как на мышь, так и на сенсорный ввод, any-hover: hover будет возвращать true . Cпецификация включает несколько примеров того, как это (а также более сложные комбинации) можно использовать.

Пример для javascript

Рассмотрим пример, когда при наведении на одинаковые картинки-ссылки нужно показывать всплывающие подсказки к ним. В обычных условиях у пользователей сенсорных устройств не будет шансов увидеть эту подсказку. Кликнув по изображению, пользователь сразу перейдет по URL-адресу ссылки и это может вызвать неприятные ощущения, поскольку ему заранее неизвестно, на какую страницу ведёт ссылка. В таком случае для устройств с touchscreen можно прервать щелчок и показать кнопку, которую пользователь сможет нажать, чтобы перейти к соответствующему URL-адресу.

Этот же медиа-запрос для обнаружения сенсорного ввода можно использовать и в JS с помощью matchMedia :

const list = document.querySelector('[data-list]') const isHoverableDevice = window.matchMedia( '(hover: hover) and (pointer: fine)' ) const blockLink = document.querySelector('[data-button-link]') /* сперва скроем blockLink */ blockLink.hidden = true list.addEventListener('click', (e) => < /* ничего не делаем, если target не ссылка, устройство не умеет hover */ if (!e.target.dataset.link || isHoverableDevice.matches) return /* Если это сенсорный экран, перехватываем клик показываем ссылку */ e.preventDefault() blockLink.hidden = false blockLink.innerText = `Visit $’s page` blockLink.setAttribute('href', e.target.href) >)

Доступность

В зависимости от пользовательского интерфейса, возможно, понадобится задействовать вспомогательные технологии, используя ARIA-атрибуты для объявления кнопки, когда происходит изменение или перемещение фокуса на кнопку. Этот пример из MDN демонстрирует, как использовать живые ARIA-регионы для объявления динамических изменений элемента.

Поддержка в браузерах

Эти медиа-запросы можно использовать прямо сейчас, поскольку они поддерживаются во всех современных браузерах и они помогут улучшить взаимодействие с пользователями всех устройств.

Источник

CSS Media Queries

It used to be that various techniques were employed to target specific mobile devices, including Javascript. In the past, we even had Internet Explorer specific HTML tags to target only those browsers.

Thankfully, those days are long gone, and we are left with a standardised set of media queries. In this section, we’ll be covering how they work.

Syntax

Media queris follow the same @ syntax used by CSS Animations. We can put CSS within a media query to say that it only runs if the criteria of that media query are met.

This lets us target smaller screens, amongst other things. Consider the following example:

div   color: red; > @media screen and (max-width: 1000px)   div   color: blue;  > > 

The above code sets all div s to be red. Then, if the screen viewport becomes less than 1000px, either because it is a mobile device, or the user resized the window, all div s will suddenly have blue text.

Notice that we mentioned screen and used the and keyword to chain multiple criteria. We have mentioned screen, but this can also be set to print for printed documents, or all for both. Let’s take a look at some of the most useful media queries available today.

Max/Min

As discussed, we can set a max-width, i.e. styles that only exist if the viewport is smaller than that width. However, we can also set a min-width, which is only for screens or devices above a certain size. The syntax is similar:

@media (min-width: 300px) > @media (max-width: 1000px) > 

Heights

We also have similar settings for height, as shown below:

@media (min-height: 200px) > @media (max-height: 800px) > 

Specific Widths and Heights

Although we can use maximum and minimum widths, we can also use the keywords width or height to select screen sizes between two values. An example is shown below:

This will target only screens between 200px and 1000px, which is more useful in some situations than having two separate clauses. The same can be done for height .

Orientation

Ever wanted to target phones only in landscape orientation? We can do that with media queries. Orientation accepts two values, either portrait or landscape . An example is shown below:

@media (orientation: landscape)  > 

Resolution

We can select pages by screen resolution, too. The below media query selects any screens with a pixel density more than 1.2. This is useful, because it also takes into account page zoom. For printed documents, we usually use dpi.

@media screen and (resolution > 1.2dppx)  > @media print (resolution > 300dpi)  > 

Hover and Pointer

Hover is very useful, since it lets us target pages which have hover capability. That means a page where the user can hover a mouse over it. Since most touch phones don’t have this, thye will not be targeted:

@media screen and hover   /* Only devices with hover capability, i.e. with mouses */ > 

Pointer

Less used, but divides between devices with fine input mechanisms, i.e. touchpads, mice, or styluses, and those with more ‘corase’ inputs, like touchpads. As such, it can be set to coarse , fine or none , none meaning there is no input pointer.

@media screen and (pointer: coarse)   /* Devices with inputs like touch, but no mouse pointer */ > @media screen and (pointer: fine)   /* Devices with mouse pointers or styluses */ > @media screen and (pointer: none)   /* Devices with no pointers */ > 

Interlaced and Progressive

Some devices render one line of pixels alternatively, allowing for a higher fps value. This is called interlaced, and usually on these screens fast movements are avoided to avoid combing or items appearing on one line, but not on the other. Progressive screens don’t have that problem. We can thus minimise movement for some old plasma TV screens using this media query with interlaced :

@media screen (scan: interlaced) > @media screen (scan: progressive) > 

Aspect Ratio

This lets us target specific aspect ratio screens, and show content differently. This is useful if we expect our pages to be displayed on a variety of different screens. We can also set min and max values.

@media (min-aspect-ratio: 16/9) > @media (max-aspect-ratio: 16/10) > @media (aspect-ratio: 4/3) > 

More Tips and Tricks for CSS

Источник