Select css: Стилизация Select с помощью css, как будто это 2020

 .selector-class::before { 
 content: "x"; 
 позиция: абсолютная; 
 дисплей: блок; 
 верх: 0; 
 осталось: 0; 
 ширина: 30 пикселей; 
 высота: 30 пикселей; 
 цвет фона: серый; 
 }
 

Здесь вы можете найти полный набор селекторов псевдоэлементов. Какие еще волшебные вещи вы можете делать с псевдоэлементами, мы обсудим в следующей главе этого блога.

Теперь вы знаете, какой селектор можно использовать в какой ситуации.

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

StyleFacts, часть 1

StyleFacts, часть 2

Если у вас есть вопросы о селекторе или у вас есть отличное дополнение к этому блогу, сообщите мне об этом в комментариях! Спасибо за прочтение. Следующий блог будет посвящен адаптивному дизайну.

Замена блока выбора со стилем в чистом CSS и семантическом HTML | Росс Ангус

·

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

Измените их внешний вид, и пользователи больше не будут знать, что они ищут.

Хорошо. Подождите, вы еще хотите их стилизовать? ОТЛИЧНО.

Есть несколько библиотек JavaScript, которые могут помочь — например, Chosen со сбивающим с толку названием, jQuery selectBox, SelectBoxIt или Select2. Некоторые из них добавляют полезные функции, такие как поиск. Но всех их объединяет одно: реализация не занимает много времени, зато есть всегда проблем с ними на этапе пользовательского приемочного тестирования проекта. Многие из этих проблем возникают из-за того, что все эти библиотеки скрывают исходное поле выбора и дублируют его другими элементами HTML, такими как привязки или теги ввода. Это означает, что события, добавленные в исходное поле выбора, часто теряются, а действия пользователя не записываются должным образом.

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

Существует несколько различных типов полей выбора:

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

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

Моя первоначальная мысль была: «Что, если я поместил кучу радиокнопок и ярлыков внутри контейнера, а затем расширил контейнер, когда один из них достиг фокуса?» Это будет работать следующим образом:

• Сами радиокнопки будут визуально скрыты
• Теги меток будут располагаться друг над другом, используя position: absolute
• Контейнер также должен быть абсолютно позиционируется таким образом, что когда он расширяется, он находится поверх любого последующего содержимого
• Как только один из переключателей достигнет фокуса, положение всех элементов label внутри контейнера изменится на static . Так как ранее я также изменил их свойство display на block , они будут располагаться друг над другом и заставлять контейнер принимать свою полную естественную высоту

Я сделал все это, и вот что получилось:

Основная проблема заключается в том, что невозможно фактически выбрать какое-либо значение. Я предполагаю, что это связано с событием размытия (из-за отсутствия лучшего имени), происходящим до фокусировки на 9Элемент 0186 label выбирает следующий переключатель.

Но есть еще одна более серьезная проблема. Правило, выполняющее большую часть работы, заключается в следующем:

input:focus ~ label {position: static;}

Это читается по-английски как «Если элемент input помещен в фокус, то измените все ». следующие теги label для позиции : static «. ~ — это следующий родственный селектор. В CSS нет следующего селектора и , и вряд ли когда-либо будет, если вы не используете flexbox. Я думаю это потому, что CSS мыслит с точки зрения синтаксического анализа вниз DOM сверху вниз (по той же причине в CSS нет родительского селектора). Он не такой гибкий, как JavaScript, который носится по всему дереву, как шимпанзе.

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

Это сработало, но я подумал, нельзя ли это улучшить.

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

Что, если бы сам переключатель выбора был частью той же серии радиокнопок, что и остальная часть поля выбора? На этот раз ключевое правило таково:

.radio-toggle:checked ~ .select label {position: static;}

На английском языке это правило гласит: «если проверен элемент с классом radio-toggle , найти все следующие элементы с класс выберите , затем измените положение всех элементов label внутри него на static «.

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

Первоначальная, чисто CSS-версия этой замены поля выбора имеет ужасный недостаток: она лишь частично доступна с клавиатуры. На эту проблему мне обратил внимание пользователь Reddit jestho, чей единственный отрицательный голос скрыл мой пост из поля зрения.

Но, конечно же, я абсолютно прав: навигация с помощью клавиатуры абсолютно необходима для таких элементов управления. Я сделал все, что мог, на чистом css, но все, что мне удалось сделать, это добавить обведите контур вокруг поля выбора, когда оно впервые попадет в фокус. К сожалению, как только пользователь выбирает значение из в пределах , поле выбора переходит к другому элементу управления, , затем возвращается к тому же полю выбора, подсветка больше не отображается (это потому, что для этого изменения в дочерний элемент должен будет подняться до родительского элемента, чего не произойдет).

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

Большая часть JavaScript предназначена для захвата и интерпретации различных нажатий клавиш, таких как:

• Клавиши курсора (перемещение вверх и вниз — в основном это бесплатно, но JavaScript останавливает фокус в конце и начале диапазона значений)
• Страница вверх (перемещение на настраиваемое расстояние вверх или к первому значению, если применимо)
• Страница вниз (как указано выше, но вниз)
• Пробел (открывает поле выбора)
• Ввод (переключает поле выбора открытые и закрытые)
• Escape (закрывает окно выбора)

Использование вкладки фиксируется событиями, связанными с изменением фокуса, поэтому мне не нужно было писать какой-либо jQuery, чтобы следить за этим.

Навигация с помощью клавиатуры JavaScript — спорный вопрос, поэтому я попытался воспроизвести поведение окна выбора по умолчанию (Windows, извините). Для навигации с помощью клавиатуры в других элементах страницы я бы посоветовал ознакомиться с WAI-ARIA Authoring Practices или, если у вас есть проблемы с W3C по какой-либо причине, с проектом A11Y.

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

• Поскольку элемент .select позиционирован абсолютно, он должен появиться внутри другого элемента, что оставит для него место в обычном потоке документов
• Элемент .select фактически display: block : он займет всю ширину любого элемента, который вы поместите внутрь. Обычные элементы select фактически являются display: inline-block и будут принимать ширину выбранного в данный момент элемента option. Но поскольку мы удаляем текущий выбранный элемент из потока документов, мы не знаем его размера.
• Обычные элементы выбора в какой-то степени осведомлены о области просмотра браузера и даже о краях экрана. Это означает, что при необходимости они могут расширяться до такой степени, что выходят из самого браузера и размещаются поверх него (см. изображение вверху этого поста). Именно такое поведение дает им репутацию части операционной системы, а не части веб-страницы. Фальшивое поле выбора ограничено корневым элементом страницы и не может выйти за его пределы. Он всегда занимает всю необходимую ему высоту, чтобы отобразить все его параметры (если только вы не хотите указать для него высоту и переполнение).
• Из-за используемого захватывающего CSS это будет работать только в IE9 и выше (если вам нужна поддержка браузеров ниже IE9, я предлагаю загрузить Sizzle в условных комментариях внутри заголовка).
• Мобильные пользователи никогда не увидят собственный стиль окна выбора, который занимает большую часть или весь экран.

  No related posts.