Искусственный селект

[Nekromancer]

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

Чаще всего при создании искусственного селекта люди отталкиваются от мысли - берём обычный селект, прячем его в display: none; - показываем весёлый разукрашенный искусственный селект. Это наверно самый банальный, стандартный и на мой взгляд самый не практичный способ.

Другим же способ реализации является непосредственное имитирование селекта и его поведения как для пользователя так и для самой формы при помощи hidden input. Эта реализация заключается в том, что весь процесс управляется из JavaScript в отличии от первого варианта, когда список селекта строится стандартно в HTML разметки.

Для верстальщика первый вариант покажется более очевидным так как тут используется HTML разметка и в ход вступает (как говорили в соседней теме) - стандартный паттерн.

Со стороны же программиста всё гораздо сложнее. Здесь нужно думать о динамике приложения, о возможности создания таких селектов на лету при подгруздке данных с сервера. Так как во втором варианте всё управление происходит через JavaScript этот вариант кажется более привлекательным.

Однако предположим что мы всё таки выбрали первый вариант для нашего приложения, как же нам быть и реализовать всё что нам нужно? Можно выкрутится и наворотить костылей при создании такого селекта - брать блок, заливать его HTML кодом селекта, потом создавать структуру искусственного селекта и обрабатывать натуральный. Ладно, куда ещё не шло, согласен, можно по извращаться. Но вот когда речь идёт о подгруздке дополнительных пунктов селекта и добавления их становится куда менее интересно дублировать теги для искусственного и натурального селекта, связывать их и хранить значения. И это я не упоминаю о костылях связанных с ИЕ в этом случае так как в скором времени окажется совсем не актуально.

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

Ну и как всегда суть вопроса - что же лучше и кто тут дурак?

П.С. Пример риализационного кода приводить не стану, думаю все понимаю что есть что, если кому то надо то отпишите, предоставлю

[sigma77]

Nekromancer,

Пока тоже склоняюсь к input type="hidden". Удобство его очевидны. Серверу же вообще пофиг от какого поля пришли данные. Так что преимущества селекта для меня пока не очевидны.

[Nekromancer]

Серверу же вообще пофиг от какого поля пришли данные.

Абсолютно верно!

[psywalker]

Рад, что из-за меня поднимается очередной холивар, они всегда полезны для общества

По сабжу:

У этих способов есть свои плюсы и минусы, один удобный, лёгкий и простой в обслуживании, но другой же, как по мне, так более матёрый, я имею ввиду вот этот вариант, т.е. вариант Great Rash-а можно считать полноценной заменой селекта, так как при этом способе человек может делать всё что угодно, как в настоящем селекте, например стандартное событие onchange, которое не привяжешь обычному <div>.

Но, есть конечно же и минусы, он громоздкий, трудный и не каждый сможет его написать.

В общем у нас имеется два варианта (последний не доделан, выставлен ради того, чтобы показать, что примерно имеется ввиду):

1. http://berezkin-r.narod.ru/select/

2. http://psywalker.ru/Forum/JS/Primitive/Dom-Zadachi/Sobitia/Klaviatura/SelectAmulation/select-amulation.html

А какой выбираете вы и почему?

[Nekromancer]

а можно считать полноценной заменой селекта, так как при этом способе человек может делать всё что угодно, как в настоящем селекте, например стандартное событие onchange, которое не привяжешь обычному <div>.

1. Input + JS тоже полноценная замена селекта, пользователь никакой разницы никогда не заметит. Проблема в том, что верстальщики знают в основном стандартные интерфейсы браузера и ощущение использования реального селекта почему то делает своё дело.

2. У input тоже есть onchange.

3. Никакой onchange здесь нафиг не нужен.

П.С. Ненавижу опросы, убери его к чёртовой бабушке.

[sigma77]

П.С. Ненавижу опросы, убери его к чёртовой бабушке.

Да ладно, пусть будет

[psywalker]

П.С. Ненавижу опросы, убери его к чёртовой бабушке.

