Веб-спеки

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

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

Это также способ быть в курсе новинок и трендов. В гридах, например, до сих пор не доделана спецификация CSS Grid Layout Module Level 2, посвящённая сабгридам (подсеткам), а также есть Level 3, посвящённый кирпичной раскладке (Masonry 1, 2). Знали? =)

Спецификации часто включают рекомендации по лучшим практикам, которые помогают избежать распространённых ошибок и улучшить производительность сайта. Когда вышел will-change, это свойство сразу же выстрелило в миллионы колен. Разработчики стали более аккуратно относиться к CSS-свойствам и действительно разбираться в том, что они используют в коде.

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

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

Благодаря флексам и гридам у нас появилась спецификация CSS Box Alignment Module Level 3, которая отвечает за выравнивание элементов внутри их контейнеров. Но знаете что? Спецификация никак не связана с гридами и флексами, то есть выравнивать мы должны уметь хоть в блочной, хоть в табличной вёрстке =)
Ну это в спеке, а что с браузерами?

align-content: center заработал во всех браузерах для блочной вёрстки(дивчиков)

Посмотрите пример как центрируется заголовок внутри дива, без флексового и гридового контекста: https://codepen.io/web-dot-dev/pen/abMxwzr. Красота же.

Начал исследовать visually-hidden.

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

Всё это опубликую в этом репозитории: https://github.com/nikolai-shabalin/visually-hidden

Уже много материала удалось насобирать

Кажется у меня произошло разочарование века: условный импорт для CSS-файла всё равно загружает CSS-файл, но браузер не обрабатывает файл.

Коротко. В браузеры постепенно имплементируется условный импорт файлов:

  <style>
    @import url('./anchor.css') supports(position-try: flip-block);
  </style>

Работает это так. Файл ('./anchor.css') начнёт работать только если supports подтвердит, что браузер поддерживает (position-try: flip-block). Я думал, что если браузер не поддерживает position-try: flip-block, то './anchor.css' даже не загрузится, но это не так.

Фронтендер

Поставьте любую эмодзи этому посту, если вы прямо сейчас ищите работу фронтенд-разработчиком

Если хотите немного поразвлекаться с JS, то вот вам задачка над реальным проектом. Бери, да делай =)

На сайте css-properties нужно создать фильтр CSS-эпох. Если захотите сделать, то отпишитесь в issue, что берётесь.

https://github.com/nikolai-shabalin/css-properties/issues/29

Сегодня читал всю обратную связь по HTML1. Всё конечно же написать не смогу.

Короткие итоги:
Курса в целом: 9.6/10
Наставники: 10/10 💪

Рад что результаты работы так высоко ценят. А теперь сниму розовые очки и пойду поднимать в небеса HTML2 =)

Привет.

Поделитесь ссылками на любые свои проекты. Можно студенческие. Желательно свежие. Себя покажите, да других посмотрите.

Результаты State of HTML 2023

Исследование охватывает не только HTML-теги, но и доступность, веб-компоненты и многое другое.

Интересные для меня моменты:
- Средний возраст HTML-программиста 33,6 года. Мы старые
- Опыт разработки 10,7 лет. Мы опытные
- 51% имеет высшее образование в смежной области.
- Самый популярный скринридер - VoiceOver (26%). Покупаем макбуки и айфоны
- Самый популярный инструмент для проверки доступности, неожиданно, LightHouse (51%), а уже после Axe (23%)
- Ожидаемые элементы: интерактивные таблицы с сортировкой, фильтрацией и прочим, нативные табы, тогглер, нативный скелетон, контекстное меню(правый клик), бесконечный скролл, масштабирование изображений, более умный <input type="date">.
- Неожиданно и то, что людям нужны сложные нативные элементы. Не хватает настроек и возможностей стилизации.

Познакомиться с исследованиями можно на странице https://2023.stateofhtml.com/ru-RU/demographics/

Не минифицируйте CSS (мнение автора статьи)

78 kB сырого CSS превращаются в 65kB. Так ли вам важны эти 13kB?

