Обложка: Как я написал кастомный шрифт ради одного символа. Но сначала неделю страдал

Как я написал кастомный шрифт ради одного символа. Но сначала неделю страдал

Эту историю наш пользователь рассказал в рамках участия в конкурсе, посвящённому #фичавгусту, который мы проводим вместе с OTUS.

Привет, я Frontend Junior Developer в одной продуктовой компании, это моя первая работа в IT.

На момент событий шел примерно третий месяц в новой сфере. Мне отдали дизайн странички, где в полях, предназначенных для ввода пароля (input type=password) были использованы не обычные точки (так называемые bullet), а очень большие. Если обычная точка в пароле — это ·, то точка, которую необходимо было отрисовать, выглядела так: .

Первая идея, которая пришла в мою неопытную голову: пойти спросить продакта, действительно ли нам необходимы именно такие точки в пароле? А еще рассказать ей, как непросто взаимодействовать с такими сущностями, как input. Это своеобразные и своенравные элементы, с ними проще не связываться. Однако мне объяснили, что такой дизайн уже был согласован с владельцами бизнеса, а их своенравность поспорит со своенравностью input-ов. Так что варианта не делать эти прекрасные буллеты у меня не осталось.

Дальше я, конечно, начал гуглить, как же мне поступить с этими точками. Буквально в первые 15 минут нашёл замечательную статью. В ней предлагалось создать кастомный шрифт с одним символом bullet, который необходимо подменять динамически, если у input type=password. Однако тогда это решение показалось мне излишним.

Безуспешные поиски решения

Я пошёл по пути наименьшего сопротивления и сделал «гениальный» в своей простоте шаг — увеличил шрифт внутри пароля до 40px. Это увеличивало стандартную точку до нужного по дизайну размера. Правда, как неопытный разработчик, я не увидел, что в этом решении были подводные камни. Они вылезли на стадии тестирования.

Оказалось, что когда браузер Safari видит на странице поле для пароля, он предлагает «Создать надёжный пароль» или «Вставить сохранённый пароль». Это выглядит как появляющееся окошко рядом с полем. Однако если у вашего поля огромный шрифт, то и у этих появляющихся окошек будет огромный шрифт. Такое поведение никто не захочет увидеть у себя на сайте: заходишь на страницу, нажимаешь на поле ввода пароля и получаешь гигантское выпадающее окно. Это нужно было фиксить.

Тогда я подумал: «Возьму и ограничу эту возможность браузера, чтобы Safari вовсе ничего не предлагал пользователю». Первый же запрос в гугле скажет вам, что если вы хотите ограничить автозаполнение поля, то нужно указать ему атрибут autocomplete=off, и будет вам счастье. Но не верьте этим статьям и подсказкам. Это решение нерабочее, так как браузеры в какой-то момент решили, что они не будут обращать внимание на этот атрибут. Главной причиной игнорирования этого атрибута стало то, что автозаполнение ограничивает владелец сайта, а недовольство пользователя направлено на браузер, который не показывает сохранённый пароль.

Я проиграл битву с автозаполнением пароля, но война продолжалась. Я начал думать, как решить проблему без увеличения шрифта. Моя новая идея заключалась в том, чтобы показывать пользователю обычное поле ввода (input type=text), но подменять там все знаки на необходимые мне, а пароль сохранять где-то рядом — в переменной. Это решение, конечно, сомнительно в отношении безопасности, но тогда я не думал об этом, передо мной была задача и казавшееся гениальным решение.

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

Решение: сделать кастомный шрифт!

Мои попытки решить задачу продолжались не один день. Я придумывал решение, реализовывал его, отдавал на тестирование, мне прилетали баги, я пытался их фиксить, снова отдавал на тестирование, получал обратно уже с другими багами. И так по кругу около недели.

В итоге я пошёл за советом к старшим разработчикам. Конечно, первая мысль, которая настигла каждого, всё же отбить у продакта желание менять поведение input-ов и оставить точки прежними. Дальше они проходили похожий путь размышлений что и я, но опытность в том и заключается, что они на ранней стадии понимали неудачность решения. В итоге мне сказали написать кастомный шрифт.

Сейчас у нас на сайте прекрасно работающие поля пароля с нужными по дизайну точками. Я же получил очень важный урок: прежде чем писать код, нужно хорошенько подумать, а не бросаться воплощать решение, которое первым приходит в голову. И ещё одно — нужно уметь просить помощи раньше, а не ждать почти неделю.

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

***

Эту историю наш пользователь написал в рамках участия в конкурсе, посвящённому #фичавгусту, который мы проводим вместе с OTUS. Чтобы принять в нём участие, нужно до 27 августа рассказать на страницах нашего сайта про самую интересную/смешную/странную/тупую фичу, которую вам доводилось реализовывать. Победителей мы выберем по рейтингу, который будет сформирован на основании оценок пользователей и редакции сайта.

Если вам понравилась эта история, проголосуйте за неё. 

Под постом есть блок с реакциями. Если история вам понравилась, ставьте палец вверх. Только эти реакции будут учитываться при составлении рейтинга. Другие эмоции подсчитываться не будут.