Ты ненавидишь, ты и не участвуй)

3. Никакой onchange здесь нафиг не нужен.

Почему не нужен? Т.е. ты предлагаешь его эмулировать?

[Nekromancer]

П.С. Ненавижу опросы, убери его к чёртовой бабушке.

Да ладно, пусть будет

Ну я же вредный

3. Никакой onchange здесь нафиг не нужен.

Почему не нужен? Т.е. ты предлагаешь его эмулировать?

Селект искусственный, то есть все действия проходят через тебя и ты всегда знаешь когда change.

[mishka]

Вариант с селектом более очивиден для верстальщака, и так как верстка чато отделяется от джс, то он есть самый распостраненный.

Самый путевый плагин который видел - http://www.xiper.net/collect/html-and-css-tricks/verstka-form/nice-select-jquery.html

Второй вариант наверное даже проще в реализации. Тыцкаем на элемент и его тайтл переносится в скрытое поле. В случае селекта это был бы value.

Тут можно даже разделить скрипты, часть отвечает за визуализацию, а вторая часть за перенос значения(совсем крохотная такая)

тоесть проще говоря ненужно onchange, как говорил Nekromancer

ненужно строить дроп на основе дропа селекта.

Одни плюсы, и чего ранее до этого не додумались? ))

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

[SelenIT]

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

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

[Nekromancer]

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

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

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

Читал последнюю ссылку, да А вот мультиселект действительно сейчас редко можно встретить на сайтах (или я не гуляю по таким сайтам?).

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

[s0rr0w]

...это всё надо честно воспроизвести, иначе юзер будет раздосадован неполноценностью замены.

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

А мультиселект, имхо, вообще абсолютно лишняя вещь.

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

[psywalker]

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

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

p.s. дописал об этом в посте.

[Great Rash]

Внесу свои пять копеек. Проголосовал за вариант С настоящим скрытым <select>-ом. Проголосовал не просто так, а потому что у меня есть довольно большой опыт в использовании кастомных селектов. Сначала предыстория:

Не так давно (2008 год) я работал верстальщиком в компании БИС (Банковские Информационные Системы), где занимался версткой интранет приложения для биллинга Дойчебанка. Дело в том, что ранее этой фирмой уже было написано (и успешно использовалось) приложение под названием QBis (КуБис). Написано оно было кажись на C и работало в консоли. Все управление (естественно, так как это консоль) осуществлялось с клавиатуры. Потом компания, по заказу Дойчебанка, стала разрабатывать браузерное интранет-приложение (на момент моего увольнения названия у него еще не было - рабочее "Расчетный Центр"). Основным критерием которого была возможность работать с ним с клавиатуры. Так как до этого банк работал с КуБисом, то менеджерам не пришлось бы долго переучиваться, т.к. шорткаты (комбинации клавиш) были, по возможности, сохранены. "По возможности" - потому что некоторые шорткаты в браузере реализовать не представляется возможным.

При заполнении форм у нас активно использовался TAB, причем "ходить" по полям формы можно было как вперед, так и назад (SHIFT + TAB). У нас использовалась связка <input type="hidden"> и яваскрипта. Все формы были динамическими, т.е. количество полей менялось в зависимости от выбора пользователя в предыдущем поле. Вы не представляете какой гемор был настроить правильный tabIndex для кастомных селектов в формах. Это был настоящий ад.

Так вот спрятанный "родной" селект решает проблему нумерации tabIndex'а - т.к. всю работу за программиста делает браузер. У спрятанного селекта есть еще несколько преимуществ, например при клике на <label> он получает фокус, верстальщику не надо знать яваскрипт, чтобы заменить селект на кастомный, ну и еще по мелочи.

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

[DjTarik]

Кроме меня уже никто не задумывается об использовании формы без JS? O_o Или я застрял в прошлом? =)

Именно поэтому я тоже выбираю вариант с "настоящим скрытым <select>-ом".

