Наконец и до меня дошла эстафета, старт которой дал Никита Селицкий. Откровенно говоря, думал, что мне она раньше перейдет и я ее не выпрошу. =) В общем, меньше воды. Денис, спасибо за эстафету, приступим.

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

1. Приступая к работе над новым макетом обязательно изучите его внимательно, разбейте его на блоки, выясните, какие блоки повторяются на разных страницах, в чем может быть у них отличие? Это позволит вам заранее избежать необходимости вероятного рефакторинга вашего кода в случае непредусмотренных моментов, которые могут потом выясниться. На эту тему я вам советую почитать Виталия Харисова.
2. Выработайте свой code style и четко придерживайтесь ему. Никогда не поддавайтесь надежде, что вот завтра я приведу код в порядок. Здесь я не говорю о невалидных конструкциях, здесь речь идет о прилежании в написании в частности CSS-кода. Буквально завтра я опубликую “Кодекс верстальщика”, который мы выработали в нашей компании.
3. В качестве кодировки файлов макетов я советую избрать UTF. Это поможет избежать проблем в многоязычных сайтах что называется в зародыше. Обязательно выбирайте UTF без BOM, это позволит избежать проблем в Internet Explorer.
4. Учитесь грамотно оптимизировать графику в процессе “нарезки” макета. Выясните для себя особенности графических форматов GIF, PNG, JPG и применяйте в каждом конкретном случае тот, который будет наиболее уместен в конкретной задаче. Пользователи будущего ресурса будут вам благодарны.
5. Скажите нет хакам и инлайновой фильтрации в общем файле стилей. Я советую в основном файле писать правила для Mozilla Firefox. Стили для Internet Explorer подключайте с помощью Conditional Comments, стили для Opera подключайте с помощью MIME type opera/css, стили для Safari подключайте с помощью особого media type screen and (-webkit-min-device-pixel-ratio:0). Хаки и инлайн фильтрация плохи тем, что рано или поздно первые перестанут работать по причине исправления парсера браузера, вторые по причине того, что в новой версии другой браузер, научившись разбирать новые селекторы, станет читать правила, не предназначенные для него.

Надеюсь, эти нехитрые советы помогут вам чуточку приблизиться к идеалу в своей работе. Эстафету я передаю Константину Ефимову, Ольге Алексашенко, Дмитрию Лялину, Павлу Коноплицкому, Николаю Мациевскому и Игорю Морозову.

Хочу напомнить правила эстафеты:

1. Речь идёт о html/xhtml/css вёрстке.
2. Передавать эстафету нужно другому блоггеру только в том случае, если вы уверены, что он действительно в этом разбирается.
3. Не используйте в качестве советов элементарные правила html/xhtml/css.
4. Особенно приветствуются хитрости исправляющие баги в IE без использования хаков.
5. Мало рассказать о каком-либо баге. Нужно предложить решение.

Участники соревнований =) :

1. Никита Селицкий
2. Александр Исаков
3. Юрий Дроздов
4. Юрий Артюх
5. Вадим Макеев
6. Владимир Агафонкин
7. Денис
8. Максим Покровский
   
9. Павел Корнилов
10. Виталий Харисов
11. Марат Таналин
12. Волотко Дмитрий
13. webmolot
14. Александр Макаров
    
15. alexilin.ru
16. Волотко Дмитрий
17. Павел Ловцевич
18. Павел Коноплицкий
19. Владимир
20. Влад Мержевич
21. Игорь Морозов
22. Ольга Алексашенко
23. Дмитрий Лялин
24. Александр Шабуневич
25. Константин Мельников

Также хочу попросить уважаемого читателя сообщить мне о других участниках эстафеты, которых я забыл упомянуть. Буду вам безмерно благодарен. =)

Сегодня известный разработчик синтетического теста браузеров на соответствие вебстанадртам ACID, а ныне работник Google, Иан Хиксон сообщил об официальном релизе ACID3. Кроме того, все версии тестов и новости проекта теперь доступны по адресу acidtests.org.

Мы уже рассказывали ранее о нововведениях в ACID3, но не лишним будет повторить, что в отличие от ACID1, проверка которого была сосредоточена на блочной модели, и ACID2, который проверял широкое разнообразие HTML и особенностей CSS, ACID3 осуществляет проверку 100 вероятно уязвимых мест в HTTP, HTML, CSS, ECMAScript, SVG и XML, а также проверяет работу с DOM’ом (без которого сложно представить себе современно веб-приложение).

• DOM2 Core
• DOM2 Events
• DOM2 HTML
• DOM2 Range
• DOM2 Style (getComputedStyle, …)
• DOM2 Traversal (NodeIterator, TreeWalker)
• DOM2 Views (defaultView)
• ECMAScript
• HTML4 (&lgt;object&rgt;, &lgt;iframe&rgt;, …)
• HTTP (Content-Type, 404, …)
• Media Queries
• Selectors (:lang, :nth-child(), combinators, dynamic changes, …)
• SVG
• XML
• XHTML 1.0
• CSS2 (@font-face)
• CSS2.1 (’inline-block’, €?pre-wrap’, parsing…)
• CSS3 Color (rgba(), hsla(), …)
• CSS3 UI (’cursor’)
• data: URIs
• и прочее

