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

В качестве альтернатив предлагаются раздельные инпуты для дня, месяца и года (особенно полезно для запоминающихся дат), селекты при ограниченном наборе вариантов и маскированные инпуты с плейсхолдерами. Для улучшения опыта можно использовать атрибуты: inputmode="numeric" для отображения цифровой клавиатуры, maxlength для ограничения ввода, pattern для валидации, autocomplete для автозаполнения и min/max для ограничений диапазона. Автор подчеркивает важность прогрессивного усиления и учета пользователей без JavaScript.

• Пользователи жалуются на нативные пикеры из-за необходимости тысяч кликов, чтобы выбрать дату рождения, и наоборот — кастомные пикеры не позволяют вводить дату текстом.
• Разработчики отвечают, что нативный <input type="date"> не поддерживает форматов вроде «MM/DD/YYYY» и не даёт контроля над UI, а кастомные пикеры не решают проблему с доступностью и не имеют единого UX.
• В итоге спор сводится к тому, что нативный пикер не решает проблему, а кастомный — не решает её лучше.
• Пользователи также жалуются на то, что нативный пикер не позволяет вводить дату текстом, а кастомный — не позволяет вводить дату текстом.
• В итоге, обсуждение сводится к тому, что нативный пикер не решает проблему, а кастомный — не решает её лучше.

Marko — это декларативный язык на основе HTML для создания динамических веб-интерфейсов, расширяющий стандартный HTML возможностями для современных приложений. Любой валидный HTML является корректным Marko, но язык добавляет декларативные конструкции для реактивности и интерактивности, позволяя встраивать JavaScript прямо в шаблоны. Ключевые особенности включают потоковую передачу контента для ускорения первого отрисовки, оптимизирующий компилятор и минимальный рантайм, что обеспечивает высокую производительность даже для высоконагруженных проектов вроде eBay.com.

Фреймворк предлагает гибкость синтаксиса — от привычного HTML до более лаконичных вариантов Concise и JS — и поддерживает TypeScript для строгой типизации. Marko обеспечивает разделение concerns, управляемые компоненты, вложенную реактивность и неизменяемое состояние, что упрощает разработку масштабируемых приложений. Интеграция с экосистемой включает file-based routing и возможность использования как простых шаблонов, так и мощных компонентов по мере роста проекта.

• Обсуждение вращается вокруг того, что веб-разработка циклически возвращается к идеям, похожим на ColdFusion и JSP, и это вызывает у участников разговора разные чувства от ностальгии до раздражения.
• Участники обсуждают, что такое "HTML-основнный" язык, и как он отличается от JSX и других подходов, и почему мы снова и снова возвращаемся к этой идее.
• Обсуждение затрагивает вопрос о том, что некоторые считают, что эволюция веб-технологий просто движется по спирали, где старые идеи периодически перерабатываются и выдаются как новые.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.

Проект "How Did I Get Here" от Hack Club демонстрирует путь, который пакеты данных проходят от вашего устройства до сервера. С помощью самописного трейсера ktr, работающего по протоколу ICMP с использованием поля TTL, проект в реальном времени отслеживает каждый узел маршрута. Интересно, что сайт работает даже без JavaScript — сервер последовательно отправляет обновленную HTML-разметку, создавая иллюзию плавной загрузки трейсера.

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

• Обсуждение охватывает различные аспекты traceroute и его ограничений, включая то, что AS-путь может быть нестабилен, а фактические точки пиринга могут сильно различаться.
• Участники обсуждают, что traceroute может не отображать обратный путь, особенно если сеть использует асимметричное маршрутизирование.
• Обсуждается, что веб-сайт может не работать из-за блокировки ICMP или из-за того, что маршрутизаторы не отвечают на ICMP запросы.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.
• Участники также обсуждают, что traceroute может не отображать правильный путь, если используются различные стратегии маршрутизации, такие как source routing или loose source routing.

Разработчик создал простое приложение для обучения детей инвестициям, так как школы не учат финансовой грамотности. Приложение представляет собой один HTML-файл, который работает как PWA (Progressive Web App) и устанавливается на старый смартфон, прикрепленный к холодильнику. Это позволяет детям визуально видеть, как их капитал растет день ото дня, с отображением ежедневного, недельного и месячного дохода, а также общего баланса. В качестве инвестиционного агента разработчик устанавливает реалистичные процентные ставки — достаточно высокие для мотивации, но умеренные, чтобы отражать реальные условия рынка.

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

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

Полностью оцифрован "Кодекс Атлантический" — крупнейшая коллекция рисунков и записей Леонардо да Винчи. В эпоху Возрождения искусство и наука не были так разделены, как сегодня, и Леонардо подходил ко всему как техник. Его художественные произведения были результатом математической точности, тщательного изучения и прямого наблюдения, а не просто творческим порывом.

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

