Hacker News Digest

Страница XSLT.RIP объявляет о смерти технологии XSLT, обвиняя в этом Google. На минимальной веб-странице всего три строки: заголовок "Если вы это читаете, XSLT был убит Google" и два коротких соболезнования. Это мемориальная страница, созданная в знак уважения к технологии, которая, по мнению автора, прекратила свое существование из-за действий Google.

Страница оформлена в виде простого XML-документа с XSLT-стилем, что создает ироничный контент. Несмотря на скудность информации, это явный протест против прекращения поддержки XSLT, технологии, которая долгое время использовалась для преобразования XML-документов. Фраза "Rest in peace" (Вечная память) подчеркивает, что автор рассматривает это как окончательную кончину технологии, а не просто изменение в политике поддержки.

• Google не «убивает» XSLT, а лишь прекращает поддержку в браузере, что вызывает споры о том, насколько это технически оправдано.
• Сайт xslt.rip использует нарочито ретро-дизайн, чтобы подчеркнуть иронию ситуации, но это вызывает споры о том, насколько это уместно.
• Обсуждение поднимает вопрос о том, что XSLT всё ещё используется в медицинских записях и других нишах, где XML по-прежнему важен.
• Некоторые участники считают, что Google просто не хочет вкладывать ресурсы в поддержку устаревших стандартов, в то время как другие считают, что это естественный процесс устаревания технологий.

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

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

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

Я ухожу с поста сопровождающего libxml2, поэтому проект временно остаётся без поддержки.

До конца 2025 года я буду исправлять регрессии в релизе 2.15.

Спасибо за вашу тяжёлую работу!

Спасибо за долгое сопровождение libxml2!

Я изучаю код libxml2 и libxslt. У меня есть время на поддержку, но нужно разобраться с последними изменениями, например, с управлением буферами ввода-вывода. Как лучше связаться для вопросов?

Спасибо за поддержку ключевых библиотек интернета, используемых в миллионах продуктов по всему миру. Удачи!

От лица миллионов пользователей благодарю за вашу работу!

• Основной сопровождающий libxml2, Nick Wellnhofer, уходит после десяти лет неоплачиваемой работы и форкает проект под лицензией AGPL.
• Сообщество обсуждает кризис поддержки критически важной инфраструктуры из-за проблем с финансированием open-source.
• Поднимается вопрос о чрезмерной сложности XML и необходимости больших библиотек вроде libxml2; предлагаются более минималистичные альтернативы (например, TinyXML2, libexpat).
• Упоминается спорная политика безопасности libxml2 «без эмбарго», что вызывает обеспокоенность по поводу будущих уязвимостей.
• Обсуждается бизнес-модель продажи исключений из GPL для коммерческого использования как потенциальное решение для поддержки.
• Отмечается упадок XSLT из-за проблем с libxml2 и планы по удалению его поддержки из браузеров.
• Высказывается мнение, что сложные стандарты вроде XML с большими RFC являются неустойчивыми и что при выборе технологий следует учитывать простоту поддержки.

• Пакеты: libxslt, linux-c7-libxslt, linux-rl9-libxslt (версии <2)
• Суть: проект без мейнтейнера, 3 неисправленные уязвимости
• CVE-2025-7424: путаница типов xmlNode.psvi
• CVE-2025-7425: use-after-free в xmlFreeID
• CVE-2025-????: четвёртая уязвимость (18.06.25) пока не раскрыта
• Статус: патчи от Apple и Google есть, но не применены из-за отсутствия мейнтейнера

• Пользователи обсуждают, что libxslt остаётся единственной C-реализацией XSLT 1.0, на которую завязаны браузеры, GNOME-стек и множество дистрибутивов.
• Google отказалась выплачивать bug-bounty за уязвимости, сообщённые контрибьютору libxslt, а новый мейнтейнер всё ещё проходит бюрократическую проверку в GNOME.
• Появились предложения вывести XSLT из браузеров и заменить его WASM-полифиллом или переложить поддержку на Linux Foundation.
• Участники отмечают, что XSLT 1.0 имеет много реализаций (Saxon, Xalan, MSXML), но именно libxslt используется в Chrome/Blink, что создаёт монокультуру.

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

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

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

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

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

Запуск

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

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

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

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

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

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

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

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

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