Веб-стандарты — красивая мечта, но какова реальность.

Веб-стандарты — красивая мечта, но какова реальность?

Введение

До этого момента мы говорили о красивом идеале веб-стандартов. Веб-стандарты допускают функциональную совместимость между всеми браузерами, на каждой операционный системе и даже на каждом доступном электронном устройстве. Но как дело обстоит в реальности? Все ли браузеры следуют стандартам на 100%? Все ли веб-разработчики используют веб-стандарты должным образом? Создают ли веб-разработчики страницы, а потом отходят, уверенные, что их дизайн будет поддерживаться везде?

Действительно простой ответ на последний вопрос – нет. Это идеальная ситуация, которая далека от реальности. В этой статье я расскажу о следующих вещах:

* Как проверить сайт на соответствие стандартам?

* Соответствие современных сайтов стандартам

o Amazon: Торговля по стандартам?

o CNN: Стандартизованные новости?

o Apple: Вершина утонченности в дизайне … и валидации?

o Небольшое исследование соблюдения стандартов

* Почему есть нехватка сайтов, соблюдающих стандарты?

o Образование

o Бизнес-причины

* Резюме

* Дальнейшее чтение

* Упражнения

Как проверить сайт на соответствие стандартам?

Прежде, чем идти дальше, ответим на вопрос, который вы, возможно, задаете себе: «как узнать, что сайт использует веб-стандарты?». Выглядит ли он иначе, чем другие веб-сайты?

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

Самый простой способ проверить сайт на соблюдение веб-стандартов, – это воспользоваться валидатором, полезным инструментом, который доступен онлайн. Консорциум Всемирной паутины сделал доступным его по адресу http://validator.w3.org/. Вы можете (и должны) использовать этот инструмент для проверки всех сайтов, которые вы разрабатываете, на наличие ошибок в HTML-XHTML-коде. CSS можно проверить при помощи CSS-валидатора, расположенного по адресу: http://jigsaw.w3.org/css-validator/. Пройдите по указанным ссылкам и протестируйте несколько ваших любимых сайтов.

Гарантия того, что ваши сайты проходят валидацию, – это лишь половина дела. Как проверить, что браузеры следуют веб-стандартам? WebStandardsProject разработал серию тестов, которые называются Acid-тестами. Эти тесты используют некоторые комплексные HTML и CSS правила (а также дополнительную разметку и код), чтобы увидеть, сможет ли браузер отобразить тестовые изображения надлежащим образом. Последняя версия Acid-теста, Acid3, находится в разработке. Подробную информацию о тестах Acid вы можете найти на сайте http://www.acidtests.org/. Там же вы можете проверить свой браузер на соответствие стандартам.

Соответствие современных сайтов стандартам

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

Почему есть нехватка сайтов, соблюдающих стандарты?

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

Образование

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

Многие образовательные курсы не рассказывают об этих вещах хоть сколько-нибудь подробно. Я готов поспорить, что если вы спросите 10 разработчиков, которые работают с соблюдением веб-стандартов, где они научились своему мастерству, 9 из них скажет, что они – самоучки (а еще одна попросит ее не отвлекать, т.к. она слишком занята попытками заставить сайт нормально работать в IE6).

Консорциум Всемирной паутины (W3C), группа, которая отвечает за развитие стандартов, и WebStandardsProject (WaSP) приняли вызов и упорно трудятся над тем, чтобы поддержка веб-стандартов была улучшена как производителями браузеров, так и разработчиками.

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

Бизнес-причины

Сайт, который я часто посещаю ради предпринимателей, вовлеченных в создание веб-стартапов, организовал несколько дискуссий об использовании веб-стандартов в Web.20-приложениях. Это обычно интересный обмен мнениями между людьми, которые верят, что веб-стандарты должны применяться (по ранее перечисленным причинам), и теми, кто просто говорит «и что?».

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

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

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

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

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

Резюме

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

Так что же должны делать предприимчивые веб-разработчики будущего? Должны вы беспокоить себя веб-стандартами (и продолжить чтение серии статей) или вы запустите графический редактор и начнете делать разметку вашего сайта таблицами?

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

↓ссылка на сайт проекта

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

http://webhitech.ru/

Открытость

