Да, из-за этого tabindex'а уже немало споров возникало. Я считаю, что все-таки текущий вариант правильный. Неудобства в любом случае остаются (2 таба до пароля либо за борт всех кто не с mail.ru).
Попробую предложить свой вариант, в котором таб переводит фокус на ввод пароля:
Идея состоит в добавлении в текущий вариант принципов, использованных в выборе цвета, т.е. пользователю видно не только mail.ru, но и еще по одному домену сверху и снизу от текущего значения. В момент ввода логина действуют кнопки Up и Down (можно указать это в виде схематичного изображения данных клавиш рядом рядом со стрелками или вместо них).
Возможно это Вас удивит, но для интернет-магазина вполне логично наличие существенной доли покупателей из регионов.
В крупных городах проблемы с поиском нужного товара практически нет, в то время как для регионов многие из них просто недоступны, либо цены неадекватные. Возможность доставки заказов интернет-магазинами по всей России устраняет этот пробел. В некоторых случаях она даже бесплатная, что дает интернет-магазину еще больший приток покупателей из регионов.
В этом и есть суть input-select'a, но не совсем очевидно добавление нового элемента (по крайней мере для меня). Ну и мультиселект отпадает в такой реализации.
Если набрать что-то и не нажать Enter, вернется то что было выбрано до этого (хотя может так и задумано).
Сначала тоже удивился почему тут Ajax не используется.
Но все встает на свои места* если еще раз посмотреть на назначение данного плагина — ненавязчивая замена стандартных выпадающих списков.
Я вот тоже про это подумал.
Как правило для открытия той или иной формы пользователь нажимает кнопку (или ссылку), содержащую описание конкретного действия. В этих случаях дублирование избыточно (вероятно еще и в название формы/страницы что-то подобное написано) и вполне достаточно ограничиться одним глаголом (создать, войти, сохранить и в некоторых случаях даже отправить).
Более эффективно, на мой взгляд, попробовать сократить рутинные операции по приведению кода к «валидному» состоянию, внедрив подобный механизм непосредственно в процесс кодирования, еще лучше — добавить автоматизацию.
В простейшем варианте становится существенно короче обратная связь, т.е. разработчик сразу получает информацию о том, что часть кода не соответствует стандарту.
В качестве другого варианта — более жесткие ограничения, не позволяющие вводить некорректные символы и редактировать некоторые части кода.
Похожий функционал несут в себе проверка синтаксиса и автодополнение, но при этом код все равно остается полностью под контролем разработчика.
Есть модуль ngx_http_referer_module.
Если закрыть глаза на прямое назначение $invalid_referer, можно через нее делать.
Только надо учитывать не только m.site.ru, но и сам site.ru.
Если серьезно, то есть такое предположение: поскольку перенаправление должно сработать только при первом обращении, можно проверять откуда идет пользователь, если извне (с чужого сайта или из пустоты) — перенаправлять, иначе ничего не трогать.
Имел в виду, что программист не должен писать (или редактировать) самостоятельно ни одного тега в коде и уж тем более лазить в стили. Все это (html + css) уже должно быть готово и поправлено при необходимости. Программист вставляет вывод данных и только. Я бы еще заменил слово «натягивает» на «одевает», т.к. оно лучше отражает описываемый мной процесс.
Чтоб не было намеков на капитана, напомню, что я комментировал вот это:
Очевидно, что подобные фреймворки удобны чисто верстальщикам, которых не волнует, как будет натягиваться верстка.
И суть комментария в том, что фреймворки могут использоваться не только криворукими верстальщиками, но и вполне вменяемыми, которые их используют как тщательно подобранный и значительно упрощающий жизнь инструмент.
Вы делаете правильно, что думаете. Это целиком задача верстальщика. Программист программирует, а не переверстывает.
Проблема в том, что обычно косяки верстки становятся заметны, когда в макет попадают реальные данные. Что ж, надо было указывать в задании дизайнеру не только сверстать по PSD один-в-один, но и всю возможную динамику данных. Либо отправлять на доработку (переверстывать опять же должен не программист).
Как правило верстальщики и программисты работают в тесной связке, поэтому проблемы переверстывания программистом при натягивании возникать не должно.
Название какое-то бессмысленное получается, если честно. Прочитав его, я сделал вывод, что использование фреймворков = некрасивая верстка. Прочитав текст и проявив немного дедукции скорректировал: использование фреймворков = верстальщик с кривыми руками.
А это не так.
Указанные css-фреймворки, как и всё другое, обладают своими плюсами и минусами. Красивая, более простая и страндартизированная верстка — это как раз одно из преимуществ фреймворков. Помимо этого верстальщик как правило получает reset, улучшение типографики, оптимизацию для печати, оформление форм и их элементов управления и многое другое.
Да, в сеточных фреймворках, появляется частичное смешение содержимого и представления. Но это на совести того, кто выбирает подходящее для решения конкретной задачи средство разработки. Если минусы фреймворка не критичны, верстальщик экономит кучу времени и получает более логичный результат. Понятное дело, что фремворк не стоит брать на борт, когда в первую очередь важны производительность и возможность координальной смены оформления.
Закончу тем, что любой фреймворк является велосипедом. Каждый сам выбирает использовать его или нет.
Попробую предложить свой вариант, в котором таб переводит фокус на ввод пароля:
Идея состоит в добавлении в текущий вариант принципов, использованных в выборе цвета, т.е. пользователю видно не только mail.ru, но и еще по одному домену сверху и снизу от текущего значения. В момент ввода логина действуют кнопки Up и Down (можно указать это в виде схематичного изображения данных клавиш рядом рядом со стрелками или вместо них).
В крупных городах проблемы с поиском нужного товара практически нет, в то время как для регионов многие из них просто недоступны, либо цены неадекватные. Возможность доставки заказов интернет-магазинами по всей России устраняет этот пробел. В некоторых случаях она даже бесплатная, что дает интернет-магазину еще больший приток покупателей из регионов.
Если набрать что-то и не нажать Enter, вернется то что было выбрано до этого (хотя может так и задумано).
Но все встает на свои места* если еще раз посмотреть на назначение данного плагина — ненавязчивая замена стандартных выпадающих списков.
* Кроме выбранного блога конечно.
Вот что придумалось, глядя на демо:
Но это ведь не проблема. При желании не так сложно «допилить» и Ctrl, и даже Shift, если пригодится.
Как правило для открытия той или иной формы пользователь нажимает кнопку (или ссылку), содержащую описание конкретного действия. В этих случаях дублирование избыточно (вероятно еще и в название формы/страницы что-то подобное написано) и вполне достаточно ограничиться одним глаголом (создать, войти, сохранить и в некоторых случаях даже отправить).
В простейшем варианте становится существенно короче обратная связь, т.е. разработчик сразу получает информацию о том, что часть кода не соответствует стандарту.
В качестве другого варианта — более жесткие ограничения, не позволяющие вводить некорректные символы и редактировать некоторые части кода.
Похожий функционал несут в себе проверка синтаксиса и автодополнение, но при этом код все равно остается полностью под контролем разработчика.
Если закрыть глаза на прямое назначение $invalid_referer, можно через нее делать.
Только надо учитывать не только m.site.ru, но и сам site.ru.
Если серьезно, то есть такое предположение: поскольку перенаправление должно сработать только при первом обращении, можно проверять откуда идет пользователь, если извне (с чужого сайта или из пустоты) — перенаправлять, иначе ничего не трогать.
Чтоб не было намеков на капитана, напомню, что я комментировал вот это:И суть комментария в том, что фреймворки могут использоваться не только криворукими верстальщиками, но и вполне вменяемыми, которые их используют как тщательно подобранный и значительно упрощающий жизнь инструмент.
Проблема в том, что обычно косяки верстки становятся заметны, когда в макет попадают реальные данные. Что ж, надо было указывать в задании дизайнеру не только сверстать по PSD один-в-один, но и всю возможную динамику данных. Либо отправлять на доработку (переверстывать опять же должен не программист).
Как правило верстальщики и программисты работают в тесной связке, поэтому проблемы переверстывания программистом при натягивании возникать не должно.
А это не так.
Указанные css-фреймворки, как и всё другое, обладают своими плюсами и минусами. Красивая, более простая и страндартизированная верстка — это как раз одно из преимуществ фреймворков. Помимо этого верстальщик как правило получает reset, улучшение типографики, оптимизацию для печати, оформление форм и их элементов управления и многое другое.
Да, в сеточных фреймворках, появляется частичное смешение содержимого и представления. Но это на совести того, кто выбирает подходящее для решения конкретной задачи средство разработки. Если минусы фреймворка не критичны, верстальщик экономит кучу времени и получает более логичный результат. Понятное дело, что фремворк не стоит брать на борт, когда в первую очередь важны производительность и возможность координальной смены оформления.
Закончу тем, что любой фреймворк является велосипедом. Каждый сам выбирает использовать его или нет.