Иан Хиксон является также одним из первых авторов спецификации HTML5, также известной как спецификация Web Apps 1.0, и ряда других разработок, как то хранение данных на стороне клиента (client‐side storage) и улучшенные формы (enhanced forms).

Иан написал 64 из 100 тестов, остальные 36 были разработаны совместными усилиями производителей браузеров и независимых веб-разработчиков. Работа над новым Acid3 началась практически в то время, когда разработчики IE8 сообщили о том, что их браузер успешно прошел Acid2. Правда, эта новость в сети была воспринята весьма критично, так как выяснилось, что для этого на стороне сервера пришлось подправить заголовки HTTP.

Обращаем ваше внимание, что для корректного тестирования вашего браузера, вы должны использовать настройки браузера по умолчанию. Изменяя масштабирование страницы, минимальный размер шрифта, применяя “fit-to-width”, или делая другие изменения можно изменить результаты прохождения теста.

Ссылки по теме:

1. Официальный сайт тестов ACID
2. Acid3 Browser Test
3. Acid3 browser test completed, available now
4. Acid3: Putting Browser Makers on Notice, Again

Вчера известный вебразработчик автор теста ACID, для проверки браузеров на соответствие вебстандартам, Иан Хиксон, выложил предварительную новую версию в сеть для всеобщего ознакомления, которая доступна здесь. Автор теста сообщает, что разработка уже практически завершена.

Традиционно тест проверял парсинг HTML и CSS, причем часто не прямым тестированием свойства, а обходным путем, изучая результаты его работы в браузерах. Например, для того чтобы пройти «ужасный» padding/margin тест, браузерам, кроме корректной поддержки CSS, нужно иметь правильную боксовую модель (“box model”).

Что же нового несет в себе ACID3? В первую очередь он главным образом основывается на технологиях ECMAScript и DOM. Разберем, что же именно тестируется, особенно в отношении ECMAScript:

• Элизия массивов – вещи подобно [,,] должны иметь нулевую длину, а для масива [0,,1] она должна быть равна 3.
• Методы массива – проверяется возможность добавления нескольких элементов в массив (.unshift(0, 1, 2)) и объединение его с undefined (.join(undefined).)
• Преобразования чисел - проверяется работа таких методов как .toFixed(), .toExponential() и .toPrecision(), в первую очередь, с дробными и отрицательными чилами.
• Операции со строками – метод substr() должен уметь работать с отрицательными аргументами (.substr(-7, 3)), доступ к символам строки должен осуществляться по их позиции (”my string”[0]). (это часть спецификации ECMAScript4)
• Работа с датами – удостовериться, что некоторые методы возвращают NaN (например, d.setMiliseconds() без аргументов), а также что происходит обязательное смещение +1900 лет.
• Unicode символы в названиях переменных – их использование должно вызывать оÑ?ибку. Например,

  eval("test.i\\u002b= 1;");

• Регулярные выражения - /[]/ должно соответствовать пустому массиву, а /[])]/ вызывать ошибку. Должны поддерживаться обратные ссылки (backreference) на несуществующие образы и отрицательные lookahed’ы - /(?!test)(test).exec(”test test”).
• Перечисления (Enumeration) – нужно убедиться, что свойства объекта правильно перечисляются, что доступны свойства с определенными именами (toString, hasOwnProperty, etc)
• Конструкторы – у пользователя должна быть возможность определять собственные конструктоы в свойстве .constructor, свойство .constructor не должно быть в перечислении, а свойство .prototype.constructor должно быть удаляемым.
• Функции – возможность вызывать функцию по имени из самой себя, прямое изменение ее имени должно быть запрещено(только используя массивы функций). (function test(){ … })(); - «test» не должен быть виден в родительской области.
• Ошибки – переменные в блоке catch(){} должны в первую очередь работать с аргументами catch(), а затем уже с родительскими. Например

  
  var e = "my name";
  try
  {
  ...//некий код
  }
  catch(e)
  {
  alert(e);
  }

  не должно выводить “my name”.

• Операции присваивания - s = a.length = “123″; - a.length должно возвращать 123, а не 3
• Кодировки - encodeURI() и encodeURIComponent() должны корректно работать с нулевыми байтами.

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

Подробности автор теста обещает представить уже в ближайшие дни.

И напоследок, предварительные результаты тестирования НЕЗАКОНЧЕННОГО Acid 3 над НЕЗАКОНЧЕННЫМИ? версиями наиболее популярных браузеров, которые предоставил автор. Мы проверили, все сходится! =)

Вот эталон, который должен показать браузер.

Firefox 2.x

Firefox 3.0b2

Safari 3

WebKit Nightly

Opera 9.5b1

