Pull to refresh

Comments 62

Лучше chosen пока ничего не видел. Смысл менять стандартные на что-то если они выглядят не лучше?
Смысл был в том, что дизайнеру требовалось внешне простые селекты и не отличающиеся по функционалу от стандартных и одинаковые во всех браузерах. У chosen более широкий функционал, мне он тоже нравится)
интересно узнать, по каким причинам дизайнеру всё это потребовалось
По тем причинам, что они должны были быть одинаковые во всех браузерах (версиях) и не быть перегружены лишним функционалом, который есть у остальных. Можно сделать сложную библиотеку, посвещенную только селекту, и угодить всем — передо мной такой задачи не стояло.
Наверняка, когда ваш дизайнер ставил перед вами задачу переопределить стандартный вид селектов во всех браузерах, он руководствовался не субъективным чувством прекрасного, не личной прихотью, а некими серьёзными инженерными причинами. Хотелось бы узнать, что это за причины.
Складывается впечатление, что он вам не угодил. Думаю, он руководстовался чувством прекрасного, он же дизайнер)
Чувством прекрасного может руководствоваться художник, как представитель творческой профессии. Веб-дизайнер — это профессия прежде всего инженерная, со всеми вытекающими.

Но мотивацию вашего работника я понял, спасибо за ответ.
Я вот согласен с onthefly, меня просто выводят из себя такие ничего под собой не имеющие аргументы(это я про вашего дизайнера, не про вас:) ). Контролы не должны выглядеть одинаково во всех браузеры без веской на то причины(функциональной в первую очередь). Как и сайты не должны выглядеть пиксель-в-пиксель во всех браузерах.
C ajax chozen довольно уныло работает, мучались мучались с ним, в итоге написали своё решение на основе UI autocomplete
Вместо chosen лучше использовать select2, ИМХО :)
Поддерживаю, Select2 базировался на Chosen, он как работа над ошибками и намного предпочтительнее.
Красиво и функционально, но много лишнего для некоторых задач. Если нужен простой селект просто без автоподбора и пр. Я вижу что мой не претендует на звание простого хотя бы из-за того что в нем много багов. Но почему-то все сравнивают его с чем-то очень функциональным.
Спасибо за select2, не знал.
Есть такой вопрос, может кто-нибудь в этой ветке знает, как заставить chosen или select2 отзываться на Page Up/Down и Home/End? В chosen предлагают решать это циклом перебирая по одной строчке, для Page Up/Down ещё чёрт с ним, но с End — это провал… :)
Не подскажете у chozen или select2 можно отключить поле поиска?
В API ничего по этому поводу я не нашел, но можно решить «в лоб» :)

.select2-search {
  display: none;
}
тогда перестает работать навигация стрелками, жаль что нет такой настройки
Тогда вот так (проверил, работает навигация стрелками):
.select2-search {
  width: 1px;
  height: 1px;
  overflow: hidden;
  opacity: 0;
}
disable_search_threshold: 10

с такой опцией поле поиска будет появляться если элементов больше 10
Opera 12.14 Win7 — нету прокрутки колёсиком у самого первого примера.
Chrome 24, Ubuntu 12.10 — нет прокрутки колесиком ни в одном примере :-)
Скроллинг в разработке. Теперь вижу, что это важный функционал.
Хех. Это первостепенный функционал в списках
Программист с самого начала знает обо всех багах и недоработках программы, но не исправляет их, надеясь, что пользователи не додумаются вызвать эти ошибки. (с) народная мудрость
Согласен с Richard_Ferlow!
Так же к вашим селектам нельзя прикрутить события, например на onChange, а такое часто нужно на реальной практике…
Да. Вот это серъезный просчет с событиями. Спасибо.
А потом открываешь сайты на маленьких сенсорных экранах и начинаешь ругаться на подобные украшательства, заточенные под десктопную мышку.
Не работает переключалка по элементам табами.
Не работает выбор при наборе с клавиатуры имени элемента.
После того, как реализуете поведение элемента, как стандартного, поймете, что это не тривиальная задача и менять контролы не надо
Реализую) Баги поправимы. Менять контролы или не менять — каждый решает сам в зависимости от поставленных задач.
Не забудьте также про фокус и поддержку клавиатуры. Элементы списков можно выбирать, набрав название элемента с клавиатуры, развернуть список и гулять по пунктам можно стрелочками, а на сам список можно попасть по табу.

