Иерархический стиль

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

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

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

Чтобы еще больше усугубить положение, некоторые тексты содержат форматирование, которое существенным образом связано с их содержанием. Так, большинство юридических документов содержит несколько уровней нумерации; если стиль нумерации (сколь угодно уродливый) изменить — документ станет недействительным. Точно так же, внешнее оформление стихотворения, как правило, крайне важно для передачи правильной интонации и переплетения смыслов. Малейшее изменение расположения текста, пунктуации или словоупотребления — убьет оригинал. Даже такое, казалось бы, невинное изменение как замена длинного тире (m-dash) более короткой современной версией (n-dash) — на что многие редакторы идут совершенно не задумываясь, — может привести к нарушению потока восприятия, и в результате — изуродованное впечатление. Да, конечно, всякое форматирование допускает подвижки в определенных границах — но зона неразрушающих модификаций очень индивидуальна, и даже вариации внутри зоны отнюдь не нейтральны — они воспринимаются как различные оттенки той же базовой интонации, отражающие особенности индивидуальной мотивации [→].

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

Однако пора возвращаться с артистических высот к компьютерным технологиям. Возможно ли вообще дать автору какие-то средства влияния на возможные форматы публикации — чтобы не слишком отвлекать его от собственно содержания? Можем ли мы провести границы между форматированием и контентом достаточно гибким образом, позволяющим учесть специфические потребности конкретного текста?

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

Типичный пример — средства HTML-разработки. Компании твердят предполагаемым клиентам, что при помощи высокотехнологичного программного обеспечения они смогут построить Web-сайт с нуля, ничего не зная об HTML, CSS, JavaScript и прочих ругательных словах... Но приходилось ли вам когда-нибудь сравнивать Web-страницу, порожденную, скажем, конвертером MS Office (FrontPage), с такой же страницей, вручную размеченной на HTML? Вторая — в несколько раз компактнее, намного более удобочитаема, и у нее меньше проблем по части совместимости с самыми различными браузерами. Я не имею ничего лично против Microsoft — все остальные ничем не примечательней. Есть общая тенденция — убрать как можно больше формата в стилевые листы и скрипт, насыщая текст внешними ссылками вплоть до полной невозможности в чем-то разобраться. Такова, дескать, цена, которую приходится платить за единообразие и мощь.

А если мне вовсе не нужна вся эта заумь на моих Web-страницах? Что если меня вполне устроит простенький вариант форматирования, который наверняка будет выглядеть примерно одинаково во всех браузерах (даже без поддержки стилей), во всех операционных системах, с их неизбежным различием в наборе установленных шрифтов? Далее, мне нужен минимум гибкости, чтобы добавлять отдельные "продвинутые" элементы когда без этого просто не обойтись. Так, я хочу показывать страницу без фреймов тем, кто их не любит, — и оставить фреймы для тех, кого смущает постоянное уплывание блока навигации из визуального поля. Мне нужно уметь вставлять картинки и, возможно, иные объекты без нарушения общей структуры текста и без ущерба для его читабельности. Короче, я хочу, чтобы мои документы были просты и приспосабливались к любому окружению без лишнего самоограничения. Или я хочу слишком многого?

Похоже, что так. Обратная совместимость давно не в чести у разработчиков программного обеспечения и компьютерного оборудования. Новые браузеры не понимают старых протоколов — и для совместимости приходится делать несколько страниц HTML, в расчете на разные браузеры — при этом нет гарантии, что очередное "улучшение" протоколов Интернет и браузеров не превратит это старье в нечто совершенно несуразное. В наши дни пользователей заставляют устанавливать все новые и новые версии программ, а для этого приходится обновлять операционную систему, а новая ОС отказывается работать со старым оборудованием... И так далее, без остановки. Даже если я отсканирую свои страницы и выставлю их как картинки (лишая себя всех прелестей гипертекста) — эволюция графических форматов в конце концов погубит и эту затею.