Internet Explorer 7

Ссылки по теме:

1. Предварительное зеркало теста.
2. Запись автора Джона Резига в личном блоге.

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

В свое время мне очень помогли блоги вебразработчиков и форумы, на которых они делились своими практическими знаниями по интересующей меня теме верстки гипертекстовых документов. Это очень помогло мне в быстром освоении правильного подхода к верстке. До моего озарения я 5 лет придерживался старой “табличной” школы верстки, слыхом не слыхивал о принципах вебстандартов, поэтому мне было крайне тяжело переучиваться, когда я столкнулся с необходимостью кардинального роста качества моей работы.
Сегодня накопленный опыт просто давит на черепную коробку изнутри и мне хочется им поделиться в свою очередь с новым поколением. И, дабы как-то упорядочить публикацию моих материалов по верстке, я решил сделать что-то вроде электронной книги. Мне кажется, так легче будет и мне подавать материал и вам его воспринимать. Может быть этот труд даже вырастет когда-нибудь в печатное издание, как знать…

В общем на текущий момент я решил публиковать материалы примерно в следующем порядке:

1. Литература и электронные материалы.
2. Инструментарий: редакторы.
3. Инструментарий: браузеры и плагины.
4. Инструментарий: утилиты и вебсервисы.
5. Введение в верстку гипертекстовых документов.
6. Вебстандарты: теория разделения содержимого и представления.
7. Выбираем технологии: HTML, XHTML, CSS.
8. Введение в селекторы.
9. Специфичность селекторов.
10. Базовый файл стилей и рекомендации “хороÑ?его” CSS.
11. Блочная модель CSS.
12. Типичная разметка.
13. Работа с текстом и шрифтами.
14. Понятие багов и методы борьбы с ними.
15. Фильтрация стилей.
16. Работа с графикой.
17. Практикум и эксперименты.

Пока я вижу это так, возможно будут коррективы по ходу написания и публикации. Этот мой маленький проект я назову пока, например, CSS Book. В месяц я планирую писать 3-4 поста, которые буду публиковаться в ленте блога. Также я создал отдельную страничку CSS Book, на которой будет собираться оглавление возможно будущей книги =).

Как и обещал выкладываю материалы своего доклада на Байнет 2.0. В конце статьи вы найдете ссылки для скачивания pdf-версии доклада и архив с презентацией.

Всегда поступайте правильно.
У некоторых людей это будет вызывать одобрение, у остальных – удивление.

Марк Твен.

Вступление. Выделение проблемных вопросов.

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

Что такое вебстандарты?

Вебстандарты это патентованные рекомендации Консорциума всемирной паутины World Wide Web Consortium, которые представляют собой технические спецификации. Благодаря особой патентной политике, основанной на W3C Royalty-Free License, стандарты могут свободно применяться при разработке любых информационных систем.

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

Любой стандарт W3C проходит 4 стадии согласования до того, как официально станет Рекомендацией W3C.

• Рабочий проект (англ. Working Draft);
• Последний созыв (англ. Last Call);
• Возможная рекомендация (англ. Candidate Recommendation);
• Предлагаемая рекомендация (англ. Proposed Recommendation);

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

World Wide Web Consortium (W3C) — организация, разрабатывающая и внедряющая технологические стандарты для сети Интернет. Она была создана в 1994 году, как консультативный орган для лидеров компьютерной индустрии. Консорциум возглавляет Тим Бернерс-Ли, изобретатель HTTP, HTML, URI, автор множества других разработок в области информационных технологий и отец-основатель Интернета.

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

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

Со времени своего основания Консорциум всемирной паутины проделал огромную работу, выпустив более 80 рекомендаций. Членами Консорциума ныне являются более 350 организаций из 28 стран мира. На рекомендациях W3C основаны тысячи программ и сотни миллионов файлов в сети Интернет. В настоящее время Консорциум является, пожалуй, самой авторитетной организацией в области стандартизации Всемирной паутины.

Что такое сайты нового поколения Веб 2.0?

Само понятие Веба 2.0 появилось с легкой руки известного компьютерного эксперта Тима О’Рейли, владельца известного издательства O’Reilly Media, в процессе подготовки очередной интернет-конференции. Так что же он имел в виду, говоря о концепции Веб 2.0?

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

Четкого определения этого модного понятия до сих пор не дал ни один эксперт. Просто потому что его и не существует. Говоря о Веб 2.0, мы можем излагать мысли тезисно. Вот такие тезисы, на мой взгляд, можно выделить. Веб 2.0 это:

1. социальная направленность;
2. применение веба в качестве платформы;
3. предоставление сервиса, вместо контента;
4. генерация контента пользователями сервисов;
5. импорт/экспорт контента между сервисами;
6. маркировка контента;
7. новое поколение настраиваемых интерфейсов;
8. маркетинговый инструмент, в конце концов и пр.

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

Таким образом, поколение сайтов 2.0 предполагает корректное применение в технологическом процессе таких технологии, как ECMAScript, XHTML, XML, JSON, AJAX, CSS, разработанных Консорциумом W3.

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

