Hacker News Digest

Проект Interop, в котором участвуют Google, Apple, Microsoft, Mozilla, Igalia и Bocoup, за несколько лет добился почти стопроцентной поддержки ключевых веб-технологий во всех основных браузерах. Пример — CSS Subgrid: в январе 2023 года тесты проходили лишь в 12% случаев в Chrome и Edge, а к концу года — уже в 100%; Firefox вырос с 63% до 91%, Safari — с 72% до 100%. Сейчас формируется Interop 2027, и Mozilla создала систему рейтинга, где разработчики голосуют за самые желанные функции.

Среди главных кандидатов — функции в CSS: директива @function позволяет определять собственные функции с параметрами и возвращать значение через result, например для перевода полярных координат в декартовы. Уже реализовано в Chromium. Другая идея — свойство corner-shape для скошенных углов и «сквирклов», а также селектор scrollable, определяющий, прокручен ли контейнер до верха или низа, что удобно для градиентов-индикаторов прокрутки.

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

Обсуждение дополняет статью скепсисом по поводу усложнения CSS и спорами о целесообразности перехода на vanilla HTML/CSS/JS. Основные тезисы: * **Сложность технологий:** @paczki и @DimmieMan призывают вернуться к «ванильным» технологиям для уменьшения бандлов, но @flohofwoe и @thibran считают, что сложность лишь переносится в браузер и веб-технологии требуют полной замены. @shevy-java отмечает, что даже при наличии Subgrid базовые задачи остаются неоправданно сложными. * **Функции в CSS:** @kumarvvr и @astrod видят в них мощный инструмент, тогда как @alberth, @unsupp0rted и @lioeters полагают, что это излишне усложняет язык, превращая его в полноценный язык программирования. * **Стандарты и доступность:** @fodkodrasz утверждает, что стандарты фокусируются на визуальных эффектах (eyecandy), игнорируя проблемы доступности, такие как работа date picker и экранных клавиатур в touch-интерфейсах. * **Влияние AI:** @sourcecodeplz, @piro0919 и @Thanemate отмечают, что LLM снижают порог входа, позволяя генерировать стили без глубокого изучения спецификаций. Однако @markasoftware считает, что фронтенд («vibecoding») — последняя часть продукта, которую стоит доверять AI, так как визуал определяет первое впечатление о качестве. * **Технические проблемы:** @jamienk указывает на отсутствие tree shaking в CSS, из-за чего файлы стилей чрезмерно разрастаются.

ascii.rest — это коллекция анимированной ASCII-графики для веба, созданная @bas3line и доступная под лицензией MIT. Сайт предлагает более 100 анимаций, разделённых на категории: пейзажи (например, «alpine dawn» или «aurora fjord»), интерфейсные элементы (часы, прогресс-бары, спиннеры), данные (графики, тепловые карты, метры CPU), типографику (типа «typewriter», «glitch», «split-flap»), логотипы языков программирования (Python, Rust, JavaScript и др.) и дистрибутивы Linux (Arch, Debian, Alpine). Все анимации работают в браузере без JavaScript — только HTML и CSS, что делает их легковесными и быстрыми.

Особенно впечатляют детализированные сцены вроде «tunnel» — анимированный тоннель с движущимися плитками, и «tv-static» — имитация помех на старом телевизоре, переключающемся между тест-картинкой и шумом. Каждая анимация — это чистый, оптимизированный код, легко встраиваемый в сайты. Проект сочетает ностальгию по эпохе терминалов с современными веб-стандартами, предлагая эстетику, которая не требует тяжёлых библиотек. Исходники доступны на GitHub, что позволяет адаптировать или расширять анимации под свои нужды.

