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 мс на обновление кадра, что приводит к просадкам фпс.
• Автор ответил, что в будущих версиях планируется добавить реки и водопады, а также улучшить производительность.

Автор обсуждает реализацию идеального хеширования для строк, где известный набор строк отображается в целые числа с отверганием остальных. Критикуется подход с использованием PEXT (из-за больших таблиц, отсутствия на ARM и медленной работы на старых x86), предлагается альтернатива из шахматного программирования — "магические битборды". Метод заключается в умножении значения на магическое число (например, 0x28400000U) и сдвиге верхних бит для получения уникальных индексов. Для строк длиной 4 символа это позволяет создать компактную таблицу с 10 записями, где проверка memcmp гарантирует отсутствие ложных срабатываний.

Для строк разной длины можно выбирать различные битовые диапазоны (16, 32 или 64 бита) или их комбинации. В удачных случаях, как с 24-символьными CSS-ключами, удается найти магическое число, дающее прямую индексацию без промежуточной таблицы. Авторы предпочитают меньшие типы данных для компактности кода и возможности перебора вместо случайного поиска. Подход эффективен для наборов в тысячи строк с допустимым временем компиляции.

• Обсуждение началось с вопроса о том, как создать идеальный хеш-функцию для известного набора ключей, и обсуждение затронуло как теоретические, так и практические аспекты, включая использование gperf и других инструментов.
• Участники обсудили, что вместо попыток создать идеальную хеш-функцию, иногда более практичным решением может быть отказ от совершенства в пользу более простого решения, особенно если набор ключей не полностью известен заранее.
• Также было отмечено, что существуют библиотеки, такие как marisa-trie и другие, которые могут быть использованы для эффективного хранения и поиска больших наборов строк, и что они могут быть использованы вместо попыток создать идеальную хеш-функцию.
• Было также упомянуто, что в некоторых случаях может быть более практично использовать простые, но менее идеальные решения, особенно если это позволяет избежать сложностей, связанных с созданием идеальной хеш-функции.
• В конце обсуждение вернулось к вопросу о том, как лучше всего подходить к проблеме создания идеальной хеш-функции для известного набора ключей, и было высказано мнение, что вместо попыток создать идеальную хеш-функцию, иногда более разумно может быть просто использовать существующие инструменты и библиотеки.

GitHub добавил встроенные CSS-функции, упрощающие стилизацию. Теперь можно писать @function square(n) { return: calc(n * n); } и использовать как width: square(10px); — это компилируется в width: 100px;. Функции поддерживают условные операторы, вроде if (condition) { … } else { … }, математические операции и даже переменные. Это похоже на препроцессинг, но встроенное в браузер. Документация уже обновлена с примерами. Пользователи в восторге, особенно от интеграции с существующими проектами, упрощающей миграцию.

• Обсуждение в основном вращается вокруг новой возможности CSS @function, где участники обсуждают её влияние на производительность, стандартизацию и будущее веб-разработки.
• Некоторые участники выражают обеспокоенность по поводу того, что CSS становится всё более сложным и мощным, что может привести к проблемам с обратной совместимостью и увеличению сложности веб-разработки.
• Обсуждается, что новые функции CSS, такие как @function, могут потенциально заменить некоторые существующие инструменты и техники, такие как препроцессоры и фреймворки.
• Участники также обсуждают, насколько необходимо иметь эту функцию в виде npm пакета, и если это будет способствовать или препятствовать распространению и использованию этой функции.

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

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

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

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

Минимальный 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-арту и существование других нишевых инструментов для работы с ним.

Функциональное программирование принесло во фронтенд мощные абстракции: React с компонентами как функциями от состояния, Redux с предсказуемыми редюсерами и TypeScript для типобезопасности. Однако эти принципы — чистота функций, неизменяемость данных и явные побочные эффекты — вступили в конфликт с природой веба, где DOM мутабелен, CSS каскадируется глобально, а пользовательские события асинхронны и хаотичны. Вместо адаптации к платформе разработчики стали строить слои абстракций, фактически объявляя войну встроенным механизмам браузера.

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

• Критика излишнего усложнения фронтенд-разработки из-за увлечения функциональным программированием и абстракциями в ущерб простоте и нативным возможностям платформы.
• Споры о читаемости и уместности использования методов массивов (map, filter, reduce) вместо классических циклов, а также о качестве кода на CSS.
• Обсуждение проблем управления состоянием и иерархией данных в UI, включая сравнение React с другими подходами и фреймворками.
• Вопросы к эволюции веб-платформы и стандартов, которые не успевают за потребностями разработчиков и популярными решениями из фреймворков.
• Замечания о качестве статьи-первоисточника: построение на спорных утверждениях (straw man) и продвижение авторской технологии (HTMLX).

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

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

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