Какие преимущества дают вебстандарты в рамках нового поколения вебсайтов?

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

• Упрощение и удешевление процесса разработки. Применение синтаксически верной семантической верстки позволяет упростить процесс форматирования данных, за счет его очевидной структурированности, отсутствии избыточности кода перед классической “табличной версткой”. Это позволяет осуществить выполнение этапа работы с меньшими трудозатратами и позволяет оперативно включать в процесс разработки новых людей. Также упрощается поиск ошибок.
• Упрощение и удешевление поддержки и модернизации. Раскрытие этого преимущества базируется на тех же принципах, что и предыдущего.
• Возможность реализации гибкой настройки интерфейсов приложений самим пользователем, как с помощью возможностей самого сервиса, так и с помощью сторонних приложений. Это преимущество достигается за счет блочного представления данных в семантической верстке. Пользователь может свободно перемещать, включать, отключать отображение блоков, в том случае конечно, если это предусмотрено самим сервисом. Также применяя свои собственные таблицы стилей или используя стороннее программное обеспечение, такое как расширение Stylish для браузера Mozilla Firefox, пользователь сможет самостоятельно, при наличии базовых знаний настраивать отображение документа в окне браузера.
• Упрощение процесса взаимодействия между сторонними сервисами. Возвращаясь к сетевой интероперабельности, в подтверждение этого преимущества можно привести тот факт, что правильно структурированные синтаксически строгие данные упрощают процесс парсинга, что приводит к упрощению и теоретическому повышению безопасности серверной логики. А применение такой технологии, как микроформаты значительно расширяет возможность обмена данными между сервисами.
• Повышение доступности сервисов. За счет разделения структуры, представления и поведения данных, на практике достигается возможность деликатной деградации (англ. graceful degradation). Применение принципов WAI и Section508 расширяет аудиторию сервиса за счет доступности сайта для людей с ограниченными физическими возможностями и доступности для устройств с ограниченными возможностями отображения данных.
• Повышение привлекательности сайта для поисковых систем. Документ, в котором больший удельный вес приходится не на структурные элементы, а на контент и документ, проходящий валидацию, при ранжировании при прочих равных условиях получает больший вес.

1. наличие атрибута alt=”” для изображений (с записью, соответствующей содержанию изображения);
2. для элементов Flash используйте звуковое сопровождение, заменяющее атрибут alt=””;
   используйте относительные размеры шрифтов для возможности их масштабирования;
   создавайте метки табуляции для полей и кнопок форм вашего документа, управляйте порядком табуляции, создавайте горячие клавиши;
3. фон содержащего текст блока всегда делайте контрастный, для проверки отключайте отображение графики в браузере и убедитесь, что весь текст остается доступным для чтения;
4. проверяйте ваш документ с отключенным CSS, он должен быть удобочитаемым;
5. проверяйте ваш документ в основных браузерах;
6. обеспечьте альтернативу для посетителей, не пользующихся мышью: onclick=”” применяйте вместе с onkeypress=””;
7. внимательно относитесь к формам, обрамляйте их в <fieldset> с описанием в <legend> и скрывайте при необходимости с помощью стилей.

1. Экранные устройства. В первую очередь цветные мониторы.
2. Портативные устройства. КПК, мобильные телефоны и прочее.

1. All – любое устройство отображения.
2. Aural – устройство речевой синтезатор.
3. Braille – для устройств с обратной связью, на основе шрифта Брайля.
4. Embossed – Намеченный для пронумерованных страницы для слепых принтеров.
5. Handheld – карманные устройства, например, КПК.
6. Print – устройства печати.
7. Projection – проекционные устройства.
8. Screen – экранные устройства, например, монитор.
9. Tty – устройства, использующие сетку с фиксированным размером знаков, например, телетайпы.
10. Tv – телевизионные устройства.

• Представление семантически неверной разметки, в основе которой лежит “табличная модель”.
• Размещение стилистического оформления в структурной части документа.
• Пренебрежение синтаксической строгостью документа.

• HTML;
• XHTML;
• XML.

• CSS1;
• CSS2;
• CSS3.

• ECMAScript;
• DOM1;
• DOM2.

• семантика документа;
• синтаксическая корректность документа.

• XML-документ, коим является XHTML, должен иметь один корневой элемент, в котором лежат все остальные.
• Все открытые теги обязаны быть закрыты. Непарные тэги должны быть самозакрывающимися.
• Ð?мена тегов регистрозависимые. В XHTML они должны быть только в нижнем регистре.
• Теги не должны нарушать вложенность.
• Все атрибуты тэгов должны быть заключены в двойные кавычки.
• Есть три символа - <, > и &, которые обязаны быть экранированы везде с помощью <, > и &. А внутри атрибутов надо экранировать еще и двойную кавычку с помощью “.
• Все символы в документе обязаны соответствовать заявленной кодировке.

