Cursor pointer: cursor ⚡️ HTML и CSS с примерами кода

Содержание

Правильный курсор на активных элементах

English language version:
“Correct Cursor on Active Elements”

На всех активных элементах по наведению должен меняться курсор. В большинстве случаев это будет cursor: pointer.

Под активными элементами подразумеваются ссылки, кнопки, селекты, лейблы вместе с чекбоксами или радиокнопками и другие аналогичные элементы.

«Активными» такие элементы должны называться, когда нажатие на подобный элемент вызывает какое-либо действие. Таким образом, ведущий на текущую страницу пункт меню, выбранная радиокнопка или задизейбленные кнопки и ссылки — не активные элементы, и по наведению на них ничего не должно меняться.

Мне казалось, что это правило очевидно, однако, оказалось, что очень многие разработчики считают иначе. Внимательно прочитав все точки зрения, я так и не нашёл ни одного серьёзного аргумента против добавления смены курсора по ховеру всем активным элементам.

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

Преимущества использования

cursor:pointer

Обратная связь

Лично для меня основная польза от смены курсора — обратная связь. В идеале у кастомных элементов должно быть прописано состояние при наведении. Скажем, подсветка фона или смена цвета текста. Но в реальной жизни подобное изменение может или вовсе отсутствовать (дизайнер не нарисовал, а верстальщик не подумал), или быть не особо заметным, не привычным или срабатывать не моментально. Таким образом, обратной связи может или не быть, или она будет не совсем очевидна.

Изменение же курсора — всегда моментально и одинаково. Клик, следующий за наведением, будет интуитивным, тогда как в противном случае мозгу придётся либо сопоставить положение курсора с элементом, либо распознать изменение и трактовать его как наведение на активную область нужного элемента.

Изменение курсора — самая естественная, заметная и понятная обратная связь, которая может быть в интерфейсе.

Определение границ активной области

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

В некоторых случаях, когда несколько элементов будут находиться рядом, одной смены курсора не будет достаточно для того, чтобы сказать над каким элементом находится курсор — в этом случае нужно менять ещё и визуальное отображение соответствующего элемента: менять ему фон, цвет текста или что-то ещё. Но это полезно делать в любом случае.

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

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

Аргументы против смены курсора

Как бы я ни искал, я не смог найти достойных аргументов против смены курсора над активными элементами. Большая часть найденных контраргументов можно описать фразой «не нужно ломать пользовательские привычки».

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

Дальше надо сразу отметить, что не все привычки полезные. Если идти на поводу у пользователей и давать им только то, к чему они привыкли, то прогресс остановится. Часто у пользователей формируются привычки, которые им только мешают. В качестве довольно яркого примера подобной привычки можно взять подписи к чекбоксам или радиокнопкам. Ленивые разработчики годами забывали связывать текст и соответствующие контролы, из-за чего пользователи обычно даже и не пытаются кликать на текст, тратя своё время и усилия на попытки попасть по маленьким областям контролов. Это отличный пример почему имеет смысл не просто связать контрол с лейблом, но и всеми доступными способами рассказать об этом пользователю.

Аргументы «по привычке» можно разделить на несколько категорий. Я попробую ответить на наиболее часто используемые аргументы против смены курсора над активными областями.

«В ОС используется обычный курсор»

В операционных системах преобладающий курсор — обычная стрелка.

Курсор над кнопками или другими элементами форм обычно не меняется при наведении. Однако, тут стоит задаться вопросом: а хорошо ли это? Привычно — да. Но удобно ли? Я бы не отказался от более явной обратной связи во многих десктопных приложениях — очень часто разработчики совсем забывают про ховер и приходится догадываться о кликабельной области наугад.

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

cursor: pointer, ранее использовавшийся только для ссылок.

Правда, случай с чекбоксами и радиокнопками немного особый: если вокруг них, с подписью, по ховеру меняется фон, то курсор-руку можно и не добавлять. Однако, надо не забыть сменить курсор для сопроводительного текста на default, ведь курсор-стрелка как раз чаще всего используется для выбора элементов. Но вот если выбор чекбокса или радиокнопки вызовет какие-то изменения на странице (скажем, раскрытие части аккордеона), можно добавить и курсор-руку для того, чтобы сказать пользователям о том, что «сейчас что-то произойдёт».

