Google убивает открытый веб

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

Вместо этого она решила предоставить «полифил» на JavaScript, который, предположительно, можно использовать для вытеснения функциональности. Однако любопытно, что компания не планирует выпускать эту альтернативу в браузере, что позволило бы выполнить прозрачный переход вообще без обсуждения XSLT. Нет, она осознанно отказалась это делать, потребовав от всех, кто использует XSLT, заменить вызов XSLT нестандартным вызовом полифила JavaScript, который должен его заменить.

Это означает, что как минимум одно из этих утверждений истинно:

1. На самом деле, полифила недостаточно для покрытия всех сценариев использования, ранее покрывавшихся встроенной поддержкой XSLT, и поскольку его недостаточно, компания не намеревается вкладывать ресурсы в его поддержку, то есть эту задачу перекладывают на плечи веб-разработчиков (иными словами, Google убирает фичу, из-за отсутствия которой веб-разработчикам потребуется больше труда на реализацию той функциональности, которую обеспечивали браузеры).

2. Поскольку полифила достаточно для замены поддержки XSLT в браузере, политика отказа от выпуска его в качестве замены подтверждает, что проблемы безопасности в библиотеке XSLT — это простые отговорки Chrome, призванные нанести добивающий удар RSS и всем остальным форматам XML, продолжающим оставаться опорой независимого веба.