Компрессия. Без gzip или Brotli уже вообще не должно быть сайтов:
- 78kB сжимается до 11kB
- 65 kB сжимается до 10kB
Так ли вам важен этот 1kB?

Протокол.
HTTP/2 мультиплексирование позволяет серверу использовать одно соединение для параллельной передачи нескольких запросов и ответов.
Если сжатый CSS-файл без минификации составляет всего 10 кБ, а затем разбивается на более мелкие фрагменты, скажем, по 2 кБ, то минификация становится как бы не проблемой

Статья: https://blog.sentry.io/why-dont-we-talk-about-minifying-css/

Моё мнение: занимайтесь оптимизацией сайта комплексно. Немножко CSS минифицировал, потом JS, потом HTML. Вот и картиночки оптимизировались. И хоба! 1mB сайта превратился в 100kB. Пользователь счастлив. Вы счастливы. Все счастливы.

Линтер для HTML

Напомню, что я делаю линтер для HTML на основе linthtml.

С последнего моего отчёта было многое, что сделано нового:
- Поправил правило htmlacademy/attr-req-value, которое требует заполнение атрибутов, например value="chto-nibud"
У правила появилось исключение для первого <option> в <select>
- input-req-label теперь исключает проверку <input type="submit">
- tag-req-attr появилась новая настройка ignore, которая спасает от ситуаций вроде <input type="submit" name="submit">
- Новое правило htmlacademy/req-stylesheet-link, которое проверяет наличие <link rel="stylesheet"> внутри тега head.
- Правило htmlacademy/req-mailto требует mailto: для ссылок с email в теле тега
- htmlacademy/no-blocking-script теперь игнорирует <script> с type="module" в <head>, так как подобные скрипты неблокирующие
- У <source> внутри <picture> требуем атрибуты размеров width и height если <source> внутри <picture>
- Добавил правило tag-forbid-attr, запрещающее использование указанных атрибутов в указанном теге.
- Правило req-tags-presence требует наличия указанных тегов на странице.
- Правило req-preload-font требует значения preload для шрифта.
- Правило req-webp-in-picture требует webp в <picture>.
- Правило no-class-in-container проверяет атрибут class для дочерних элементов внутри указанного контейнера.

Работа идёт и если у вас идеи для правил, то приходите в гости https://github.com/htmlacademy/linthtml-rules-htmlacademy

На данный момент уже стало ясно, что из-за того, что linthtml не развивается, а его API не обширно, то уже хочется какой-то другой инструмент. Поживём - увидим.

Альтернативное описание на максималках

Четыре года назад я на работе обсуждал, что альтернативное описания контентным изображениям никто не пишет. Все понимают, что надо, но всем лень. Тогда пришли к мнению, что надо донести простую мысль. Если лень, то хотя бы оставь alt правильно пустым — alt="". Это уже победа.

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

.element {
  content: url("images/background.jpg") / "альтернативное описание";
}

в content можно добавить /, после него написать описать изображение текстом. Такое описание попадает в дерево доступности.

Но это вообще не рабочий вариант, так как описание находится в стилях. Абсолютно никто не будет после изменения изображения, да и во время создания, менять текст описания, а это значит, что этот текст будет только сбивать столку.

Буквально сегодня, в Chrome 126 версии, должно произойти, то что сможет нам все помочь. Лень никуда не уйдёт, но будут способы делать нормальное описание.

И так: в спецификации CSS Generated Content Module Level 3 для content появились новые возможности, а именно использование функции attr() для альтернативного описания.

Исправим изначальный пример

.element {
  content: url("images/background.jpg") / attr(data-alt);
}

добавим в разметку атрибут

<div class="element" data-alt="Альтернативное описание"></div>

Кажется, что ничего не поменялось, текст "Альтернативное описание" всё также попадает в дерево доступности, а мы всего лишь перенесли описания из стилей в разметку. В этом заключается мощь. У нас появляются новые возможности управлять контентом. Теперь у нашего бэкендера появляется возможность взять нейросеточку, которая делает описания изображению, а результат работы нейросетки вставлять в разметку в data-alt="", ну либо сделать это руками.

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

gap