Обсуждение уточняет, что анимации относятся к цветному Unicode‐шейдеру, а не к классическому ASCII‐арту. Спор: некоторые считают, что использование цвета и Unicode‐символов делает их не настоящим ASCII‐артом, так как определение ограничивается простыми текстовыми символами. Большинство отмечают, что сайт поддерживает reduced motion: анимация останавливается на первом кадре для пользователей, избегающих движения. Пользователи сообщают о низкой частоте кадров на мобильных устройствах, особенно на главной странице, ухудшая восприятие. Есть запросы на визуальный редактор или генератор для создания собственных анимированных ASCII‐сцен. Предлагается принимать pull‐request‐ы для интеграции проекта Flow и других улучшений — сообщество хочет участвовать в развитии. Комментаторы согласны: интерес к ASCII‐арту связан с трендом ретро‐текстовых интерфейсов в UI‐дизайне. Спор: работа оценивается поляризованно — некоторые называют её «плохой» и «слишком минимальной», другие восхищаются эстетикой. Отмечено: в некоторых браузерах (например, Firefox Mobile) порядок анимаций перемешивается — требуется исправление.

Capsule — это инструмент, который упаковывает полноценное приложение — интерфейс, данные и логику — в один портативный файл с расширением .capsule. Он работает полностью офлайн, без облака, регистрации или подписок: всё хранится локально внутри файла, включая пользовательский интерфейс на HTML/CSS и локальную базу данных SQLite. Такой файл можно отправить как обычный документ — через WhatsApp, AirDrop или email — и при открытии на другом устройстве он мгновенно запускается с уже загруженными данными, готовый к использованию.

Формат основан на открытых веб-технологиях, что исключает привязку к конкретным вендорам и обеспечивает кроссплатформенность: один и тот же .capsule файл запускается на macOS, Windows и Linux без конвертации. Поддержка iOS и Android планируется в ближайшее время. Capsule позиционируется как бесплатное решение для создания личных инструментов — трекеров, портфолио, заметок — с полным контролем над данными и нулевой зависимостью от сети или серверов. Для работы достаточно установить хост-плеер под свою ОС, после чего любые .capsule файлы становятся исполняемыми приложениями в один клик.

Концепция Capsule решает проблему распространения интерактивных приложений с локальным состоянием без сервера, что актуально для малых групп и AI-генерации в условиях стремления к автономности и контролю над данными. Формат, объединяющий UI, логику и данные (SQLite) в одном файле, позволяет создавать «умные документы» по аналогии с Jupyter Notebook, MS Access или Lotus Notes. Подобные идеи уже реализованы в проектах uapp, Decker и sqlar. Однако решение вызывает критику: 1. **Дистрибуция и доступность**: необходимость установки проприетарного клиента усложняет запуск по сравнению с полноценными приложениями или использованием File System Access API в браузерах. Для массового принятия требуется нативная поддержка браузерами. 2. **Синхронизация и совместная работа**: отсутствие механизмов слияния изменений при редактировании разных копий файла ведет к конфликтам и потере данных. Ручная пересылка файлов менее эффективна, чем веб-хостинг. 3. **Безопасность и надежность**: закрытый формат и клиент вызывают недоверие. Для аудита необходим просмотр исходного HTML/JS и схемы SQLite перед запуском, чтобы исключить вредоносный код. Также SQLite в одном файле уязвим к повреждениям при некорректном завершении работы, что не надежнее IndexedDB. Из-за проблем с управлением, безопасностью и отсутствием прозрачности концепция плохо масштабируется на корпоративные среды.

Один HTML-файл содержит полностью интерактивный ASCII-город в киберпанк-стиле, который можно исследовать с клавиатуры. Проект создан энтузиастом под ником Grow Now! Games и использует только чистый HTML, CSS и JavaScript без внешних зависимостей или фреймворков. Город генерируется процедурно: здания, улицы, неоновые вывески и даже движущиеся поезда представлены символами ASCII, а их расположение и поведение определяются алгоритмами в скрипте. Пользователь перемещается стрелками или WASD, вид сбоку имитирует прогулку по улицам, а фоновая музыка и звуки усиливают атмосферу.

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

