Кто догадается, о чём будет надвигающийся пост? :)

#заметка дня

Сразу с панча: не используйте input[type=“number”].

Он тащит за собой целый ворох проблем:

1. странно выглядит (ниже о том, почему);
2. плохо стилизуется;
3. не подчиняется стандартным атрибутам вроде maxlength (sick!);
4. имеет ARIA-роль spinbutton (ниже поясню, что это);
5. позволяет ввести e (10e9) и валидация даже не заикнётся;
6. в старых Safari и Chrome округляет введённые числа (например, номер кредитки) до мантиссы и экспоненты (по-моему, это уже конец);
7. во время ввода можно случайно нажать стрелку вверх или вниз (или даже тронуть колесо мышки на некоторых ос) и введённое число изменится.

Как видите, минусов немало. А откуда они вообще взялись?

А всё просто: input[type=“number”] создавался для имитации т. н. tally counter, ручного счётчика. Ну вы наверняка видели фильмы, где людей или скот считали надетым на палец устройством (см. иллюстрацию выше). Отсюда и ARIA-роль spinner (счётчик оборотов), и стрелки ввода.

Вот только числа с плавающей запятой или ввод мантиссы и экспоненты — это уже самодеятельность браузеров. Что приводит к идиотичным ситуациям вроде округления чисел.

Так что же делать?

А делать следующее:

<input type="text" inputmode="numeric" pattern="[0-9]*">

В 2021 году с такой конструкцией проблем у вас не возникнет. И с точки зрения доступности всё верно. И на мобильных клавиатура нужная встанет.

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

За подробностями можно обратиться к блогу разработчиков официального сайта правительства Великобритании: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

Крайне неожиданно было вообще узнать, что ребята из техотдела правительства Великобритании вообще свой блог ведут на официальных началах.

Я помню подобное было у сайта kremlin.ru. И то в итоге почти все фишки исчезли со временем... Но мы отклонились от темы.

Подытожим: input[type=“number”] делался не для того, как его применяют.

Подумайте об этом.

#css #html #number #aria #semantics #a11y

#видео дня

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

У меня ещё есть огромный проект на работе на ES3 и перевести его на TS очень непросто, но очень хочется.

Так вот, совсем недавно Евгений Обрезков записал целую двухчасовую лекцию про типы в TypeScript: https://youtu.be/i03l0N5g7nE

И вот мне всего год назад чего-то подобного очень и очень не хватало.

Желательно иметь хоть какое-то понятие о том, что такое TypeScript и базовые типы вообще, ибо лекция построена по принципу велосипедостроения. Создавая свои типы для разных данных, вы сможете понять, зачем в TS введена та или иная сущность.

#typenoscript #types

#заметка дня

В чате вопрос возник: «А при каких условиях и на что нужно ставить role=“button”?»

Вопрос весьма разумный, ведь вроде как кнопка она и есть кнопка, button. Вот только не всё так просто.

Для начала давайте определимся раз и навсегда: ссылки вместо кнопок не используются никогда.