«Я вижу курсор — считаю это ссылкой»

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

Шли годы, сайты становились всё насыщеннее, на страницах появлялись разные кастомные элементы, в том числе и ссылки, стилизованные под кнопки. И, в большинстве случаев, никто не убирал ссылочное поведение — и на таких кнопках смена курсора оставалась. Если сейчас посмотреть на большинство подобных кастомных кнопок, сделанных ссылками, на них всех осталось поведение ссылок.

«Ссылку можно открыть в новом окне и вызвать для неё контекстное меню»

Ну да — ссылка это не кнопка, а кнопка — не ссылка. Но из этого не следует, что поведение кнопок и ссылок по наведению должно отличаться.

Никто не будет ожидать у кнопок возможностей открыть в новом окне или скопировать адрес. В каждом случае и кнопка, и ссылка будут иметь свой контекст, в котором пользователи могут или ожидать поведения ссылки, или же этого не ожидать. Неважно какой будет в этом случае курсор — если пользователи увидят курсор в контексте ссылки (а многие дизайнеры сейчас чуть ли не всё рисуют в виде кнопок), они будет обращаться с ней как с ссылкой не задумываясь.

И, наоборот, если там будет кнопка, а пользователи не будет ожидать ссылки, всё будет в порядке. Если они захотят прикрепить файл — их не смутит, что там, внезапно, курсор-рука. Если они захотят найти что-то через поисковую форму, их не смутит, что там на кнопке изменился курсор. Они просто на неё нажмут. Пользователи могут возмутиться разве что в случаях когда кнопка будет замаскирована под ссылку, не находясь при этом в контексте формы.

Дальше — больше. Очень часто можно встретить ссылки, которые не являются ссылками — я почему-то не слышал возмущений насчёт того, что у подобных псевдо-ссылок меняется по наведению курсор. Различные выпадушки, фильтры, раскрывашки катов, закрывающие крестики, ссылки «отмена» — на многих сайтах можно найти огромное число элементов с изменённым поведением, но везде на подобных элементах остаётся смена курсора по наведению. Почему бы в этом случае не добавить курсор к кнопке или селекту, чем они будет отличаться от всех этих элементов?

Кстати, вот отличный пример передового сервиса г+:

Если хотите, можете попробовать догадаться, какие из отмеченных цифрами элементов изначально являются ссылками, какие нет; у каких есть курсор-поинтер, а у каких — нет. И что вообще произойдёт если на тот или иной элемент навести курсор, а потом и нажать. Чуть позже я дам ответ, а пока продолжу.

Если прямолинейно говорить, что «всё, у чего есть href — должно иметь курсор-поинтер, а то, у чего нет — не должно», то могут возникнуть некрасивые противоречивые случаи: в разных местах визуально кнопкой может быть сделана и ссылка. Если у таких элементов будет различаться поведение по ховеру, то это будет смущать пользователей больше, чем если бы у них было любое, но одинаковое поведение. Другой случай — когда рядом находятся и кнопка (

button или input), и псевдо-ссылка. Например, часто делают попапы с кнопкой «Ок» и ссылкой «отмена». Тут получается так, что у кнопки курсора нет, а у ссылки (которая ссылкой только притворяется) — курсор есть. Я считаю, что подобные неоднородности только мешают. Но из двух вариантов приведения к общему знаменателю кто выберет отсутствие курсора по ховеру у ссылки?

Теперь рассмотрим ситуацию с отключённым состоянием. Что, если мы задизейблим какую-то кнопку? Она перестанет нажиматься. А если задизейблим ссылку? По-хорошему, мы должны будем убрать и курсор. Представим: сначала пользователи сталкиваются с задизейбленной ссылкой без курсора, потом каким-то действием её раздизейбливают и видят сменившийся курсор. Потом где-то в интерфейсе пользователи видят кастомную серую кнопку без курсора — как в этом случае пользователям понять, что она не задизейбленна?

В итоге можно собрать множество примеров конфликтов кнопок, ссылок, их состояний и поведения. Подобные разногласия будут возникать только в случаях когда курсор меняется строго у элементов-ссылок, если же приравнять смену курсора к любой смене состояния (когда логично было бы менять фон/цвет/что-то ещё), то этих проблем не будет.