• @kragen отмечает высокое качество ресурса, но указывает на низкое разрешение изображений (пример: https://codex-atlanticus.ambrosiana.it/assets/500/000R-1.jpg), что затрудняет чтение текста и архивацию.
• @vim-guru замечает, что некоторые страницы отображаются вверх ногами.
• @trvz предлагает решение: использовать URL с высоким разрешением (например, https://codex-atlanticus.ambrosiana.it/assets/2000/000R-1.jpg).
• @trvz рекомендует инструмент wget для пакетного скачивания всех изображений высокого разрешения (страницы R и V, номера 1-1119).

Статья напоминает о четырех важных HTML-тегах, которые стоит включать для корректной работы веб-страниц. Без <!doctype html> браузеры могут переключиться в quirks mode, имитируя устаревшее поведение. Указание языка через <html lang="en"> помогает поисковикам и скринридерам правильно интерпретировать контент. Тег <meta charset="utf-8"> гарантирует корректное отображение специальных символов, таких как кавычки, эмодзи и нелатинские символы. Наконец, <meta name="viewport"> необходим для адаптивного дизайна, предотвращая крошечный текст на мобильных устройствах.

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

• Обсуждение затронуло тему минимализма в веб-разработке: отсутствие бандлов, использование Lit Elements без TypeScript и отсутствие сборщиков.
• Участники обсуждали, что HTML5 позволяет опускать закрывающие теги и некоторые атрибуты, что может влиять на читаемость кода.
• Были упомянуты такие практики, как неиспользование сборщиков и бандлов, что может быть связано с философией "no-build".
• Обсуждались также такие темы, как использование сторонних библиотек и фреймворков вместо "ванильного" JavaScript и CSS, и как это влияет на производительность и размер страницы.
• Участники также затронули тему "легковесных" решений и их влияние на производительность и удобство использования.

ShadCN Themes — это платформа для создания и обмена красивыми темами для библиотеки shadcn/ui. Инструмент предлагает интуитивный редактор тем, позволяющий пользователям строить идеальные цветовые палитры и делиться ими с сообществом. Пользователи могут фильтровать темы по цветовой гамме, включая красный, оранжевый, желтый, зеленый, бирюзовый, синий, фиолетовый, розовый, серый, черный и белый, что обеспечивает широкий выбор для любого дизайна.

Проект с открытым исходным кодом доступен на GitHub, что позволяет разработчикам вносить свой вклад и расширять функциональность. ShadCN Themes упрощает процесс кастомизации интерфейсов, делая его доступным как для новичков, так и для опытных дизайнеров. Платформа стремится создать сообщество вокруг создания и обмена темами, повышая гибкость и персонализацию в экосистеме shadcn/ui.

• Пользователи жалуются на невозможность открыть ссылки в новой вкладке из-за использования <button> вместо <a>, что ломает стандартное поведение браузера.
• Поднята тема о том, что shadcn/ui — это просто копипаста компонентов, которые не предоставляют никакой гибкости для кастомизации, в отличии от TweakCN, который предоставляет полный контроль над внешним видом.
• Разработчик утверждает, что у него есть доступ к созданию и редактированию тем без регистрации, но пользователи отмечают, что это не так.
• Пользователи также жалуются на то, что невозможно дойти до футера из-за бесконечного скролла.
• Разработчик утверждает, что его инструмент предоставляет большее удобство в использовании, но пользователи отмечают, что TweakCN предоставляет более продвинутый интерфейс для редактирования тем.

Предоставленный текст содержит только навигационную структуру сайта MDN, но не основное содержание статьи о методе setHTML(). В тексте отсутствует описание самого API, его синтаксиса, параметров, примеров использования и совместимости с браузерами. Для создания точного пересказа требуется полное содержание статьи, описывающее новый метод DOM API, который, вероятно, предоставляет альтернативу innerHTML с дополнительными возможностями или улучшенной безопасностью. Без доступа к фактическому описанию метода невозможно предоставить содержательный пересказ его функциональности и применения.

• Впервые за 25 лет в Firefox Nightly появилась возможность безопасно вставлять HTML через Element.setHTML(), что вызвало обсуждение: спор о том, почему так долго не хватало базовой возможности, и о том, что API-шный дизайн (включая именование setHTML/setHTMLUnsafe) не идеален.
• Участники обсуждения отметили, что новое API встроенной санитизации встроенной в браузер — это фактически встроенный DOMPurify, и что спор в основном ведется о том, что «безопасность по умолчанию» должна быть выбрана как поведение по умолчанию.
• Некоторые комментаторы выразили обеспокоенность тем, что спецификация пока не различает между контентом и вставляемым через setHTML() и innerHTML, и что это может влиять на производительность, если разработчики начнутт читать спецификацию как «естественное продолжение» innerHTML.
• Были также затронуты темы о том, что встроенная санитизация может влиять на разработчиков, которые полагаются на встроенную санитизацию, и о том, что это может влиять на разработчиков, которые полагаются на встроенную санитизацию.

Asciinema — платформа для записи и обмена терминальными сессиями, позволяющая пользователям сохранять командную работу в различных форматах. На представленном примере запись "untitled" от пользователя crc набрала 3676 просмотров и доступна для скачивания в оригинальном формате .cast, текстовом варианте .txt или в виде анимированного GIF. Платформа поддерживает воспроизведение в терминале с помощью asciinema play и встраивание на веб-сайты через специальный плеер.

Пользователи могут делиться записями с параметрами запуска (например, указывать время начала воспроизведения через ?t=30), встраивать скриншоты в README проектов и конвертировать терминальные сессии в GIF с помощью утилиты agg. Asciinema также предоставляет CLI-инструменты для локального воспроизведения записей и предлагает варианты встраивания для различных платформ, включая HTML и Markdown.

• Обсуждение охватывает от Open Firmware и Forth до внутреннего конфликта имени ILO/ILO и влияния на OLPC, а также затрагивает вопросы эстетики и практичности в контексте встроенного ПО и влияния на разработчиков.
• Участники обсуждают, что такое "открытая прошивка" и как она влияет на разработчиков и пользователей, а также затрагивает вопросы лицензирования и патентов.
• Обсуждение также затрагивает вопросы влияния на OLPC и другие проекты, а также затрагивает вопросы влияния на пользователей и разработчиков.
• Участники также обсуждают, как влияет выбор инструментов на разработчиков и их продуктивность, а также затрагивает вопросы влияния на пользователей.

Ollama выпустила новые мощные модели для генерации и анализа кода, а также обновила интеграции с популярными средами разработки. GLM-4.6 и Qwen3-Coder-480B теперь доступны как в облаке, так и локально, поддерживая до 300 ГБ видеопамяти. Эти модели могут использоваться напрямую через API Ollama, а также интегрированы с VS Code, Zed и Droid через простые настройки в интерфейсе. Например, для VS Code достаточно указать модель в настройках Copilot, а для Droid — через конфигурационный файл. Новые модели особенно эффективны для генерации и рефакторинга кода, включая создание полных приложений по текстовому описанию. Пример: GLM-4.6 смог создать игру типа "Dino" в одном HTML-файле по текстовому запросу.

• Пользователи обсуждают использование модели GLM-4.6, её доступность и стоимость, включая обсуждение её использования через различные сервисы и API.
• Обсуждается использование локальных моделей, включая проблемы с производительностью и ограничениями на оборудовании.
• Участники обсуждают использование Ollama и их моделей, включая обсуждение их доступности и стоимости.
• Обсуждается использование различных моделей для кодирования, включая их сравнение и стоимость.
• Обсуждается использование и стоимость различных облачных и локальных решений, включая их сравнение и стоимость.

HTML-тег <output> почти не используют, но он решает две задачи: делает результат вычислений доступным для скринридеров и избавляет от необходимости вручную подключать ARIA live-регионы. Пример: калькулятор, слайдеры, индикаторы сложности пароля. Тег работает без JavaScript и ARIA-атрибутов, поддерживается всеми браузерами и скринридерами.

• <output> оказался почти неиспользуемым тегом, и его поддержка в браузерах и скринридерах фрагментарна, что делает его практически бесполезным.
• Попытки использовать <output> для отображения результатов вычислений сталкиваются с тем, что большинство фронтенд-разработчиков не знают о существовании тега, а спецификация вводит в заблуждение, что тег сам обновляет свое содержимое.
• Практика показывает, что вместо <output> используются другие теги, и это вызывает вопрос, почему вообще нужен этот тег, если он не работает как задумано.
• Поднимается вопрос о том, что если тег не работает как задумано, то возможно стоит пересмотреть спецификацию или полностью отказаться от тега в пользу более надежных решений.

Datastar — это «гипермедийный» фреймворк, который позволяет строить реактивные веб-приложения без JavaScript-кода. Он использует HTML-атрибуты и SSE-потоки для связи с сервером, а не JSON-API. Библиотека весит всего 10,75 КиБ и не требует сборки, что делает её идеальной для быстрого прототипирования. Примеры включают в себя чат-приложение, доска Kanban и т.д.

• Datastar и его автор Делани Гиллиан продвигают идею минималистичного подхода к веб-разработке, но критики указывают на то, что это может быть маркетинговым ходом, поскольку Pro-версия платная, а также что фреймворк может быть переоценённым решением, которое не решает фундаментальные проблемы веб-разработки.
• Обсуждение выявило, что Datastar не предоставляет никаких новых решений для проблем, с которыми сталкиваются разработчики, и вместо этого фокусируется на уже известных проблемах, таких как сложность, с которой сталкиваются разработчики, и не предлагает никаких новых решений.
• Участники обсуждения также подняли вопрос о том, что Datastar может быть не более чем просто ещё одним инструментом в арсенале веб-разработчика, и что его ценность может быть переоценена, в то время как другие инструменты, такие как HTMX и Alpine.js, могут предложить схожий функционал без необходимости платить за Pro-версию.
• Некоторые участники обсуждения также выразили обеспокоенность тем, что Datastar может быть не более чем попыткой монетизировать open-source проект, и что это может быть неэтичным, особенно если это не делает ясным, какие именно функции являются Pro-версией эксклюзивными.
• В конце концов, обсуждение подошло к выводу, что хотя Datastar и может быть полезным инструментом в определённых контекстах, его ценность может быть переоценена, и что его подход может не подходить для всех.

Разработчики выпустили PyTauri — это привязка Python к фреймворку Tauri, который позволяет создавать настольные приложения с помощью веб-технологий. Теперь разработчики могут использовать Python для создания приложений, которые компилируются в нативные исполняемые файлы, сохраняя при этом все преимущества веб-разработки, такие как HTML, CSS и JavaScript. Это открывает возможности для создания кроссплатформенных приложений с меньшим весом и более высокой производительностью по сравнению с традиционными Electron-приложениями. Проект примечателен тем, что объединяет простоту Python с мощью современных веб-технологий.

• Обсуждение показало, что Tauri не является просто обёрткой над системным WebView, а скорее фреймворком, который может использовать различные движки, включая экспериментальный Servo.
• Участники обсудили, что Tauri позволяет использовать веб-технологии для создания десктоп-приложений, но при этом не требует включения полной копии Chromium в каждом приложении, как это делает Electron.
• Были упомянуты преимущества Tauri в контексте лицензий Qt и сложности использования Qt, а также вопросы производительности и размера дистрибутива.
• Участники также обсудили, что Tauri позволяет использовать Python в качестве бэкенда, что может быть полезно для веб-разработчиков, желающих использовать веб-технологии для создания десктоп-приложений.

Минимальный CSS для приятного сайта включает базовые стили, улучшающие типографику и читаемость. Начните с ограничения ширины медиа-контента: img, svg, video { max-width: 100%; display: block; } предотвращает переполнение. Для типографики используйте system-ui как безопасный шрифт, увеличьте размер до 1.25rem и установите line-height в 1.5 для лучшей читаемости.

Добавьте поддержку тёмной темы через html { color-scheme: light dark; }, но учтите, что пользователям может потребоваться ручное переключение. Ограничьте ширину основного контента с помощью main { max-width: min(70ch, 100% - 4rem); margin-inline: auto; } для оптимальной длины строки в 45–90 символов. Этот подход избегает избыточного кода и обеспечивает адаптивность.

• Обсуждаются минималистичные подходы к CSS, включая сброс стилей, базовые настройки для типографики и ограничения ширины контента для улучшения читаемости.
• Поднимается вопрос о реализации темной темы, важности ручного переключения пользователем и проблемах с "миганием" при загрузке.
• Критикуются стандартные системные шрифты и обсуждаются потенциальные проблемы с их отображением в разных ОС и локалях.
• Упоминаются различные инструменты и философии (например, SSG, Tailwind, Every-Layout) для создания простых и эффективных сайтов.
• Высказывается мнение, что пользователь должен иметь максимальный контроль над стилизацией контента, а не сайт.

Онлайн-инструмент для рисования ASCII-арта с настраиваемыми кистями разных размеров (1×1, 2×2, 3×3) и возможностью выбора символов из Unicode, включая спецсимволы вроде ✦ или █. Есть ластик, очистка всего холста, настройка размеров сетки (столбцы и строки), а также функции копирования и экспорта в текстовый файл.

Работает в реальном времени с индикацией текущих параметров (например, 90×40, кисть 2px). Автор отмечает, что не все Unicode-символы отображаются корректно из-за ограничений шрифтов, и призывает дать обратную связь через соцсети.

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

Технологии с «шероховатостями» — признак долговечности, а не недостаток. Например, SQLite имеет гибкую типизацию и отключённые по умолчанию внешние ключи, но эти особенности — результат многолетней обратной совместимости, которую ценят в production. Автор предлагает выбирать инструменты, которые сохраняют работоспособность кода десятилетиями, даже если сегодня их поведение кажется неидеальным.

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

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

Репозиторий содержит минимальный набор файлов и конфигураций для создания прогрессивного веб-приложения (PWA). Включает базовый HTML, манифест и сервис-воркер, необходимые для установки приложения на устройство и работы в офлайн-режиме. Это позволяет разработчикам быстро начать работу с PWA, не тратя время на настройку.

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

• Обсуждаются технические возможности и ограничения Progressive Web Apps (PWA) на iOS, включая сложности с установкой и кэшированием.
• Участники делятся минималистичными примерами и подходами к созданию PWA, в том числе с использованием одного HTML-файла и динамической генерацией манифеста.
• Поднимаются вопросы долгосрочной жизнеспособности PWAs как метода распространения приложений в обход официальных правил Apple.
• Приводятся практические советы по отладке (очистка кэша) и решению проблем, например, "cache busting" и версионирование кэша.
• Обсуждается нестандартный характер некоторых API, представленных на ресурсах о возможностях PWA, и их непринятие основными браузерами.

Это браузерная игра «Змейка», которая использует URL-страницы в качестве игрового поля. Управление осуществляется стрелками или клавишами WASD, а змейка перемещается прямо в адресной строке. Если URL отображается некорректно, есть кнопка для исправления отображения.

Игра сохраняет рекорд игрока в очках и позволяет делиться результатом. Создана разработчиком под ником @epidemian, исходный код открыт на GitHub. Проект демонстрирует креативный подход к использованию стандартных элементов браузера для создания игрового процесса.

• Пользователи восхищены креативностью и нестандартным подходом к реализации игры "Змейка" в адресной строке браузера с использованием символов Unicode (Braille).
• Обсуждаются технические аспекты и проблемы: некорректное отображение пробелов в некоторых браузерах, предложения по улучшению (использование других символов, зацикливание границ), ограниченная работа на мобильных устройствах.
• Предупреждения о возможных проблемах с историей браузера и рекомендации использовать режим инкогнито.
• Упоминаются похожие проекты: игры в favicon (2048, другая версия "Змейки"), а также шуточные предложения портировать Doom.
• Автор проекта (@epidemian) отмечает, что игра создана 10 лет назад и может некорректно работать в современных браузерах.

Сервис позволяет создавать RSS-ленты из любого сайта, указывая CSS-селекторы для заголовков, описаний и ссылок. Пользователь вводит URL, задаёт название фида и выбирает элементы для парсинга — например, самые читаемые статьи Washington Post или джазовые обзоры на Bandcamp.

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

• Обсуждаются различные инструменты и подходы для создания RSS-лент из веб-страниц, включая самописные скрипты, готовые решения и использование XSLT.
• Поднимаются вопросы о весе зависимостей (например, Django), производительности и возможности бесплатного хостинга на платформах вроде Cloudflare Workers.
• Участники делятся альтернативами, такими как RSS-Bridge, FreshRSS и инструменты для парсинга HTML с помощью CSS-селекторов.
• Обсуждаются технические детали RSS/Atom, такие как необходимость GUID и дат для совместимости с читалками.
• Отмечаются проблемы с надежностью подобных инструментов на современном вебе, включая некорректную работу режима чтения в браузерах.

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

Я перестроил CSS вокруг трёх слоёв: base, components и utilities. Всё в base уже было на селекторах тегов, поэтому задача свелась к пересмотру компонентов и удалению утилит. Сначала я усилил использование семантических элементов и контекстных стилей, но зашёл слишком далеко, создавая сложные селекторные паттерны.

Решение пришло через кастомные теги и атрибуты по образцу веб-компонентов, но без JavaScript. Например:

note-pad {
  padding-block: var(--size-lg);
  border-block-end: var(--border-default);
}

А кастомные атрибуты заменили модификаторы в стиле BEM:

random-pattern {
  & [shape-type="1"] {
    border: 0.1rem solid var(--color-sheet);
  }
}

Плюсы: сократил CSS до ~5КБ, улучшил доступность и чистоту разметки. Минусы: подход требует большего планирования и не подходит для крупных проектов с разноуровневой командой.

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

• Автор сайта утверждает, что добился минималистичного дизайна почти без использования CSS-классов, полагаясь на семантическую структуру HTML.
• Многие участники дискуссии указывают, что сайт на самом деле содержит множество классов (175+), что противоречит заявлению автора.
• Подход семантической вёрстки (без лишних классов) хвалят за чистоту кода и хорошую доступность, но критикуют за жёсткую привязку стилей к структуре HTML, что усложняет поддержку и изменения.
• Отмечается, что такой подход хорошо работает для статических документов (например, блогов), но не подходит для сложных и динамических веб-приложений.
• В качестве альтернатив упоминаются методологии вроде BEM, фреймворки типа Tailwind CSS и использование современных возможностей CSS (:has, @scope, @layer).
• Часть участников считает, что полный отказ от классов — это скорее эстетическое упражнение, а не практичный паттерн для реальных проектов.
• Общий вывод: важен баланс — использовать семантические элементы по умолчанию, но добавлять классы там, где это необходимо для гибкости.

Как самостоятельно разместить веб-шрифт с Google Fonts

Обычно веб-шрифты берут с Google Fonts. Не вставляйте готовый код оттуда — скачайте файлы шрифтов и разместите их на своём сервере.

ВАЖНО: Это не юридическая консультация. Я не ваш юрист.

Шаги:

-1. Убедитесь, что использование шрифта соответствует лицензии. 0. Скачайте шрифт:

• Найдите нужный шрифт на Google Fonts.
• Нажмите «Get font» → «Get embed code» (не копируйте код).
• Выберите нужные настройки.
• Скопируйте URL из атрибута href в предоставленном HTML (например, https://fonts.googleapis.com/css2?family=Fira+Code&display=swap).
• Скачайте этот CSS-файл и все файлы шрифтов, на которые он ссылается.
• Поместите файлы в папку с версией (например, /Assets/Fira/Code/2025-8-13/).
• Измените CSS: замените абсолютные ссылки на относительные (например, src: url(uU9eCBsR6Z2vfE9aq3bL0fxyUs4tcw4W_D1sJVD7Ng.woff2) format('woff2');).

1. Добавьте лицензию: Найдите лицензию шрифта через Google Fonts (раздел «License») и сохраните её в файле.
2. Добавьте HTML:

   <link href="/Assets/Fonts/Fira/Code/2025-8-13/fira-code.css" rel="preload">
   <link href="/Assets/Fonts/Fira/Code/2025-8-13/fira-code.css" rel="stylesheet">
   

3. Добавьте CSS:

   code {
       font-family: "Fira Code", monospace;
       font-optical-sizing: auto;
       font-weight: 400;
       font-style: normal;
   }
   

4. Укажите ссылку на лицензию и соблюдайте её условия.

Пример реализации можно посмотреть здесь.

---

Atom Feed
Контакты: velocifyer@veloicfyer.com (поменяйте местами «i» и «C» в домене).
Лицензия: CC-BY-SA 4.0, кроме favicon, JavaScript и шрифтов.
Исходный код блога на Codeberg.

• Представлен инструмент для подмножества и самостоятельного хостинга веб-шрифтов из каталога Google Fonts с целью уменьшения их размера.
• Обсуждаются потенциальные проблемы конфиденциальности при использовании Google Fonts API, хотя официально Google заявляет об отсутствии сбора данных и cookies.
• Рассматривается дилемма выбора между хостингом шрифтов на собственном сервере (риск полного отказа) и использованием Google CDN (риск недоступности или блокировки).
• Упомянуты альтернативные инструменты и ресурсы для скачивания и самостоятельного хостинга шрифтов, включая Google Webfonts Helper, FontSource и GitHub-репозитории.
• Подчёркиваются технические преимущества самостоятельного хостинга: контроль, отсутствие лишних запросов к Google, возможность субсеттинга и base64-кодирования для уменьшения FOUC.
• Отмечается, что Google динамически подбирает формат и версию шрифта под User Agent, что усложняет точное копирование их метода раздачи.
• Часть пользователей считает самостоятельный хостинг излишним, учитывая надёжность Google CDN и сложность воссоздания его оптимизаций.
• Некоторые участники выражают удивление, что тема стала популярной, так как самостоятельный хостинг шрифтов является давно известной и простой практикой.
• Обсуждается, что использование переменных шрифтов (variable fonts) и современных CSS-практик может быть более эффективным, чем методы, описанные в статье.

• Реклама в интернете — зло: тратит время и уродует сайты.
• Поддержи автора напрямую: 1 $ приносит больше пользы, чем тысячи показов баннеров.
• На сайте выводится тонкое сообщение: «Adblock не обнаружен. Поставь uBlock Origin — сэкономишь трафик и нервы».
• Блок скрывается кнопкой «Закрыть» и больше не появляется (cookie notice-shown).
• Техника:
  – в HTML встроен <div> с «адоподобными» классами и скрипт nativeads.js;
  – если div вырезан или скрипт заблокирован, сообщение не видно;
  – стили показывают блок только при ≥75 em ширины и ≥30 em высоты;
  – без JS сообщение не вставляется, без CSS просто не стилизуется.
• DNS-блокировку не отследить, поэтому банер маленький и некликабелен вне основного контента.

• Без блокировщиков рекламы веб выглядит как «лабиринт трекеров и баннеров»: большинство пользователей живут в этом каждый день.
• uBlock Origin называют едва ли не «лучшим антивирусом»; ФБР и CERN рекомендуют блокировщики как защиту от скама и малвари.
• Даже с адблоком сайты всё чаще «раскрывают» посетителей через identity-graph (IP, хэши устройств) и потом спамят e-mail.
• Часть участников считает блокировку «паразитизмом»: контент бесплатен только потому, что кто-то смотрит рекламу.
• Другие возражают: договор «контент ↔ реклама» давно нарушен — автозвук, трекинг, монополии Google/Meta, потребление трафика и батареи.
• Альтернатива — платить авторам напрямую, но пожертвования от 0,01 % читателей не покрывают хостинг, уж не говоря о зарплате.

Pico CSS — микро-фреймворк, который делает красивый интерфейс из обычного HTML без классов.
Подключил — и готово: адаптив, тёмная/светлая тема, 0 JS, 15 КБ.

<form><input type=email placeholder=Email></form>

• 130 CSS-переменных для настройки
• 20 цветовых тем, 30 компонентов
• Вес ≈ 10 КБ, без зависимостей

• Pico CSS — фаворит для быстрых сайтов и прототипов: «включаешь — и красиво», без классов.
• Пользователи хвалят тёмную тему, accessibility и переменные, но жалуются на 50+ КБ, «огромные» контролы и отсутствие компонентов (табы).
• Кто-то берёт Pico как анти-Tailwind: семантичный HTML, нет «супа классов», легко править.
• Для LLM-флоу советуют засунуть доку Pico целиком в контекст, чтобы модель не тянула Tailwind.
• Альтернативы: Neat (ещё меньше), Newcss, Beercss; обзоры на cssbed.com и dropin-minimal-css.

Семантические разрывы строк

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

Кратко:

• точка/вопрос/восклицание — обязательный разрыв
• запятая/точка с запятой/тире — желателен
• 80 символов — мягкий лимит
• не режь слова и гиперссылки

Плюсы:
автору легче мыслить, редактору — править, читатель ничего не замечает.

• «Семантические» разрывы строк (по предложению/подпредложению) делают исходник читаемым, упрощают редактирование и уменьшают шум в diff.
• Поддержка в Markdown/HTML проблематична: одиночный перевод строки превращается в пробел, что портит тире и списки; выход — U+200B или <wbr>.
• Противники считают это микро-оптимизацией, ломающей авто-перенос и затрудняющей «визуальные» разрывы в финальном тексте.
• Инструменты уже есть: плагины редакторов, git diff --color-words, sembr для автоматического расстановления.

0b5vr: 64K «живой сет» в одиночку
Японский сценер 0b5vr показал на Revision 2023 интро 0mix: 64 КБ HTML-файл, который выглядит как запись клубного live-coding-сета.

Идея
Смешал три вещи:

• техно-демки с диджейским миксом (Medium, Ion Traxx, Emix)
• live-coding: код и визуал/саунд рождаются на глазах
• 64K-интро: всё процедурно, весом до 64 КБ

Реализация
Год спустя, в одиночку:

• собственный 64K-движок на WebGL
• синтезатор и секвенсор в GLSL
• таймлайн, переходы, VJ-эффекты — всё кодом
• финальный файл — обычный index.html 64 КБ

Выводы

• Делать 64K solo «адски тяжело» — берите напарников.
• Попал в PC-demo-вместо 64K-конкурса — не обиделся, главное показать.
• В Японии растёт тренд: музыка через шейдеры, машинный лайв, генеративный VJ.

Для непрограммистов
«Сцена — место, где код = волшебство. Смотрите, танцуйте, не бойтесь».

• Ветка вызвала ностальгию у «старичков», вспомнивших mode13h и ранние 90-е.
• Новичкам советуют начать с Revision (Саарбрюккен, Пасха) или летней Evoke в Кёльне; есть специальные «newcomer corners».
• Сцена живёт ради «чистого» искусства без monetизации и чтобы тусоваться с единомышленниками.
• Ключевые ресурсы: pouet.net, scene.org, деморепозитории на GitHub.
• Европа (особенно Восточная и бывший СССР) остаётся географическим центром, но встречаются группы и в США, и в Новой Зеландии.

Tufte CSS — стиль для веб-статей, вдохновлённый книгами Эдварда Тафти: простота, боковые заметки, встроенная графика и продуманная типографика. Проект Дэйва Липмана, опирается на Tufte-LaTeX и R Markdown. Предложения приветствуются на GitHub.

Цель — не копировать книги в вебе, а адаптировать приёмы Тафти под экраны.

Быстрый старт

Скопируй tufte.css и папку et-book со шрифтами, добавь в <head>:

<link rel="stylesheet" href="tufte.css"/>

Основы

• Разметка: <article> → <section> → заголовки h1, h2, h3.
• Новая мысль: <span class="newthought"> + неотступный абзац.
• Цвета: фон #fffff8, текст #111111, мягкий контраст.
• Шрифт: ETBook → Palatino → Georgia; жирный и курсив — отдельные файлы.
• Ссылки: цвет текста, подчёркнуты, без hover-эффектов.

• Участники спорят о визуальном устаревании Tufte CSS: кому-то шрифт и отступы кажутся «атrocious», другие всё ещё находят стиль уместным для длинных текстов.
• Критикуют выбор почти-белого фона (#fffff8) и почти-чёрного текста (#111111): считают аргументы о «мягком контрасте» надуманными, особенно на OLED.
• Поднимают тему повторных постов: Tufte CSS регулярно появляется на HN каждые ~18 месяцев, и с каждым разом нравится меньше.
• Отмечают проблемы типографики: узкий сериф, плохой кернинг, «ужасная» open-source копия Bembo.
• Некоторые делятся опытом адаптации стиля под мобильные устройства и предлагают альтернативы вроде tint или Scribe.

• HTML: справка по элементам, глобальным атрибутам, форматам дат/времени, руководства по адаптивным изображениям, видео и аудио.
• CSS: справка по свойствам, селекторам, @-правилам, единицам измерения; гайды по блочной модели, анимациям, Flexbox, цветам; «поваренная книга» для колонок, центрирования, карточек.
• JavaScript: справка по встроенным объектам, операторам, функциям; гайды по управлению потоком, циклам, объектам, классам.
• Web APIs: File System, Fetch, Geolocation, DOM, Push, Service Worker; гайды по Web Animations, Fetch, History, Speech API, Web Workers.
• Другие технологии: Accessibility, HTTP, URI, WebAssembly, WebDriver, WebExtensions.
• Обучение: курс «Frontend-разработчик», основы HTML, CSS, JavaScript.
• Инструменты: Playground, HTTP Observatory, генераторы теней, радиусов, границ, палитра цветов.

• Участники обсуждают, как использовать тег <template> без фреймворков: он удобен для клонирования больших фрагментов, ускоряет рендер и снижает нагрузку по сравнению с React/Vue.
• Недостаток — приходится вручную связывать данные и DOM; многие хотят единого формата «HTML+CSS+JS» для компонентов.
• Shopify, Salesforce, MedusaJS и Alpine.js уже применяют <template> в продакшене, но спецификация HTML Modules пока не завершена.

Статические сайты = машина времени
Варун написал о геймификации блогов, и я вспомнил свои «бейджики» 2021 года. Сначала подумал, что скриншотов нет, но потом понял: сайт на Eleventy статичный, поэтому достаточно git checkout нужного коммита и eleventy serve, чтобы увидеть страницу в том же виде.

В отличие от WordPress или сборок, где посты тянутся из CMS только при деплое, у меня каждый коммит — полный снепшот. Путешествие во времени занимает две команды (если только я не забыл закоммитить).

Год назад я завёл GitHub Action, который ежемесячно делает скрин главной «на всякий случай», но теперь не переживаю: история дизайна всегда под рукой в git.

Если тема близка — пишите на juhamattisantala@gmail.com, буду рад обсудить.

• Участники обсуждают, как лучше «путешествовать во времени» по старым версиям сайтов: Wayback Machine, Git-архивы, локальные бэкапы или собственные «музейные» режимы.
• Кто-то предпочитает чистый HTML/CSS без генераторов, чтобы минимизировать зависимости и упростить долгосрочное хранение.
• Поднимаются вопросы обратной совместимости JS/CSS и роли стандартов: насколько браузеры гарантируют, что сегодняшние сайты откроются через десятилетия.
• Упоминаются практические сложности: старые зависимости, версии Node, базы данных, билд-инструменты.
• Появляются идеи распределённого архивирования (плагины, GitHub Actions, клиентские кэши) и примеры «игровых» подходов к ведению блога.

Современный веб без JS
Фреймворки вроде React и NextJS часто превращают сайты в тяжёлые, медленные и ошибочные конструкции. Виной тому не столько сами фреймворки, сколько килобайты трекеров и плохой код. Тем не менее, многим проектам JavaScript вовсе не нужен — HTML и CSS способны на многое.

CSS не так плох
Негатив к CSS часто идёт от незнания основ. Его считают «карандашом для рамок», хотя это полноценный язык. Центрировать div сегодня тривиально: display: flex; justify-content: center; align-items: center;. В девтулзах есть интерактивный редактор flexbox, забыть синтаксис невозможно.

Писать стало приятно
CSS-фичи последних лет убрали боль:

• Вложенность без препроцессоров
• Кастомные элементы <cool-thing shadow>
• Логические свойства, clamp(), aspect-ratio, @container, :has() и др.

Пример старого vs нового
До:

.post > .buttons .like:hover { color: var(--like-color-hover); }

После:

.post {
  .buttons .like:hover { color: var(--like-color-hover); }
}

Итог
Я не призываю отказаться от JS полностью, но показываю, что большинство сайтов могут обойтись без него, если грамотно использовать современный CSS.

• Некоторые считают CSS «ужасным» и «загадочным», другие — наоборот, хвалят его эволюцию (nesting, flexbox, :has).
• Часть споров сводится к «CSS vs JS»: Tailwind-фанаты и «CSS-only» энтузиасты доказывают, что можно обойтись почти без скриптов.
• Поднимаются боли: каскад, специфичность, нелогичные названия свойств, отсутствие системности.
• Появляются практические советы: уже работают sibling-index(), @mixin, Web Components, а WYSIWYG-редакторы могут вернуться.
• Вопросы доступности и обучения: где взять современный учебник/справочник и как сделать компоненты доступными без JS.

• Сделал блог-фреймворк на XSLT: демо, код.
• Зачем? Для себя. После пары «вайб-промптов» понял, что 20-летний стандарт покрывает всё, что надо.
• Хочу: писать чистый HTML, без WYSIWYG и Markdown; RSS «из коробки»; единый шаблон на все посты; немного JS для картинок и тем.
• XSLT = один файл-шаблон, XML-контент. Браузер сам превращает XML в HTML. RSS тоже XML, поэтому тот же индекс используется и для ленты.
• Публикация: создал пост, добавил в index.xml, залил — всё. Без сборок и бэкенда.

• Участники вспомнили XSLT как способ превращать XML в HTML прямо в браузере, но большинство считают технологию устаревшей и медленной.
• Предложено заменить RSS на Atom из-за более чистого формата дат и лучшей поддержки.
• Некоторые используют XSLT на сервере (PHP, SaxonJS), где он работает быстро и безопасно.
• Браузеры удаляют XSLT из-за рисков безопасности и низкого спроса; IBM предложила свой JIT-движок, но его вряд ли примут.
• SEO и кэширование вызывают сомнения: динамически собранные страницы могут быть плохо проиндексированы.

Для работы приложения включите JavaScript.
Перейдите по ссылке на HTML-версию; после клика должно произойти перенаправление.

Если этого не случилось, браузер устарел или игнорирует заголовки no-cache.
Агрессивное кеширование (например, в текстовом браузере Links) может мешать.
Отключите кеш, несколько раз обновите страницу или обратитесь к разработчикам браузера.

• Архив Internet Archive (IA) временно убрал файлы ROM-хаков из-за ложных срабатываний антивирусов, а не по просьбе правообладателей.
• Куратор IA Джейсон Скотт предложил писать ему напрямую при подобных проблемах.
• Участники удивлены: IA годами хранит «чистые» нелицензионные ROM-ы без жалоб, а патчи вдруг заблокировали.
• Обсуждают, помогут ли шифрование или пароль на архивы — скорее нет, антивирусы реагируют и на защищённые zip.
• Упоминается, что RomHacking.net чуть не закрылся в 2024-м, но продолжает работать, а RomHack.ing стал его «духовным преемником».

• LIBRE — свободное пространство без границ.
• Языки: español, english.
• Символы: 🌍🌌📜🚀❤️ — путь к свободе.
• Поддержка: ko-fi.com/libreantisocial.
• Контакт: libreantisocial@gmail.com.
• © 2025 Libre

• Проект Libre — анонимная доска без лайков, подписчиков и модерации — за час превратился в «4chan без фильтров»: расизм, нацизм, порно, XSS-уязвимости и сломанные кнопки «Report».
• Участники сходятся: радикальная анонимность без последствий и инструментов модерации неминуемо приводит к захвату платформы троллями и психопатами.
• Некоторые находят эксперимент интересным как напоминание о «раннем интернете», но большинство предрекает итог «вот почему у нас нет хороших вещей».
• Критикуют и техническую реализацию: отсутствие санитизации HTML, поломка при выключенном JS, пустые ToS и неработающие импорты ID.

Репозиторий Evidlo/xsl-website
Публичный пример генерации сайта средствами XSLT: XML-документ преобразуется в полноценную HTML-страницу без серверной логики.

Ключевые файлы

• index.xml – исходные данные
• index.xsl – таблица стилей
• README.md – краткое руководство

Запуск

1. Откройте index.xml в браузере или
2. Примените XSLT-процессор: xsltproc index.xsl index.xml > index.html

Репозиторий демонстрирует, как обойтись без движков шаблонов, используя лишь стандартные XML-технологии.

• Обсуждение началось с демонстрации, как SGML/XML-entity можно использовать для «без-JS» сборки страниц, но напомнили, что браузеры никогда не реализовали полноценный SGML-парсер.
• Участники сравнили XSLT и CSS: CSS может вставлять контент, но лишь декоративно, тогда как XSLT позволяет полноценные преобразования, однако Google просит удалить XSLT из стандарта и уже прячет его за флагом в Chrome.
• Всплыли воспоминания о 2000-х, когда XML/XSLT активно применялись для документации, e-learning и CMS (Symphony), но сложность и отсутствие поддержки со стороны браузеров постепенно вытеснили технологию.
• Предложили альтернативы: серверная трансформация (PHP, CI/CD) или полный отказ в пользу современных сборщиков и SSR-фреймворков.

Кратко: стандартизировать в браузерах XSLT 3.0 нецелесообразно.
Технология мало используется, реализация сложна, а современные подходы (JS-шаблонизаторы, Web Components, SSR) решают те же задачи быстрее и проще.

• Пользователи мечтают о «навсегда-статическом» сайте без обновлений зависимостей; кто-то до сих пор использует PHP-include, кто-то — <template>+JS.
• Появилась фантазия «а вдруг браузеры вернут XSLT 3.0»; сторонники называют это разделением данных и представления, скептики — «громоздким XML-гипертекстом».
• Поддержка XSLT в браузерах всё ещё есть, но фактически мертва: Google убирает упоминания из спецификаций, а правительственные сайты жалуются на поломки.
• Основные претензии к XML/XSLT: чрезмерная многословность, сложность ручного редактирования, жёсткая типизация и «всегда есть пять способов записать то же самое».
• JSON и современные SSR-шаблонизаторы оказались проще и быстрее, поэтому даже ностальгирующие разработчики признают: «красивый, но неудобный» стандарт проиграл конкуренцию сетевым эффектам и эргономике.

• Удаление XSLT в браузерах разрушит работу правительственных и регуляторных сайтов по всему миру.
• Сотни порталов (Финляндия, Германия, США, Канада, Австралия и др.) используют XSLT для отображения XML-документов (законы, отчёты, статистика).
• Без XSLT эти ресурты станут недоступны для граждан, нарушатся юридические обязательства и процессы e-government.
• Предлагается сохранить поддержку XSLT как критическую инфраструктуру или предоставить механизм миграции.

• Участники спорят о предложении WHATWG исключить XSLT из HTML-спецификации: одни считают технологию мёртвой и опасной, другие — полезной для «без-JS» задач и госсайтов.
• Поднимаются вопросы безопасности (libxslt на C), обратной совместимости и «доктрины never break the web».
• Некоторые предлагают вынести XSLT в расширение или полифил, а также сравнивают судьбу XSLT с Flash, ActiveX и другими удалёнными технологиями.
• Отмечается, что процесс удаления может занять годы, а пока лишь начато обсуждение, а не принято решение.

Идея: добавить в HTML атрибут rel="share-url" для явного указания URL-адреса, предназначенного для шеринга.

Проблема:

• Сейчас браузеры и соцсети угадывают, какой URL считать «поделиться» (обычно document.location).
• Это ломается, если страница содержит параметры отслеживания или AMP-версию.

Решение:

<link rel="share-url" href="https://site.com/clean-url">

• Убирает лишние параметры.
• Позволяет указать канонический адрес.
• Работает без JavaScript.

Бонус: можно добавить title, description, image таким же способом.

• Уже с 2016 г. существует более зрелый стандарт Web Share Target, реализованный в Chromium, поэтому ShareOpenly выглядит временной мерой.
• Большинство комментаторов считают кнопки «поделиться» на сайтах избыточными: копирование ссылки проще и не отслеживает пользователя.
• Текущие кнопки нужны в первую очередь соцсетям для сбора данных, а не для удобства пользователей.
• На мобильных устройствах системная кнопка «поделиться» быстрее и единообразнее, чем разные реализации на сайтах.
• Предложенный способ описывает, как сторонний сайт может сгенерировать URL для предзаполнения формы, но не решает проблему выбора нужного сервиса.

PlutoPrint — библиотека Python для генерации PDF и изображений из HTML, работает на базе PlutoBook.
Установка: pip install plutoprint.

Основные возможности

• HTML → PDF/PNG/JPEG — одна строка кода.
• CSS/JS — полная поддержка современных стандартов.
• Шаблоны — Jinja2, Django, Flask и др.
• Пакетная обработка — асинхронный режим.
• Docker-образ для быстрого деплоя.

Быстрый старт

from plutoprint import PlutoPrint

pp = PlutoPrint()
pp.html_to_pdf("report.html", "report.pdf")

Параметры

• format: pdf, png, jpeg
• width/height, orientation, margin, header/footer, dpi

Примеры

• Отчёты, чеки, инвойсы, почтовые этикетки, скриншоты страниц.

Лицензия

MIT.

• Пользователи сравнивают PlutoPrint с WeasyPrint, Puppeteer и Typst: новый движок на C++ обещает быть быстрее и легче по памяти, но покрывает не весь CSS.
• Рекомендуют прогнать тесты с print-css.rocks и проверить прод-качество (проблемы с thead, page-break-inside и т.д.).
• Puppeteer даёт полную поддержку веб-платформы, но требует Chromium и много RAM, особенно для 200-500-страничных PDF.
• Есть вопросы по flexbox, SVG, оглавлению, поддержке Markdown и крэшу на macOS.
• Несколько человек рассматривают PlutoPrint как замену wkhtmltopdf и fpdf, автор открыт к спонсорству.

• Что изменили: из спецификации HTML полностью убраны упоминания XSLT.
• Почему: технология считается устаревшей, поддержка в браузерах минимальна, а спецификация XSLT живёт отдельно.
• Что удалили:
  • раздел «XSLT» и связанные термины;
  • алгоритм «transform-to-document»;
  • обработку type="text/xsl";
  • примеры и ссылки на XSLT.
• Как проверили: сборка без ошибок, тесты WPT не затронуты.

• Все браузеры, а не только Chrome, поддерживают идею убрать XSLT из веб-платформы.
• Основная причина — безопасность и тяжёлая поддержка устаревшей библиотеки libxslt.
• Часть пользователей возмущена: «спросили всех, все сказали “нет”, но всё равно уберут».
• Некоторые предлагают замену на WASM-полифилл или серверную трансформацию.
• Сторонники XSLT жалуются на разрыв обещания «HTML навсегда» и гибель старых сайтов.

Как я ускорил Ruby до скорости Ruby

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

Как работает компиляция

Шаблон — это Proc:

->(title:) {
  html { body { h1 title } }
}.render(title: 'Hi')

При вызове #render код превращается в:

->(buf, title) {
  buf << "<html><body><h1>"
  buf << ERB::Escape.html_escape(title.to_s)
  buf << "</h1></body></html>"
  buf
}

1. Парсинг: Sirop читает файл и строит AST через Prism.
2. Трансформация: TagTranslator заменяет CallNode на TagNode, если вызов соответствует HTML-тегу без получателя.
3. Обратный код: подкласс Sourcifier преобразует AST обратно в Ruby, подставляя строки буфера и экранирование.

Оптимизация

Jean Boussier указал узкие места и направления. В результате генерация стала заметно быстрее «чистого» Ruby.

• Автор создал альтернативу ERB, ускорил её до сопоставимой скорости, но, по мнению @swombat, выводит ошибочное заключение.
• @ciconia (автор) спорит: производительность Ruby важна, его системы выдают >1K RPS.
• @barrkel: Ruby медленнее, но быстрее Python; у каждого свои пути к скорости.
• @Alifatisk: сравнивать Ruby с Rust бессмысленно — языки для разных задач.
• Остальные комментарии свелись к старому мему «yo dawg».

Hyperclay — однофайловые HTML-приложения
Работайте как с глиной: открыли файл, изменили — изменения сохранились. Без сборки, деплоя и фреймворков.

• Прямое редактирование в браузере: меняете DOM — файл перезаписывает себя через /save.
• Полная переносимость: скачали HTML — запустили где угодно, офлайн.
• Версии: каждое сохранение фиксируется, откат в один клик.

Примеры: dev-log, writer, kanban, landing.

Почему это важно

Статические сайты удобны, но изменения исчезают после перезагрузки. Чтобы сделать цифровой объект «физическим» — нужен сервер, БД, API, аккаунты. Hyperclay убирает всё лишнее: UI, логика и данные — в одном самомодифицирующемся HTML-документе.

• Hyperclay — это NodeJS-сервер + клиентская библиотека, которая сохраняет изменения DOM прямо в исходный .html-файл, обновляя его на лету.
• Идея вызывает ассоциации с TiddlyWiki, Webstrates и даже HTA-архивами Windows 98, но делает акцент на многопользовательской работе и версионировании.
• Участники обсуждают проблемы локального file:// (CORS, модули), безопасность, ограничения iOS и то, что без сервера изменения не сохраняются.
• Некоторые делятся своими однофайловыми решениями: шифровальщик, Asteroids, «твиттер» на git-коммитах и т.д.
• Сообщество просит открытый код, нормальную документацию и понятную схему версионирования/обновления приложений.

• Markdown = лёгкая обёртка HTML, rST = промежуточное дерево документа.
• В Markdown картинка: ![alt](img.jpg) → прямое преобразование в <img>.
• В rST: .. image:: img.jpg :alt: alt → регистрируется обработчик, возвращает объект-узел, который потом рендерится нужным бэкендом.
• rST расширяем: добавил .. figure::, подключил обработчик — готово.
• Можно трансформировать дерево до вывода: перенос решений упражнений в конец книги, генерация ссылок, разные стили для HTML, PDF, EPUB.
• Пример: .. exercise:: Fizzbuzz и .. solution:: собираются в одном месте, но при сборке перемещаются в solutionlist, связываются ссылками, в EPUB открываются всплывающими сносками, в LaTeX — через answers.

• RST мощнее и расширяемее, но синтаксис вызывает отторжение и сложен для новичков.
• Markdown читается и пишется проще, поэтому стал де-факто стандартом, но не хватает возможностей для больших документов.
• MyST, Asciidoc, Djot и Typst предлагают компромисс между простотой и функциональностью, но пока уступают Markdown в распространённости инструментов.
• Парсеры RST доступны в основном на Python, а у Markdown — «каждый реализует свой диалект».
• Для книг и сложной документации RST + Sphinx выигрывают за счёт автогенерации HTML/PDF/EPUB, глоссариев и индексов.

• CSS

  • min-width: auto (по умолчанию) имеет приоритет над flex-shrink, overflow: hidden, width: 0; задайте min-width: 0.
  • Горизонталь и вертикаль различаются: width: auto растягивается, height: auto по содержимому; margin: 0 auto центрирует по горизонтали, но не по вертикали (в flex-direction: column работает).
  • BFC (display: flow-root) предотвращает схлопывание margin и «обнуление» высоты родителя с float-потомками.
  • Новый stacking context создают transform, filter, opacity, position: fixed/sticky, z-index + absolute/relative и др.; z-index действует только внутри контекста.
  • На мобильных 100vh включает скрытые панели; используйте 100dvh.
  • position: absolute ориентируется на ближайший «positioned» ancestor, а не на родителя.
  • float не работает внутри flex/grid-родителя.
  • Процентные width/height не работают, если размер родителя не задан.
  • display: inline игнорирует width, height, вертикальные margin.
  • Пробелы между inline-block элементами рендерятся; в flex/grid — нет.
  • box-sizing: content-box (по умолчанию) не включает padding/border; включите border-box.
  • Указывайте width/height у <img> для предотвращения CLS.
  • Загрузка файлов не показывается в DevTools; используйте chrome://net-export/.
  • Внутри <script> строка </script> ломает парсинг.

• Unicode

  • Отличайте code point и grapheme cluster (последнее — то, что видит пользователь).

• Маршрутизаторы могут тихо обрывать простаивающие TCP-соединения; настройте TCP-keepalive или HTTP-заголовки.
• Возвращать null из Optional<T> — антипаттерн; Kotlin и аннотации уже решают это.
• UTF-16 в Java/C#/JS — деталь реализации; в Go строки — просто байты.
• min-width: auto работает не везде; CSS-свойства нельзя читать изолированно.
• Регексы, YAML, LF/CRLF, rm -rf $DIR/ — каждый язык/платформа имеет свои подводные камни.

Чар простой текстовой страницы

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

Такой контент можно скопировать в письмо, отправить в ChatGPT, распечатать или сохранить на Kindle — он везде работает.
Ссылка открывается мгновенно без CDN и предзагрузок.
Хостинг стоит копейки, сайт живёт даже на Raspberry Pi.

Читая, легко переключаться между беглым просмотром и вдумчивым чтением, не чувствуя вины за «потерянное» время.

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

• Участники мечтают о браузере без JS, где только HTML и выбранная пользователем CSS-тема.
• Хвалят сайты вроде plaintextsports.com и berkshirehathaway.com за минимализм, читаемость и отсутствие трекеров.
• Спорят о шрифтах: кто-то любит моноширинные «под печатную машинку», кто-то просит sans-serif и контрастные цвета.
• Соглашаются, что картинки допустимы, если служат тексту, а главный враг — избыточный JS, баннеры и медленные фреймворки.
• Вспоминают лёгкие новостные «lite»-версии CNN/NPR и альтернативные протоколы вроде Gemini как примеры «текстового» интернета.

Всегда твой приятель, Мелон!
🍉

Ты покидаешь информационную магистраль!
Автовоспроизведение звука — лучше в Firefox.
Добро пожаловать в Мелонленд :^]

Музыка: johnny_ripper — by the sea ☺

• Участники делятся впечатлениями от «нео-геосити»-сайта Melonland: радуются GIF-фонам, MIDI-музыке, iframe и живому гостевику.
• Все сходятся, что сайт вызывает ностальгию по 90-2000-м: нет бесконечного скролла, работает кнопка «Назад», форум с тредом «покажи своё рабочее место».
• Кто-то воспринимает это как подлинную «старую сеть», кто-то — как стилизованную реконструкцию молодыми.
• Сайт оказался на HN благодаря алгоритмам, иронизируют пользователи, но без них такие места остаются «домиком на дереве».

Современные ИИ-чаты умеют отвечать на сложные вопросы, потому что мы так и не научились структурировать информацию. Пример: «Какое животное изображено на флаге страны, где первая британская колония появилась в год, когда Швеция объявила войну Франции?» — ChatGPT за секунды выдал «попугай сиссеро на флаге Доминики, колония 1805 г.», а Google AI-виджет провалился.

Такой «поисковый» паттерн повсюду: Google Drive — облачная папка, которую легче искать, чем упорядочивать; сайты вместо структуры набиты ключевыми словами; документацию заменяют чат-боты.

Семантический веб, где данные должны были быть машиночитаемыми и связанными, так и не случился: вместо структурированного HTML — динамические div-ы без метаданных. Личные компьютеры не стали персональными базами знаний с семантическими связями, как мечтал ХайперКард.

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

• Участники сравнивают идею «всё структурировать» с утопией «если бы все просто были хорошими людьми» – красивая теория, но нереалистична.
• Напоминают, что Semantic Web, Knowledge Graph и Cyc пытались кодировать знания вручную, но масштабировались плохо: люди не умеют быстро и точно описывать мир.
• Отмечают, что современные ИИ-модели стали «пластырем», который сам строит семантические связи из хаотичных данных, хотя и с ошибками.
• Подчёркивают: поисковики и LLM дополняют друг друга; ни один не решает всё, но вместе дают результат.
• Главный вывод: неудача не в «плохих людях», а в сложности мира и в том, что рутинная работа по разметке никому не принадлежит и никем не финансируется.

flip-card
Проект Nicholas-L-Johnson на GitHub: публичный репозиторий, демонстрирующий карточку, переворачивающуюся при наведении.

• Технологии: HTML, CSS, возможно JavaScript.
• Функция: плавный 3D-переворот с лицевой стороны на обратную.
• Применение: карточки товаров, профили, интерактивные элементы UI.

Клонировать:

git clone https://github.com/Nicholas-L-Johnson/flip-card.git

• Проект — ультратонкая электронная визитка с симуляцией жидкости; вызывает восторг, но кажется дорогой для раздачи.
• Ключевые плюсы: реалистичное движение «воды», простая и дешевая конструкция, легко отлаживать.
• Минусы: можно намочить одежду, толщина USB-C + ПКБ выглядит «толстой» для визитки, шрифт на обороте раздражает многих.
• Отмечены изюминки: USB-C на краю платы без дополнительных деталей, прошивка на Rust с плавающей точкой, аккумулятор почти кредитной толщины.
• Люди хотят больше деталей о сборке, просят sans-serif шрифт и чуть более игривый дизайн.

Я листал соцсети и наткнулся на toot Энди P с трюком:

width: calc(infinity * 1px); height: calc(infinity * 1px);

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

Сделал див с width/height: calc(infinity * 1px), обнулил отступы, проверил в Safari, Chrome и Firefox (Nightly) на macOS — и началось странное.

• Safari: около 33,554,428 px по ширине/высоте
• Chrome: около 33,554,400 px
• Firefox: высота схлопывается до межстрочного (например, 19.2 px при normal, 16 px при line-height: 1), ширина — вычислено ~17,895,700, но в раскладке ~8,947,840 (ровно половина минус 10)

Safari/Chrome почти упираются в 2^25 - 1 (33,554,431), но чуть ниже. Почему именно так — загадка. Firefox же ведет себя особенно: высота с “бесконечностью” игнорируется и падает к строке, ширина делится пополам в layout.

Дальше я попробовал font-size: calc(infinity * 1px):

• Safari: 100,000 px
• Chrome: 10,000 px
• Firefox: вычислено 3.40282e38 (макс для 32-бит float), но в раскладке шрифт ~2,400 px при normal; при line-height: 1 высота блока вдруг раздувается до ~8.9 млн. То же при переносе стилей на body.

Вывод: у Safari/Chrome жесткие десятичные лимиты для font-size (100k и 10k). У Firefox — вычислительно “бесконечность” как float, но реально рендерится ограниченный размер и странная связь с line-height.

Проверил line-height: calc(infinity * 1px):

• Safari: ~33,554,428
• Chrome: ~33,554,400
• Firefox: вычислено ~17,895,700, в раскладке ~8,947,840

Итоговые наблюдения:

• Safari/Chrome для размеров элементов/line-height ограничивают около 2^25 - 1; для font-size — вручную заданные пороги (10k/100k).
• Firefox: несогласованность вычисленного и реального значения; высота может схлопываться к строке, ширины/line-height делятся пополам, сильная зависимость от line-height.

Если кто знает первопричины (история движков, типы хранилищ, квантизация, внутренние лимиты раскладки/скролла/композитинга) — расскажите в комментариях или постом с трекбеком.

• Firefox ограничивает высоту блока 17 895 697 px — это максимум для 32-битного signed-целого в единицах 1/60 px.
• Chrome/Safari держатся чуть выше, около 33 554 431 px, т.к. у WebKit/Blink единица 1/64 px и тот же 32-битный signed.
• «Бесконечные» таблицы/листы реализуются через огромный прокручиваемый div, но приходится рисовать свой скролл или канвас, когда нативный height перестаёт работать.
• CSS-значение infinity (новое 2–3 года) просто приводится к этому максимуму, а не даёт настоящую бесконечность.

Переосмысление DOM с нуля

Браузеры в странном положении: WebAssembly выстрелил, даже на сервере, а клиентская часть ощущается почти как 10 лет назад. Доступ к веб-API из WASM решают тонким JS-клеем — но зачем вообще лезть в DOM? Просто других опций нет. Пора отправить DOM и его API «на ферму», и вот почему.

Никто уже не знает браузеры целиком — и это часть проблемы.

Модель «документа»

Мало кто осознает, насколько DOM раздут. У document.body в Chrome 350+ ключей, а в document.body.style — около 660 свойств. Граница между свойствами и методами размыта, геттеры могут триггерить релэйаут, висят легаси-штучки вроде onevent. DOM толстеет; страничникам это почти не видно, а приложениям — боль.

Большинство избегают прямой работы с DOM; деклартивности мало и она несовременна. Способов сделать одно и то же много, ни один не приятен.

connectedCallback() {
  const shadow = this.attachShadow({ mode: 'closed' });
  const template = document.getElementById('hello-world').content.cloneNode(true);
  const hwMsg = `Hello ${ this.name }`;
  Array.from(template.querySelectorAll('.hw-text')).forEach(n => n.textContent = hwMsg);
  shadow.append(template);
}

Веб-компоненты пришли поздно, непопулярны: API громоздкий, Shadow DOM плодит уровни вложенности и области видимости. Главная беда — строковая наследственность SGML/XML: состояние хранить в документе плохо; React-подобные это избегают, их «XML» — лишь синтаксис.

HTML почти не менялся 10–15 лет. ARIA стала заплаткой тому, что не дала «семантика HTML». Цели так и не достигли: нет <thread> или <comment>, правила странные. WHATWG (то есть вендоры) добавляет лишь заплатки по краям; даже CSS оброс выражениями — любая шаблонка хочет стать языком программирования.

Редактируемость HTML через contentEditable — теоретически есть, практически — темная магия; у команд Docs/Notion наверняка кошмары. Догмы про «прогрессивное улучшение» и разделение разметки/стилей в мире приложений мало кто исповедует.

Сегодня приложения склеивают HTML/CSS/SVG до «достаточно красиво», ценой огромных оверхедов — это анти-UI тулкит.

Подпись: Ввод Slack

Подпись: Оффскрин-хаки для буфера обмена

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

CSS вывернут наизнанку

CSS не имеет стройной…

• Участники признают, что веб-платформа сложна и разрослась из-за обратной совместимости, множества требований и долгой эволюции; переписывание «с нуля» в реальности лишь добавляет новые слои сложности.
• Многие защищают DOM/HTML/CSS: они кроссплатформенны, поддерживают доступность, приватность, IME/спеллчек и текстовые сценарии, с которыми канвас/кастомные рендеры часто не справляются.
• Критика фокусируется на перегруженности API, «текучих» абстракциях и смешении ролей (CSS как и стиль, и лейаут), предлагаются идеи модульности API, хранение состояния в документе, и дисциплинированное использование Web Components.
• Аргумент «выбросить и заменить» упирается в стоимость миграции и необходимость покрыть весь исторический функционал; успех веба объясняют именно гибкостью, хаками, позже закреплёнными стандартами, и жёсткой обратной совместимостью.
• Проводят параллели с нативными UI-стеками: многие считают веб-технологии более удачными; обсуждают Flutter/WASM/WebGPU как путь к «приложенческому» вебу без ломания существующего.
• Идеи разделения «документы vs приложения» всплывают часто (вплоть до «DOCTYPE app»), но консенсус: нужно сосуществование обоих подходов, а не замена.
• Скепсис к «HTML на Canvas» и «перезапуску браузера» высок: полезнее усиливать существующие примитивы (дешёвый доступ WASM к DOM, лучше продуманные формы/контролы, богатые стандартные виджеты), чем плодить новые параллельные стеки.

There is a lot valid concern on accessibility and abuse this could result in, but it think it's important to see the other side of the argument.There was a really good thread on Twitter a couple of days ago:> In light of recent Figma news, lemme reiterate that of all the goods th