Ссылка – это или переход к якорю на этой же странице, или же переход на другую страницу и только. Никаких a[href=“#”] с onClick, забудьте.

Остаются button, input[type=“button”] и input[type=“submit”].

Последние потомков внутри не предполагают и являются замещаемыми. Это значит, псевдо-элементов у нас тоже там нет. Впрочем, они вполне себе неплохо оформляются и как вещь в себе работают сносно: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/button

И вот, button. Что же с ним может быть не так, что нам потребуется нечто с role=“button”?

Давайте с очевидного: валидатор запрещает иметь div внутри button.

Выражаясь языком спецификации, button ожидает фразовый контент, а не потоковый: https://caninclude.glitch.me/can/include/?child=div&parent=button

То есть речь идёт не только о div, а ещё о десятке тегов. В итоге официально вкладывать можно практически один лишь span. Наверное, это не всем и не всегда удобно.

Впрочем, браузеры такой трюк позволяют.

Но если вам не всё равно — добавьте role=“button” и tabindex на любой удобный вам элемент, чтобы превратить его в интерактивный. Валидатор и скринридеры будут довольны. А ещё старые Safari, которые не умеют во flexbox на кнопках.

Мы у себя в дизайн-системе назвали такой компонент PlainButton, вот иногда ну надо.

Второй же случай посложнее.

Есть такой вид кнопок, toggle-кнопки. Переключатели. Это не checkbox, это не switch. Это просто что-то, что можно «зажать» сейчас и «отжать» потом. Например, кнопки в текстовом редакторе.

Они или находятся в зажатом положении (текст по центру, полужирный и т. д.), или в отжатом. Переключаем, в общем.

Почему это не чекбоксы? Потому что это не волеизъявление (согласие на что-то) как таковое, это просто некое действие, влияющее на что-то в приложении. Почему не свитчи? Потому что мы ничего не включаем физически. Кажется, об этих концептах стоит потом подробнее написать 😅

В общем, если вы подменяете логику работы кнопки с моментальной реакции на что-то иное вроде toggle, вам необходимо отдельно указать как минимум два необходимых атрибута: role=“button” и aria-pressed. Это же касается, например, кнопок открытия аккордеонов. Вот только вместо pressed нужно будет устанавливать expanded: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role

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

#button #a11y #role #toggle

#работа дня

Итак, по моей вине новые пользователи нашего продукта не могли его запустить. Как это обнаружилось? Упало число запросов на пробную лицензию.

Что в этой ситуации плохо?

Плохо не то, что я допустил ошибку в коде. Плохо не то, что этот кусок кода практически невозможно протестировать. И даже не то, что этот PR прошёл ревью.

Плоха скорость реакции.

Любой продукт такого уровня с ног до головы обмазан записями в лог и различными средствами обнаружения аномалий. И вот тут случился затык.

Главное в этой ситуации, да и в любой другой, не поддаваться панике. Не бегать как курица с отрубленной головой по офису. Не думать, что уволят.

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

Естественно, будет встреча по поводу даунтайма. Естественно, придётся объяснять, что случилось.

Любая ошибка — это повод анализировать проблему, а никак не нервничать.

#work

#заметка дня

Итак, весьма очевидно, какие устройства разделяют стили выше:

✅ десктоп
✅ мобильные
✅ что-то со стилусом
✅ какое-то устройство
✅ мышеподобное нечто

На это всё дело имеется спецификация: https://drafts.csswg.org/mediaqueries/#pointer

И конечно же можно посмотреть поддержку: https://caniuse.com/css-media-interaction

Ну и попробуем, почему же нет: https://codepen.io/meduzen/pen/BqwYgj?editors=1100

Кажется, прям хорошо. Но не совсем.

iPad Pro что в режиме стилуса, что в режиме мыши пошлёт вас куда подальше. А если вспомнить, насколько велико разрешение его экрана… в общем, вернётесь вы к медиазапросам с плотностью пикселей.

Но в целом, в 2021 году этим всем вполне уже можно пользоваться.

#css #media #stylus #touch #hover #cursor #mobile

Так, господа, а чего это я. Мы же обычно скриншоты с устройств выкладываем к таким заметкам.

Два моих в комментариях. Поддержите :)

Переключайте codepen из заметки в режим Full Page и делитесь.

#вопрос дня

Что браузер выведет в консоль?

#тред дня

Мне приходится проводить всё больше и больше собеседований к нам в Supermetrics на позицию фронтенд-разработчика, поскольку компания растёт.

Да, внезапно, хоть канал и называется «Будни верстальщика», моя позиция — Tech Lead команды разработки одного из наших основных продуктов.

И я уже пересмотрел достаточно много тестовых заданий. Чаще всего они меня не устраивают с самого начала.

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

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

1. Помни о том, что тот кто будет проверять тестовое будет это делать на бегу и вряд ли сможет сделать это хорошо. Дедлайны горят, прод горит, митинги кучами. А тут ещё тестовое проверять. Ни у кого нет времени два дня разбираться с твоим кодом.

2. Проверяющий скорее всего будет смотреть на формальные признаки. Сам код будет прочитан по диагонали и если там нет цепляющих взгляд вещей то он пройдет “ревью”.

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

4. Первая мелочь - не пиши весь код в одном файле, даже если кода 50 строк. Проверяющий доебется что не умеешь декомпозировать и в прод будешь писать так же в одном файле.

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

6. Третья - подробное ридми. Просто код без описания никому не нужен, скорее всего чел забьет его вообще смотреть. Напиши что ты сделал, для чего, как запускать, как запустить тесты, как правильно посмотреть работоспособность. Представь что делаешь опенсорс проект.

7. Хорошо если ты заморочишься и сделаешь мейкфайл, а еще докерфайл. Делов на 15 минут а сразу бонусных очков заработаешь.

8. Если можешь - лучше пиши на английском - ридми, коммит месседжи, комментарии к коду. Добавит очков, у нас странное отношение к английскому.

9. Добавь файл с версией, пусть будет вечный 0.1.0-SNAPSHOT но проверяющий заметит что ты подумал о версии. Совсем мелочь на 10 секунд работы, а очень бросается в глаза.