Вернёмся к иллюстрации из г+:

Итак, список с разъяснениями где какой элемент:

Пермалинк поста, ок. Ссылка есть, по наведению появляются подчёркивание и курсор.
Это вовсе не ссылка, просто текст 🙂
Это псевдоссылка, ссылки нет, по ховеру — и подчёркивание и курсор. По клику появится дропдаун.
Аналогично — просто контрол, без ссылки, по ховеру меняются цвет и курсор.
Опять не ссылка. В этом сниппете ссылкой являются только заголовок и картинка.
Тут и юзерпик, и имя — ссылки. Две, не связанные, но ведущие в одно место, на обеих меняется курсор по ховеру, у текста появляется подчёркивание.
Псевдоссылка — без хрефа. Как положено, появляется подчёркивание и меняется курсор.
Казалось бы — кнопка. По ховеру курсор не меняется, но — внезапно — появляется выпадушка. По ховеру.
Ок, допустим, «системный» элемент (хоть и кастомный) — кнопка — не имеет курсора. Но последним элементом тут обозначен чекбокс (который тоже, по той же логике, «системный») с подписью. Но тут, внезапно, хоть ссылки-то и нет, курсор по ховеру меняется. Плюс еле заметно подсвечивается чекбокс.

Что тут можно сказать? Никакой последовательности, куча интерфейсных ошибок и отсутствие курсора на кнопке. Выводы можете сделать сами.

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

«В спецификации написано…»

SelenIT приводит такой аргумент, что в спецификациях CSS2.1 и CSS3 Basic UI сказано: «The cursor is a pointer that indicates a link». Кроме того, он ссылается на сообщение Жерара Тальбо, в котором он отказывает в изменении одного из тестов к CSS 2.1. Однако, вряд ли подобное сообщение можно как-либо трактовать в пользу отсутствия курсора у кнопок. Контекст сообщения — тесты к спецификациям, и если в спецификации написано о том, что «курсор-поинтер указывает на ссылку», то это должно и в тестах значить только это.

Обновление 2018-10-16: После долгой битвы в ишьюс CSSWG, у нас получилось протолкнуть более корректную формулировку для этого дела!

В спецификации не сказано, что этот курсор не может использоваться для чего-либо ещё. Указано, скорее, его применение по умолчанию. На месте разработчиков спецификаций я бы изменил этот момент на «The cursor is a pointer that indicates an element that can be clicked» (по аналогии с тем, что предлагалось в тесте) или аналогичное, более общее, высказывание.

Это место в спецификации так и тянется как минимум с 1997 года, но веб с того времени сильно изменился и уже нельзя говорить о том, что «курсор-указатель указывает на ссылку», фактически его уже очень часто используют и для многих других элементов.

«Мерцание»

Мне тут подсказали ещё один аргумент: если на странице много активных элементов, то при перемещении курсор будет постоянно «мерцать», меняя состояние с обычного на поинтер.

Но такой аргумент — не проблема курсора на активных элементах. «Мерцание» курсора будет всего лишь симптомом, а проблемы могут быть следующими:

Активные элементы могут быть расположены не вплотную друг к другу. В этом случае, во-первых, пользователям будет сложнее попасть по нужному элементу, во-вторых, «мерцание», скорее всего, будет проявляться не только в смене курсора, но и в смене фона, текста, или чего-то ещё. По-хорошему, все однородные активные области элементов должны находиться как можно ближе друг к другу.
Другая, более редкая, проблема — захламлённость интерфейса. Если у вас вся страница утыкана всевозможными активными элементами, то это значит, что пора задуматься все ли они тут нужны прямо сейчас, и не стоит ли что-то упростить или упорядочить.

Итого

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

Ну а каких-то критичных недостатков у добавления курсора по ховеру просто нет — даже если каких-то пользователей это может немного смущать — бóльшему числу пользователей это облегчит жизнь.

Да, конечно, если у кого-то есть чем дополнить или опровергнуть часть высказанных мной утверждений — конкретные цифры, замеры и аргументы приветствуются. Все места, где я пишу о том, что «кому-то это облегчит жизнь» — чисто умозрительные и не подтвеждённые цифрами. Но всё говорит за то, что так оно и есть — так что спорить с этим можно только после A/B-тестирования и сравнения его результатов.

