HTML *

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

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

В этой статье мы посмотрим на Firefox DevTools в деталях. Отойдем от банальных соревнований в стиле «у кого DevTools длиннее». Вместо этого разберем, в каких ситуациях панель Firefox может сэкономить вам время, а в каких всё же удобнее остаться в Chrome. Откроем для себя несколько приёмов, которые можно добавить в свою ежедневную работу, независимо от браузера.

Зачем изобретать свой Street View?

Все мы привыкли к Google Street View, но что, если нужно показать пространство, куда машина со 360-камерой не заедет? Интерьер офиса, музей, университетский холл. Коммерческие решения для виртуальных туров часто дороги или ограничены в кастомизации.

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

Проблема заключается в том, что в таблице на React с колонками, у которых есть свойство position: sticky, иногда пропадала граница между соседними ячейками по вертикали. Причём проявлялась она не всегда и носит случайный характер. Забавно, что изменение масштаба страницы (Ctrl + колесико мыши) мгновенно возвращает исчезнувший бордер. При этом в CSS все прописано и никуда не исчезает — это чисто визуальный баг рендера.

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

Во фронтенде изменения происходят постоянно. Только разобрался с одним инструментом, он уже считается устаревшим. Плюс на смену ему появляются новые. В JavaScript регулярно добавляются новые методы и API, а HTML и CSS, разумеется, не отстают.

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

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

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

Всем здравствуйте, дорогие читатели!

Меня зовут Рамазан, я Frontend-разработчик, энтузиаст и я люблю исследовать грани возможностей современных Web-технологий.

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

Safari — новый Internet Explorer для фронтенд-разработчиков! Поведение вёрстки в нём отличается от спецификаций, а иногда бывает и непредсказуемым.

Но если Microsoft свой браузер похоронила, то Apple регулярно обновляет Safari, создавая новые проблемы для фронтендеров. Релиз Safari 26.0 не стал исключением, а усложнил ситуацию новый дизайн Liquid Glass, изменивший интерфейс браузера.

Я — Дима Фукс, Head of Frontend в Додо. Сегодня расскажу о старых и новых проблемах Safari на iOS на примере простой задачки: реализации фуллскрин-модалки с текстовым полем — то есть чата поддержки или окна комментария, встроенного в сайт.

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

Каждый год я смотрю, какие новые фишки в HTML и CSS стали поддерживаться современными браузерами. Таким образом понимаю, что уже можно использовать. Так как я люблю делиться всем с вами, то я подумал: «А почему бы не рассказать о новинках на Хабре?». Вот я и пришёл.

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

Моё главное правило для отбора фич заключается в том, чтобы она стала «зелёной» в 2025 году на сайте «Can I Use». Смотрю последние версии браузеров Chrome, FireFox, Opera, Edge, Safari, iOS Safari, Samsung Internet и Android Chrome.

Не буду больше тянуть. Давайте посмотрим, что я вам подготовил.

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

Мой личный топ из всех популярных онлайн-маркетов — это Wildberries. Я люблю этот сервис и активно им пользуюсь. Мне кажется, это уже хороший повод посмотреть, насколько он доступен людям с различными ограничениями. Безусловно, это очень популярная платформа в странах СНГ, но это, конечно же, не значит, что она одновременно и доступна на 100%.

Сразу хочу оговориться: я не пытаюсь подчеркнуть какой-то изъян платформы. В конце концов, у каждого продукта свои бизнес-приоритеты, и доступность (если она не обязательна с точки зрения законодательства) — это личное дело каждого бизнеса. К примеру, мой продукт тоже не удовлетворяет всем критериям доступности, да и многие другие, на которых я работал. При том что моя личная аналитика прошлого года показала, что 20% моей пользовательской базы меняют размер шрифта для лучшего восприятия, но не факт, что есть хотя бы один (я бы сказал, его и нет) кто использует продукт, будучи полностью незрячим, со скринридером.

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