• режим уловок (quirks mode);
• режим стандартов (standards mode);
• режим стандартов в понимании IE (присущ только браузерам на основе Gecko).

• Любой полный DOCTYPE включает режим стандартов в браузерах, начиная со следующих веток IE5+/Mac, IE6/Win, NS6/Win, Moz1/win, Opera7/Win.
• Полный строгий DOCTYPE включает режим стандартов во всех указанных выше браузерах и их более новых версиях.
• Полный переходный или фреймовый DOCTYPE включает режим стандартов в понимании IE в браузерах на основе движка Gecko.
• Неполный DOCTYPE с относительным или отсутствующим URI включает режим обратной совместимости во всех браузерах, поддерживающих режим переключения доктайпа, кроме Internet Explorer 6.0+.

• Во-первых, он использует отличный от XML синтаксис, а современная разметка все больÑ?е склоняется к XML.
• Во-вторых, в DTD отсутствует типизации узлов.

• Priority 1;
• Priority 2;
• Priority 3;

• Проекционные устройства.
• Печатные устройства.
• Синтезаторы речи и пр.

Текущее положение вещей в сети.

Морально устаревший код в современных вебразработках.

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

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

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

Из основных архаизмов на сегодняшний день можно выделить следующие:

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

Препятствия к широкому внедрению вебстандартов.

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

Широкое распространение браузеров с очень низкой и зачастую неправильной поддержкой вебстандартов.
Массовая пассивность и безответственность вебразработчиков.

Низкий порог входа в среду веб-разработчиков.

На май 2007 года, согласно статистике liveinternet.ru, пользователями наиболее распространенных сегодня браузеров Internet Explorer 6-ой и 7-ой версий являются 72.6% аудитории русскоязычного сегмента Интернета. Internet Explorer 6.0 был выпущен в 2002 году, т.е. 5 лет назад и на сегодняшний день во всех отношениях является морально устаревшим продуктом. Однако, производитель этого браузера – компания Microsoft, пользуясь своим фактически монопольным положением на рынке браузеров, до последнего момента не спешила к обновлению линейки своего продукта.

Вебразработчики всего мира с надеждой ожидали выхода новой версии. Однако разочарование после столь долгого ожидания оставило неприятный осадок. Согласно независимой статистике сайта Web Devout, поддержка CSS2.1 у нового браузера составила всего 55% против 51% у предыдущей версии. Для сравнения у браузеров Firefox 2 и Opera 9 эти показатели составляют 93% и 96% соответственно. Если в эту статистику включить тест поддержки DOM, ECMA Script, то картина будет еще более удручающей.

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

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

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

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

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

Раньше задача стояла так – решить насущные проблемы без учета завтрашнего дня.”

Внедрение вебстандартов в процесс разработки сайтов нового поколения.

Философия разделения структуры, представления и поведения.

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

Итак, структуру документа описывают языки разметки:

Стилистическое оформление берет на себя единственная актуальная технология в нескольких своих версиях:

За поведение отвечают стнадртизированный скриптовый язык и несколько версий объектной модели документа:

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

Все внешнее оформление – привязка графического дизайна к сайту, определение оформления текстового материала – выносится во внешний файл стилей, который подключается к документу. Этот файл представляет собой список правил согласно спецификациям CSS1-3, который дает практически абсолютный контроль над изменением стилистического оформления страницы: управления шрифтами, позиционированием элементов, цветами и т.д.

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

Поведение документа контролируется с помощью стандартной объектной модели документа DOM1-2, которая замечательно работает с CSS, HTML, XHTML, XML и ECMAScript. Внесение в разметку того, что касается сугубо функциональности, в той же мере оÑ?ибочно, что и применение устаревших приемов верстки. Это нарушает принцип разделение функций во front-end-технологиях. Применение этих стандартов W3C позволяет в большинстве случаев отказаться от использования патентованных платформозависимых технологий.

Семантика документа, как повод к смене образа мышления.

Разработка вебсайтов по стандартам в контексте верстки несет в себе два критерия:

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

Таким образом, первым шагом к вебстандартам станет отказ от табличной верстки в пользу семантической или, как ее еще называют, “дивной”. Т.к. семантическая суть структурного элемента <table> – отображение табличных данных! В свое время таблицы стали применяться в отсутствие иного приемлемого способа разметки документа. Однако сегодня у разработчиков есть мощнейшие инструменты в виде технологий HTML, XHTML и CSS. Карты в руки, как говориться.

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

С разметкой разобрались, перейдем к оформлению. Заголовки должны обязательно браться в тэг заголовка, абзац в тэг абзаца, любой список – соответственно в список. Здесь стоит отметить, что меню сайта является упорядоченным списком, которое и стоит верстать, применяя элементы списка. Это позволит делать сложнейÑ?ие по внеÑ?нему виду меню, недоступные иными путями без использования скриптовых языков.

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

В общем, лучше не успеть научиться верстать таблицами, чем потом переучиваться.

