CSS-live.ru

Поведение курсора при наведении на текст

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

cursor

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

При определении значения «text» для свойства cursor спецификация поясняет: «Указывает текст, который может быть выделен. Чаще всего отображается, как l-образный текстовый курсор.»

Но, как вы наверное знаете, это может быть переопределёно в CSS, поэтому вы можете отображать курсор, какой захотите и в любое время. Заметьте, например, на сайте SitePoint с помощью CSS переопределено поведение курсора, который находится над обычным текстом.

cursor-sp

На данный момент я не могу припомнить другой сайт, где встречается курсор, который при наведении на текст не меняет своего поведения. Единственное, я помню, что когда на "A List Apart" был редизайн сайта, они изначально сделали точно так же, как сейчас мы наблюдаем на SitePoint, т.е. ипользовали курсов в виде стрелки (по умолчанию), но через некоторое время вернули поведение курсора назад, изменив его на курсор по умолчанию для текстов (в виде палочки)

Какое поведение правильное?

Если вы обратитесь к спецификации, то увидите, что «текстовый» курсор (вертикальный I-образный текстовый курсор) является правильным. И, если вы захотите узнать, к какому курсору привыкли люди, то вы получите точно такой же ответ, как и в спецификации — «текстовый» курсор.

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

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

Здесь это случается в каждом браузере, когда мы передвигаем курсор в адресную строку:

chrome-cursor

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

chrome-settings-cursorЗаметьте, что на странице настроек в браузере Chrome (которая является простой веб-страницей, внутри которой вы можете проинспектировать элемент и посмотреть код) переопределено дефолтное поведение при помощи значения «default» свойства cursor, когда курсор находится над текстом.

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

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

Дополнение: Как было отмечено в комментариях, многие заметили, что родные приложения используют I-образный текстовый курсор не только для редактируемого, но также и для любого выделяемого текста. Это имеет место в большинстве случаев. Лично я думаю, что I-образный текстовый курсор больше подходит в качестве индикатора «вставки текста» или «редактирования этого текста», чем индикатор выбора. И так же я считаю, что есть «родные» приложения, включающие выделяемый текст, в которых курсор является простой дефолтной стрекой-указателем. Но это не очень частая вещь, так что я в какой-то мере снимаю свои аргументы насчет обычных приложений, если рассматривать I-образный курсор как универсальный индикатор для выделяемого и редактируемого текста.

Заключение

Я не знаю исторической причины, по которой браузеры используют «текстовый» курсор на нередактируемом тексте. Некоторые сайты, такие как SitePoint, признали, что в этом отношении, может быть, было бы лучше следовать общим правилам.

На любой веб-странице, я думаю, это имеет больше смысла, если текстовый курсор используется для редактируемых элементов, типа textarea, input, и даже элементов с атрибутом contenteditable.

Что вы думаете? Браузеры всё время ошибались? Я не думаю, что мы сможем здесь повлиять на что-либо, но я полагаю, что если мы дождемся момента, когда используемые браузеры будут автообновляться, производители могли бы договориться использовать более интуитивное родное поведение в этом отношении.

Охх, и приношу извинения за все анимированные курсоры. Уверен, они ни у кого не вызвали раздражения :)

Оригинал статьи и автор

P.S. Это тоже может быть интересно:

12 комментариев

  1. Помимо редактируемых элементов есть смысл ставить l-курсор на тексте, который пользователь может скопировать. На остальном тексте уже без разницы какой курсор, но если у нас веб-приложение, а не сайт, то, наверное, лучше будет ставить не l-курсор. А вот ещ вопрос, развивая мысль статьи. Какой должен быть курсор на label-элементах (для примера можно посмотреть на 3 label вверху, где надо указывать имя, мыло и сайт). Мне всегда казалось, что надо ставить ссылочный курсор, потому что при клике на текст происходит действие.

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

      А вот насчет label… Я бы сказал, что на сайтах ссылочный курсор им не нужен, достаточно default, который уже отличает их от text для обычного выделяемого текста. Ну и неплохо бы подсветить их по :hover вместе с соотв. input-ом.

      Но у меня вообще давний пунктик, что "палец" как индикатор нажимабельности — не совсем правильно. По всем CSS-спецификациям, pointer — индикатор ссылки, а не кликабельности. Я считаю, что индикация кликабельности только сменой курсора — нечто сродни верстке каркаса таблицей: решение быстрое, но вынужденное, от бедности стандартных средств решения задачи, и повелась с той поры, когда IE поддерживал :hover только для ссылок, а тег button существовал только в черновиках. В руководствах по юзабилити нередки утверждения, что одной смены курсора недостаточно для визуальной обратной связи, а минздрав США и вовсе рекомендует, чтобы графические кликабельные области были очевидны и без курсора. Того же требуют сенсорные экраны. А если кликабельность видна и без курсора, то нужно ли его менять?

      Правда, до недавнего времени в cursor:pointer для label-ов была практическая необходимость: без этого они не передавали клик на input в iOS. Но как минимум в iOS7.1 этот баг исправлен и необходимости больше нет.

      1. >Насчет приложений, имхо, надо смотреть по ситуации

        Системы бывают разные :) В большинстве диалогов и приложений Linux, например, можно выделить и скопировать текст. Что бывает крайне удобно, когда надо найти информацию по этому тексту в поисковике, скажем, и т.п. И курсор там, естественно, превращается в «I».

    2. А я просто подведу свои итоги, как я это вижу:

      1. Курсор в виде пальца — для ссылок и чего-то открывающегося, например, другого окна, вкладки и т.д
      2. Курсор в виде вертикального l-образного текстового курсора — для выделяемого и редактируемого текста.
      3. Курсор в виде стрелки — для всего остального, например, лейблов, чекбоксов и т.д.

      1. Уж не знаю важны ли кому мои 5 копеек но я хочу видеть что курсор изменяется например на тот что в виде пальцп когда навожу на кнопку, чекбокс или лейбл. Мне так больше нравится чем неменяющийся курсор в виде стрелки.

        1. Важное замечание! Действительно, за многие годы пользователей и разработчиков настолько приучили к мысли, что у всего нажимаемого должен быть курсор-палец, что без него даже некомфортно. По-хорошему, имхо, нужно проводить полномасштабное A/B тестирование (причем желательно с обычными людьми, не разработчиками, опросы на околовебных технических ресурсах поневоле дадут смещенную выборку). Если простые пользователи стабильно будут предпочитать вариант с "пальцем", возможно, есть смысл переписать спецификацию. Правда, примеры вроде GMail намекают, что не так всё однозначно: вряд ли в Гугле не делали таких тестов, но кнопки действий типа "написать", "ответить", "вперед-назад" и т.п. там с обычной стрелкой, в отличие от ссылок на папки и т.п.

          Но я по-прежнему считаю, что в любом случае изменение курсора не должно быть единственным индикатором кликабельности элемента. Должен быть полноценный :hover, а курсор может быть (если большинству пользователей с ним удобнее) лишь приятным дополнением.

  2. В старой Opera (которая была на Presto) курсор над текстом был в виде стрелки. Потом было мучительно больно привыкать к новому поведению в Chrome :)

    1. Если не ошибаюсь, сама Опера отказалась от этого еще задолго до смены движка (где-то в окрестностях 11.6).

  3. Роман Комаров больше года назад писал на эту тему — http://kizu.ru/blog/cursor-text/

    Лично мне устоявшееся поведение кажется более удобным (пусть и "не правильным"), так как я часто выделяю мышкой куски текста в процессе чтения. В этом случае текстовый курсор удобнее.

    1. Мне тоже кажется, что текстовый курсор для текстовых элементов, с которыми возможны любые текстовые операции (выделение/копирование, вставка/редактирование и т.п.) — привычно, и незачем это менять. Курсор-палец для текстовых полей для меня выглядел бы дико, лично я бы решил, что это какой-то баг))

  4. Cпасибо за перевод :)
    Статья понравилась, раньше об этом не задумывалась, а щас благодаря таким педантичным (очень в хорошем смысле) людям которые замечают разные детали и относятся к этому исследовательски, обратила внимание  на такое поведение курсора :)

Добавить комментарий для amelice Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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