Почти все элементы мира хайтека, от самых современных ИИ-систем крупнейших компаний до обычных кусков кода, написанных студентами, аннотируются и описываются в одном простом текстовом формате. Когда вы пытаетесь дать сложные инструкции ChatGPT, хотите поделиться списком покупок в Apple Notes или скопировать чью-то домашнюю работу в Google Документах, вы пользуетесь одним и тем же форматом. Самое безумное заключается в том, что этот формат придумал не конгломерат технологических корпораций, а ворчун с добрым сердцем, который сейчас, вероятно, пересматривает фильм Кубрика или болеет за любимую спортивную команду. Но нам стоит разобраться, как родились столь простые текстовые файлы; не только для того, чтобы я мог похвастаться щедростью и умом моих друзей, но и чтобы напомнить вам, как работает Интернет на самом деле: умные люди придумывают хорошие вещи, а затем отдают их бесплатно, снова и снова, пока их технология не захватит мир и не сделает его лучше для всех.

Идея «умного» рабочего стола у меня появилась давно. Под "умным" я понимал не виджеты, прогнозы погоды и не очередную анимацию, а максимально простую идею: фон рабочего стола должен соответствовать тому времени суток, которое сейчас у меня за окном. Без условностей. Только солнце.

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

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

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

Привет, друзья!

В этой небольшой статье мы вместе с вами немного пощупаем новый Web API - Anchor Positioning.

Anchor Positioning API предоставляет новые возможности для связывания элементов между собой. Одни элементы являются якорями (якорными, anchor elements), другие - позиционируемыми относительно якорей (закрепленными, anchor-positioned elements). Размер и положение позиционируемого элемента может определяться размером и положением якорного элемента.

Кроме того, с помощью CSS можно:

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

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

На сегодняшний день этот API поддерживается всеми основными браузерами (в Safari пока только в качестве экспериментальной возможности).

Привет, Хаброчане!

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

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

Странный заголовок, не правда ли?

А зачем вообще обходиться без id? Даже не знаю, но это вполне возможно, и приложение будет живым и вполне себе «реактивным». А всю «магию» при этом творит функция, которую я назвал tokenize.

Конечно же я, ни в коем случае, не настаиваю на отказе от id. "Элементарные" id никому не мешают и tokenize`у тоже. Но если обходиться без id, то как же получать ссылки на DOM элементы, для обращения к ним? Вот для этого и нужна функция tokenize, которая собирает референсы в удобную структуру с ветками, подветками и листьями (ссылками на DOM элементы). А вот как она это делает, мы с Вами сейчас и разберём.

Здравствуйте, товарищи! Меня зовут Валентин, и сегодня мы снова поговорим про Atomic CSS! Обсудим имеющиеся проблемы в верстке и посмотрим, как атомарный подход их решает (или не решает). Разберем основные мифы, посмотрим на лучшие практики этого подхода и сделаем выводы.

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

Уже многие годы JavaScript остаётся «рабочей лошадкой» веба. Если вам нужно сделать то, что невозможно реализовать средствами HTML и CSS, то обычно найти решение помогает JS. И это замечательно! JS помог расширить возможности пользователей, а также стимулировал прогресс HTML и CSS!

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

Я ничего не имею против JS, но у него есть иные задачи, кроме как управление аккордеонами и внеэкранными меню навигации... Кроме того, JS нужно скачивать, распаковывать, обрабатывать, после чего он ещё часто тратит память на мониторинг и поддержку фич. Если мы сможем перенести какую-то функциональность JS в нативный HTML или CSS, тогда пользователям придётся скачивать меньше данных, а оставшийся JS сможет уделить внимание более важным задачам, с которыми (пока) не справляются HTML и CSS.

В этой статье я приведу несколько примеров; сможете придумать свои?

Опыт одиночной разработки и поддержки долгоживущего веб-приложения: отказ от фронтенд-фреймворков, использование нативных возможностей браузера, работа с Core Web Vitals и влияние AI-поиска на трафик реального проекта.

Кто-то знает и пользуется, а кому-то, возможно, короткая статья освежит в памяти этот лайфхак. Я так пользуюсь постоянно.

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

Хорошо, если в поле ввода пароля есть стандартная кнопка «Отобразить пароль»，и можно посмотреть, что подставляется в поле ввода пароля:

Привет, друзья!

В этой небольшой статье я хочу рассказать вам о новом Web API - Invoker Commands.

Invoker Commands API позволяет декларативно управлять поведением некоторых интерактивных элементов с помощью кнопок. "Декларативно" означает, что управления элементами осуществляется только с помощью HTML, без JavaScript.

На сегодняшний день этот API поддерживается всеми основными браузерами (в Safari пока только в качестве экспериментальной возможности).