Современные стековые наборы шрифтов используют системные шрифты, доступные в операционных системах, что обеспечивает мгновенную загрузку без скачивания файлов, отсутствие смещений макета и мерцания. Они организованы по классификации типографики, включая System UI, Transitional, Old Style, Humanist и другие, каждый с оптимизированным списком шрифтов для резервного отображения.

Например, стек System UI использует system-ui, sans-serif, а Monospace Code — ui-monospace, 'Cascadia Code', Menlo, что подходит для кода. Это решение повышает производительность веб-страниц и универсальность, так как шрифты уже установлены у пользователей.

• Использование кастомных шрифтов может привести к неожиданному рендерингу из-за настроек браузера и системных ограничений, особенно при блокировке веб-шрифтов.
• Широкие стеки шрифтов могут негативно влиять на производительность, если первый шрифт в списке не содержит нужных глифов, что особенно актуально для нелатинских шрифтов и эмодзи.
• Веб-шрифты считаются предпочтительным решением для обеспечения консистентности брендинга, а инструменты вроде screenspan.net помогают подобрать системные fallback-шрифты с похожей метрикой.
• Для внутренних дашбордов и инструментов рекомендуется использовать системные стеки (например, system-ui) для лучшей интеграции с ОС, в то время как для публичных сайтов важнее контроль над брендингом.
• На Android многие стеки шрифтов выглядят идентично из-за ограниченного набора системных шрифтов, что требует создания гибридных решений или компромиссов.

Оригинальная версия Prince of Persia была создана Джорданом Мечнером для Apple II за три года (1986–1989), но наиболее известной стала PC-версия 1990 года с улучшенной графикой и MIDI-музыкой, переоркестрованной его отцом. Именно она легла в основу большинства последующих портов благодаря превосходству языков C-семейства над устаревшим 6502.

Любопытны судьбы портов для Amiga и Macintosh: первый сделал легендарный Дэн Горлин идеально и в срок, а второй затянулся из-за постоянных адаптаций под новые модели Mac. Неофициальные порты для Commodore 64 и Plus/4 появились лишь десятилетия спустя, уже от фанатов.

• Книги Джордана Мекнера о создании игр "Karateka" и "Prince of Persia" высоко оцениваются как увлекательный личный дневник и взгляд на историю компьютерной революции.
• Обсуждается ценность свежего взгляда при тестировании и ревью кода (или любого творческого продукта), так как автор не замечает собственных допущений.
• Пользователи делятся ностальгическими воспоминаниями о своем первом опыте игры в Prince of Persia на различных платформах: DOS, Hercules, Siemens-телефоне, SNES и фанатском порте для Atari.
• Критикуется двухколоночная верстка статьи на сайте, предлагаются технические решения для улучшения читаемости (изменение CSS, режим чтения).
• Отмечаются технические детали портирования игры (поддержка Hercules, различия версий для разных платформ) и высокое качество арта и музыки в версии для SNES.

Servo, высокопроизводительный движок для встраивания веб-технологий, в августе объединил рекордные 447 пул-реквестов. Ключевые нововведения включают поддержку inline SVG-элементов, улучшающую отображение таких сайтов, как Google, где логотип реализован через SVG. Также добавлены именованные линии и области CSS Grid (пока за флагом layout_grid_enabled) и поддержка переменных шрифтов через font-variation-settings на всех основных платформах, что позволяет гибко настраивать параметры вроде толщины.

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

• Отмечается отсутствие скроллбаров в Servo как существенный недостаток пользовательского опыта.
• Выражается поддержка Servo как проекта, увеличивающего выбор браузеров и противостоящего доминированию Chrome.
• Обсуждается уход Mozilla из проекта и надежды на нового спонсора (например, Brave), а также текущее финансирование от Igalia.
• Подчёркивается, что Servo позиционируется не как будущий браузер, а как платформа для встраивания веб-технологий в приложения.
• Упоминается масштабная переработка кодовой базы Servo (движок компоновки, сетевые компоненты) и сложность полной замены Gecko.

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

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