А вообще, не тратьте время на чепуху.
jquery.core-ui-select, пользуюсь с момента прочтения статьи.
Стилизуется оттуда, откуда должен стилизоваться (из CSS, ну). Обрабатывает скролл и клавиатуру. На айосах выключается.
Недавно довелось пользоваться uniformjs — хорошая реализация, заменяет все элементы формы, IE7+ поддержка.
OS X, Safari:
1. По табу селект не выбрать;
2. пробел при открытом селекте прокручивает страницу;
3. отстутствие эвентов/колбэков;
4. отстутствие API;
5. нет поддержки optgroup

Да и вообще сам плагин сомнительного качества. Не предлагаю посмотреть в сторону моего ikSelect.
Что значит сомнительного качества?)
Пробежался глазами. Не понравилось:
1. Структура. Стоило прибегнуть хоть к какому-то паттерну.
2. В коде определен метод «extend». Чем не угодил $.extend?
3. Никаких namespace-ов у event-ов.
4. Ужасная производительность при большом количестве option-ов, судя по коду. Из каждого option создается объект, который аппендится к списку.
и тд
2. В коде определен метод «extend». Чем не угодил $.extend?


Наверное, абсолютно другим функционалом)

4. Ужасная производительность при большом количестве option-ов, судя по коду.


Я бы не судил о производительности по коду. Тем более поверхностно.
Наверное, абсолютно другим функционалом)

По-моему, $.extend(CreateClone.prototype, SelectToggle.prototype) вполне справился бы в данном случае.

Я бы не судил о производительности по коду. Тем более поверхностно.

Я бы не судил, если б не делал свой плагин для селектов и не столкнулся бы с данной проблемой.
С такой проблемой не столкнулся. Производительность на уровне при большом количестве селектов.
Я не про количество select-ов, а про создание списка ul>li из, например, тысячи option-ов.
Никогда не сталкивался с селектом из 1000 option-ов. C 300-ами не тормозит — проверил.
Посмотрите Selectik.
Были исправлены баги, реализован весь стандартный функционал селекта, API, преопределение методов. Весит меньше.
Там, к примеру, того же поиска по первой букве тоже нет
Готов не согласиться. Может вы нашли баг — тогда прошу создать issue.
Спасибо. Ответил вам там же. «Это не баг, а фича». В действительности абсолютно нормальное поведение стандартного селекта.
В Safari на OS X как выскакивал стандартный дропдаун при нажатии на стрелку, так и выскакивает. )
Будет возможность протестировать снова в OS X — займусь этим багом.
Убрать стандартное поведение селекта в Safari на Mac'е, к сожалению, не возможно. С учетом поведения, которое использует сейчас Selectik.
Но есть маленький костыль. Подробнее можете ознакомится здесь.
А есть ли хоть один, который может следить за изменением состояния селекта и апдейтиться соответственно.
А есть тут проект, который грузит данные в селект с третьего сервера. Причём влезть в этот процесс нельзя (чужой скрипт).
Изменения состояния селекта:
1. Если вы изменяете структуру, то Selectik автоматически это не делает. Надо вызывать функцию плагина.
2. Если изменяется выбранный элемент — да.

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

При повторении привычных действий с кастомным селектом пользователь испытывает к. д. Частично (скроллинг по списку при событии drag) реализован в Select2.

«Прижал — Потянул — Отпустил» превращается в «Щелкнул — Прокрутил — Выбрал — Щелкнул», это если прокрутка колесом работает, в противном случае все еще сложнее. Не зря же стандартные контролы продумывают до мелочей под различные поведения пользователя.
Вы высказали очень интересное замечание. Постараюсь подумать, как это можно реализовать.
Да вы крут! Только скроллинг не работает. FX 18
Firefox 18.0.2/Windows 7 — при зажатой левой кнопке с помощью скролла(мыши) работает.
Можете расписать ваши действия? Возможно в личку.
Нет, нет. Скролл должен срабатывать при перемещении с последнего элемента за нижнюю границу выпадающей области при зажатой кнопке мыши! И так же для верхнего элемента. Поиграйтесь со стандартным элементом и все станет ясно. Колёсико в данном случае совсем не участвует.
Сделано. Пользуйтесь (тестируйте).
Правки внес, так как это действительно нативное поведение селекта.
Спасибо за помощь.
В раскрытом селекте должна работать навигация вверх-вниз с помощью стрелок на клавиатуре, у вас этого пока нет. Было бы замечательно реализовать и это поведение, свойственное стандартным управляющим элементам.
Данная возможность была перекрыта последним коммитом. Исправлено.
Only those users with full accounts are able to leave comments. Log in, please.