Ссылки

Заметка Криса Койера о том, как добавить ссылки кликабельным элементам.
В комментариях приводятся всё те же доводы про привычки и операционные системы, плюс консервативные, не подкреплённые аргументами взгляды на то, что только ссылки должны иметь курсор-поинтер.
Заметка Дмитрия Фадеева про соответствие курсора
В этой заметке Дмитрий приходит к заключению «Если тип курсора неверный, то нужно задавать его, используя CSS-свойства cursor», приводя в пример кастомные кнопки и плейсхолдеры для инпутов.
Слайды доклада Вадима Макеева «Жми сюда!»
Доклад больше о том, что функциональность элемента должна отражаться в используемых html-тегах, но в одном месте Вадим пишет про кнопку: «Делать лапу cursor:pointer совсем не нужно» и не приводит никаких аргументов в пользу этого утверждения. Надеюсь, прочитав эту статью, Вадим или изменит свой взгляд по этому вопросу, или напишет аргументы в пользу своего высказывания.

Опубликовано 22 января 2013 г. с метками: #Practical #Design #Accessibility

Correct Cursor on Active Elements

Русскоязычная версия:
«Правильный курсор на активных элементах»

Every active element must have a set cursor on hover. And it should be cursor:pointer in most cases.

By active elements I mean links, buttons, selects, labels with checkboxes and radio buttons, and other similar elements.

Those elements should be treated as “active” when clicking on such element results in any action. Thereby a menu item for the current page, checked radio button or disabled buttons or links are not active elements, so they shouldn’t have any change on hover.

At first I thought it’s obvious, but then I found out there are a lot of developers who think otherwise. And I didn’t find any proper arguments against cursor:pointer for active elements after reading all their points of view.

In this article I’ll tell you my arguments at first, and then I’ll discuss all the arguments against my point of view, describing why those arguments hadn’t incline me from it.

Benefits of using

cursor:pointer

Visual Feedback

For me the main profit from changed cursor is the visual feedback. Ideally every custom element should change its state on hover. However, in real life such state could be absent or wouldn’t differ much from the original state, or would happen with a transition. So there would be no feedback, or it would be not obvious.

But you surely would see when the cursor changes — this happens instantly and stable. The click that could follow the mouseover would be intuitive, otherwise the brain would need to match the position of the cursor with the element or spot the element’s change and then find out if it’s a hover state over this element’s active area or something else.

Changing of the cursor is the most natural, noticeable and obvious feedback you could easily add to any element. Of course, it’s not the best variant, but it’s cheap and easy. If you could add a distinct visual state on hover, then it would be even better.

Delimitation of the active area

There are a lot of cases when you should hint to the users that they could click already. You could often want to increase the clickable area of different elements, like for small icons or for menu items placed near the window edges. In those cases adding a cursor on hover would help users to find out when they could click on an element.

In some cases, when there are adjacent elements, the cursor wouldn’t be enough to tell which element is hovered — in those cases you should change the visual state of those elements.

Anyway, if you’d hint users when to use any specific active element, users would know it and it would be easier for them to use the UI next time — they’d need to aim with less precision, because they’d know that active area of an element could be bigger than it can be seen. And when they’d move the cursor they could click right at the moment the cursor would change. Otherwise, if an element don’t change its cursor on hover, the users would need to aim carefully to hit the area of a small element like icon or checkbox.

And I could argue if someone would say the active area of an element should be as big as its visual representation, but I’ll keep my arguments on this topic for another article.

Arguments against changing the cursor

I really did try, but hadn’t find any proper arguments against changing the cursor over the active elements. Most of those arguments can be described as “Don’t break users’ habits!”

But you can’t treat the presence of habits as an argument. This means there was one of the possible solutions and it was either the only one there, either it was the best at the moment. The habit should be treated in its context, and in context of what would happen if we’d brake it. Would it be destructive in some way, or it would be just a matter of minor users’ discomfort?