Обсуждение подтверждает работоспособность браузерного подхода к ASCII‐арту, но выявляет ряд ограничений: падение производительности при частой смене цветов, различие визуального качества между видео и реальным отображением, ограниченный доступ к полной версии проекта и сложность анализа кода из‐за WASM‐обфускации. Браузер предпочтительнее терминала для фикс‐ширинного ASCII‐арта благодаря точному контролю над шрифтами, пропорциями, вводом мыши и профилированием производительности. Среди методов отрисовки DOM‐текст даёт самую чистую картинку, но при частой смене цвета в каждой строке замедляется из‐за обёртывания символов в `<span>`. WebGL достигает более 1000 FPS и лучше подходит для динамических цветов. Для выбора метода рекомендуется бенчмаркинг DOM, Canvas и WebGL. Часть разработчиков считает браузер слишком тяжёлым для TUI и предпочитает терминал из‐за низкого потребления ресурсов и возможности SSH‐доступа к мощным серверам; другие рассматривают браузер как более гибкую и современную платформу. Реальное отображение в браузере нередко выглядит менее чётко, чем демонстрационное видео, что указывает на различия в рендеринге между браузерами. Для улучшения качества рекомендуется использовать блоковые символы (ASCII 219) в сочетании с половинными блоками и символами затенения (220, 223, 176–178) для дезеринга. Расширенный ASCII (символы выше 127) добавляет графических возможностей, но его поддержка зависит от шрифтов и окружения. Более продвинутая версия проекта находится за платным прототипом, а доступные ссылки ведут к старой версии, отличающейся от видео. Код проекта компилирован в WebAssembly и обфусцирован, что ограничивает прямой анализ, хотя некоторые пользователи пытаются его декомпилировать. Первая ссылка в посте ведёт к демо, вторая — к исходному коду, который может не соответствовать последним улучшениям. Движок города построен на сетке, использует лучевое трассирование каждый кадр для расчёта перспективы, глубины и коллизий и полностью реализован в одном HTML‐файле без внешних ресурсов. Проект вызывает ностальгию у любителей классических MUD и текстовых приключений, показывая, что чистый HTML способен обеспечить погружающий опыт без тяжёлых движков.

98.css — это CSS-библиотека, которая воссоздаёт визуальный стиль интерфейсов Windows 98 с точностью до деталей: выпуклые кнопки, вдавленные поля, пунктирные фокусные обводки и «выцветшие» отключённые элементы. Библиотека не содержит JavaScript — только семантический HTML и CSS, что делает её совместимой с любыми фронтенд-фреймворками. Каждый элемент, от кнопок до чекбоксов, требует корректной разметки: метки обязательны, а доступность — приоритет. Кнопки по умолчанию 75×23 пикселей, при нажатии становятся вдавленными, а фокус отмечен тонкой пунктирной линией внутри.

Поддерживаются все стандартные формы: чекбоксы с обязательными <label>, группы через класс field-row, а также стили для статусных полей и рабочих зон — status-field-border, field-border-disabled. Можно легко кастомизировать отступы и цвета, сохраняя аутентичный вид. Установка через npm или CDN: достаточно одной строки <link> для старта. Проект открыт для вкладов, MIT-лицензирован и создан как тёплый, ироничный tribute к устаревшему дизайну — с акцентом на доступность и простоту.

Пользователи обсуждают дизайн интерфейсов, сравнивая стиль Windows 98 с современными подходами, такими как flat design и избыточное белое пространство. Согласны: интерфейс должен быть интуитивным и удобным — многие считают, что современные тренды этого не обеспечивают. Спорят о плюсах и минусах выпуклых кнопок, пунктирных фокусных обводок и серых (grayed out) кнопок: последние признаны полезными в определённых случаях. Советуют сочетать современные решения с классическими элементами, адаптируя дизайн под потребности пользователя.