Необходимо отметить, что существуют некоторые ограничения среды отображения, в частности, монитора, которые в своей работе должен учитывать дизайнер. Дизайнер не всегда может понять логику сервиса, ему важнее композиция работы. Но, увлекаясь тем, как сделать правильную композицию, он теряет “логику” своей модели. Таким образом, в идеале должен существовать тандем дизайнера и фронтенд разработчика. В своем совместном сотрудничестве они будут корректировать работу друг друга, что избавит от дальнейÑ?их проблем в реализации дизайна.

И запомните, стандарт – это, прежде всего, эталон!

Синтаксическая корректность документа (well-formed).

Синтаксическая корректность (англ. well-formed) – это набор четких, строгих правил составления документов, форматируемых посредством тэгов. В нашем случае мы будем рассматривать ее в контексте XML-совместимых документов, в частности, XHTML.

Основными правилами являются:

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

Сегодня большинство гипертекстовых документов обрабатываются не XML, а SGML-парсером, который “прощает” встречающиеся ошибки. Ð?менно поэтому и существует такое безразличное отношение к контролю качества разработки.

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

Синтаксические правила корректности языка разметки (valid).

Корректность языка разметки (валидность) - это синтаксические правила корректности конкретных языков разметки.

Правила валидности определяют следующие аспекты:

• название корневого элемента;
• элементы, допустимые внутри какого-то элемента;
• допустимость текста внутри элемента;
• обязательность присутствия элемента;
• обязательность присутствия конкретных атрибутов элемента.
• расшифровки строковых сущностей (например, знак амперсанда).

Правила валидности записываются формально в виде DTD-описания, подключаемого к документу, путем объявления его типа (DOCTYPE).

Объявление типа документа (англ. DOCTYPE) – это элемент структуры (x)HTML-документа, указывающий браузеру, каким образом следует обрабатывать документ, а службам проверки он сообщает, какая версия языка разметки используется и как тестировать документ на соответствие стандартам.

Указание типа документа является ключевым компонентом в совместимости гипертекстовых документов и влияет на поведение документа в различных браузерах.

Элемент DOCTYPE помещается над всеми (x)HTML-документами, предшествуя остальному коду. После объявления типа документа для (x)HTML-документов следует пространство имен. Пространством имен в XML является набор элементов и имен атрибутов, связанных с определенным типом документа (DTD). Декларация пространства имен позволяет идентифицировать пространство имен, путем указания его расположения. Также вместе с декларацией указывается язык документа и языковая версия XML.

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

Типов режимов существует три:

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

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

Итак, подытожим реакцию браузеров на объявление типа документа:

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

Сейчас идёт постепенный отказ от формата DTD по ряду причин:

На смену DTD идет стандарт консорциума W3C XML Schema, однако более детальное углубление в этот вопрос выходит за рамки обсуждаемой темы.

Конформность документа (conformance).

Конформность – это полное соответствие документа стандарту W3C.

Соответствие стандарту W3C подразумевает не только прохождение синтетических тестов, таких, как валидатор (x)HTML, CSS. Многие правила в спецификации сформулированы в виде простого человеческого языка.

Ошибками в валидных, но не конформных документах могут быть следующие примеры:

• несемантическое использование структурных элементов;
• нелогичные описания изображений в атрибуте alt=””;
• и прочие, противоречащие логике решения.

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

Повышение доступности содержимого сайтов нового поколения.

Пользователи с ограниченными возможностями.

Доступность сайта и вебстандарты связаны самым непосредственным образом. В конце 90-х готов W3C даже запустил специальный проект в помощь разработчикам для повышения доступности их сайтов, получивший название Web Accessibility Initiative (WAI).

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

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

Доступность сайта за счет правильного семантического применения структурных элементов позволяет сделать сайт доступным для специальных программ – речевых синтезаторов, которые могут адекватно считывать текст. Кроме того, самым важным посетителем любого сайта с проблемами зрения является поисковая система Google, для которой также очень важна семантика документа.

Все средства повышения доступности никак не влияют на дизайн сайта, они применяются в разметке незаметно для пользователя. Я перечислю основные из них:

Думаю, всем известна история Дага Баумана, который после редизайна сайта wired.com получил благодарственное письмо от некоего Марка, посетителя обновленного сайта, получившего удовольствие от работы с ним. Эта история не получила бы широкой огласки, если бы не одно «но». Этот посетитель оказался слепым человеком.

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

Многообразие сред отображения документов.

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

Согласно спецификации CSS2 можно выделить следующие типы актуальные типы сред отображения пользовательских агентов:

Кроме того, определяются и более экзотические среды, такие как:

Полный список выглядит следующим образом:

Скачать доклад в PDF-формате. Скачать презентацию в формате s5 (работает под Mozilla Firefox).

