CSS-live.ru

Долговременная веб-семантика

Перевод статьи Long Term Web Semantics с сайта infrequently.org, c разрешения автора — Алекса Рассела.

Что-то раздражает меня во фразе «семантичный HTML».

Подразумеваемый смысл вполне ясен: использование HTML так, чтобы он был читаемым, описание вещей простым языком. Но «семантика» означает совсем не это. Можно было сказать просто «хорошо написанный» или «проверенный редактором». Это подошло бы лучше. Разметка, которую мы сегодня называем «несемантичной», на самом деле не такова: для конечных пользователей-то смысл есть, просто он передается слишком многословной разметкой. Рассусолено, но не «несемантично» (т.е. не «бессмысленно»).

Замысловатое и ускользающее от понимания — вроде того, что выходит из-под моего пера — плохо. Простое и ясное — хорошо. Сложно определить, что такое «просто» и «ясно», поскольку здесь замешаны вопросы значения и то, чего авторы (веб-разработчики) могут ожидать от читателей (браузеров). Для этого есть специальные фразы, напр. «Чтение на уровне 8 класса». Расчет на продвинутого читателя позволяет писать кратко и передавать тонкие оттенки. Знатокам не нужно разъяснять термины. Есть реальная польза в повышении общей грамотности в сообществе.

Употребление слова «семантичный», при котором речь идет о простоте, и подразумеваемое при этом значение этого слова говорят о глубокой путанице насчет того, как работает язык, роли разработчиков в донесении этого значения и реального потенциала смыслового развития для веба. Почему это важно? И чем плох «семантичный HTML»?

Возможно, ничем. Я склоняюсь к мысли, что это зависит от того, насколько мы приписываем успех веба как платформы везению, и как оцениваем вклад его специфики в этот успех. Моя версия, что везение (плюс удачность момента) и специфика соотносятся примерно как 40/60. У этой оценки нет экспериментальных подтверждений помимо сравнительных наблюдений за Flex, XAML, OpenLaszlo, JavaFX и Android-раскладками, а также их более настойчивыми конкурентами. Трудно планировать и проводить эксперименты по внедрению фреймворков для UI.

Как бы то ни было, мы можем набросать работающую схему участников, их интересов и того, что дает им HTML, чтобы лучше объяснить значимость, созданную теми ~60%. Это поможет нам осознать, в чем реальная семантика HTML, как она стала такой, и в чем может быть смысл ее осмысленного развития. Держа в уме эту схему, мы сможем выяснить, как изменения в HTML влияют на столь разных его потребителей. Она также позволит нам предвосхищать влияние JavaScript и расширений HTML (микроформатов, RDFa и Schema.org). С ними связано множество надежд и опасений, но если у нас будет работающая схема, которую мы можем примерить к наблюдаемой реальности, мы сможем перейти от чистых догадок к обсуждению механизмов.

Построить такую схему можно несколькими способами, но я думаю, что эффективнее всего рассмотреть основные аудитории HTML и выяснить, чего они хотят и что получают от HTML, CSS и JS. Тогда мы сможем очертить зоны пересечения этих интересов и обсудить, как возникает и передается значимость.

Аудитории

Разработчики

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

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

HTML превращает смертных в героев. Подобно тому, как это бывает в завязках дешевых комиксов, непосредственность и нетребовательность HTML дают «не-разработчикам» способность создавать вещи, которыми они могут делиться с другими людьми. Вещи, которые нужны людям. Именно этим отличаются хорошие инструменты. Он даже и на код не очень-то похож.

Значимость HTML с точки зрения разработчиков состоит полностью в показе разных штук на экранах, чтобы смотреть на них и взаимодействовать с ними. У модных течений «связанных данных» и «семантического HTML» есть странная склонность забывать об этом. Главная причина, по которой люди создают что-то в вебе — желание, чтобы другие люди нашли это что-то, и оно обогатило бы их жизнь. Обычно речь о визуальной и интерактивной значимости: показать, ввести в контекст, отобразить.

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

Разработчики пытаются добиться от пользователей, чтобы те восприняли именно то, что сами разработчики имели в виду. Что в статье важно. Что тут навигация, а что — основной контент. Какие элементы формы действительно обязательны. Для пользователей всё это — не «технические подробности». Семантичный контент — это то, что воспринимают конечные пользователи.