cssQuake — это браузерный клиент, воссоздающий оригинальную Quake с помощью чистого HTML и CSS, реализованного на PolyCSS. Игрок перемещается клавишами WASD, обзорает мир мышью, стреляет кликом, прыгает пробелом, бежит Shift, кроется Ctrl. Меню открывается стрелками, выбирается Enter, а откат происходит по Esc; в нём есть отдельные экраны для одиночной игры, мультиплеера, помощи и настройки.

Встроенный debug‑панель позволяет включать и выключать контуры, статистику, FPS, динамическое освещение, звук, частицы и даже отключать урон или движение, что даёт полный контроль над визуализацией. Меню создания комнаты отображает название, цвет, карту, лимит фрагментов и максимальное количество игроков; при попытке создать переполненную комнату появляется надпись «ROOM FULL». Панель отладки содержит несколько вкладок — Record, Capture, Visible, DOM, Enemies, Pickups, World Special Objects/items Enemies — где можно фиксировать события, захватывать скриншоты и просматривать структуру документа. Кроме того, в игре реализованы динамические эффекты освещения, настраиваемый крестик, mute‑звуки и отображение частиц, позволяющие экспериментировать с визуальными параметрами в реальном времени, а все изменения мгновенно отражаются в браузере без перезагрузки. Пользователь может также включать отображение HUD, показывать подсказки и менять масштаб интерфейса в реальном времени.

• Демонстрация CSS‑Quake впечатляет: запуск без движка, но требует JavaScript.
• Пользователи отмечают ностальгию, плавность на современных устройствах и лёгкость по сравнению с оригиналом.
• Есть проблемы: «залипание» в углах, скольжение курсора, баги с меню и падениями.
• Комментарии подчёркивают, что это не только хак, а полноценная реконструкция движка, вызывающая споры о целесообразности использования CSS.

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

Вращая Arbor, пользователь натягивает пружину, после чего она постепенно раскручивается, вращая барель и приводя в движение механическую передачу. Arbor имеет небольшую крючок, который схватывает конец пружины, позволяя передать крутящий момент без скольжения. Баррель с толстыми стенками сдерживает резкое раскручивание, а система трения фиксирует наружный конец, обеспечивая равномерный отдач и предотвращая перемотку. Благодаря этому механизму часы могут работать несколько дней без подзарядки, а интерактивная демонстрация lets you drag the device and examine each part in detail. Эти детали делают механический механизм не только надёжным, но и эстетичным, позволяя увидеть, как энергия превращается в точность времени.

• Интерактивный сайт объясняет механизмы часов простым языком и визуально, делая сложные темы доступными.
• Автор использует чистый «ванильный» HTML/CSS/JS, сайт работает даже на старых устройствах.
• Обсуждение охватывает автоматический механизм, необходимость ношения часов и их сервисные аспекты.
• Участники делятся рекомендациями по недорогим часам, сервису и вдохновением от проекта.

EPUB‑формат, как открытый стандарт, позволяет создавать электронные книги, которые корректно отображаются в большинстве приложений и устройств. Тем не менее Kobo официально отказывается принимать такие файлы в своей экосистеме и указывает на проблемы совместимости, связывая их с работой Adobe. По их версии, ошибки появляются из‑за того, как Adobe обрабатывает метаданные, реализует DRM и генерирует файлы EPUB3, а не из‑за недостатков самого стандарта. Кроме того, Kobo требует строгий XML‑манифест и определённые метаданные, которые часто нарушаются в результате автоматической конвертации Adobe.

Кроме того, аналитика показывает, что около 70 % всех жалоб о несовместимости напрямую связаны с обработкой DRM‑защищённых EPUB‑книг в Adobe Reader, тогда как открытые книги без защиты открываются без проблем на Kobo и других платформах. Компания подчёркивает, что её собственный формат основан на EPUB, но содержит дополнительные ограничения, которые облегчают контроль над контентом. Поэтому рекомендация – конвертировать книги в поддерживаемый формат или использовать альтернативные читалки, а также, при необходимости, удалять DRM‑защиту, чтобы восстановить полноценную работу EPUB‑файлов. Таким образом, проблема остаётся в реализации Adobe, а не в самом стандарте.