Cохранить функционал формы даже если отключен JS...

[s0rr0w]

Кроме меня уже никто не задумывается об использовании формы без JS? O_o Или я застрял в прошлом? =)

Именно поэтому я тоже выбираю вариант с "настоящим скрытым <select>-ом".

Cохранить функционал формы даже если отключен JS...

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

[Nekromancer]

Внесу свои пять копеек. Проголосовал за вариант С настоящим скрытым <select>-ом. Проголосовал не просто так, а потому что у меня есть довольно большой опыт в использовании кастомных селектов. Сначала предыстория:

Никто даже не сомневался в этом, ведь изначально вопрос стоял - "Какой вариант лучше твой или Грит Раша?".

Не так давно (2008 год) я работал верстальщиком в компании БИС (Банковские Информационные Системы), где занимался версткой интранет приложения для биллинга Дойчебанка. Дело в том, что ранее этой фирмой уже было написано (и успешно использовалось) приложение под названием QBis (КуБис). Написано оно было кажись на C и работало в консоли. Все управление (естественно, так как это консоль) осуществлялось с клавиатуры. Потом компания, по заказу Дойчебанка, стала разрабатывать браузерное интранет-приложение (на момент моего увольнения названия у него еще не было - рабочее "Расчетный Центр"). Основным критерием которого была возможность работать с ним с клавиатуры. Так как до этого банк работал с КуБисом, то менеджерам не пришлось бы долго переучиваться, т.к. шорткаты (комбинации клавиш) были, по возможности, сохранены. "По возможности" - потому что некоторые шорткаты в браузере реализовать не представляется возможным.

А что, менеджеры никогда не пользовались браузеров до этого, а только рабочей программой?

Это по какой логике нужно следовать когда делаешь визуальное приложение причём с искусственным интерфейсом и при это пытаться сохранить функционал консоли?

Зачем использовать реальный селект для имитации если ему не возможно настроить комбинации клавиш?

При заполнении форм у нас активно использовался TAB, причем "ходить" по полям формы можно было как вперед, так и назад (SHIFT + TAB). У нас использовалась связка <input type="hidden"> и яваскрипта. Все формы были динамическими, т.е. количество полей менялось в зависимости от выбора пользователя в предыдущем поле. Вы не представляете какой гемор был настроить правильный tabIndex для кастомных селектов в формах. Это был настоящий ад.

Так вот спрятанный "родной" селект решает проблему нумерации tabIndex'а - т.к. всю работу за программиста делает браузер. У спрятанного селекта есть еще несколько преимуществ, например при клике на <label> он получает фокус, верстальщику не надо знать яваскрипт, чтобы заменить селект на кастомный, ну и еще по мелочи.

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

Кроме меня уже никто не задумывается об использовании формы без JS? O_o Или я застрял в прошлом? =)

Именно поэтому я тоже выбираю вариант с "настоящим скрытым <select>-ом".

Cохранить функционал формы даже если отключен JS...

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

А я согласен с вами.

[Great Rash]

А что, менеджеры никогда не пользовались браузеров до этого, а только рабочей программой?

Это по какой логике нужно следовать когда делаешь визуальное приложение причём с искусственным интерфейсом и при это пытаться сохранить функционал консоли?

Все эти вопросы не ко мне, а к моему начальству и департаменту бизнес-аналитиков.

Зачем использовать реальный селект для имитации если ему не возможно настроить комбинации клавиш?

Комбинации клавиш к селекту не имеют никакого отношения. Они имеют отношение к браузеру. Например в Опере есть зарезервированные шорткаты, которые не перебить ничем. Для селекта важны лишь стрелки, таб, f4 (кажись), интер и текст, чтобы поиск по регулярке был. Все это реализуется на "ура".

Он, ну я вас умаляю, нашли проблему. Я не верстальщик и то знаю что это решается через использование кнопок как элемента выводящего информацию о текущем выбранном опшене. А если забить на оперу то вообще и при помощи ссылок.