Another fact is that not all of the habits are good. If we’d always stay with the users’ desires, the progress would stop. Often users become used to the things that only hinder them. A clear example of such bad habit are labels for checkboxes and radio buttons. Lazy developers didn’t bind them together for years, so users often don’t know what the labels could be actually clicked, so they spend their time and efforts trying to hit those little areas of those little controls even if the labels are clickable too. It’s a great example why you should not only bind the inputs with labels, but also tell users about it with all possible ways.

We could divide the “habits arguments” into different categories. I’d try to answer the most frequently used arguments against the changing of the cursor on hover.

“The cursor doesn’t change in users’ OS”

In OS the most used cursor is just an arrow. It doesn’t change over most of the system controls like buttons. However, the question is “Is this really good?” Is it familiar? Yes. But is it usable and could it be better? I often see how some desktop app is not usable because I need to guess where to click — there are no signs of active areas.

When we are talking about desktop we should also talk about games too. Unlike apps, games often have custom cursors that are changed over different UI elements. In comparison with modern games most of the web apps feel like the old games with pixel-hunting — you have to guess where to click and where to hover in order to do something. However, recently the web apps tend to use more cursors for different actions like drag-n-drop or resize. But why then use the default cursor for buttons? cursor:pointer would fit great there. And when we’d look at the checkboxes and radio buttons, then there should be not only a distinct visual hover state like changed background, but you shouldn’t forget to set the cursor:default for them — that’s the cursor the desktop apps mostly use to select something. But if selecting the checkbox or radio button results in a UI change like expanding the accordion’s section, then the best cursor would be a pointer one — telling something would happen after you’d click.

Web apps are not the same as desktop apps, there are a lot of new patterns and UI elements there, so it’s time to think again and decide which habits to forget.

“I see a pointer cursor and think it’s a link!”

Ah, that’s another often used argument. When there were no web apps, there were only linked textual documents. The apps mostly didn’t have such links, so in browsers, to tell users what the HTML <a> is, there appeared underline, blue color and a pointer cursor. And as all the buttons and inputs were system controls, they inherited the default behavior with the default cursor.

Years passed and sites become more complex and UI-rich, designers created new controls and they often were just the links disguised as buttons and other elements. And in most cases nobody removed the links’ cursors. So if you’d look at the modern sites, most custom buttons would be actually links and would have cursor:pointer there.

In fact, you should forget the “pointer is for links” thing a long ago.

Well, yeah — links are not buttons, and buttons are not links. But that doesn’t mean the behavior of hover for links and buttons should differ.

Nobody would expect an ability to open something in a new tab from the button. In each case both the links and the buttons would have their context where users could either await the link’s behavior, either they would just use the control they have. And it really doesn’t matter which cursor the users would see — if users would see a cursor in a links’ context, they would treat it as a link. But if users won’t expect a link, the button underneath would be ok. If users would like to attach a file, they won’t need the link’s behavior. If users would like to send a form, they would just do it, even if there’d be a cursor:pointer on it, the users won’t go away and won’t try to open it in a new window — they already know how to use search forms. The only place when the users would be confused — if you’d do it reverse: make a button look like a link — be blue and underlined.

Further more — there are already a lot of links that don’t look like ones and other elements that are disguised as links. Different dropdown handles, filters, cuts, closing icons, “cancel” links — a lot of sites have a lot of elements using different tags in HTML for them and having this cursor:pointer. Why would then simple buttons or selects have default cursor instead of the one all other controls have?

There is a great example from one company’s service:

You could try to guess which marked elements are links, which are not; which have cursor:pointer, which don’t. What would happen when you’ll hover or click any of those elements? You can think for a while, and I’ll give you an answer later.

If you’d say straightforwardly “only everything that have href must have a cursor” then a lot of confusing things could appear. For example, if there would be one element visually, but with different tags underneath (like bootstrap’s buttons are), then it would be strange and confusing if there’d be a difference between the button made of <a> and <button>. So, I hope everyone would agree that the cursor over every such element should be consistent. And If you’d make the default one, then it would become really confusing, ’cause there could be a disabled state for this button and you would need to spot the change of the button’s background in order to know could it be pressed or no. And then if you’d remove the cursor:pointer from an actual link it won’t be any better, so the only proper way is to have cursor:pointer in both cases.

