Веб-стандарты. Философия изящества. Часть 1

Артемий Ломов

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

Мысли, раскрываемые здесь, в тех или иных сочетаниях уже не раз озвучивались мной устно на различных семинарах и конференциях, но как-то до сих пор не представлялось повода объединить тезисы, посвященные каким-то частным проблемам, в целостный рассказ и облечь его в «твердую» письменную форму. Кое-что о философии веб-стандартов я, конечно, писал в своих колонках на «ИнфоБуме» и в первой книжке, но это было уже слишком давно. С тех пор мир существенно преобразился. Наверное, уже целое поколение веб-разработчиков успело смениться. :-)

Стандарты или рекомендации?

Начнем с того, что сам по себе термин «веб-стандарты» (калька с англоязычного “web standards”), положа руку на сердце, не вполне корректен — ну или, по крайней мере, не вполне точен и самоочевиден. Под веб-стандартами в узком смысле понимаются спецификации, разрабатываемые консорциумом W3C — а документы эти имеют статус рекомендаций, то есть их можно придерживаться, а можно и нет — никто насильно не заставляет. Спецификации W3C (за исключением редких частных случаев) не обладают статусом стандартов ISO или ГОСТ. Их несоблюдение не может повлечь за собой какие бы то ни было санкции в отношении веб-разработчиков или производителей браузеров со стороны гипотетических контролирующих органов — штрафы, отзывы лицензий и прочее подобное. Собственно, в этом мне видится одна из причин, скажем прямо, наплевательского отношения к букве спецификаций W3C подавляющего большинства веб-разработчиков, не склонных страдать приступами перфекционизма.

И даже еще не рекомендации!

Скажем больше. Рекомендация — это финальный статус спецификации W3C. До момента утверждения в таком статусе разрабатываемая спецификация проходит «огни, воды и медные трубы» весьма многочисленных этапов «шлифовки». Процесс этот порой по разным причинам затягивается на много-много лет. Так, например, официального утверждения спецификации CSS2.1 в качестве рекомендации W3C прогрессивная общественность ждала почти 10 лет — и дождалась наконец-таки вот буквально на днях, . В складывающихся условиях производители браузеров реализуют в своих продуктах, а веб-разработчики используют на создаваемых сайтах элементы «сырых» (то есть формально находящихся в разработке и ожидающих тех или иных дальнейших изменений) спецификаций задолго до их утверждения в качестве рекомендаций. Впрочем, только по такому сценарию и возможно вообще развитие веб-технологий как таковое — в этом процессе должно прямо или косвенно участвовать все профессиональное сообщество, а не только избранные участники рабочих групп W3C. Консорциум W3C, спору нет, — локомотив развития веб-стандартов, но, на минуточку, задача локомотива — тянуть за собой вагоны с пассажирами в нужном последним направлении. Локомотиву же, вообразившему себя самодостаточным, ничего не остается, как проследовать на тупиковый путь в полном одиночестве — что весьма наглядно продемонстрировала нам история XHTML2.

Открытость

Принципиально важный момент заключается в том, что веб-стандарты являются открытыми — любой желающий может совершенно свободно пользоваться этими технологиями, и они не защищены никакими патентами никаких компаний. Исторически так сложилось, что наряду с открытыми стандартами на веб-сайтах нашли себе применение и разного рода проприетарные технологии — скажем, графический формат GIF (срок его патентной защиты, правда, уже истек) или, например, Flash. Сообщество веб-стандартистов выражает уверенность в том, что рано или поздно таким вещам придется освободить занятое теплое место в пользу открытых стандартов (ну, предположим, формат GIF может быть замещен форматом PNG, а «убить» Flash и Silverlight вполне по силам таким технологиям, как SVG, Canvas и встроенная поддержка видео в HTML5 — на разных фронтах будут применяться различные тактики наступления.)

Чем плохи проприетарные технологии? Почему Flash и Silverlight обязательно нужно «убить»? Есть смысл остановиться на этом поподробнее, поскольку многие разработчики даже вполне прогрессивных взглядов недооценивают «масштаб бедствия».

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

Возможно, кто-то помнит, что в окрестностях 2004 года доля IE превышала 90%. И я лично знаком с людьми, которые тогда на полном серьезе предлагали объявить IE «единственно правильным» браузером, узаконить его монополию и развивать стандарты веб-технологий «от противного» — то есть руководствуясь тем, как реализована поддержка той или иной функциональности в IE. Сегодня подобные заявления кажутся нам горячечным бредом, но тогда у этой идеи были сторонники — причем, в общем-то, даже среди вполне адекватных во всех прочих воззрениях персоналий.

Нет необходимости фантазировать, что было бы (например, со всем зоопарком мобильных устройств, которые теперь, в отличие от 2004 года, поголовно умеют ходить в Интернет), если бы этот кошмарный сон волею какого-нибудь вопиющего массового помешательства смог стать реальностью. Достаточно вспомнить только тот реальный исторический факт, что IE7 вышел спустя пять с лишним лет (что в масштабах Интернета равносильно вечности) после выпуска IE6 — и то, надо полагать, это радостное событие изрядно поторопила нараставшая конкуренция со стороны Firefox, первая версия коего появилась на свет, на беду IE, в конце пресловутого 2004 года.

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

Дух и буква

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

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

Вот такая же штука и с веб-стандартами. Можно сверстать страницу, которая будет проходить проверку валидатором на соответствие спецификации XHTML 1.0 Transitional, но при этом код не будет иметь ничего общего с версткой не то что хорошего, но даже минимально приемлемого уровня. (Впрочем, сказанное справедливо даже для XHTML 1.0 Strict и HTML5 — свободы там ощутимо меньше, но ее все равно более чем достаточно. Не применяйте тегов <h1><h6> для обособления заголовков; отделяйте абзацы текста друг от друга тегом <br>, не используя для этих целей элементы <p>; горизонтальные отступы создавайте при помощи последовательностей из множества неразрывных пробелов; вставляйте картинки, не являющиеся частью контента, а служащие декоративными элементами, всегда при помощи тега <img> вместо того, чтобы делать их фоновыми рисунками; старайтесь как можно чаще использовать inline-стили — и цель будет достигнута. Любой приверженец веб-стандартов с не слишком крепкими нервами упадет в обморок от вашего кода.)

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

Три кита

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

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

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