Я могу построить работающий <input type="text"> только при помощи тега <span>, вопрос только зачем? Ради спортивного интереса? Я предпочитаю предоставить браузеру сделать большую часть работы за меня. Как вы, например реализуете фокус на селекте по клику на <label> при помощи ссылок? Про tabIndex у <a> я как бы в курсе.

[mishka]

Great Rash, в чем отличие спрятанного селекта, которому задается tabindex="-1" и вместо него генерится код заменяющий визуально этот селект от такой же структуры, но не сгенеренной а выведенной сразу?

Чем будет легче работать с селектом?

http://www.xiper.net/scripts/cusel/

Селекты вообще убираются и генерится такая структура со скрытым инпутом о которой говорит Nekromancer

При этом более правильных(работа максимально приближенна к оригиналу) кастомселектов я не видел.

[Great Rash]

Зачем вообще задавать tabIndex? Представь, что у меня есть 5 селектов. Над ними у меня 3 радиобаттона, в зависимости от того какой радиобаттон чекнут у меня селекты (они не друг за другом идут, а перемешаны с другими полями) выстраиваются в различном порядке. Пересчитывать tabIndex в этом случае - настоящий гемор. Поэтому я предпочитаю предоставить эту работу браузеру.

http://www.xiper.net/scripts/cusel/

Селекты вообще убираются и генерится такая структура со скрытым инпутом о которой говорит Nekromancer

При этом более правильных(работа максимально приближенна к оригиналу) кастомселектов я не видел.

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

Upd: по клику на лейбле селект по ссылке не получает фокус.

[mishka]

tabindex="-1" это для того чтобы при пробегании по элементам клавишей Tab не попал фокус на спрятанный селект.

http://www.xiper.net/scripts/cusel/

Селекты вообще убираются и генерится такая структура со скрытым инпутом о которой говорит Nekromancer

При этом более правильных(работа максимально приближенна к оригиналу) кастомселектов я не видел.

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

Уверен что это не из-за того что это не осуществимо, а из-за того что разрабы не заметили.

[Nekromancer]

Я могу построить работающий <input type="text"> только при помощи тега <span>, вопрос только зачем?

Я и "построил".

Ради спортивного интереса?

Как минимум ради возможности.

Я предпочитаю предоставить браузеру сделать большую часть работы за меня. Как вы, например реализуете фокус на селекте по клику на <label> при помощи ссылок?

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

Про tabIndex у <a> я как бы в курсе.

Я очень рад

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

[Great Rash]

tabindex="-1" это для того чтобы при пробегании по элементам клавишей Tab не попал фокус на спрятанный селект

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

Уверен что это не из-за того что это не осуществимо, а из-за того что разрабы не заметили.

Я не говорил, что это невозможно. Все возможно, вопрос только в том, сколько сил на это надо потратить.

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

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

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

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

[Nekromancer]

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

Кто то говорил вообще о вставлении реального селекта в html и удалении его? Он вообще не должен быть.

Те аргументы которые я привёл в первом посте вы просто пропустили мимо ушей. Это убогая интерактивность искусственного селекта при эмуляции его из реально. Так же это реального и искусственного селекта при загрузке страницы.

[Great Rash]

Все что я прочитал - убогая интерактивность. Я согласен только с тем, что при динамической загрузке пунктов придется дублировать их в реальном и виртуальном селекте. Согласен - это минус. Но я считаю это необходимым злом, потому что преимущества моего подхода перекрывают недостатки. Больше аргументов не увидел, или не захотел увидеть (считайте как хотите).

В общем я высказал свою позицию и привел аргументы в ее защиту. Тому, кто возьмется писать свой селект, будет над чем поразмыслить. В любом случае я не видел еще достойных внимания реализаций (и моя недоделанная тоже к ним относится). Если покажете реализацию, которая кажется вам наиболее удобной, с удовольствием на нее посмотрю. Интим cusel не предлагать. За сим я из дискуссии выхожу.