Favicon, что это и для чего он нужен? Favicon.ico это файл ярлыка в ОС Win32 который является иконкой-ссылкой на страничку сайта, на которой он присутствует. Его можно видеть в в избранных ссылках вашего браузера, адресной строке и на закладках в многооконных браузерах. Как его прикрутить к страничке? Для того чтобы нарисовать иконку вам необходимо воспользоваться любым графическим редактором, но после вам необходимо конвертировать ваш полученный графический файл в формат .ico либо же изначально рисовать его в специализированных редакторах типа AWIcons Pro, IconWorkshop, MicroAngelo и т.п. Простое переименование расширения файла в .ico плохая идея, т.к. некоторые браузеры не примут такой файл и не отобразят иконку. Если вам всеже привычнее работать в фотошопе, то вот здесь вы можете скачать плагин для работы с изображениями в формате .ico. Для работы плагина файл необходимо распаковать и сохранить в папке Plug-Ins\File Formats в корневой директории Photoshop.

Итак, у нас есть иконка, конвертированная правильным способом в формат .ico. Далее по пунктам.

1. Название иконки должно быть favicon.ico, т.к. некоторые старые браузерв не смогут опознать ее именно как ярлык сайта.
2. Подключение иконки к документу осуществляется следующим кодом

   
   < link href="/favicon.ico" rel="shortcut icon" type="image/x-icon" />

   . Обязательно необходимо указать тип содержимого как image/x-icon и связь с документом как shortcut icon. Кроме того, что это обязательно по спецификации w3c, есть вероятность того, что вы снова споткнетесь об особенности работы некоторых браузеров, не указав тип содержимого.

3. Размер иконки вы можете выбрать от 16х16 до 48х48, чем больше иконка тем она будет симпатичнее, в случае, когда пользователь вздумает поместить ярлык на ваш сайт на свой рабочий стол, например. Но! Мы живем в реальности которая называется “Все мы любим Internet Explorer”. Поясняю, иконки размером превышающие 16х16 px попросту проигнорируются IE 6.0 и ниже. Однако существует возможность в один файл .ico упаковать несколько изображение, как разных по размеру, так и по содержимому, пользуйтесь этой возможностью.
4. Где же разместить файл с иконкой сайта? Для надежности просто положите его в корневую директорию вашего сайта.

Грабли.

1. Как указал выше, IE lt 6.0 не понимает иконок, превышающих 16х16 пикселей.
2. IE 6.0 и ниже отобразит иконку только после добавления странички в избранное и перезагрузки. Ну любит MS перезагружать все и вся ;-).
3. Если IE 6.0 и ниже и после этого не отобразит ее, то попробуйте почистить кэш браузера.
4. Если и после этого иконка не появится там, где ей положено быть необходимо удостовериться, что ваш сервер передает иконку в браузер и отображает ее, а не передает, как файл и предлагает вам его сохранить. Это проверяется простым путем ввода в браузер адреса вашего сайта и имени иконки, например http://yoursite.com/favicon.ico, при условии конечно, что иконка лежит в корневой директории. Во втором случае ваш сервер не настроен на отображение файлов .ico. Для того чтобы исправить эту ситуацию вам необходимо создать в корне сайта файл .htaccess и добавить в него следующую строку AddType image/x-icon .ico .

Ссылки по теме:

1. Как добавить собственную иконку сайта в адресную строку и в закладки браузера?
2. Favicon - иконка в адресной строке.
3. Ð?конка в адресной строке.
4. favicon.ru - favicon.ico generator and editor.

Во времена “младенчества” сети Интернет, ему многое прощалось: отсутствие качественного оформления документа, отсутствие эргономики интерфейсов, некорректность по ряду причин программного кода языков и многое другое. Было это потому, что сам Интернет был неким ноу-хау, если хотите, и распространялся по принципу “как есть”. Это была эпоха Веб 1.0, как его позже назовут. Сегодня же мы с вами являемся современниками Веба, который с легкой руки Тима О’Рейли получил название Веб 2.0, что означает выход на новый качественный уровень, когда в вебразработку приходят профессионалы, которые не рисуют мышкой, заботятся об удобстве использования своего продукта, отвечают за корректность каждой строчки кода и за его безопасность. Работы этих специалистов говорят сами за себя. Это люди, которые понимают и принимают весь груз ответственности за то, каким Веб станет после них.

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

HTML является потомком языка разметки чисто теоретического, академического, если хотите, SGML. В свое время именно он был выбран в качестве основы нового языка гипертекстовых документов для сети Интернет. В своей первой редакции HTML четко следовал философии SGML, т.е. чисто логическому форматированию данных. Из чуть более 40 тэгов в версии 1.2 он включал в себя всего 3, которые можно было причислить к стилистическим. Необходимо отметить, что это было вполне оправдано даже с чисто практической точки зрения, т.к. в те времена господствовали текстовые браузеры, а первым и единственным графическим стал NCSA Mosaic. Однако, после продажи Mosaic компании Microsoft, на рынок вышли новые продукты, поддерживающие графический контент, как от самого гиганта из Редмонда, так и от сторонних производителей. И естественным желанием для разработчика стало применение графических элементов, для оформления своего документа. Однако в первое время отсутствие какого-либо языка стилистического оформления, а затем, с появлением оного (CSS), его слабая поддержка, породили множество оформительских тэгов в самом HTML. Причем как стараниями самого w3c, организации, занимающейся разработкой рекомендаций и стандартов в сети Интернет, так и разработчиков браузеров.