We could find a lot of examples with buttons, links and their states would conflict with each other and the overall UX. Making the cursor:pointer to mark only actionable elements makes sense and won’t create any conflicts other than slight discomfort for some persons.

And let’s get back to one strange service:

So, what’s there?

It’s the post’s permalink. Ok, it’s an actual link, there is an underline and a pointer on hover.
Hey, it’s not a link, it’s just a text, not clickable at all.
That’s pseudo-link, there is no actual link, but there is a hover state as the one on permalink: underline and pointer. Clicking here calls a dropdown to appear.
Another control that behaves like link (changes color on hover and gets cursor:pointer), but there is no actual link. Again, dropdown on click.
This icon is not a link and clicking on it does nothing, while the other parts of the snippet — header and picture — are links.
There are two links: userpic and username. They’re not connected and have their own hovers: pointer and an underline for username.
It’s a pseudo-link, no href seen. And the underline on hover and pointer.
Oh, a button! A custom button. But what’t that? No pointer on hover! And even more — hover brings the dropdown, I feel like on a minefield there.
So, the button was treated as a “system” element, but what’s with checkbox? It and its label have cursor:pointer. Wow.

So, what could I say? There is no even slight consistency and a lot of other UI mistakes. But hey, there is no cursor:pointer on a button! I wonder which excuses the developer have for this.

BTW it’s very interesting to look at different services in the search for consistency, almost no one is perfect, so you could often find things to think about and to criticise on.

“But the specs say…”

SelenIT brings another argument (in Russian): both the CSS2.1 spec and the CSS3 Basic UI clearly states that “the cursor is a pointer that indicates a link”. He also gives a link to a Gérard Talbot’s message, where he declines a change to one of the CSS2.1 tests. However, it couldn’t be an argument for this issue — the context of this message is a test for spec, and if spec says something, then the test should cover only this.

Update from 2018-10-16: After a long battle at CSSWG github issues, we have managed to push the more correct wording to the spec!

In specs it is only said the pointer is supposed to be used for links, but it don’t imply you can’t use it for anything other than link. It states the default use of such cursor, nothing more. Moreover, I think this part in specs should be changed to something like “The cursor is a pointer that indicates an element that can be clicked” to reflect modern state of the web — ’cause the current statement is come at least from the year 1997 and a lot of things did happen since then.

“Flickering”

Here is another, different from habit ones, argument. If there would be a lot of actionable elements, they say, the cursor would blink a lot when you’d move it here and there.

But that’s not a proper argument, it’s a pointer for one of another problems:

Active elements could be placed not that close one to another. In that case it would be harder for users to hit those elements and there would be symptomatic flickering when you’d move the cursor from one such element to another. Ideally, those elements should have continuous active areas. And to delimit different elements in that case you should use the visual hover like changing background and not the cursorless gaps.
Another problem — cluttered interface. If you’d have whole page covered in active elements, then — yeah — the cursor would change a lot (however, it already changes a lot when you hover over text or other static elements). When you have a lot of active areas, it could be that you need to simplify something there.

Recap

In ideal situation every active element should have a distinct visual hover state. But even with such state it won’t hurt to add a cursor:pointer — it would only add clarity and would remove possible UI conflicts. And if you can’t find how to make a visual state on hover, adding pointer would be enough for most cases (however, if you’re working with a designer, it would be better to ask them to give you a correct visual hover state).

And there are just no other arguments against cursor over active elements than user habits. And there would be more happy users than those who moan.

However, if you have any other arguments I didn’t cover — I would like to hear them. If you know of any A/B-testing with different cursors — it would be very cool to look at the results of those.

Anyway, I hope now this topic is obvious and you would go and add the cursor:pointer to anywhere on you page where it is needed.

Chris Coyer’s snippet on adding pointer cursor
Except for the snippet itself, in the comments there are all the same arguments on habits and points of view without arguments at all.
Dmitry Fadeyev’s article on cursor’s affordance
In this article Dmitry comes with this statement: “If the cursor type is wrong, specify it using the CSS cursor property” and gives as an example custom buttons and input placeholders.
Vadim Makeev’s slides (in Russian)
Nice slides on using the right elements for right purposes and all those things, however Vadim says you shouldn’t make a pointer cursor for buttons and I disagree there. Hope he’ll make up his mind after this article.