Принципиально важный момент заключается в том, что веб-стандарты являются открытыми — любой желающий может совершенно свободно пользоваться этими технологиями, и они не защищены никакими патентами никаких компаний. Исторически так сложилось, что наряду с открытыми стандартами на веб-сайтах нашли себе применение и разного рода проприетарные технологии — скажем, графический формат 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, эта проблема особенно актуальна в связи с тем, что «автономные» сайты почти вымерли — все вокруг считают священным долгом понавешать себе на страницы всякие счетчики, виджеты социальных сетей, разнообразные информеры, рекламные блоки… И, мягко говоря, далеко не все эти произведения сторонних разработчиков идеальны. А перфекционистов, готовых пожертвовать каким-нибудь красивым виджетом в пользу абсолютного совершенства верстки, — единицы.)

Три кита

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

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

Часть 2

Четыре стихии

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

Содержание — это, грубо говоря, «полезный груз» веб-страницы, тот текст, который вы видите, разглядывая ее в окошке браузера.

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

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

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

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

Большая тройка технологий

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

По мере развития HTML, CSS и JavaScript наблюдается смещение границ их сфер влияния.

Лет 15 тому назад для того, чтобы сделать шрифт надписи покрупнее и покрасить буквы красным, любой веб-мастер написал бы прямо в HTML-коде вот что: <fontsize="+1" color="#ff0000">очень важная надпись</font>. И оказался бы совершенно прав, ибо других способов добиться желаемого не существовало в принципе. Сегодня же за такое сразу выдают чугунную медаль за профнепригодность.

Лет 10 тому назад реализация эффекта «перекатывания» кнопок меню навигации не обходилась без JavaScript. Спецификация CSS2 уже даже была рекомендацией W3C, но это мало кого трогало — в распространенных на тот момент браузерах она толком не работала.

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

Семантика

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

На базовом уровне речь идет об использовании элементов HTML-разметки строго по их прямому назначению. К примеру, структурную единицу, по смыслу являющуюся заголовком первого уровня, необходимо размечать тегом <h1> и только им — другие элементы разметки для этого не подходят по своему назначению. Верно и обратное: использовать тег <h1> надлежит для разметки только и только такого элемента, смысловая роль которого — заголовок первого уровня. (Обычно заголовок первого уровня — это заглавие документа в целом, и такой элемент употребляется на странице в единственном экземпляре.Хотя спецификации HTML отнюдь не запрещают использование множественных элементов <h1> — ну, это к вопросу о духе и букве.)

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

Приведу простой пример для наглядности. Предположим, дизайн некоторого сайта предполагает использование цветового выделения дат публикации свежих новостей в блоке с информацией о текущих обновлениях. Скажем, оранжевым. Казалось бы, ничто не мешает нам разметить соответствующие элементы примерно следующим образом: <spanclass="orange">07.06.2011</span>, определив стилевые правила для класса orange в CSS-коде. А теперь представьте, что спустя некоторое время нам захотелось модифицировать цветовую схему новостного блока — ну, допустим, изменить выделение дат публикации новостей с оранжевого на синее. Конечно, можно было бы оставить код разметки в покое, заменив только соответствующее стилевое правило, но в таком случае старое, неактуальное уже название класса станет противоречить здравому смыслу и вносить лишнюю путаницу в и без того трудную жизнь — по-хорошему, код разметки надо бы тоже поправить. А вот если бы мы сразу поименовали соответствующий класс в соответствии с его смысловой нагрузкой — ну, например, как-то вроде newsdate, — описываемой проблемы не возникло бы в принципе. Кстати, в HTML5 для разметки информации о дате и времени предусмотрен специальный элемент <time>. Так что, если вы используете в верстке сайта именно HTML5, то совсем правильным было бы применение для обсуждаемых целей вот этого самого элемента <time>вместо семантически нейтрального <span>.

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

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

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

Валидность

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

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

Формальное соответствие HTML- и CSS-кода веб-страниц спецификациям W3C можно, как известно, проверить онлайновымивалидаторами разметки и таблиц стилей на официальном сайте консорциума.

Если вы относительно консервативны и не выходите в процессе разработки за рамки спецификаций, уже официально утвержденных в качестве рекомендаций W3C (речь идет, например, о сочетании XHTML 1.0 Strict и CSS2.1), в идеале необходимо стремиться доводить код до полностью валидного состояния. Тут все, в общем-то, предельно ясно.

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

Как тут поступить? В плане проверки валидности проблем почти нет — онлайновые валидаторы на сайте W3C уже давно научились понимать HTML5 (похоже, что даже в полной мере) и CSS3 (увы, здесь наблюдается ряд проблем, но баги отслеживаются и исправляются).

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

