Как читать 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».
Заключение
- Поймите, что спецификации W3C написаны для разработчиков реализаций, а не для конечных пользователей.
- Во многих спецификациях есть раздел с описанием, как они организованы и как их нужно читать.
- Знайте словарь, используемый в спецификациях.
- Помните, что не нужно читать каждое слово. Бегло просматривайте в поисках частей, которые имеют смысл.
- Избегайте обсуждений пространств имен.
- Научитесь читать BNF — он используется во многих местах.
- Научитесь читать DTD для ответов на вопросы по синтаксису.
- Если технология поддерживает скрипты, информация находится в привязках.
Будьте терпеливы и настойчивы, и вас поразит, сколько полезной информации вы сами сможете извлечь из W3C-спецификации.
P.S. Это тоже может быть интересно:
В данной статье немного не верно написана одна цитата,указано … Библия дана не для чтения,а для толкование… Так вот-это ошибочно-искаженный текс,который уже в 18 веке обрел свое существование в каталической церкви одним богословом. Верно же это звучит так… Библия дана для её исполнения,а не только для чтения… и т.д