HTML *

Привет, Хабр!

Я говорю о семантической вёрстке уже десять лет. Только как-то так получилось, что в последнее время я ничего не писал на эту тему. Надо исправляться!

В современных веб-интерфейсах я часто встречаю определённый набор семантических элементов. Это header, main, nav, footer. Даже элемент button встречается. Реже, чем другие, но всё же есть.

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

Давайте посмотрим, что я вам подготовил.

Выкатили новую фичу, а потом бэкендер со своим Firefox пишет, что у него что-то не работает? Или пользователь с Safari жалуется на неудобства? Ничего страшного: поищу причину в интернете, починю баг и продолжу использовать для разработки Chrome </sarcasm>.

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

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

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

Год назад я выложил RWC — реактивные веб-компоненты на сигналах, без JSX и шаблонного компилятора. Статью прочитали восемь тысяч человек, тридцать оставили комментарии, после чего я переписал ядро. Рассказываю, что изменилось в 3.0, и отвечаю на главные претензии из комментариев: зачем это всё, если есть Lit, и правда ли Web Components так плохи, как о них говорят.

Что делать, когда есть вполне стандартная задача, но популярные инструменты не могут ее решить? Правильно, время - изобретать свой велосипед.

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

Видим, что нам необходимо проверять на покрытие именно сущности, а не ветвление, сценарии или код, как это делают, допустим, coverage.py или pytest-cov

Атрибуты width и height сэкономят ресурсы CPU затрачиваемые на отрисовку страницы. Также они избавят от эффекта «скачущих изображений», когда во время загрузки страница резко дёргается, раздвигается, чтобы освободить место под под появляющиеся изображения.

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

Привет, Хабр.

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

Вместо обычного ворчания я делюсь мыслями о том, как исправить ситуацию. Больше всего мне нравится показывать, что HTML и CSS могут помочь в этой задаче.

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

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

А теперь давайте посмотрим, что я вам подготовил.

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

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

Что, если я скажу вам, что в 2026 году JavaScript для всего этого нам больше не нужен?

Всем привет! Меня зовут Евгений, я фронтенд‑инженер с большой экспертизой в разработке современных веб‑приложений. Сегодня хочу рассказать про свой очередной open‑source проект для построения веб‑приложений на основе Angular.

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

Итак, встречайте Centrifugal. Посмотрите официальный сайт проекта, там очень много крутых примеров использования!

Проект разрабатывался изначально, чтобы создать набор высокопроизводительных, гибких инструментов и компонентов для построения веб‑приложений. Но на одной из итераций разработки я решил обеспечить поддержку для построения All‑in‑One интерфейсов, то есть добавил режим standalone‑приложений с отображением собственной виртуальной клавиатуры, которую можно полностью кастомизировать. Тем самым обеспечил полноценную поддержку создания пользовательских интерфейсов, например, под киоски самообслуживания и тому подобное.

У вас бывает такое чувство, когда вы при выполнении работы упёрлись в какую-то проблему и что-то внутри подсказывает, что не может такого быть, чтобы у неё не было решения? Когда кажется, что уже всё пропало и мы столкнулись с фундаментальным ограничением реальности, но отказ принять это продолжает вести вас в дебри спецификаций, беседы на Github 10 летней давности и изучение статей гигантов уже прошедших этот путь и поделившихся с нами своими результатами? И вот спустя многие часы напряжённого скрипа извилин вы дописали очередную строчку, обновили страницу и вот оно, то, что вы хотели получить смотрит на вас с экрана? Это ощущение успеха, наверное, в той или иной степени знакомо каждому инженеру. В такие моменты мне, обычно, очень хочется поделиться результатом с коллегами и, по возможности, написать статью если это может быть полезно кому-то ещё. В этой записи я собрал 3 подобных ситуации, где в рамках нашей работы возникли решения, которые, насколько мне известно, довольно уникальны и в полной мере не были описаны раньше. Приглашаю вас разделить со мной радость обнаружения решения, которое казалось невозможным!