CSS3 развивается несколькими десятками отдельных модулей, находящихся в разных стадиях проработки (так, CSS ColorModuleLevel 3 уже получил, в один день со спецификацией CSS2.1, статус рекомендации). Особенность процесса развития CSS такова, что спецификация того или иного модуля CSS3 не имеет шансов на утверждение в качестве рекомендации в сколько-либо обозримые сроки до тех пор, пока не появится несколько полных не противоречащих друг другу реализаций данного конкретного модуля в основных браузерах. Потенциальной возможностью пересмотра тех или иных разделов «сырых» спецификаций порождена необходимость в первое время использовать экспериментальные свойства и значения CSS с вендорными префиксами — например, -moz- (для MozillaFirefox), -webkit- (для браузеров на основе движка Webkit — в частности, Chrome и Safari), -o- (для Opera). Применение конструкций CSS, использующих вендорные префиксы, конечно же, с формальной точки зрения автоматически делает соответствующие таблицы стилей невалидными, но этот «костыль нового поколения» — во всех отношениях разумное и удачное решение, против которого ничего не имеют ни W3C, ни сообщество веб-стандартистов. (К слову, у упоминавшегося CSS-валидатора с сайта W3C даже есть опция проверки таблиц стилей с учетом использования вендорных префиксов.)

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

Часть 3

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

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

Заключение

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

http://cleverscript.ru/html/2012-04-08-23-01-00/44-test-web-standarts.html

Тест на знание современных веб-стандартов
Если вы занимаетесь web-разработкой и используете такие web технологии как HTML, CSS, Javascript и пр. Вам будет интересно пройти замечательный тест на проверку свох знаний в области веб разработки и использовании web-стандартов. Вопросы довольно интересные и многие составлены в ключе последних статусов спецификаций различных web стандартов (HTML, CSS, SVG).

Пройти тест вы можете на сайте http://www.itquiz.ru/Rules.aspx, и ко всему прочему вы можете выиграть интересные призы от Microsoft, а также в конце теста получить и распечатать сертификат.

Довольно полезный тест, который может подтолкнуть к изучению веб стандартов, что в последствии повысит эффективность вашего труда:))

 

http://appledu.ru/library/web-development-new-edu

Введение

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

Самый краткий ответ: «Соблюдая стандарты!» Но разве раньше дело обстояло иначе? Да. И это было объяснимо. Сами по себе web-стандарты еще довольно молоды. Но главное, мало иметь стандарты, нужны программы, полноценно их поддерживающие. Пока на компьютерах основной массы пользователей стояли браузеры, плохо совместимые со стандартами, web-дизайнеры были вынуждены использовать соответствующий код. Создавались книги и интернет-ресурсы описывающие такой подход. Это, конечно, не могло не отразиться на содержании школьного курса.

Сейчас ситуация изменилась. Практически во всех современных браузерах для Windows, Linux, Mac OS X (MS InternetExplorer 6+, Netscape 6+, Opera 7+, Firefox, Safari, Konqueror, Galeon и др.) достаточно хорошо реализованыweb-стандарты. В то же время в школы (в том числе, в результате национального проекта «Образование») приходят новые компьютеры, доступнее становится Интернет. Это позволяет иначе строить и обучение разработке web-страниц.

В чем же особенности предлагаемого подхода и какие преимущества он предоставляет?

Есть три кита...

XHTML — eXtensibleHyperTextMarkupLanguage — расширенный язык разметки гипертекста
CSS — CascadingStyleSheets — каскадные таблицы стилей
DOM — DocumentObjectModel — объектная модель документа

Современныеweb-стандарты позволяют разделить структуру документа, его оформление и поведение. За структуру отвечает XHTML (или HTML). Внешний вид описывается на языке CSS. «Оживить» же страницу позволяет JavaScript, обращающийся к ее отдельным элементам в соответствии с DOM. JavaScript (под именем ECMAScript) был стандартизован Европейской ассоциацией по стандартизации информационных и вычислительных систем (ранее называвшейся Европейской ассоциацией производителей компьютеров — ECMA); XHTML, CSS, DOM являются рекомендациями (фактически, тоже стандартами) Консорциума World-WideWeb (W3C).

Рассказывая о разработке web-сайтов на уроках информационных технологий, мы и должны сразу же опираться на «трех китов» — разметку структуры, описание внешнего вида, программирование поведения, и четко различать назначение языков XHTML, CSS и JavaScript.

Структура