10. Старайся форматировать код читабельно, чтоб он выглядел красиво. Не комментируй каждую строку. Код должен выглядеть прилично если его смотреть по диагонали. Однобуквенные переменные оставь для прода, в тестовом задании их писать нельзя. (Ну счетчики i,j можно)

11. Если просят задание в виде репозитории отформатируй git log. Он должен выглядеть прилично и показывать ход мысли. Даже если ты писал за один присест. Покажи что ты умеешь атомарно вносить изменения а не одним куском. Ну и автора не забудь поправить. Фамилия имя вот это все.

12. Вот тут можно посмотреть как делал тестовое я (2pizza, прим. редактора). Кода меньше чем обвязки в виде скриптов и описаний.

13. Главный принцип - тестовое задание должно выглядеть как настоящий проект, даже если там делов на час. Это все не гарантия стопроцентного прохождения, но сильно сильно улучшит мнение проверяющего.

#собеседование #тестовое #работа #личинкатимлида #twitter

#заметка дня

Мне не очень нравится вложенность в SASS/SCSS/LESS и иже с ними.

Не очень нравится и будущее предложение внести вложенность (nesting) в CSS.

И я поясню, почему.

В первой части заметки много кода, телега не справится. Пройдите сюда, пожалуйста: https://gist.github.com/bekharsky/dea79c6b51fb693fba81897a40a594a4

Не так давно я в чате пытался помочь человеку, который накидал & для формирования классов (пытался в БЭМ) и никак не мог понять, как же сделать &:hover.

Получалось что-то вроде:

.block {
  &__element {
   // styles
  }

  &:hover {
    &__element {
      // styles
    }
  }
}

Кто-то на этом месте фыркнет. И будет неправ, потому что SCSS мог бы вместо простой конкатенации строк делать что-то более умное с блоками. Но надо ли?

Более опытные вспомнят про кеширование селекторов. Тоже вариант. Закешируем с десяток, почему нет… попробуй разберись.

В общем, я с некоторых пор использую нестинг только для псевдо- классов и элементов. Ограничиваю область видимости, не пытаясь решить все проблемы на свете.

Нестинг затрудняет понимание кода и поиск. Стили потомка могут оказаться в любом месте стилей родителя. Зачем?

Все мои аргументы касаются только читаемости кода. Ты можешь быть юным гением, который знает любое место в своём проекте. Но зачем вообще тратить ресурсы мозга на это?

#css #scss #nesting

#статья дня

Схлопывание отступов… марджинов, маргинов, margin — да как пожелаете.

В мире flexbox и grid всю боль этой фразы понять непросто, хотя стоило бы. Возможно, перестали бы пихать флекс там, где достаточно блока… ну да ладно. Чего только стоит один мой недавний вопрос: https://news.1rj.ru/str/htmlshit/531

Но Джош Камю просто взял и сделал прекрасную статью, на пальцах и картинках объясняющую схлопывания в разных ситуациях: https://www.joshwcomeau.com/css/rules-of-margin-collapse/

Как всегда, горячо рекомендую если не читать, то хотя бы по примерам потыкать. Лучше никто не делает пока :)

#css #margin #collapse #tutorial

#фишка дня
…несуществующая

В эту последнюю пятницу лета (в Финляндии лето считают с мая по июль, чтобы хотя бы два месяца осени были без снега) хочется помечтать.

Вы только подумайте, насколько простым стало бы создание стилизованных радиокнопок и чекбоксов если бы у нас в руках был :has… суть – родительский селектор.

Но его нет. Он только лишь обсуждается: https://www.w3.org/TR/selectors-4/#relational

Правда, это сломает многие оптимизации в браузерах… но может, новые завезут.

Мечты, мечты…

#css #has

#заметка дня

Не давече чем вчера ко мне прибежал начальник нашего энтерпрайза с мольбой о помощи. «Все пропало», — говорит, — «Значения текстовых полей в форме настроек дублировались, это починили, но теперь не все данные сохраняются. Выручай!».

А все потому что коллега перед тем, как в отпуск уйти, сделал рефакторинг ключей (key) в выводе массивов в React. И почти всё протестировал.

Казалось бы, ключи. Но даже вроде бы опытные разработчики ошибаются и делают key недостаточно уникальными, что может привести, и приводит, к последствиям, описанным выше.

Форму я, конечно, починил, косяк был буквально в паре строк. Но придётся коллеге по возвращению скинуть тред небезызвестного Дэна Абрамова: https://mobile.twitter.com/dan_abramov/status/1415279090446204929?s=20