Каждый раз, когда верстаешь новый проект, лендинг или дэшборд, Дизайнер просит поставить на плашки ссылки со свежими логотипами сервисов, соцсетей или технологического стека. Начинается отдельная каста разработки и дизайна: найди официальный брендбук, вытащи оттуда SVG (Не факт что он там будет) или иди на сторонние агрегаторы, где половина файлов кривые, а скачивание запрятано за скрытой рекламой "Скачать Яндекс". Когда мне это полностью надоело я создал свой сервис - ГдеИконка (GdeIkonka)

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

15 июля Canva выпустила Code 2.0. Анонс успел отлежаться, первые восторги немного выветрились, а независимые авторы добрались до кнопок, которые обычно остаются за краем презентации.

Главное новшество звучит скромнее привычного обещания собрать сайт одной фразой. Получившийся проект теперь можно редактировать как обычный дизайн Canva: менять текст, цвета, изображения, обсуждать правки с командой и публиковать всё из одного окна. Ещё сервис принимает готовый HTML и превращает его в редактируемый макет.

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

Фреймворки дают клиентский роутинг из коробки. У HTML и Web Components его нет. Если сайт уже отдаёт полные страницы, а клиентская навигация нужна только для части разделов, переписывать всё на фреймворк незачем.

Aura Router решает эту задачу, сохраняя HTML исходной точкой: маршруты объявляются как Custom Elements, а ссылки остаются обычными <a href>. Без JavaScript те же URL открываются как обычные страницы.

В статье соберём минимальный сайт из двух страниц и проверим прямой заход по URL, клиентскую навигацию и работу ссылок без JavaScript.

Статья посвящена базовым принципам работы тайловых веб‑карт. В ней рассматривается, как карта мира разбивается на небольшие изображения — тайлы, как устроен их URL и что означают параметры zoom, x и y.

На простых примерах разбирается связь между географическими координатами и положением тайла в общей сетке. Пошагово выводятся формулы преобразования долготы в координату X и широты в координату Y с учётом проекции Web Mercator.

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

Часто разработка начинается с кода. Есть идея - мы открываем IDE, создаём проект и начинаем писать. Не задумываясь о том, что в этот момент мы ещё можем не понимать, какую проблему решаем и что вообще должна делать система.

В этой статье разберём путь от пользовательской потребности до реализации: UCD → FR/NFR → KISS → компонентная разработка → код.

Привет, Хабр!

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

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

Давайте посмотрим, что я вам подготовил.

CSS «слушает» нас. Нет, не в буквальном смысле. Суть в том, что в CSS появляется все больше псевдоклассов, которые позволяют реагировать на события JS без необходимости писать сам JS. Формально псевдоклассы отслеживают состояния, а не события, но порой они настолько похожи на обработчики событий, что разница становится почти незаметной (хотя в контексте CSS это не так уж важно).

Я тут решил решил чуток заморочиться и протестировать локальные MOE модели на кодинг. Кодинг громко сказано - мои задачи исключительно игры причем на html, css, js. Но зато с таким набором можно сразу в продакшен, легко проверить без компиляций, кроссплатформенность ну и другие известные плюсы и минусы. На тесте побывало 10 моделей: Qwen 3.6 (MTP), KAT Coder V2.5, Gemma 4, Aurora-Code-1, Frontis, GLM 4.7 Flash, Ornith 1.0, Salience 1.5 Pro, Agents A1, GPT-oss 20b. Ссылки на модели есть в таблице результатов на которую ниже будет тоже ссылка. Многие из этих моделей сделаны на базе Qwen и тем интереснее было тестировать, потому что по бенчмаркам в карточках моделей на HF они часто превосходят своего учителя. Правда я сразу был настроен скептически и понимал что вряд ли они смогут составить реальную конкуренцию - хоть и дообучаются на кодинг, но такого рода тесты не очень как будто бы проходят, что собственно и подтверждает итоговая таблица с результатами (подсчитывал результаты Qwen3.8-Max):

После запуска хобби-проекта я заметил, что один робот за сутки открыл календарь 88 632 раза и добрался до 7273 года. Причиной оказалась обычная ссылка “следующий месяц”, которая создавала бесконечную цепочку корректных URL.

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

Привет, Хабр!

Я во фронтенде уже пятнадцать лет и всегда видел разные примеры кода «с душком». То, что десять лет назад считалось нормальной практикой, сегодня вызывает улыбку. Современная вёрстка не стала исключением.

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

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

Давайте посмотрим, что я вам подготовил.