Пусть это отложится как следует. С точки зрения пользвателей, слайды PowerPoint или формы в PDF могут передавать практически ту же семантику, что HTML — визуальный и интерактивный контент, воспринимаемый как «значение» контента большую часть времени.

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

Подумайте о скромном <a href="...">: у него изначально есть интерфейс, чтобы отличить его от обычного текста (подчеркивание), плюс системная поддержка адресов и соглашения для них (посещенность, наведенность и т.п.), а также способность реагировать на ввод (переход по клику). Код для всего этого устрашал бы своим размером, и вам никогда не удалось бы навязать всем единые соглашения, если бы система не предоставляла свои. Но у тега ссылки всё это уже есть: связь между текстом и адресами, встроенный UI, поддержка поведения и прежде всего — невероятно компактная упаковка, благодаря которой вся эта мощь стала доступной любому, у кого есть текстовый редактор и FTP-клиент.

Дабы устоять пред искушением недооценить визуальные и интерактивные соглашения, представьте себе мир без них. Или мир, где у браузеров есть JS-овые API для перехода к другим документам, но нет встроенной системы, связывающей клики с переходами. Конечно, стихийный порядок мог бы возникнуть, но едва ли. За всё время, сколько существует флэш-контент, так и не появилось стандартного способа для «ссылок» между его единицами. Можно смело сказать, что обеспечение пользователей наглядными возможностями, чтобы помочь им решать свои задачи, и есть то, благодаря чему HTML преуспел.

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

Конечные пользователи

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

Технология, веб, «приложения»… это всё посредники. С хорошими посредниками нам проще получить нужное, и у них будут постоянные клиенты. Задача хорошей технологии — помочь пользователям получить то, что им нужно, быстрее, проще и с минимумом помех. Поэтому от нее не требуется обладание уникальным UI, если только вы не желаете выразить что-то очень ценное, что не по силам существующей системе. То, что визуальные и интерактивные соглашения не дают интерфейсам быть слишком индивидуальными — не случайность. Пользователи, дизайнеры и платформы изменяют наш визуальный язык все вместе. Если ваше приложение слишком далеко отобьется от стаи, его съедят.

Экономика HTML предпочитает встроенные компоненты UI дизайнерскому эксклюзиву: они быстрее и проще, даже если впечатление от их использования для данного сайта не идеально. Их понимают как пользователи, так и система, предоставляющая дефолтный UI «бесплатно» (сайтам не нужно строить его скриптами). По сравнению с ним изобретение JS-велосипедов оказывается еще менее выгодным.

Крупнейшей революцией в вебе стали поисковики. Построенные на основе соглашений HTML, поисковики позволили не только каждому публиковать, но и большинству — находить. PageRank лихо сыграл на соглашениях веба, чтобы извлечь смысл из хаоса. Поисковикам «виден» тот же контент, что пользователям (если он не спрятан в двоичном коде, открываясь лишь во время исполнения), так что можно передавать значение пользователям совершенно по-новому.

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

Не все пользователи одинаковы, конечно. Для многих UI по умолчанию бессмыслен или близок к тому. HTML приносит пользу и им, не потому, что заставил всех заботиться о доступности, а потому, что позволяет сторонним инструментам, выступающим от имени пользователей, заново интерпретировать высокоуровневый замысел в других низкоуровневых контекстах (напр. чтение вместо копирования блоками).

Опять же, невероятная мощь дефолтности играет поддерживающую роль: никакая вспомогательная технология не возникла бы, если бы встроенная библиотека элементов обычно не использовалась в основном одинаковым образом. Та же история и с поисковиками. Стимулы, которым подчиняются веб-разработчики — единственное, благодаря чему <a> не начал давным-давно стилизоваться по умолчанию как блочный контейнер (почему бы нет, это ведь короче, чем <div>). Эти стимулы вытекают из потребности быть понятыми большинством пользователей (теми, кто не пользуется вспомогательными технологиями). Простейший и лучший способ для этого — избегать переопределения слов. Пусть браузер рисует UI, придерживайтесь стандартного набора для всего остального и не пытайтесь вводить слишком много новых слов без крайней необходимости.

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

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

Издатели

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