• Рекомендация инструментов для создания палитр с учётом доступности (Color Brewer, iWantHue, Fabio Crameri's colour maps, colorcet.com, coolors.co, flatuicolors.com).
• Критика некоторых палитр за низкую контрастность и плохую различимость для людей с дальтонизмом.
• Обсуждение необходимости проверки палитр через эмуляцию различных видов цветовой слепоты (например, в инструментах разработчика Chrome).
• Упоминание конкретных стандартов и гайдлайнов по использованию цветов (IBM's Color-blind safe, SVG gradient format).
• Запросы на функциональность инструментов: вывод палитр в форматах для gnuplot, CSS и других технических нужд.

Сервис позволяет создавать 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).
• Часть участников считает, что полный отказ от классов — это скорее эстетическое упражнение, а не практичный паттерн для реальных проектов.
• Общий вывод: важен баланс — использовать семантические элементы по умолчанию, но добавлять классы там, где это необходимо для гибкости.

У 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 реальное конкурентное преимущество, и считает обвинения в антиконкурентном поведении безосновательными или преувеличенными.

Как самостоятельно разместить веб-шрифт с 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-практик может быть более эффективным, чем методы, описанные в статье.

• SVG-сайт целиком сделан в Inkscape.
• Проверяем: индексирует ли Google текст внутри SVG и переходит ли по встроенным ссылкам.
• Это ключевые вопросы для оценки возможности «чистого» SVG-сайта.
• Контакт для уточнений — в пункте «About».
• Понимаю про риск «раздутия» и частичную поддержку эффектов (Gaussian Blur требует Gecko ≥1.9 / Firefox 3+).

Искомый роботами текст: lmtbk4mh.

• SVG-веб-сайты: чёткие, масштабируемые, SEO-дружелюбные, но могут глючить в разных браузерах и медленно выделять текст.
• Плюсы: малый вес, выделяемый/индексируемый текст, стили CSS, анимации, спрайты без лишних запросов.
• Минусы: разный рендер, проблемы с доступностью и RSS, риск XSS, падение FPS при тысячах элементов.
• Инструменты: Chartist, Tumult Hype, GSAP DrawSVG, ручной код + LLM.
• Ностальгия: выглядит как Flash-сайты 2000-х, но теперь с индексируемым текстом и без плагинов.

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

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

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

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

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

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

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

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

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

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.

Как я сделал фонетическую арабскую клавиатуру

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

1. RTL: direction: rtl; — готово.
2. Скрипт: браузер сам стыкует буквы (Safari требует ZWJ).
3. Прямые пары (17 букв):
   b → ب, t → ت, s/c → س и т. д.
4. «Эмфатические» (5): произносятся в глотке, похожи на базовые, но «сильнее». Назначил заглавные:
   H → ح, S → ص, D → ض, T → ط, Z → ظ.
5. «Уникальные» (6): добавляем точки к уже назначенным.
   sh → ش (с + 3 точки), th → ث (т + 3 точки), dh → ذ (д + 1 точка), kh → خ (ḥ + 1 точка), 3 → ع, gh → غ (ع + 1 точка).

Код: две таблицы — обычная и шифт; по нажатию выбираем нужную и отдаём UTF-символ.

• Обсуждение крутится вокруг новой «арабской QWERTY»-раскладки, которая привязивает арабские буквы к латинским по принципу транслитерации (ع → e рядом с 3, ش → shift+S и т.д.).
• Пользователи сравнивают проект с уже существующими решениями: Yamli (2005), Buckwalter, SATTS, старым Windows-переводчиком и даже пиньинь-вводом для китайского.
• Главный аргумент «за» — не нужны наклейки на клавиатуре: запоминаешь английскую букву и сразу получаешь арабскую.
• Некоторые ждали именно «чат-транслит»-режима (3=ع, 7=ح, 2=ء), но авторы делают упор на полноценную клавиатуру, а не на транслитерацию текста.
• В итоге идею признают полезной для изучающих язык и для быстрого набора без смены раскладки, но отмечают, что подобные инструменты существуют уже два десятилетия.

• 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.

Проблема: 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), вызывая разговоры о «блоте» современных веб-приложений.

OKLCH — новая цветовая модель, построенная на пространстве OKLab. Она равномерна по восприятию: одинаковые шаги по Lightness, Chroma, Hue выглядят одинаково яркими и насыщенными.

• Lightness 0–1 (или 0–100 %)
• Chroma — «чистота» цвета
• Hue — тон, 0–360°

Плюсы OKLCH

• Меняя только Hue, получаем равные по яркости цвета (в HSL они «плывут»).
• Изменяя Lightness, сохраняется оттенок без сдвига в серый или фиолетовый.
• Градиенты ровные, без грязных средних точек.
• Поддерживает Display-P3 и другие широкие гамуты.