Как я уже упоминал в посте Fediverse, здесь можно провести очевидную параллель с событиями, которые уже упоминались в своей предыдущей статье: когда Mozilla поддалась давлению Google и убила RSS, вырезав из своего браузера фичи «Live Bookmarks», обосновывалось это всё техническими проблемами (как обычно, затратами на обеспечение безопасности и обслуживание, но, несмотря на все её разглагольствования о важности открытого и совместимого веба, Mozilla так и не представила никакой официальной замены этой функциональности, вынудив пользователей устанавливать различные аддоны с подобной функциональностью, ни один из которых не написан и не поддерживается Mozilla. Сравните это с интеграцией Pocket, которую она принудительно устанавливала везде, прежде чем убила в конечном итоге этот сервис.

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

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

Не подчиняйтесь

Не устанавливайте полифил. Не меняйте файлы XML так, чтобы загружать его. Вместо этого забрасывайте issue tracker компании требованиями вернуть встроенную в браузер поддержку XSLT. Создавайте отчёты о поломанной поддержке XSLT в браузерах, потому что это не проблема веб-сайтов.

Я не смирюсь. Точно так же, как я годами продолжал пользоваться MathML, SVG и SMIL (иногда даже одновременно), несмотря на намерения Google превратить их в устаревшие технологии, я продолжу пользоваться XSLT, ища новые возможности применять его. Мой сайт будет выдавать окно с предупреждением о том, что браузер пользователя может быть поломан и не способен соответствовать стандартам, как я делал это с MathML и SMIL (такие уведомления вы можете увидеть на странице, ссылку на которую я дал выше). И точно так же, как я в конечном итоге оказался прав (спустя много лет Google наконец исправила поддержку SMIL и MathML в Chrome), следует ожидать, что если мы усилим давление, то стандарты победят.

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

Отказ от использования XSLT — полностью политическое решение, хорошо вписывающееся в общую схему паразитической корпорации, убивающей фундамент собственного успеха в попытках получить над ним всё больше контроля. И то, что команда WebKit в Apple и команда Firefox в Mozilla намерены следовать по тому же разрушительному пути — это не контрапункт, а, скорее, подтверждение моего анализа, потому что ни одна из этих компаний не заинтересована в том, чтобы User Agent был чем-то большим, нежели инструментом надзорного капитализма.

(Именно поэтому Mozilla, компания, как будто испытывающая дефицит ресурсов, впустую тратит их на реализацию LLM-фич, которые никому не нужны вместо устранения старых багов. Обратите внимание, что баг связан с неправильной обработкой форматов на основе XML, например, RSS.)

Если вы хотите потратить время на борьбу со стремлением отключить XSLT в Chrome, то оптимальнее его будет тратить на изобретение более качественных способов применения XSLT и на отправку отчётов о поломанном рендеринге, если/когда компания начнёт отключать его, а не поддаваться её разрушительным требованиям.

WHATWG служит плохую службу открытому вебу

Как я уже говорил, WHATWG, даже несмотря на, вероятно, благие намерения при его создании, плохо служит открытому вебу. Это больше похоже на коррупционный захват власти, только вместо захвата W3C они просто решили перехватить инициативу и пользоваться тем, что они, как реализаторы, имеют последнее слово в том, что считается «стандартом» (де-факто, если не де-юре): это ровно такое же отношение, как когда Microsoft пыталась захватить веб при помощи Internet Explorer во времена первой войны браузеров; такое отношение вполне обоснованно осуждалось тогда.

Самое важное здесь то, что чем бы ни была (или должна была стать) WHATWG, когда её основали разработчики Opera и Mozilla, теперь она явно превратилась в корпоративного монстра. Его корпоративный управляющий видит веб совсем иначе, нежели видение веба, заложенное при его основании, продвигаемое W3C и служащее истинно открытому и независимому вебу.

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

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

Новая война браузеров?

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

Довольно иронично то, что в период, когда хостинг превратился в почти тривиальную задачу, мы будем вести бой за то, что должно происходить на стороне клиента. Но самый важный вопрос заключается в том, кто же те герои, которые выступят на нашей стороне?

Мне бы хотелось увидеть в наших рядах браузеры наподобие Vivaldi, духовного наследника моего любимого классического браузера Opera, но из-за его зависимости от движка рендеринга Blink, контролируемого Google, они не смогут сделать ничего, только уступать, как и другие FLOSS-браузеры на основе движков Google или Apple. Я предвижу, что ни один из них не будет предпринимать какие-то существенные усилия к откату обширных изменений, связанных с отказом от XSLT. (Мы уже наблюдали это, когда дело коснулось поддержки JPEG XL, но в то же время Vivaldi сделал RSS-фиды документами первого класса, так что кто знает? Возможно, они найдут способ, например, через упомянутый выше полифил или что-то подобное?)

Кто ещё может нам помочь? Существует Servo — движок рендеринга, который разрабатывался Mozilla в качестве замены Gecko и превратился в независимый проект, когда его коллектив подвергся массовому увольнению в 2020 году; но он пока не поддерживает XSLT, и я не вижу причин, по которым разработчики бы отдали приоритет ему в ущерб, например, MathML или SVG-анимациям со SMIL (снова взял два моих любимых примера), или оптимизации скорости (серьёзно, попробуйте открыть главную страницу моего сайта и поскроллить).

По сути, пока у нас остаётся лишь пара форков Firefox, и два из них (LibreWolf и WaterFox) — это «Firefox без наиболее явно нарушающих конфиденциальность фич», из-за чего остаётся открытым вопрос, на что они будут готовы, когда Mozilla помогает Google убивать XSLT. И лишь один, Pale Moon, вырос в независимый форк (так как это настолько старая версия Firefox, что она, на самом деле, не поддерживает плагины на базе WebExtensions, например, новые версии таких важных плагинов, как uBlock Origin и Privacy Badger; впрочем, можно установить поддерживаемые сообществом форки этих плагинов, предназначенные для легаси-версий Firefox и форков наподобие Pale Moon).

(Да, я знаю, что есть и другие мелкие независимые проекты браузеров наподобие Dillo и Ladybird, но первый ещё не в той форме, чтобы стать серьёзным претендентом на использование со сложными страницами (примеры тоже можете посмотреть на моём сайте), а второй находится даже не на этапе альфы; не говоря уже о его спорной стратегии «никакой политики».)

Время от времени я изучаю их (точнее, форки Firefox), чтобы проверить, достаточно ли они хороши для моего повседневного применения. Я специально только что протестировал их снова. Они пока не готовы, по крайней мере, для меня, но должен сказать, что после моего предыдущего изучения чётко видны улучшения, а ведь это было даже не так давно. Могу подтвердить, что в некоторых случаях они даже лучше Firefox: например, в Pale Moon и WaterFox есть качественная поддержка JPEG XL (в том числе поддержка прозрачности и анимации, которая ломается в LibreWolf, как и в последней проверенной мной nightly-версии Firefox), а в Pale Moon по-прежнему есть первоклассная поддержка RSS, от индикатора в адресной строке до рендеринга даже при отсутствии таблицы стилей (будь то CSS или XSLT).

(Что я могу посоветовать? Уделить больше внимания поддержке микроформатов. Например, неплохо было бы иметь вспомогательную панель с ссылками «предыдущее»/«следующее»/«наверх». Это одна из тех мелочей, благодаря которым выделялась классическая Opera. Дополнение: я только что узнал, для Pale Moon есть соответствующий аддон!)

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

И я понимаю: дизайн UI — это сложно. Я и сам плохо с ним справляюсь, поэтому не должен давать рекомендаций, но я всё равно могу увидеть разницу между проработанными интерфейсами и теми, которые требуют дополнительной работы; и даже если кто-то наподобие меня, предпочитающего функцию форме, находит эти мелочи раздражающими, то могу представить, насколько хуже они выглядят в глазах пользователей, которым больше важна вторая. К сожалению, если в новой войне браузеров мы будем бороться за контроль с захваченной корпорациями WHATWG, это важно.

В конечном итоге, я нахожусь сейчас в состоянии ожидания. Как долго понадобится Firefox, чтобы убить поддержку XSLT? Что с этим смогут сделать ближайшие к нему форки (я особо слежу за WaterFox)? Или Pale Moon останется единственным современным браузером с поддержкой XSLT, как устойчивый форк, уже давно пошедший своим путём? Станут ли они достаточно совершенными, чтобы превратиться в мои основные браузеры? Время покажет.

Новый веб?

Интернет — это не только World Wide Web, построенный на основе протокола HTTP и формата файлов HTML. До веба было уже много Интернета, и хотя основная его часть практически осталась лишь тенью прошлого, заслонённой вебом и тем, что было создано на его основе (не всё из этого было хорошим), в нём существуют и новые части, которые пытаются учиться на ошибках прошлого и создавать нечто иное.

Здесь уместно привести пример так называемого «Gemini Space» — небольшого уголка Интернета, никак не связанного с LLM, которым пытается пичкать нас всех Google; на самом деле, он появился раньше, как я уже говорил, но намеренно был создан на другой технологии, чтобы оставаться подальше от влияния Google и подобных ей.

Протокол Gemini проектировался так, чтобы концептуально быть проще, чем HTTP, обеспечивая при этом такие современные возможности, как встроенная безопасность транспортного уровня и аутентификация стороны клиента на основе сертификатов, а также собственный «нативный» формат документов, так называемый gemtext.

Я не буду подробно расписывать критику Gemini Space: можете прочитать мнение автора curl (однако стоит учесть, что с момента публикации его поста произошли существенные изменения: например, спецификация разных компонентов была разделена, как и предлагал Дэниел), и критику использования gemtext.

Не буду я и восхвалять протокол Gemini и gemtext, хоть мне и нравится идея веба, построенного на легковесных форматах разметки: было бы здорово, если бы в браузерах имелась нативная поддержка форматов наподобие Markdown или AsciiDoc (и gemtext): именно поэтому я не удаляю браузерное расширение AsciiDoctor.

Но если в целом, веб (или, по крайней мере, его пользовательские агенты) не должен разграничиваться. Он не должен разграничиваться по протоколу или формату. Такое происходило, когда исключались форматы изображений наподобие MNG на основании заявлений, которые сегодня кажутся свидетельством их идиотичности (и да, даже Pale Moon не поддерживает этот формат); сегодня подобная судьба угрожает JPEG XL, только теперь этому даже не придумывают оправданий. С другой стороны, у нас есть браузеры с полнофункциональными возможностями чтения PDF, и это хороший шаг в направлении интеграции этого формата с большим вебом.

В идеальном мире браузеры бы не отказывались от старых протоколов наподобие Gopher или FTP и просто добавляли поддержку новых наподобие Gemini, а также поддержку новых (открытых) форматов документов в процессе их появления.

(Почему важна их открытость? В ещё одной теме Fediverse об отказе от XSLT у нас с автором произошла интересная дискуссия об SWF — главном формате интерактивной мультимедиа веба начала этого века. В конечном итоге, Adobe Flash Player потерял свою популярность, вероятно, из-за появления мобильного Интернета: заявлялось, что Flash убил iPhone, и хотя письмо Стива Джобса Thoughts on Flash заслуженно подвергали критике за лицемерие, правда в том, действительно убили этот формат его проприетарность и неполная задокументированность. И хотя мы не хотим оплакивать смерть проприетарного формата, даже сегодня остаётся истинным то, что потеря даже легаси-поддержки Flash стала существенной потерей для культуры и искусства.)

Веб взаимосвязанного ПО?

Пользовательский агент не должен выбирать, доступ к каким форматам есть у пользователя и через какой протокол. Я понимаю, что существуют существенные затраты на поддержку, возрастающие с количеством форматов и протоколов, но по опыту классической Opera мы знаем, что в комплекте браузера на самом деле вполне можно выпустить весь набор Интернета.

В прошлом разработчики браузеров осознавали, что один поставщик не способен покрыть все возможности, поэтому и родились интерфейсы наподобие NPAPI. С тех пор из большинства браузеров был удалён интерфейс плагинов, тоже по инициативе Google, объявленной в 2013 году и завершённой в 2015 году, и остальные крупные браузеры вскоре последовали за ними; сегодня их поддержка осталась лишь в независимых браузерах наподобие Pale Moon.

Хоть можно и заявить, что конкретно NPAPI обладает неисправимыми проблемами безопасности и портируемости, а потому должен уйти, его удаление без чёткого кросс-браузерного пути апгрейда стала существенной потерей для эволюции веба, уничтожившей попытку решения проблемы курицы и яйца: поддержки форматов на стороне клиентов и применения форматов на стороне серверов. Кстати, это также стало причиной грубейшего промаха W3C — стандартизации DRM для веба в виде так называемых Encrypted Media Extensions, ставшей предательством собственной миссии W3C.

Роль стриминга мультимедиа в смерти пользовательского агента

Временная последовательность здесь довольно интересна: она коррелирует с уже упомянутой историей Flash и его недолго жившего конкурента Microsoft Silverlight, во многом ответственных за первоначальный стремительный рост сервисов стриминга мультимедиа в первые годы XXI века. В конфликте между стремлением Apple убить Flash и потребностями новых стриминговых сервисов наподобие Netflix и Hulu в поддержке стриминга мультимедиа в браузере возникла необходимость поддержки мультимедийных форматов в новой спецификации HTML5; в то же время MAFIAA и партнёры требовали, чтобы такая поддержка накладывала ограничения, среди прочего, не позволяющие пользователям сохранять локальную копию стрима; эту задачу проще было бы реализовать в контролируемых индустрией плеерах Flash, чем в пользовательском агенте, управляемом пользователем.

В таких условиях началось развитие EME в 2013 году: оно наконец-то позволило относительно быстро избавиться от плагина Flash, а позже — и от интерфейсов плагинов, обеспечивавших его интеграцию с браузерами. К тому времени плагин Flash был практически единственным плагином, для которого и существовал API, а сам плагин всё ещё какое-то время поддерживался браузерами после того, как поддержка API была завершена (иногда это было реализовано через альтернативные интерфейсы наподобие PPAPI, иногда — благодаря сохранению поддержки NPAPI, но только для плагина Flash).

Этот беглый взгляд на историю Flash и EME помогает выделить множество интересных аспектов.

Во-первых, это ещё один фрагмент истории, показывающий, насколько поворотным был 2013 год для ухудшения World Wide Web.

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

В-третьих, это превосходный пример того, как интерфейс плагинов помог продолжению эволюции веба.

Контролируемая эволюция

Избавление от поддержки NPAPI и последовавшее за ним несколько лет спустя избавление от интерфейса PPAPI (который должен был стать «более безопасной и портируемой» эволюцией NPAPI) без предоставления какой-либо альтернативы — явный признак того, что путь, по которому идёт разработка браузеров последний десяток лет — это путь, на котором веб полностью контролируется Google, Apple и Microsoft (смотрите-ка, снова GAFAM!), решающими, что в нём разрешено и что запрещено.

С этой точки зрения, переход от плагинов к браузерным расширениям нельзя рассматривать как вопрос безопасности и портируемости; что более важно, это ещё и вопрос урезания функциональности: на самом деле, расширения сохраняют в себе достаточно возможностей, чтобы быть вектором malware и adware, но недостаточно для обхода нежелательного поведения браузеров; особенно это актуально в контексте так называемого Extension Manifest V3, специально разработанного для борьбы с блокировкой рекламы.

При работе с плагинами в World Wide Web можно было интегрировать что угодно, и такая интеграция была бы максимально эффективной. Без плагинов такая интеграция становится неудобнее и затратнее, а иногда и вообще оказывается невозможной.

Например, существуют браузерные расширения, способные добавлять поддержку JPEG XL в браузеры, не имеющие нативной поддержки. Это позволяет обходным путём показывать такие изображения в этих браузерах, но когда сервер предлагает изображение в нескольких форматах (например, как это делаю я для обеспечения отката к PNG изображений JXL), скачиваются оба формата, и PNG, и JXL, увеличивая, а не уменьшая объём передаваемых данных (что было бы одним из преимуществ JXL относительно PNG). Плагин же мог бы регистрировать себя в качестве обработчика формата JPEG XL, а браузер мог бы делегировать рендеринг изображения плагину, откатываясь к PNG только в случае сбоя, максимизируя полезность формата и мотивируя к его встроенной реализации.

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

(На самом деле, немного удивляет отсутствие MathJax в виде браузерного расширения, за исключением пользовательского скрипта GreaseMonkey, но я думаю, что это цена, которую мы вынуждены платить за гибкость библиотеки и за требования к сэндбоксингу, накладываемые на JavaScript в современных браузерах.)

Стоит уточнить, что я не стремлюсь однозначно к возвращению NPAPI. Мы уже накопили десятки лет опыта и знаем технические проблемы этого интерфейса, способы его улучшения (которые, например, реализовал PPAPI, прежде чем Google решила, что лучше будет полностью прибить плагины, получив таким образом полный контроль над вебом, как над платформой), а также о сэндбоксинге внешнего кода, выполняемого в браузерах (в основном благодаря усилиям по сэндбоксингу JavaScript). Можно спроектировать более качественный API плагинов.

Но этого не произойдёт. Уже очевидно, что крупные браузеры явно и намеренно не хотят допускать ту степень гибкости, которую обеспечивали плагины, пряча свои попытки контроля за оправданиями. Следовательно, задача по разработке такого интерфейса (или нескольких, как минимум, одного для протоколов и одного для типов документов) ложится на менее популярные браузеры, но большинство из них привязаны к движкам рендеринга, контролируемым Google (по большей части), Apple (некоторые по-прежнему WebKit вместо Blink) и Mozilla (некоторые форки Firefox), поэтому у них очень мало свободы в том, что они теоретически могут поддерживать.

Но даже если по какому-то счастливому стечению обстоятельств они смогут договориться и реализовать поддержку такого API, появится ли у сторонних разработчиков интерес к созданию плагинов для него? Мне видится в этом способ для браузеров сообща прорабатывать поддержку новых протоколов и форматов до их нативной реализации (скажем, те же Gemini и gemtext можно было бы сначала сделать плагином для браузеров с поддержкой подобных интерфейсов). Однако есть ли в этом интерес для разработчиков? Не проще ли пытаться внедрить функцию прямо в браузеры?

Сеть из кубиков

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

Появился новый протокол?

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

Появился новый формат документов?

Реализуем плагин для его обработки, и он будет использоваться для рендеринга документов в этом новом формате.

Появился новый формат изображений?

Реализуем плагин, и все изображения в новом формате становятся видны в браузере.

Появился новый скриптовый язык?

Вы уже поняли: реализуем для него плагин…

Возможно, тогда могли бы иметь реальный шанс проявить себя многие технологии, жизнь которых была прервана не из-за технических ограничений, а из-за контроля корпораций? Кто знает, может быть, интеграция RSS и Atom по-прежнему была бы тривиальной задачей; никому не пришлось бы бороться с давними багами рендеринга PNG из Explorer, процветал бы MNG, JPEG XL начали бы использовать повсеместно спустя полгода после финализации его спецификации; HTML+SMIL обеспечивали бы возможность появления декларативных интерактивных документов без JavaScript ещё в 2008 году; XSLT 2 и 3 уже давно заменили бы XSLT 1 в качестве основных языков шаблонизации в вебе, или же XSLT вытеснил бы существенно более удобный XQuery; XHTML2 жил и развивался бы параллельно с HTML5, предоставляя более логичную разметку многих распространённых фич и долгожданные возможности наподобие включений на стороне клиента.

Веб сильно отличался бы от современного; и что самое важное, мы бы не беспокоились о том, что одна корпорация сможет диктовать нам, что разрешено и что запрещено в вебе.

Но реальность гораздо более жестока и мрачна. У Google есть контроль, и нам нужно вырвать его из рук этой компании.

Сопротивляйтесь

Поэтому не подчиняйтесь.
Сопротивляйтесь.
Распространяйте неудобные ей технологии.
Пользуйтесь RSS.
Пользуйтесь XSLT.
Применяйте JPEG XL в качестве основного формата изображений.
И в отчётах о поломавшихся недавно сайтах указывайте истинную причину: сбой браузера, а не проблему с контентом.

Постскриптум

Сюда я буду добавлять ресурсы, продвигающие XSLT.

Начну со ссылки, которую обнаружил благодаря JWZ:

1. xslt.rip (лучше заходить через браузер с поддержкой XSLT; крайне рекомендуется посмотреть исходники).

2. Rivista Journal — это «синдикатная система публикаций для XMPP»; основана на комбинации двух форматов и протоколов XML, Atom и XMPP; может представлять контент непосредственно в веб через преобразование в XSLT.

3. И, разумеется, мой собственный веб-сайт, потому что смысл в использовании XSLT заключается в создании не HTML, а SVG.

Попал в новости

• На Hacker News создали тему.

• И ещё одну на Lobste.rs.

Единственный комментарий, на который стоит ответить, принадлежит пользователю, предпочитающему EME тому хаосу плагинов, которым мы раньше пользовались. Я понимаю причины, но не согласен с сутью: DRM не должен существовать и его нельзя было стандартизировать в нарушение миссии W3C; с другой стороны, чем неудобнее он для пользователя, тем лучше он проявляет свою негативную природу.

Комментирующие ошибочно интерпретируют смысл, придавая своему личной нелюбви к XSLT больший вес, чем важной роли, которую он играет в открытом и независимом вебе. Достаточно увидеть, сколько людей следует корпоративной рекомендации применять его на стороне сервера и передавать «отрендеренный» HTML, чтобы понять, что эти люди понятия не имеют, о чём говорят: например, мои sparklines по-прежнему в десять раз меньше в виде данных XML плюс XSLT, чем отрендеренный SVG; их преимущества заключаются в амортизации при наличии на странице множества sparkline (благодаря общему XSLT) и в экономии времени (данные меняются, а XSLT нет; кроме того, реальное соотношение данных SVG к XML гораздо больше, чем десятикратное, и с увеличением объёмов данных соотношение стремится к этому). В случае мелкого, дешёвого и/или домашнего хостинга XSLT остаётся победителем с большим отрывом.

Вам не нравится его синтаксис? Это нормально. Но тратьте эту энергию критики на продвижение XQuery, а не на подкрепление позиции корпораций относительно отказа от XSLT.