насколько мне известно, activeX предлагал веб-мастерам возможность значительно улучшать функциональность страницы в рамках одного браузера. По нескольким причинам, в том числе из-за закрытости этого решения, activeX сейчас используется очень мало
вы предлагаете возможность улучшать функциональность страницы для нескольких (далеко не всех) браузеров, и я вижу тут прямую аналогию
с настройками очень просто: конструктор получает id select'а и прочие параметры. Параметрами он настраивается, а из селекта берет данные. Потом подменяет собой селект.
можете не гореть желанием, но так вы потеряете ощутимую часть самых профессиональных разработчиков, которые могли бы использовать контрол
4 месяца — это долго, но работу обычно меряют не по усталости ; )
optgroup - это что? ну как вам сказать... почитайте спеку html, с этого и нужно было начинать создание эмулятора контрола
автоподстановка и выбор из списка — разные вещи, это должно быть очевидно. Если вы предоставляете замену стандартного контрола, то она должна уметь как минимум то же самое, что и этот контрол, а не предлагать использовать апи ; )
выпадающее меню без яваскрипт — это select. Его можно улучшать (см. progressive enhancement), но базовая функциональность должна быть доступна агенту без поддержки css и js. Если при отключении этих фич все продолжает быть как надо — это и есть graceful degradation.
Вообще рекомендую побольше почитать хотя бы западных js-блоггеров на тему стандартов и accessibility, и только потом браться за такую серьезную задачу, как свой контрол. Это не хиханьки, серьезно.
еще желателен поиск option'ов при наборе на клавиатуре как в стандартном селекте — если открыть его и начать нажимать на клавиатуре кнопки, выберется начинающийся с этих букв option
и очень грустно, что при отключенном яваскрипте функциональность становится недоступна... как же graceful degradation?
с одной стороны, это хороший, правильный комментарий
с другой стороны, мне очень не хочется, чтобы разработчики prototype.js учитывали опыт, который приводит к результатам вроде этого: $(”#id”) - IE 6 - 651ms
если так лажать, то да, потом можно ускоряться и на два порядка ; )
тормозить он стал еще больше, кстати
что я делаю неправильно?
а второй абзац как будто перенесся сюда из какого-нибудь 1997 года ; )
вы предлагаете возможность улучшать функциональность страницы для нескольких (далеко не всех) браузеров, и я вижу тут прямую аналогию
да, я против нарушения стандартов
можете не гореть желанием, но так вы потеряете ощутимую часть самых профессиональных разработчиков, которые могли бы использовать контрол
4 месяца — это долго, но работу обычно меряют не по усталости ; )
и его не всегда отключают, некоторые браузеры его просто не умеют, возьмите хоть мобильные телефоны
автоподстановка и выбор из списка — разные вещи, это должно быть очевидно. Если вы предоставляете замену стандартного контрола, то она должна уметь как минимум то же самое, что и этот контрол, а не предлагать использовать апи ; )
выпадающее меню без яваскрипт — это select. Его можно улучшать (см. progressive enhancement), но базовая функциональность должна быть доступна агенту без поддержки css и js. Если при отключении этих фич все продолжает быть как надо — это и есть graceful degradation.
Вообще рекомендую побольше почитать хотя бы западных js-блоггеров на тему стандартов и accessibility, и только потом браться за такую серьезную задачу, как свой контрол. Это не хиханьки, серьезно.
однако один раз они капитально слажали, и я думаю, что это легко может повториться
еще желателен поиск option'ов при наборе на клавиатуре как в стандартном селекте — если открыть его и начать нажимать на клавиатуре кнопки, выберется начинающийся с этих букв option
и очень грустно, что при отключенном яваскрипте функциональность становится недоступна... как же graceful degradation?
с другой стороны, мне очень не хочется, чтобы разработчики prototype.js учитывали опыт, который приводит к результатам вроде этого: $(”#id”) - IE 6 - 651ms
если так лажать, то да, потом можно ускоряться и на два порядка ; )