Адреса ссылок и возможность поиска. Если ссылки и возможность делиться ими хороши для пользователей, то для издателей они — просто бомба. Они получают наиболее непосредственную выгоду от социального поведения, и ссылки — смазка в шестернях этого механизма. Не требуя выпуска 2-й или 3-й версии, веб сделал «создание сайта» еще и возможностью связать всё со всем без лишних хлопот. И, конечно, в большинстве современных фреймворков вам придется еще постараться, чтобы адреса не получились более-менее приличными.

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

Поисковики

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

Каковы практические выводы из этого для семантики? Ну, вы же не выберете документ, где половина контента от вас спрятана, верно? И уж точно не выберете его ради того контента. Действительно, документы, выдающие ботам и пользователям разный контент — скорее всего, спам. Из презентации Мэтта Каттса вполне ясно: индекс пытается увидеть веб так же, как видите его вы… и, конечно, помочь вам с выбором ответа. Но всё это основывается на определенном «понимании»… и платоновский идеал «понимания» контента не имеет никакого отношения к тайно внедряемым данным, он в первую очередь в том, что страница пытается донести до пользователя так, как сам пользователь это поймет.

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

Если цель поисковиков — понимать страницы так, как пользователи, то и семантика, о которой мы заботимся — та, что имеет значение для пользователей. Мысль, что нам нужно создать еще один смысловой слой над/под/сбоку от контента… совершенно ниоткуда не вытекает.

Рассмотрим таблицы.

Наверняка всю вашу профессиональную карьеру вам говорили, что использовать <table> для чего-либо, не являющегося табличными данными — БЯКА (как минимум, «неправильно»). И всё же вы видите, что множество компьютеров в мире не взрываются из-за неправильного применения <table> . Или <li> . Или <dt>/<dd> .

С одной стороны, да, таблицы помогают визуально оформлять что-либо в табличном виде. Но история свистопляски с механизмами веб-раскладок привела к ситуации, когда единственным универсальным способом добиться полной программной власти над раскладкой было использование таблиц для нетабличных данных… как каркас верстки. У этого были практические проблемы: некоторые браузеры отображали их плохо или медленно. О постепенной отрисовке не было и речи. Хватало багов. Всё это привело к тому, что использование <table> расширилось далеко за пределы табличных данных. Без общеупотребительного толкования значимость интерфейса выхолостилась. Как бы ни теплилась у HTML-пуристов надежда на то, что когда-нибудь данные внезапно станут машиночитаемыми оттого, что они в элементе <table>, это точно далеко от сегодняшнего положения дел, по трем причинам:

  1. Нахождение табличных данных в таблице не делает их полезными для кого-либо еще. Элемент <a> хотя бы дает пользователям какую-то возможность воспользоваться связями между UI и тем, к чему он относится, помимо «чистого представления».
  2. В HTML больше нет ничего, что умело бы пользоваться этими данными. Даже если вы поместите все свои табличные данные в <table> , это не добавит мощности никакой другой части вашего UI.
  3. Люди лгут.

Забудьте о машиночитаемости. Тег <table> не «растерял свою семантику», потому что его якобы «не так использовали», наоборот, он так и не стал чем-то «семантичным», потому что не смог развиться достаточно, чтобы иметь осмысленные отношения с чем-то еще, будь то с пользователями или с другими частями системы.

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

Ах да, я же упоминал ложь, так?

Да, люди лгут. И заставляют машины лгать за себя. Такова жизнь. HTML может быть «семантичным» в рамках своего предопределенного словаря лишь в той мере, в которой мы согласны использовать некоторые слова одинаковым образом — то, что мы чаще делаем по указке пользовательского интерфейса: посмотрите, в какое месиво превратились <article> , <section> и т.п. из HTML5. Добросовестные в целом действия добропорядочных людей не делают весь контент более достоверным или авторитетным, они лишь повышают средний уровень. Наша мысленная схема про веб-семантику должна учитывать, что в этом большом и страшном интернете какие-то куски кода, обозначающие себя как то-то и то-то, возможно, пытаются пользователя как-то обмануть. Так что показатели качества — первая попытка классификации в открытом вебе.

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

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

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

Семантический дрейф

Если вам доводилось вести раскопки в SQL-ных залежах крупной (читай: старой) компании, вы знаете, как невинно это всё начинается: была описана задача, создана схема, данные вбиты, и теперь это никак не изменить. Биты упакованы в поля, к которым они не относятся, поскольку перенормализовать базу нельзя по организационным причинам. Это лишь наиболее техническая версия того, что случается при столкновении языка с реальностью: если слова хоть чем-то полезны, они быстро расплываются. У них появляются контекстные значения, которых раньше не было. Они пробуждают другие ассоциации и расходятся по сообществам с их собственным жаргоном. Короче, они потихоньку дрейфуют далеко от своего первоначального значения (если оно вообще у них было) и начинают одновременно значить и больше, и меньше.