Ограничения

• Очень высокие значения Chroma могут выходить за пределы реальных экранов и обрезаться.
• Старые браузеры не понимают oklch(); используйте @supports и резервные sRGB-значения.

CSS-пример с фолбеком

:root {
  --brand: #0066ff;
}
@supports (color: oklch(0 0 0)) {
  :root { --brand: oklch(0.55 0.18 260); }
}

• OKLCH — это цветовое пространство на базе OKLab (перцептивно-равномерное), где задаются Lightness, Chroma и Hue; название — «OK, it does an ok job».
• Градиенты в OKLCH могут «ехать» по кругу hue и давать неожиданные цвета; для плавности чаще берут OKLab-интерполяцию.
• Основные плюсы: равномерная яркость, отсутствие «мутных» средних, удобные относительные цвета в CSS.
• Минусы: неинтуитивная chroma, разные максимумы в зависимости от hue/lightness, нужно учитывать гамут-ограничения.
• Полезные ресурсы: oklch.com, офлайн-пикеры, конвертеры и статья Evil Martians.

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

Почему мы играем в Metroid
Мы не используем Nintendo в качестве маркетингового трюка. Именно через игры мы научились строить Antithesis. Задаваясь вопросом «почему фаззер не может пройти Zelda», мы шаг за шагом вывели архитектуру платформы.

Красная дверь в Metroid
Автономная система Antithesis без труда проходит большую часть Metroid (1986), но застревает у красной двери. Анализ позиций Самус показывает, что исследована вся карта, кроме зоны за этой дверью.

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

• Участники вспомнили старый «лексикографический» солвер для NES-игр и обсудили, как fuzzer-компания Antithesis ищет баги в играх вроде Castlevania и Metroid.
• Отмечены проблемы с прокруткой и воспроизведением видео в Firefox (особенно в приватном режиме), которые частично решаются CSS-фиксом.
• Появилась идея использовать fuzzer для постановки новых TAS-рекордов; сама компания уже устраивает «человек против машины» на Mario 1-1.
• Несколько человек пожелали более краткого «введения для новичков» на сайте Antithesis, хотя документацию находят полезной.

CSS random()
Новая функция random(min, max, step) генерирует случайные значения без JS. Все аргументы должны быть одного типа; step опционален и округляет результат.

Пример: звёздное поле

body{background:#000}
.star{
  position:fixed;
  top:random(0%,100%);
  left:random(0%,100%);
  width:random(2px,10px,1px);
  background:#fff;
  border-radius:50%;
}

Каждый .star получает случайные координаты и размер, создавая естественное распределение.

Дополнительные эффекты
Используйте CSS-переменные и слои box-shadow для свечения, а random() для прозрачности и цвета, усиливая атмосферу.

• Предложили «старую» технику «cicada principle» с фонами-простыми числами для предсказуемой «случайности».
• Обсудили, что «настоящая» случайность в графике выглядит плохо из-за скоплений и пустот; нужны low-discrepancy последовательности.
• Подняли вопрос воспроизводимости: хотят фиксированный seed при перезагрузке, но пока в спецификации нет такого механизма.
• Появились шутки о «безопасности в CSS» и предупреждения не использовать random() для криптографии.
• Ссылка на спецификацию: CSS Values 5; работает пока только Safari.

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, автор открыт к спонсорству.

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-ускорение для кривых Безье и рендеринг шрифтов.

• Это не настоящий WYSIWYG, а прозрачное синтакс-подсветка Markdown в textarea.
• Работает через наложение прозрачной textarea на div-рендер, что даёт лёгкость и совместимость с undo/redo и мобильной клавиатурой.
• Пользователи хвалят простоту (≈45 KB, нет зависимостей), но замечают просадку FPS на телефонах, смещение каретки и невозможность вставки картинок.
• Часто предлагают завернуть решение в web-component с shadow DOM, чтобы избежать проблем CSS-наследования.
• Несколько человек поделились похожими проектами (CodeJar, rich-textarea, Milkdown) и предложили добавить авто-списки, подсветку кода в блоках и поддержку variable-width шрифтов.

• 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, только цвет фона, генерируемый сервером — это вызывает удивление и восхищение.

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 года) просто приводится к этому максимуму, а не даёт настоящую бесконечность.

Я обожаю 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-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.

Переосмысление 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, лучше продуманные формы/контролы, богатые стандартные виджеты), чем плодить новые параллельные стеки.