Published on January 22, 2013 with tags: #Practical #Design #Accessibility

Thanks to Shagen Ogandzhanyan for some proofreading.

Сделать Windows более удобной для просмотра

Windows 11 Windows 10 Больше…Меньше

Если вы хотите сделать свой экран более удобным для просмотра, Windows предлагает множество функций и параметров, которые могут вам помочь. Вот несколько предложений.

Настройка размера и цвета

Чтобы настроить размер текста, приложений и других элементов, нажмите кнопку Пуск , затем выберите Настройки > Специальные возможности > Размер текста . Используйте ползунок рядом с Размер текста , чтобы увеличить размер только текста на экране. Чтобы увеличить масштаб всего на экране, нажмите кнопку Пуск , затем выберите Настройки > Система > Дисплей и измените раскрывающееся меню Масштаб в разделе Масштаб и макет на больший процент.

Сделать вещи больше

Если между элементами на экране недостаточно контраста, попробуйте использовать тему с высокой контрастностью. Нажмите кнопку Пуск , затем выберите Настройки > Специальные возможности > Контрастные темы , выберите один из вариантов в раскрывающемся меню рядом с Контрастные темы и выберите Применить . Вы можете выбрать между Aquatic , Desert , Dusk и Night sky .

Включите контрастные темы

Знайте, куда вы указываете

org/ListItem»>
Сделайте мышь более заметной, изменив цвет и размер указателя мыши. Выберите Пуск , затем выберите Настройки > Специальные возможности > Указатель мыши и касание и выберите наиболее подходящие для вас параметры.
Добавляя следы указателя, вы можете видеть, где мышь движется на экране. Нажмите кнопку Пуск , затем выберите Настройки > Bluetooth и устройства > Мышь > Дополнительные настройки мыши . В окне Свойства мыши выберите вкладку Параметры указателя , а затем Показать следы указателя .
Windows также может отображать визуальную обратную связь при касании экрана. Нажмите кнопку Пуск , затем выберите Настройки > Специальные возможности > Указатель мыши и касание , а затем установите Сенсорный индикатор на On .

Изменить текстовый курсор и указатель мыши

Увеличьте экран

Экранная лупа увеличивает часть или весь экран, чтобы вы могли лучше видеть слова и изображения. Чтобы быстро открыть экранную лупу, нажмите Клавиша с логотипом Windows + Знак плюс (+) . Когда экранная лупа открыта, используйте клавишу с логотипом Windows + знак плюс (+) или клавишу с логотипом Windows + знак минус (-) , чтобы увеличить или уменьшить масштаб. Чтобы закрыть экранную лупу, нажмите клавишу с логотипом Windows + Esc .

Открыть лупу

Дополнительные сведения о лупе см. в разделе Использование лупы для просмотра объектов на экране.

Применение цветных фильтров

Упростите просмотр фотографий, текста и цветов, применив к экрану цветной фильтр. Цветовые фильтры изменяют цветовую палитру на экране и могут помочь вам различать объекты, отличающиеся только цветом.

Чтобы применить цветовые фильтры, нажмите кнопку Пуск , затем выберите Настройки > Специальные возможности > Цветовые фильтры , установите для параметра Цветовые фильтры значение Вкл. и выберите наиболее подходящие параметры.

Чтобы быстро включать и выключать цветные фильтры, нажмите кнопку Пуск , затем выберите Настройки > Специальные возможности > Цветовые фильтры и установите Сочетание клавиш для цветных фильтров на Вкл. . Затем нажмите Клавиша с логотипом Windows + Ctrl + C чтобы включать и выключать их.

Открыть цветовые фильтры

Дополнительные сведения о цветовых фильтрах см. в статье Использование цветных фильтров в Windows.

Используйте экранный диктор для навигации по компьютеру

Экранный диктор — это встроенное в Windows средство чтения с экрана, которое читает вслух то, что у вас на экране, чтобы вы могли использовать эту информацию для навигации по компьютеру. Чтобы запустить или остановить экранный диктор, нажмите Клавиша с логотипом Windows + Ctrl + Введите .

Открыть экранный диктор

Дополнительные сведения об использовании экранного диктора см. в Полном руководстве по экранному диктору.