Последней утвержденной и опубликованной версией HTML стала HTML 4.01 от 24.12.1999, которая в своей версии Strict сделала первый шаг к порядку в коде, отменив множество стилистических тэгов и их атрибутов, предложив вместо них воспользоваться соответствующими возможностями специально созданного для этого языка CSS. На момент публикования последней спецификации HTML уже прочно стоял на ногах мощный, фактический неограниченный язык XML. И, судя по всему, заглядывая в светлое и идеальное будущее, в w3c решили, что именно XML и станет кросплатформенным стандартом обмена данными, который откроет возможность совместного использования с другими языками XML и позволит привести в порядок сам HTML, ликвидировав его устаревшие элементы и расширив функциональность. Первым шагом к этому стало создание промежуточного языка – XHTML. Итак, 12 мая 1998 года параллельно с работой над соверÑ?енствованием HTML была опубликована первая редакция XHTML.

Что же он из себя представляет? XHTML это гипертекстовый язык разметки документов, являющийся подмножеством XML и соответствующий спецификации SGML, т.е. фактически это HTML, переформулированный в синтаксисе XML. Язык был избавлен от, все еще остававшихся в HTML, оформительских средств. Фактически все вернулось на круги своя. Целью языка разметки XHTML стало описание структуры документов, а на CSS была возложена роль, полностью взять на себя представление внеÑ?него вида гипертекстовых документов.

Сегодня об XHTML можно говорить, как о становящимся, наконец, на ноги семействе языков разметки гипертекста. XHTML это шаг к эволюционному развитию Ð?нтернет и переходу к чистому XML, при сохранении обратной совместимости документов для устаревÑ?их типов пользовательских агентов. Текущей опубликованной версией является XHTML 1.1 от 16 февраля 2007 года.

XHTML является преемником HTML и обладает рядом закономерных преимуществ перед ним. Так почему же стоит его применять на практике?

1. XHTML является текущим опубликованным стандартом разметки гипертекста, заменившим HTML и рекомендованным к повсеместному использованию.
2. XHTML является более последовательным и строгим языком, чем HTML, применение его снижает вероятность возникновения ошибок в коде, повышая, таким образом, общее качество гипертекстового документа и уровень вебразработок в целом.
3. XHTML, за счет строгого синтаксиса, разбирается парсером пользовательского агента проще и быстрее, в отличие от HTML, что позволяет осуществить его обработку на устройствах с малыми вычислительными ресурсами.
4. XHTML является подмножеством языка XML, который позволяет уже сейчас значительно расширить возможности работы с документами посредством применения таких технологий, как XSLT, SVG, MathML, RSS, VoiceXML, Web3D, RDF/XML, XMP, XUL, SOAP, Ajax и Jabber/XMPP). В будущем же он позволит использовать все новые, возможно, пока еще неизобретенные или неутвержденные XML-технологии.
5. XHTML позволяет правильно и полноценно использовать приложения (например, скрипты и апплеты), относящиеся к Document Object Model.
6. XHTML открывают путь в мир метаданных, что, можно утверждать с большой долей вероятности, позволят в будущем поисковым маÑ?инам более корректно и точно обрабатывать данные в XHTML документах (читай страницах сайта). Сейчас это уже стало реальностью в виде микроформатов.

Важно отметить, что XHTML корректно обрабатывается старыми браузерами, что уменьшает препятствия к его применению на практике.

XHTML это правильный способ публикации гипертекстовых документов в сети, это то, к чему приÑ?ли разработчики вебстандартов, основываясь на опыте последних 15 лет существования сети Интернет. И самая главная причина применения текущих стандартов на практике состоит в том, что ваш документ гарантированно будет доступен и через 10 и через 20 лет, благодаря строгому следованию стандарту.

Вместо заключения. Следует отметить, что сегодня параллельно ведутся работы над следующей версией языков гипертекстовой разметки документов (X)HTML5 и XHTML2, однако это тема большой отдельной статьи, так что про перспективы каждого мы поговорим в следующий раз.

Ссылки по теме:

1. Что такое XHTML? http://www.itstan.ru/content/view/2661/2344/
2. Золотой век http://www.itstan.ru/content/view/2654/2337/
3. http://ru.wikipedia.org/wiki/Xhtml
4. Настоящий XHTML или пока не стоит? http://cssing.org.ua/2005/02/25/xhtml-worth-or-not/
5. Оценка XHTML http://www.webmasterpro.com.ua/news333.html
6. Преимущества XHTML http://www.itstan.ru/content/view/2665/2349/
7. Ответы на часто задаваемые вопросы по XHTML и HTML http://www.w3.org/2006/06/xhtml-faq-ru.html