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

мой первоначальный подход включал управление JavaScript State:

]
1. переменная состояния для отслеживания видимости подсказки (видимого/скрыто). Это состояние обновит класс на соответствующем HTML -элементе.
]
2. слушатели событий ( mouseenter , mouseleave ) для управления переходами состояния.
]
3. задержка из трех секунд перед установкой состояния в visible on mouseenter .
]
4. подсказка будет оставаться скрытой ( mouseleave ).
]

это был проект React, поэтому использование состояния JavaScript казалось естественным. Однако в ретроспективе это оказалось излишне сложным. MouseEnter и MouseLeave чувствовали себя немного ненадежными, и вся функциональность могла быть реализована более кратко и эффективно с CSS.

] смущающая реализация: я излишне использовал библиотеку JavaScript, когда решение CSS было легко доступно.

я сохранил пользовательский интерфейс React, но удалил управление штатом JavaScript. Решение включало простой CSS переход-delay свойство:

.thing {
  transition: 0.2s;
}
.thing:hover {
  transition-delay: 3s; /* delay hover animation only ON, not OFF */
}

этот элегантный одностроитель идеально достигает желаемого эффекта длинного проживания.

Этот подход, однако, не полностью обращается за доступностью сенсорного экрана. В то время как считыватели экрана обрабатывают доступный текст, а пользователи настольных компьютеров получают выгоду от подсказки инструментов, пользователи только для прикосновения могут пропустить этикетки значков. Мой проект нацелен на большие экраны, предполагая доступность курсора, но доходность остается проблемой. Если элемент является ссылкой, : Hover может активировать на начальном TAP. Если ссылка приводит к странице с четким заголовком, это может обеспечить достаточный контекст. В противном случае, обработка событий Javascript для событий Touch остается жизнеспособным вариантом.