HTML *

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

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

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

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

60-70% поисковых запросов в 2026 году заканчиваются без клика — пользователи читают ответы ChatGPT, Perplexity или Gemini и закрывают вкладку. Классическая оптимизация сайта под поисковые системы больше не гарантирует видимость. Нужна GEO оптимизация — адаптация контента под генеративные движки искусственного интеллекта.

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

Для кого: разработчики, техдиректора, SEO-специалисты, которые видят падение трафика при стабильных позициях.

Время чтения: 10 минут. Результат: чек-лист действий на 30 дней.

Почти все элементы мира хайтека, от самых современных ИИ-систем крупнейших компаний до обычных кусков кода, написанных студентами, аннотируются и описываются в одном простом текстовом формате. Когда вы пытаетесь дать сложные инструкции 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 пока только в качестве экспериментальной возможности).

Всегда хотел сравнить ИИ модели на чем-то наглядном и с большим творческим потенциалом. Если попросить ИИ решить школьную задачу по математике, то, скорее всего, все справятся на отлично, тут и сравнивать нечего. Если попросить решить более сложную задачу, то уже придется объяснять читателям, кто из ИИ прав, а кто не очень. Создание компьютерной игры по мотивам хита 80-х, да и еще работающей в мобильном и десктоп браузере, кажется идеальной задачей для сравнения современных ИИ моделей. Посмотреть и поиграть в результаты будет и полезно, и весело.

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

Всем привет!

Пока из каждого утюга рассказывают о различных ИИ-инструментах, агентах и прочих радостях упрощающих жизнь, я хочу рассказать о 11 незаслуженно потерянных фичах в недрах Chrome Devtools. Про фишки ИИ в DevTools рассказывать не вижу смысла, так как в нашем регионе они пока не работают.

Кстати, первая часть тут - тык.

Погнали!

Всем привет! Меня зовут Максим Иванов. Сегодня я хотел бы провести небольшой исторический экскурс и объяснить, почему Document Picture-in-Picture — это не просто способ отображать видео в формате «картинка в картинке», а новое и любопытное API, которое потенциально может заменить привычный всем window.open.

Возможность выводить видео в режиме PiP появилась еще в сентябре 2018 года в Chrome 69. С тех пор прошло более семи лет активного тестирования и развития. В 2019 году подобный механизм появился в Safari, а к 2020-му — и в Firefox.

Теперь, когда почти каждый браузер умеет открывать видео в отдельном плавающем окне, возникает логичный вопрос: могут ли браузеры с той же легкостью открывать в отдельном окне интерактивный HTML-контент, а не только видео? И если да, то каким образом? Давайте поговорим об этом ниже.

Представьте ситуацию: пятница, вечер, до релиза осталось два дня. Заказчик внезапно вспоминает, что «было бы неплохо генерировать договоры в PDF». Знакомо?

Я оказался в похожей ситуации год назад. Задача казалась тривиальной: взять HTML-шаблон счёта, подставить данные и получить красивый PDF. «Часа на два работы», — подумал я. Как ошибался...

Часто в работе возникает потребность жестко выдерживать тайминг при заслушивании серии докладов: при защите проектов, программ развития, дипломных работ и прочее. Если в повестке дня какого-либо мероприятия 10+ докладчиков, то без строгого соблюдения регламента невозможно не выбиться из графика. Как правило, это приводит к тому, что запланированное время мероприятия увеличивается кратно. А докладчикам, выступающим последними, фактически не достаётся должного внимания.

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

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

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

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

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

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