• Adobe RMSDK устарел, часто «падает» и не поддерживает современные CSS‑стандарты, что приводит к проблемам с валидацией EPUB.
• Kobo использует собственный движок (Kepub) для файлов с расширением .kepub.epub, но обычные .epub проходят через старый Adobe‑движок, вызывая ошибки отображения.
• Альтернативные читатели, такие как Koreader и Calibre‑конвертер, обеспечивают лучшую совместимость и поддержку современных CSS‑возможностей.
• При публикации нужно ориентироваться на «наименьший общий знаменатель» – простые стили и минимум CSS, чтобы избежать проблем с разными e‑reader‑платформами.

Penpot — открытая платформа для совместной работы над дизайном и кодом, альтернатива Figma и Sketch. Полностью веб-ориентированный инструмент на базе SVG позволяет дизайнерам и разработчикам работать в реальном времени без потери данных: прототипы генерируют точный CSS, Flexbox и Grid-код. Поддерживает импорт из Figma, Sketch, Adobe XD; self-hosted или облачная версия.

Ключевые фичи: векторный редактор с авто-layout, компоненты, состояния, инспектор кода для экспорта SVG/SVG sprites/PDF. Более 45 тыс. звёзд на GitHub, 10 тыс. форков; сообщество >100 контрибьюторов. Бесплатен для личного/коммерческого использования (EPL/MPL 2.0), фокус на доступности и privacy — без vendor lock-in.

• Смешанные отзывы о Penpot: хвалят open-source, self-hosting, низкие цены hosted-версии (дешевле Figma) и векторное редактирование.
• Основные жалобы: лаги, краши, высокое потребление памяти на больших проектах, канвасах и при навигации между страницами.
• Ожидание улучшений от нового rendering engine (open beta скоро); есть неофициальные desktop-версии и Docker-поддержка.
• Сравнение с Figma: уступает в стабильности, но привлекает свободой от proprietary облака и vendor lock-in.

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

Генератор поддерживает экспорт результатов в多种 форматы, включая CSS, высотные карты, VOX, TXT и PNG, что обеспечивает гибкость использования. Функции импорта, отмены/повтора действий, а возможность копировать код для встраивания или открывать его в Codepen упрощают интеграцию в другие проекты. Несмотря на раннюю версию (v0.0.1), Layoutit Terra уже предоставляет мощные возможности для создания детализированных CSS-ландшафтов с минимальными усилиями.

• Пользователи отмечают, что «CSS-only»-демо всё же использует JS для интерактивности, хотя рендеринг ландшафта действительно на 100 % CSS.
• Визуально демо напоминает RCT, SimCity 2000, Populous и другие изометрические «тайкун»-игры, вызывая ностальгию.
• Несколько человек сообщили о проблемах с производительностью: при включённом JS в Firefox 144 и Chrome 131 на Windows 10/11 рендеринг занимает 100-200 мс на обновление кадра, что приводит к просадкам фпс.
• Автор ответил, что в будущих версиях планируется добавить реки и водопады, а также улучшить производительность.

Минимальный 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) для создания простых и эффективных сайтов.
• Высказывается мнение, что пользователь должен иметь максимальный контроль над стилизацией контента, а не сайт.

У Apple есть приватное CSS-свойство для добавления эффектов Liquid Glass на веб-страницах. Оно называется -apple-visual-effect и позволяет использовать материалы вроде -apple-system-glass-material.

Однако это свойство не работает в обычном Safari — только внутри приложений через WKWebView с включённой приватной настройкой useSystemAppearance. Использование этой настройки приведёт к отклонению приложения в App Store.

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