Да, конечно, есть скриптовые библиотеки и интеграционные платформы, которые автоматически решают проблемы совместимости — до некоторого уровня. Разумеется, там много всякого мусора, который мне никогда не потребуется, — однако если предположить, что оптоволокно в каждый дом — дело ближайшей перспективы, заботиться о компактности, вроде бы, уже и не нужно. Все равно для современных Web-страниц, набитых под завязку графикой, звуком и видео, лишний мегабайт чистого текста погоды не делает. С другой стороны, разработчики сайтов нынче помешались на динамическом порождении контента — и старая добрая статика в наше время воспринимается как дурной тон, нечто неуместное в приличном обществе. Даже тупо текстовые страницы, на которых по определению никогда ничего не изменится, следует компоновать на лету из мелких кусочков — исключительно ради стилистического единообразия. В современном HTML почти не осталось собственно HTML, это сплошные скрипты. Конечно, дизайн становится громоздким и неуклюжим, съедает все имеющиеся ресурсы и целиком забивает полосу пропускания, приводит к периодическим подвисаниям из-за конфликтов с другими активными процессами. Но, конечно же, все это временное явление, и ситуация должна улучшиться с приходом технологий нового поколения, к которым лучше готовиться загодя... Но потом, когда долгожданные новые технологии все-таки приходят, оказывается, что они уже морально устарели — и современный уровень сложности для них становится высоковат. Все это напоминает бесконечную российскую стройку: мы постоянно что-то строим — но почему-то никак не видно ничего построенного, чем можно было бы просто пользоваться.

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

В идеале, автор мог бы ограничиться лишь общими указаниями на то, какие элементы форматирования для него существенны, — а все остальное возьмет на себя автоматика публикации. Такая система подготовки текстов включала бы набор всевозможных фильтров, позволяющих динамически обеспечивать качественное представление текста на любом носителе. Внутритекстовая разметка (да-да, я обожаю все эти старинные <i> или <b> и считаю, что обязательная замена их стилями стала бы катастрофой!) и введение индивидуальных стилей — это явное указание на важность соответствующего форматирования. Например, если я хочу, чтобы кусок текста был изображен жирным шрифтом или курсивом, — так оно и должно быть на печати, и мне дела нет до каких угодно экспертов, полагающих, что такой способ выделения уже не в моде и должен быть выведен из употребления. Почему я должен соглашаться с общепринятым идиотским мнением, что таблицы HTML не столь удобны для форматирования, как хаос явно и неявно привязанных к стилям секций <div>, про которые практически невозможно заранее сказать, во что это превратится на экране? Если я использую пробелы для создания отступов — это мое право, и стандартная ширина пробела должна сохранять мой замысел в неприкосновенности. Разумеется, мне потребуются разные виды пробелов для разных нужд — наряду с разными дефисами и тире; таким способом я смогу из самого текста управлять разбивкой на строки и выравниванием. И конечно же, нужен простой и удобный способ размещения в тексте графики (а здесь пока хромает любой HTML, со стилями или без). При необходимости я должен иметь возможность определять собственные стили — и мой выбор любая система презентации обязана уважать (включая встроенные шрифты или даже индивидуальные обработчики стилей).

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

Так или иначе, идея иерархического форматирования скрыто присутствует в большинстве текстовых процессоров. Например, похожий принцип был положен в основу TeX; однако существующие реализации как-то упустили из виду эту сторону дизайнерской работы, и в результате, как и в случае с HTML, приходится бороться с несовместимостью разных версий, корпоративных решений и типовых шаблонов. Любые попытки выработать универсальную модель документа обречены на провал, пока мы не откажемся от привычного древесного представления и не осознаем потребности в динамическом (ориентированном на контент) структурировании. В какой-то мере это напоминает использование статистических и структурных особенностей файла алгоритмами сжатия ради достижения максимальной плотности упаковки. Точно так же, модель документа в норме должна возникать из его содержания, а не из общих соображений, основанных на чьем-то ограниченном опыте и личных предпочтениях, а потому не отвечающих нуждам других категорий пользователей. Гибкость достигается путем смещения акцентов с единичных правил на общие принципы, позволяющие компоновку любых комбинаций правил по требованию. Такая обращаемость иерархий — необходимое условие для создания систем эффективной подготовки текстов.