В предыдущем посте этой короткой серии мы рассмотрели скрипт для создания полей маскированных паролей , и я был очень тронут силой ответов на этот пост. Парни, вы, ребята, ненавидите это! В то время, когда я публиковал его, у меня были сомнения относительно определенных аспектов, но в целом я думал, что это хорошая идея.
Ну, теперь я передумал! Прочитав комментарии и замечания, которые были опубликованы, я не думаю, что это хорошая идея. И дело было не столько в отдельных деталях, как в отсутствии поддержки автозаполнения или необходимости ограничивать позицию каретки, но скорее в том, что они создают эти ограничения, не добавляя при этом много пользы . То, что эти поля пароля не являются действительно безопасными для отслеживания плеча, и не обязательно легче использовать, чем обычные помеченные поля.
Но, тем не менее, мы столкнулись с исходной проблемой — обычные помеченные поля "password" имеют плохое удобство использования, и было бы неплохо найти лучшее решение.
Так что в этом посте мы рассмотрим альтернативную идею, которую пару из вас уже упомянули, и которая вроде как выдает название этого поста…
Флажок «Показать пароль»
По своей сути, гораздо более простой и простой подход, чем решение с символами маскировки, мы просто добавляем флажок под или рядом с полем пароля, который, когда установлен этот флажок, преобразует поле в обычный текст, чтобы вы могли видеть его без запутывания :
Форма входа с флажком «показать пароль».
Лично я бы никогда не стал пропагандировать чисто простое поле пароля, независимо от ситуации, но смысл этого решения в том, что мы даем пользователям контроль . В конце концов, мы всегда знаем, когда мы в безопасности от случайных наблюдателей — я сейчас прислонился к стене, и в любом случае я один в этой комнате!
Таким образом, мы даем пользователям возможность видеть их пароль в чистом виде, а затем предоставим им возможность подумать, когда это будет безопасно. (Несмотря на это, какое-то предупреждение не повредит — демо, которое я собрал для этого поста, имеет пометку на ярлыке с флажком о том, что это не рекомендуется в публичном месте
.)
Итак, вот скрипт, который добавляет эту функциональность к полям "password" , прогрессивным и кросс-браузерным способом. Взгляните на демоверсию и получите копию кода:
Разметка первая
Мы начнем этот пример с той же разметки, что и в прошлый раз:
<label for="pword">Password:</label> <input type="password" id="pword" name="pword" />
Но на этот раз нет необходимости изменять существующую разметку, мы просто добавим к ней некоторые новые вещи. Сначала чекбокс и метка, которые являются видимым переключателем, а затем вторичное "text" поле, которое вы видите, когда устанавливаете флажок.
В идеале, мы бы просто переключали type поля между "password" и "text" чтобы достичь этого, но, естественно, это не сработает в IE . Поэтому вместо этого мы создаем второе текстовое поле в том же контексте, что и оригинал, а затем переключаемся между ними, переключая их display .
Таким образом, мы получаем разметку вот так:
<label for="pword">Password:</label> <span> <input type="password" id="pword" name="pword" /> <input type="text" id="pword" autocomplete="off" style="display:none;" /> <label class="show-password" for="showpasscheckbox-1" title="Show the password as plain text"> <input type="checkbox" id="showpasscheckbox-1" title="Show the password as plain text" /> <span>Show Password</span> </label> </span>
Теперь наблюдатели с орлиными глазами заметят, что и поле исходного пароля, и новое текстовое поле имеют одинаковые ID , что делает недействительным DOM . Я буду первым, кто признает, что это неправильно, но это прагматично — на самом деле это не просто ID , скрипт копирует каждый атрибут из поля пароля (кроме его name и type ), так что он наследует тот же внешний вид и поведение , и в конечном итоге, выходит так же, как его прародитель. Вы можете удалить это поведение из скрипта, но в этом случае вам нужно будет заменить его на известную семантику стилевого крючка, такую как фиксированное имя class (то, что сторонний скрипт, как этот, никогда не мог бы делать).
Вы могли также заметить подлый autocomplete = «off» там, но расслабьтесь! Это просто на простом поле для предотвращения дублирования — автозаполнение в поле пароля работает так же, как обычно.
Сценарий последний
События, которые нам нужны, чтобы сделать эту работу, на самом деле довольно простые. Прежде всего, у нас есть обработчик change как для пароля, так и для текстового поля, так что ввод в один из них обновляет значение в другом. Нет необходимости использовать более непосредственное событие, чем onchange , потому что по определению вы не можете просматривать одно поле, не удаляя фокус из другого.
Затем на самом флажке есть обработчик click , который переключает отображение двух полей — так, чтобы одно из них было видимым, а другое скрыто (текстовое поле по умолчанию скрыто). Но в этой точке также есть небольшая ошибка, которая означает, что всякий раз , когда мы переключаем поля, мы также должны обновлять их значения , т.е. повторно скопируйте значение из отображаемого в данный момент поля в поле, которое должно быть показано…
При переходе по истории браузера с отправленной страницы обратно в форму в некоторых браузерах вы обнаружите, что одно из значений все еще там, а другое удалено (в IE пароль все еще будет, но обычное значение удалено, в Opera все будет наоборот, в Firefox они оба будут пустыми). Эти несоответствия (которые возникают из-за различий в безопасности браузера и моделях событий) могут привести к тому, что эти два значения будут не синхронизированы, поэтому, чтобы поддерживать их синхронизацию, мы просто должны убедиться, что всякий раз, когда мы переключаем отображение полей, мы также синхронизируем их значения ,
Мы также должны сделать что-то подобное предварительное представление. Возможно, что пользователь вернется в историю в состояние моментального снимка в браузере, где было видно простое поле, затем повторно введет или отредактирует это значение и сразу же повторно отправит его, не переключаясь обратно в поле пароля. Это представляет проблему, потому что поле пароля является тем с полем отправляемого значения в нем; простое поле — это просто показание. Поэтому, чтобы исправить это, мы добавляем подпрограмму непосредственно перед отправкой формы (т. submit Слушатель submit который не влияет на собственное поведение), который копирует значение из обычного поля в поле пароля, если обычное поле является тем, которое видимый.
Интермеццо!
Однако в Opera осталась одна проблема безопасности, которую я не смог предотвратить. Одной из самых сильных сторон Opera является также одно из ее самых больших неудобств, если смотреть под определенным углом зрения: когда вы возвращаетесь в историю Opera, она не перезагружает страницу — даже из кеша — она буквально воссоздает предыдущую снимок процессора этой страницы. Так, если, например, вы переходите на страницу по ссылке в выпадающем меню, когда вы возвращаетесь на предыдущую страницу, меню все равно будет открыто, точно так же, как вы его покинули — событие загрузки не сработает, и нет другого признака для разработчика, что загрузка страницы произошла вообще … потому что это не так!
Та же ситуация в меньшей степени относится ко всем просмотрам страниц в кэше в Opera, и для пользователей это означает, что все просмотры страниц в кэше выполняются быстрее. Но для нашего сценария это означает, что если вы отправите форму с видимым простым паролем, а затем вернетесь в историю, простой пароль все еще будет виден — прямо там, потенциально предоставляя ваш пароль наблюдателям, если вы не Не ожидаю этого.
Я не думаю, что есть какой-то способ, которым мы можем уловить эту ситуацию, потому что, что касается событий сценария, ничего не произошло — никакие события не запускаются, потому что никаких событий не произошло. Странно, да? И все же совершенно разумно!
Я думаю, что мы можем немного успокоиться в том факте, что пользователи Opera — которые, как правило, более демографичны, чтобы быть более технически грамотными, не говоря уже о том, что они очень хорошо знают, как работает их браузер — вероятно, не будут слишком удивлены этим. Я имею в виду, я живу в Opera большую часть времени, и одна из вещей, которые мне больше всего нравятся в этом, это то, как вы можете шаг за шагом проходить через отправку форм, не вызывая события сценария !!
Слишком легко!
Так что это почти все, что нужно — никаких неприятных сюрпризов!
Я полагаю, что если мы примем простоту близко к сердцу, из обзора должно быть очевидно, что это лучшее решение, чем поле маскированного пароля. Это чище, проще и не требует принудительного удаления нативного поведения, чтобы эта чертова штука работала! Но оно не идеально, и если это решение действительно хорошее, возможно, было бы лучше, если бы оно было реализовано самим браузером.
Присоединяйтесь ко мне в ближайшее время для третьего и последнего поста в этой серии, где я буду смотреть на что-то маленькое и милое, что вы можете добавить практически в любом месте!
Миниатюра кредит: явно неоднозначно