Буквально на пальцах и кружках 🔴🔵🟡 описано, в чем же вообще проблема и зачем React’у так нужны ключи в выводе массивов.

#react #key

#фишка дня

Мне тут сообщили, что в 92 Хром и в 90 Фаерфокс с пылу с жару завезли метод Array.prototype.at(). Передаёте в at индекс элемента массива и получаете его значение, собственно.

Я сижу и честно говоря не очень понимаю, зачем он так сильно всем нужен.

Если коротко, то при передаче положительного числа, он работает точно так же, как и . Т. е. arr[2] и arr.at(2) оба вернут третий элемент.

Веселье заключается в том, что at поддерживает отрицательные значения индекса. И вы правильно догадались, они отсчитывают значения элементов с хвоста.

Последний элемент имеет индекс -1.

Т. о. то, что раньше писалось как arr[arr.length - 1] теперь пишется как arr.at(-1). Ну и так далее.

Собеседник сказал, что от первого варианта пахнет языком Си 🧐. По-моему так от обоих.

А каково ваше мнение?

#js #array

Кажется, я нашёл способ гарантированно и бесплатно повторять баги вёрстки в Safari на Windows-машинах. Оставайтесь на связи, попробую упаковать эту информацию максимально доступно 🧐

#заметка дня

Давайте разбираться, что же не так с Safari и почему он отстаёт.

История Safari начинается с движка KHTML, первая версия которого вышла в 1998 году. KHTML разрабатывался как движок рендеринга HTML для среды рабочего стола KDE (как пропатчить KDE2 под FreeBSD?). Как и Trident в Internet Explorer для Windows, его планировалось использовать вообще везде в системе.

Разрабатывался медленно, но верно, и получился великолепным. В итоге именно его форкнули в Apple для создания движка своего браузера и взорвали общественность в 2003 году. Я сокращаю историю, советую почитать хотя бы Википедию, там интересно.

В общем, Safari просто был лучше всех существующих аналогов на тот момент и поэтому именно его движок решили использовать в Google для создания своего браузера. WebKit как раз был выпущен как открытый проект в 2005. В раскрутку Chrome была брошена вся медийная сила Google.

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

В итоге мы пришли к тому, что Safari, побыв некоторое мультиплатформенным браузером (с 2007 по 2012), уступил место на Windows окончательно. Для Apple это был маркетинговый ход, ибо выглядел он на Windows точно так же, как на macOS, включая даже рендеринг шрифта. Они надеялись так переманить к себе людей.

Прошло 8 лет. Blink и WebKit очень сильно разошлись по своим возможностям. Google начала активно подминать под себя веб, давя всё на своём пути (почитайте хотя бы, почему сдохла Opera). Новые возможности начали появляться как на дрожжах, иногда просто ради реализации желаний того или иного вендора. Иногда этим вендором была сама Google (удивительное рядом).

Apple не имела таких длинных рук в вебе. Ошибка ли это или нет, но компания решила занять позицию "защиты" своих пользователей от посягательств (других вендоров, в основном). Правда где-то они переборщили и далеко не каждая фича современного веба реально имела какое-то отношение к безопасности. Например, различные поля ввода (даты, времени, цвета). Но давайте честно — они и в Chrome c Firefox совершенно неудобны и выглядят крайне странно.

Второй аргумент Apple — это энергоэффективность Safari. И тут им сложно что-то противопоставить, Chrome жрёт батарею просто на ура. Firefox чуть лучше, но в целом у него точно так же имеются проблемы с совместимостью то тут то там, особенно на мобильных устройствах.

Apple, перестав развивать версию Safari для Windows, забросила и адаптацию WebKit, оставив это сторонним разработчикам. Появились WebKitGTK и Qt WebKit. Если слова GTK и Qt вам не знакомы, это, очень грубо говоря, UI-киты для разработки десктопных приложений на разных платформах, но в основном, конечно, для основанных на Linux системах. На WebKit стали появляться независимые браузеры и он приобрёл большую любовь сообщества. Некоторые из них были даже доступны на Windows (Midori, Epiphany).

А потом в мир ворвалась вечно везде опаздывающая последние лет 15 Microsoft и представила WSL, Windows Subsystem for Linux. Стало возможным запускать даже графические приложения без особых проблем вообще и разработка версий вышеупомянутых браузеров для Windows окончательно застопорилась.

Apple никак не помогала адаптировать процессы разработки WebKit, и многие независимые Windows-разработчики повернулись в сторону Blink. Но под Linux разработка не прекращалась и последние версии движка WebKit всё так же доступны в составе современных браузеров.