• Участники обсуждают новую приватную CSS-функцию Apple (Liquid Glass), доступную только для системных приложений, что некоторые считают антиконкурентной практикой.
• Высказывается предположение, что сама Apple активно использует вебвью (WebViews) в своих приложениях (например, App Store, Настройки, Музыка), но делает это настолько незаметно, что пользователи их не распознают.
• Многие отмечают, что плохая репутация вебвью связана как раз с теми случаями, когда они реализованы плохо, в то время как хорошо интегрированные остаются незамеченными.
• Эстетическая ценность и utility-эффекта Liquid Glass оцениваются участниками неоднозначно: одни видят в нём возвращение личности системе, другие считают его бесполезным и уже устаревшим.
• Часть комментаторов сомневается, что данная функция даёт Apple реальное конкурентное преимущество, и считает обвинения в антиконкурентном поведении безосновательными или преувеличенными.

• Реклама в интернете — зло: тратит время и уродует сайты.
• Поддержи автора напрямую: 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 % читателей не покрывают хостинг, уж не говоря о зарплате.

Анимации не всегда нужны

Хорошая анимация делает интерфейс предсказуемым и живым, плохая — раздражает и снижает доверие.
Перед добавлением спроси себя: зачем она нужна?

• Объясняет (как на linear.app/ai) — ок.
• Подтверждает действие (кнопка слегка уменьшается) — ок.
• Просто «красиво» — допустимо, если пользователь видит это редко.

Частота использования
Если элемент открывают сотни раз в день (Raycast, список команд), анимации быть не должно — они только тормозят.
Клавиатурные переходы никогда не анимируются.

Скорость
Всё, что дольше 300 мс, воспринимается как лаг.
Спиннеры быстрее = кажется, что грузит быстрее.
Тултипу нужна задержка при первом появлении, но при наведении на соседние — мгновенно и без анимации.

Итог
Добавляй анимацию, если она:

1. решает задачу,
2. видна редко,
3. длится < 300 мс.
   Иначе — не добавляй.

• Большинство участников сходятся: анимация должна быть почти невидимой (<150 мс) или вовсе отключаться, иначе она превращается в тормоз.
• Главный критерий целесообразности — объясняет ли анимация изменение состояния; если пользователь ждёт её окончания, чтобы продолжить, значит, она лишняя.
• «Делайт» и «восторг» нужны в основном самим дизайнерам; обычные пользователи после третьего раза хотят выключить всё, что мешает работать.
• Частые повторяющиеся действия (разблокировка, чекаут, корпоративные формы) требуют минимума анимации; для единичных экранов-онбордингов допустима более заметная, но быстрая подсказка.
• Практически каждый советует добавлять системную настройку «отключить анимацию» и уважать prefers-reduced-motion.

Проблема: GitHub в Safari работает крайне медленно.
Описание: Страницы грузятся по 5–10 сек, анимации подвисают, прокрутка «рыхлая». В Chrome и Firefox всё нормально.

Версии:

• Safari 17.5 (macOS 14.5)
• Safari 16.6 (macOS 13.6) – та же картина

Что пробовали:

• Очистить кэш и куки
• Отключить все расширения
• Переключить DNS (Cloudflare, Google)
• Сменить сеть (домашний Wi-Fi, мобильный интернет)
• Включить/выключить «Разработка → Использовать WebKit Nightly»

Результат: ничего не помогло.

Симптомы:

• В Activity Monitor процесс «Safari Web Content» грузит CPU до 100 % при открытии любой страницы GitHub.
• В инструментах разработчика видно, что 80 % времени уходит на «Rendering».

Временное решение:

• Переключиться на Chrome/Firefox.

Просьба: Проверьте, не сломали ли вы что-то в CSS/JS для WebKit.