Часто ведь возникает вопрос «В каких случаях мне переписывать margin на gap» 🤔 У меня уже сложилось мнение, которое я ещё уточняю, но всегда не хватает примеров.

Ахмад Шадид постарался и показал кучу примеров - https://ishadeed.com/article/the-gap/
Статья на английском, но знаний английского не нужно, так как есть примеры кода и небольшие интерактивные демонстрации. Статья хоть и длинная, но хватит 5 минут, чтобы её посмотреть

Уже практически закончился Я 💛 Фронтенд 2024

https://www.youtube.com/watch?v=xKhuDlMySsE

но вы пересмотрите позже =)

Коллекция проектов для самостоятельной тренировки JS начального уровня.

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

https://www.jisan.io/dom-projects/#projects

<permission>

Пока мы все наслаждаемся тем, что не нужно изучать новые HTML-теги, Google начинает экспериментировать над новым тегом <permission>. Тег уже доступен в 126 версии Chrome за флагом.

Если коротко: Новый HTML-тег <permission> предназначен для запроса разрешений на использование функций, таких как доступ к камере или микрофону. Этот тег позволяет избежать проблем с "спамом разрешений", это ситуация, когда сайты постоянно запрашивают разрешения на доступ к различным функциям устройства.
Тег также поддерживает атрибуты для настройки запросов, такие как type и type-ext, например:

<permission type="camera">
<permission type="camera" type-ext="precise:true"> <!-- для разрешения геолокации -->

В type можно передавать несколько значений

<permission type="camera microphone">

Демо: https://permission.site/pepc

Стилизация элемента <permission> на данный момент сильно ограничена, но возможно будет расширена после окончания эксперимента.

<permission> работает вместе с API Permissions. Можно прослушать несколько событий:
- onpromptdismiss: пользователь отклонил запрос на разрешение
- onpromptaction: запрос разрешения был разрешен пользователем
- onvalidationstatuschange: элемент переходит из состояния "валидный" в состояние "невалидный"

На данный момент <permission> является одиночным тегом. Также я не увидел, что можно изменять текст "кнопки", видимо для снижения манипуляций над пользователем.

Новые стейджи

Делегаты Ecma TC39 находятся на этой неделе в Финляндии на 102-й встрече, которая проходит в течение трёх дней и организуется Mozilla и Университетом Аалто. Комитет работает на основе консенсуса и имеет право вносить изменения в спецификацию, если сочтет это необходимым. Сегодня несколько предложений получили консенсус для перехода на следующий этап.

Коротко:
- "Ленивая инициализация модулей" переходит на stage 2.7
- Error.isError() переходит на stage 2
- RegExp Escaping переходит в stage 2.7
- Promise.try переходит на stage 3

Ещё много вкусного в статье: https://socket.dev/blog/tc39-advances-key-proposals

Очерёдность выполнения

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

1. Сначала выполняется весь синхронный код:
- Весь код, который находится вне асинхронных конструкций (например, setTimeout, Promise, async/await), выполняется сразу же в порядке написания.
2. Выполнение микротасков:
- После выполнения всего синхронного кода, JavaScript движок выполняет микротаски (microtasks). К микротаскам относятся:
- Колбэки, добавленные в .then и .catch блоках промисов.
- Колбэки, добавленные с помощью метода queueMicrotask.
- Во время выполнения микротасков могут быть добавлены новые макротаски или микротаски. Они будут обработаны в следующих итерациях.
3. Выполнение макротасков:
- После выполнения всех микротасков, движок переходит к выполнению макротасков (macrotasks). К макротаскам относятся:
- Колбэки, переданные в setTimeout и setInterval.
- Колбэки событий DOM.
- Во время выполнения макротасок могут быть добавлены новые микротаски или макротаски. Микротаски будут обработаны в конце текущей макротаски.
4. Повторение цикла:
- После выполнения макротаски, движок снова возвращается к выполнению микротасков, если они появились в процессе выполнения макротасков.

console.log("Start"); // 1