HTML в этом не отличается. С чего бы ему отличаться? Что означает <b>? Это оформление? Можно ли найти случай, где он не был бы оформлением? Чем теснее привязка к изначальной модели данных, тем сильнее тяга к дрейфу. Слова, в конце концов, пластичны. Да, если мы скажем «голубь», подразумевая «тыква», все услышавшие это посчитают нас идиотами, но когда достаточно людей воспримут это значение и начнут его использовать, неизбежный дрейф возьмет своё.

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

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

Латынь в наши дни накапливает не так уж много новых значений.

И, кстати, никто на ней и не говорит.

Это не совпадение.

Создатели браузеров

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

Ключевая вещь, которую нужно понять насчет команд разработчиков движков, фанатов стандартов, шлифующих их «острые углы», и (главным образом) C++-программистов, заставляющих всё это работать — то, что большинство из них не делает сайты. Как и их клиенты (конечные пользователи). Большинство программистов браузеров получают информацию, что надо бы реализовать, а что нет, из вторых рук. Самым сильным аргументом при этом оказывается «наши конкуренты реализовали нечто». Следующий по силе — «есть такая спецификация». Последний — «Это отличная идея, решающая проблему». Звучит как какое-то ретроградство? Подумайте о стимулах: если вы не главный источник прибыли, стоит ли вам разбиваться в лепешку ради «фичи», которой вы не сможете выделить свой продукт среди других (кроме, разве что, общего впечатления от его быстродействия). Веб-разработчики приведут ваш движок к «общему знаменателю» для конечных пользователей, и почти никто из веб-разработчиков не бросится использовать только новые (они же «проприетарные») возможности. Чтобы выйти из патовой ситуации, производители ищут признаки меньшего риска: действия конкурентов и спецификации. Если другие это сделали, наверное, это безопасно, и никто не хочет быть последним. А раз есть спецификация, то она наверняка прошла несколько этапов обтачивания самых неудобных углов (эх, если б только это было правдой!).

Самое важное, что здесь надо запомнить — несмотря на то, что у производителей браузеров есть все возможности для внедрения новой семантики, веб-семантика значит для них очень мало. Ситуация может улучшиться, когда движки начнут поддерживать больше всякой всячины на базе JS, теневой DOM и т.п., но по-моему не стоит слишком надеяться на это.

Семантическая эволюция

Логичное представление об эволюции веб-платформы начинает вырисовываться. Она должна:

  • позволять разработчикам создавать новую семантику (визуальную и интерактивную) для конечных пользователей, когда словаря HTML недостаточно;
  • быть осмысленно декларативной, желательно путем ссылок на другие данные/URL-ы для улучшения опыта;
  • иметь возможность стандартизироваться со временем.

Последний пункт, возможно, противоречив: многие из разработчиков JavaScript-библиотек уверяли меня, что если они могут убедить каждого использовать определенное окошко выбора даты (например) на базе jQuery, то зачем заморачиваться созданием стандартной версии?

Аргумент за стандартизацию — не то, что она ускорит внедрение новых существительных/глаголов, а скорее то, что она может помочь распространению их для новых поколений, тем самым снижая «цену» использования их в диалоге. Это роль словарей, и это логичная роль для HTML: как только семантика чего-либо доказала свою ценность, широко используется и имеет единую семантическую трактовку (визуальную, интерактивную и декларативную), HTML может узаконить наиболее массово используемый набор значений, тем самым позволяя создателям браузеров внедрить эти канонические версии. Для веба есть разница в эффективности между использованием «бесплатного» HTML-элемента и затратами на подключение виджета из библиотеки, всех ее зависимостей и интеграцию скрипта в свое приложение. Словами, которые, предположительно, знают все остальные, проще всего выразить значение. HTML — это человеческий язык для людей, разве в нем должно быть по-другому?