Завтра я покажу наш первый вариант решения проблемы. Как минимум, из трёх. Многие уже точно догадались, к чему я веду :)

#apple #webkit #safari #wsl

Ну, как обещал. Смотрим на баги Safari в Windows. С опозданием на день, но вы мне простите, надеюсь :)

Подробное описание летит следом, терпение.

#заметка дня

Продолжаем наше сафари по Safari (офигеть каламбур).

Тенденция такова, что вообще никто не любит собирать браузеры на WebKit. Blink компилировать и интегрировать намного приятнее. Остались лишь самые упорные. Ну, с ними и поработаем.

Итак, давайте запустим браузер Epiphany в Windows. Он же GNOME Web.

Установка

Нам понадобится:

1. WSL2: https://docs.microsoft.com/en-us/windows/wsl/install-win10

Не надо бояться, там делов на десять минут.

Кстати, горячо рекомендую попутно поставить WIndows Terminal. И ещё более горячо рекомендую привыкнуть к мысли, что на WSL вообще всё делать удобнее, VSCode вас в этом поддержит.

Могу потом показать, что именно я имею в виду.

2. Я буду производить эксперименты на Ubuntu, так что устанавливаем её из магазина приложений. Более опытные могут брать что угодно.

3. Устанавливаем в Ubuntu epiphany-browser:

sudo apt install epiphany-browser

Возможно, списки серверов, раздающих пакеты приложений (да и списки приложений вообще) нужно будет обновить:

sudo apt update

4. Если у вас версия Windows 10 ниже 20H2, вам потребуется VcXsrv.

Это сервер X Window System. Я намеренно опускаю объяснения, что есть что, для этого есть Википедия, но именно эта штука позволит вам запускать графические приложения Linux в Windows.

Можно ещё XMing, но я в него не умею. Поделитесь.

Если же у вас Windows 10 20H2 или Windows 11, вам даже этот шаг не нужен. Всё заработает из коробки:

В общем, это всё.

Запуск

Можете посмотреть видео выше, а можете — почитать инструкцию:

1. Сначала нужно запустить X-сервер, для этого в составе VcXsrv имеется утилита XLaunch. Стартуем.

2. Она предложит режим работы на выбор, я предпочитаю многооконный полноэкранному.

3. На втором экране выбираем просто запуск сервера, без конкретного клиента (Start no client). Клиент это, собственно, приложение. Логика X-сервера немного перевёрнута с ног на голову, кому интересно — почитает Википедию, а мы двигаемся дальше.

4. Поскольку моё личное железо довольно бывалое (ThinkPad T450s), я решил не пытаться запускать графическое ускорение, оно всё равно для наших целей не нужно. А вот авторизацию стоит отключить (Disable access control), одна машина же.

5. Ubuntu надо указать, где же находится наш сервер окон. Для чего выполняем следующую команду:

export DISPLAY=$(grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'):0.0


Так получилось, что WSL2 требует IP-адрес даже локального компьютера, так что приходится ему его и указывать. Т. е. вот этот кусок внутри большой команды:

grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'

Просто выводит ваш собственный локальный IP-адрес.

Для этого и нужна вся магия grep и awk. В моём случае получается:

export DISPLAY=192.168.3.1:0.0

В вашем – ваш собственный адрес.

Можно потом и в конфигурацию вашей командной строки внести (.bashrc или .zshrc), чтобы работало сразу при запуске.

6. Ну теперь, пожалуй, надо запустить и сам браузер:

epiphany


Если всё было проделано верно, откроется окно браузера, не совсем похожее на ваши привычные Windows-окошки (что за день, каламбур за каламбуром). Это всё потому, что Epiphany использует так называемые Client-side decorations. Это когда управление окном отрисовывается самим приложением. Мы отвлеклись.

Версия WebKitGTK в моём случае 2.32.3. Это примерно соответствует Safari 14. Внизу баги, которые я проверял на видео:

1. Clip-path и stacking context:
https://bugs.webkit.org/show_bug.cgi?id=140535
https://bug-140535-attachments.webkit.org/attachment.cgi?id=244746

2. Flexbox на summary:
https://github.com/philipwalton/flexbugs
https://philipwalton.github.io/flexbugs/9.3.a-bug.html

3. important и animate:
https://bugs.webkit.org/show_bug.cgi?id=75558
https://bugs.chromium.org/p/chromium/issues/detail?id=552085
http://jsfiddle.net/fFJ3m/1/

И — о чудо — они совпадают с Safari 14.1.2. Уж можете мне поверить.

Засылайте ваши любимые баги в комментарии, посмотрим-с.

#safari #linux #webkit #epiphany