setTimeout(() => {
  console.log("Timeout 1"); // 4 
  Promise.resolve().then(() => {
    console.log("Promise inside Timeout 1"); // 5 Микротаски будут обработаны в конце текущей макротаски.
  });
}, 0);

Promise.resolve().then(() => {
  console.log("Promise 1"); // 3 микротаски идут быстрее макротасок
  setTimeout(() => {
    console.log("Timeout inside Promise 1"); // 6
  }, 0);
});

console.log("End"); // 2 потому что синхронная задача

Приходите в комментарии если есть что добавить

Привет. Давно не виделись =)

Ко мне в команду ищем джуна фронтендера: React + TS + SCSS.

Требования
- Опыт работы с React.js от 1 лет (обязательно)
- Опыт работы с TypeScript от 1 лет (обязательно)
- Опыт работы c любым из популярных state manager: MobX (используется на проекте), Redux, и тд от 1 лет
- Знания в области кроссбраузерной и адаптивной верстки с использованием HTML5/CSS3
- Владение нативным JavaScript (ES5/ES6/ES7)
- Опыт использования пакетных менеджеров (NPM, Yarn).
- Опыт работы с git. Стандартный набор команд. Ничего сверхъестественного.
- Опыт командной разработки и умение разбираться в уже реализованном коде;

Будет плюсом:
- Опыт работы с CSS-препроцессором LESS/ SASS/ SCSS.
- Опыт работы с любой из систем сборки (Webpack, Gulp, Grunt, Browserify) будет плюсом.
- Опыт написания unit-тестов или e2e-тестов (Jest, etc).
- Понимание концепций ООП, методологий разработки, шаблонов проектирования;

Что делать:
Разработка web-приложения для возможности отрисовки диаграмм, моделирующих бизнес-логику обработки данных, в соответствии с бизнес- и системными требованиями. Участие в подготовке методики тестирования разработанного функционала.
Контроль качества кода, исправление дефектов. Проведение ревью и рефакторинга кода. Оптимизация производительности функционала, анализ ошибок и сбоев.

Формат работы: Очный / смешанный / удаленный

По всем вопросам пишите: https://t.me/kinzazdev

lint-staged

Инструмент, позволяющий запускать линтеры только для файлов, которые попадут в коммит.

Полезность инструмента

В крупных проектах запуск одного линтера на сотни файлов затягивается на десятки секунд. Ситуация усугубляется, когда количество линтеров увеличивается. Стайллинт проверяет сотни CSS-файлов проекта, eslint проверяет сотни js-файлов, а мы в это время гадаем, будут ли ошибки или подсветка редактора кода была достаточной.

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

В конфигурационный файл .lintstagedrc.json можно добавить запись в простом виде:

{
  "*.js": "eslint --fix"
}

Но работа для проекта остаётся непростой. Когда теперь будет коммит файлов (git commit), произойдёт следующее:
- Из всех файлов, которые попадут в коммит, отфильтруются все .js-файлы.
- Из-за указанного флага --fix произойдёт исправление для правил, которые можно автоисправить.
- Исправленные .js-файлы заново попадут в коммит.
Если во время работы eslint, даже с --fix, всё равно будут ошибки, то коммит не будет создан, а eslint как и всегда выведет ошибки в терминал.

npm-пакет: https://github.com/lint-staged/lint-staged

PS: lint-staged не отменяет полной проверки кода всех файлов. Её всё-таки нужно делать, но точно не во время активной разработки фичи.

Commitlint

Я продолжаю исследовать инструменты.

Commitlint — это инструмент, который проверяет сообщения коммитов в Git на соответствие определенным правилам.

Например, можно написать правило, чтобы заголовок коммита отвечал на вопрос "Что делает?".
У меня в команде принято писать в начале коммита номер задачи, для этого тоже можно написать правило.
Если сообщение коммита не удовлетворяет правилу, то коммит не создаётся, а в терминале происходит подсказка, что поправить, как в любых других линтерах.

Это позволяет не держать в голове все возможные правила ведения проекта, а переложить это на инструменты, которые всегда подскажут как поправить commit message.
Также удобно для тех, кто только пришёл в команду и привыкает к нюансам работы конкретно в этой новой команде.