Это одна из идей, которыми руководствовались создатели веб-компонентов. Позволяя разработчикам расширять семантику HTML напрямую, мы получаем реальный шанс сделать веб-семантику для конкретных случаев, вроде той, что предлагают микроформаты и Schema.org, более осмысленной — во-первых, придавая ей непосредственную значимость для конечных пользователей в форме UI, во-вторых, обеспечивая такую интеграцию разметки, которая позволяет поисковикам извлекать какой-то смысл из обоих вышеупомянутых.

После долгих блужданий, в ходе которых библиотеки виджетов бьются друг с другом, сплавляются воедино и становятся «стандартами де-факто», сленг может попасть в каталог. Не дословно, конечно. Точная форма <person> или <place>, скорее всего, отбросит библиотечный префикс (напр. <polymer-person>), а встроенный UI пожертвует настраиваемостью в обмен на интеграцию с системой (для мест может всплывать карта, для людей возможно взаимодействие с адресной книгой). При таком раскладе у браузеров будет осмысленное занятие, и при расширяемости в самом ядре этой экосистемы, такой процесс может сформировать иерархию, где фантазии и типы данных стремительно эволюционируют (и вымирают) по краям, но те, что выживают и действительно входят в обиход, в итоге заслуживают включения в «словарь» — живую спецификацию HTML.

Не приведет ли это к повторению истории с вавилонской башней?

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

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

Это вызов для нас. Мы должны видеть эпохи в вебе не как вещи в себе, которым мы можем лишь подчиняться, но как ландшафт, который, стоит нам правильно определить правила, мы сами сможем быстро формировать для себя и медленно — для всех остальных.

Благодарности

Я благодарен Брюсу Лоусону, Дайону Элмаеру, Стиву Фолкнеру, Джейку Арчибальду и Фрэнсис Бэрриман за их комменатрии к раннему черновику. Все ошибки и опечатки целиком мои.

P.S. Это тоже может быть интересно:

14 комментариев

    1. Здравствуйте! Если честно, я удивлён такому выводу про "переводчик так себе", ибо считаю, что перевод просто великолепен. Илье (переводчику) удалость грамотно передать стиль и мысли автора статьи, причём достаточно литературно, как собственно и у автора. Я лично вижу, что перевод очень красивый и правильный, что в нём хорошо подчёркнуты все важные моменты в статье.

      В связи с этим у меня к вам просьба. В качестве подтверждения своего вывода о переводе, приведите пожалуйста список тех слов/фраз/предложений + ваш собственный перевод, которые вы считаете "так себе".

    2. Не буду спорить, перевод далек от идеала, оригинальная статья написана довольно заковыристо и в нескольких местах перевода у меня до сих пор есть сомнения (хотя я изо всех сил старался не исказить смысл и по возможности воспроизвести стилистику). Буду очень благодарен за указания на конкретные переводческие ляпы (особенно искажающие смысл оригинала), хотя бы самые значительные, чтобы исправить их и сделать текст лучше!

      1. А вы не могли бы на деле, а не на словах указать на те места/фразы/слова (и предложить свой перевод, соответственно), где по вашему мнению переводчик перевёл неверно?

  1. Поначалу я удивился комменту Кирилла, но потом во мне заговорил недостойный ученик замечательного литературного редактора, ныне покойного. Я перечитал статью и, да, нашел некоторые основания для критики. Мне кажется, Илья временами слишком "упирался в оригинал", из-за чего кое-где появились совершенно несвойственные ему стилистические просмотры ("Я склоняюсь к мысли, что это зависит от того, какую долю успеха веба как платформы вы припишете везению, а какой роли в этом успехе удостоите его достоинства.") Имхо, Илье надо больше доверять своему языку и своему стилю, они у него вполне заслуживают доверия (всё-таки не первый его материал читаю).

    Однако это вовсе не значит, что перевод неудачный. Даже наоборот, учитывая ту самую "заковыристость" источника, о которой сказал Илья. Статья действительно не простая, но весьма интересная. Алекс Рассел — мужик башковитый, и по ходу не раз хотелось задрать указательный палец и сказать "О!" или даже "Вот так вот!" Хотя иногда и поспорить хотелось, но с кем же и спорить, как не с башковитыми мужиками :)

    Короче, спасибо!

    1. Спасибо за отзыв! Действительно, некоторые моменты (включая процитированный) получились вымученными, потому что я пытался сохранить авторскую игру слов (не знаю, случайную или намеренную), напр, «how much you attribute to its particular attributes». Но статья действительно интересная и, на мой взгляд, актуальная (несмотря на то, что написана больше года назад — в конце концов, она же про долговременную семантику:), так что мне очень хотелось донести ее до тех, кто не сможет прочитать ее в оригинале, насколько это возможно. Буду благодарен за любые идеи, что в переводе можно улучшить!

      1. Согласен с автором вышенаписанного поста. Авторскую игру слов, на другом языке, передать просто не реально, если только не дать автору хорошо выучить этот язык, и посмотреть, как он будет на нём общаться. Хорошо понимать мысль автор и его юмор, это хорошо понимать контекст, в котором происходит и то и другое.

        Для примера, возьмём отвлечённую простую фразу «Take you mind to you own buisiness». Наверное, она хорошо передаёт психологию англичан и американцев, не совсем дословно это будет звучать»направь свою сознательность в свой собственный бизнес», понятно, что под бизнесом они имеют в виду, не только бизнес, в нашем понимании, но, думаю, не зря мы именно у них позаимствовали это слова для означения предпринимательской активности, работающего предприятия и тому подобное. Мы говорим: у него собственный бизнес, имея в виду, как правило, некое функционирующая организация, приносящая доход. Вероятно, слово бизнес, более ёмко и удачно выражает подобные смыслы, в большинстве привычных нам контекстов. Возможно они, и не о бизнесе, думают, в чём-то, как о бизнесе, о проекте, бизнес с неденежной прибылью :-) Это всё форма, в которую они, так или иначе, могут вкладывать довольно разное содержимое. Для них может быть привычно, в подобную форму обрамлять то содержимое, которое для нас, в подобную форму, обрамлять не привычно. А поскольку содержимое, всё-таки первично, то оно добавляет, словам, или выражениям, некие, не вполне привычные нам, добавочные смыслы. Ну просто «у них» про это говорят немного по-другому, другой набор штампов, из которого можно собрать ту или иную мысль, с той или иной степенью достоверности, передав те или иные нюансы. Но эти нюансы «обратно в слова», на другом языке, уже не упаковываются, нужно, всё-таки немного «собирать заново» используя «свой набор». Можно чтоб подчеркнуть где-то местный колорит, например, перевести не «не лезь не в своё дело» или «не суй нос не в свои дела», а скажем «дружок, думай о своих делах». Всё это может иметь смысл, а может и не иметь. Как на деле лучше, можно понять, уловив мысль и настроение автора. И выразив это доступными средствами.

        В целом, читал спокойно и комфортно, о качестве перевода особо не задумывался.

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

    Исходя из таких соображений, слегка изменим перевод всё той же фразы: "Я склоняюсь к мысли, что ответ зависит от того, какую долю успеха веба как платформы вы припишете везению, а какую — его собственным достоинствам." Что мы потеряли? Да ничего!

    Но, повторяю, Илья, всё это касается лишь некоторых частностей. Перевод состоялся, и единственное, что я могу посоветовать, так это дать ему немного отлежаться, стать как бы "чужой речью", а потом пройтись по нему с окончательной правкой. Статья еще долго будет актуальна, имхо.

     

     

  3. «Что-то раздражает меня во фразе „семантичный HTML“. Подразумеваемый смысл вполне ясен: использование HTML так, чтобы он был читаемым, описание вещей простым языком»

    Семантика по отношению к верстке означает соответствие имени контейнера его содержанию. Никаких разночтений тут быть не может. Если на горшке написано «Мёд», значит в нем «Мёд». И наоборот, если а нас есть «Дерьмо» мы должны хранить его в горшке с надписью «Дерьмо». Многословная ли разметка, лаконичная ли — роли не играет, это не критерий семантичности.

    И видя, что статья начинается с ложных предпосылок,  сразу возникает чувство брезгливости. Честно говоря, всё это выглядит бредом двоечника.

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

    Что значит семантичный контент? Как влияет осмысленность контента на верстку? Можно ли из этих слов автора, сделать вывод, что верстка становится семантичнее, если в нее положен «не бессмысленный» контент

     

    1. Семантика по отношению к верстке означает соответствие имени контейнера его содержанию.

      Допустим (хотя такие безапелляционные утверждения желательно подкреплять ссылкой на какой-нибудь АИ:). Но автор ведь как раз и удивляется, почему это соответствие имени контейнера содержанию вдруг стали называть термином «семантика», общепринятое значение которого (задолго до появления вёрстки и вообще интернета) — наука о смысле. Не правда ли, звучит не менее странно, чем «“Мёд” по отношению к вёрстке означает “дерьмо”»?:) Ну и вёрсткой мир (даже мир веб-разработки!) отнюдь не ограничивается, своя семантика есть даже у HTTP-заголовков.

      А W3C сейчас определяет семантику (в контексте веб-документов и интерфейсов) как

      Значение чего-то, как его понимает человек, определенное таким образом, что компьютеры могут обработать представление объекта, напр. элементы и атрибуты, и надежно представить объект так, что разные люди получат взаимно непротиворечивое понимание этого объекта.

      Так что на первом месте именно восприятие смысла человеком. И способность технологии этот смысл передать и донести. А «соответствие имени контейнера» и прочие технические мелочи — лишь средство, одно из многих.

      Автор этой статьи как раз предлагает взглянуть на всю эту картину более глобально, не упуская из виду конечную цель. И попытаться всё-таки достичь этого «взаимно непротиворечивого понимания»:)

      1. Что-то ответ не появляется, премодерации вроде нет, в прошлый раз коммент сразу появился. Если это реально дубль, просто оставьте последний вариант.

        Допустим (хотя такие безапелляционные утверждения желательно подкреплять ссылкой на какой-нибудь АИ:).

        Ну, например, английская википедия: Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages and web applications rather than merely to define its presentation or look

        Но автор ведь как раз и удивляется, почему это соответствие имени контейнера содержанию вдруг стали называть термином «семантика», общепринятое значение которого (задолго до появления вёрстки и вообще интернета) — наука о смысле.

        Термин не я придумал, но думаю, именно потому, что семантическая верстка подразумевает, что имя контейнера указывает на суть своего содержимого, а не на то, как оно должно быть представлено. Не жирный большой текст, а заголовок; на наклонный текст, а важный; не текст, выделенный отступом, а цитата. Так что, если говорить о примерах, то именно это и есть семантика в верстке. В свое время именно по этой причине стали избегать таблиц, именно по этой причине все теги big, small, font — теперь deprecated.

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

        Иногда мне кажется, что семантическая верстка в html это вообще один сплошной миф, если говорить о практике. За редким исключением, семантическую верстку проще обнаружить заглянув в любой fb2 или docbook — и это именно то, к чему в свое время хотели придти идеологи семантической верстки.

        Так что на первом месте именно восприятие смысла человеком. И способность технологии этот смысл передать и донести.

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

        1. Спасибо за комментарии! Нет, это не дубль, видимо, первый раз что-то действительно сбойнуло (будем разбираться).

          Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information

          Ну вот, википедия как раз говорит о том, что разметка должна передавать значение контента. Но есть нюанс в том, в чем именно состоит это значение:). Например, для практически любого человека таблица — то, что выглядит как таблица, а не как список или что-то еще. И вроде как нельзя упрекнуть скринридеры, которые не зачитывают как таблицы элементы table с неродным display: ведь на экране это получается уже не таблица, а скринридеры — именно что читалки экрана. Вот браузеры и сообщают им ту информацию, которую «видят» на экране. При том, что авторы искренне старались сделать разметку семантичной — теги для табличных данных выбрали правильные, возможно, даже атрибуты scope для th потрудились проставить как надо… разве что чуть «подшаманили» со стилями, чтобы адаптировать эту таблицу для маленьких экранов. И вроде бы и авторы правы, и браузеры (по-своему) правы — а в результате конфликт…

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

    2. За своей категоричностью, Вы упрощаете. Для передачи простых смыслов сказанное — верно и просто, но для передачи любых более-менее сложных вещей, это, почти никогда не работает. Любой язык ВСЕГДА проще передаваемых им смыслов и оттенков смысла, просто потому что смысл всегда сложнее значения, значение это усреднённый смысл, который кладут в коробочку и дают ей надпись исключительно для удобства. Жизнь состоит не из коробочек, она сложнее. Поэтому не язык определяет мысль, а мысль передаётся языком. Цель языка — возможность передачи сложных смыслов.

      Мечта отличника, «правильный мир» и брезгливость к миру не правильному… Но правильность сама по себе не может быть разумной целью, разумная цель, сделать работу с одной стороны удобной, а с другой — не потерять в удобстве осмысленности. Ну как-то так.

Добавить комментарий для Денис Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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