CSS-live.ru

Как читать W3C-спецификации

Перевод статьи How to Read W3C Specs с сайта alistapart.com для css-live.ru. Автор — Джей Девид Эйсенберг.

(Примечание редакции CSS-live.ru: оригинал статьи написан более 20 лет назад. Не удивляйтесь, это не баг, а фича. Иногда полезно оглянуться назад и увидеть за калейдоскопом новинок какие-то неизменные основы. Или лучше понять ход прогресса технологий и порадоваться ему еще больше. В любом случае, многое в статье актуально по сей день, и уж точно стоит обсудить. Приятного чтения и приобщения к суперсиле спецификаций!)

Консорциум Всемирной паутины — это хранитель спецификаций по всем технологиям в вебе. Как веб-разработчик, вы могли заходить к ним на сайт в поиске ответа на вопрос про XHTML или чтобы узнать больше о новой технологии, такой как «Объекты форматирования XSL» или «Масштабируемая векторная графика»

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

Спецификация — не руководство пользователя

Библия предназначена не для чтения, а для толкования

— авторство неизвестно

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

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

Если технология новая, то для неё не всегда найдётся справочная информация: единственная доступная документация — это спецификация. В этом случае научиться читать спецификацию — это не роскошь, а необходимость.

Структура спецификаций

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

Слова для мудрых людей

Я ненавижу определения.

— Бенджамин Дизраэли

В руководстве по ремонту важнее всего точность, его не пишут в виде лёгкого неформального диалога с читателем. Точно так же W3C-спецификация пишется со всей традиционной формальностью японского театра Кабуки. Вот некоторые слова, которые встречаются при чтении спецификации:

нормативный

Слова «Этот раздел является нормативным» обозначают, что тут указаны детали, которые определяют, чему должны соответствовать реализации. Информативные разделы, напротив, обычно состоят из примеров и пояснений.

Пользовательский агент

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

RFC

«Рабочее предложение» (англ. Request for Comments — буквально «Запрос на отзывы») — документ, воплощающий стандарт интернета.

Вспомогательные глаголы

Если в спецификации сказано, что она соответствует RFC2119, то некоторые вспомогательные глаголы приобретают формальное значение. must означает, что определение — обязательное требование, must not — что это безусловный запрет, should — что функцию можно не реализовывать, но для этого должна быть действительно веская причина, а should not — что нужна действительно веская причина, чтобы эту функцию включить.

Беглое пролистывание

Дорогая тетя Марта! Спасибо за книгу о слонах. Она рассказала мне о слонах больше, чем мне хотелось знать.

— Детское письмо с благодарностью

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

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

4.2.5 Ограничения наложения: в этом разделе определяются понятие ограничений блочного и строчного наложений, затрагивающих области. Они определяются, как упорядоченные связи — если у А и Б есть ограничения наложения, это необязательно означает, что… Эй! Вы уже готовы пролистнуть?

С другой стороны, бывают моменты, когда стоит замедлиться. Если видите иллюстрацию, посмотрите на подписи и/или выноски. Обычно они относятся к важной информации. Когда вы видите раздел с примером или примерами, замедлите темп и внимательно прочитайте его.

Пространства имён

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

Вот знаменитое уравнение Эйнштейна E = MC2, с которым мы все знакомы.

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

Научитесь читать БНФ

BNF означает «Форма Бэкуса-Наура» или «Нормальная форма Бэкуса». Это компактный способ представления грамматики компьютерных языков, и он был, можно сказать, всегда. В различных спецификациях используются разные разновидности БНФ, но все они переводят длинные английские описания в символическую форму. Рассмотрим это на примере бутерброда:

Бутерброд состоит из нижнего ломтика хлеба, горчицы или майонеза; по желанию салат, по желанию ломтик помидора; от двух до четырех ломтиков варёной колбасы, салями или ветчины (в любом сочетании); один или несколько ломтиков сыра и верхний ломтик хлеба.

Это записывается как:

бутерброд ::= нижний_ломтик [ горчица | майонез] салат? помидор? [ варёная_колбаса | салями | ветчина ] {2,4} сыр + верхний_ломтик

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

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

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

Научитесь читать определение типа документа

Электронная энциклопедия фирмы Grolier — это источник всех ответов и вопросов, заданных на викторине Jeopardy.

— Строчка в титрах телеигры

Знаете про эти объявления <!DOCTYPE …>, которые вы вставляете в свои документы, чтобы сообщить браузеру, какую версию HTML или XHTML вы используете? Эти объявления ссылаются на определение типа документа, или DTD, которое решает, какие сочетания элементов допустимы в документе.

Хотя научиться читать DTD сложно, это вполне реально. И оно того стоит, поскольку именно DTD определяет, какой синтаксис правильный для конкретного языка разметки.

Полное объяснение DTD выходит далеко за рамки этой статьи, но его можно найти в визуальном кратком руководстве Элизабет Кастро «XML для всемирной сети» или «Изучение XML» Эрика Рэя. Вот краткий пример того, что можно увидеть в DTD:

<!ENTITY %fontstyle "(tt | i | b)"> 
<!ENTITY %inline "(#PCDATA | %fontstyle;)">
<!ELEMENT div (p | %inline;)+> 
<!ATTLIST div align (left | right | center) #IMPLIED>

В переводе на обычный язык это значит вот что:

Элементы стиля шрифта — это <code>, <i> и <b>. Инлайн-элементы состоят из текста или элементов стиля шрифта. <div> может содержать один или несколько <p> или инлайн-элементы в любом порядке. У <div> есть необязательный атрибут align со значениями left, right или center.

Проходите мимо IDL, опирайтесь на привязки

Некоторые технологии XML, такие как SVG и SMIL, позволяют пользователю писать программы для динамического управления документом, так же как JavaScript позволяет управлять HTML-документом. В их спецификациях будут разделы, описывающие, как скрипты работают с объектной моделью документа. В этих разделах показаны интерфейсы в IDL, языке определения интерфейсов.

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

На самом деле вам скорее всего понадобятся не они, а привязки Java или ECMASсript, в зависимости от языка, на котором вы программируете.

Привязки — это забавный термин для списка объектов, свойств и методов, доступных для ваших сценариев. ECMAScript — это стандартная версия JavaScript Европейской ассоциации производителей компьютеров.

Если вы используете какой-либо другой язык, к примеру, Perl или Python, то для них придётся искать стороннюю библиотеку в местах вроде «Всеобъемлющая сеть архивов Perl» или «Специальная группа по обработке XML на Pytnon».

Заключение

  1. Поймите, что спецификации W3C написаны для разработчиков реализаций, а не для конечных пользователей.
  2. Во многих спецификациях есть раздел с описанием, как они организованы и как их нужно читать.
  3. Знайте словарь, используемый в спецификациях.
  4. Помните, что не нужно читать каждое слово. Бегло просматривайте в поисках частей, которые имеют смысл.
  5. Избегайте обсуждений пространств имен.
  6. Научитесь читать BNF — он используется во многих местах.
  7. Научитесь читать DTD для ответов на вопросы по синтаксису.
  8. Если технология поддерживает скрипты, информация находится в привязках.

Будьте терпеливы и настойчивы, и вас поразит, сколько полезной информации вы сами сможете извлечь из W3C-спецификации.

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

1 комментарий

  1. В данной статье немного не верно написана одна цитата,указано … Библия дана не для чтения,а для толкование… Так вот-это ошибочно-искаженный текс,который уже в 18 веке обрел свое существование в каталической церкви одним богословом.  Верно же это звучит так… Библия дана для её исполнения,а не только для чтения… и т.д

Оставить комментарий

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

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