• GitHub стал критически медленным: Safari и Firefox тормозят даже на мощных М-системах, а большие PR (>1000 файлов) почти не открываются.
• Пользователи связывают падение производительности с переходом на React/SPA после покупки Microsoft и отказом от старого SSR.
• Предлагают мигрировать на Forgejo, Codeberg, SourceHut или возвращаться к простому HTML/CSS.
• Вопрошают, как в крупной компании могут пропустить такую регрессию и почему тесты не ловят разницу между Chrome и Safari.
• Ситуация повторяется и на других сайтах (Jira, Stripe, GCP), вызывая разговоры о «блоте» современных веб-приложений.

Репозиторий 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-фреймворков.

SVG <path>: краткий путеводитель

<path> — единственный способ рисовать сложные фигуры и кривые в SVG. Синтаксис пугает, но разобравшись, становится удобным.

Основы

• Атрибут d — последовательность команд, как «рецепт» для пера.
• Каждая команда начинается с буквы и получает координаты как аргументы.
• Предыдущая точка автоматически становится началом следующей команды.
• Используйте пробелы и запятые — читаемость важнее байтов.

Команды

• M x,y — поднять перо и переместиться в точку.
• L x,y — прямая линия до точки.
• C x1 y1, x2 y2, x y — кубическая Безье.
• Q x1 y1, x y — квадратичная Безье.
• A rx ry x-axis-rotation large-arc-flag sweep-flag x y — дуга эллипса.
• Z — замкнуть путь к начальной точке.

Относительные координаты

Буквы в нижнем регистре (m, l, c…) двигают перо относительно текущей позиции, а не от начала координат.

Цепочки кривых

Повторяйте команды, чтобы строить сложные формы без лишних M.

Анимации

Изменяя d через CSS или JS, можно плавно морфить фигуры.

Советы

• Начинайте путь всегда с M.
• Для читаемости группируйте команды построчно.
• Проверяйте результат в интерактивном редакторе.

• Участники обсуждают интуитивные способы задавать эллиптические дуги без булевых флагов, предлагая параметры вроде углов или контрольной точки.
• Хвалят интерактивный гайд по SVG-путям, его наглядность и звуковые эффекты.
• Делятся практическим опытом: динамическая генерация карт в играх, разметка сканов, чтение путей «с нуля».
• Рекомендуют инструменты для редактирования и генерации SVG: GodSVG, Boxy SVG, онлайн-редактор yqnn.
• Отмечают связь SVG с PostScript, Logo и даже коническими сечениями; обсуждают GPU-ускорение для кривых Безье и рендеринг шрифтов.

• 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 как примеры «текстового» интернета.

Горизонт в 41,60054° N, 93,60911° W

• Высота: ~300 м над уровнем моря
• Рельеф: пологие холмы, сельхозугодья, редкие деревья
• Видимость: 20–25 км, ограничена деревьями и постройками
• Точки рельефа:
  • Север: 1,5 км до реки Des Moines
  • Юго-запад: 2 км до лесополосы
• Освещение: ровное, без резких теней из-за низкого рельефа
• Цвета: зелёные поля, тёмно-серая дорога, голубое небо

• Проект показывает реальный цвет неба прямо сейчас, используя расчёты по научной статье и данные местоположения Cloudflare.
• Пользователи в восторге: «совпадает 100 %», «в точку», «прекрасный минимализм», но ночью/при облаках видно просто чёрный или тёмный фон.
• Автор Suncalc рад, что его библиотека пригодилась; другие предлагают добавить погоду, сделать обои для iOS/десктопа или встроить в smart-дэш.
• Кто-то путается, ждёт загрузки, пока не понимает, что ночь; кто-то ставит телефон к окну и зовёт жену «посмотри!».
• В коде нет JS/CSS, только цвет фона, генерируемый сервером — это вызывает удивление и восхищение.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

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

Но свои публиковать некомфортно: мои алиасы, кастомизации и решения кажутся слишком личными. Почему — точно не знаю.

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.