Zeldman dzheffri web dizain po standartam by Ирина Коваль

Джеффри Зельдман

Web-дизайн по стандартам Школа Web-мастерства

NT Press Москва, 2005

УДК 004.738.5 ББК 32.973.26-018.2 3-48 Подписано в печать 20.05.2005. Формат 70x90/16. Гарнитура "Баскервиль". Печать офсетная. Усл. печ. л. 31,9. Тираж 5000 экз. Зак. № 5566. Зельдман Д. 3-48 Web-дизайн по стандартам / Джеффри Зельдман ; Пер. с англ. Г. П. Ковалева. - М. : НТ Пресс, 2005. - 440 с. : ил. - (Школа Web-мастерства). ISBN 5-477-00106-2 Автор книги - Джеффри Зельдман - последовательно и целенаправленно ведет читателя к пониманию необходимости перехода к Web-стандартам. Издание описывает все основные технологии, необходимые для быстрого и эффективного перевода сайта на новый уровень, - XHTML, CSS, XML. Вы научитесь создавать красивые сайты, которые будут доступны пользователям как альтернативных браузеров, так и мобильных устройств. Книга заставит вас иначе взглянуть на Webдизайн в частности и Интернет в целом; покажет, что будущее за стандартами W3C. Издание предназначено для дизайнеров, разработчиков, владельцев и менеджеров сайтов, желающих снизить затраты, повысить работоспособность сайтов и охватить более широкий круг пользователей. Authorized translation from the English language edition, entitled DESIGNING WITH WEB STANDARDS, 1st Edition, ISBN 0735712018, by ZELDMAN, JEFFREY, published by Pearson Education, Inc, publishing as New Riders, Copyright © 2004. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. RUSSIAN language edition published by NT PUBLISHING HOUSE, Copyright © 2005.

УДК 004.738.5 ББК 32.973.26-018.2 Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельца авторских прав. Материал, изложенный в данной книге, многократно проверен. Но, поскольку вероятность технических ошибок все равно остается, издательство не может гарантировать абсолютную точность и правильность приводимых сведений. В связи с этим издательство не несет ответственности за возможный ущерб любого вида, связанный с применением содержащихся здесь сведений.

ISBN 0-7357-1201-8 (англ.) ISBN 5-477-00106-2 (рус.)

Оглавление Введение

;

ЧАСТЬ I. Хьюстон, у нас проблемы

Перед тем как начать

Глава 1- 9 9 , 9 % сайтов устарели Современные браузеры и Web-стандарты Новый код для новой работы Проблема версий Устаревшее мышление Устаревшая разметка: платят владельцы сайтов Обратная совместимость Блокировка доступа пользователей к сайту плохо влияет на бизнес Дорога в город дураков Как написать код для сайта Когда с плохим кодом происходят хорошие вещи Плохой код может быть опасен для «жизни» вашего сайта Решение всех проблем

37 38 38 40 41 45 47 48 51 53 54 56 56

Глава 2. Разработка и дизайн по стандартам Через тернии к звездам Цена дизайна до появления стандартов Современный сайт и устаревшие методы Три кита Web-стандартов Структура Внешний вид Поведение В действии Преимущества переходной модели Web Standards Project: совместимость в действии Один документ для всех A List Apart: одна страница, много видов Дизайн за пределами экрана Экономия времени и расходов, рост аудитории Куда двигаться дальше? Переходная модель совместимости Строгая совместимость

58 59 60 62 66 66 68 69 69 70 73 75 77 80 82 82 83 85

•

6 88 88

Глава 3- Неприятности со стандартами Красивый сайт, ужасный код

Общие цели - общие средства .. Восприятие против реальности 2000: год появления новых браузеров IE 5/Мас: переключение и увеличение Смелый шаг Netscape Путь открыт Слишком мало, слишком поздно? CSS: первый сбой бесплатно Плохие браузеры - плохие сайты Проклятие устаревшего отображения Наследование Поведение Время стандартных скриптов пришло Сбивающие с т о л к у сайты и ставящие в тупик названия Академичность против экономики Консорциум предполагает, компании предлагают Результат против стандартов Слова на букву «F» Ценность Flash Проблема Flash Другие проблемы с Flash Плохое слово «совместимость» Сила языка влияет на восприятие Проблема вдохновения Другие проблемы

Глава 4. XML завоевывает мир Универсальный языкХМ!_

89 90 93 '.. 93 95 96 99 99 100 101 102 103 104 104 106 106 107 110 110 113 114 114 115 115 117

118 118

Сравнение XML и HTML 119 Дети одного родителя 119 Необходимая составляющая профессионального и потребительского ПО .... 121 Более популярно, чем MTV 123 Пять причин популярности XML 126 Неисчерпаемый кладезь изобретений 126 Средства Web-публикации 128 К вашим услугам 130 ХМL-приложения и ваш сайт 131 Все еще в яслях 132 Совместимость от рождения 132 Новая эра сотрудничества 133 Тестовая среда и спецификации 134

Создание тестовой среды Web-стандарты и средства авторской разработки Группа специалистов по Dreamweaver Визуальные редакторы: два из трех не так уж и плохи FrontPage: несовместимость от природы Появление разметки CSS Кампания за обновление браузеров Начало потопа Бесконечные преобразования М э й н с т р и м Web-стандартов Коммерческие сайты принимают вызов Преобразования Wired Digital Внедрение стандартов с помощью переходных методов W3C вступает в игру Выводы ЧАСТЬ I I . Д и з а й н и р а з р а б о т к а

Глава 5. Современный код Тайный позор плохого кода Переформулировка Выводы Какой XHTML подходит вам 10 главных причин перехода на XHTML 5 главных причин не переходить на XHTML Глава 6. X H T M L : р е с т р у к т у р и з а ц и я С е т и Преобразование в XHTML: простые правила, легкое руководство Точный D O C T Y P E M пространство имен Укажите кодировку страницы Пишите все теги в нижнем регистре Заключайте в кавычки все значения атрибутов Все атрибуты должны иметь значения Закрывайте все теги «Пустые» теги тоже нужно закрывать ,. Не используйте двойное тире в комментариях Кодируйте все символы < и & Выводы: правила XHTML Кодировка: глупо, по-настоящему глупо Unicode и другие кодировки Структурное исцеление Создание кода с учетом логики, а не стиля

134 136 136 138 138 139 139 143 143 148 151 151 156 156 157 159 161 164 166 167 169 170 171 172 172 173 175 177 178 180 180 181 181 182 183 183 183 184 185

ШеЬ-дизайн по стандартам

Цвет внутри границ Визуальные элементы и структура

185 188

Глава 7. Структура и метаструктура в строгой и смешанной разметке Должен ли каждый элемент быть структурным?

190 190

Глава 8. X H T M L в примерах: с м е ш а н н а я р а з м е т к а Преимущества переходного подхода Таблицы стилей вместо JavaScript Основной подход: обзор Раздельные таблицы: CSS и доступность Пропустить навигацию: каки почему Дополнительные атрибуты Id Первый и последний вариант кода Код навигации - первая таблица Оформление, семантика, чистота стандартов и ошибка Добавим контент- вторая таблица

213 213 214 215 216 217 221 222 223 224 225

Глава 9. Основы CSS Обзор CSS Преимущества CSS Анатомия стилей

227 227 228 229

div, id и другие помощники Попробуйте делать меньше Смешанная разметка и компактный к о д - з а и против Плохая практика Распространенные ошибки смешанной разметки В div нет ничего плохого Любовь к id Прочь лишние ячейки таблицы Парад устаревших приемов Карты изображений Фигурная нарезка В защиту табличной разметки навигационного меню Излишнее многословие В Сети появился плохой CSS Движемся дальше

Селекторы, описания, свойства и значения Множественные описания Пробелы и регистр Альтернативные и общие значения Сгруппированные селекторы Наследование и его недостатки Контекстные (наследуемые) селекторы

192 195 197 198 198 202 203 204 206 206 208 209 209 210 212

229 230 231 231 232 233 234

Оглавление Селекторы id и контекстные селекторы id Селекторы класса Сочетание селекторов для задания эффектов Внешний, вложенный или последовательный стиль Внешние таблицы стилей Последовательный стиль ...: Дизайн по методу «идеальных условий» От вложенной к внешней таблице стилей: метод двух таблиц Относительные и абсолютные ссылки на файл Преимущества двух стилей и разработки для «идеальных условий»

235 237 238 241 241 244 244 245 246 246

247 247 249

Глава 10. CSS в действии: смешанная разметка Подготовка изображений Установка основных параметров

Общий стиль Классы Hide и Block Цвета ссылок. Вводим псевдоклассы Описание других общих элементов , Еще немного о размерах шрифтов „. Установка разделов страницы Элементы навигации: первая редакция Панель навигации на CSS: второй подход, первая попытка Панель навигации CSS: окончательный подход Окончательные штрихи: внешние стили и эффект «Вы находитесь здесь»

250 251 252 254 256 258 261 264 265 266

Глава 1 1 . Переключение DOCTYPE и п о д д е р ж к а стандартов.... Сага о переключении DOCTYPE Переключатель для включения и выключения стандартов Появление переключателя DOCTYPE в браузерах Управление браузером: переключатель DOCTYPE Три режима для сестры Сары Полные и неполные DOCTYPE Список полных XHTML DOCTYPE Да здравствует разнообразие браузеров! Пробелы вокруг изображений в Gecko От «Да здравствует разнообразие!» до «@#$! Это $#@$»

270 271 272 272 273 274 274 276 278 279 283

Глава 1 2 . Блочная м о д е л ь , о ш и б к и б р а у з е р о в и обходные пути Блочная модель и ее недостатки Как работает блочная модель Разрушение блочной модели Трюки с блочной моделью Дефектный пробел в IE/Windows

284 284 286 287 294 296

ШеЬнцшайн по стандартам

Ошибка свойства float в IE6/Windows Ступор в старых значениях Скрипт - решение проблемы Flash и QuickTime: объекты преклонения Вложенные объекты: история о высокомерии и мести Палка о двух концах: объекты мультимедиа при поддержке стандартов Ложка дегтя: сбой объектов Повседневный мир обходных путей

Глава 13. Оформление текста Размер имеет значение Пользовательский контроль Кошмары устаревшего подхода Различия во взглядах Наконец стандартный размер - надолго ли? Хорошая работа загублена одним щелчком Забвение: неправильная реакция на изменения в браузерах Chimera и Safari: отличная производительность, проблемы с размером Беда с единицами ems Пользовательский выбор и единицы ems Пиксель Самая маленькая единица: абсолютно относительная Неприятности с пикселями Ключевые слова размера шрифта Чем ключевые слова лучше ems или процентов Изначальная проблема с использованием ключевых слов Ключевые слова: метод Фарнера Удобный способ: поиски продолжаются

Глава 14. Основы доступности О доступности в книгах Распространенные заблуждения

Слепой миллиардер Доступность не ограничена лишь плохим зрением Туманные идеи Закон и разметка Section 508 Разоблачение мифов доступности Миф 1: для доступности вам необходимо создавать две версии сайта Миф 2: текстовые версии отвечают требованиям доступности Миф 3: доступность слишком дорого стоит Миф 4: доступность заставляет создавать примитивные сайты с простым дизайном Миф 5: все сайты должны выглядеть одинаково во всех браузерах и устройствах

300 301 301 302 303 304 305 308

310 310 310 311 312 313 316 '316 318 321 322 326 326 330 333 333 334 335 337

338 339 340

340 341 '.341 343 343 345 345 346 346 349 349

.пые Миф 6: доступность нужна только людям с ограниченными возможностями Миф 7: Dreamweaver MX /Watchfire's Bobby может решить вопрос доступности Миф 8: дизайнер может игнорировать требования доступности, если клиент не возражает Советы по повышению доступности, элемент за элементом Изображения QuickTime и другие потоковые медиаобъекты Macromedia Flash 4/5 Macromedia Flash MX 1 Цвет

CSS

Эффекты при наведении указателя мыши и другие скрипты Формы Карта изображений Табличная разметка Таблицы, используемые для данных Фреймы, апплеты Мигающие или мерцающие элементы Сопутствующие средства Работа с Bobby Анализ отчета Табуляция: наш хороший друг атрибут tabindex Планирование доступности: ваши дивиденды....;.... Доступность у вас на службе

Глава 15. Работа со скриптами на основе DOM Знакомство с DOM

350 350 351 352 352 354 355 355 357

357

360 362 362 362 363 363 363 363 365 365 366 371 371

373 373

Стандартный способ заставить Web-страницы вести себя как приложения ... 374 Где это работает 377 Несовместимая с DOM среда 377 Подробнее о DOM 378 Пожалуйста, DOM, не обижай браузеры 380 Суть DOM-модели 381 Упрощение динамических сайтов: для курящих и некурящих 382 Варианты кода 382 Зачем нужна DOM-модель 38J3 Преимущества 383 Недостатки 383 Отображение и сокрытие контента 384 Сочетание приема показать/спрятать с другими методами 387 Динамические меню 389 Переключатели стилей: доступность и выбор 390 Еще больше о DOM 394

Web-дизайн ш> стандартам

Глава 1 6 . CSS-редизайн Определение целей 10 важнейших задач Методы и безумие Установка основных параметров Настройка боковой панели Расположение Создание цветных панелей Пространство для контента * Правила в основе дизайна Кнопка На главную страницу и CSS-эффекты Замена изображения поФарнеру Дополнительные способы применения метода Фарнера Панель навигации CSS/XHTML Добавляем стиль Завершение работы

395 395 396 398 400 402 403 405 406 408 410 411 413 416 417 422

Приложение. Современные браузеры

427

Предметный указатель

432

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

Один размер для всех? Мы рассмотрим некоторые способы решения распространенных проблем дизайна с помощью стандартов. Конечно, мы не можем описать все трудности и их решения. Ведь другие разработчики могут иметь совершенно иную точку зрения на обсуждаемые вопросы. Наша книга нацелена на решение практических и неотложных задач с учетом завтрашнего дня. Описанные в книге приемы и идеи были опробованы в моем дизайнерском и консалтинговом агентстве и были признаны достаточно полезными и использованы при создании тысяч сайтов, ориентированных на будущее. Понятно, что не каждый пользователь немедленно начнет использовать все предложения, содержащиеся в книге. Если вы любите таблицы, возможно, вас не заинтересует глава 16. Если вы хотите, чтобы ваш сайт хорошо смотрелся в

ШеЬ-дазайн не стандартам

браузерах версии 4.0, вас заинтересуют главы 8-10, а обсуждение работы чистых приемов CSS, приведенное в главе 16, вы сможете пропустить. Однако любой думающий дизайнер, разработчик или владелец сайта одобрит и оценит общие положения, приведенные в книге. Стандарты жизненно важны. Так как программное обеспечение, с помощью которого пользователи просматривают сайты, наконец-то стало поддерживать стандарты, есть смысл узнать о них больше и правильно использовать их. Таким образом, можно сэкономить время и деньги, уменьшить расходы и предоставить более удобный доступ к содержимому сайта. Последнее особенно важно для всех, кто хочет охватить более широкую аудиторию. Важно помнить, что нетрадиционные способы доступа в Internet становятся все более популярными. Кроме того, все больше стран и штатов в США принимают требования к доступности в отображении сайтов на различных устройствах и платформах, а также доступности восприятия содержимого сайта различными категориями посетителей (дети, люди с ограниченными физическими возможностями и т.д.). Web-стандарты помогут вашему сайту придерживаться данных положений.

Теория против практики Однако некоторые приемы и идеи, описанные в нашей книге, можно оспорить. Если вы - ярый приверженец стандартов, вы можете не захотеть использовать XHTML, пока все браузеры не начнут поддерживать отправку документов XHTML в виде application/xhtml, а не text/html. Более подробно этот вопрос рассмотрен в работе Яна Хиксона (Ian Hickson) "Sending XHTML as Text/ HTML Considered Harmful" (http://www.hixie.ch/advocacy/xhtml). Если вы разделяете точку зрения Яна, возможно, пока вы захотите использовать HTML4.01, либо настроить Web-сервер на отправку данных в виде application/xhtml+xml браузерам, распознающим их, и text/html - остальным браузерам (http://lists.w3.org/Archives/Public/www-archive/2002Dec/0005.html). В данной книге я избежал обсуждения подобных моментов, так как стараюсь выполнить поставленную задачу с учетом современных условий и полагаю, что большинство читателей думают точно так же.

Смешанная разметка: готовиться к выходу? Более того, некоторые сторонники технологии CSS (Cascading Style Sheets - каскадные таблицы стилей) могут проигнорировать идею смешанной разметки CSS/таблица. Способы использования смешанной разметки (главы 8-10) приводятся в книге для тех, кто намерен использовать их. Они могут заинтересовать

Введение

дизайнеров, чьи работы должны выглядеть одинаково хорошо как в старых, так и в новых версиях браузеров. Однако эти приемы могут просуществовать совсем недолго. Пока я писал эту страницу, ESPN.com был обновлен уже с использованием разметки CSS (рис. 1). Число посетителей этого спортивного сайта ежедневно составляет десять миллионов. Когда такой большой коммерческий сайт принимает на вооружение CSS, становится очевидно, что торжество Web-стандартов неминуемо. Несмотря на то что изначально использование стандартов на сайте было далеко от идеала, вот что арт-директор Майк Дэвидсон и его команда сделали правильно:

Web-дизайн по стандартам

• все элементы страницы размещены с помощью CSS. На сайте не используются таблицы, кроме как в элементах, размещаемых спонсорами, на которые команда дизайнеров не в силах повлиять; • исключено использование тегов форматирования шрифта; • пропускная способность. Размер кода главной страницы уменьшился вдвое, в то время как контента на странице только прибавилось. (При использовании приемов, описанных в главах 5-9, можно добиться еще более значительного сокращения кода.); • использована одна таблица стилей для всех браузеров, нет необходимости в определении типа браузера. Сайт выглядит практически одинаково во всех браузерах, поддерживающих метод getElementByld, включая браузер Safari для компьютеров Apple. Благодаря использованию приемов, описанных в нашей книге, ESPN.com добился значительных преимуществ и позволил посетителям сэкономить на входящем трафике, так как код сайта стал более компактным. Однако первое воплощение сайта в CSS имеет некоторые недочеты, которые можно исправить, используя идеи, изложенные в нашей книге (которая все же еще не была опубликована на тот момент). Сайт использует зачастую ненужное определение типа браузера, код содержит некоторые ошибки. Необходимо повысить доступность кода и сделать CSS-разметку более логичной и компактной. К тому времени, когда вы будете читать эту книгу, возможно, ESPN.com устранит некоторые или все эти ошибки. Но, даже если это и не будет сделано, зададимся вопросом - стакан наполовину пустой или наполовину полный? Несомненно, что за ESPN.com последуют менее известные и крупные сайты. Когда сайт, который посещает 10 млн. человек в день, переходит на использование разметки CSS, это знаменует победу стандартов в Web-дизайне и методах разработки сайтов. За неделю до перерождения ESPN.com сменил технологию разметки сайт Netscape DevEdge (рис. 2), превратившийся в образец использования стандартов. На этом сайте всегда можно было найти много информации о развитии Internet, включая руководства по использованию стандартов, однако конструкция сайта противоречила его содержимому. После изменения дизайна с учетом стандартов, сайт, последовавший своим собственным советам, превратился в образец для подражания. Теперь сайт обладает CSS-разметкой без таблиц; выпадающими меню, созданными по стандартам; ссылками URL, которые выводятся с помощью свойств CSS в наиболее удобном для пользователя стиле.

Введение

Континуум, а не набор незыблемых правил Мы подчеркиваем, что Web-стандарты непрерывно развиваются и не являются сводом незыблемых правил. Начав использовать Web-стандарты, вы, возможно, не достигнете идеального отделения структуры от представления (см. главу 2) в ваших первых работах. Первые попытки повысить доступность сайта (см. главу 14) могут привести вас лишь к достижению минимальных требований стандарта WAI Priority I (Web Accessibility Initiative от W3C).

Well-дизайн mm стандартам

Однако главное - начать. Страх несовершенства может парализовать вас, так же как лишний вес мешает нам пойти в спортзал. Но мы не можем приобрести хорошую форму, пока не начнем заниматься фитнесом. Так же и наши сайты не будут совместимы с новыми требованиями, если мы не начнем хоть с чего-то. Первым шагом может стать простое удаление тегов форматирования шрифта. Или можно начать с разбиения неструктурированного кода на логичные теги <h...> и <р>. Это может стать отличным началом, а с помощью нашей книги вы получите более полные сведения о современных технологиях разметки и стандарте XHTML.

Показывайте, не продавайте Иногда дизайнеры сталкиваются с трудностями коммерческого применения стандартов. На протяжении нескольких лет я получил сотни писем от дизайнеров, которые хотят использовать стандарты, «но клиент не позволяет». Если стандарты представляют собой континуум, как клиент может возражать против попыток использовать их? Например, даже сайт с очень большим количеством таблиц можно преобразовать в HTML4.01 или XHTML1.0 Transitional и сделать его отвечающим требованиям доступности US Section 508 или WAI Priority 1. Какой клиент будет возражать против доступного сайта, не содержащего ошибок? То, что многие дизайнеры обеспокоены коммерческой стороной использования стандартов, на самом деле говорит о том, что они просто не могут использовать их настолько, насколько это возможно. Например, они не могут использовать CSS-разметку для определенного сайта, так как заказчик (или начальник) использует Netscape 4, в лучшем случае с установленным обновлением для поддержки CSS. Возможно, это так, но это не повод для отказа от корректной CSS-разметки или использования других методов, описанных в главе 9, чтобы создать сайт, одинаково хорошо отображаемый в разных поколениях браузеров. Сотудники моего агентства серьезно и благовейно относятся к Web-стандартам и доступности, но не к приемам, которые применяются для достижения некоего «абсолютного стандарта». Мы используем способ, который наиболее подходит для выполнения данного проекта. Чтобы продать его, у нас есть два приема. В нашем предложении выполнения проекта мы явно указываем технологию, которая будет использована, описывая ее просто и прямолинейно. Например: «будет использован стандарт XHTML 1.0 Transitional». После того как клиент подписал договор и таким образом разрешил использовать данную технологию, никаких проблем не возникает. Если использование выбранной

Введение

технологии негативно повлияет на отображение сайта в старых версиях браузеров, это также четко указывается в договоре. При дальнейшей работе, когда мы показываем клиенту проект на различных стадиях выполнения, мы сводим обсуждение технических деталей к минимуму, даже если заказчик и неплохо разбирается в этом вопросе. Когда мы после изменения показываем клиенту сайт, размер кода которого заметно сократился и при этом форматирование стало более насыщенным и устойчивым к частым обновлениям, мы не говорим: «Это стало возможно благодаря технологии CSS». Мы говорим, что «мы создали систему, сохраняющую форматирование и при этом обеспечивающую низкую нагрузку на канал связи». Если при этом заказчик подумает, что мы умные ребята и доверит нам выполнение других проектов, мы не обидимся.

Пусть ваша работа продает себя сама Когда компании Hillman Curtis Inc. и Happy Cog совместно работали над редизайном сайта Fox Searchlights Pictures, в роли заказчика выступал довольно опытный Web-дизайнер и разработчик. Тем не менее некоторые приемы смешанной разметки CSS/таблица, которые мы использовали, были незнакомы ему. «Сайт так быстро загружается», - постоянно повторял он. В конце работы мы включили описание стилей в руководство по технической стороне редизайна, но к тому времени уже не было необходимости пытаться продать нашу работу, так как она говорила сама за себя. По мере того как вы будете становиться известными благодаря подобной работе, клиенты будут сами обращаться именно к вам, и вам останется прикладывать все меньшие усилия, чтобы продать свой труд. Хотя в Happy Cog скептически относятся к применению смешанной разметки вместо чистой разметки CSS, все мои персональные сайты и все увеличивающееся число мелких сайтов моего агентства выполнены с использованием разметки CSS. Мы также считаем, что некоторую исследовательскую работу дизайнеру легче выполнять, используя CSS, а не Photoshop. Один из последних наших проектов для Clear Channel Entertainment требовал предоставить несколько вариантов дизайна, как это обычно бывает на начальной стадии проекта. «Кстати говоря, это разметка CSS», - сообщили мы клиенту. «Я знаю», - ответил он. По мере того как использование подобных приемов становится все более распространенным (не без помощи крупных коммерческих - ESPN.com, DevEdge, Wired.com - и правительственных сайтов, что описано в главе 4), эти технологии постепенно начинают использовать по

Web-дизайн по стандарта!»

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

Продажа внутри компании Я показал вам, как обстоят дела в частном Web-агентстве, но на самом деле то же самое происходит и внутри компаний. Постарайтесь избежать бесполезных обсуждений возможностей браузеров и других устаревших вопросов. Лучше выберите подходящие средства, коротко опишите их в документации, покажите начальству и приступайте к работе. За два года до написания этой книги я читал лекции для группы разработчиков в одной крупной правительственной организации. Слушатели интересовались Web-стандартами, но внутри организации все пользовались устаревшей версией браузера, не поддерживающей современные стандарты, в связи с чем некоторые разработчики полагали, что использовать стандарты на внутреннем уровне будет довольно затруднительно. (Эти предположения были безосновательны. Запомните: Web-стандарты - это континуум.) Во время работы над введением для данной книги я вновь посетил эту организацию и заметил некоторые перемены. Теперь на большинстве компьютеров был установлен Netscape 7. Некоторые продолжали использовать Netscape 4, так как определенные приложения, используемые внутри организации, были написаны с использованием document. l a y e r s модели DHTML от Netscape. Но на лекциях разработчики горячо обсуждали возможность переноса существующих приложений на модель W3C DOM.

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

Введение

структурированная разметка, представляют собой гораздо больше, чем можно описать в этой книге или в любом другом руководстве. И, как мы уже отмечали, на все описанные в книге вопросы могут существовать точки зрения, отличающиеся от авторской. Оставьте двух дизайнеров наедине, и вы услышите три разных мнения. Вряд ли можно найти двух Web-дизайнеров, разделяющих одинаковое мнение относительно типографии, навигации, логотипов или цветов. Это же относится и к стандартам. Сколько существует практиков и теоретиков, столько же возникает и разногласий по данному вопросу. Ни одна книга не может донести исчерпывающие сведения до всех читателей, и наша книга служит лишь указателем для вас. Она исполнит свой долг, если поможет вам понять, как можно использовать стандарты для создания сайтов с учетом Web-технологий будущего, и даст несколько практических советов. Я заинтересовался Web-стандартами, имея за плечами трехлетний опыт создания сайтов старым, дедовским способом, и мне потребовалось еще пять лет, чтобы понять то, о чем эта книга. Вы можете не согласиться с тем или иным утверждением, приведенным в книге. Более того, я сам могу не согласиться с некоторыми утверждениями через год или два после выхода книги. Главное не отрицать сути из-за несогласия с некоторыми частностями. Главное - начать делать изменения, которые помогут вам создать сайты, доступные большей аудитории, которые проживут дольше и обойдутся вам гораздо дешевле. Если не сейчас, то когда? Если не вы, то кто?

Отзывы читателей «Руководство Зельдмана станет мудрым и полезным компаньоном для дизайнеров и программистов. В книге подробно изучаются механизмы искусства Webдизайна, а результаты являются своего рода Розеттой Стоун в Web-дизайне» (Дон Бакли, старший вице-президент отдела интерактивного маркетинга WARNER BROS. PICTURES). «Я знаю и уважаю Джеффри Зельдмана еще с тех пор, как он участвовал в создании проекта Web Standards. Зельдман объединяет в себе страсть и прагматизм относительно поддержки стандартов Web-дизайна. Начинающим и опытным Web-дизайнерам, несомненно, пригодится эта книга как при создании сайта с нуля, так и при его реконструкции» (Карл Дюбост, менеджер отдела контроля качества, W3C). «Теперь цель моей жизни - устранение несовершенного кода и создание для себя и моих клиентов Web-сайтов, ориентированных на будущее. Без сомнения,

Web-дизайн mm стандарта»)

идеи, приведенные в этой книге, помогут мне повысить качество своей работы и удержаться на рынке. Данная книга является отличным руководством для понимания и применения Web-стандартов» (Чэд Брэндт, менеджер Web-службы Best Software). «Многие мои коллеги страдают от недостатка информации по данному вопросу. Автору удалось изложить суть вопроса простым и понятным языком, без сухих и скучных фраз» (Джен ДеХаан, Web-дизайнер и автор). «Эта книга - это настоящая бомба, как раз то, что мы ждем от Зельдмана. Она затрагивает все вопросы, рано или поздно возникавшие у нас, и дает нам возможность ответить на них. Это руководство и настольная книга для создателей вечного кода» (Кэти Келлер, Texas Parks and Wildlife Communications Web Group).

anne

Об авторе Джеффри Зельдман - один из наиболее известных Web-дизайнеров в мире. Его личный сайт (www.zeldman.com) посетило более шестнадцати миллионов пользователей, ежедневно к нему обращаются тысячи Web-дизайнеров и разработчиков. Он является издателем и креативным директором Internet-журнала A List Apart (www.alistapart.com), ориентированного на создателей Web-сайтов, а также основателем Happy Cog (www.happycog.com) - дизайнерского и консалтингового агентства, клиентами которого являются такие учреждения, как Clear Channel Entertainment, Warner Bros. Pictures, Fox Searchlight Pictures и Общественная библиотека Нью-Йорка. В 1998 году он стал одним из основателей проекта Web Standards (www.Webstandards.com), сообщества Web-дизайнеров и разработчиков, которое помогло прекратить «войну браузеров», убедив Microsoft и Netscape обеспечить поддержку одинаковых технологий в своих браузерах. Джеффри - автор книги "Taking Your Talent to the Web" (New Riders: 2001) и многочисленных статей для A List Apart, Adobe, Creativity, Digital Web, Macworld, PDN-Pix и других сайтов и печатных изданий. Он был членом жюри на Communication Arts Interactive Festival, Art Directors Club of New York, 5K, Addy Awards и Radio Mercury Awards, а также является членом совета конференций Meet the Makers и i3Forum. Он читал лекции в таких заведениях, как American Institute of Graphic Arts (AIGA), Columbia University Libraries, Los Alamos National Laboratories, New York Public Library, Public Library Association, New York State Forum for Information Resource Management, также выступал на различных конференциях, включая Builder, CMP, Seybold, SXSW Interactive, Web Design World и Web visions. Но своим настоящим призванием он считает обучение.

Технические консультанты Наши консультанты, благодаря своему большому опыту практической работы, внесли значительный вклад в создание данной книги. По мере написания книги они проверяли достоверность содержания книги и ее оформление. Комментарии этих специалистов помогли нам убедиться в том, что данная книга отвечает запросам читателей и содержит технические сведения высочайшего качества. . Эрик А. Майер (Eric A. Meyer) работает в сфере Web-дизайна с 1993 года. В настоящее время он работает в компании Netscape Communications в качестве

Web-дизайн по стандарта»!

специалиста по стандартам, живет в городе Кливленд, штат Огайо. Признанный специалист в данной области, Эрик часто выступает на различных конференциях с докладами и лекциями, посвященными Web-стандартам, совместимости с различными видами браузеров, CSS и Web-дизайну. Эрик является выпускником и бывшим Web-дизайнером Case Western Reserve University. В W3C он работал над созданием CSS I Test Suite и постоянно расширяет границы дизайна, основанного на CSS. Эрик является автором книг "Eric Meyer on CSS: Mastering the Language of Web Design" (New Riders), "Cascading Style Sheets: The Definitive Guide" (O'Reilly & Associate), "CSS 2.0 Programmer's Reference" (Osborne's McGraw-Hill) и известных таблиц по CSS-совместимости браузеров. Дж. Дэвид Эйзенберг (J. David Eisenderg)-живет в Сан-Хосе, штат Калифорния, со своими кошками Марко и Зои. Он преподает HTML, XML, Perl и JavaScript, а также с удовольствием пишет обучающие программы и онлайн-руководства.

Введение

Благодарности Эту книгу написал я, но направляли меня многие люди. Я в долгу перед Дженнифер Эберхард (Jennifer Eberhardt) из издательства New Riders. Без ее терпения и настойчивости эта книга так и не была бы написана. Я благодарен Майклу Нолану (Michael Nolan) за то, что он привел меня в издательство New Riders в 2000 году и поддержал меня при создании этой книги. Крис Нельсон (Chris Nelson) всячески подбадривал меня, а Дэвид Двайер (David Dwyer) посоветовал мне написать именно такую книгу, когда мне предложили поработать над «маленькой оранжевой книгой по Web-дизайну». В деле проверки книги я полагался на двух талантливых технических редакторов. Дж. Дэвид Эйзенберг (J. David Eisenberg) - преподаватель, участник проекта Web Standards и автор "SVG Essentials" (http://www.oreilly.com/catalog/ svgess). Эрик Майер (Eric Meyer) отвечает за поддержку стандартов в Netscape и является автором книги "Eric Meyer on CSS" (http://www.ericmeyeroncss.com). Кстати, название книги по-прежнему смущает его. Помимо всего прочего, они оба еще и мои друзья. Благодарю также моих коллег и партнеров, вместе с которыми мы опробовали многие приемы, описанные в этой книге: Брайана Элви (Brian Alvey), Ли Бэйкер-Фоли (Leigh Baker-Foley), Хиллмана Кертиса (Hillman Curtis), Ника Финка (Nick Finck), Дэнниса Джеймса (Dennis James), Джамала Кэйлса (Jamal Kales), Эрин Киссэйн (Erin Kissane), Брюса Лифингстона (Bruce Livingstone), Таню Рэбоурн (Tanya Rabourn), Брэда Ральфа (Brad Ralph), Яна Рассела (Ian Russell)n Вэйфэбейби (Waferbaby). Я также благодарен всем клиентам Happy Cog, помогавшим мне, пока я писал книгу, особенно Стиву Бробэку (Steve Broback), Дону Бакли (Don Buckley), Эрику Эфериджу (Eric Etheridge), Эндрю Лину (Andrew Lin), Алеку Поллаку (Alec Pollak) и Рэнди Уолкеру (Randy Walker). Благодарю за интерес к нашей работе, включая случавшиеся иногда неудачные эксперименты и оплаченные счета. Все, что у меня получилось как надо, произошло в большей степени благодаря Тантеку Целику (Tantek 3elik), Джо Кларку (Joe Klark), Тоду Фарнеру (Todd Fahrner) и (снова) Эрику Майеру (Eric Meyer). Они знают намного больше, чем я смогу когда-либо познать, но думают то же самое и обо мне. Без Джорджа Олсена (George Olsen) и Гленна Дэвиса (Glenn Davis) не было бы проекта Web Standards, а без этого проекта сейчас мы бы создавали каждый сайт пятнадцатью разными способами. Спасибо вам за помощь в изменении мира.

стандартам

Я признателен всем участникам данного проекта, особенно Тиму Брэю (Tim Bray) за острый ум, Стивену Чэмпиону (Steven Champeon) за то, что он держит планку, и Дори Смит (Dori Smith). Также выражаю благодарность Эндрю (Andrew) и Рэйчел (Rachel) за успешную работу с компанией Macromedia и сообществом их пользователей. Джеффри Вин (Jeffrey Veen) может об этом не знать, но он помог мне более свободно чувствовать себя, выступая перед аудиторией, что позволило мне донести сведения о Web-стандартах до большего числа слушателей. Я многому научился у всех последователей проекта Web Standards и у его противников, благодаря этим людям с 1998 по 2002 годы сформировалась стратегия нашего проекта. Спасибо всем создателем браузеров, трудившимся в поте лица на протяжении последних лет, невзирая на все препятствия и маленькие бюджеты, чтобы осуществить полную поддержку Web-стандартов. Также я хочу поблагодарить Джэнет Дэйли (Janet Daly), Карла Дюбоста (Karl Dubost), Хакона Лай (Hekon Lie), Молли Хольцшлаг (Molly Holzschlag), Мэрил Эванс (Meryl Evans) и Майкла Шмидта (Michael Schmidt). Спасибо пионерам CSS Дугласу Боумэну (Douglas Bowman), Оуэну Бригсу (Owen Briggs), Крису Касчиано (Chris Casciano), Эрику Костелло (Eric Costello), Тоду Домини (Todd Dominey), Крэйгу Сэйла (Craig Saila), Кристоферу Шмиту (Christopher Schmitt), Марку Ньюхаузу (Mark Newhouse) и Вэйфэбейби (Wafebaby), а также сотням Web-дизайнеров, чья работа вдохновляет нас всех. Эта книга была бы в два раза толще, если бы я перечислил вас всех, но вы и так знаете, о ком я говорю. Особую благодарность выражаю дизайнерам Уоррену Корбиту (Warren Corbitte), Джошуа Дэйвису (Joshua Davis), Мэтту Оуэнсу (Matt Owens) и Ли Мисенхаймеру (Lee Misenheimer). Ваша работа заставляет меня дважды подумать, прежде чем что-то сделать или поверить во что-то. Разные точки зрения имеют право на сосуществование. Я также хочу поблагодарить моего отца Мориса (Maurice) за помощь в написании книги и пожелать ему и его невесте Кэтрин (Katherine) здоровья, любви и счастья. Эта книга посвящена Кэрри (Carrie). Я люблю тебя.

Хьюстон, у нас проблемы П е р е д т е м как начать ГЛАВА 1. 9 9 , 9 % сайтов устарели ГЛАВА 2* Разработка и дизайн по стандартам ГЛАВА 3. Неприятности со стандартами ГЛАВА 4. XML завоевывает мир

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

Расходы растут, доходы сокращаются Запутанный код, разметка из вложенных таблиц, теги <f ont> и другие архаизмы повышают трафик в два-три раза даже для самых простых сайтов. Посетители сайта вынуждены дожидаться полной загрузки или, не дождавшись,

Перед гет как начать

покинуть сайт. Некоторым же приходится ждать лишь для того, чтобы убедиться, что сайт недоступен. Страницы, размер которых может составлять 20 Кб, в этом случае занимают 60 Кб, увеличивая нагрузку на серверы и счета, предъявляемые нам хостинг-провайдерами. Чем больше посетителей имеет наш сайт, тем выше расходы. В случае сложных динамических сайтов возрастает нагрузка на базы данных, еще более увеличивая расходы. В конце концов мы вынуждены покупать или арендовать дополнительные серверы - не из-за возросшего числа посетителей, а благодаря избыточному коду. Между тем зарплата программистов, создающих наш сайт шестью различными способами, растет (отчасти за счет потребности писать разные версии сайта для каждой версии браузера пользователей) и может настолько повысить расходы на развитие, что у нас просто закончатся деньги. Появится новая версия браузера или новое беспроводное устройство, и мы будем просто не в состоянии создать еще одну версию сайта для них. Мы встречались с такой ситуацией, когда при просмотре сайта в новой версии браузера вместо содержимого мы видим сообщение о том, что для просмотра сайта требуется обновленная версия браузера, которая на самом деле намного старее используемой нами. Необязательно владельцы или разработчики сайта отстали от жизни или не понимают, о чем говорят. Возможно, они просто израсходовали весь бюджет, и им больше не на что создавать новые версии сайта. В иных случаях дело может быть не в ограниченности финансов, а в недостатке знаний или неправильном понимании дела. Корпорация Connected Earth, имеющая звучный слоган «Как связь изменила мир», потратила на модернизацию сайта 1 млн. фунтов стерлингов, и, несмотря на это, сайт не поддерживает некоторые новейшие версии браузеров. Его невозможно просмотреть, используя Mozilla (рис. 3), Netscape 6/7 и Opera (рис. 4). Так как сайт также не поддерживает операционные системы, отличные от Windows, доступ к нему закрыт и пользователям Internet Explorer для компьютеров Macintosh. В любом случае, стал ли сайт бесполезным из-за нехватки финансов, или он уже был создан таким из-за использования устаревших приемов, результат одинаковый: снижение числа посетителей. Ведь в конце концов, тратите вы 1 млн. фунтов или $1000 на сайт, целью является привлечение пользователей, а не наоборот.

Положите конец устареванию сайта Технологии, созданные организацией World Wide Web Consortium, поддерживаются большинством современных браузеров и устройств, благодаря чему

Web-дизайн пи стандартам

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

Что такое W 3 C . Организация World W i d e W e b Consortium (W3C) ( h t t p : / / www.w3c.org), созданная в 1 9 9 4 году, занимается созданием спецификаций и руководств для развития Web и обеспечения совместимости различных технологий. В данный консорциум входит около 5 0 0 организаций. Директор организации, Тим БернерсЛи (Tim Berners Lee, http://www.w3.org/people/berners-lee), разработал в 1 9 8 9 году стандарты языка HTML и World W i d e Web. Созданные W 3 C стандарты включают в себя HTML, CSS/ XML, XHTML и D O M (Document Object Model).

м начать

Что такое W 3 C (окончание). На протяжении нескольких лет W 3 C именовала эти спецификации «рекомендациями», из-за чего компании-участники, такие как Netscape и Microsoft, применяли их на практике не так уверенно, как следовало бы. В I 9 9 8 году после создания проекта W e b Standards (www.Webstandards.org) эти спецификации стали именоваться Web-стандарты. Данный маркетинговый ход помог добиться точной и полной их поддержки в любом браузере или Internet-устройстве. Другой аналогичной организацией является European Computer Manufacturers Association (ECMA), отвечающая за язык ECMAScript, более известный под названием standard JavaScript.

Weii-дизайн mm стандартам

Что такое заблаговременная совместимость Когда мы употребляем это выражение, мы имеем в виду, что разработанный и созданный правильно документ, опубликованный в Сети, должен быть совместим со всеми браузерами, платформами и Internet-устройствами, и он останется таковым при появлении новых браузеров и устройств. Подобное свойство документа в Сети возможно благодаря открытым стандартам. Кроме того, еще одним преимуществом является то, что при разработке и создании сайта по стандартам можно добиться снижения производственных и эксплуатационных расходов и одновременно сделать сайт более доступным для людей с ограниченными возможностями. (Это означает следующее: больше клиентов, ниже затраты, улучшение общественного имиджа, снижение вероятности возникновения проблем в связи с ограниченной доступностью.) Что мы подразумеваем под Web-стандартами? Структурированные языки вроде XHTML и XML, CSS, объектные модели, подобные W3C DOM, и скрипты, например ECMAScript. Обо всем этом мы и поговорим в книге. Созданные экспертами, эти, технологии предоставляют большие преимущества огромному числу Web-пользователей. Собранные воедино, они являются основой для рационального, доступного, утонченного и эффективного создания сайтов. (Для владельцев и менеджеров: не обращайте внимание на технические главы этой книги. Убедитесь, что ваши подчиненные прочитали и осознали их.) Что мы имеем в виду под совместимыми со стандартами браузерами? Речь идет о таких продуктах, как Mozilla, Netscape 6+, MSIE 5+/Mac, MSIE6+/Win и Opera 7+, поддерживающих XHTML, CSS, ECMAScript и DOM. Эти браузеры идеально поддерживают все данные стандарты? Конечно, нет. Пока еще не было создано ни одного программного продукта, полностью лишенного недочетов. Более того, стандарты сами по себе достаточно сложны, и способы их взаимодействия довольно запутаны. Тем не менее современные браузеры позволяют нам забыть о старых методах разработки и создавать более изящные сайты на благо пользователям. Кроме того, придерживаясь заблаговременной совместимости, мы можем даже дать доступ пользователям, работающим в старых браузерах и устройствах.

Перед тем к а к начать

Нет догмам и правилам Это не религиозная книга. В Web-дизайне не существует догмы. Нет самого лучшего способа создания сайта, нет единственно верного способа применения стандартов в вашей работе. Мы не призываем использовать стандарты в ущерб переходному подходу, который может оказаться более уместным для некоторых сайтов и задач. Я не буду рекламировать Web-стандарты, утверждая, что все рекомендации W3C безупречны. В книге вы найдете способы решения часто возникающих проблем совместимости с Netscape Navigator, Internet Explorer и другими современными браузерами, а также приемы работы со старыми браузерами, которые могут использовать некоторые посетители вашего сайта. Мы не собираемся обманывать вас. Некоторые запатентованные средства использовать легче, чем спецификации W3C. Например, создание скрипта исключительно для IE с помощью созданных Microsoft методов вроде i n n e r html может быть более легким и удобным способом, чем написание скриптов для всех браузеров с помощью стандарта W3C DOM. Но даже в этом случае более разумным решением будет создание кода для всех браузеров, а не для одного, и сделать это можно, используя модель DOM. И наоборот, несмотря на преимущества структурированного кода и XHTML, мы не собираемся притворяться, что каждый тег на каждой странице каждого сайта всегда должен быть структурирован. И мы не утверждаем, что все сайты немедленно должны быть переведены с HTML в XHTML, однако мы надеемся, что преимущества XHTML убедят вас сделать именно это. Автор данной книги убежден, что по возможности Web-страницы лучше создавать с помощью Cascading Style Sheets (CSS), не прибегая к традиционным таблицам HTML. Благодаря стандарту CSS можно решить многие проблемы, с которыми сталкиваются разработчики и пользователи. Будущее за разметкой CSS, которая уже успешно используется на многих сайтах начиная с корпоративных столпов вроде Wired - www.wired.com (рис. 5) - и популярных поисковых систем (www.alltheWeb.com) и заканчивая частными сайтами и персональными страничками. Тем не менее окончательно «хоронить» разметку с помощью таблиц еще рано, поскольку она по-прежнему подходит для выполнения многих задач. Несмотря на очевидные преимущества CSS, это же ваш сайт, и вам решать, каким ему быть.

Рис. 5. Большой, корпоративный и созданный по стандартам XHTML и CSS Wired.com (www.wired.com)

По мнению некоторых пуританских сторонников стандартов, популярным патентованным технологиям вроде Flash или QuickTime не место в Сети. Такой подход можно простить теоретикам, но перед всеми нами стоят определенные задачи, и подобные технологии являются самым лучшим способом для решения многих из них. В данной книге этим технологиям уделено совсем мало внимания, мы рассмотрим лишь их связь с разметкой и доступностью, но не потому, что нам не нравится Flash или QuickTime, а просто потому, что этот вопрос выходит за рамки нашей книги. Вам, возможно, встречались ярые приверженцы стандартов, готовые критиковать вас даже за использование текста заголовков в формате GIF вместо XHTML-текста, стиль которого задан в CSS. Конечно, рекомендуется делать заголовки в XHTML, но реально хорошо подобранный шрифт текста в формате GIF может оказаться более удобным для вашего сайта, чем модель CSS, которая

Перед тем как начать

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

Практика, а не теория Мы не выступаем против тех, благодаря кому возникают Web-стандарты. На самом деле мы, наоборот, восхищаемся ими и почитаем за счастье дружить с ними и учиться у некоторых из них. Но наша книга предназначена для практикующих дизайнеров и разработчиков, их клиентов и заказчиков, оплачивающих работу. Мы рассмотрим стандарты с точки зрения дизайна, контента и маркетинга. Нашей целью является показать вам мир Web-стандартов и оставить решения за вами. Если в данной книге и есть догма, или одно твердое неоспоримое утверждение, то оно выглядит так: стоимость ведения бизнеса по старинке слишком высока. Никто из читателей не в состоянии больше позволить себе создавать современные Web-сайты с помощью вчерашних приемов. Устаревшие способы применялись, когда одни Web-стандарты еще не были, написаны, а другие худо-бедно поддерживались большинством популярных браузеров. Но это время прошло. Создание одного сайта шестью разными способами могло иметь место во времена Internet-бума и невероятно раздутых бюджетов, но эти дни тоже в прошлом. XHTML, XML, CSS, ECMAScript и DOM останутся с нами надолго. Они не замыкаются в себе, а являются компонентами рационального решения задач, стоящими перед владельцами и создателями сайтов со времен появления тега <blink>. Что такое проект W e b Standards. Проект Web Standards был создан в 1998 году и помог положить конец так называемой войне браузеров, убедив Microsoft, Netscape и других производителей ПО придерживаться стандартов, что помогло снизить расходы и сложность разработки, обеспечить простоту и доступность для всех. Помимо производителей браузеров группа сотрудничает с производителями инструментов для разработки, например Macromedia, а также с владельцами и разработчиками сайтов. Деятельность проекта Web Standards носит добровольный и некоммерческий характер.

Это на самом деле необходимо? Чтобы распрощаться с традиционными проблемами Web-сайтов и перейти на новый уровень, дизайнеры и разработчики должны научиться использовать

Web-дизайн но стандартам

Web-стандарты, а владельцы и менеджеры сайтов должны узнать, какие выгоды они им принесут. Web-стандарты не могут заявить о себе сами, владельцы бизнес-сайтов вряд ли зайдут на сайт W3C, чтобы изучить имеющиеся там документы, маловероятно, что они интуитивно поймут, какую выгоду для их бизнеса принесет аббревиатура XHTML или CSS. Также и загруженные работой дизайнеры, думающие о том, как бы сдать проект вовремя, просто не имеют времени почитать рассылки или онлайн-руководства и найти доступное описание новых Web-технологий. Для этого и была написана наша книга. Эта честь выпала мне, как соучредителю проекта Web Standards. Иногда я говорю от себя, но пишу «мы», надеюсь, читатели простят мне эту привычку, появившуюся в 1995 году, когда я начал создавать Web-сайты. Возможно, вы бы с большим удовольствием прочитали о графическом дизайне, новых веяниях в архитектуре сайтов и их юзабилити1, а не о меняющихся технологиях, на которых держится Web. И, наверное, я бы также с большим удовольствием написал об этих вещах, но все наши попытки улучшить дизайн сайта, его архитектуру и удобство использования окажутся тщетными, если сайт не будет открываться в браузере X или устройстве У. Киноиндустрия не смогла бы существовать, если бы не стандарты, регламентирующие частоту кадров, параметры линз, технику записи звука. Точно так же Web-дизайн и развитие Internet зависит от Web-стандартов. Без них не может быть истинного удобства использования и целостного подхода к дизайну. Популярность Web обогнала процесс создания и принятия стандартов, благодаря чему нам приходилось создавать сайты, моментально устаревающие по мере выхода новых версий браузеров и появления новых технологий. Мы были так заняты созданием, что не могли даже задаться вопросом - как это работает? Теперь для продолжения успешной работы нам необходимо пересмотреть используемые приемы. Web-стандарты являются инструментами, с помощью которых каждый из нас может создавать изящные, прекрасные сайты, которые будут так же хорошо работать завтра, как и сегодня. В этой книге я объясню, как работает каждый стандарт и как все они могут использоваться вместе. Остальное зависит от вас. Джеффри Зельдман

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

Глава 1. 99,9% сайтов устарели Сети распространяется недуг, не щадящий ни безобидные персональные странички, ни крупнейшие корпоративные сайты. Коварно и постепенНО недуг заражает все новые сайты, оставаясь незамеченным, так как он опирается на принятые в Web-отрасли нормы. И хотя их владельцы и менеджеры еще не знают об этом, но 99,9% сайтов устарели. Эти сайты могут отображаться и нормально работать в распространенных браузерах для персональных компьютеров, названия которых заканчиваются на цифру 4 или 5. Но за пределами этой устойчивой к сбоям области признаки болезни видны довольно явно. При просмотре с помощью последних версий Microsoft Internet Explorer, Opera, Netscape Navigator, Mozilla (основанный на Gecko браузер с открытым кодом, используемом в Navigator, CompuServe, AOL для OS X, AOL China и других продуктах) тщательно созданная разметка разваливается на части, а дорогостоящий сайт перестает работать. По мере развития данных ведущих браузеров работоспособность сайта лишь падает. В менее популярных браузерах, устройствах для чтения информации с экрана, используемых людьми с ограниченными физическими возможностями, или в нестандартных устройствах доступа к Internet - начиная с Palm Pilot и заканчивая сотовыми телефонами - эти сайты никогда не откроются. В зависимости от потребностей и бюджета, владельцы и менеджеры сайтов либо вообще не учитывали аудиторию, использующую подобные средства, либо применяли приемы их обнаружения и писали для них свою версию сайта, как и для любой версии браузера. Чтобы понять всю тщетность создания таких сайтов и увидеть, каким образом они повышают расходы владельца и сложность создания, одновременно так и не достигая поставленной цели, необходимо рассмотреть современные браузеры и отметить их отличия от несовместимых со стандартами браузерами прошлых лет.

Глава 1» 99,9% сазп

Современные браузеры и Web-стандарты В нашей книге, когда мы говорим современные браузеры или совместимые со стан-

дартами браузеры, мы имеем в виду браузеры, распознающие и поддерживающие HTML и XHTML, Cascading Style Sheets (CSS), ECMAScript и Объектную модель документа от W3C (W3C DOM). Собранные воедино, они позволяют нам выйти за рамки пресловутого кода разметки, несовместимых скриптов и вызванного ими устаревания сайта. К современным браузерам можно отнести такие продукты, как Mozilla 1.0, Netscape Navigator начиная с версии 6, Microsoft Internet Explorer для Windows начиная с версии 6, Microsoft Internet Explorer для Macintosh начиная с версии 5 и Opera 7. Список и сравнения первой волны поддерживающих стандарты браузеров приведен в приложении. Конечно, этот список не является исчерпывающим и может быть расширен. Несмотря на то что мы будем употреблять выражение «поддерживающий стандарты», не забывайте, что ни один из браузеров не поддерживает их идеально. Тем не менее несовершенство браузеров не является причиной для отказа от использования стандартов. Миллионы людей в настоящее время пользуются Internet Explorer для Windows версии 5 или 5.5. С точки зрения стандартов эти браузеры уступают IE6/Windows, Netscape 6+ и так далее. Значит ли это, что если ваш проект ориентирован на пользователей IE 6/Windows, то вам следует забыть о стандартах? Значит ли это, что вы должны предложить пользователям IE 5 обновить их браузеры или уйти с вашего сайта? Мы отвечаем отрицательно. Разработка сайта с учетом стандартов не означает, что он предназначен лишь для самых последних версий браузеров. Точно так же использование XHTML и CSS не означает, что пользователям Netscape 4 следует предложить вместо просмотра сайта пойти поиграть в «Казаки-2». Правильно созданный сайт с учетом стандартов необязательно будет выглядеть идентично в Netscape 4 и в современных браузерах. На самом деле, в зависимости от способа создания, сайт может выглядеть совершенно по-другому. И в данном случае это нормально. Мы ответим на все возникшие у вас вопросы во второй части книги.

Новый код для новой работы Современные браузеры являются не просто новыми версиями того же продукта. Они имеют фундаментальные отличия от своих предшественников. Зачастую они переписываются с нуля. Mozilla, Netscape 6/7 и другие основанные на Gecko браузеры не являются лишь новыми версиями Netscape Navigator 4. IE 5+/Мас - это

Современные браузеры и ШеЬ-стандарты

далеко не обновленный IE 4 для Macintosh. Opera 7 версии была в корне переделана, чтобы обеспечить максимальную поддержку стандартов. Все эти продукты были оптимизированы для выполнения новой задачи - наиболее совершенной поддержки всех обсуждаемых в этой книге Web-стандартов. Старые браузеры, выпущенные в девяностых годах, были сфокусированы на патентованных технологиях (строго ориентированные на Netscape или Microsoft, их создатели не думали о стандартах). Справедливости ради следует сказать, что практически все старые браузеры игнорировали стандарты, но это и не причиняло разработчикам сайтов головной боли. Например, если браузер не поддерживал стандарт Portable Network Graphic (PNG), то разработчики просто не использовали изображения PNG. Нет проблем. Загвоздка в том, что эти старые браузеры оказали Web-стандартам медвежью услугу, поддерживая их некорректно и не полностью. Неверная поддержка такого простого стандарта как HTML привела к появлению непригодной для успешного развития сайтов Web-среды, которая, в свою очередь, спровоцировала появление ненадежных способов создания сайтов. Представьте себе, что, вместо профессионального удаления аппендикса опытным доктором, молодой практикант отрежет лишь половину отростка, наугад удалит несколько других органов и забудет зашить пациента. Примерно то же самое происходило и со старыми браузерами, что представляло самую настоящую угрозу для сети Internet. Если Netscape 4 игнорировал правила CSS, применяемые к элементу <body>, и добавлял произвольное число .пробелов ко всем структурным элементам на странице, a IE 4 правильно распознавал <body>, но имел затруднения с обработкой отступов, о каком использовании CSS может идти речь? Некоторые разработчик! просто отказались от использования CSS. Другие создавали одну таблицу стилей для компенсации недостатков IE 4 и вторую для устранения проблем в Netscape 4. Для компенсации различий шрифтов и оформления пользовательского интерфейса требовалось создание отдельных таблиц стилей для разных платформ, Windows или Мае. Если же посетитель сайта использовал Unix или Linux - тем хуже для него. Проблемы с обработкой CSS - это только цветочки, браузеры по-разному обрабатывали даже HTML, прорисовывали таблицы или обрабатывали скрипты, предназначенные для добавления на страницу интерактивности. Единых правил для структуризации содержимого страницы не существовало. Точнее, один метод был, но браузеры его не поддерживали. Также не было ни одного правильного способа создать гибкий дизайн сайта или придать ему определенное поведение (они опять же были, но ни один старый браузер не поддерживал такие приемы).

Глава 1. 99,9% сайтов устарели

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

Проблема версий Создание множества нестандартных версий сайта, каждая из которых оптимизирована для определенного браузера, ведет к постоянному устареванию сайта. Правила игры будут постоянно меняться, а сроки достижения целей - все более отдаляться. Несмотря на то что это дорого, нецелесообразно и нестабильно, такая практика сохраняется и по сей день, даже при полном отсутствии необходимости в ней. Имея дело с браузером, поддерживающим стандарты, многие дизайнеры относятся к нему как к несовместимому. Они пишут скрипты для обнаружения браузера пользователя, пытаются вычислить Internet Explorer 6, полагая, что он воспринимает только скрипты от компании Microsoft, хотя IE 6 правильно обрабатывает и ECMAScript, и DOM. После этого разработчики готовы писать отдельный скрипт обнаружения версии браузера и специальный код страницы для современных браузеров Netscape, в то время как они также поддерживают стандарт ECMAScript и DOM. Как показывают данные примеры, в наши дни совершенно необязательно использовать скрипты определения версии браузера. Это более чем необязательно, это просто вредно. Даже при частом обновлении, что делают далеко не все владельцы сайтов, скрипты определения версии браузера часто создают ошибки и не справляются со своей задачей. Например, в операционной системе Windows браузер Opera идентифицирует себя как Explorer. В основном он это делает для того, чтобы избежать запрета доступа со стороны сайтов (например, это делают многие банковские сайты), ориентированных на IE. Но в этом случае написанные специально под IE скрипты не выполнятся в Opera. После установки Opera в настройках по умолчанию задано, что браузер должен идентифицировать себя как IE. Когда же скрипты на сайте, написанные под IE, не срабатывают, пользователь оказывается в полном замешательстве. В принципе можно, изменив в настройках значение параметра User

Устаревшее тыштшм®

Agent, заставить браузер честно идентифицировать себя как Opera, но много ли пользователей знают об этой возможности? Они и не должны об этом думать. Помимо скриптов разработчики часто используют громоздкий код для оформления и дизайна страниц, удваивающий трафик при просмотре той или иной страницы и делающий ее менее доступной для поисковых систем и нетрадиционных устройств. Подобная стратегия зачастую вызывает проблему, которую она должна была решить, - правильное отображение сайта в разных браузерах. Чем больше существует версий сайта, тем выше расходы на его содержание и больше путаница. Сайты, построенные на технологии DHTML и созданные с учетом патентованных спецификаций Netscape 4 и IE 4, не работают в большинстве современных браузеров. Может быть, владельцу сайта следует раскошелиться и попросить разработчиков создать еще одну, пятую или шестую версию сайта? Но если в бюджете нет средств на эти расходы? Тогда многие посетители сайта просто останутся за бортом. Точно так же разработчики могут потратить массу усилий, времени и средств для создания «беспроводной» версии сайта только для того, чтобы обнаружить, что используемый ими код устарел или созданная версия не поддерживается новыми устройствами. Некоторые решают подобные проблемы созданием все новых версий сайта. Другие ограничиваются сообщением с обещанием создать версию, поддерживающую данное устройство в ближайшем будущем. Даже при использовании стандартных технологий вроде XHTML или CSS дизайнеры и разработчики, придерживающиеся принципов старой школы, делают те же ошибки. Они используют стандарты, чтобы избежать создания множества версий одного сайта, и пишут отдельные файлы CSS для каждой платформы и браузера (рис 1.1-1.2). Используя подобные приемы, вы выбрасываете на ветер деньги и время. И самое печальное в трм, что этот метод не позволяет решить проблему. Сайты по-прежнему не работают, а посетители не могут получить к ним доступ.

Устаревшее мышление Взгляните на код любого крупного сайта 2003 года начиная с Amazon и заканчивая Microsoft.com, Sony или ZDNet. Запутанный нестандартный код, использование патентованных ActiveX или JavaScript, неправильное использование CSS (если CSS вообще используется). Удивительно, что такие сайты вообще отображаются в каком-нибудь браузере. Эти сайты работают в популярных браузерах прошлого, так как первые пять поколений Netscape Navigator и Microsoft Internet Explorer не просто допускали

Ттащв 1 * § § , § % сайтов устарели

Рис. 1.1. Сайт MSN Game Zone (zone.msn.com/blog.asp) использует семь внешних таблиц стилей и все равно отображается неправильно в большинстве современных браузеров. Даже применение 14 скриптов (включая скрипт определения браузера пользователя) не решают проблему

нестандартный код, адаптированный под каждую версию браузера, но на самом деле просто поощряли неряшливо сделанные сайты и патентованные скрипты в . попытке выиграть место под солнцем в войне браузеров. Зачастую сайты работают в браузерах вчерашнего дня, так как их владельцы выложили кругленькую сумму за создание нескольких версий сайта, заточенных под требования и спецификации каждой платформы и браузера. Из-за этого пользователи, особенно использующие модемный коммутируемый доступ в Internet, вынуждены проявлять терпение, в то время как лишний трафик создается избыточным разветвленным кодом, многоуровневыми вложенными таблицами, прозрачными пикселями и другими уловками. Что такое разветвление кода. В наш цифровой век программисты пишут код для создания программных продуктов, операционных систем и множества других приложений. Когда над проектом работает несколько групп разработчиков, код может начать разветвляться на несколько несовместимых версий, в зависимости от того, над чем работает каждая группа и какую задачу она пытается решить. Такое несоответствие и децентрализация обычно не приветствуются. В нашей книге разветвлением кода мы называем практику создания нескольких версий сайта для корректного отображения в разных версиях браузеров, не поддерживающих стандарты ECMAScript и DOM (см. раздел «Проблема версий»).

Рис. 1.2. Заголовки статей на сайте Adobe (www.adobe.com) отображаются неправильно, строки наползают друг на друга из-за того, что дизайнеры перехитрили сами себя и создали отдельные стили для каждой платформы и браузера, вместо того чтобы создать одну или две связанные таблицы стилей. Многие дизайнеры, придерживающиеся старых методик, не понимают, что благодаря CSS и XHTML можно избежать создания множества версий одного сайта

В то же время использование множества версий способно невероятно увеличить расходы за счет роста трафика. Чем крупнее сайт, тем выше трафик, больше денег тратится на содержание сервера, загрузку изображений и неоправданно объемного кода. Если размер кода сайта сократится на 35%, то и расходы на трафик снизятся на ту же величину. Компания, расходующая на оплат)7 трафика $2 500 в год, сэкономит $875. Если расходы составляют $165 000, то за год удастся сэкономить $57 000. Главную страницу сайта Yahoo (рис. 1.3) посещает несколько миллионов человек ежедневно. Каждый лишний байт, потраченный на устаревший HTMLдизайн, умножается на астрономическое число показов страниц, выливаясь в

Глава 1. 99,9% сайтов устарели

Рис. 1.3. Главная страница Yahoo (www.yahoo.com) выглядит очень просто

гигабайты ненужного трафика, оплачиваемого Yahoo. Если бы Yahoo просто заменила устаревшие теги <f ont> (рис 1.4) на их эквивалент в CSS, стоимость обслуживания каждой страницы значительно сократилась бы, а прибыль компании выросла. Так почему Yahoo не делает этого? Мы можем лишь предположить, что, наверное, компания хочет, чтобы ее сайт выглядел одинаково как в браузерах 1995 года выпуска, не поддерживающих CSS, так и в современных браузерах. Но вся ирония в том, что, кроме менеджеров Yahoo, до дизайна сайта больше никому нет дела. Посетителей привлекает его содержимое, а не красота дизайна (которую можно поставить под сомнение). Вывод прост: использование такой блестящей компанией устаревшего кода для поддержания образа, который никто даже не оценит, наглядно показывает вам образ мышления и характер поведения разработчиков, считающих обратную совместимость более важной, чем рациональность, удобство использования и даже их собственную прибыль.

Устаревшее мышпшж

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

Устаревшая разметка: платят владельцы сайтов Предположим, что объем кода некоего сайта составляет 60 Кб. Заменив теги <f o n t > и другой устаревший «мусор» на грамотную CSS-разметку, можно сократить размер страницы до 30 Кб. (Вообще-то, исходя из моей практики я могу сказать, что можно сократить размер страницы с 60 Кб до 22 Кб. Но в нашем примере мы будем рассматривать более скромную цифру - 50%.) Что нам это принесет? Ниже приведены два сценария развития дел. Сэкономим на линиях Т1 Сценарий: Сайт небольшой компании или общественной организации с собственным сервером для сайта и постоянным потоком посетителей. После сокращения объема страниц на 50% с помощью перехода от устаревшего кода на ясный XHTML организация сэкономит $1500 в месяц.

Глава 1. 99,9% шмшт устарели

Как это работает: Для обслуживания своих посетителей перед переводом сайта на новый код компании требовалось использование двух цифровых линий передачи данных Т1, аренда каждой составляет порядка $1500 в месяц (средняя месячная стоимость аренды линии Т1 со скоростью пропускания 1,544 Мбит/с). После снижения размера сайта на 50% получается, что организация сможет обходиться и с одной линией Т1, что приведет к экономии в $1500 в месяц. То есть, помимо экономии на трафике, ей еще удастся снизить расходы и на поддержание аппаратного обеспечения в рабочем состоянии. Чем проще код, тем быстрее он доходит до пользователя. Чем быстрее он доставляется на компьютер пользователя, тем меньше нагрузка на сервер, тем меньше серверов необходимо покупать, обслуживать и заменять. Особенно актуально это для серверов, работающих с базами данных, в частности для Internet-магазинов и большинства современных информационных сайтов. Измеряем мегабайты Сценарий: По мере роста популярности коммерческого хостинга владельцы сайтов, расположенных на серверах хостера, все чаще сталкиваются с оплатой ежемесячных счетов за перерасход выделенного трафика, размеры которых составляют сотни или даже тысячи долларов. Снижение размера сайта в два раза уменьшит на соответствующую величину и размеры счетов. Как это работает: Большинство компаний, предоставляющих хостинг для сайтов, выделяют своим пользователям определенный объем бесплатного трафика, скажем 3 Гб в месяц. Если вы укладываетесь в этот объем, то платите обычную месячную сумму. Однако, превысив его, вам придется оплатить все мегабайты дополнительного трафика, размеры которого могут быть значительны. Сразу вспоминается случай, когда хостинговая компания Global Internet Solutions выставила дизайнеру Аль Сакуи (Al Sacui) счет на $16 000 после того, как месячный трафик его некоммерческого сайта Nosepilot.com превысил выделенную квоту. Естественно, это выдающийся случай, и дизайнеру удалось избежать оплаты этого гигантского счета, доказав, что хостинг-компания изменила условия договора без уведомления клиентов (http://thewebfairy.com/ gisol), но лишь после затяжного судебного разбирательства. Много ли найдется желающих потягаться в суде с крупным хостинг-провайдером? Конечно, не все хостинг-компании взимают огромные суммы за превышение трафика. Pair.com, например, берет лишь 1,5 цента за каждый дополнительный мегабайт трафика, и для маленьких компаний, пользующихся ее услугами, расходы на трафик за год могут составить лишь $200. Более интересной возможностью уменьшения объема кода сайта может быть крупная фирма с большим объемом трафика. Независимо от того, большой ваш сайт или маленький, посещается ли он миллионами пользователей или лишь группой объединенных общими

те

интересами людей, - в любом случае снижение размера файлов сайта ведет к понижению трафика и вероятности получения счета за перерасход трафика от вашей хостинговой компании. Кстати говоря, более разумным выбором станет хостинговая компания, не ограничивающая трафик вашего сайта, чем фирма, взимающая плату за каждый дополнительный мегабайт трафика. Компактный код против сжатого. После того как я прочитал лекцию о Web-стандартах, ко мне подошел один разработчик и отметил, что помимо написания компактного кода (заменив устаревший HTML дизайн новым поддерживающим стандарты кодом) можно просто-напросто использовать его цифровое сжатие, доступное в некотором серверном программном обеспечении. Например, Web-сервер Apache включает в себя модуль mod_zip, который сжимает HTML-код на стороне сервера. Затем HTML распаковывается уже браузером пользователя. Этот разработчик привел такой пример: если Amazon.com будет тратить 40 Кб на устаревшие теги <f o n t > и другой «мусор», но использовать сжатие кода с помощью mod_zip, размер страницы можно будет также уменьшить до 20 Кб. Таким образом, можно добиться сокращения размера кода, не прибегая к технике, описанной в этой книге. Однако, как выяснилось, Amazon не использует mod_zip. На самом деле эта возможность вообще используется довольно редко в коммерческих сайтах, быть может, из-за того, что это создает дополнительную нагрузку на сервер. Но если подумать - чем меньше файл, тем меньше он становится при сжатии. Если можно сэкономить, снизив размер страницы с 80 Кб до 40 Кб, используя компактный современный код, то, сжав страницу с 40 Кб до 20 Кб, мы сэкономим еще больше. Экономия на одном сеансе может показаться ничтожной, но суммарный трафик уменьшится невероятно. С течением времени экономия окажется довольно внушительной и предотвратит возникновение незапланированных расходов. (Например, вы сможете отказаться от аренды еще одной линии Т1.) Экономия на трафике является только одной из многих причин использовать четкий, совместимый со стандартами код для создания Web-сайтов, и это оценят как менеджеры, так и посетители сайта.

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

Глава 1. 9 9 3 % сайтов устарели

Netscape Navigator 7 или IE 2. Святой Грааль Web-дизайна, обратная совместимость хорошо выглядит лишь в теории. Но стоимость ее воплощения в жизнь слишком высока и на практике часто оборачивается обманом. Не существует настоящей обратной совместимости. Всегда приходится чем-то жертвовать. К примеру, ни Mosaic (первый графический браузер), ни Netscape 1.0 не поддерживают табличную разметку. По определению, пользователи этих браузеров просто не в состоянии увидеть сайты такими же, как они отображаются на экранах пользователей чуть более поздних версий Netscape 1.1 или MSIE 2. Разработчики и заказчики, ориентирующиеся на обратную совместимость, обычно выбирают какую-то версию браузера, скажем, Netscape 3, и соглашаются, что это самая старая версия браузера, которую они принимают в расчет. (Пользователям же Netscape 2 в таком случае не повезло.) Для претворения в жизнь своей преданности принципам обратной совместимости разработчики используют на страницах различные приемы и хитрости, которые, конечно, утяжеляют сайт. В то же время разработчики пишут несколько версий сайта для каждого браузера и сценарии для определения версии браузера пользователя, чтобы предоставить браузеру оптимизированный под него код. Делая это, разработчики еще больше усугубляют положение своего сайта, увеличивают нагрузку на серверы и вносят свой вклад в то, чтобы борьба с практикой создания устаревающих сайтов продолжалась до тех пор, пока у них не закончатся средства на создание очередной версии сайта.

Блокировка доступа пользователей к сайту плохо влияет на бизнес В то время как некоторые компании стараются сделать так, чтобы их сайт одинаково отображался в новых и старых браузерах, другие полагают, что следует брать в расчет только новые версии браузеров. Придерживаясь стратегии по снижению расходов, они создают сайты, работающие только в Internet Explorer и иногда только под Windows, таким образом лишаясь 15-25% потенциальных посетителей и клиентов (рис. 1.5-1.9). Не будем притворяться, что мы понимаем бизнес-модель компании, отказывающей во внимании почти четверти потенциальных клиентов. Такое число потерянных клиентов должно беспокоить любого мыслящего руководителя компании. Ведь, согласно статистике NUA Internet Surveys (www.nua.ie/surveys), по состоянию на сентябрь 2002 года число пользователей Internet составило 650,6 млн. человек.

Устаревшее мышяеиие

Рис. 1.5. Домашняя страница KPMG (www.kpmg.com), кое-как отображаемая, а точнее, не отображаемая в Navigator, благодаря коду, ориентированному только на IE

Допустим, что вы не против потерять до 25% потенциальных посетителей вашего сайта. Но даже и в этом случае ориентация только на IE может не оправдать себя, так как нет никакой гарантии, что этот браузер (или вообще браузер для персонального компьютера как вид) и в дальнейшем будет сохранять лидирующее место на рынке. За несколько лет до написания этой книги рыночная доля Netscape Navigator намного превышала позиции Microsoft Internet Explorer, занимаемые им сегодня. Соответственно, разработчики полагали, что принимать во внимание следует только Navigator, и создавали сайты, оптимизированные именно под этот программный продукт. Спустя некоторое время ситуация резко изменилась, и заточенные под Netscape сайты остались за бортом. Может ли такая же судьба ждать современные Web-сайты, оптимизированные под IE? Однозначного ответа нет. В Web единственное постоянство - это переменчивость. Использование мобильных устройств с доступом в Internet набирает обороты, и создание сайтов, ориентированных только на отдельные браузеры в ущерб другим продуктам, все больше напоминает решение безумца.

Рис. 1.6. В Navigator 7 страница также не отображается

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

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

Дорога в город дураков В начале 1997 года обычной практикой было использовать JavaScript для браузеров Netscape и JScript (схожий с JavaScript язык) для браузеров Microsoft. Также было принято использовать JavaScript (работавший только в Netscape) и технологию

Глава 1. 99,9% i

гстарели

Рис. 1.8. Этот же сайт в IE6/Windows, где он наконец-то начинает работать

ActiveX (работавший только под IE/Windows) для отправки каждому браузеру подходящего кода. Все это делалось для браузеров третьей (3.0) версии. Такие приемы оставляли за бортом пользователей браузеров других фирм, например Opera, созданные сайты неверно работали на других платформах, скажем, Macintosh, но тем не менее это подходило для «большинства» пользователей и быстро стало нормой. При необходимости создать динамическую Web-страницу, которая не просто хорошо выглядела и была статичной, приходилось следовать данному порядку. В конце 1997 года Netscape и Microsoft выпустили браузеры версии 4.0, которые поддерживали динамический HTML (DHTML), но каждый по-своему. Они также были несовместимы и со своими же более ранними версиями. То, что работало в Netscape 4, не выполнялось в Netscape 3. И, естественно, эти браузеры были абсолютно несовместимы с менее известными коллегами, которые просто поддерживали стандарт HTML, а не придумывали собственные языки.

ICaic написать кед для сайта

Рис. 1.9. Нужно отметить, что сайт работает в Opera 7, но только когда браузер идентифицирует себя как IE

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

Как написать код для сайта Итак, у нас был DHTML для Netscape .4. Совершенно с ним несовместимый DHTML для Internet Explorer 4, работавший, по сути, только под Windows. Был не поддерживающий DHTML JavaScript для Netscape 3 и такая же ситуация с IE 3. Также можно было еще создать версию для менее популярных программных продуктов и более ранних версий браузеров. Таким образом, код даже самого простого сайта был неимоверно разветвленным.

54 Г лава 1 * § 9 3 % с

мели

Некоторые разработчики ограничивали себя лишь двумя версиями сайта для IE 4 и Netscape 4, а посетителям предлагали либо установить один из этих браузеров, либо покинуть их сайт. Другие компании, с меньшим бюджетом, делали ставку лишь на один браузер и обычно проигрывали. Участники проекта Web Standards, созданного вскоре после выхода браузеров 4 версии, установили, что из-за необходимости создания четырех или более несовместимых версий сайта расходы на его создание вырастали минимум на 25%, что, естественно, отражалось на клиентах. Некоторые разработчики ответили на данное утверждение очень просто: популярность Web на пике, клиенты желают платить сколько угодно, так почему Web-агентства должны беспокоиться о стоимости создания нескольких версий одного сайта. Когда же Internet-бум прошел и бюджеты уменьшились, уже ни одно агентство не могло себе позволить такую роскошь, как раньше. По мере сокращения рабочих мест и закрытия Web-агентств один за другим на свет появились браузеры, поддерживающие DOM, созданный W3C. Это означало, что эра дизайна по Web-стандартам наконец-то началась. И какова же была реакция Web-индустрии на данное благое известие? Продолжалось создание разветвленного кода, сайтов, работающих только в IE/Windows, и переход на Macromedia Flash - все это абсолютно недальновидный подход.

Когда с плохим кодом происходят хорошие вещи В самом начале обучения компьютерному программированию студенты узнают о принципе GIGO (Garbage In Garbage Out) «мусор на входе - мусор на выходе». Ведь языки вроде С и Java не просто поощряют правильную технику создания кода, они ее требуют. Точно так же начинающие графические дизайнеры узнают, что качество конечного продукта зависит от качества исходных материалов. При грамотной работе готовая Web-графика (качественные фотографии с высоким разрешением) будет выглядеть отлично. Если попробовать создать дизайн с низкокачественным изображением, вряд ли результат получится сколько-либо привлекательным. Можно оптимизировать для Web изображение в формате EPS с высоким разрешением, но нельзя из низкокачественного файла GIF сделать что-либо приемлемое. Запомните: «мусор на входе - мусор на выходе».

т происходят хорошие вещи

Но традиционные браузеры работают по другому принципу. Они собирают воедино кривой код и неработающие ссылки и в большинстве случаев отображают сайты довольно приемлемо. Такое послабление привело к тому, что многие разработчики и дизайнеры обзавелись вредными привычками, о которых они даже не догадываются. В свою очередь дизайнеры среднего уровня стали относиться к технологиям, подобным CSS, XHTML и JavaScript, как к довольно примитивным. Ну а если вы не уважаете инструмент, вряд ли вы будете использовать его надлежащим образом. Обратите внимание на следующий пример кода дорогостоящего сайта электронной коммерции, приведенный здесь в оригинале: <td width="100%"xont face="verdana,helvetica,arial" size="+l" color="#CCCC66 "xspan с 1 ass= "header" x b x J o i n now! </bx/span> </ontx/td>

Бессмысленный тег <ont> происходит от столь нелюбимого нами <font>, этот тег повторяется в коде сайта тысячи раз благодаря мощной системе публикаций сайта. Если бы не эта ошибка, данный код, возможно, показался бы вам очень знакомым. Он даже может вам напоминать код вашего собственного сайта. На самом деле в контексте Web-страницы предыдущий фрагмент кода можно было заменить следующим: <h3>Join now!</h3> Имея соответствующее правило, указанное в таблице стилей, эта строка выполнит те же функции, что и предыдущий отрывок кода, но заметно сэкономив трафик и облегчив переход на более гибкий код XML. Код того же сайта включает в себя и следующую нерабочую ссылку на языке JavaScript: <script language=JavaScriptl.lsrc= "http://foo.com/params.richmedia^yes&etc"

></script>

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

Глава 1. 9 9 3 % сайтов устарели

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

Решение всех проблем После долгого противостояния дизайнеров и разработчиков с производителями браузеров мы наконец-то можем использовать приемы, гарантирующие корректное отображение и поведение наших сайтов не только в одном браузере, а во всех. Технологии вроде CSS, XHTML, ECMAScript (стандартная версия JavaScript) и W3C DOM позволяют дизайнерам следующее: • обрести более четкий контроль над разметкой, размещением элементов и управлением текстом в графических браузерах и одновременно дать возможность пользователям изменять облик сайта на свой вкус; • создавать функциональные сайты, работающие на всех платформах и во всех браузерах; • создавать сайты, отвечающие требованиям доступности без необходимости жертвовать внешним видом или функциональностью; • тратить на редизайн несколько часов вместо дней или недель и таким образом снижать расходы; • поддерживать множество браузеров без создания отдельных версий сайта для каждого из них; • поддерживать нетрадиционные устройства доступа к Internet;

, •

• • • •

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

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

Г1ШМ 1. Разработка и дизайн по стандартам

аким образом создавались Web-сайты до того, как были приняты Webстандарты и браузеры научились поддерживать их? Ответ -любым возможным способом. В качестве примера можем рассмотреть сайт одного из первых и интереснейших периодических изданий Suck.com (рис. 2.1). Авторы Suck.com писали необычным стилем и придумали публиковать ежедневные статьи и новости прямо на главной странице. Сегодня в этом нет ничего удивительного, однако в середине девяностых, когда появился проект Suck, такой подход был нетипичен и большинство сайтов скрывали свое содержимое за страничками приветствия, навязчивой графикой и запутанным оглавлением. Такой прямолинейный, ориентированный на текст подход выглядел новаторским на фоне остальных сайтов, использовавших излишне метафоричный и изысканный стиль. В то время было очень популярно использование бесполезной графики, в стиле high-tech или готическом стиле. Многие сайты были оптимизированы под примитивный Netscape 1.1, активно использовали тег < c e n t e r > , а для фона применяли небольшое повторяющееся изображение. Некоторые сайты (рис. 2.2), кстати говоря, до сих пор используют эти приемы. И даже для создания такой простой концепции сайта Suck.com его соавторам Карлу Стедману (Carl Steadman) и Джоуи Энаффу (Joey Anuff) пришлось преодолеть немало трудностей. HTML недоставало средств оформления дизайна, и на то была своя причина: создатель Internet Тим Бернерс-Ли (Tim Berners-Lee) полагал, что HTML является структурированным языком разметки (http:// www.w3c.org/MarkUp/html-spec), произошедшим от SGML, а не языком для дизайна, как, например, Adobe PostScript или CSS. (CSS еще только предстояло быть одобренным W3C как стандарт. Пройдет еще 4 года, прежде чем браузеры начнут достаточно приемлемо поддерживать его.) Так каким же образом Стедман и Энафф управляли внешним видом своего сайта? Для этого им понадобились сообразительность, мастерство и, конечно, творческий подход.

Рис. 2.1. Suck.com, несомненно, выдающийся сайт своего времени (www.suck.com)

Через тернии к звездам Для создания своего собственного стиля Стедман и Энафф написали сценарий на Perl, который подсчитывал число символов в строке и вставлял закрывающий тег <р> после того, как было достигнуто определенное число: <p>0ne of the strange-but-truisms of <p>minor peddling is that using the <p>computer and other Fetish fodder <p>somehow empowers children - plug <p>in, log on, attend a good <p>college on full scholarship, and <p> get the hell out of the house.

Затем весь текст заключался в теги < t t > , чтобы заставить ранние версии графических браузеров, например Netscape 1.1, отображать текст в моноширинном шрифте вроде Courier или Monaco. Такие ухищрения в 1995 году были единственным способом достигнуть желаемого эффекта. (На рис. 2.1 показана

Тшта 2, Разработка и дизайн но стандартам

обновленная в 1996 году страница сайта. Оригинальная минималистская версия дизайна больше недоступна.) Подобные HTML-приемы были широко распространены среди Web-дизайнеров и даже описывались в ранних руководствах по дизайну Линды Вейнмен (Lynda Weinman) и Дэвида Сигела (David Siegel). Создатели HTML были недовольны, наблюдая подобное искажение языка, но дизайнерам ничего не оставалось, как прибегать к подобным приемам, так как клиенты требовали красивых сайтов. Многие дизайнеры до сих пор используют аналогичные методы в своей практике, а во многих книгах продолжают обучать таким приемам, которые не просто архаичны, но и непродуктивны. Например, в 2002 году мне попалась под руку одна довольно неплохая книга, в которой, тем не менее, советовалось управлять оформлением текста с помощью тегов font и HTML-скриптов. Теги font давно устарели, а словосочетание «HTML-скрипты» вообще звучит дико, однако подобные советы появляются в публикациях с завидной регулярностью.

Цена дизайна до появления стандартов Благодаря манипуляциям с HTML создатели Suck добились нужного им внешнего вида, но какой ценой? Сайт стал недоступен для некоторых пользователей, и его содержимое было довольно проблематично обновлять. В ранних версиях программ для считывания текста с экрана (для людей с ограниченными физическими способностями) голос, озвучивающий текст с сайта Suck, делал паузу каждые несколько секунд, когда доходил до конца строки: One of the strange-but-truisms of ... minor peddling is that using the ... computer and other Fetish fodder ... somehow empowers children- - plug ...

(пауза) (пауза) (пауза) (пауза)

in, log on, attend a good ... (пауза) college on full scholarship, and ... (пауза) get the hell out of the house.

Такое повествование разобрать на слух довольно сложно. Благодаря этим паузам и заминкам великолепное содержание сайта Suck.com стало недоступно пользователям программ для считывания текста с экрана. Но, помимо того что сайт был недоступен для пользователей с ограниченными физическими возможностями из-за используемых уловок HTML, обновлять содержимое сайта было тоже довольно проблематично.

Цена дизайна цо п

арт#в

Глава 2. Разработка и дизайн по стандартам

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

Современный сайт и устаревшие методы Перенесемся из 1995 года в 2001. Перед нами современный сайт, рекламирующий Gilmore Keyboard Festival (www.thegilmore.com), - рис. 2.3. Красивый сайт с табличной разметкой, на которую потрачено немало времени.

Рис. 2.3. Web-сайт Gilmore Keyboard Festival (www.thegilmore.com). Есть на что посмотреть, но сложно обновлять и обслуживать

fe;.-i ;

;

•

•-

•

;

: ; • ' • : • • ' • : • • :

•

;

•

• • , • • . = • ; • , / ; • - • :

: • : • . - : •

;

•

Что не так с этим сайтом, помимо того что он определяет разрешение монитора посетителя? Очевидно, что его владельцев должны беспокоить следующие два момента: • финансовые затраты, вызванные необходимостью внесения изменений: если потребуется внести любые изменения в сайт фестиваля, допустим, будет слегка изменена его программа, сделать это через простую текстовую ссылку не удастся. Также не получится добавить дополнительные ссылки и в изображение GIF, выполняющее функции навигационного меню. Таблица HTML, которая собирает воедино разные фрагменты изображения (рис. 2.4), просто развалится на куски, если размер хоть одного рисунка будет изменен. Таким образом, даже небольшие изменения повлекут за собой значительные расходы времени и сил. Придется переделывать графику, вновь нарезать изображения на кусочки, повторно оптимизировать их, а код таблицы переписывать вместе с кодом разметки изображений и JavaScript.

Глава 2. Разработка и дизайн но стандартам

Если добавление текстовой ссылки требует нескольких часов работы, стоит пересмотреть используемые методы дизайна; • невозможность просмотра сайта множеством потенциальных посетителей: менее очевидная причина, но от этого не менее важная - сайт, созданный таким образом, совершенно недоступен для пользователей программ считывания с экрана и текстовых браузеров, устройств вроде Palm Pilot и сотовых телефонов, а также для пользователей обычных браузеров, но с отключенной опцией показа изображений. Такие пользователи не получат от посещения сайта абсолютно никакой информации, что может, например, негативно сказаться на продажах билетов. При просмотре в браузере без отображения картинок (рис. 2.5) все содержание сайта сводится к следующему: [INLINE] [INLINE] [INLINE] [INLINE] [usemap] [INLINE] [INLINE] Contact Us [INLINE] Privacy Statement Copyright 2001 Сомнительно, что цель сайта - донести до публики сообщение INLINE INLINE INLINE. Вряд ли INLINE INLINE INLINE чем-то поможет потенциальным клиентам. Однако, помимо этого, теоретически любой пользователь с ограниченными физическими возможностями может увидеть в данном сайте дискриминацию по отношению к себе. Мы, конечно, не юристы и не собираемся подавать в суд на сайт, который, несомненно, был создан с самыми лучшими намерениями. Мы не хотим сказать, что графика - это плохо или красота - это плохо. Напротив, создатели сайта Gilmore проделали отличную работу для придания сайту великолепной формы. Такая красота не должна быть недоступной. Сайт может выглядеть точно так же, но быть доступным для всех посетителей. Несмотря на привлекательный внешний вид, сайт Gilmore является очень типичным по способу создания и дизайну. Соответственно, проблемы, с которыми сталкиваются создатели сайта, тоже очень типичны. В большинстве случаев, когда заказчик захочет внести какие-то изменения в страницу, наш отточенный дизайн и выверенные таблицы разваливаются на куски. Придется либо выставлять счет клиенту, либо нести расходы самим. При ограниченном бюджете клиент может потребовать быстрого и простого решения, что полностью уничтожит созданную красоту и четкость разметки.

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

Например, можно просто добавить три гипертекстовые ссылки вверху или внизу страницы сайта Gilmore, что позволит получить доступ к новому содержимому, но также вызовет некоторое непонимание со стороны посетителей. (Почему эти ссылки отделены от других? Они более важные, чем другие? А может, наоборот.) Добавление таких ссылок также внесет дисбаланс в эстетический облик сайта, что понизит его ценность как маркетингового инструмента. Так же как и создатели сайта Gilmore, многие из нас зачастую обнаруживают, что старые методы дизайна больше не работают. Конечно, они могут неплохо смотреться в популярных браузерах при «обычных» условиях и «нормальных» настройках. Но за пределами этой тепличной среды наши сайты могут оказаться нефункционирующими, что как минимум ведет к сокращению числа посетителей. Владельцы и создатели сайта Gilmore не одиноки в своем заблуждении. Они лишь следуют установленным в Web-индустрии нормам. Вызванные соблюдением этих норм проблемы стоят перед очень большим числом сайтов, созданных

Г пава 2. Разработка и дизайн пи стандартам

с оглядкой лишь на популярные модели браузеров и не использующих стандарты для увеличения числа потенциальных посетителей. Эти трудности также неотступно следуют и за теми, кто создает внешний вид сайтов, используя возможности H T M L . *

Три кита Web-стандартов На рис. 2.6 показано, как можно решить описанные выше трудности с помощью Web-стандартов, разбив любую страницу на три составные части: структура, внешний вид и поведение.

Структура Язык разметки (XHTML:http://www.w3.org/TR/xhtmll) содержит текстовые данные, отформатированные согласно их смысловому значению: заголовок, подзаголовок, абзац, нумерованный список, список определений и так далее. Опубликованный в Сети текст, который вы читаете, скорее всего, будет частью списка определений, заключенных в <dl>. Подзаголовок «Структура» будет помечен тегом заголовка определений <dt >. Данный абзац будет заключен в теги данных определения <dd>:

Три кита Web-стандартов

Глава 2» Разработка и дизайн и© стандартам

сосредоточимся на XHTML, переходном языке, который, согласно рекомендациям W3C, работает как HTML практически во всех браузерах и Internet-устройствах. При корректном написании (без ошибок, запрещенных тегов и атрибутов) код XHTML полностью пригоден к переносу на другую платформу. Он работает в Web-браузерах, программах чтения текста с экрана, текстовых браузерах и беспроводных устройствах. По усмотрению разработчика код также может содержать дополнительные структуры. Например, контент PI навигация могут быть помечены определенным образом и помещены в соответствующие теги: <div id="content"> [Сюда поместить данные.] </div> <div id="navigation"> [Меню навигации по сайту.]</div> Код может содержать вложенные объекты, например изображения, ролики Flash или фильмы QuickTime, а также теги и атрибуты, представляющие текст сайта в специальном виде для тех, кто не может просмотреть эти объекты в своем браузере.

Внешний вид Языки оформления внешнего вида сайта - два поколения языка CSS (CSSlrhttp:// www.w3.org/TR/REC-CSSl; CSS2:http://www.w3.org/TR/REC-CSS2) - позволяют задать формат страницы, управлять шрифтами, расположением элементов, цветом и так далее. В большинстве случаев CSS может занять место устаревшей табличной разметки на HTML. В любом случае с помощью CSS можно отказаться от использования тегов шрифта и другого устаревшего «мусора», только увеличивающего трафик вроде этого примера: <td bgcolor="#FFCCOO" align="left" valign=" top" xbrxbrxbr>&nbsp; </ td>

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

действии

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

Поведение Стандартная объектная модель (W3C DOM, http://www.w3.org/DOM/ DOMTR#doml) работает с CSS, XHTML и ECMAScript 262 (http://www.ecma.ch/ ecmal/STAND/ECMA-262.HTM), стандартной версией JavaScript, что позволяет создавать разнообразные варианты поведения страницы и эффектов на ней, работающих на разных платформах и в разных браузерах. Больше не нужен JavaScript только для Netscape или технологии ActiveX и JScript только для IE/Windows. В зависимости от цели создания сайта и его аудитории, дизайнеры и разработчики могут использовать всю мощь Web-стандартов для полного разделения структуры, внешнего вида и поведения. Либо можно создать переходный сайт, комбинируя старые и новые приемы и используя простую табличную разметку XHTML и технологию CSS для оформления сайта.

В действии Если бы проект Suck функционировал до сих пор благодаря таким Web-стандартам, как XHTML и CSS, авторы смогли бы сосредоточиться на творчестве. Структуру документа обеспечивал бы простой шаблон XHTML. С помощью CSS можно было бы управлять оформлением сайта. Отпала бы необходимость доработки сайта при каждом обновлении, кроме обработки изображений, связанных с публикуемым материалом. Благодаря таблицам стилей в графических браузерах типа IE, Mozilla/ Netscape и Opera, сайт Suck.com выглядел бы именно так, как задумали его создатели. С помощью структурированного XHTML содержимое сайта можно было бы прочитать не только в этих браузерах, но и в карманных компьютерах (PDA), программах для чтения информации с экрана и текстовых браузерах. Так как сайт Suck.com ориентирован в первую очередь на содержание, он стал бы главным кандидатом на использование технологии XHTML/CSS, где оформление и содержание реализовывались на разных языках: CSS отвечает за разметку, а XHTML - за контент. Но владельцы Suck также могли бы добиться успеха и используя переходную модель: простые таблицы XHTML для задания расположения основных элементов страницы, a CSS для оформления внешнего вида сайта.

Глава 2. Разработка и дизайн по стандартам

Создатели сайта Gilmore вряд ли смогут извлечь выгоду из использования шаблонов, по крайней мере, если будет сохранена главная страница сайта в ее теперешнем виде. Однако они могли бы создать такую же разметку с помощью CSS, сэкономив на трафике и позволив дизайнерам изменять отдельные секции страницы без нужды переделывать всю разметку. Создатели Gilmore могли использовать свойство фона в CSS, чтобы расположить основное изображение в виде единого файла JPEG, а не резать его на девять мелких кусочков (см. рис. 2.4). Меню можно было наложить сверху, используя один из проверенных приемов CSS, поддерживаемых даже в браузерах версии 4.0. Дизайнеры сайта Gilmore также могли бы использовать XHTML и атрибуты a l t , t i t l e или longdesc, чтобы обеспечить доступность сайта более широкому кругу пользователей (см.,рис. 2.5). Менее насыщенные графикой остальные страницы сайта можно было создать переходным методом (CSS и таблицы) или только CSS-разметкой.

Преимущества переходной модели Использование переходного метода создания сайтов с помощью XHTML и CSS стало бы значительным улучшением общего положения в Сети и помогло бы решить обсуждаемые в данной книге проблемы. Используя переходный метод - CSS для шрифтов, управления цветом, границами и другими подобными элементами, а таблицы XHTML для основной разметки, - можно улучшить удобство использования сайтом, доступность, совместимость и долгосрочную работу сайта, хотя при этом потребуется больше человеческих ресурсов и трафик будет не таким низким, как при использовании одного лишь CSS. Сайт Web-агентства автора, Happy Cog (www.happycog.com), создан на основе переходной технологии (рис. 2.7-2.9). Он сочетает в себе табличную разметку XHTML с CSS 1 и CSS 2, а также скрипты, основанные на объектной модели документа W3C DOM. Данный сайт соответствует стандартам XHTML1.0 Transitional и CSS, требованиям доступности Section 508 и WAI Priority I Guidelines. Благодаря соответствию требованиям XHTML, CSS и Section 508 сайту обеспечена долгая жизнь по мере развития браузеров и стандартов. Благодаря использованию испытанных методов (табличной разметки) он хорошо смотрится

Преимущества ш

лш

Рис. 2.7. Happy Cog (www.happycog.com) является примером переходной модели сайта, сочетающего в себе табличную разметку XHTML с CSS и скрипты, использующие D0M

в современных браузерах (см. рис. 2.7) и неплохо отображается в браузерах девяностых годов вроде Netscape 4 (см. рис. 2.8), которые довольно посредственно поддерживали CSS. В то же время использование простой структурной разметки на сайте Happy Cog позволяет просматривать его как пользователям текстовых браузеров (см. рис. 2.9) и программ чтения информации с экрана, так и пользователям появляющихся новых моделей беспроводных устройств. Используемая Happy Cog переходная стратегия обеспечивает совместимость как со старыми моделями браузеров, так и с новыми, и является наиболее правильным выбором для большинства сайтов. Однако, чтобы насладиться всеми возможностями Web-стандартов, необходимо кардинальным образом изменить способ мышления дизайнеров и используемую методологию.

Глава 2» Разработка и цизайн я® ста

Рис. 2.8. При открытии в старом браузере (Netscape 4) большая часть содержимого сайта отображается как положено. Некоторые тонкости дизайна пропали, но ни мы, ни пользователи Netscape 4, привыкшие к отсутствию совершенства на большинстве просматриваемых ими сайтов, не возражаем

Оптимальные методы разработки сайтов, сохранение целостности и совместимости, удовлетворительный уровень дизайна во всех пользовательских продуктах - это не просто недостижимый эталон; это пример того, как сайты могут работать уже сейчас при использовании Web-стандартов. Краеугольным камнем нового подхода к дизайну является возможность отделения структуры от оформления и поведения сайта. Именно так будут создаваться все сайты в будущем (за исключением Flash-сайтов) и уже создаются такие бескомпромиссные сайты, ориентированные на будущее. Некоторые из них мы рассмотрим в этой книге.

Web Standards Project: совместимость в'действии

Рис. 2.9. Сайт Happy Cog, открытый в текстовом браузере Lynx. Как и должно быть, все содержимое сайта оказалось доступным, в отличие от изображенного на рис. 2.5. Создатели сайта Happy Cog не.умнее или хитрее создателей сайта Gilmore, они просто используют стандарты

Web Standards Project: совместимость в действии Созданный в 1998 году Web Standards Project (WaSP) - рис. 2.10 - помог убедить Netscape, Microsoft и других производителей браузеров внедрять в свою продукцию поддержку обсуждаемых в данной книге стандартов. Потребовались время, настойчивость и стратегия, но в конце концов производители браузеров осознали, что совместимость со стандартами является жизненно необходимой для дальнейшего развития Web.

Глава 2* Разработка и дизайн г§«* стандартам

Парадокс. Интересно, что в борьбе за создание Web-стандартов принимали участие и Netscape с Microsoft, являющиеся членами W3C, однако затем потребовалось приложить немалые усилия, чтобы они стали создавать продукцию, поддерживающую созданные ими же стандарты.

Когда же браузеры наконец научились поддерживать стандарты (см. главу 3), проект Web Standards Project был перезапущен в 2002 году, чтобы донести до дизайнеров и разработчиков очевидность преимуществ данных технологий. Сайт проекта был переработан в связи с изменением его миссии с лоббистской на образовательную. Как того требовала миссия проекта, дизайн сайта отлично отображался в совместимых со стандартами браузерах (рис. 2.10). Он также хорошо смотрелся

Рис. 2.10. Домашняя страничка Web Standards Project (www.webstandards.org), открытая в браузере Chimera (основан на коде Gecko) для Mac OS X. CSS-разметка сайта выглядит одинаково во всех современных браузерах

Web Sir

шесть в

Рис. 2.11. Этот же сайт выглядит и работает вполне нормально в Netscape 4. Специальной версии для Netscape 4 создано не было

и в более старых браузерах (рис. 2.11). И все это без использования альтернативной или дополнительной разметки и определения браузера пользователя.

Один документ для всех Сайт Web Standards Project создан с использованием только XHTML 1.0. CSS применяется для разметки и оформления. Нет отдельных версий для Palm или WAP. Создание нескольких версий PI не требуется - при работе по стандартам один документ подходит для всех. На рис. 2.12 слева мы видим сайт webstandards.org на экране карманного компьютера Palm Pilot, а справа - тот же сайт в Microsoft PocketPC. Самое

Глава 2* Разработка и дизайн «о стандартам

Рис. 2.12. Тот же сайт, открытый на другой день в Palm Pilot. Скриншот предоставлен Porter Glendinning - www.serve.com/apg, справа - этот же сайт в Microsoft Pocket PC. Скриншот предоставлен Энил Дэшом (Anil Dash) - www.dashes.com/anil

интересное показано на рис. 2.13 - мы видим работающий сайт на карманном компьютере Newton, давнем предшественнике Palm Pilot от компании Apple. Грант Хатчинсон, предоставивший нам этой снимок, отметил, что сравниться с современным сайтом, открытым в устаревшем браузере на допотопном компьютере, не может ничто. Эти слова звучат как музыка для любого дизайнера или разработчика, который хочет охватить как можно большую аудиторию с минимальными усилиями. Строгое соответствие нормам XHTML и правильное использование CSS освобождает дизайнеров от создания нескольких версий одного сайта.

A List Apart: одна страница, много видов

Обратите внимание, что на рис. 2.12-2.13 меню, использующее DHTML и отображаемое в левой части экрана, превращается в обычный маркированный список на Palm, PocketPC или Newton. Как это произошло? Ответ прост. Меню DHTML на самом деле является простым маркированным списком. CSS изменяет его внешний вид в совместимых браузерах. Меню добавляется на страницы с помощью технологии Server Side Includes (SSI).

Рис. 2.13. Снова Webstandards.org, на этот раз открытый в «наладоннике» Apple Newton. Скриншот предоставлен Грантом Хатчинсоном (Grant Hutchinson) -www.splorp.com

A List Apart: одна страница, много видов Сайт принадлежащего автору данной книги электронного журнала "A List Apart" (www.alistapart.com), предназначенного для людей, создающих Web-сайты, был полностью переведен на разметку CSS в феврале 2001 года. Дизайн сайта (рис. 2.14) сохранил привычный дух HTML минимализма, который ранее достигался с помощью таблиц HTML.

Ттава 2» Р а з р а б о т к а и д и з а й н по стандарта»

Посетители ALA, которым не нравится мелкий шрифт сайта, используемый по умолчанию, могут переключиться на более крупный с помощью переключателя таблиц стилей, созданного Полом СоуДеном (Paul Sowden). В 126 номере ALA (www.alistapart.com/issues/126) объясняется, как работает переключатель, и приводится открытый код, который вы можете использовать по своему усмотрению. (Дополнительные сведения можно найти в главах 15 и 16.) На рис. 2.14 показан сайт ALA, открытый в совместимом с CSS браузере вроде IE5+, Mozilla, Netscape 6+ и Opera 5+. В другой среде сайт выглядит совершенно иначе. Мы видим тот же сайт, но открытый в несовместимом с CSS браузере - Netscape Navigator 4 (рис. 2.15). Сайт по-прежнему полностью доступен и функционален.

A List Apart: «дна страница, много видев

Несомненно, многие читатели предпочтут именно такой вариант. Сразу после перехода сайта на CSS-разметку число посетителей с браузером Netscape 4 возросло. Похоже, эти пользователи предпочли более простой внешний вид, доступный их браузерам, прежнему сложному дизайну, лишь подчеркивавшему слабость их браузеров. Те же, кто считает, что стандарты ущемляют пользователей старых версий браузеров, могут считать эту историю примером обратного утверждения: при правильном использовании стандарты помогают всем. Глядя на рис. 2.15, вы можете подумать, что панель, навигации исчезла. На самом деле она просто переместилась вниз страницы. Размер и шрифт текста определяются настройками браузера пользователя. Для отображения упрощенного формата сайта не применяется определение используемого пользователем браузера. Вместо этого таблица стилей, контролирующая вид сайта, подключена таким образом, что несовместимые браузеры просто игнорируют ее. (Мы объясним, как это сделать во второй части книги.)

Гтввв 2. Разработка и дизайн по стандартам

Рис. 2.15. Этот же сайт в браузере версии 4.0. Нет поддержки CSS, но нет и проблем. Сайт полностью доступен

Мы не использовали таблицы и другой «мусор» в создании страниц. Единственное - атрибут цвета фона в теге <body>, чтобы графика сочеталась с остальной страницей в несовместимых с CSS браузерах.

Дизайн за пределами экрана И наконец, на рис. 2.16 мы видим напечатанную на принтере страницу с сайта A List Apart. Как видно, боковая панель была удалена, шрифт и цвета оптимизированы для печати, и URL каждой ссылки отображены для большего удобства. Это «волшебство» работает за счет отдельной таблицы стилей для печати, созданной Эриком Майером (Eric Meyer) на базе старой таблицы стилей печати, созданной автором этой книги и Тоддом Фарнером (Todd Fahrner). Майер является признанным экспертом по CSS и автором книги "Eric Meyer on CSS: Mastering the Language of Web Design" (издательство New Rider, 2002). В его статье "Going To Print" (www.alistapart.com/stories/goingtoprint/) для журнала "ALA' объясняются способы создания таблицы стилей для печати. Мы также обсудим этот вопрос во второй части книги.

•

;

•

;

- • • • •

;

•

Рис. 2.16. Из Сети на бумагу. Статья ALA оптимизируется для печати «на лету» благодаря таблице стилей для печати

Самое главное, о чем мы хотим сказать, - благодаря одному небольшому документу - таблице стилей для печати - 'A List Apart" больше не нуждается в создании отдельной, оптимизированной для печати версии. То же самое можно сделать и с вашим сайтом. Исключением станут лишь сайты, статьи которых расположены на нескольких страницах (вроде www.wired.com или www.oreilly.com). Создание отдельных версий для печати необходимо, чтобы соединить страницы статьи в один

Глава 2.

пишш^г

о стандартам

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

Экономия времени и расходов, рост аудитории Если дизайн и разработка сайтов по стандартам означает отказ от необходимости создания нескольких версий одного сайта, легко понять, почему экономия времени и расходов станет значительной: • • • • • •

больше никаких версий только для Netscape; больше никаких версий только для Internet Explorer; больше нет «простых» версий для старых браузеров; во многих случаях нет нужды в отдельных версиях для WAP или WML; нет необходимости в оптимизированных для печати версиях; не нужно прибегать к определению браузера или платформы, можно избежать лишней нагрузки на сервер, не используя оптимизированные под отдельные браузеры или платформы компоненты.

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

Куда двигаться дальше? Созданные на базе XML языки разметки (см. главу 4) превратят Сеть в детский сад. Но мы не можем двигаться вперед, используя устаревшие нормы дизайна и разработки. Есть два способа движения вперед: переходная совместимость, при которой используется сочетание традиционных и основанных на стандартах техник, и строгая совместимость, основанная на полном (или почти полном) разделении структуры, оформления и поведения.

Куда двигаться даныне?

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

Переходная модель совместимости Составляющие: • правильный XHTML-код. (Также допустимо использовать HTML 4.01.); • CSS для управления шрифтами, цветом, границами и другими элементами; • легкое использование таблиц XHTML для разметки. Следует избегать вложенных таблиц, возлагая эту работу на CSS; • дополнительно: можно применять структурные метки к значащим ячейкам таблицы (полезно для CSS и при создании скриптов, поможет в переходе к разметке CSS без таблиц); • JavaScript/ECMAScript на базе DOM, допустимо разветвление кода с учетом IE и Netscape версии 4.0; • атрибуты для повышения доступности и тестирование. Рекомендации Переходная модель рекомендована для сайтов, значительная часть посетителей которых пользуется браузерами версии 4.0 и более старыми, которые просто не в состоянии адекватно поддерживать CSS и DOM. Также рекомендуется для тех случаев, когда таблицы справляются с разметкой лучше/чем CSS. Переходный метод использован при создании сайта Нью-йоркской общественной библиотеки (рис. 2.17), чтобы сохранить огромную базу пользователей Netscape 4.0, внедрить совместимость с XHTML и CSS и обеспечить доступность в будущем. Преимущества: • рациональная совместимость со старыми браузерами. Сайты смотрятся достаточно неплохо даже в невероятно старых версиях браузеров. Естественно, в новых браузерах они будут выглядеть гораздо привлекательнее (в некотором смысле это даже лучше, так как может побудить некоторых пользователей сменить свои древние1 браузеры на новые); 1

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

Глава 2. Разработка if дизайн но стандартам

Рис. 2.17. Сайт Общественной библиотеки Нью-Йорка (www.nypl.org/branch) создан по переходной технологии: XHTML и умеренное использование таблиц для разметки, доступность WAI Priority 1, CSS для оформления. Совместимый с новыми и старыми устройствами, такой метод является оптимальным для некоторых организаций

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

85 Недостатки: • структура и внешний вид по-прежнему связаны, что несколько осложняет обслуживание и обновление сайта; • по этой же причине в будущем поддерживать такие сайты будет все труднее, если учесть распространение основанных на XML систем управления контентом (Content-management System - CMS). Вряд ли это станет проблемой для маленьких сайтов, но для крупномасштабных сайтов, содер' жащих сотни и тысячи динамических страниц, это может обернуться большой головной болью.

Строгая совместимость Составляющие: • полное отделение структуры от оформления и поведения; • для разметки используется CSS. Таблицы применяются лишь по прямому назначению - для отображения табличных данных, например адресных книг, списков событий, учетных записей, электронных таблиц; • создание структуры * страниц на XHTML 1.0 Strict или XHTML 1.0 Transitional; • акцент на структуре. В коде не содержится уловок по оформлению сайта (строгий подход Strict) или их число сведено к минимуму (переходный подход Transitional); • структурные метки элементов дизайна; • для придания динамики сайту используются скрипты, основанные на объектной модели DOM. Разветвление кода только в случае крайней необходимости; • атрибут повышения доступности и тестирование. Рекомендации Строгая совместимость рекомендуется для всех сайтов с малым числом посетителей, использующих браузеры версии 4.0 или ниже. При этом содержимое сайта все равно останется доступным даже для таких пользователей, но может несколько пострадать модель поведения и внешний вид. Преимущества: • более высокая степень совместимости с существующими PI будущими браузерами и беспроводными устройствами; • легкий переход к более продвинутым формам основанного на XML кода; • рост аудитории при меньших трудозатратах;

Глава 2* Разработка и д

^таш

• нет необходимости в создании отдельных версий; • почти полное отсутствие проблем с доступностью. Контент созданного таким образом сайта обычно доступен все пользователям; • элегантный, простой,и логичный код; • более легкое, быстрое и дешевое создание и обслуживание. Благодаря снижению затрат на создание и поддержку сайта, маленькие бюджеты можно уберечь от истощения, а большие использовать для наполнения сайта контентом, дизайна, программирования, графики, фотографий, редактирования и тестирования юзабилити; • проще интегрировать сайт с системами управления контентом на базе шаблонов и динамической публикации; • благодаря CSS можно создавать дизайн, который невозможен при разметке с помощью таблиц HTML; • сайты будут работать в еще не созданных браузерах и устройствах. Недостатки: • в старых браузерах сайты будут выглядеть довольно просто; • поддержка браузерами CSS еще не идеальна. Могут потребоваться некоторые доработки; \ • некоторые приемы, легко выполняемые с помощью таблиц HTML, невоз' можно осуществить с помощью CSS. Поэтому, возможно, потребуется переосмыслить определенные дизайнерские идеи; • некоторые в целом совместимые со стандартами браузеры (например, Opera до 7 версии) могут некорректно обрабатывать скрипты, основанные на модели DOM; • динамические модели сайта на базе DOM не будут работать в браузерах 4.0 и более ранних версиях, а также в программах для чтения информации с экрана, текстовых браузерах и в большинстве беспроводных устройств. Для обеспечения функциональности в этих устройствах и браузерах потребуется использовать теги < n o s c r i p t > и возможности CGI. Во второй части книги объяснены принципы работы стандартов (отдельно или совместно друг с другом), а также предложены советы и приемы для решения дизайнерских и финансовых проблем, связанных с различными путями развития Сети. Но, перед тем как погрузиться в этот вопрос, давайте сделаем небольшую паузу и рассмотрим некоторые вопросы, наверняка уже назревшие у вас.

Куда двигать

мое?

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

Г Я Ш 1. Неприятности со стандартами eb-стандарты являются ключевым фактором в разработке доступных, экономически эффективных Web-сайтов. Однако изучение значительной части существующих в течение последних нескольких лет сайтов не натолкнет вас на такую мысль. В этой главе мы попытаемся рассмотреть, почему использование Web-стандартов не стало повсеместно распространенной практикой среди Web-дизайнеров. Если вы хотите прежде познакомиться с историей успешных Web-стандартов, перейдите к главе 4. Если вы уже сейчас поняли преимущества стандартов и готовы приступить к работе, переходите к главе 5. Если же вы хотите набраться побольше сведений о стандартах для дальнейшей их пропаганды среди ваших коллег, или просто желаете понять, как Web-индустрия может принимать стандарты, но не использовать их - эта глава для вас.

Красивый сайт, ужасный код В середине 2002 года я вместе с шестью другими специалистами входил в жюри восьмой ежегодной церемонии награждения Communication Arts Interactive Awards (www.commarts.com), одного из наиболее престижных конкурсов в Webиндустрии. Представленные на конкурсе сайты и проекты были одними из лучших образцов дизайна и разработки. В качестве жюри мы провели 10 недель, просматривая тысячи Web-сайтов и компакт-дисков и сводя число участников до сотни финалистов, из которых получить награды должны были менее 50 участников. Отбор победителей проходил в Сан-Франциско, где мы попали в своеобразное недельное заточение нам нельзя было покидать город до объявления победителей. В конце недели мы назвали 47 победителей и были отпущены на свободу.

Красивый сайт, ужасный коц

Чтобы отпраздновать это событие (и вновь обретенную свободу), я решил встретиться со своим другом, проживающим в этих местах. Мой приятель заинтересовался этим конкурсом, так как в некоторой степени интересовался развитием Web. Он спросил, снижали ли мы оценки сайтам, не совместимым со стандартами. Я ответил, что абсолютно все представленные на конкурс сайты не были совместимы со стандартами. Это правда. Из тысяч рассмотренных Web-сайтов ни один не был создан с помощью верного, структурного HTML-кода. Многие сайты обладали великолепным визуальным дизайном (рис. 3.1) и были виртуозно запрограммированы (рис. 3.2), некоторые отличались выдающимся контентом, а другие были просто оригинальны до невозможности. Но ни один сайт не мог похвастаться структурным кодом, компактным CSS или написанными на основе стандартов скриптами. Более половины рассмотренных нами сайтов были полностью созданы на Flash. Остальные полнофункционально работали только в IE 4 и Netscape 4. Многие были оптимизированы под Windows. Сто лучших сайтов, большинство из которых обошлись своим создателям в кругленькую сумму, с пренебрежением отнеслись к существующим Web-стандартам. И это были лучшие профессиональные сайты отрасли.

Общие цели - общие средства Представленные на конкурс Communication Arts Web-сайты отличались друг от друга своими творческими и маркетинговыми задачами. Но у всех была одинаковая цель - такая же, как и у моего или вашего сайта. Мы все хотим, чтобы наши сайты привлекли внимание потенциальной аудитории, подтолкнули посетителей на определенные действия, были легкими для понимания и использования, формировали у посетителя хорошее мнение о нашей организации, продукте или услуге не только на словах, но и благодаря тому, как выглядит и работает сам сайт. Большинство из нас стремится получить по максимуму в обмен на потраченные средства. Мы хотим, чтобы наш сайт работал в как можно больших средах и был доступен для максимального количества пользователей. Мы стараемся избежать появления возможной несовместимости с различными браузерами и платформами и быть хотя бы на шаг впереди технологического прогресса. Большинство из нас надеется создать сайт, который продолжит работать и в браузерах будущего без необходимости дополнительной настройки и

Глава 3. Неприятности С0 стандартами

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

Восприятие против реальности По какой-то причине некоторые дизайнеры, так же как и в случае с обеспечением доступности сайта (глава 14), ошибочно полагают, что Web-стандарты какимто образом противоречат или являются противоположностью хорошему графическому дизайну. Кроме того, сами создатели стандартов прикладывают очень

Рис. З.2. Еще один победитель -Web-сайт World Resources Institute (http://earthtrends.wri.org) обладает неплохим дизайном, грамотно запрограммирован, но опять же не использует Web-стандарты

мало усилий для их пропаганды. Довольно ущербные сайты W3C или ЕСМА (European Computer Manufactyrers Association) - рис. 3.3 - вряд ли смогут вдохновить художников и дизайнеров. Соответственно, внешний вид W3C или ЕСМА не способен развеять миф о том, что стандарты противоречат визуальному дизайну. Изменить такую точку зрения под силу только красивым Web-сайтам, созданным по стандартам (рис. 3.4). Еще одной причиной малого распространения Web-стандартов является то, что дизайнеры и разработчики, изучившие всевозможные традиционные средства создания сайтов и использования запатентованных технологий, не видят смысла в изучении чего-то нового. Либо они просто слишком заняты, чтобы учить JSP, ASP или .NET. У тех же дизайнеров, кто привык использовать WYSIWYG-редакторы для создания сайтов, имеются свои причины.

Глава 3« I

эта»!и

Рис. 3.3. Организация ЕСМА является создателем стандартов и домом для многих гениальных умов. Тем не менее сайт ассоциации далек от совершенства в плане графика, структуры и удобства для пользователя. Таким образом, сайт ЕСМА (www.ecma.ch) вряд ли вдохновит многих разработчиков на изучение ECMAScript

А именно - их зависимость от WYSIWYG-редакторов. Они могут даже не знать о том, что последние версии таких программ уже поддерживают стандарты. Естественно, такими программами, как Dreamweaver и GoLive, пользуются многие квалифицированные дизайнеры, однако они популярны и среди полуобразованных создателей сайтов, которые не смогут создать даже самую простую страницу без помощи подобных средств. И наконец, еще одной причиной является то, что популярные браузеры только относительно недавно предложили пользователям серьезную поддержку стандартов. Многие Web-дизайнеры настолько привыкли делать свою работу старыми методами, что они просто не заметили, как браузеры изменились. Давайте рассмотрим эту причину в первую очередь.

2000: год появлении новым I

эв

Рис. 3.4. Сайт Kaliber 10000 (КЮк) является популярным порталом о дизайне (www.k10k.net), построенным с помощью XHTML, CSS и W3C DOM. Использование стандартов сайтом с достойным дизайном является хорошим примером при пропаганде Web-стандарта в

2000: год появления новых браузеров С появлением в марте 2000 года IE 5 Macintosh Edition мир (по крайней мере, часть мира, использующая Мае) наконец-то получил нечто большее, чем дразнящий призрак стандартов. IE 5/Мас поддерживал XHTML, ECMAScript, почти все спецификации CSS1, многие спецификации CSS2 и большую часть модели DOM. Также 1Е5/Мас мог отображать сырой код XML, хотя непонятно, кому это могло понадобиться. (Дополнительные сведения об этом можно найти в главе 5 или на сайте Bugzilla - http://bugzilla.mozilla.org/show_bug.cgi?id=64945).

IE 5/IVIac: переключение и увеличение IE 5/Мас был настолько приспособлен к стандартам, что он мог изменять отображение и выполнение страницы согласно < ! DOCTYPE>, указанному в начале

Fnaea 1. Неприятности со стандартами

кода страницы. Такая техника получила название «переключение DOCTYPE». Более подробно этот прием мы обсудим в главе 11. В целом, благодаря корректному использованию DOCTYPE, страница будет отображаться и функционировать, как ей указывают Web-стандарты. При использовании старого или частичного DOCTYPE страница будет отображаться в обратно-совместимом режиме, позволяющем избежать ошибок работы устаревших, несовместимых со стандартами сайтов, число которых в Сети составляет порядка 99,9% (рис. 3.5).

Рис. З.5. Здравствуй мир, это IE 5 Macintosh Edition, первый в мире браузер, практически безошибочно поддерживающий Web-стандарты. Некоторые использованные в нем инновации затем были применены в конкурирующих продуктах (www.microsoft.com), но, к сожалению, не все

В IE 5/Мас также была применена опция Text Zoom (рис. 3.6), позволяющая пользователям увеличить или уменьшить любой текст на странице, независимо от того, каким образом задан его размер. Это решало одну из важнейших проблем доступности. До IE 5/Мас подобной возможностью обладал лишь браузер Opera, позволявший увеличить всю страницу, включая изображения. Такой подход также имел свои плюсы, так как давал возможность избежать разрыва страницы при изменении масштаба и сохранить дизайнерскую задумку (рис. 3.7-3.9).

2000: год к&

юв

Рис. 3.6. IE 5/Mac Text Zoom в действии. С помощью выпадающего меню или «горячей» клавиши пользователи могли приблизить либо отдалить любой текст на странице, независимо от способа, которым был задан размер шрифта. Размер изображений и других элементов при этом не менялся

Смелый шаг Netscape Вслед за появлением IE 5/Мас было выпущено множество совместимых со стандартами браузеров. Netscape б и Mozilla поддерживали XML, XHTML, CSS, ECMAScript и DGM на всех платформах. Netscape также использовал переключение DOCTYPE и Text Zoom и был переписан с нуля как полностью совместимый со стандартами браузер. Для достижения полной совместимости со стандартами компания Netscape решительно отмела в сторону имеющийся код браузера Navigator/ Communicator 4.0 и решила начать создание новой версии с нуля. Естественно, этот процесс занял гораздо больше времени, чем простое обновление имеющегося браузера. Netscape потеряла значительную рыночную долю за период разработки Mozilla/Netscape б, начавшейся в 1998 году и закончившейся релизом браузера в 2000 году (на самом деле жизнеспособный продукт появился лишь в 2002 году).

Глава 3, I

гнбсти со стандартами

Рис. 3.7. Сайт популярного портала о дизайне PixelSurgeon (www.pixelsurgeon.com/news), открытый в Opera 7 в натуральную величину

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

Путь открыт Затем появился браузер Opera б - без переключений DOCTYPE и DOM, однако с поддержкой других основных стандартов. В Opera отсутствовала поддержка переключений DOCTYPE, так как ее создатели всегда придерживались намерения отображать страницы согласно спецификациям W3C. Поэтому

2000; год появлении новым браузеров

Рис. З.8. Тот же сайт с увеличением 200% при помощи инновационных возможностей Opera. Эта опция позволяет приблизить не только текст, но и графические элементы, например небольшие кнопки, и прочитать надписи

производители Opera не позаботились о поддержке режимов обратной совместимости. (Opera 5 и 6 не поддерживали W3C DOM, Opera 7 2002 года выпуска поддерживает этот стандарт.) Наконец Microsoft выпустил IE б под Windows. Браузер очень похож на коллегу под Macintosh в плане поддержки CSS, XML, ECMAScript и DOM и, так же как и IE5/Mac, Mozilla и Netscape 6+, поддерживает переключение DOCTYPE. В IE 6/Windows отсутствует функция Text Zoom, но, несмотря на всю привлекательность с точки зрения доступности, эта функция является скорее новшеством, чем стандартом. ВIE6/Windows была неправильно реализована функция фона CSS и требовала исправлений ошибка, вызывавшая сбой разметки CSS при использовании свойства f l o a t . Тем не менее браузер IE6/Windows был сделан довольно неплохо, соответствовал стандартам, а его предшественник IE5.x/Windows также стал довольно популярным продуктом. Ни один их этих браузеров не был идеальным, как не бывает таковым ни один программный продукт, но каждый из них демонстрировал огромные достижения

Глава 3, i

мшшш

и желание добиться совместимости через Web-стандарты. Никто из нас, даже в Web Standards Project, не мог представить себе, что эти компании сделают так много. После того как популярные браузеры наконец-то достигли соответствия в поддержке стандартов, дизайнеры и разработчики могут более уверенно пользоваться CSS и другими стандартными технологиями. 2 0 0 0 - 2 0 0 1 : авангард стандартов. Еще до выпуска IE 6 / W i n d o w s многие дизайнеры и разработчики начали создавать сайты с разметкой CSS и другими стандартными приемами, включая скрипты на базе D O M . Некоторые делали это, используя некоторые ухищрения, позволяющие IE 5 / W i n d o w s корректно отображать CSS, и отключая CSS в браузерах четвертой версии. Другие создавали разметку, позволявшую всем браузерам отобразить хоть что-то, но сохраняя полную версию для новых версий браузеров. Более подробно об этом авангарде дизайнеров мы узнаем из главы 4, а о методах их работы и приемах - из второй части книги.

Слишком шало, слишком поздно?

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

CSS: первый сбой бесплатно Впервые описание CSS 1 было опубликовано в канун Рождества 1996 года. Спустя несколько месяцев на свет появился IE3, среди прочих особенностей которого можно отметить зачаточную поддержку CSS. Учитывая это, а также полное отсутствие поддержки CSS в Netscape 3, браузер от Microsoft получил первые лестные отзывы в свой адрес на фоне полного господства в сети Netscape Navigator. Поддержка CSS в IE 3 позволяла отказаться от устаревших тегов <f ont> и начать экспериментировать с разметкой CSS. Вдохновленные демонстрационной страницей от Microsoft (рис. 3.10), показавшей возможности CSS, многие дизайнеры совершили первый заплыв в мир CSS и вскоре были вынуждены вернуться из-за нехватки воздуха. Поддержка CSS в IE 3 была первым шагом, и, как это обычно бывает, он оказался неполным и не лишенным недостатков. Энтузиазм, вызванный новыми возможностями CSS, довольно быстро сошел на нет, так как ошибки в IE 3 могли привести к тому, что страница попросту не будет отображаться. Например, при некоторых обстоятельствах изображения на страницах с CSS отображались не рядом с текстом, а накладывались на него, что делало просмотр страницы невозможным. Чтобы представить себе такую ситуацию, положите*руку на страницу и попробуйте прочитать текст сквозь нее. Решением этой проблемы было размещение текста и каждого изображения в отдельной ячейке таблицы, что увеличивало размер страницы, тогда как предназначением CSS был совершенно противоположный результат. Вскоре дизайнеры пришли к выводу, что CSS не является готовым к употреблению продуктом, что стало логичным объяснением полного отсутствия поддержки CSS в безусловном лидере - Netscape 3.

100

Глава 3

I си станд

Рис. 3.10. Страница галереи Microsoft CSS 1998 года (http://www.microsoft.com/typography/css/ gallery). Текст и изображения внахлест были созданы только с помощью CSS, без GIF- или JPEG-файлов. Несмотря на то что совместимость IE 3 со стандартом CSS практически отсутствовала и для создания демонстрационной страницы использовались некорректные значения, тем не менее джин был выпущен из бутылки. Увидев возможности CSS, многие из нас уже никогда не оглядывались назад

Плохие браузеры - плохие сайты Затем появились браузеры версии 4.0. Поддержка CSS в IE 4 по сравнению с IE 3 значительно улучшилась, хотя и оставалась неполной и вызывала ошибки. Создатели Netscape 4 ввели в свое творение поддержку CSS в самую последнюю минуту, поэтому она оказалась на уровне двухлетней давности. Справедливости ради следует отметить, что поддержка CSS в Netscape 4 намного превосходила IE 3 (http://www.webreview.com/style/cssl/leaderboard.shtml). Учитывая то, что уже никто не пользуется IE3, но число поклонников Netscape 4 довольно велико, многие владельцы сайтов считают своим долгом обеспечить их совместимость с Netscape 4. Однако, вместо того чтобы обеспечить

Плохие браузеры ~ плохие сайты

101

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

Проклятие устаревшего отображения Имея цель абстрагировать оформление от структуры, CSS не делает предположений о том, как должны быть расположены элементы на экране или какой язык разметки вы собираетесь использовать, несмотря на то что браузеры и другие программы пользователей обычно делают такие суждения. (Некоторые современные браузеры с помощью CSS создают подобные предположения и позволяют таблицам стилей дизайнеров управлять ими.) По умолчанию в большинстве браузеров заголовок <hl> будет отображен крупным и жирным с вертикальными отступами сверху и снизу, если иное не описано в таблице стилей. С помощью CSS все это можно изменить. Описанный в CSS-таблице заголовок <hl> может быть мелким, выделен курсивом и без отступов, если так захочет дизайнер. Но только не в Netscape 4, который добавляет свое правило отображения для каждого CSS-параметра, использованного дизайнером. Если CSS говорит, что вокруг заголовка не должно быть отступов, Netscape 4 все равно вставит их туда. В процессе работы дизайнеры быстро обнаружили, что при добавлении CSS к коду HTML IE 3 показывает то, что от него требуется, тогда как Netscape 4 делает из их разметки полную неразбериху. В связи с этим некоторые дизайнеры отказались от использования CSS. Другие (включая меня) вначале пытались решить подобные проблемы, используя конструкции вроде <div c l a s s = " h e a d l i n e l " > вместо <hl>. Это помогало решить проблему в ущерб структуры документа и его семантики, таким образом создавая первые проблемы на пути к будущей совместимости сайта и вызывая множественные сопутствующие неприятности. Автор книги уже давно отказался от практики создания нелогичной структуры всего документа, но многие дизайнеры и разработчики и по-прежнему создают кривой код в угоду совместимости с Netscape 4. Эта распространенная практика ведет к фатальным ошибкам, создает проблемы с удобством использования и мешает попыткам нормализовать и стабилизировать обмен данными в Сети. Системы управления контентом, средства публикации и визуальные Web-редакторы (WYSIWYG), разработанные в эпоху браузеров четвертой версии, заставляют использовать устаревший бессмысленный код, повышая сложность и стоимость процесса приведения сайтов к совместимости с современными

102

" Гнаеа 3. Ш-

спя со о

стандартами и базами данных XML. Над созданием крупных сайтов часто трудятся несколько дизайнеров, каждый из которых использует свои любимые нестандартные теги, из-за чего просто невозможно собрать все данные и отформатировать их для более удобного использования. (Такое положение вещей можно сравнить с библиотекой, в которой книги рассортированы не по алфавитному порядку, а по разным системам каталогизации нескольких людей.) За пределами области графических браузеров такой неструктурный код также делает страницу менее доступной. Для пользователей Palm Pilot, мобильного телефона или программы для чтения текста с экрана <div c l a s s = " h e a d l i n e l " > является простым текстом, а не заголовком* Таким образом, мы создаем или покупаем систему управления контентом, которая заменяет одни теги на другие, тогда как мы могли бы обойтись использованием одного набора стандартных тегов. Или же мы обрекаем пользователей Palm Pilot, сотовых телефонов и программ для чтения информации с экрана на просмотр нашего запутанного кода и гадание, что бы он мог значить. Во всех этих неурядицах мы могли бы обвинить Netscape 4 и наше собственное желание приспособиться к его ошибкам. Неудивительно, что специалисты Netscape и Mozilla работали четыре года над созданием нового продукта с нуля достойного браузера, на который можно было бы опереться, у них просто не было.

Наследование Создателям Netscape 4 также не удалось осознать всю важность и воплотить в жизнь поддержку наследования - замечательной концепции, лежащей в основе могущества CSS. Ведь CSS облегчает производство сайтов и снижает трафик, позволяя использовать общие правила во всех документах по нисходящей, если дизайнером не будет указано иначе. Например, с помощью CSS можно назначить шрифт, размер и цвет тега <body > документа, и эти же параметры будут применены ко всем дочерним элементам этого тега начиная с <hl> и заканчивая <р>, но только не в Netscape 4. В Netscape 42 + 2 = 2 + 2,а не 4. Некоторые дизайнеры обошли этот недостаток, используя устаревшие правила такого типа: body, td, serif; }

hi, p

{font-family: verdana,

a r i a l , helvetica,

sans-

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

Плохие браузеры - плохие сайты

103

Менее находчивые дизайнеры записывали данное правило в несколько строк, еще более «замусоривая» код и увеличивая трафик: body td hi p

{font-family: {font-family: {font-family: {font-family:

verdana, verdana, verdana, verdana,

arial, arial, arial, arial,

helvetica, helvetica, helvetica, helvetica,

sans-serif;} sans-serif;} sans-serif;} sans-serif;}

и так далее. Естественно, трафик возрастал, но задача была выполнена. Другие разработчики сделали вывод, что CSS попросту не работал в Netscape 4 (что имело смысл) или CSS был недоделан (что было неверно, но объяснимо). Помимо перечисленного, у Netscape 4 имелись и другие огрехи в поддержке CSS, однако и описанного нами достаточно для общего представления ситуации. Этого также было достаточно, чтобы заметно отсрочить повсеместное распространение стандарта CSS.

Поведение Помимо неразберихи с CSS, ранние версии браузеров по-разному интерпретировали динамическую модель сайта, реализованную на скриптах. Каждый браузер обладал свойством Объектная Модель (Object Model), определяющим, какой тип поведения можно присвоить каждому объекту на странице. Netscape 4 использовал запатентованную модель document. l a y e r s . В IE 4 применялась собственная модель document . a l l . Ни один из браузеров не поддерживал спецификацию W3C DOM, потому что она еще не была создана. Соответственно, разработчикам, желавшим присвоить странице определенную модель поведения, приходилось делать это двумя способами, чтобы подстроиться под IE 4 и Netscape 4. Поддержка более ранних версий требовала дополнительных уловок. Ранние версии браузеров не могли достигнуть согласия даже относительно используемого языка написания скриптов. Например, когда в Netscape изобрели JavaScript, они обещали сделать его стандартом, доступным для всех. Однако по какой-то причине компания несколько лет удерживала спецификации JavaScript в секрете, считая это своим тайным оружием и коммерческим преимуществом перед конкурентами. (Они полагали, что если Navigator останется единственным поддерживающим JavaScript браузером, то зачем кому-то понадобится создавать сайты для других браузеров. Кстати говоря, спустя некоторое время Microsoft прибегла к такой же тактике со своей технологией ActiveX.) Компания Microsoft в ответ создала свой язык, назвав его JScript. Он работал почти так же, как JavaScript, но все же не совсем так. Новый язык отличался от JavaScript достаточно сильно, чтобы запутать дизайнеров. Одновременно

104

Глава 3. Неприятности се ст

ами

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

Время стандартных скриптов пришло В конце концов ЕСМА приняла за стандарт JavaScript, который они скромно назвали ECMAScript (www.ecma.ch/ecmal/STAND/ECMA-262.htm). Затем W3C приняла стандарт DOM. Наконец-то Microsoft и Netscape стали поддерживать одинаковые стандарты! Однако этому предшествовало длительное противостояние, из-за которого многие дизайнеры превратились в экспертов по запатентованным технологиям и несовместимым скриптам, а Web-дизайн стал ассоциироваться с непрекращающейся головной болью. Появились сайты «только для IE», не работающие скрипты определения версии браузера пользователя и отказ от стандартов в пользу запатентованных технологий вроде Flash. Кстати, если вы хотите узнать, как расшифровывается аббревиатура ЕСМА, не пытайтесь найти ответ на запутанном сайте организации (рис. 3.3). ЕСМА означает Европейская ассоциация производителей компьютеров (European Computer Manufacturers Association). Она устанавливает стандарты в мире компьютеров, в отличие от проекта W3C, который называет некоторые технологии всего лишь рекомендациями, а не стандартами.

Сбивающие с толку сайты и ставящие в тупик названия Посмотрите на описание CSS 2 на сайте W3C (рис. 3.11). CSS 2 является мощным средством для дизайнеров, позволяющим облегчить их труд, однако такая мысль не придет в голову при просмотре этой страницы. Эта страница настолько же не впечатляет, насколько и домашняя страничка вашего соседа, которую он сделал за одно утро, воспользовавшись Microsoft FrontPage и редактором картинок за $50. Но, допустим, что вы, не обращая внимания на растущее неприятное чувство, все же решили прочитать и понять приведенные на сайте спецификации,

Civ

сайты ш ставящие е тупим твзшшмшш

105

Рис. 3.11. Описание CSS 2 на сайте W3C (www.w3..Grg/TR/REC-CSS2)

несмотря на непривлекательный внешний вид страницы. Все-таки W3C объединяет ученых, а не дизайнеров, так ведь? Главное - это информация. После двадцати минут чтения, вздыхая и потирая глаза, вы, скорее всего, откроете сайт Internet-магазина и купите Macromedia Flash. По правде говоря, специалисты W3C не только не могут создать хороший графический дизайн, удобный для использования сайт или хорошую структуру информации, но они также и не способны написать руководства, ориентированные на дизайнеров. Сайт W3C является лишь подборкой сухих научных спецификаций и описаний технологий. В статье «Как читать спецификации W3C» (www.alistapart.com/stories/ readspec) Дэвид Эйзенберг объясняет это так: «Когда вы ищете ответы и хотите научиться использовать технологию, вам требуется руководство пользователя или справочник. Но это не является целью спецификаций W3C. Задача

106

Глава 3L Неприятности С0 с

ами

спецификации - объяснить программистам, которые будут внедрять данную технологию в браузеры, какие функции она должна содержать и как их следует внедрять. В этом отличие спецификации от руководства пользователя». По определению, информация на сайте W3C предназначена разработчикам программного обеспечения, а не широкой общественности. Организация не пытается красиво преподнести или доступно объяснить стандарты, которые она создает. Она даже не называет их стандартами, хотя именно ими они и являются. В отличие от коммерческих организаций, W3C не получает прибыль или дивиденды от использования Web-стандартов и даже порицает компанийучастников проекта за подобные попытки (http://www.w3.org/TR/2002/ WD-patent-policy-20021114).

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

Консорциум предполагает, компании предлагают В реальном мире, когда перед нами стоит проблема или задача, обычно мы открываем подходящее программное обеспечение и начинаем решать проблему (задачу). Владельцы сайтов наблюдают за посетителями сайта, просматривая статистику, отформатированную в Microsoft Excel, дизайнеры создают логотипы в Adobe Illustrator, анимацию - в Macromedia Flash, изображения и разметку - в Adobe Photoshop. Для каждой задачи существует определенная категория программ, и в каждой категории есть свой признанный лидер.

Сби

ч названия

107

Несмотря на то что многие дизайнеры-пионеры индустрии создавали свои сайты в программах Notepad или SimpleText, многие их последователи стали полагаться на визуальные редакторы (средства WYSIWYG-разработки). По мере того как создание сайтов становилось все более сложным процессом из-за появления запатентованных языков и несовместимых объектных моделей, такие программы, как Macromedia Dreamweaver и Adobe GoLive, помогали многим дизайнерам создавать прекрасные сайты любой сложности. Каким образом достигалась совместимость с разными браузерами? Нажатием той или иной кнопки. Всю остальную работу проделает сама программа. Эти признанные визуальные редакторы были очень мощными и функциональными. Но до недавнего времени создаваемый ими код имел очень слабое отношение к стандартам. Так же как и сами разработчики, программы типа Dreamweaver и GoLive создавали ориентированные на конкретные браузеры скрипты и нестандартные семантические структуры кода. Dreamweaver MX и GoLive б являются гораздо более совместимыми со стандартами, чем предыдущие версии, хотя они и требуют некоторых навыков разработки сайтов. А откуда берут знания пользователи подобных программ? Они обращаются за примером к привлекательным, хорошо написанным сайтам, служащим руководством пользователя и одновременно фактором, способствующим росту сообщества почитателей Dreamweaver и GoLive. Давайте более подробно поговорим о таких сайтах.

Результат против стандартов По мере того как компании старались предоставить пользователям готовые решения для создания сайтов высочайшего уровня, то же самое происходило и на более низком уровне. Запатентованные средства публикации и базы данных от крупнейших производителей вроде IBM, Sun, Lotus и Microsoft и небольших компаний вроде Allaire (ставшей частью Macromedia) предлагали необходимые функции в то время, когда стандарты типа XML и DOM еще только обсуждались и не были приняты. Для того чтобы обзавестись автомобилем, не обязательно проектировать его с нуля, так зачем же создавать ваш сайт подобным образом? Зарегистрируйтесь, купите его, и, если что-то не работает, это будет исправлено при следующем обновлении. Для дизайнеров, перед которыми проявляются крайние сроки завершения работы, такой подход может быть вполне привлекательным, так же как когда-то имело смысл обращаться с HTML как с дизайнерским инструментом - иными словами, этот подход немедленно решает все пожелания заказчика.

108

Глава 3, Неприятности со стандартами

Таким образом, Web-разработчиков, а тем более Web-дизайнеров, скорее волновал конечный результат, а не Web-стандарты. На каждого дизайнера, посетившего и прочитавшего сайт W3C, было 10, почерпнувших свои знания с сайтов Netscape, Microsoft, Macromedia (рис. 3.12), Adobe (рис. 3.13) и других крупных (и умных) компаний.

Рис. 3.12. Так же как и W3C, Macromedia создает бесценные инструменты для дизайнеров и разработчиков (www.macromedia.com). Однако, в отличие от\Л/ЗС, Macromedia продает и прикладывает усилия для развития их популярности

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

цщие с толпу сайты и ставящие в тупим mas

109

Рис. 3.13. Так же как и Macromedia, конкурирующая с ней компания Adobe (www.adobe.com) постоянно общается со своими потребителями, узнавая об их нуждах и потребностях. Компания также старается говорить на языке дизайнеров

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

110

Глава 3. Неприятности со стандартами

Слова на букву «F» Из всех запатентованных технологий и продуктов, которые пытались продать крупные корпорации, ни один не добился такого успеха, как Macromedia Flash (рис. 3.14). Карьера Flash началась со скромного модуля FutureSplash, позволявшего дизайнерам вставлять в страницы векторную графику и анимацию.

Рис. 3.14. Добро пожаловать в мир Macromedia Flash! Рабочая среда продукта может быть сложной, глубокой и предоставляющей широкие возможности, но Macromedia сделала все, чтобы взять дизайнеров за руку и не отпускать в течение всего процесса их работы "с Flash

Вначале дизайнеры не обратили особого внимания на FutureSplash, но Macromedia сразу распознала потенциал данного продукта. Компания выкупила права на этот модуль и переименовала его в Flash. Затем на базе похожего на JavaScript языка программирования - ActionScript - была создана полноценная среда для создания графики, которая и легла в основу Flash. Macromedia также удалось создать целый культ поклонников Flash, создающих мультфильмы, яркие презентации и поражающие своей функциональностью и динамикой Web-приложения.

Ценность Flash В то время как несовместимые языки программирования и Объектная модель браузеров четвертой версии наводили хаос и панику на просторах Сети, Flash 4

€H0!

41 Jf «р»

111

и ее мощный язык скриптов работали одинаково хорошо и в Navigator, и в IE, и в Opera. И почти так же хорошо на платформах Mac Os, Linux, Unix, как и в Windows. Для многих дизайнеров это означало расставание с HTML и CSS и переход на Flash. Крутящиеся логотипы, утомительные экраны с надписью Загрузка, нескончаемые, надоедливые заставки и вступления - все это поначалу сказалось на нехорошей славе Flash среди пользователей. Однако вскоре дизайнерам надоело играться с возможностями Flash и стали появляться изысканные сайты наподобие One9ine (рис. 3.15), Juxt Interactive (рис. 3.16) и другие образцы умелого использования Flash. Спохватившись, многие дизайнеры и разработчики тоже поспешили вскочить на уходящий поезд Flash, зачастую второпях создавая не такие функциональные проекты, но винить в этом Flash нельзя, так же как нельзя списывать плохую работу неумелого столяра на молоток и гвозди. Flash пожирала Сеть, так же как браузер Microsoft завоевывал рыночную долю Netscape.

112

Гиава 3. Неприятности со стандартами

Несмотря на полную уместность в некоторых проектах, технология Flash был непригодна для многих сайтов, использующих ее. Она также вызывала и вызывает много вопросов относительно доступности и юзабилити, волновавших пользователей, но не замеченных дизайнерами. Одним из наиболее ярых критиков Flash является Джейкоб Нильсен (Jacob Nielsen) из консалтинговой группы Nielsen Norman (http://www.useit.com). В 2002 году Macromedia решила разобраться с этими проблемами, улучшив доступность и удобство использования в обновленном продукте Flash MX и наняв Нильсена в качестве консультанта. (Если бы Microsoft и Netscape проявили бы подобную мудрость и привлекли на работу своих критиков, возможно, мне бы не потребовалось писать эту книгу.)

Снова «а букву «F»

113

В умелых руках Flash значительно облегчает достижение целей, которые было бы трудно создать с помощью стандартного кода, CSS, SVG (Scalable Vector Graphics) и DOM. Что такое SVG. SVG является приложением XML и стандартом векторной графики, поддерживающим анимацию и скрипты и полностью совместимым с другими Webстандартами. Однако во время написания данной книги ни один из браузеров не поддерживал SVG по умолчанию. Для этого требовалось использование дополнительного модуля, так же как и для Flash. (Браузер Amaya консорциума W3C в определенной степени поддерживает SVG, также некоторые разновидности Mozilla могут быть скомпилированы с поддержкой SVG, но эти продукты никак нельзя назвать популярными.)

В настоящее время для создания сложных, запоминающихся приложений и интерфейсов легче это выполнить во Flash, благодаря единой среде разработки и огромной устанавливаемой базе исходных средств. В будущем, возможно, более логично будет решать подобные задачи, используя сочетание XML, XHTML, CSS, ECMAScript, SVG и DOM.

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

114

Глава.

юи со стандартами

Другие проблемы с Flash Еще одна загвоздка с использованием Flash заключается в том, что некоторые дизайнеры настолько влюблены в эту технологию, что забывают про использование Web-стандартов, если вообще когда-то об этом помнили. В результате появляются сайты на Flash, которые работают только в одном или двух браузерах. Сама по себе технология Flash работает в любом браузере, в котором есть подключенный модуль для ее просмотра, однако некоторые сайты сделаны настолько скверно, что многие пользователи просто не могут получить доступ к Flash-содержимому. Встречаются даже сайты, требующие использования IE только для отображения простой презентации Flash. Это все равно что требовать использовать телевизор Philips вместо Sony только для того, чтобы воткнуть в него антенный кабель. Когда же заказчик просит создать «традиционный» сайт, совместимый со стандартами, эти дизайнеры и агентства используют методы, уже рассмотренные нами, зачастую передавая заказ другой команде начинающих разработчиков, чтобы старшие профессионалы могли сосредоточиться на работе с Flash. Они, видимо, полагают, что Web не развивалась с тех времен, как они обнаружили существование Flash. И тем не менее XML, XHTML, CSS и DOM вовсе не являются простенькими технологиями для начинающих дизайнеров. Это мощные и сформировавшиеся стандарты, способные донести до пользователя любую задумку разработчика. Я не выступаю против агентств, специализирующихся на создании красивых, полнофункциональных проектов Flash. Просто я хотел бы увидеть такое же отношение и к остальным 90% методов дизайна и разработки.

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

Плохие слово «совместимость»

115

Сила языка влияет на восприятие Возможно, виной этому стала фраза «Web-стандарты». Члены проекта Web Standards посчитали данную фразу подходящей для пропаганды стандартов. Нам показалось, что благодаря этому словосочетанию нам удастся донести до разработчиков программного обеспечения, дизайнеров и пользователей всю важность необходимости внедрения этих технологий. Слово «рекомендации» для этого не подходило, а «стандарты» кажутся более уместным термином. У нас не было денег, одни лишь надежды, и тем не менее мы добились успеха. Сегодня компании вроде Netscape, Microsoft, Adobe и Macromedia борются за совместимость со стандартами, это стало ожидаемой и почти обязательной опцией любого программного обеспечения - так же как полный привод в автомобилях. Но, несмотря на то что многие компании поняли это, не все дизайнеры и разработчики последовали их примеру. Некоторые путают Web-стандарты с неким набором правил и рекомендаций по дизайну. Таким специалистам необходимо понять, что Web-стандарты не имеют никакого отношения к графическому дизайну и правилам создания внешнего вида сайта. Если же дело не в выражении «Web-стандарты», может быть виновато слово «совместимость». Дизайнеры хотят, чтобы их проекты были «совместимы» лишь с их творческим замыслом, а не с набором каких-то технических правил и регулировок. Нужно объяснить им, что эти правила не имеют никакого отношения к внешнему виду и облику сайта, они созданы лишь для того, чтобы браузеры пользователей могли отобразить всю ту красоту, о которой беспокоятся дизайнеры. Заказчики в свою очередь также хотят, чтобы их сайты отвечали настроениям клиентов и соответствовали не каким-то воображаемым стандартам внешнего вида сайтов, а стилю компании, поставленным маркетинговым целям. Им также не помешало бы узнать, что благодаря Web-стандартам их сайты станут лишь более доступными для разных браузеров и платформ.

Проблема вдохновения Возможно, дизайнеров и их заказчиков оттолкнул недостаток визуального дизайна на некоторых сайтах, посвященных Web-стандартам, или хвастовство других, часто даже более некрасивых сайтов, об их соответствии одному или нескольким спецификациям W3C. Однако дело здесь не в самих стандартах, а дизайнерах, создавших эти сайты. Конкурс Wthremix (рис. 3.17), начавший работу в декабре 2002 года, был призван заполнить этот недостаток эстетики. Организаторы конкурса так объяснили его цель: «W3C создает мощные стандарты и руководства, благодаря которым

116

Тпв

-i €© стандартами

развитие Web становится более рациональным и дружелюбным для пользователей. С помощью XML, CSS, XHTML, DOM и рекомендаций по доступности вроде Web Accessibility Initiative мы можем создавать более мощные сайты, одинаково хорошо работающие на компьютерах всех пользователей. Однако W3C состоит не из дизайнеров, думающих о пользователях, не из разработчиков, художников и писателей, а из настоящих зануд». В результате все ценные сведения W3C заключены в рамки скучнейшего, безликого сайта. Целью нашего конкурса была попытка выяснить, возможно ли сайт W3C преобразовать в красивый, хорошо структурированный и более удобный для использования и понимания продукт. WThRemxi ~ Design and Code Challenge

Плохое слово «с*

цяость»

117

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

Другие проблемы Некоторые специалисты не доверяют стандартам из-за негативного, опыта, полученного в результате использования первой версии Netscape б, имевшей ошибки, и IE 6, некоторые ошибки в котором не были исправлены и спустя год после выпуска. Некоторые люди, вдохновленные перспективами Web-стандартов, переделали свои сайты из HTML в XHTML лишь для того, чтобы обнаружить, что созданная разметка смотрится совершенно по-разному в Netscape 6+, Mozilla или IE 6. Мы объясним причины этого в главе 11 и предложим простые, быстрые решения для устранения подобных неприятностей. Но, если вы не знаете об этих простых приемах, очевидно, что у вас появится некоторое недоверие к стандартам и вы можете захотеть вернуться к проверенным методам, которые так хорошо отработаны в старых браузерах. Не надо сдаваться. Несмотря на то что невежество и предубеждение широко популярны не только в Web-дизайне, но и в других областях человеческой деятельности, Web-стандарты никуда не уйдут и наша книга поможет вам найти с ними общий язык.

режде чем двигаться дальше, следует преодолеть негативные эмоции, возможно возникшие при чтении предыдущих глав, когда вы знакомились с процессом возникновения и развития стандартов и следили за ростом их популярности. Несмотря на непонимание, сдерживающее их распространение, на некоторых фронтах Web-стандарты все же одержали победу. В этой главе мы познакомимся с самым популярным после HTML стандартом: XML - Extensible Markup Language (Расширяемый язык разметки). XML является всеобъемлющим форматом данных, используемым во всем мире для решения сложных задач. Мы узнаем, как XML помогает программным продуктам оставаться жизнеспособными на быстро меняющемся рынке, решает проблемы обработки данных и как он в конечном итоге привел к всплеску нового поколения межплатформенных Web-приложений и служб. Мы также увидим, как благодаря XML ослабела вражда и появилось некоторое сотрудничество между конкурирующими создателями браузеров, как программы для создания сайтов научились поддерживать стандарты, а персональные сайты передовых дизайнеров и разработчиков способствовали распространению CSS, XHTML и пропаганде соответствия рекомендациям доступности Web Accessibility Initiative (WAI) и Section 508. Каждая из этих историй успеха имеет одинаковую подоплеку: Web-стандарты становятся все более популярны благодаря их высокой работоспособности. Чем шире распространение стандартов, тем лучше они работают и тем проще станет наш труд.

Универсальный язык XML В главе 3 мы обсудили, как скверно реализованная поддержка стандартов в ранних браузерах привела к недоверию дизайнеров к стандартам, что сказалось на

Универсальный?

/11

119

росте популярности устаревших методов разработки и использования Flash вместо CSS, HTML и JavaScript. После прочтения этой главы у вас могло сложиться мнение, что Web-стандартам предстоит нелегкая борьба для достижения всеобщего принятия и верного использования. Как же обстоят дела с XML? Стандарт Extensible Markup Language (XML) был принят в феврале 1998 года и завоевал индустрию Web-дизайна штурмом (рис. 4.1). Впервые в истории был предложен универсальный, адаптируемый формат для структуризации документов и данных не только в Сети, но и за ее пределами.

Сравнение X M L и H T M L Несмотря на то что XML и HTML созданы по одной технологии и XML также использует теги, атрибуты и значения для форматирования структурированных документов, XML имеет довольно значительные отличия. HTML является простым языком для создания разметки Web-страниц. Он обладает фиксированным числом тегов и некоторым расплывчатым набором правил. В HTML следует закрывать некоторые теги, нельзя закрывать другие и по желанию можно закрывать или не закрывать остальные. Такая простота позволяет практически любому создать свою Web-страницу, знают ли они что делают или нет. Естественно, это было одной из идей создания HTML. Идея была превосходна на первых стадиях развития Web, когда сайты состояли из простого контента, большего и не требовалось. Но в современных сайтах, где страницы зачастую формируются с помощью средств публикации, а информация передается из базы данных на Web-страницу или на беспроводное устройство и принтер, скудность возможностей HTML препятствует круговороту данных. Легко преобразовать текст в HTML, но весьма проблематично преобразовать данные в формате HTML в какой-либо другой вид. Помимо того, HTML является лишь простым языком форматирования. Он не содержит сведений о контенте, что опять же ограничивает возможность использования данных в различных областях. И, естественно, HTML предназначен только для использования в Web. Основанная на XML разметка, в свою очередь, обладает устойчивыми правилами и может применяться далеко за пределами Сети. При разметке документа в XML он не просто готов к демонстрации в Web, он заключен в теги, которые распознает любая среда с поддержкой XML.

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

120

Рис. 4.1. «Смотри, XML повсюду». Запустите поиск файлов в любом Macintosh, и вы обнаружите сотни XML-файлов, многие из которых являются компонентами различных приложений. XML является Web-стандартом, шагнувшим далеко за пределы Web

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

; язык ЖШк

121

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

Необходимая составляющая профессионального и потребительского ПО Возможность форматирования, распознавания и обмена данными сделала XML таким же популярным и вездесущим, как Coca-Cola в своей отрасли. XML применяется не только в Internet или корпоративных базах данных, он стал общим языком как для программ, работающих с базами данных, например FileMaker Pro, а также для других программных продуктов, таких как Microsoft Office и OpenOfflce. Многие конфигурационные файлы этих программ представляют собой XML-файлы. Операционная система Macintosh OS X, созданная на базе Unix, хранит многие параметры конфигурации в файлах XML. Программы Quark Xpress 5.0 и Adobe InDesign 2.0 позволяют импортировать и экспортировать XML и поддерживают создание шаблонов на базе XML. Визуальные Web-редакторы вроде Macromedia Dreamweaver MX и Adobe GoLive 6 также работают с XML, что значительно облегчает обмен данными между Web-разметкой, базой данных и другими приложениями. Осознав все возможности XML, многие разработчики программного обеспечения создают свои продукты на этом языке. Программа Macromedia Dreamweaver MX состоит из множества XML-файлов, доступных для конечного пользователя (рис. 4.2-4.4), благодаря чему можно модифицировать само приложение путем изменения этих файлов (www.alistapart.com/stories/dreamweaver). Изменение конфигурации Dreamweaver таким способом и последующая продажа программы коллегам стала даже чем-то вроде нового типа домашнего бизнеса. В программном обеспечении для обычных пользователей также все чаще используется XML. Например, Personal Information Manager для PC, Mac или PDA позволяет открывать и сохранять файлы XML, или его можно научить этому с помощью продуктов вроде AElfred XML для Palm Pilot (wwwxml.com/pub/r/216).

122

Глава 4. XML завоевывает тшр

Рис. 4.2. Популярное приложение для создания Web-сайтов Dreamweaver MX состоит из множества конфигурационных файлов XML...

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

•

;

• '

•

Рис. 4.З. ...а также из GIF, HTML и JavaScript. Так же как и файлы Web-сайта, компоненты Dreamweaver рассортированы по каталогам

Даже приложения для управления и хранения фотографий вроде iPhoto (рис. 4.5) распознают XML. При печати фотографии получаются должным образом благодаря настройкам, хранящимся в виде данных XML в операционной системе Macintosh OS X.

Более популярно, чем MTV Почему язык XML завладел умами огромного числа производителей и нашел применение в их продукции? XML совмещает в себе стандартизацию с расширяемостью (широкими возможностями модификации), возможностью преобразований (способность преобразовывать данные из одного формата в другой) и практически неисчерпаемые возможности обмена данными между XML-приложениями. Являясь открытым стандартом, не ограниченным всевозможными патентами, XML сметает с пути устаревшие, запатентованные форматы с ограниченными возможностями. W3C не взимает с вас комиссионных, когда вы используете XML на своей Web-странице или в программном продукте. Более того, принятие и повсеместное использование XML являются жизненно необходимыми. Чем больше компаний будут использовать XML в своих продуктах, тем проще станет обмен данными между приложениями различных производителей.

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

124

Глава 4, XML. завоевывает мир

Рис. 4.4. Продвинутые пользователи Dreamweaver могут изменять эти файлы для модификации приложения. На этом рисунке показано, как пользователь изменяет используемые «горячие» клавиши, редактируя файл menus.xml

поддерживающее XML, делает это безукоризненно. Безукоризненно или нет, однако XML произвел переворот в индустрии создания программного обеспечения. Даже производители ПО, не поддерживающего XML, стали считать, что это нужно исправить. В апреле 2002 года разочарованная падением продаж и раздробленным рынком группа провайдеров интерактивного телевидения и

125

смежных технологий объединилась под именем iTV Production Standards Initiative. Целью союза стала поддержка стандарта XML для облегчения создания производителями единого интерактивного контента и возможности распространения его на все популярные платформы персональных компьютеров (www.allnetdevices.com/developer/news/2002/04/09/itv_firms.html). Где-то мы уже это слышали, не так ли? Именно это говорили участники Web Standards Project о стандартах W3C во времена войны браузеров в девяностых годах.

126

Глава 4. KML завоевывает тшр

Пять причин популярности X M L На просторах Internet XML продолжает набирать популярность среди ГГ-профессионалов, разработчиков и специалистов по контенту, которые работают с большими объемами данных в крупных корпоративных и некоммерческих системах. Среди причин, благодаря которым выбор падает на XML, можно перечислить следующие пять: • как и ASCII, XML является единым, универсальным форматом файлов, хорошо совместимым с другими; • в отличие от ASCII (или HTML), XML позволяет не только хранить данные, но и информацию о самих данных (метаданные), что облегчает некоторые функции, например поиск; • XML является расширяемым языком, способным к адаптации под различные нужды. Также XML позволяет создавать другие языки на его основе для выполнения специфических задач, например для объединения данных и обеспечения работы Web-служб; • язык XML создан на основе правил, которые обеспечивают целостность данных при их переносе между базами данных, преобразовании в другие форматы или использовании другими XML-приложениями; • с помощью дополнительных XML-протоколов и вспомогательных XMLязыков XML-данные можно автоматически преобразовывать в многочисленные форматы - от Web-страниц до оптимизированных для печати документов. О такой возможности разработчики могли лишь мечтать до появления XML.

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

Я з ы к преобразований X S L T Язык преобразований XSLT (Extensible Stylesheet Language Transformations, www.w3.org/TR/xslt), основанный на XML, позволяет извлекать и сортировать XML-данные и форматировать их как HTML или XHTML, после чего они становятся готовы к просмотру в Web. При необходимости XSLT может преобразовать

127 данные в формат PDF, текстовый файл или использовать их для постоянного обновления некой таблицы, диаграммы или других изображений в формате Scalable Vector Graphics (SVG). С помощью XSLT можно выполнять все эти задачи одновременно. Более подробные сведения по данному вопросу можно найти в руководстве Дэвида Эйзенберга (David Eisenberg) "Using XML" (www.alistapart.com/stories/usingxml).

Механизм описания ресурсов RDF Механизм описания ресурсов RDF (Resource Description Framework, www.w3.org/ RDF), основанный на XML, предоставляет связанную структуру для приложений, обменивающихся метаданными в Web. Согласно архитектуре Web, кото.рую разрабатывает и продвигает W3C, RDF представляет собой связующее звено между XML-документами и высокоуровневыми средствами, обеспечивающими поиск и навигацию. Описание ресурса в RDF - это совокупность утверждений о свойствах ресурса. Ресурсами могут быть целые Web-страницы, части Web-страниц и даже целый сайт. Ресурсом может быть что-то совершенно не связанное с Web, например книга. Иными словами, RDF описывает, собирает и объединяет новости, программное обеспечение и все типы контента. RDF также облегчает взаимодействие и обмен данными между разными типами коллекций (например, коллекции музыки и фотографий). RDF все чаще используется в некоторых приложениях. Например, если открыть каталоги браузера Mozilla, можно найти файлы RDF (и CSS), необходимые браузеру для работы. Сейчас в RDF для записи метаданных применяется синтаксис XML. Но это не означает, что RDFописания и впредь будут записываться только в XML-форме. Технология RDF развивается. Rich S i t e S u m m a r y Rich Site Summary (RSS), http://backend.userland.com/rssO92, - технология простого описания информационного наполнения сайта - является XML-языком для описания Web-сайтов. Он был разработан Дэном Либби (Dan Libby) для портала My Netscape компании AOL/Netscape. Пбсле потери интереса AOL к этому проекту в апреле 2001 года продвижением RSS занялась компания Дэйва Вайнера (Dave Winer) UserLand Software Company. Сегодня RSS используют тысячи сайтов, что сделало RSS одним из наиболее популярных форматов XML в Web (рис. 4.6). RSS нашел широкое применение в новостных лентах сайтов. По сути, новостная RSS-лента представляет собой обычный XML-файл, в котором указана некоторая справочная информация о той или иной новостной статье: заголовок, время и дата, автор, краткое содержание.

128

Глава 4. XML завоевывает мир

Рис. 4.6. Веблоги на сайте Splorp.com (www.splorp.com) используют технологию RSS, что позволяет легко использовать содержимое сайта

XML-RPC

Еще одна разработка UserLand Software - XML-RPC, www.xmlrpc.com, - является спецификацией и набором правил, позволяющим приложениям, работающим на разных платформах и в разных средах, осуществлять вызов процедур через Internet. Помимо всего прочего, XML-RPC можно использовать для автоматизации задач по управлению сайтом и в программах Web-публикации. Тело запроса на удаленный сервер построено на XML. Процедура выполняется на сервере, и возвращаемое значение также форматируется в XML. Параметры процедуры могут быть скалярными величинами, числами, строками, датами и.т.д. Мы не будем очень подробно останавливаться на этой, еще развивающейся технологии.

Средства Web-публикации Основываясь на своем опыте, мы можем заявить, что задачи, выполняемые описанными выше платными технологиями, благодаря XML-приложениям в умелых руках могут быть решены бесплатно. В свою очередь, многие разработчики создают подобные приложения, чтобы облегчить жизнь своих коллег дизайнеров, разработчиков и авторов. Например, программа для Web-публикаций (CMS) под названием Movable Туре (www.movabletype.org), используемая сообразительными или не интересующимися техническими деталями авторами для поддержания и обновления Webжурналов, новостных сайтов и блоков, использует XML-RPC для облегчения управления сайтом и XML RSS для автоматического распределения контента между другими, поддерживающими XML сайтами (рис. 4.7). Тогда как Movable Type позволяет пользователям публиковать свои творения в Сети, XML позволяет Movable Type просто существовать.

Универ?

:1L

129

Movable Type является лишь одной из многих программ, использующих XML для управления контентом. В качестве других примеров подобных продуктов можно назвать Radio UserLand (рис. 4.8), UserLand Frontier (http:// frontier.userland.com) и Blogger от компании Руга Software (www.blogger.com). Популярность таких продуктов неуклонно растет, как и число пользователей, обнаруживших всю простоту и удовольствие, получаемое от публикации своих мыслей и творений в Internet. Таким образом, по мере распространения средств публикации увеличивается и использование XML - не только за счет разработчиков, но и благодаря пользователям, которые даже не слышали о стандарте XML. Лидеры рынка также не отстают от менее крупных производителей ПО в плане поддержки этого стандарта. Flash MX позволяет импортировать,

130

Глава 4* К

-iaer

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

К вашим услугам Логика XML также ведет к развитию рынка Web-услуг. Основанный на XML упрощенный протокол доступа к объектам Simple Object Access Protocol (www.develop.com/soap) облегчает обмен информацией в децентрализованной, независимой от платформы сетевой среде; доступ к службам, объектам и

XML»nptiложения и ваш сайт

131

серверам, а также кодирование, декодирование и обработку сообщений. Возможности XML позволяют SOAP работать с разными платформами и продуктами. SOAP - единственный протокол в мире Web-служб (www.w3.org/2002/ws) и категория, которой желают завладеть такие крупные компании, как IBM (www106.ibm.com/developerworks/webservices) и Microsoft (www.microsoft.com). Небольшие независимые разработчики предлагают свой вариант существования децентрализованных Web-служб без монополизма доминирующей компании. Вот какое определение Web-службам дает Дэвид Росэм (David Rosam): «Web-службы - это многократно используемые программные компоненты на базе XML и связанные протоколы, позволяющие осуществлять взаимодействие между бизнес-системами практически без затрат. Их можно использовать для внутренних целей - для быстрой и недорогой интеграции приложений, а также сделать доступными для потребителей, поставщиков или деловых партнеров». Источник - www.dangerous-thinking.com/stories/2002/ 02/16/webServiceDefined.htmL Благодаря своим возможностям XML является движущей силой большинства протоколов Web-служб. До тех пор пока XML будет доступен для всех, нет необходимости, чтобы в этой области доминировала одна (пусть даже очень могущественная) компания.

XML-приложения и ваш сайт XML является языком, на базе которого созданы стандарты Scalable Vector Graphics (www.w3.org/TR/SVG) и Extensible Hypertext Markup Language (www.w3.org/TR/2002/REC-xhtmll-20020801). Художники, сохраняющие логотопы заказчиков в формате SVG, и дизайнеры, создающие XHTML-страницы, используют XML, знают они об этом или нет. Общие для всех форм XML правила помогают этим форматам работать совместно, а также взаимодействовать с другими типами XML - например, с XML данными в базе данных. Графика SVG может быть автоматически изменена в ответ на запрос со стороны посетителя либо может постоянно обновляться в соответствии с передаваемыми в XML данными. Например, сайт местной телевизионной компании может использовать эту возможность для прямой трансляции любой передачи, скажем, для информирования зрителей о дорожных пробках. По мере исчезновения одной пробки и возникновения другой эта информация будет поступать на сервер, форматироваться в доступный для чтения формат XHTML и преобразовываться в карту дорог в формате SVG. В то же время данные могут передаваться и другим

132

Глава 4* Xf

аетшир

компаниям с помощью RSS или RDF или посредством SOAP - в администрацию города, чтобы она смогла принять адекватные меры и решить проблему. Несмотря на то что SVG-графика основана на XML, ее можно создать и в таких продуктах, как Adobe Illustrator 10 (www.adobe.com/products/illustrator/ main.html). Так же как и векторная графика Flash, изображения в формате SVG могут быть масштабированы без потери качества, при этом расход трафика будет небольшим. Управлять изображениями SVG, так же как и другими стандартными компонентами Web-страниц, можно с помощью ECMAScript в модели DOM. Помимо этого, текстовое содержимое SVG-изображения всегда остается доступным и может быть выделено курсором, несмотря на то, как оно деформировано или масштабировано.

Все еще в яслях В настоящее время вся мощь формата SVG несколько ограничена из-за необходимости использования дополнительного модуля (www.adobe.com/svg), так же как и для просмотра Flash. Этот модуль также пока недостаточно стабильно работает на всех платформах и браузерах. Когда все браузеры будут обладать встроенной поддержкой SVG, возможность добавления визуальных интерактивных элементов в Web-страницы возрастет многократно. Поддержка браузерами XML также пока находится на начальном уровне. Несмотря на то что XML применяется в базах данных, различных приложениях и Web-службах, лишь несколько браузеров могут похвастать правильным отображением файлов XML, а искусством создания XML-приложений овладела лишь малая часть дизайнеров и разработчиков. Сообщество разработчиков решило последнюю проблему, создав на базе XML различные языки, протоколы и продукты, которыми мы можем пользоваться. W3C решила проблему поддержки XML браузерами, создав стандарт XHTML (который мы рассмотрим в главе 5), сочетающий мощь XML и простоту HTML.

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

Нованэра»:

133

Повсеместно используемый в современных профессиональных и потребительских приложениях и в Web-дизайне, жизненно необходимый для рынка Web-служб и совместимый с будущими продуктами, XML позволяет решить проблему устаревания, описанную в главе 1. Успех XML превзошел все самые смелые ожидания, так как эта технология позволяет решить самые страшные кошмары несовместимости и найти выход из технологического тупика. Производители программного обеспечения, не желающие оказаться в числе ретроградов и потерять часть своих клиентов, понимают, что создание продуктов, поддерживающих XML, поможет им удержаться на рынке. Руководители компаний и IT-специалисты, более не намеренные использовать устаревшие запатентованные средства баз данных для хранения ценных сведений, могут легко перейти на XML. Небольшие независимые разработчики могут легко конкурировать с крупными фирмами, используя мощь XML, в основе применения которого лежит интеллект, а не бюджет. В сегодняшнем перенасыщенном данными мире старые запатентованные технологии больше не справляются со своей ролью, если они когда-то вообще делали это. Правила игры задает XML, и в игру приглашены все желающие. XML является Web-стандартом, который работает. И это является отличительной способностью любого хорошего стандарта - он работает, выполняет задачи и хорошо взаимодействует с другими стандартами. Это можно называть возможностью взаимодействия или просто совместной работой компонентов, однако, как бы вы это ни называли, XML является огромным шагом вперед по сравнению с устаревшими запатентованными технологиями прошлого. Под чарами Web-стандартов даже конкуренты научились сотрудничать.

Новая эра сотрудничества Как мы уже упоминали сотни раз, браузеры от Microsoft, Netscape и Opera в конце концов стали поддерживать одинаковые стандарты. Неожиданным результатом технологического сотрудничества стала корректная совместная деятельность конкурентов в другой области. JB июле 2002 года компания Microsoft предложила рабочей группе W3C по HTML на рассмотрение набор тестов и тестовых средств HTML для поддержки W3C HTML 4.01 Test Suit Development (http://lists.w3c.org/Archives/Public/www-qa-wg/ 2002Jul/0103.html). Это предложение поступило от Microsoft, Openware Systems, Inc. и America Online, Inc., владельцев Netscape и Mozilla. Opera Software Corporation и команда проекта Web Standards также изучили данное предложение.

134

Глава 4, XMi. за

; ает ттр

Тестовая среда и спецификации Тестовые среды W3C позволяют производителям браузеров определить, совместим ли их продукт со стандартами или требует доработки. Для HTML 4.01 (языка разметки, также являющегося основой для XHTML 1.0) не существовало подобной среды. В связи с этим производителям браузеров, желающим, чтобы их продукт соответствовал стандарту, не оставалось ничего, кроме как скрестить пальцы и молиться, чтобы это произошло. , Помимо этого, разработчики стандартов оказались в сложной ситуации. Как можно быть уверенным в том, что создаваемые тобой технологии могут решить проблему и сыграть свою роль, если отсутствует возможность убедиться в этом на практике? Это все равно что разработать автомобиль лишь на бумаге, не имея мастерской для воплощения задумки в жизнь. В интересах самих создателей стандартов и производителей браузеров такую тестовую среду следовало бы создать давным-давно.

Создание тестовой среды Когда компания Microsoft приняла решение исправить положение и создать тестовую среду, она предложила поучаствовать в этом и своим конкурентам, и сторонней группе специалистов (WaSP). И конкуренты, и WaSP сразу же согласились. Получившийся продукт и все его производные были полностью свободны от каких-либо патентов и принадлежали только W3C. Ни Microsoft, ни другие компании даже не пытались заработать на этом деле. Обычно Microsoft не слишком заботится о помощи AOL/Netscape, так же как и эта компания не сильно переживает за Microsoft или Opera. И все эти компании уж точно не стали бы заниматься общим делом, чтобы потерять свои деньги, участвуя в бесполезных совместных проектах. И тем не менее они все вместе собрались и работают над общим делом, препарируя не какую-то очередную новую запатентованную технологию, а старый знакомый HTML 4. Не замеченное прессой, это тихое событие на самом деле стало очень значимым. Прошли те дни, когда производители браузеров думали только о своем продукте и собственных технологиях в ущерб Web-стандартам и пользователям, надеясь таким образом вытеснить конкурентов с рынка. Естественно, производители браузеров продолжают внедрять новшества в свои продукты и надеются, что потребители выберут именно их браузер, а не конкурирующей фирмы. Однако возникшее у них желание работать совместно показывает, насколько глубоко они прониклись пониманием необходимости использования

Новая эра сотрудничества

135

и поддержки Web-стандартов и совместимости и как сильно изменилось положение дел в этой индустрии со времен войн браузеров (1996-1999).

Не верьте слухам Время от времени в журналах и газетах появляются статьи, основанные на некоторых изменениях на рынке, о том, что войны браузеров возобновились. Например, такое произошло в июне 2002 года, когда компания AOL перевела своих пользователей CompuServe с браузера, основанного на IE, на браузер на базе Mozilla/Netscape. «Изменения на рынке Web расстраивают разработчиков», «Войны браузеров 2» - такие заголовки появились в прессе. Подобные сообщения возникли в газетах и журналах и несколько месяцев спустя, когда AOL перевела своих пользователей Mac OS X на браузер на базе Gecko. Однако верить этим слухам не стоит. В сегодняшнем мире редакторы газет должны заботиться о рейтингах и продажах, если они хотят остаться в своих креслах. Различные кризисы и конфликты всегда привлекают больше внимания, чем простые разумные статьи, этим и пользуются многие таблоиды. Независимо от тенденций на рынке войны браузеров остались в прошлом и ни один редактор не сможет вновь воскресить их. Теперь Web будет строиться на основе стандартов, поддерживаемых всеми популярными браузерами. Борьба между AOL/Netscape и Microsoft, естественно, будет обостряться время от времени, однако она переместилась из области браузеров в другую, не интересующую нас арену (исключением остается FrontPage, о которой мы поговорим чуть позже).

Взросление W e b Конечно, не являясь таким же важным и фантастичным, как план ООН по установлению мира во всем мире, набор тестов HTML, скромно представленный Microsoft и ее конкурентами, знаменует собой значительные изменения в дальнейшем развитии Сети. Когда вечные конкуренты сотрудничают подобным образом, это является признаком, что всемирная Сеть выросла и повзрослела. То же самое происходит и в других развитых индустриях. К примеру, звукозаписывающие компании, ненавидящие друг друга, мирно работают над созданием нового стандарта или бок о бок борются с возникающей для их бизнеса угрозой (например, пиринговые Сети обмена музыкой вроде Napster). To, что Microsoft, AOL/Netscape и Opera могут работать вместе, указывает на взросление Сети. То, над чем они трудятся, повествует нам о том, почему произошло взросление. Всемирная сеть выросла благодаря стандартам, описанным в нашей книге.

136

Глава 4, XML завоевывает шир

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

Web-стандарты и средства авторской разработки Созданные в самом разгаре войн браузеров наиболее популярные и мощные профессиональные визуальные Web-редакторы Macromedia Dreamweaver и Adobe GoLive изначально решали проблему несовместимости браузеров путем создания отдельного кода для браузеров версии 3.0 и 4.0. Когда браузеры использовали нестандартные, неверные теги HTML, Dreamweaver и GoLive давали им то, что они хотели. Если каждый браузер использовал собственную несовместимую с другими объектную модель документа и собственные запатентованные скрипты, Dreamweaver и GoLive создавали соответсвующие коды. Таким образом, Dreamweaver и GoLive были виноваты не более чем дизайнеры, создававшие такой же код вручную. Как описано в главе 2, дизайнеры и разработчики были вынуждены так работать, поскольку стандарты находились на стадии разработки, а браузеры практически не поддерживали их. Такая стратегия была оправданной в те дни, однако использовать ее в настоящее время совершенно недопустимо. По мере того как браузеры учились поддерживать Web-стандарты, Dreamweaver и GoLive тоже следовало бы заняться этим. И сегодня они также поддерживают их.

Группа специалистов по D r e a m w e a v e r В 2001 году внутри проекта Web Standards была организована группа специалистов по Dreamweaver для взаимодействия с разработчиками Macromedia. Ее целью стала оптимизация Dreamweaver для написания совместимых со

Web-ста^

тшт

137

стандартами кодов создаваемых в этом приложении сайтов. Историю деятельности этой группы можно найти по адресу www.webstandards.org/act/ campaign/dwtf. Среди главных задач группы, определенных Рэйчел Эндрю (Rachel Andrew) и Дрю МакЛиллан (Drew McLellan), были следующие: • программа Dreamweaver должна создавать только не содержащий ошибок код со стандартными тегами и атрибутами; • Dreamweaver должна предоставлять выбор между XHTML и HTML, использованием в каждом случае переключателя DTD (DTD, или Document Type Definition, сообщает браузеру, какой тип разметки был использован для страницы.); • Dreamweaver должна считаться с DTD и создавать разметку и код в соответствии с ним; • Dreamweaver должна позволять пользователям легко создавать Web-страницы, доступные всем; • Dreamweaver должна правильно отображать CSS 2, чтобы подобные страницы можно было обрабатывать в Dreamweaver; • Dreamweaver не должна повреждать правильную разметку CSS вставкой стилей без ведома пользователя; • пользователи Dreamweaver должны быть уверены, что созданный в этом редакторе код будет правильным и доступным. Эти и другие поставленные задачи были реализованы в мае 2002 года, когда была выпущена версия Dreamweaver MX. Оценивая продукт, в создании которого они принимали участие, специалисты Web Standards Project пришли к выводу, что Dreamweaver MX: • создавала правильную разметку; • позволяла пользователям создавать доступные сайты; • достаточно аккуратно отображала разметку CSS 2, хотя оставались некоторые проблемы с отображением элементов, расположенных с помощью CSS; • не повреждала верную разметку CSS; • поощрялось корректное использование XHTML и CSS (автоматическое тестирование на соответствие стандартам); • уважала и поддерживала Web-стандарты. Дополнительные сведения. Полностью отчет специальной группы WaSP no Dreamweaver можно найти по адресу: www.webstandards.org/act/campaign/dwtf/rnxassessed.html.

138

Глава 4, XML завоевывает мир

Визуальные редакторы: два из трех не так уж и плохи Таким образом, Macromedia не на словах, а на деле доказала свое стремление поддерживать стандарты. Поддержка стандартов в Dreamweaver MX отвечает возможностям всех современных браузеров. Несмотря на то что WaSP не удалось сотрудничать с Adobe, компания самостоятельно и довольно успешно применила поддержку стандартов в своем редакторе GoLive (www.adobe.com/products/golive/main.html). Кроме CSS и XHTML, GoLive поддерживает Synchronized Multimedia Integration Language (www.w3.org/AudioVideo), стандарт W3C для создания доступных мультимедийных презентаций. Все пользователи этих двух редакторов могут с легкостью создавать Web-страницы, совместимые со стандартами.

FrontPage: несовместимость от природы Третий продукт данной категории - Microsoft FrontPage - малопопулярен среди профессионалов, но очень широко распространен среди начинающих, возможно, из-за того, что он поставляется в пакете с другими продуктами Microsoft. Многие дизайнеры вынуждены работать с FrontPage, так как бюджет не позволяет им раскошелиться на «дополнительный» редактор. «У нас уже есть Web-редактор», - могут подумать некоторые. И будут не правы. FrontPage не является Web-редактором; это редактор страниц для Internet Explorer. Несмотря на то что Microsoft производит совместимые со стандартами браузеры, редактор FrontPage использует запатентованные технологии для создания сайтов, которые корректно отображаются и работают только в Internet Explorer. Это не является ошибкой создателей. Данная функция редактора может считаться одной из его опций, хотя и созданной без учета интересов пользователей. Экс-президент Microsoft Билл Гейтс (Bill Gates) признался, что давал указания разработчикам продуктов группы Office, куда относится и FrontPage, не делать ее документы совместимыми с другими приложениями. Он не хотел, чтобы конкурирующие продукты могли открывать, сохранять и изменять документы FrontPage. Таким образом, если вы создаете сайт в FrontPage, вероятнее всего, он будет работать лишь в Internet Explorer. Тем не менее некоторая надежда осталась. В июле 2002 года UsableNet объявила об интеграции средства LIFT в Microsoft FrontPage (www.usablenet.com/ frontend/onenews.go?news_id=45), таким образом поощряя стремление пользователей FrontPage создавать доступные сайты. (LIFT также встроена и в Dreamweaver

Появление р

; CSS

139

MX.) Хотя это и не гарантирует, что FrontPage вскоре станет совместимой со стандартами, однако это является первым шагом в сторону совместимости. Пока же, если вы хотите создать совместимый со стандартами сайт, сделать это можно либо вручную в текстовом редакторе, либо с помощью визуальных редакторов Dreamweaver или GoLive. Использовать FrontPage для этой цели можно, только если вы готовы вручную исправить практически все теги и атрибуты, сгенерированные этой программой.

Появление разметки CSS Стандарт CSS 1 был создан в 1996 году для отделения внешнего вида сайта от его содержимого. К 2000 году все популярные браузеры наконец научились правильно отображать разметку CSS. Но дизайнеры и разработчики по-прежнему не торопились использовать CSS, так как большая часть пользователей все еще использовала браузеры версии 4.0. Необходимо было что-то предпринять, дабы сделать использование Web-стандартов «безопасным» для дизайнеров. Участники проекта Web Standards решили прибегнуть к партизанской тактике.

Кампания за обновление браузеров В феврале 2001 года Web Standards Project запустил кампанию в поддержку обновления браузеров (www.webstandards.org/act/campaign/buc). Как следует из ее названия, целью кампании было побудить пользователей перейти с устаревших, не поддерживающих стандарты браузеров на более новые версии, а дизайнеров подтолкнуть к отказу от использования ухищрений и трюков HTML в пользу Web-стандартов. В некотором смысле кампания достигла своих целей, поощрив некоторых разработчиков действовать, как будто вся их аудитория использовала современные браузеры. Делалось это так - с помощью фрагмента JavaScript в разделе <head> документа проверялось, поддерживает ли браузер пользователя модель DOM. Если да, то загружалась страница, в ином случае пользователь перенаправлялся на страницу, доступную его браузеру. На этой странице пользователю рекомендовалось обновить его браузер на более позднюю версию и объяснялось, как это улучшит его возможности по пользованию Сетью. В отличие от сообщения «Сайт оптимизирован для...», кампания WaSP не выделяла какой-то один браузер. Неважно, браузером какой компании вы пользуетесь, главное, чтобы он был совместим со стандартами.

140

Глава 4» ЖЖк завоевывает т и р

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

Кампания, не доведенная до конца Увы, слишком часто ленивые дизайнеры использовали данный способ для отказа посетителям в доступе к сайтам, которые были далеки от Web-стандартов. Лишь усиливая раздражение пользователей, вместо их просвещения они просто отправляли бедолаг на сайт WaSP. Как вы можете себе представить, подобное поведение лишь вызывало разочарование пользователей, а не желание обновить браузер. Среди таких недобросовестных сайтов был и Raiderettes.com (рис. 4.9), отправивший наибольшее число пользователей со своих страниц на WaSP. Сайт выглядит довольно привлекательно, но попытка проверить его разметку (http://validator.w3.org) привела к следующему результату: Fatal Error: no document type declaration; will parse without validation. I could not parse this document, because it uses a public identifier that is not in my catalog.

Raiderettes.com, так же как и некоторые другие коммерческие сайты, использовал код WaSP для переадресации пользователей не в целях распространения знаний о стандартах, а просто для отказа в доступе пользователям браузеров, не поддерживающих DHTML. Стоит ли говорить о том, сколько гневных писем получил WaSP от разъяренных мужчин, которым отказали в возможности рассмотреть красавиц с сайта, вместо этого предложив почитать о CSS и ECMAScript.

Более гибкий путь к обновлению Несмотря на подобные неудачи, кампания добилась успеха, подтолкнув тысячи дизайнеров к использованию стандартов. Она также привлекла внимание прессы к проблеме стандартов, а многие пользователи благодаря этой кампании сменили свои браузеры на более новые. Несмотря на некоторый ореол дурной славы, возникший благодаря перенаправлению пользователей на другие страницы, был достигнут и позитивный эффект. Используя более мягкие подходы, можно не отказывать пользователю в доступе. В поддержку этой кампании сайт A List Apart (www.alistapart.com) был

•

. • • • ; -

•:

•••

•

• 1

Рис. 4.9. Официальный сайт группы поддержки команды Oakland Raider (www.raiderettes.com)

переделан с использованием разметки GSS и правильного HTML (вскоре уступившего место XHTML), как описано в главе 2. При попытке продемонстрировать гибкость кампании сайт ALA показал, что можно избежать отказа в доступе к страницам и перенаправления пользователей со старыми браузерами. Вместо этого сайт просто скрывал разметку в несовместимых браузерах. Пользователи Netscape б, IE 5+, Opera 5+ и других современных браузеров могли видеть и содержимое, и разметку. Пользователи старых браузеров получали только контент, без разметки, а также видели сообщение о необходимости обновить браузер, которое было скрыто от пользователей современных браузеров. Web-стандарты предстали во всей своей красе. Для подогрева дизайнерского интереса сайт ALA был оформлен в стиле пропагандистского манифеста и было отмечено, что начиная с этого времени CSS-разметка сайта будет не видна пользователям браузеров, не поддерживающих этот стандарт (рис. 4.10-4.11).

142

Глава 4. XIVIL завоевывает мир

Рис. 4.10. «К черту старые браузеры!» Этим лозунгом ALA призывал дизайнеров использовать CSS и DOM (www.alistapart. com/stories/tohell)

floss

ж ш ш ш 1 CSS

143

Журнал "A List Apart" призывал 70 000-ую аудиторию своих еженедельных читателей перестать придумывать отговорки и приступить к использованию Web-стандартов: «Через полгода, год или два все Web-сайты будут создаваться по стандартам, отделяющим структуру от содержания. (Либо они будут сделаны с помощью Flash 7.) Мы можем либо наблюдать за тем, как наши навыки устаревают, либо начать изучение Web-стандартов прямо сейчас. На самом деле последние версии IE, Navigator и Opera уже поддерживают многие Web-стандарты. Если мы отбросим уверенность в необходимости оглядываться назад, мы можем перестать придумывать для себя отговорки и начать использовать Web-стандарты. В ALA начиная с выпуска №99 мы будем делать именно так. Присоединяйтесь».

Начало потопа Призыв "A List Apart" возымел свое действие. Спустя всего несколько дней один за другим независимые сайты стали преображаться, используя CSS для разметки и XHTML для создания структуры. В качестве примера можно привести сайт Тодда Домини (Todd Dominey) - рис. 4.12, - на котором он использует CSS и XHTML. Свой сайт-портфолио (рис. 4.13) Тодд выполнил во Flash. На своем персональном сайте Тодд объясняет, почему он перевел его на использование Web-стандартов: «Этот сайт полностью выполнен с помощью разметки XHTML/CSS. Нет прозрачных изображений GIF, колонок, строк - ничего подобного. Причина этого довольно проста - мне нужно было место для экспериментов с новыми технологиями дизайна, что невозможно сделать в проектах клиентов (в большинстве случаев). Этот сайт корректно отобразится в Explorer 5.0 и выше, Mozilla, Netscape б, Opera. Пользователи более ранних версий, например iCab или OmniWeb, могут столкнуться с проблемами. Если все, что вы видите, - это серый фон и синий текст на нем, вам срочно нужно обновить свой браузер (www.whatdoiknow.org/about.shtrnl)»,

Бесконечные преобразования После начала кампании за обновление браузеров и редизайна сайта ALA на CSS/ XHTML перешло несчетное число персональных сайтов и личных страничек. Для удовлетворения внезапно возникшего интереса к разметке CSS на некоторых сайтах были опубликованы открытые исходные коды разметок CSS,

144

Гнаеа 4. XML завоевывает тшр

которые можно было использовать для своих нужд. Если вы не уверены в понимании CSS или не до конца разобрались в разметке страниц с помощью CSS посетите эти сайты и скопируйте разметку с них: • Blue Robot's Layout Reservoir (рис. 4.14); • Eric Costello's CSS Layout Techniques (http://glish.com/ccc); • Owen Briggs's "Little Boxes" (рис. 4.15). Для более амбициозных дизайнеров Эрик Майер на своем сайте (рис. 4.16) предлагает ознакомиться с наиболее сложными приемами разметки CSS, которые работают только в самых совместимых браузерах. Эти методы вряд ли удастся использовать в проектах заказчиков, однако они позволяют нам потренироваться в своих навыках и отточить мастерство для будущих проектов.

145

Рис. 4.13. Сайт-портфолио Домини являет собой прекрасный образец рационального использования Flash (www.domineydesign.com)

Большинство CSS-дизайнеров создают сайты, корректно отображающиеся в IE 5 и более новых версиях и имеющие приемлемое качество в более старых браузерах (в которых может отображаться лишь контент без разметки). На сайте Real World Style Марка Ньюхауза (Mark Newhouse) - рис. 4.17 - можно найти разметки CSS, работающие в Netscape 4 и других устаревших браузерах. Хотите использовать CSS? Не можете послать к черту старые браузеры? На сайте Real World Style есть решения ваших проблем. По мере распространения комбинации XHTML/CSS среди персональных и независимых сайтов все больше дизайнеров стали задумываться о доступности их творений, об их соответствии требованиям Section 508 и руководству по доступности WAL На момент написания книги ведущие независимые сайты можно было разделить на две категории:

146

: :

• совместимые со стандартами сайты, использующие CSS для разметки и XHTML для создания структуры, отвечающие требованиям Section 508 и других руководств по доступности; • полностью выполненные во Flash сайты, использующие ActionScript (язык, созданный Macromedia на основе ECMAScript). Можно сказать, что, если ваш сайт не использует стандарты или Flash, многие коллеги сочтут вас отставшим от жизни. Какой бы банальной ни казалась эта истина, в ней есть свои положительные стороны. Такое положение дел способствует скорейшему принятию Web-стандартов.

Появлеш

тки CSS

147

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

148 Г пава 4. XML завоевывает мир

Рис. 4.16. На сайте Эрика Майера представлены образцы наиболее совершенных и сложных разметок, работающие лишь в самых совместимых браузерах (www.meyerweb.com/eric/css/edge)

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

Мэйнстрим Web-стандартов В 2001 году в США и Канаде были опубликованы инструкции, согласно которым все сайты, относящиеся к правительственным организациям, должны быть созданы в соответствии со стандартами, чтобы быть доступными всем пользователям. Вскоре этому примеру последовали Великобритания и Новая Зеландия.

149

В 2002 году крупные государственные сайты, в том числе Texas Parks 8c Wildlife (www.tpwd.state.tx.us), - рис. 4.18 - осуществили редизайн с использованием Web-стандартов, включая разметку CSS. Texas Parks 8c Wildlife так объясняет причину редизайна сайта (www.tpwd.state.tx.us/standards/tpwbui.htm): «Texas Parks 8c Wildlife, являясь государственной организацией, в соответствии с требованиями административного кодекса штата Техас §201.12, обязана создавать сайт согласно Web-стандартам, принятым W3C. В основе этих требований лежит вопрос доступности. Web-сайт должен быть доступен для всех пользователей, независимо от их физических ограничений и средств доступа к сайту». Но если страницы выглядят по-разному для каждого пользователя, как они могут быть доступными?

150

•

;

Рис. 4.18. Juneau.org (www.juneau.org) был одним из первых государственных сайтов, сменивших устаревшие фреймы и код на CSS и XHTML

Доступность не означает, что все пользователи видят одинаковые страницы. Доступность относится к контенту и информации и подразумевает, что все пользователи могут просмотреть полное содержимое сайта (текст, изображения, мультимедиа). Чтобы добиться этого, дизайнеры TPW воспользовались CSS для отделения контента от внешнего вида, что позволило повысить качество страниц. Стандарты W3C делают возможным создание доступных страниц. Используя CSS и XHTML, Texas Parks 8c Wildlife приступила к созданию совместимых Web-страниц. Разработчики сайта столицы Аляски привели примерно такие же доводы (www.juneau.org/about/stylesheets.php): «Мы преобразовали сайт из фреймов в стандартный CSS. Этот стандарт дает нам большую свободу в плане дизайна и повышает его доступность для

1№йнс?р

-стандартов

151

пользователей. С помощью CSS мы можем сделать наш сайт доступным практически для всех браузеров и платформ, а также для различных беспроводных устройств. Кроме этого, он позволит нам распрощаться со многими проблемами, вызванными нашим старым дизайном с фреймами». Единственным недостатком такого подхода является то, что многие старые браузеры не совместимы с CSS. Тем не менее CSS намного более снисходительно относится к таким браузерам, чем фреймы к браузерам, не поддерживающим их. Несовместимые с CSS браузеры отобразят вместо разметки сайт в текстовом формате. Хотя такой вариант и будет лишен привлекательности, вся информация, включая ссылки и изображения, сохранится и будет доступна пользователям. С помощью CSS дизайнер может контролировать порядок отображения контента в несовместимых браузерах, без влияния на облик сайта в совместимых браузерах. Это является большим преимуществом и лично я, как дизайнер, предпочту, чтобы пользователи говорили, что мой сайт выглядит нелепо, чем то, что он не работает. Большинство новых версий браузеров поддерживают CSS. Если ваш браузер не относится к ним, щелкните по одной из кнопок внизу страницы для загрузки новой версии. Для старых компьютеров с небольшим объемом памяти и медленным процессором выберите браузер Opera, так как он не предъявляет высоких системных требований к вашему ПК.

Коммерческие сайты принимают вызов В 2002 году коммерческие сайты также начали переходить к использованию CSS и XHTML. В июле того же года поисковая система Lycos Europe перешла на XHTML и CSS, а вслед за ней последовал и HotBot. Примерно в то же время быстрая поисковая система AllTheWeb (рис. 4.19) также была переведена на CSS/XHTML. На момент написания книги Yahoo и Google еще не последовали примеру своих более мелких конкурентов, однако, как мы уже отмечали, такова природа перемен: вначале рискуют небольшие независимые сайты, а затем, вслед за ними, идут и большие игроки, когда убедятся в безопасности перемен.

Преобразования W i r e d Digital В сентябре 2002 года популярный сайт Wired Digital был полностью переделан в соответствии со стандартами: XHTML для данных, CSS для оформления (рис. 4.20-4.21). Глава дизайнеров сайта Дуглас Бауман (Douglas Bowman) рис. 4.22 - отвечал за новый дизайн и его соответствие стандартам.

152

Гиава4* XML завоевывает мир

Рис. 4.19. Поисковая система AllTheWeb (www.alltheweb.com), угрожающая сбросить с пьедестала Google, была переведена на CSS/XHTML в 2002 году

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

Некоторые трудности После редизайна сайт Wired.com содержал ошибки, некоторые из которых были вызваны системой управления контентом Vignette, использовавшейся сотрудниками Wired. Причиной других были рекламные блоки сторонних компаний, созданные с ошибками. С такими же проблемами сталкивалось и мое агентство Happy Cog, да и вы тоже, возможно, не избежали подобных проблем. Бывает, что после создания отличных шаблонов система

Лйэйн стрим Wefo»cran.

153

Рис. 4.20. Сайт Wired Digital был переведен на XHTML и CSS в 2002 году (www.wired.com)

управления контентом добавляет туда некорректный код, и весь сайт разваливается на глазах. В случае с Wired эти проблемы были быстро устранены и спустя пару дней после перезапуска сайт являлся прекрасным образцом совместимого со стандартами крупномасштабного коммерческого проекта. Тем не менее стоит отметить, что не каждая компания в состоянии исправить ошибки, возникшие из-за использования Vignette. Для прогресса Web-средствам публикации контента необходимо научиться поддерживать стандарты. Владельцам сайтов и менеджерам необходимо донести до производителей подобных систем, что поддержка стандартов является совершенно необходимой, так же как в свое время дизайнеры и разработчики донесли эту мысль до производителей браузеров. Чем больше пользователей сообщит об этом производителям, тем скорее они начнут выпускать совместимые со стандартами продукты.

154

Глава 4* XML. завоевывает mug»

Системы публикации и стандарты. Чистое использование XHTML/CSS редко встречается на крупных коммерческих сайтах, даже владельцы которых полны желания соответствовать стандартам W 3 C . Зачастую виной этому являются используемые приложения, такие как базы данных, системы публикации контента и другие подобные средства. Как мы уже отмечали ранее в этой главе, независимые дизайнеры и разработчики обычно не сталкиваются с трудностями, применяя CSS и XHTML Некоторые из них в качестве хобби даже исправляют подобные ошибки на коммерческих сайтах за несколько часов работы. В целом создать сайт в соответствии со стандартами XHTML, CSS и требованиями по

155

Рис. 4.22. Новый дизайн Wired Digital был создан в основном благодаря Дугласу Баумэну, вскоре покинувшему Wired и создавшему собственную компанию Stop Design (www.stopdesign.com) доступности Prioriiy 1 совсем не сложно, и любой упорный дизайнер может выполнить такую задачу. Однако трудности возникают в крупномасштабных системах и при использовании контента третьих сторон, который необходимо интегрировать в большинстве крупнейших сайтов. Для уверенности в совместимости и работоспособности наших сайтов мы должны убедиться в том, что системы управления контентом сами совместимы со стандартами и не испортят наш код. Необходимо, чтобы создатели подобных продуктов осознали важность стандартов. И, конечно, для модернизации этих продуктов потребуются деньги. В здоровой экономике компании инвестируют в исследования, обучение персонала и в долгосрочные проекты. В неэффективной экономике компании фокусируются на снижении расходов, сокращении штата и т.д. Заставить дизайнеров выучить новые приемы легко, следует лишь показать им преимущества этого подхода. Но заставить компании, борющиеся за выживание, инвестировать в долгосрочные проекты, от которых зависит будущее здоровье Сети, не так просто.

156

Гяава 4. ЖЖк т

;aei

Внедрение стандартов с помощью переходных методов Не всегда соответствие стандартам требует перехода к строгой разметке CSS, и не всем компаниям и организациям необходимо прибегать к столь радикальным мерам в попытке добиться совместимости со стандартами. В главе 2 описаны переходные способы добиться совместимости со стандартами, предусматривающие использование как старых, так и новых технологий. Подобный неспешный подход перехода к совместимому со стандартами сайту подходит для организаций, большая часть пользователей которых использует устаревшие браузеры. Одной из таких организаций является Общественная библиотека Нью-Йорка. В 2001 году под руководством Кэрри Бикнер (Carrie Bickner) сайт филиалов библиотеки (www.nypl.org/branch) был переведен на XHTML 1.0 и комбинацию CSS со старыми таблицами. Сайт также стал соответствовать требованиям доступности Section 508. Одновременно с редизайном сайта библиотека опубликовала руководство по стилю (www.nypl.org/styleguide) под авторством К. Бикнер и вашего покорного слуги, в котором были приведены требования к дизайну и разметке для всех дочерних проектов библиотеки, включая справочник по CSS и XHTML. Вместо того чтобы сделать руководство доступным только для сотрудников, библиотека разместила его на внешнем ресурсе в надежде, что тысячи дизайнеров и разработчиков скорее обратятся к XHTML и CSS. Как оказалось, этот шаг возымел действие. Так же как некогда стандарты занимали умы независимых дизайнеров, теперь они завладели разработчиками из крупных коммерческих компаний и различных организаций, которые воспринимают их как способ охватить широкую аудиторию и сделать свои сайты более доступными.

W 3 C вступает в игру Еще совсем недавно W3C придерживался довольно пассивной политики, предпочитая публиковать спецификации стандартов, но не проталкивать их в жизнь. Теперь эти дни остались позади. В 2001 году W3C сформировал группу поддержки качества (http://www.w3.org/QA), для того чтобы более успешно общаться с дизайнерами и разработчиками, а также чтобы убедиться в корректном применении Web-стандартов. W3C также приступил к публикации статей в поддержку принимаемых стандартов.

Выводы

157

Например, в статье W3C (www.w3.org/WAI/bcase/benefits.html) приводятся доводы в пользу использования Web-стандартов при создании сайтов с точки зрения увеличения рыночной доли, расширения аудитории, снижения расходов и демонстрации социальной ответственности. Статья, безусловно, стоит того, чтобы ее прочесть, распечатать и донести до других. Если эти преимущества звучат знакомо - очевидно, вы внимательно читали эту книгу, а не просто перелистывали страницы. Стандарты и повышение доступности приводят к росту вашей аудитории, одновременно сокращая расходы. Если это предложение не заинтересует владельца какой-либо компании, видимо, он живет не нашей планете.

Выводы Стандарты, подобные XML, изменили бизнес. Поддержка стандартов положила конец войнам браузеров и их негативному влиянию на удобство использования, доступность и продолжительную жизнеспособность. Благодаря CSS и XHTML, поддерживаемым популярными браузерами и визуальными редакторами, изменились способы создания сайтов не только на уровне персональных страничек, но и на уровне коммерческих, государственных и сайтов организаций. Мы наблюдаем повсеместную победу Web-стандартов. А теперь давайте прекратим ликовать и вернемся к работе.

Дизайн и разработка ГЛАВА 5.

Современный код

ГЛАВА 6»

XHTML: реструктуризация Сети

ГЛАВА 7.

Структура и метаструктура в строгой и смешанной разметке

ГЛАВА 8,

XHTML в примерах: смешанная разметка

ГЛАВА 9.

Основы CSS

ГЛАВА 1 0 . CSS в действии: смешанная разметка ГЛАВА 1 1 . Переключение DOCTYPE и поддержка стандартов ГЛАВА 1 2 . Блочная модель, ошибки браузеров и обходные пути ГЛАВА 1 3 . Оформление текста ГЛАВА 1 4 . Основы доступности ГЛАВА 1 5 . Работа со скриптами на основе DOM ГЛАВА 1 6 . CSS-редизайн

Г л а м I. Современный код

первой главе нашей книги мы обсудили деловые и творческие затруднения, возникающие при использовании устаревших методов Web-дизайна, коснулись преимуществ дизайна по стандартам и набросали общие тенденции развития индустрии. В оставшейся части книги мы перейдем от общего к частному, и лучше всего будет начать с повторного взгляда на основы Web-кода. Некоторые дизайнеры могут неодобрительно покачать головой. Естественно, те из нас, кто занимается созданием сайтов больше двух недель, могут думать, что знают о HTML все, что можно знать. Неужели нельзя изучить что-то более мощное и новое? Например, может, лучше познакомиться с серверными технологиями PHP, ASP или ColdFusion, чем тратить драгоценное время на переосмысление таких рудиментов, как HTML-таблицы или тег font? Ответ - и да и нет. Серверные технологии жизненно важны для создания динамичных сайтов, реагирующих на запросы пользователей. Даже традиционные информационные сайты могут получить выгоду, храня свой контент в базах данных и обращаясь к ним посредством РНР или других подобных технологий. Так же как и стандарты, серверные технологии помогают отделить данные от интерфейса. Как и стандарты, подобные CSS, освобождают дизайнеров от необходимости заключать каждый фрагмент информации в табличную ячейку, языки вроде РНР и ASP освобождают создателей от необходимости создавать каждую страницу вручную. Но от этих динамически создаваемых страниц не будет никакого толку, если они будут несовместимы с большинством браузеров или устройств либо будут работать на основе некорректного и устаревшего кода. Если страницы не будут отображаться в некоторых продуктах или будут загружаться 60 с вместо 10, серверные технологии не смогут проявить себя во всей красе. Иными словами, стандарты и подобные технологии не исключают друг друга, а позволяют работать совместно и более эффективно. Серверные технологии и базы данных

162

Глава 5» Современный мод

помогают создавать более «умные» и функциональные сайты, однако их содержимое становится более доступным при использовании четкого структурированного кода. Что такое PHP. PHP (www.php.net) является открытым языком скриптов общего назначения, идеально подходящим для Web-дизайна и отлично взаимодействующим с XHTML. Синтаксис языка похож на С, Java и относительно прост в изучении. РНР (на1 звание языка является рекурсивным акронимом PHP: Hypertext Preprocessor ) обладает множеством возможностей, однако стал популярен по одной причине: при использовании совместно с базой данных MySQL (www.mysql.com) РНР позволяет разработчикам с легкостью создавать динамические сайты и Web-приложения. С 1998 года развитием и продвижением РНР занимается компания Zend Technologies. Этот язык распространяется на основании лицензии open source, то есть является открытым программным продуктом (что также отразилось на его широкой популярности). Влюбленные в РНР разработчики постоянно создают на базе этого языка всевозможные приложения, распространяемые бесплатно. Например, приложение Refer Дина Аллена (Dean Allen) позволяет отслеживать посетителей вашего сайта (www.textism.com/ tools/refer), пришедших с других сайтов по ссылкам (рис. 5.1). Приложение URL Cleaner Дэна Бенджамина (Dan Benjamin) - рис. 5.2 - исправляет некорректные Web-адреса, созданные другими языками, например ColdFusion (www.hivelogic.com/urlcleaner.php). РНР совместим с Web-сервером IIS от Microsoft, однако наиболее часто он применяется в комбинации с сервером Apache. Apache работает и под Windows, а наиболее часто, конечно, под UNIX. Mac OS X для Apple, созданная на базе UNIX, включает в себя и РНР, и сервер Apache, как и большинство дистрибутивов Linux. Microsoft Active Server Pages, или ASP, - www.asp.net - и Macromedia ColdFusion (www.macromedia.com/software/coldfusion) также являются популярными языками для создания динамических Web-страниц. Из этих трех языков бесплатным является только РНР. ASP обычно используется в связке с серверным ПО от Microsoft, ColdFusion обычно сочетается с другими продуктами от Macromedia, включая Dreamweaver и Flash, тогда как для независимых разработчиков оптимальным выбором остается РНР. С другой стороны, даже такие лидеры рынка, как Yahoo, используют РНР (www.theopenenterprise.com/story/TOE20021031 S0001). Это говорит о том, что бесплатный РНР привлекает не только мелкие компании. Yahoo, как и многие крупные компании, использует ряд других открытых технологий, что демонстрирует многогранность и независимость Web-индустрии.

Первоначально язык назывался РНР - Personal HomePage Tools - и в 1994 году был призван автоматизировать работ)' домашней странички автора, Расмуса Ледфорда. - Прим. науч. ред.

Современный код

163

Рис. 5.1. Приложение Refer позволяет отслеживать посетителей вашего сайта, пришедших с других сайтов по ссылкам (www.textism.com/tools/refer)

Что такое РНР (окончание). Каждый из этих трех языков использует как крупные, так и мелкие сайты. У каждого из них есть свои преимущества и недостатки. Следует отметить, что все эти языки генерируют длинные URL, содержащие амперсанды, что недопустимо в HTML/XHTML. В HTML/XHTML символ амперсанда (&) используется для служебных целей, например # & 8 2 1 7 , что является обозначением в кодировке Unicode апострофа. ColdFusion, в частности, нарушает эту договоренность. Это можно исправить с помощью функции U R L E n c o d e d F o r m a t ( ) . В AS.P есть схожая функция HTMLEncode. В обоих случаях разработчики могут избежать возникновения проблемы, воспользовавшись этими функциями. Java Server Pages (JSP) является еще одной динамической технологией, наиболее часто используемой в крупных развлекательных сайтах, и ее описание выходит далеко за рамки нашей книги.

164

Глава 5. Современный код

Тайный позор плохого кода Чем более успешными в Web-дизайне мы становимся и чем дольше мы занимаемся этой деятельностью, тем меньше мы задумываемся или знаем о скрытых последствиях плохого кода. В эпоху раннего развития Сети Web-дизайн был схож с кормлением требовательных и разборчивых детей. Для созидания работающего сайта мы создавали несколько версий для каждого браузера. Современные браузеры все потребляют одинаковую пищу, однако не все дизайнеры знают об этом. Так же как плохое питание негативно влияет на организм, плохой код подрывает «здоровье» всей Сети. Но до недавнего времени этот факт был скрыт от

Тайный позор плохого кода

165

нас, как уже описывалось в главе 1, потому что нам не с чем было сравнивать, 99,9% сайтов устарели. В этой и последующих главах мы разобрались с причиной существования плохого кода и научились думать структурно, а не рассматривать Web-разметку как второсортный инструмент для дизайна. В то же время мы познакомились с XHTML, стандартным для создания Web-страниц, обсудили его задачи и достоинства и рассмотрели стратегию перехода от HTML к XHTML. По странному совпадению корректное использование XHTML ведет к созданию хорошо структурированных сайтов и отказу от бессмысленных уловок. В XHTML 1.0 Transitional использование таких трюков разрешается, но более логично выполнить стоящие задачи с помощью CSS. В XHTML 1.0 и 1.1 Strict подобные уловки запрещены. При их использовании ваша страница не пройдет проверку в W3C (рис. 5.3).

166

Глава 5. Современный к ад

Проверьтесь! Служба проверки кода W3C (http://validator.w3.org) может проверить Web-страницы HTML 4.01, XHTML 1.0 и XHTML 1.1 на их соответствие стандартам. Проверить корректное использование CSS можно с помощью службы проверки CSS (http://jigsaw.w3.org/css-validator). Еще одна программа проверки кода создана Web Design Group (http://www.htmlhelp.com/tools/validator). Все эти три службы работают абсолютно бесплатно.

Выберете ли вы XHTML Strict или Transitional, с течением времени вы обнаружите, что все, что вы знали, ошибочно. Вы откажетесь от множества привычных процедур: тегов <br>, которыми вы раньше щедро сыпали налево и направо для эмуляции списка, заголовков, прозрачных изображений GIF и многого другого. Вместо использования этих уловок вы начнете мыслить структурно. Пусть разметка станет настоящим качественным кодом. Даже при переходном способе, используя таблицы, вы научитесь делать больше с помощью CSS. По мере изучения нового языка мы можем забыть все устаревшие приемы, используемые нами в течение многих лет. Так, может, начнем?

Переформулировка Согласно W3C, XHTML является (www.w3.org/TR/xhtmll) переформулировкой HTML в XML. Более простыми словами, XHTML является языком разметки на базе XML, который работает и выглядит так же, как и HTML, за исключением некоторых небольших, но существенных различий. Для браузеров и пользователей XHTML ничем не отличается от HTML, но некоторые наиболее новые модели браузеров обрабатывают такой код несколько иначе, чем HTML (более подробно мы рассмотрим этот вопрос в главе 6). Для дизайнеров и разработчиков XHTML почти не отличим от HTML, за исключением наличия более строгих правил и нескольких новых элементов. В главе 4 мы описали XML - Extensible Markup Language (http:// www.w3.org/XML) как некий сверхъязык разметки, из которого разработчики могут создавать другие языки разметки. XHTML (Extensible Hypertext Markup Language - Расширенный язык разметки гипертекста) как раз и является одним из таких языков. XHTML 1.0 является первой и наиболее обратно-совместимой версией XHTML и, соответственно, наиболее легкой для изучения.

Bi»fB0&bl

167

Число других приложений и протоколов на базе XML подсчитать невозможно, и их популярность обусловливается возможностью безболезненного обмена данными между ними, что также относится и к XHTML. Среди этих протоколов можно упомянуть Scalable Vector Graphics (http://www.w3.org/TR/SVG), Synchronized Multimedia Integration Language (http://www.w3.org/TR/RECsrnil), Simple Object Access Protocol (http://www.w3.org/TR/SOAP), Resource Description framework (http://www.w3.org/RDF), Platform for Privacy Preferences (http://www.w3.org/TR/P3P). Все эти протоколы (и бессчетное число других) играют важную роль в развитии Сети, но ни один из них не является таким легким в изучении и таким важным для дизайнеров и разработчиков, как XHTML. Почему необходимо «переформулировать» HTML в XML? Одной из причин является последовательность XML против полной неразберихи в HTML. В XML каждый тег должен быть закрыт. В HTML же некоторые теги обязательно должны быть закрыты, другие никогда не закрываются, а третьи можно закрывать или нет на усмотрение дизайнера. Такая непоследовательность может создать массу проблем. Например, некоторые браузеры могут отказаться отображать HTML-страницу с открытыми ячейками таблицы, даже если по правилам HTML такие теги можно не закрывать. В XHTML вы должны закрывать все элементы, что помогает избежать появления проблем с браузером, устраняет необходимость тратить время на тестирование и отладку и избавляет от необходимости помнить, какие теги надо закрывать, а какие - нет. Но, что более важно, языки и приложения на базе XML являются ключом для успешного будущего ваших сайтов. Использование XML может гарантировать, что ваш сайт будет успешно работать с другими языками, протоколами и приложениями на базе XML. Вы можете спросить, если XML настолько важен, зачем создавать язык разметки на базе XML, который работает как HTML? XML мощный и всеобъемлющий, однако большинство браузеров не может обработать сырой XML и отобразить аккуратно отформатированную Web-страницу (рис. 5.4). XHTML является мостом, соединяющим мощь XML и простоту HTML.

Выводы Попросту говоря, XHTML - это XML, который ведет себя как HTML в старых и новых браузерах, а также корректно работает в большинстве Internet-устройств от Palm Pilot до сотовых телефонов и программ для чтения информации с экрана.

168

Глава 5. Современный код

РИС. 5.4. Простой XML-документ (http://p.moreover.com/cgi-local/page?index_xmH-xml), открытый в современном браузере (в данном случае Chimera). Некоторые браузеры отображают XML как текст, некоторые - как текст с тегами. Ни один вариант не является приемлемым, тогда как XHTML корректно отображается практически в любом браузере и устройстве

XHTML легко изучить и использовать, как и HTML. Новичкам сделать это будет даже легче, так как у них еще не появились вредные привычки плохой разметки, свойственные более опытным дизайнерам. XHTML является текущим стандартом создания Web-страниц (сменившим HTML 4.0), и с его помощью можно вернуть логическую структуру документа Web-контенту, совместимость с другими стандартами, например CSS и DOM, a также обеспечить корректную совместную работу с другими языками, приложениями и протоколами на базе XML.

Какой XHTML подходит ват

169

Какой XHTML подходит вам В этой главе и во всей нашей книге мы сфокусируемся на XHTML 1.0 и XHTML 1.0 Transitional, наиболее легкой в освоении, толерантной к дизайнеру и совместимой с существующими методами дизайна версии XHTML. Многие сторонники стандартов предпочитают XHTML 1.1 Strict, и в этом нет ничего предосудительного, однако эта версия менее совместима со старыми браузерами и она использует MIME-типы, что может вызвать некоторые проблемы в поведении определенных популярных браузеров. Кроме того, преобразование созданных старыми методами сайтов в XHTML 1.1 Strict требует большего труда и времени, чем в XHTML 1.0 Transitional. Для большинства читателей этой книги оптимальным выбором скорее станет XHTML 1.0 Transitional. На момент написания книги сообществу разработчиков были представлены наброски стандарта XHTML 2.O. В своем нынешнем воплощении этот стандарт довольно близок к идеалу. XHTML 2.0 не совместим с HTML или XHTML 1.0. В нем не используются некоторые привычные элементы, включая IMG (вместо него используется OBJECT), тег <br> заменен на элемент LINE, появился элемент HLINK. Возможно, эти характеристики стандарта и изменятся к моменту выхода книги в свет1. Некоторые разработчики встретили появление XHTML 2.0 с нескрываемым восторгом, тогда как реакция других была полностью противоположной. Кое-кто занял просто выжидательную позицию. А некоторые дизайнеры вообще ничего не слышали о происходящем и до сих пор не знают, для чего нужны опции доступности в Dreamweaver. Со временем мы увидим, какие именно спецификации XHTML 2.0 превратятся в стандарт, будут ли дизайнеры и разработчики поддерживать его или проигнорируют. Так как XHTML 2.0 еще не стал стандартом и не поддерживается ни одним браузером, его существование интересно, но не более того, и не относится к нашей книге или работе, и мы еще раз советуем вам остановиться на XHTML 1.0. В настоящий момент опубликована 6 редакция языка XHTML 2.0, но до окончательного утверждения стандарта и тем более его поддержки браузерами еще далеко. - Прим.науч. ред.

170

Глава S. Современный код

И наконец, учитывая то, что XHTML 2.0 не является обратно-совместимым, вы можете задуматься о том, насколько XHTML будет совместим с будущими продуктами. Отвечаем, что пока ни один производитель ПО или аппаратного обеспечения не выразил желания в будущем отказаться от поддержки XHTML 1. Так же как и ни один производитель браузеров не намерен отказываться от поддержки HTML 4. Сайты, написанные на корректном HTML 4.01, будут продолжать работать годы и годы. Это же относится и к XHTML 1. Выбирая между HTML и XHTML, обратите внимание на следующие моменты.

1О главных причин перехода на X H T M L 1. XHTML является текущим стандартом разметки гипертекста, заменившим HTML 4. 2. XHTML совместим с другими продуктами на базе XML - языками, протоколами и приложениями, чего нельзя сказать о HTML. 3. XHTML более последователен, чем HTML, что снижает вероятность возникновения ошибок. 4. XHTML 1.0 является мостом к будущим новым версиям XHTML. Если появится стандарт, XHTML 2.0 будет легче перейти на него с XHTML 1.0, чем с HTML. 5. Старые браузеры так же корректно отображают XHTML, как и HTML. 6. Новые браузеры любят XHTML (в частности, XHTML 1.0), он предоставляет многие функции, недоступные в HTML. 7. XHTML так же хорошо работает в беспроводных устройствах, программах для чтения информации с экрана и других пользовательских устройствах, как и в традиционных браузерах, что во многих случаях устраняет необходимость создания отдельных версий для беспроводных устройств и повышает доступность сайта. 8. XHTML является частью семейства Web-стандартов (также включающего в себя CSS и W3C DOM), что позволяет контролировать внешний вид и поведение страницы на разных платформах, браузерах и устройствах. 9. Использование XHTML ведет к повышению доступности вашего сайта и одинакового отображения страниц в браузерах разных производителей. 10. Использование XHTML может выработать у вас привычку проверять страницы с помощью служб проверки кода, что может сэкономить время на тестировании и отладке и поможет избежать основных ошибок доступности, например отсутствие атрибута a l t для каждого тега <IMG>.

Какой ХН1ТЛ1 w

171

5 главных причин не переходить на XHTML 1. У вас как у дизайнера почасовая оплата. 2. Вам нравится создавать отдельные версии сайта для каждого браузера, платформы и устройства. 3. Ваш внутренний голос подсказывает вам не делать этого. 4. Вы уходите из Web-дизайна. 5. Вы не знаете правил XHTML. По счастливому стечению обстоятельств мы можем исправить пункт №5. Переходим к следующей главе.

Г л а м

6 .

X H T M L :

реструктуризация Сети

ы могли назвать эту главу «XHTML: простые правила, легкое руководство». Так как правила и приемы, рассмотренные в ней, на самом деле просты и понятны. Кроме того, слова «легко» и «просто» для книг по Web-дизайну то же самое, что и «новинка!» и «бесплатно!» для товаров в супермаркете, - они притягивают потребителей как магнит и вызывают у них интерес. Конечно, нам хочется стимулировать интерес и подтолкнуть вас к знакомству с XHTML. Почему? Потому что после того, как вы освоитесь с простыми и легкими идеями, приведенными в этой главе, вы переосмыслите образ работы Web-страниц и измените свой подход к их созданию. Это не значит, что вы начнете использовать теги, модные в этом году, вместо прошлогодних. Вы просто начнете мыслить и работать в целом совершенно по-другому. «Простые правила, легкое руководство» уже не смогут охватить всех этих вопросов. С другой стороны, еще одно возможное название главы - «Достижение единства с правильным способом достичь просветления» - кажется слегка напыщенным. А реструктуризация как раз отражает суть XHTML и данной главы. Поэтому - «XHTML: реструктуризация Сети». В этой главе мы изучим азбуку XHTML и узнаем, в чем разница между структурным кодом и оформлением. Если вы уже занимались внедрением Web-стандартов в свою практику, некоторые моменты, рассматриваемые в этой главе, могут оказаться для вас знакомыми. Но даже опытные программисты могут обнаружить для себя неожиданные секреты в этой главе.

Преобразование в XHTML: простые правила, легкое руководство Преобразование из традиционного HTML в XHTML 1.0 Transitional является быстрым и безболезненным процессом, если вы соблюдаете несколько простых

Преобразование в XHYfVli: простые правила, легкое руководство

173

правил. Если вы можете написать HTML-код, вы сможете создать и XHTML-код. Если вы никогда не работали с HTML, вы все равно сможете научиться писать на XHTML. Давайте познакомимся с простыми основами языка.

Т о ч н ы й DOCTYPE и пространство имен Документы XHTML начинаются с элементов, указывающих браузеру, каким образом обрабатывать их, а службам проверки - как тестировать их на соответствие стандартам. Первый элемент называется DOCTYPE (сокращение от document type - тип документа). Он сообщает службам проверки, какая версия XHTML или HTML используется. По причинам, известным лишь членам W3C, DOCTYPE всегда пишется заглавными буквами.

Что т а к о е DOCTYPE XHTML позволяет дизайнерам и разработчикам создавать несколько различных типов документов, каждый их которых соответствует различным правилам. Правила для каждого типа указаны в приложении к описанию стандарта XHTML под названием «определение типа документа» (DTD). С помощью элемента DOCTYPE вы сообщаете службе проверки или браузеру, в соответствии с каким DTD вы создали свой документ. Согласно этой информации, браузер или служба проверки решает, как обращаться с вашим документом. DOCTYPE является ключевым компонентом в совместимости страниц, кроме того, выбор DOCTYPE влияет на поведение вашей Web-страницы в различных браузерах. Неожиданные результаты в этом случае могут сильно удивить вас. В главе 11 мы рассмотрим влияние DOCTYPE на Internet Explorer и на браузеры, основанные на Gecko, - Netscape, Mozilla, Camino. XHTML 1 предлагает на выбор три типа DOCTYPE: • Transitional - удобный, слегка неряшливый тип DTD, девиз которого «Живи и дай жить другим»; • Strict - строгий DTD, не позволяющий использовать элементы и атрибуты оформления в коде; • Frameset - этот тип прямо из 90-х годов; разрешает использовать фреймы.

К а к о й DOCTYPE использовать Из трех перечисленных выше типов наиболее близко к HTML стоит XHTML 1.0 Transitional. Он единственный из трех позволяет использовать в структуре кода элементы оформления и устаревшие атрибуты.

174

Глава 6. XHTML: реструктуризация Сети

Например, одним из таких рудиментов является атрибут t a r g e t для ссылки HREF. Если вы хотите, чтобы ссылки открывались в новом окне, или ваш заказчик настаивает на этом, Transitional является единственным типом XHTML, разрешающим сделать это с помощью атрибута t a r g e t : <р>Просмотреть <а href="http://www.yoursite.org" target= "_Ыапк">вашу страничку</а> в новом окне.</р> <р>Просмотреть <а href="http://www.yoursite.org" target^ "verbatemM>Bamy страничку</а> в именованном окне</р> Чтобы открыть ссылку в новом окне при использовании XHTML 1.0 Strict, необходимо написать JavaScript, а также потребуется убедиться, что ссылка работает в среде, которая не поддерживает JavaScript. Целесообразность открытия ссылок в новом окне выходит за рамки нашего обсуждения. Суть в том, что XHTML 1.0 Transitional позволяет сделать это с минимальными затратами. XHTML 1.0 Transitional также позволяет указывать в коде цвет фона для ячеек таблицы и другие подобные приемы, которые целесообразнее было бы выполнить с помощью CSS. Если ваш DOCTYPE указывает на использование XHTML 1.0 Strict, а в коде присутствует элемент bgcolor, служба проверки укажет вам на ошибку, а некоторые браузеры проигнорируют этот атрибут. В свою очередь, если вы указали, что используете XHTML 1.0 Transitional, b g c o l o r не будет помечен как ошибка, а браузеры корректно обработают его. Иными словами, XHTML 1.0 Transitional является лучшим выбором для дизайнеров, осуществляющих переход к современным Web-стандартам. Иначе в W3C не назвали бы его переходным. Некоторые могут возразить, что при переходе к стандартам, оптимальным выбором станет XHTML 1.0 Strict, так же как некоторые полагают, что для желающих сбросить лишний вес оптимальным способом станет служба в морской пехоте. И все же мы полагаем, что для большинства читателей этой книги больше подходит XHTML 1.0 Transitional. Ниже приведен DOCTYPE для него: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtmll/DTD/xhtml1-transitional.dtd"> DOCTYPE frameset используется для документов, содержащих фреймы, то есть элементы <frameset>. Элемент DOCTYPE следует помещать над всеми XHTML-документами, перед остальным кодом. Он предшествует элементам <head>, < t i t l e > , <meta> и ссылкам на таблицы стилей и файлы скриптов JavaScript. Он также предшествует контенту. Другими словами, элемент DOCTYPE предшествует всему.

Преобразование в XHTML: простые правила, легкое руковоцсягМ

175

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

После DOCTYPE следует пространство имен Вслед за декларацией DOCTYPE следует объявление пространства имен XML, более подробное, чем элемент <html>: <html

xmlns=http://www.w3.org/1999/xhtml

xml:lang="ru"

lang="ru">

Пространством имен в XML является набор типов элементов и имен атрибутов, связанных с определенным DTD, декларация пространства имен позволяет идентифицировать пространство имен, указав на его расположение, в данном примере это www.w3.org/1999/xhtml. Два остальных атрибута указывают на то, что документ написан на русском языке и используемая версия XML также русская. С определением DOCTYPE и объявлением пространства имен ваша страница на XHTML 1.0 Transitional будет начинаться так: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtmll/DTD/xhtmll-transitional.dtd"> <html xmlns=http://www.w3.org/.1999/xhtml xml:lang="ru" lang="ru"> Скопировать, вставить и готово! Если вам не нравится перепечатывать код из книги, можете найти его на zeldman.com, alistapart.com или webstandards.org и просто скопировать его, изменив версию языка en на ги.

Укажите кодировку страницы Для корректного отображения в браузерах и прохождения тестов в службе проверки во всех документах XHTML необходимо указывать тип кодировки, используемой при их создании. Это может быть Unicode, Windows-1251, KOI8-R или чтото другое. Если вы не знакомы с системами кодировки или KOI8-R ни о чем вам не говорит - не беспокойтесь, мы коснемся этого вопроса чуть позже. Пока же вам необходимо запомнить - есть три способа сообщить браузеру об используемой кодировке, но только один из них надежно работает во всех браузерах на момент написания книги и ни одна из них не является рекомендуемой W3C.

176

Глава & KHTML: реструктуризация Сети

Объявление X M L и к а к его пропустить Многие XHTML-страницы начинаются с необязательного введения XML, также называемого объявлением XML. При использовании объявление XML должно быть расположено перед DOCTYPE и объявлением пространства имен. Его предназначением является указание версии XML и типа используемой кодировки. W3C рекомендует начинать все XML-документы, включая XHTML-документы, с этого объявления XML. Для указания кодировки Windows-1251 можно использовать следующее введение XML: <?хш1 version="l.О" encoding="Windows-1251" ?> Ничего сложного. Тег сообщает браузеру, что используется версия XML 1.0, а кодировка - Windows-1251. Единственное новшество - вопросительный знак, открывающий и закрывающий тег. К сожалению, многие старые браузеры, даже самые популярные, не могут нормально обработать этот XML-тег. После того как они сталкиваются с ним, браузеры начинаются «смущаться», «спотыкаться» и «задумываться». И все же в этом случае страдает не браузер, а посетитель, который не в состоянии просмотреть ваш сайт. Иногда весь сайт становится недоступным или «зависает» браузер пользователя. В других случаях сайт отображается, но некорректно. К счастью, есть решение для этой проблемы. Вместо этого объявления можно указать тип кодировки с помощью элемента Content-Type в разделе <head> вашего документа. Чтобы указать кодировку Windows-1251, введите следующее: <meta http-equiv="Content-Type" content="text/html; charset=Windows-1251" /> В этом случае начало вашего документа XHTML будет выглядеть следующим образом: <1DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 1 "http: //www.w3.org/TR/xhtmll/DTD/xhtmll-transitional.dtd' > <html xmlns=Hhttp://www.w3.org/1999/xhtml"> <head> <title>nepexoflHaH модель Web-документа.</title> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1251" /> </head>

Если вы работаете над международным сайтом, содержащим массу символов,.не принадлежащих к ASCII, можно использовать кодировку Unicode и вставить следующий элемент Content-Type в код:

Преобразование в ХНтеи.: простые правила, легкое руководство r

content

=11

177

text/html; charset=UTF-8" />

Вы можете всегда посмотреть исходный код страниц на zeldman.com, alistapart.com или webstandards.org и скопировать этот код.

Пишите все теги в нижнем регистре В отличие от HTML, XML чувствителен к регистру. Поэтому и XHTML также различает регистр. Все элементы XHTML и имена атрибутов следует писать строчными буквами, иначе ваш документ будет содержать ошибки. Давайте взглянем на типичный элемент HTML: <Т1ТЬЕ>Будущее Web-дизайна в красивом коде.</TITLE>

Это знакомый элемент TITLE. Перевести этот фрагмент на XHTML будет предельно просто - надо лишь переписать тег строчными буквами: <title>By\n;yii];ee Web-дизайна в красивом KOfle.</title>

Таким же образом <Р> становится <р>, <BODY> - <body> и так далее. Естественно, если в вашем HTML-документе все теги и элементы прописаны строчными буквами, вам не придется ничего менять. Но многие из нас привыкли писать элементы HTML заглавными буквами, поэтому необходимо преобразовать их в строчные для перехода на XHTML. Популярные HTML-редакторы вроде BareBones BBEdit, Optima-Systems PageSpinner и Allaire HomeSite позволяют автоматически преобразовать все теги и атрибуты в строчные буквы, а также это можно сделать с помощью бесплатного приложения HTML Tidy.

Не волнуйтесь о регистре значений атрибутов или контента Обратите внимание, что в нижнем регистре необходимо указывать лишь названия тегов, атрибутов и элементов. Регистр информативного содержимого может быть любым. Названия элементов и атрибутов должны быть в нижнем регистре, значения атрибутов и контент могут иметь любой регистр. Ниже приведены три примера, и все они относятся к корректному XHTML: <img src="/images/logo.jpg" alt="Логотип вашего сайта." /> <img s r c = " / i m a g e s / L O G O . J P G " a l t = "JIoroTjiII вашего с а й т а . " •/> <img s r c = " / i m a g e s / l o g o . j p g " а:и="ЛОГОТИП ВАШЕГО САЙТА." />

178

Глава 6. XHTML: реструктуризации Сети

В зависимости от используемого вами серверного ПО и операционной системы, имя файла, указанное в атрибуте, может быть в определенном регистре, но для XHTML это неважно. Однако значения ID и классов CSS чувствительны к регистрам. Будьте внимательны при работе с именами атрибутов со смешанным регистром. Если вы используете визуальные редакторы, например Macromedia Dreamweaver или графический редактор вроде Adobe ImageReady для создания элементов JavaScript, вам придется изменить такие элементы, как onMouseOver на onmouseover. С таким кодом могут возникнуть неприятности: OnMouseOver="changeImages () " А с этим все будет хорошо: onmouseover="changelmages()" Время уборки. В настоящее время наилучший способ создать XHTML-страницу - сделать это вручную. Однако часто Web-дизайн представляет собой редизайн, например обновление старых страниц. Редизайн дает прекрасную возможность перейти на XHTML, и необязательно делать это вручную. Например, бесплатное приложение HTML Tidy (рис. 6.1) поможет быстро преобразовать HTML в XHTML. Эта программа была создана сторонником стандартов Дэйвом Раггетом (Dave Raggett) и распространяется как приложение с открытым исходным кодом компанией Source Forge (http://tidy.sourceforge.net), а некоторые энтузиасты создали модификации этой программы. Например, Терри Тиг (Terry Teague) разработал версию для Мае OS (http:// www.geocities.com/terry_teague/tidy.html), которая и показана на рис. 6 . 1 . Существуют как онлайн-версии этой программы, так и отдельно загружаемые приложения для Windows, UNIX, Linux, Mac (OS 9 и OS X) и других платформ. Некоторые версии работают в виде дополнительных модулей для различных Web-приложений. Например, BBTidy является модулем для редактора BBEdit (X)HTML от компании BareBones Software. Каждая версия предлагает различные возможности и поставляется со своей документацией. Программа выглядит довольно просто, однако является мощным инструментом, и, чтобы лучше освоить ее, вам понадобится руководство пользователя.

Заключайте в кавычки все значения атрибутов В HTML не требуется заключать в кавычки значения атрибутов, однако в XHTML это требование является необходимым для выполнения (height="55", а не h e i g h t = 55). Вот в принципе и все, что можно сказать по этому поводу.

fipec-

ЭТ1Ж:

простые правттш, легкое р^&иводств®

179

Рис. 6.1. Бесплатная программа HTML Tidy (http://www.w3.org/People/Raggett/tidy) поможет преобразовать HTML в XHTML

Хотя, пожалуй, стоит отметить еще один момент. Предположим, значение атрибута включает в себя текст в кавычках. Например, если значением атрибута a l t является текст «Большой Театр представляет роман «Мастер и Маргарита» М.Булгакова», как вы это запишете? Вероятно, так: <img src="/images/bulgacov. jpg" a l t = "Большой Театр представляет роман "Мастер и Маргарита" М.Булгакова" /> Если вы пожелаете использовать код для типографических апострофов и кавычек, запись будет выглядеть следующим образом: <img src="/images/bulgacov. jpg" alt="Большой Театр представляет роман &#821б;Мастер и Маргарита&#821б; М.Булгакова" /> После того как вы заключили атрибуты в кавычки, необходимо разделить их пробелами. Такой код является ошибочным: <hr width="75%"size="7" /> Примечание. Программа проверки кода W3C обрабатывает как HTML, так и XHTML, и его анализатор не сможет отследить эту ошибку. Однако ее обнаружит любой анализатор, созданный для XML.

180

Глава 6. XHTML: реструктуризация Сети

Если в значении атрибута вам необходимо использовать прямые двойные кавычки, используйте для этого &quot;, как показано в следующем примере: <img src=/images/afisha.jpg" alt="Афиша гласила: постановка романа М.Булгакова.&quot;" />

&quot;Новая

Можно также использовать апостроф & a p o s ; для кавычек в атрибуте:

alt='I&apos;ve never been in

Заключение значения атрибута в кавычки в HTML было необязательным, но многие дизайнеры делали именно так, поэтому в этой области при переходе на XHTML делать ничего не потребуется. Некоторые сайты не использовали кавычки, чтобы снизить трафик. Для перехода на XHTML им придется начать делать это. Программа HTML Tidy может расставить все необходимые кавычки автоматически. На самом деле с ее помощью можно автоматически выполнить все упомянутые в этой главе задачи для перехода на XHTML.

Все атрибуты должны иметь значения Всем атрибутам в XHTML должны быть присвоены значения. Таким образом, атрибутам в следующем фрагменте HTML-кода: <td nowrap> <input type="checkbox" name="shirt" value="medium" checked> <hr noshade> должны быть присвоены значения. Значения должны быть идентичны самим атрибутам: <td nowrap="nowrap"> <input type="checkbox" name="shirt" value="medium" checked="checked" /> <hr no shade =''no shade" /> Мы знаем, знаем. Выглядит странно и требует привыкания. Но, ничего не поделать, это стандарты.

Закрывайте все теги В HTML можно было открывать некоторые теги, например <р> и < l i > , и не закрывать их. Ниже приведен фрагмент вполне приемлемого HTML-кода, но никуда не годного XHTML-кода:

Преобразование в XHTML: простые правила, яешое py введете!»

181

<р>Это корректный HTML-код, но он не годится для XHTML. <р>Я забыл закрыть тег абзаца! <р>Но, HTML все равно. Зачем вообще было изменять эти правила? В XHTML все открытые теги должны быть закрыты: <р>Это корректный HTML-код, и он годится для XHTML.</р> <р>Я закрываю все теги после открытия.</р> Это правило, что каждый тег должен быть закрыт после его открытия, выглядит более разумным, чем неразбериха в HTML, и оно может помочь избежать ненужных проблем. Например, если вы забудете закрыть тег абзаца, в некоторых браузерах может возникнуть проблема отображения CSS на вашей странице. XHTML принуждает вас закрывать все теги и, таким образом, обеспечивает работоспособность вашей страницы.

«Пустые» теги тоже нужно закрывать В XHTML даже «пустые» теги, такие как <br> и <img>, также необходимо закрывать с помощью прямого слэша (/) в конце тега: <br /> <img-src="zeldman.gif" /> Обратите внимание на слэш (/>) после тега разрыва страницы. Теперь присмотритесь к слэшу после тега изображения. Перед ними необходимо вставлять пробел, чтобы браузеры, созданные до появления стандарта XHTML, также распознавали их. Последние версии BBEdit, PageSpinner и HomeSite автоматически добавляют пробелы и слэшы к пустым тегам, если вы укажете, что создаете XHTML-документ (рис. 6.2). Так же поступают и визуальные редакторы вроде Dreamweaver и GoLive. Вообще-то, для повышения доступности элемент изображения в данном примере должен иметь атрибут a l t и t i t l e : <img src="zeldman.gif" а1Ь="Д.Зельдман - автор книги Web-дизайн по стандартам." title="Д.Зельдман, один самых уважаемых и именитых Web-дизайнеров." /> Теперь это хороший XHTML-код.

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

182

Глава 6* XHTIViL; реструктуризации Сети

Рис. 6.2. При работе в режиме XHTML в PageSpinner программа автоматически закрывает все теги и пишет названия элементов в нижнем регистре (www.optima-system.com/pagespinner)

<!— Недопустимый фрагмент: — так же как и классический "разделитель" внизу. — > ^ i

I Шт

Необходимо либо заменить тире другими символами, либо разделять их пробелами: < I — Допустимый фрагмент - - как и разделитель, приведенный ниже —> < | = = = =:=: = =: = = = = = = — = =:=: = =: = = = =: — =: ->

Кодируйте все символы < и & Все символы «меньше» (<), когда они не являются частью тега, следует кодировать как & l t ; , а символы амперсанда (&), не являющиеся частью элементов escape-последовательности, следует кодировать как &атр;. Таким образом: <p>She & he say t h a t x < у when z = 3. </p> следует писать как: <p>She &amp; he say t h a t x &lt; у when z = 3. </p> Служба проверки кода W3C пропустит код с этими символами в незакодированном виде и выдаст предупреждение, тогда как анализатор XML сообщит о неустранимой ошибке. Примечание. Рекомендуем вам всегда кодировать и знак > как &gt;. Несмотря на то что в этом нет жесткой необходимости, в этом случае ваш код будет более симметричным и понятным для других программистов. Итак, давайте рассмотрим изученные правила XHTML.

Кодировка: глупо, по-иастояще^у гну

те

183

Выводы: правила X H T M L Вот эти правила: • • • • • • • • •

документы начинайте с указания DOCTYPE и пространства имен; указывайте кодировку документа с помощью элемента МЕТА Content; названия всех элементов и атрибутов пишите строчными буквами; значения атрибутов заключайте в кавычки; значения присваивайте всем атрибутам; закрывайте все теги; закрывайте «пустые» теги пробелом и слэшем; не вставляйте двойные тире в комментарии; заменяйте знаки < и 8с на &11; и &атр;.

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

Кодировка: глупо, по-настоящему глупо Возможно, читая раздел «Укажите кодировку страницы», вы спрашивали себя, зачем это нужно. Возможно, вы даже спросили себя о том, что такое кодировка страницы. Ответы на эти вопросы находятся ниже. Если вы спрашиваете себя, должны ли вы читать все эти утомительные объяснения до конца, отвечаем да. Если мы написали все это, то кто-то должен и прочитать. Кроме того, вы можете кое-чему научиться благодаря этому.

Unicode и другие к о д и р о в к и По умолчанию для документов XML, XHTML и HTML 4.0 используется кодировка Unicode (http://www.w3.org/International/O-unicode.html), стандарт, принятый Unicode Consortium (www.unicode.org). Стандарт Unicode является удобной кодировкой, присваивающей уникальное число для каждого символа независимо от платформы, программы или языка. Unicode можно назвать универсальным алфавитом, только скорее это не алфавит, а цифровая схема соответствий. Несмотря на то что Unicode используется по умолчанию в Web-документах, разработчики могут выбрать и другую кодировку, лучше отвечающую их потребностям. Например, американские и западноевропейские Web-сайты часто используют кодировку ISO-8859-1 (Latin-1).

184

Глава 6. XHTIVIL; реструктуризация Сети

Что т а к о е ISO 8 8 5 9 ? ISO 8859 является группой стандартизированных побайтово-закодированных наборов символов для определения множества алфавитных языков, и первый из этих наборов - ISO-8859-1 (также называемый Latin-1) используется для западноевропейских языков. ISO-8859 включает в себя Latin-2 (восточноевропейский стандарт), турецкий язык, греческий, иврит, русский и другие. Стандарт ISO-8859 был создан в середине 80-х годов Европейской ассоциацией производителей компьютеров (ЕСМА) и одобрен Международной организацией по стандартизации (ISO).

Объявление кодировки Независимо от выбранной кодировки вам следует указать ее в документе, как упоминалось ранее. Для этого можно выбрать один из трех способов: • администратор сервера может указать кодировку с помощью заголовков HTTP, возвращаемых Web-сервером. W3C рекомендует именно такой способ, но мало кто использует его на практике. Возможно, потому, что администраторы серверов чаще заняты игрой в сетевые игры, чем заголовками HTTP; • для документов XML, включая XHTML, дизайнеры/разработчики могут указать кодировку с помощью объявления XML. W3C также рекомендует этот способ, но пока браузеры не научатся корректно обрабатывать код, мы не советуем поступать таким образом; • в документах HTML или XHTML можно указать кодировку с помощью метаэлемента Content-Type. Мы советуем именно такой способ, так как, в отличие от системного администратора, который может забыть о своей работе, и от пролога XML, который может быть неправильно обработан браузером, данный способ является наиболее надежным. Поздравляем! Вы только что закончили чтение самой неинтересной части этой книги. Теперь перейдем к переосмыслению Web-дизайна как искусства и методов создания сайтов.

Структурное исцеление Разработка сайтов в XHTML не ограничивается переходом с верхнего регистра на нижний и добавлением слэшей в конце некоторых тегов. Если бы дело

Структурны* исцеление

185

заключалось только в этом, все было бы слишком просто. Для получения позитивных результатов от использования XHTML необходимо воспринимать код как нечто структурное, а не визуальное.

Создание кода с учетом логики, а не стиля Запомните: насколько это возможно, используйте CSS для разметки страницы. В мире Web-стандартов код XHTML используется не для оформления внешнего вида, а для формирования структуры документа. Документы с хорошей структурой так же доступны пользователям карманных компьютеров и программ для чтения информации с экрана, как и пользователям последних версий компьютерных браузеров. Такие документы так же корректно отображаются в старых браузерах, не поддерживающих CSS, как и в новых, пользователи которых по тем или иным причинам отключили CSS. Конечно, не любой сайт может отказаться от использования табличной HTML-разметки. Изобретатели CSS W3C не спешили переводить свой сайт на CSS-разметку до декабря 2002 года. Кроме того, даже самые ярые приверженцы стандартов не всегда в состоянии отделить структуру от оформления, по крайней мере не в XHTML 1. Но такое отделение структуры от внешнего вида (или данных от дизайна) является идеалом, к которому все мы должны стремиться. Ниже вы найдете некоторые советы, которые помогут вам начать мыслить структурно.

Цвет внутри границ В школе нам всем приходилось писать сочинения в тетрадках одинакового размера. Когда мы стали дизайнерами, мы почувствовали свободу от ненужных границ и пустились в плавание по волнам самовыражения. И все же в HTML нам приходилось всегда размещать текстовый контент в некоторой ограниченной иерархией структуре. После того как браузеры стали поддерживать CSS, мы получили возможность создавать документы более свободно. При создании текста для сайта или преобразовании имеющихся документов в Web-страницы старайтесь мыслить в контексте традиционных, последовательных границ: <Ь1>Тема</Ы>

•

<р>Введение</р> <112>Подзаголовок</Ь2> <р>Текст</р>

• • -

186

Глава 6. XHTML: реструктуризация Сети

Старайтесь избегать использования устаревших HTML-элементов, например тегов <f ont> или бессмысленных элементов <br />, для имитации логической структуры там, где ее нет. Например, не пишите так: <font size="7 ">TeMa</fontxbr /> Введение<Ьг / x b r /> <font size=" 6" >Подзаголовок</:£ontxbr Текст<Ьг /> .

/> -

Используйте элементы согласно их значению, а не внешнему виду Некоторые из нас имеют обыкновение помечать текст тегом <hl>, когда мы хотим сделать его покрупнее, или использовать тег < l i > , когда мы хотим добавить перед текстом маркер. Мы привыкли, что <hl> означает крупный шрифт, < l i > - маркер, a <blockquote> - отступ. С помощью структурных элементов HTML мы создаем внешний вид страницы. Или, например, если дизайнер хочет сделать одинаковым размер всех заголовков, он может использовать для этого тег <hl>, хотя это и создает структурную неразбериху, а специалист по юзабилити Джейкоб Нильсен назвал бы это грехом, если бы не был так занят проблемой цвета ссылок: <hl>3To главный заголовок, вернее, он был бы таким, если бы я организовал свой текст.</hl> <hl>3To не главный заголовок, но я хотел, чтобы он был такого же размера, как и главный заголовок. Кроме того, я не умею работать с CSS.</hl> <hl>A это вообще не заголовок. Но я очень хотел, чтобы весь текст на странице был одного размера. Если бы я знал о CSS, я бы смог добиться этого без пожертвования структурой документа.</Ы> Игры кончились, пора начать использовать элементы по их назначению, а не по внешнему виду. На самом деле <hl> может выглядеть, как вы того захотите. Например, в CSS тег <hl> может быть мелким и в шрифте Roman, текст с тегом <р> может быть крупным и полужирным, < l i > может не иметь маркера (или же может вместо него использовать изображение в формате PNG, GIF или JPEG) и так далее. Начиная с сегодняшнего дня мы будем использовать CSS для задания внешнего вида элемента. Мы даже можем установить их внешний вид в зависимости от их расположения на странице или сайте. Больше нет необходимости (если

Структурное исцеление

187

она вообще когда-либо была) использовать < l i > для целей, отличных от его предназначения, - указывать, что элемент является частью списка других схожих элементов. CSS полностью отделяет внешний вид документа от структуры, позволяя придать любому элементу требуемый стиль. В совместимых с CSS браузерах при желании можно сделать, чтобы заголовки всех шести уровней (hl-h6) выглядели одинаково: h i , h2, h 3 , h4, h5, h6 { font-family: georgia, palatino, "Book Antiqua", times, serif; font-weight: normal; font-size: 2 em; margin-top: lem; margin-bottom: 0; }

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

Предпочтение структурных элементов бессмысленному коду Так как мы забыли или не знали, что элементы HTML и XHTML предназначены для структуризации документов, многие из нас стали создавать код, не содержащий структуры вовсе. Например, многие HTML-дизайнеры создают список на своих страницах следующим образом: Пункт списка <br /> Еще один пункт <br /> Следующий пункт <br />

Вместо этого можно использовать такой код:

188

Глава 6* XHTIVIL; ре€трумтуртацтт Сети

«Но < 1 i> добавляет маркер, а мне он не нужен!» - можете возразить вы. Ответ приведен в предыдущем разделе. CSS отображает структурные элементы так, как вы скажете ему. Отключить маркер для CSS - это пара пустяков. Он может заставить список выглядеть как обычный текст абзаца или как графическая панель навигации со всевозможными эффектами при наведении на нее указателя мыши. Поэтому используйте элемент < l i > для создания списков. Также предпочитайте <strong> тегу <b>, <em> - <i> и так далее. По умолчанию большинство браузеров отобразит <strong> как <b>, a <em> как <i>, что создаст желаемый визуальный эффект без ущерба для структуры документа. Пока еще нам не попадался браузер, отображающей <strong> иначе, чем полужирным (конечно, если сам дизайнер не захочет этого). Если же вы волнуетесь, что вдруг попадется какой-нибудь странный браузер, отображающий < s t r o n g > по-своему, можно использовать следующее правило CSS: strong

{ font-weight: bold; font-style: normal; }

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

Визуальные элементы и структура Соблюдение Web-стандартов проявляется не только в используемых нами технологиях, но и в том, каким образом мы их используем. XHTML-код и разметка в CSS не делают автоматически наши сайты более доступными, совместимыми или компактными. XHTML или CSS важно использовать правильно. Некорректный XHTML-код производит трафика» не меньше, чем такой же HTML-код. Громоздкий, чрезмерно нагруженный CSS не станет правильной заменой разметки таблицами HTML, это всего лишь замена одной плохой вещи на другую. Советы, приведенные в разделе «Структурное исцеление», помогут избежать сложных, семантически бессмысленных структур. А как же быть с визуальными элементами, например с панелью навигации, которая обычно включает в себя и логотип компании? Могут ли эти элементы быть структурными? Должны ли они быть такими?

Визуальные элементы и структура

189

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

Г Л MB 7. Структура и метаструктура в строгой и смешанной разметке

чем бы вы ни думали, не пропускайте эту главу. Ее прочтение усовершенствует ваши навыки и углубит понимание разницы между кодом и дизайном. В этой главе мы коснемся некоторых идей, легких для понимания, которые могут значительным образом изменить облик вашего сайта и облегчить работу над его созданием, дизайном и обновлением. В этой главе мы покажем, как писать логичный, компактный код, который может снизить трафик практически на 50%, таким образом ускорить загрузку сайта и снизить нагрузку на сервер. Мы достигнем этих результатов, устранив из XHTML-кода ненужные элементы, а также научимся избегать зловредных приемов, не дающих хороших результатов. Эти приемы заразили множество сайтов, особенно те, которые используют некоторые элементы CSS в сочетании с табличной разметкой. Почти всегда это выполнено неаккуратно и неверно, даже если дизайнеры и являются опытными профессионалами. Такие проблемы могут появиться и на сайтах, написанных вручную, и на созданных в визуальных редакторах вроде Dreamweaver и GoLive. В данной главе мы перечислим наиболее распространенные ошибки, чтобы вы знали о них и обезопасили себя от их использования, а также мы расскажем, какие приемы использовать вместо них. Мы также познакомимся с идентификатором id и покажем, как с его помощью писать ультракомпактные коды XHTML при создании смешанной или чистой CSS-разметки.

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

Должен ли каждый элемент быть структурные?

191

что даже в чистой CSS-разметке некоторые компоненты могут быть не структурированными, по крайней мере с точки зрения «заголовок-абзац-список», описанной в главе 6. Тем не менее эти элементы могут быть метаструктурированными. То есть они могут быть созданы с помощью общих структурных элементов и определенных атрибутов, указывающих на специфическую структурную роль, которую они выполняют в дизайне сайта. Это делается не для каких-то теоретических целей, а для самых необходимых - например, для снижения трафика и облегчения обслуживанием сайта. Рубрика ежедневных новостей на сайте zeldman.com (рис. 7.1) использует CSS для разметки и XHTML для создания структуры. Почти все элементы кода структурны - от списков до абзацев и логотипа.

Рис. 7.1. Рубрика ежедневных новостей на zeldman.com. CSS для разметки, XHTML для кода. Навигационные элементы вверху страницы не структурированы или наоборот?

192

Глава 7, Структура и метаоруктура в строгой и смешанной размети:©

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

div, id и другие помощники В этой и последующих главах будет часто упоминаться элемент d i v и атрибут id. При правильном использовании d i v является незаменимым помощником при создании структурного кода, тогда как с помощью id вы сможете создавать удивительно компактный код, разумно применять CSS и придавать сайту любую динамику посредством управления объектной моделью документа (DOM). W3C следующим образом определяет эти и другие элементы HTML/XHTML: «Элементы d i v и span вместе с атрибутами id и c l a s s представляют собой механизм для формирования структуры документа. Span указывает на то, что контент должен располагаться в строке, a d i v - в блоках, однако больше никаких ограничений на внешний вид не накладывается. Таким образом, дизайнеры могут использовать эти элементы совместно с таблицами стилей для изменения HTML-кода в соответствии со своими нуждами (http://www.w3.org/ TR/REC-html40/struct/global.html#h-7.5.4)». Что такое div. «div» является сокращением от «division» (часть, раздел). Когда вы собираете несколько ссылок вместе, это становится одной частью документа. Контент выделяется в другую, заявление об авторских правах - в третью, а нижнее меню страницы станет отдельной частью.

Общий механизм для частных структур Все HTML-программисты знакомы с общими элементами, такими как тег абзаца или h i , но некоторые могут быть не знакомы с div. Ключ к пониманию сущности d i v лежит в его определении W3C как «общий механизм для добавления структуры». В примере с сайтом zeldman.com элементы навигационной графики заключены в теги div, так как они не являются частью абзаца, списка или другого заданного структурного элемента. Но в более общем смысле слова эти изображения играют определенную структурную роль, а именно выполняют роль навигационных элементов. Чтобы выделить эту роль, элементу div с изображениями присвоен

Должен пи каждый элемент быть структурным?

193

атрибут id «primenav», что является используемым мной сокращением от «primary navigation», то есть «основная навигация». Вы можете использовать любое другое название на свой вкус. Но лучше всего подходят метаструктурные названия (то есть названия, объясняющие выполняемые элементом функции). Это позволяет избежать такой ситуации, когда при просмотре кода спустя, скажем, полгода после его создания, вы будете мучительно вспоминать, о каком элементе идет речь - области навигации, боковой панели, форме поиска или еще чем-нибудь. Кроме того, использование структурных меток id вроде «меню», «контент» или «форма поиска» будет напоминать вам, что код - это не дизайн, и структурная страница может выглядеть, как вы пожелаете. Работаете ли вы с чистым CSS или со смешанной разметкой (CSS и таблицы), если вы возьмете за правило присваивать структурные названия основным компонентам страницы (таким, как навигация, контент и области поиска), то вы автоматически начнете удаляться от беспорядочного кода.

id против class Атрибут id не является новичком в XHTML, так же как c l a s s или элементы d i v и span. Все они происходят из HTML. С помощью атрибута id можно присвоить элементу уникальное имя. Каждое имя можно использовать в пределах одной страницы только один раз. (То есть, если на вашей странице есть d i v с id «content», она не может содержать другой d i v или элемент с таким же именем.) В свою очередь, атрибут c l a s s можно использовать в пределах одной страницы несколько раз. (Например, пять абзацев на странице могут относиться к классу «small» или «footnote».) Приведенный ниже фрагмент кода поможет понять разницу между c l a s s n i d : <div id="searchform">3десь разместить компоненты формы поиска.</div> <div с1азз="Ь1одеп1:гу">Здесь разместить запись Be6nora.</div> В этих примерах d i v i d = " searchform" необходим для определения области страницы, содержащей форму поиска, тогда как d i v c l a s s = " b l o g e n t r y " можно использовать для определения области страницы под каждую запись веблога (более привычен термин блог). Так как на странице имеется только одна форма поиска, для нее выбран атрибут id. Но блог может содержать несколько записей, поэтому для него используется атрибут c l a s s . Если блог может обойтись без использования элементов div, если возможно использовать обычную структуру заголовков и абзацев - так даже лучше. Ежедневные новости на zeldman.com многие называют блогом, хотя записи на этой странице оформлены общими элементами h3, h4 и р.

194

Глава Т, Структура и метаструктура в строгой и смешанной разметке

Теория стикеров Можно сравнить атрибут id со стикерами - ьслейкими записками, которые мы прилепляем на холодильник, чтобы не забыть купить молоко, или на телефон, чтобы не забыть перезвонить задолжавшему заказчику. Атрибут id схожим образом помечает определенную область кода, напоминая, что он требует какого-то особенного обращения. Для этого вы позднее напишете одно или несколько правил в таблице стилей или несколько строк кода в файле JavaScript, относящихся к этому id. Например, файл таблицы стилей CSS может содержать особые правила, относящиеся только к элементам с атрибутом id «searchform» или к таблице с id «menubar». Когда атрибут id используется в качестве метки для определенного набора правил CSS, он называется селектор CSS. Есть много способов создать селекторы (см. главу 9), в частности использовать id, что очень удобно и гибко.

Мощь id Атрибут id является чрезвычайно мощным инструментом. Помимо прочего, его можно использовать для решения следующих задач: • в качестве селектора таблиц стилей, что позволяет создавать компактный XHTML-код; • в качестве якоря для гипертекстовых ссылок, заменив им устаревший атрибут «name»; • для ссылки на определенный элемент основанного на DOM скрипта; • в качестве имени объявленного элемента объекта; • как средство для последующей обработки документа (например, для идентификации полей при извлечении данных из Web-страниц и занесения их в базу данных, при переводе документов HTML в другой формат и так далее). Правила применения атрибута i d . Значение id должно начинаться с буквы или подчеркивания, оно не может начинаться с цифры. Служба проверки кода W 3 C может и не заметит подобную ошибку, однако анализатор XML ее обнаружит. Также, если вы намереваетесь использовать id в JavaScript в форме d o c u m e n t . i d n a m e . v a l u e , необходимо присвоить ему допустимое имя переменной JavaScript, которое должно начинаться с буквы или символа подчеркивания и в которых не допускается использование пробелов или дефисов. Также нежелательно использовать символы подчеркивания в именах c l a s s или id по причине старых ограничений в CSS и старых браузерах.

Должен ли наждый элемент быть структурным?

195

Правила применения атрибута id (окончание). Наконец, для самых строгих приверженцев стандартов отметим, что первым символом в имени id или c l a s s может быть и цифра - вместо самой цифры необходимо указать соответствующую escapeпоследовательность. Правда, таким методом никто не пользуется.

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

Попробуйте делать меньше Теперь, после того как мы обсудили элементы XHTML общего назначения (в частности, d i v и id), давайте еще раз взглянем (рис. 7.1) на пример с сайта zeldman.com. Четыре больших изображения меню расположены с помощью общего элемента div, имеющего уникальную метаструктурную метку «primenav»: <div id="primenav">[Здесь разместить изображения со ссылками.] </ div> Этот способ отличается от более знакомого приема тем, что в описании элемента отсутствуют инструкции для его отображения - не указаны ни высота, ни ширина, ни фоновый цвет, ни горизонтальное или вертикальное выравнивание. Так как же браузер понимает, где расположено изображение? Давайте вспомним о рассмотренных ранее селекторах CSS. " primenav" как раз и является таким селектором. В одной из таблиц стилей сайта в правилах CSSуказано, что элемент "primenav" не имеет отступов и полей, - иными словами, он не окружен пустым пространством. Так как первый видимый элемент кода XHTML - это <div id=" primenav" >, совместимые с CSS браузеры поместят его в верхний левый угол страницы. Четыре изображения элементов меню располагаются с помощью элемента "primenav" в строке один за другим. Нет необходимости использовать таблицу для выравнивания этих элементов относительно друг друга. Также не нужно выравнивать каждый элемент с помощью отдельного правила CSS. Элементы отображаются на странице в том же порядке, в котором они перечислены в XHTML-коде.

196 Г пава 1. Структура и гкетасгруктура в строгой и смешанной разметке

С помощью такого приема мы можем избежать табличной разметки и использования ненужных таблиц стилей, создав четкую разметку, которая загружается быстрее за счет отсутствия лишних правил CSS. Ниже приведен фрагмент кода сайта zeldman.com с удаленными элементами ссылки на JavaScript и условными путями к изображениям: <div id="primenav"> <а href="/"ximg src="/i/home.gif" width="150" height= H 100" border="0" alt="Home" /></a> <a href="/"<img src="i"dailyreport.gif" width "140" height="100" border="0" alt="The Daily Report" /></a> <a href="/glamorous/"<img src="/i/glamorouslife.gif" width="110" height="100" border="0" alt="My Glamorous Life"/x/a> <a href="/classics/"ximg src="/i/classic .gif" width="100" height="100" border="0" alt="Classics, 1995-2002" /></a>

Обратите внимание, что использование атрибутов высоты и ширины изображений желательно, но не обязательно. Также благодаря CSS атрибут границ является абсолютно ненужным, хотя мы и используем его в этом фрагменте для старых браузеров. Приведенный выше фрагмент кода мог бы выглядеть следующим образом: <div id="primenav"> <а href =" / "ximg src="/i/home.gif" alt = "Home" /></a> <a href ="/ "ximg src=" /i/dailyreport .gif" alt="The Daily Report" /></a> <a href =" /glamorous/ "ximg src="/i/glamorouslife.gif" alt="My Glamorous Life"/x/a> <a href ="/classics/"ximg src="/i/classics.gif" alt="Classics, 1995-2002" /x/a>

А теперь сравните компактность и логичность предыдущего примера с обычным кодом подобной табличной разметки: <table border="0" cellpadding="0" cellspacing="0" width="500"> <tr> <td valign="top" width="150" height="100" bgcolor="#339999"> <a href="/"ximg src="/i/home.gif" width="150" height="100" border="0" alt="Home" /></a> </td> <td valign="top" width="140" height="100" bgcolor="#339999"> <a href ="/"ximg src=" /i/dailyreport .gif" width="140" height="100" border="0" a l t = "Daily Report" /x/a>

Смешанная разкгетка и компактный мед - за н против 197 </td> <td valign="top" width="110" height="100" bgcolor="#339999"> <a href="/glamorous/"ximg src="/i/glamorouslife.gif" width="110" H height="100" border="0 alt="My Glamorous Life" /></a> </td> <td valign="top" width="100" height="100n bgcolor="#339999"> <a href =" /classics/ "ximg src="/i/classics .gif" width="100" height="100" border="0" alt="Classics, 1995-2002" /></a> </td>

</tr> </table>

Разница очевидна. Однако компактный код и метаструктурное мышление не ограничиваются только разметкой CSS. Они могут применяться и при табличной разметке.

Смешанная разметка и компактный код за и против

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

198

Глава ?* Структуpa m e i

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

Распространенные ошибки смешанной разметки Давайте рассмотрим типичный для табличной разметки дизайн сайта (рис. 7.2) с навигационным меню (рис.7.3), изменяющим свой внешний вид (рис. 7.4) в зависимости от местонахождения пользователя на сайте. В качестве логотипа сайта, скорее всего, будет использоваться простое изображение, вероятнее всего, в формате GIF. Пункты меню (События, О компании, Контакты и т.д.) могут также быть как изображениями, так и простыми гипертекстовыми ссылками. Если используются гипертекстовые ссылки, сторонники старых методов воспользуются тегами шрифта для управления внешним видом (размер, шрифт, цвет) и устаревшими атрибутами для выравнивания, установки границ и фонового цвета ячейки таблицы, содержащей пункт меню. Современные дизайнеры обратятся для этого к CSS, однако при неверном использовании полученные результаты могут быть еще хуже. Даже если для пунктов меню используются изображения GIF, дизайнер, скорее всего, постарается как-то выделить меню на фоне других элементов сайта. Например, использовать для меню тонкие черные границы (рис. 7.3-7.4), тогда как остальные элементы сайта обходятся без границ. В еще более запущенном случае дизайнер может поместить таблицу с меню внутри другой таблицы, единственной целью которой является создание рамки. Вот так мы создавали

тат ртштш ш компактный над - за и против

199

200

Глава 1. Структура и метаструнпгура в строгой и смешанной разметке

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

Класситсы: болезнь кода Каким образом мы отличаем ячейки таблицы, служащие пунктами меню, от остальных ячеек на странице? Или заставляем ссылки внутри этих ячеек отличаться от всех иных ссылок страницы? Точно не с помощью устаревших тегов оформления и атрибутов вроде bgcolor, как вы уже могли догадаться. Мы не используем подобный код: <td align="left" valign="top" bordercolor="black" bgcolor="white"> <font family="verdana, a r i a l " size="2"><b> <a href="/events/">Co6HTMH</a></b></fontx/td> и так далее.

Но также мы не хотим, чтобы к каждому элементу, требующему особенного обращения, присваивался c l a s s , что встречается довольно часто: <td class="whitewithblackborder"xspan class="menuclass"><b> <a href ="/events/">Co6HTMH</ax/b></spanx/td> и так далее.

Как бы это ни было прискорбно, но мы признаемся, что видели даже такие образцы: <td class= "whitewithblackborder"xspan class="menuclassxfont class= "menuf ontclass" x b > <a href ="/events/ ll >Co6HTMH</a></bx/fontx/spanx/td> и так далее. Мы называем такой стиль разметки класситсом (classitis). На подобных сайтах каждый тег имеет свой класс. Чрезмерное использование элемента c l a s s необоснованно увеличивает размер кода каждой страницы. Появление этого приема уходит корнями во времена, когда браузеры едва-едва поддерживали CSS, а также оно отражает весьма неглубокие и поверхностные познания дизайнера в CSS. Возможно также, что многие дизайнеры так и не переросли этот этап поверхностных знаний о CSS, так как перешли на изучение других технологий Web-дизайна, или учили CSS с помощью просмотра кода, создаваемого их визуальными редакторами, прилепляющими c l a s s к каждому генерируемому ими тегу.

Смешанная разметка и компактный нод - за и против

201

Визуальные редакторы и класситсы. Даже самый лучший и современный визуальный редактор все равно норовит вставить несколько ненужных атрибутов c l a s s туда, где они совершенно не нужны. Это объясняется именно тем, что это визуальные редакторы, а не люди, которые могут абстрагироваться от частностей и мыслить глобально. То есть, когда вы задаете абзацу стиль в CSS, вы знаете, что собираетесь задать этот стиль всем абзацам. Но редактор не может читать ваши мысли. Таким образом, например, если вы работаете в таком редакторе и создадите пять абзацев, отформатированных шрифтом Verdana I I px, приложение может создать для каждого абзаца свой c l a s s . Несмотря на всю мощь и совместимость со стандартами таких редакторов, как Dreamweaver и GoLive, вам все равно не помешает иногда просматривать созданный ими код и редактировать его.

202

Глава 7, Структура ш метаструктура в строгой и смешанной раздаетке

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

В div нет ничего плохого Кто-то из вас, наверное, посчитал меня непоследовательным. В одном разделе я пишу, что использовать d i v не надо, а в первом примере этой главы (в описании меню zeldman.com) сам использовал div. Как это понимать? На самом деле я никогда не говорил, что использовать d i v - плохо. Тег div является вполне приемлемым элементом кода, предназначенным для расположения структурных элементов на вашем сайте. Но стоит не использовать d i v лишь тогда, когда вы слишком часто заменяете им другие, более уместные элементы. То есть, если вы создали абзац, то пусть он будет абзацем и помечен соответствующим образом, а не элементом d i v класса t e x t . Самый крупный заголовок на странице должен быть помечен тегом h i , а не <div с las.s=" h e a d l i n e " > . Чувствуете разницу? Конечно, да.

Почему div? Многие дизайнеры используют тег d i v в далеком от структуры контексте для замены любых элементов - от абзаца до заголовка. Большинство из них приобрели эту привычку, обнаружив, что браузеры 4.0, в частности Netscape, вставляли ненужное пустое пространство, разрушающее разметку, вокруг структурных элементов вроде <hl>, однако с разметкой, использующей неструктурные элементы div, все было хорошо. Пытаясь сохранить мельчайшие нюансы разметки для стремительно снижающегося числа пользователей браузеров четвертых версий, многие дизайнеры так увлеклись, что стали настаивать на использовании неструктурных элементов d i v вместо обычных элементов абзаца, заголовка и так далее. Цена такого метода высока. Такие сайты практически недоступны растущему числу пользователей карманных компьютеров, мобильных телефонов и программ

Смешанная разметка и компактный над - за ш против

203

для чтения информации с экрана. Кроме того, такой код совершенно неоправданно увеличивает используемый трафик. Еще одним примером использования дивитсов является ситуация, когда дизайнер заражается вирусом «таблицы - плохо, CSS - хорошо» и с энтузиазмом заменяет 200 т «замусоренного» кода на 200 т вложенных di v. Таким образом нельзя добиться положительного результата, вместо этого лишь затрудняется редактирование документов.

Любовь к id Итак, если неструктурный код отменяется, класситсы и дивитсы тоже, то какие правила дизайна мы применим к области навигации нашего сайта при смешанной разметке, сочетающей таблицы и CSS? Мы сделаем это с помощью атрибута id. Присвоим уникальную, метаструктурную метку таблице, содержащей меню: <table id="menu"> Позднее, при создании таблицы стилей, мы создадим селектор «menu» и связанный с ним набор правил CSS, указывающих параметры отображения для ячеек таблицы, текстовых и других элементов. При использовании гипертекстовых ссылок в качестве пунктов меню можно обойтись еще меньшими усилиями: <tdxa

href ="/events/">Co6biTMH</a></td>

«А где остальное?» - спросите вы. А больше ничего и не требуется, кроме кода для других ячеек таблицы. Пометив таблицу идентификатором «menu» или другим подходящим именем и используя «menu» в качестве CSS селектора в таблице стилей, вы избежите вех описанных здесь ошибок. Нет класситсов, нет дивитсов, нет ненужных тегов <font>. Нет надобности использовать устаревшие параметры высоты, ширины, выравнивания, фонового цвета для каждого экземпляра элемента <td>. С помощью одного идентификатора id вы подготовили чистый и компактный код для обработки в отдельной таблице стилей. CSS будет управлять всеми аспектами внешнего вида данной ячейки таблицы, включая фоновый цвет (или изображение), рамку, отступы, горизонтальное или вертикальное выравнивание и, конечно, эффекты при наведении указателя мыши на элемент. Такие эффекты часто включают в себя изменение фонового цвета, цвета рамки или и то и другое. Эти эффекты поддерживаются большинством браузеров и не вызовут ошибку в браузерах, не поддерживающих их. Таким же образом с помощью CSS можно контролировать и внешний вид ссылки, включая шрифт, его размер, цвет и множество других свойств.

204

Глава 7. Структура и тетаструктура в строгой и смешанной разметке

А как насчет изображений? Работает ли эта комбинация уникального id, компактного XHTML и таблицы стилей так же хорошо, если для табличных меню используются изображения, а не гипертекстовые ссылки? Хороший вопрос! Схема работы такая же. Создайте таблицу с самыми необходимыми элементами, проделайте ту же процедуру с изображениями и убедитесь, что каждое изображение имеет соответствующий атрибут a l t . Можно комбинировать прозрачные изображения GIF с правилами CSS, создающими эффекты при наведении указателя мыши без использования JavaScript. Но не будем забегать вперед. Для понимания того, как сделать табличную разметку более «умной» и менее «вредной», нужно коснуться еще одного момента.

Прочь лишние ячейки таблицы Рассмотрим сайт старейшего в Сети поставщика редких видов рыб и кораллов The Marine Center (рис. 7.5), созданный в 2003 году. Обратите внимание, что разметка сайта разделена на несколько областей, привязанных к определенной задаче. Например, колонка справа предлагает купить самые популярные в настоящее время продукты, а также позволяет посетителю зарегистрироваться в списке рассылки сайта и найти нужную информацию. В центральной области представлены новые поступления в виде сменяющихся фотографий рыб, также посетителю предлагается ознакомиться с ежемесячной колонкой Истории о рыбах. При такой разметке обычно каждый компонент заключен в свою ячейку таблицы, почти так же, как и на сайте Gilmore (см. рис. 2.3-2.4). В обычной разметке, созданной с помощью нарезки изображения в Photoshop или расположения элементов в визуальном редакторе, крупное изображение рыбы будет находиться в своей ячейке таблицы, так же как и мелкие изображения, графический заголовок Истории о рыбах и так далее. В других ячейках будут находиться прозрачные изображения GIF, необходимые для контроля числа вертикальных и горизонтальных отступов между секциями. В такой разметке участвуют десятки ячеек, связанные сложной взаимозависимостью. Например, если менеджер по контенту сайта напишет слишком длинное введение, то крупное изображение рыбы может сместиться вниз, что нарушит состояние правой колонки. Кроме того, на таком сайте существенно повышается трафик - не из-за того, что он содержит изображения и графику, а из-за его сложной табличной структуры со всеми связанными тегами и атрибутами.

Смешанная разметка и компактный к о д - за и против

205

Рис. 7.5. Сайт The Marine Center (www.themarinecenter.com), на котором можно найти редкие виды рыб и кораллов, содержит смешанную разметку

Несмотря на то что Marine Center использует смешанную разметку, его дизайнерам удалось избежать большинства широко распространенных в этом случае ошибок, так как они свели использование таблиц к абсолютному минимуму. Основу таблицы образуют две колонки. Элементы расположены в этих столбцах в порядке появления, а нюансы отступов контролируются с помощью CSS. Пока же важно запомнить, что табличные элементы следует использовать как можно меньше. Когда вы начнете комбинировать сведенную к минимуму табличную разметку и CSS, вы обнаружите, что некоторые приемы, которые вы ранее считали неотъемлемыми от дизайна, вовсе не являются таковыми.

206

Глава 1» Струшгуpa ш метаструктурз в строгой и смешанной разметке

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

Карты изображений На заре возникновения коммерческого Web-дизайна для создания привлекательных панелей навигации вроде показанных на рис. 7.3-7.5 использовались так называемые карты изображений наподобие мозаики. Ранние мозаики схемы изображений состояли из пяти частей: • созданный в Photoshop (или другом графической редакторе) файл, представляющий собой натуральное изображение графического интерфейса пользователя, сохраненного в формате GIF или JPEG; • файл-схема, содержавший координаты каждого активного района изображения вместе с URL, на который они (координаты) ссылались; • программа CGI, обычно написанная на PERL n установленная в специальный каталог на сервере, задача которой была преобразовывать нажатия мыши пользователя в URL, указанные в файле-схеме; • к элементу изображения в исходном коде страницы добавлялся атрибут «ISMAP»; • ссылка, указывающая адрес программы CGI. HTML-код в таком случае выглядел примерно так: <А HREF="/cgi-bin/imagemap/image.map"><IMG SRC= 11 /images/image ..gif" ISMAPx/A> Это была известная в середине девяностых серверная карта изображения, названная так потому, что скрипт CGI на сервере выполнял работу по преобразованию щелчков мыши пользователя в URL. Дизайнеру, конечно, тоже приходилось немало потрудиться. Такой способ создания дизайна был не самым легким, но единственно возможным для достижения желаемых графических результатов. Вскоре серверные схемы изображений уступили место клиентским, названным так потому, что обработка щелчков мыши выполнялась непосредственно в браузере пользователя. Такой подход не требовал отдельного файла-схемы, вместо этого координаты изображений приводились прямо в HTML-коде, который мог выглядеть примерно так:

207

Преобразование на клиентской стороне было более простым, и поэтому оно, естественно, заменило серверную схему. Разве это не прогресс?

Карта изображений и ее недостатки Разработчики, которые использовали такой подход для создания навигации и хотели уведомлять своих посетителей об их местонахождении на сайте (см. рис. 7.3-7.4), вынуждены были создавать отдельное изображение панели навигации для каждой страницы. А несчастным посетителям, использующим модем, не оставалось ничего, кроме как загружать новое изображение вместе с каждой страницей. Если дизайнер был достаточно искушенным, он также мог изменить и файл-схему для каждой страницы, чтобы пункт меню, относящийся к текущей странице, был недоступен для нажатия. Для загрузки таких сайтов требовалось передавать немало трафика, а так как модемная скорость соединения в 1994-96 годах была не самая высокая, большинство пользователей были не очень довольны таким положением дел. Движение в поддержку повышения удобства использования сайтов в связи с этим объявило, что использование изображений в целом является довольно неудачной привычкой. Сегодня почти никто не использует такой способ для создания меню навигации. И тем не менее закаленные в те годы специалисты по юзабилити сайтов по-прежнему с недовольством относятся к изображениям и графике.

Нет доступности, нет структуры Графические схемы повышали привлекательность сайтов, однако они работали только в графических браузерах с включенной опцией отображения рисунков. Они требовали от пользователя определенных физических возможностей - перемещать мышь и видеть изображения. Доступность таких сайтов можно было несколько повысить с помощью атрибута a l t , однако это не получило широкого распространения. . ' Что более важно, такой подход не обеспечивал структурного смысла. Это были простые изображения, по которым вы могли щелкнуть мышью при наличии определенного оборудования. Таким образом, прецедент для неструктурного HTML-кода был создан.

208

Глава 1* Структура и метаструктура в строгой ш смешанной разметке

Фигурная нарезка Главным недостатком графических схем была невозможность экономии трафика за счет кэширования компонентов изображения. Вскоре дизайнеры стали нарезать изображения в Photoshop и сохранять его по кусочкам в формате GIF или JPEG, а для расположения фрагментов использовать таблицы HTML. Такой способ также был далек от структурного подхода, однако он позволял несколько снизить трафик, сохраняя фрагменты изображения в кэше браузера пользователя и загружая их оттуда при необходимости. Также такие страницы можно было сделать более доступными с помощью атрибута a l t : <а href="/events/"> <img src="/images/events.gif"

alt="События">

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

Нарезка устарела Раньше в Photoshop мы создавали изображение, вручную разрезали его, вставляли каждый фрагмент в новый файл. Затем с помощью дополнительных модулей сохраняли их в формате GIF. После этого вручную создавали HTML-таблицы и молились, чтобы наши сделанные вручную кусочки слились воедино незаметно для пользователя. Затем произошли некоторые изменения. Netscape .расширила возможности изобретенной ранее технологии JavaScript, и в 1996 году появилась возможность изменять изображения при наведении на него указателя мыши. Многие из нас учили JavaScript только для того, чтобы использовать данный эффект в своем проекте, некоторые копировали код с популярных сайтов вроде Project Cool. А многие делали и то и другое. Тем временем Adobe старалась остаться на рынке Web-дизайна, выпустив продукт ImageReady, изначально продававшийся отдельно, а теперь интегрированный в Photoshop. С помощью ImageReady можно было автоматически нарезать изображение на фрагменты. Программа даже умела самостоятельно создавать HTML-код для таблицы, а более поздние версии генерировали и JavaScript-код для эффектов наведения указателя мыши на изображение. Такие же возможности предлагает и приложение Fireworks от Macromedia. Вскоре Macromedia и Adobe выпустили на рынок приложения для визуального

Парад устаревших приемов

209

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

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

Излишнее многословие При попытке понизить трафик, увеличить доступность и улучшить взаимодействие с поисковыми системами (не воспринимающими изображения) в середине девяностых некоторые дизайнеры перестали использовать GIF-текст и стали имитировать нарезанную разметку путем написания собственных навигационных меню средствами HTML, вставляя их в табличные разметки. Тогда браузеры не поддерживали CSS, в отличие от запатентованных «расширений» HTML. Таким образом, можно было натолкнуться на подобный «замусоренный» код, требующий трафика не меньше, чем изображения, которые он призван был заменить: <!—Внешняя таблица. Она создает эффект черной рамки—> <TABLE WIDTH=80% BORDER=0 CELLSPACING=1 CELLPADDING=O> <TR> <TD WIDTH=100% VALIGN=TOP BGCOLOR="#000000 ">

210

Тштшт!» Структуpa и шетаструктура в строгой и с

разметке

<!—Начинается настоящая навигационная таблица—> <TABLE WIDTH=100% HEIGHT=100% BORDER=0 CELLSPACINGS CELLPADDING=O> <TR> <TD WIDTH=2 5% HEIGHT=50 VALIGN=TOP BGCOLOR=#FF9900"> <F0NT S I Z E = 2 x B R x B R x F 0 N T FACE= "GENEVA, ARIAL, HELVETICA"><B> <A HREF="iteml .html">IIyHKT MeHrol</Ax/B></FONT><BR><BR></FONTx/TD> <TD WIDTH=25% HEIGHT=50 VALIGN=TOP BGCOLOR="#FF9900 " x F O N T S I Z E = 2 x B R x F 0 N T FACE= "GENEVA, ARIAL, HELVETICA" ><B> Ж <A HREF="item2 . h t m l " > П у н к т MeHro2</Ax/B></F0NT><BRxBRx/F0NTx/TD> <TD WIDTH=25% "HEIGHT=50 VALIGN=TOP. BGCOLOR="#FF9900 " x F O N T S I Z E = 2 x B R x F 0 N T -FACE= "GENEVA, ARIAL, HELVETICA" ><B> <A HREF="item3 . h t m l " >Пункт MeHra3</Ax/B></F0NT><BRxBR></F0NTx/TD> <TD WIDTH=25% HEIGHT=50 VALTGN=TOP BGCOLOR="#FF9900"xFONT SIZE = 2 x B R x F O N T FACE= " GENEVA, ARIAL , HELVETICA" ><B> <A HREF="item4 .html">IlyHKT M e H r o 4 < / A x / B x / F 0 N T x B R x B R x / F 0 N T x / T D > </TR> </TABLE> <!—Конец таблицы навигации—> </TD> </TR> </TABLE> <!—Конец внешней таблицы, создающей эффект—>

Несмотря на полную нецелесообразность подобного кода, такие приемы до сих пор используются на многих сайтах, включая крупные коммерческие проекты. Многие сайты усугубляют свое положение тем, что хранят тонны «замуложив дого В неструктурной, bgcolor. соренного» чае ные ниться с потоком В 1997 Подобные Вместо Сети даже перспективами элемента, году, титанические в при кэше ссылок «мусора», когда появился запутанным редизайне сайты браузера излишне что MS на нового создавало могут который усилия, IE единый 3сайта, пользователей, оформлением многословной предложил выбраться стандарта плохой ихлынет файл новый, не им меньше придется сдизайнеры частичную из при таблицами логичный кода точки мы эпохи CSS загрузке трафика, вставляли всделать зрения, своих каменного поддержку подошли структурный стилей, контента это базах чем так стили рано кполюбившейся пресловутые CSS который данных. периода, нему отдельно из код или 1,сбазы заинтриговантой не поздно. Вможет лишь справится же данных. этом для font самой, нам. прикажхраслуи

Парад устаревших приемов

211

В попытке поддержать «CSS-несовместимые браузеры» мы вдобавок ко всему прочему вставляли и теги шрифта, еще более «утяжеляя» наши страницы. И, естественно, мы не думали о структуре документа. Настоящая сила CSS - отделять структуру от внешнего вида - еще не была доступна в браузерах, и, что более важно, такая мысль не посетила ни одного ведущего дизайнера. Дизайнеры были не готовы идти навстречу CSS, потому что сама технология была не готова к встрече с ними. К упомянутым выше ошибкам класситсов и дивитсов можно добавить еще один прием, более серьезный, чем они, так как указание стилей CSS в самом документе полностью противоречит сущности технологии. Ниже приведен фрагмент CSS/XHTML-кода, стиль которого точно такой же, какой был в 1997 году. Мы хотим, чтобы вы просмотрели его и постарались избегать подобных ошибок в своей практике.

Вечеринка в духе 1 9 9 7 года Приведенный ниже код является прекрасным образцом плохого CSS (в сочетании с плохим кодом), повсеместно распространенного в 1997 году. Такой же код мог сгенерировать и визуальный Web-редактор: <font color="#FFFFFF">|</font> &nbsp; &nbsp; <a style="color:#FFFFFF;text-decoration:none;" href= "/isapi/gosearch.asp?target=/us/default.asp" target="_top" onmouseover="this.style.color='#FFCC00';" onmouseout="this.style.color='#FFFFFF';">Search</a>&nbsp;

Это может показаться невероятным, но этот кусок кода взят не из архивов 1997 года, не является фрагментом студенческой работы новичка или исходным кодом загнивающего сайта мелкой конторы. Он был взят именно в таком виде, в каком вы его видите, с Web-сайта компании Microsoft (рис. 7.6) 7 января 2003 года. Учитывая то, что избыточность вредна не только в коде, но и в книгах, мы не станем объяснять, что не так с этим кодом. Если вы сами еще не поняли, то кто-то из нас схалтурил, делая свою работу. Компания Microsoft является участником W3C, внесла ключевой вклад в создание CSS и XHTML и, хотя вроде бы преодолела пристрастие к корявому HTML- и CSS-коду, производит браузеры, подобные тому, что использован на сайте компании. Остается только почесать голову и удивляться странному возврату компании к середине девяностых.

212

Глава 7, Структура и метаструктура в строгой и смешанной разметке

Рис. 7.6. Куда мы отправимся сегодня? Обратно в 1997 год (www.microsoft.com)

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

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

Глава 8. XHTML В примерах: смешанная разметка

та глава и две последующие объединены общим смыслом. В данной главе я предлагаю закатать рукава и применить на практике все обретенные нами знания о XHTML. Мы создадим код, который будет частично структурированным, частично переходным и полностью совместимым со стандартами. В главе 9 мы рассмотрим основы CSS, а в главе 10 мы,продолжим изучение CSS и завершим создание нашего сайта, учась на практике. Такой подход к обучению некоторые могут сравнить с обучением плаванию путем погружения в холодную воду, однако нам больше нравится думать о нем как об изучении французского языка благодаря поездке в Париж. После завершения нашего проекта мы рассмотрим некоторые приемы для повышения его доступности.

Преимущества переходного подхода В данной главе мы приступим к созданию смешанной, переходной разметки, используя для этого традиционные таблицы и структурный код, а также некоторые средства повышения доступности. Используемые в проекте приемы описаны в главах 8-10 и идеально подходят для библиотек и других общественных организаций, а также для небольших компаний и любых других учреждений, имеющих следующие задачи: • управление крупным объемом данных при ограниченных финансовых возможностях; • поддержка разнообразных браузеров и устройств; • снижение трафика; • переход к Web-стандартам с надежными, эффективными и простыми в использовании средствами публикации.

214

Глава В. XHYIVIL в призерам: смешанна» разметка

Таблицы стилей вместо JavaScript К концу главы 10 мы создадим совместимый со стандартами шаблон для сайта i3Forum (рис. 8.1). Готовый шаблон можно найти на сайте h t t p : / / i 3 . happycog.com. Готовый сайт, созданный на базе этого шаблона, можно посмотреть на сайте http://i3forum.com. В этой главе мы поработаем над кодом. В главе 10 мы добавим CSS для управления цветом, размером и расположением элементов на странице. (В главе 9 мы остановимся на изучении основ CSS.) Помимо прочего, с помощью CSS мы создадим эффекты, возникающие при наведении указателя мыши на элемент и обычно создаваемые посредством JavaScript или изображений. В использовании JavaScript или изображений нет ничего предосудительного, однако, используя CSS и XHTML, мы сэкономим трафик и сделаем сайт более

Основной подход: овзир

215

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

Основной подход: обзор Сайт i3Forum выглядит просто, четко и без лишних деталей. Такой же прямолинейной является и его XHTML-разметка. Она состоит из двух таблиц, выровненных по центру, внешний вид которых формирует CSS. Первая таблица представляет собой навигационное меню, во второй находится контент (рис. 8.2). XHTML-код для таблиц будет приведен ниже, однако у вас, возможно, уже появились вопросы. Обычно для такой разметки используется одна таблица, а для управлениями столбцами и строками применяются атрибуты rowspan и

216

Глава 8. XHTML в примерах: смешанная разметка

c o l span. Если бы мы создавали подобную страницу в Adobe ImageReady, она также была бы сгенерирована с помощью одной таблицы. Так почему же мы используем две?

Раздельные таблицы: CSS и доступность Если вы пропустили обсуждение div, id и других помощников в главе 7, вас могут заинтересовать следующие сведения. Благодаря разбиению нашей разметки на две таблицы, мы сможем использовать атрибут id для достижения следующих целей: • для рационализации кода CSS, который мы создадим в главе 10; • для повышения доступности; • для структурной разметки каждой таблицы, благодаря чему в будущем будет легче разобраться в этом коде и заменить таблицы XHTML на CSS-разметку.

Элемент summary Помимо этого, используя две таблицы, мы можем добавить к каждой из них атрибут summary: <table id="nav11 suimary="Навигационное меню"> <table id="content" summary="Основной контент"> Этот атрибут невидим в обычных браузерах вроде IE или Netscape. Однако программы для чтения информации с экрана, используемые пользователями с ослабленным зрением, распознают этот атрибут и озвучат его значение. В нашем случае они прочитают «Навигационное меню» и «Основной контент». Хорошие программы для чтения информации с экрана позволяют пользователям пропустить часть страницы, если она им не интересна. Поэтому, использование атрибута summary значительно повышает доступность сайта, так как позволяет пользователям, не заметившим ссылку Пропустить навигацию, сделать это с помощью данного атрибута.

Структура страницы и id Мы присвоили атрибут идентификатора - id - каждой таблице согласно ее назначению - навигация или контент. Таким образом, позднее мы сможем создать правила CSS для всей таблицы в целом, что позволит избежать ненужного использования элементов c l a s s и div.

Основной подход: обзор

217

Благодаря этому мы также создали ссылку Пропустить навигацию в начале кода.

Пропустить навигацию: как и почему Как следует из ее названия, ссылка Пропустить навигацию позволяет пользователю пропустить меню навигации и перейти непосредственно к таблице с основной информацией с помощью известного еще из HTML якоря. Таким якорем является атрибут id со значением " c o n t e n t " : H

<div c l a s s = h i d e " x a href="#content" title="Пропустить навигацию" accesskey="2">nponycTHTb Использование этой опции не является первейшей необходимостью для пользователей с нормальным зрением, которые могут просто сфокусироваться на интересующей их части страницы, игнорируя другие, например меню навигации. Пользователи с ослабленным зрением, использующие программы для чтения с экрана, просматривают Web-страницы в линейном, последовательном режиме, по одной ссылке за раз. Им нет необходимости прослушивать весь список ссылок снова и снова при каждой загрузке любой страницы вашего сайта. Поэтому, с помощью опции Пропустить навигацию они могут избежать этой неприятности. Ссылка Пропустить навигацию также позволяет пользователям сотовых телефонов и карманных устройств, не поддерживающих CSS, избежать необходимости просматривать при открытии каждой страницы десяток ссылок снова и снова.

Пропустить навигацию и атрибут accesskey С помощью ссылки Пропустить навигацию пользователи текстовых или не поддерживающих CSS браузеров имеют возможность перейти непосредственно к контенту во второй таблице, id которой имеет значение " c o n t e n t " : <table

id="content">

В текстовых или несовместимых с CSS браузерах эта ссылка будет доступна вверху страницы (рис. 8.3-8.4). Вам потребуется создать правило GSS чтобы скрывать ссылку Пропустить навигацию в браузерах, поддерживающих CSS. Для самых нетерпеливых мы приводим его здесь: .hide{ display: none;

218

Глава S« XHTML в призерах: сшешаинаи разметка

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

Благодаря этому правилу пользователи браузеров с поддержкой CSS не увидят ссылку Пропустить навигацию, большинству из них эта ссылка и не нужна, так как им не требуются предлагаемые ею возможности. Программы для чтения информации с экрана прочтут эту ссылку, уведомив пользователя, что он может пропустить ненужного повторения всей таблицы меню при открытии каждой новой страницы. (К сожалению, некоторые программы для чтения информации с экрана все равно выполняют правила CSS, несмотря на то что их пользователи не могут видеть соответствующий эффект.) Естественно, в каждом правиле есть свои исключения. Некоторые пользователи с ограниченными физическими возможностями, использующие совместимые с CSS браузеры, также могут пожелать пропустить навигацию. Хотя, в отличие от слабовидящих пользователей, они в состоянии просматривать всю страницу целиком, но для перемещения они все же используют клавиатуру или другие специальные вспомогательные устройства. В таком случае их навигация по сайту с помощью меню может быть затруднена. Как мы можем сделать так, чтобы эти пользователи тоже могли пропустить навигацию, если они не видят ссылку Пропустить навигацию? Это можно сделать с помощью атрибута accesskey, работающего даже когда ссылка Пропустить навигацию не видна, хотя этот способ и не является безупречным.

219

220

Глава 8. XHTIVIL в призерах: смешанная разметка

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

accesskey и iCab На момент написания книги лишь iCab (рис. 8.5) для Macintosh отображал присвоенные accesskey клавиши на странице. Однако большинство пользователей Web - это не пользователи Macintosh, и не все пользователи Macintosh используют iCab. Кроме того, iCab не показывает клавиши a c c e s s k e y , когда ссылка Пропустить навигацию скрыта благодаря CSS. На момент выхода этой книги из печати iCab по-прежнему не поддерживал полностью стандарт CSS 1, принятый еще в 1996 году. Иными словами, несмотря на желание iCab поддерживать HTML4, он не сможет решить мировой проблемы с accesskey.

Д в е утопические перспективы для accesskey Очевидно, что большинство пользователей, использующих accesskey, не смогут воспользоваться этой опцией, так как не будут знать, какие клавиши следует нажимать. Поэтому включать a c c e s s k e y в свой код рекомендуется лишь идеалистам. Если бы W3C предлагал единый набор клавиш для подобных функций и дизайнеры и разработчики стали бы придерживаться рекомендаций W3C, то пользователи бы всегда знали, какую клавишу для чего нажимать. Это было бы очень неплохо. Либо производители браузеров могли бы включить в свои продукты визуальное отображение имеющихся accesskey на странице и позволили бы пользователю включать и отключать эту опцию. Ведь если пользователи IE могут включать и выключать опцию игнорирования размера шрифтов на Web-сайтах, почему бы не ввести опцию Всегда показывать значения accesskey? Остается признать, что обе эти идеи выглядят довольно утопично. Тем не менее мы продолжаем использовать accesskey. Некоторые пользователи просматривают исходный код, чтобы выяснить, какие значения имеют accesskey на странице, и затем используют их для навигации. Мы же надеемся, что скоро использование этого атрибута пользователями упростится тем или иным способом.

Основной подход: обзор

221

Дополнительные атрибуты id В дополнение к основным именам атрибута id (nav и c o n t e n t ) мы также присвоили уникальные идентификаторы каждой ячейке таблицы навигации. Вот пример двух ячеек: <td width^'lOO" height="25" id«"eventsи><а href =" events. html" >Events</ax/td>

222 Глава 8. XHTIVIL в примерах: смешанная размепса <td width="100H height="25" id="schedule"><a href ="schedule .html ">Schedule</ax/td>

Мы также присвоим идентификаторы двум основным разделам таблицы контента, а именно боковой ( i d = " s i d e b a r ")• и основной области (id= " p r i m a r y c o n t e n t " ) . Ниже приведен код таблицы контента: <table id="content"> <tr> <td width="2 00" id="sidebar"> Здесь будет контент боковой области.

</td>

<td width="400" id="primarycontent"> Здесь располагается содержимое основной области. </td>

Второй ряд в таблице навигации также помечен атрибутами id: <tr id="nav2"> А третий ряд навигационных «кнопок» имеет следующее значение атрибута id: <tr id="nav3">

Слишком много - это сколько?

Последние идентификаторы (nav2 и nav3) не обязательно использовать в данной разметке, однако они могут оказаться очень удобными при последующем редизайне. Следует применять их или нет? С одной стороны, их использование добавляет несколько лишних байт в наш XHTML-код и с равным успехом мы можем отказаться отОн них. ровать и PHP, зуются nav2 файле, На от nav3 <body> Если этой JSP, и нецелесообразно. этот nav3 подключаемом ивикод ColdFusion конечном следующих до файл для меню </body>. облегчения и изменить вручную или результате нескольких на С ASP), стороне другой же последующего добавляется облик вявляется меню будущем сервера стороны, страницах всего навигации иможно сайта. во (или окончательным редизайна если все выбудет В увидите будет подобные страницы, этом будет находиться вили любой случае находиться наш поиска технологии вариантом лучше вариант использовать момент под ошибок. использовать управлением в отредактиотдельном кода не структуры испольсайта nav2

Первый и последний вариант кода

Первый и последниг

Аткода

223

документа. Все последующие настройки и изменения облика сайта производились путем использования CSS. Вы наглядно увидите преимущества освобождения кода сайта от разметки оформления и перевода ответственности за внешний облик страницы на CSS. Чтобы сэкономить место в книге, вместо текста шаблона мы использовали некий условный текст. Обратите внимание также и на то, что в приведенном коде мы использовали относительные ссылки на изображения ( img src=" images /logo . g i f " ) , а не абсолютные. В настоящем коде используются абсолютные ссылки. (Абсолютные ссылки считаются более надежными, так как они не теряются при изменении расположения файла. Также абсолютные ссылки помогают избежать ошибок CSS в некоторых старых браузерах, путающих относительные ссылки в таблицах стилей.) Технически приведенный здесь код отличается от реального относительными ссылками на файлы. Скорее всего, вас это не очень заботит, однако мы отметили сей факт, так как всегда найдется один читатель, обратившийся к исходному коду страницы, чтобы указать на нашу некомпетентность. Возможно, вам будет удобнее просмотреть код в электронном виде. Напоминаем, что он доступен по адресу http://i3forum.com.

Код навигации - первая таблица Ниже приведен код таблицы навигации. Хотим отметить, что он содержит фрагмент, который сторонники стандартов посчитают ошибкой. Попробуйте найти его: <body

bgcolor="#ffffff">

<div class="hide"xa href="#content" title="Skip navigation." accesskey="2">Skip navigation</a>.</div> <table id="nav" summary="Navigation elements" width="'600" border="011 align-"center" cellpadding="O" cellspacing="O "> <tr> <td rowspan="3" id="home" width="400"xa href="/" title="i3Forum home page."ximg src= "image/logo.gif" widths"400" height="75" border="0" a l t = " i3Foru,m home" /> </ax/td> <td width="100".height="25" id="events"><a href="events.html">Events</a></td> <td width="100" height="25" id="schedule"><a href ="schedule .html ">Schedule</ax/td> </tr> <tr id-"nav2"> •

<td width="100" height="25" id="about"><a href="about.html">About</

224

Гиава 8. XHYIVtL в примерах: смешанная разметка

ax/td> <td width="100lf height = "25" id= "details"><a . href="details .html">Details</ax/td> </tr> <tr id=Ilnav3ll> <td width="100" height="25" id="contact"><a href = • contact. html • >Contact</ax/td> <td width="100" height = "25" id="guestbios"xa href ="guestbios .html">Guest Bios</ax/td> </tr> </table>

Оформление, семантика, чистота стандартов и ошибка Вы заметили серьезную ошибку в нашем XHTML-коде? Использование устаревшего атрибута b g c o l o r для того, чтобы указать не поддерживающим CSS браузерам белый цвет фона: <body bgcolor=»#ffffff»> Ну что же, использование такого кода может привести к нашему изгнанию из Академии чистых стандартов. В конце концов, указать цвет фона можно и посредством CSS, и W3C рекомендует нам именно этот способ. С точки зрения многих поклонников стандартов, использование этого атрибута является большим «грехом».

Переходная книга в переходное время

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

Первый и последний вариант нэда

225

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

Второй шанс для старых браузеров Почему же мы использовали bgcolor, несмотря на все его недостатки? Дело в том, что сайт со смешанной разметкой не требует определенной версии браузера пользователя. В старом, не поддерживающем CSS браузере, в случае если фоновый цвет будет отличаться от белого, логотип сайта, представляющий собой прозрачное изображение GIF не впишется в общий дизайн. Разве хоть один клиент захочет, чтобы логотип его компании выглядел скверно хоть в одном браузере? Например, один популярный старый браузер, не поддерживающий CSS, по умолчанию устанавливает серый цвет для фона. Наш логотип оптимизирован под белый цвет. Если мы не зададим фоновый цвет через XHTML, в таком браузере наш логотип будет выглядеть плохо. В реальности вам может быть все равно, как будет выглядеть ваш сайт в браузерах версии 2.0 или 3.0. Вам (вашему боссу или клиенту) даже может быть наплевать на то, как он будет выглядеть в версии 4.0. В нашем примере мы не пытаемся создать сайт, одинаково отображаемый во всех версиях браузеров. В не поддерживающих CSS браузерах наш сайт будет выглядеть не лучше, чем на рис. 8.3. И это нормально. Мы использовали таблицы и атрибут b g c o l o r в этом примере, чтобы показать вам, что это допустимо в XHTML 1.0 Transitional. Мы также хотели показать вам, что все попытки использовать стандарты в ваших проектах, даже с некоторыми компромиссами, стоят того, чтобы их осуществить.

Добавим контент - вторая таблица Код следующей таблицы c o n t e n t следует сразу за первой таблицей и понятен всем, кто когда-либо работал с HTML или XHTML. Следует отметить две вещи - компактность и применение атрибута id: <table id="content" summary="Main content." Width="600" border="0" align="center" cellpadding="O" cellspacing="0"> <tr> <td width="200" id="sidebar" valign="top"> <img src="images/astro.jpg" width="'200" height="200" border="0" alt=lli3Forum. Breeding leadership." Title="i3Forum. Breeding leadership." />

226

Глава 8. XHTML в примерах: смешанная разшетма

РЛЯ1В •• Основы CSS

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

Обзор CSS W3C определяет CSS как «простой механизм для добавления стиля (например, шрифтов, цветов, пробелов) в Web-документы» (www.w3.org/Style/CSS). Отметим также следующие моменты: • CSS является стандартным языком разметки для Web-документов. С его помощью можно управлять цветами, типографическими параметрами, размером и местоположением элементов и изображений на странице; • несмотря на мощь и точность, создавать правила CSS можно легко и вручную, в чем вы убедитесь, прочитав эту главу; • CSS не повышает трафик - один файл CSS может использоваться всеми страницами сайта, что поможет вам сэкономить; • CSS задумывался своими создателями (W3C) для замены табличной разметки HTML, фреймов и других приемов оформления документа, но, как мы увидим, он может быть высокоэффективен и при сочетании с ними в переходных, смешанных разметках; • чистая CSS-разметка в сочетании со структурным XHTML-кодом может помочь дизайнерам отделить внешний вид от структуры, повысив доступность сайта и легкость его обслуживания.

228

Глава 9. Основы CSS

Преимущества CSS Как говорится в пословице, повторение - мать учения. Поэтому простите нас за то, что мы еще раз отметим: CSS, как и другие Web-стандарты, был создан не для каких-то абстрактных целей в неопределенном будущем. При правильном использовании уже сейчас CSS может предоставить следующие (и не только эти) преимущества: • экономию трафика, снижение времени загрузки страницы; • снижение нагрузки на сервер; • сокращение времени на разработку и дизайн. Создать страницу для нашего сайта (главы 8-10) мы смогли за пару часов, из которых некоторое время мы потратили на написание самих глав; • сокращение времени на обновление и обслуживание: - специалистам по контенту больше не придется думать о сложных таблицах, тегах шрифта и других устаревших компонентах разметки, которые могут нарушиться при обновлении сайта; - дизайнерам, разработчикам и агентствам больше не придется волноваться о том, что клиент испортит сайт. - глобальные изменения можно осуществить за несколько минут. Слишком темный текст? Измените пару правил в файле CSS, и весь сайт тут же отобразит изменения; • повышение совместимости с разными платформами благодаря использованию Web-стандартов; • повышение доступности за счет удаления некоторых, многих или всех элементов оформления из кода. Книги о CSS. Карманный справочник по CSS Эрика Майера ("CSS Pocket Reference", Eric Meyer: O'Reilly & Associates, Inc., 2001). Книга, как следует из названия, помещается в кармане, но пусть ее размер не смущает вас. Книга является самым четким и полным руководством по CSS 1. Если вам нравится разбираться в чем-то на примерах, вам может понравиться книга CSS от Эрика Майера ("Eric Meyer on CSS", Eric Meyer: New Riders, 2002). Полезная книга, содержащая много примеров. Мы рекомендуем вам ознакомиться с обеими этими книгами. В одной из них объясняется грамматика CSS, а вторая показывает, как творчески использовать эту технологию.

Анатомия стилей

229

Прозрачный фон и Netscape 4. Внимание: Netscape 4.x зачастую интерпретирует t r a n s p a r e n t как черный. Если вы используете вместо этого b a c k g r o u n d : i n h e r i t ; , цвет получается зеленым. Это происходит оттого, что Netscape 4.x обрабатывает значения как шестнадцатеричные, даже когда они явно не подходят для этого. (IE/Windows грешил этим же до версии 4.0, но в дальнейшем эта ошибка была устранена.) Суть в следующем: если пользователи Netscape 4 составляют значительное число вашей аудитории, вы можете полностью отказаться от объявления цвета фона в ваших страницах. Делать это стоит только в том случае, если вы абсолютно уверены.

Точка с запятой И вот опять появились исключение и непоследовательность. Согласно правилам CSS, после последнего описания ставить точку с запятой не обязательно, и некоторые дизайнеры так и делают. Однако более опытные дизайнеры все равно ставят точку с запятой даже после последнего описания. Отчасти они делают это для целостности кода, но в основном для того, чтобы избежать проблем при последующем редактировании. Если каждое описание оканчивается точкой с запятой, вам не придется беспокоиться об этом при удалении или перемещении какого-либо описания.

Анатом

P ( font-size:

231

small;

}

Пробелы или их отсутствие не влияют на отображение CSS в браузерах, и, в отличие от XHTML, CSS не чувствителен к регистру. Здесь есть исключение: уникальные имена c l a s s и id чувствительны к регистру, когда они связаны с документом HTML. В этом случае my Text и ту t e x t - это разные вещи. Сам по себе CSS не делает разницы между регистрами, но в контексте использующего его документа это может быть важно. Дополнительные сведения по этому вопросу можно найти по адресу http://devedge.netscape.com/viewsource/2001/ css-class-id.

Альтернативные и общие значения Дизайнер может указать шрифт для всего сайта следующим образом: body

{

font-family: "Lucida Grande", Verdana, Lucida, Arial, sansserif; }

Обратите внимание, что шрифты, названия которых состоят из нескольких слов, следует заключать в прямые кавычки и запятую нужно выносить за кавычки, а не помещать внутри них. Шрифты будут использоваться в порядке перечисления. Если на компьютере пользователя установлен шрифт Lucida Grande, текст будет отображаться этим шрифтом. Если нет - будет использован шрифт Verdana. Если Verdana не

232

Глава 9. Основы CSS

установлен - используется Lucida и так далее. Почему шрифты расположены в таком порядке?

Порядок шрифтов для разных платформ Порядок перечисления шрифтов имеет определенное значение. Шрифт Lucida Grande используется в Mac OS X. Verdana - во всех современных системах семейства Windows, в Mac OS X и старых операционных системах Мае. Если в перечислении шрифтов вначале указать Verdana, компьютер с OS X отобразит сайт шрифтом Verdana, а не Lucida Grande. Указав первые два шрифта, Lucida Grande и Verdana, дизайнер охватил практически всех пользователей Windows и Macintosh. Lucida указан для пользователей UNIX, a Arial - для пользователей старых версий Windows. Если ни один из этих шрифтов не доступен, будет использован любой шрифт семейства sansserif. Если и таких шрифтов не окажется, браузер будет использовать шрифт по умолчанию.

Далеко не точная наука Мы не делаем вид, что Lucida, Verdana, Arial и Helvetica совершенно одинаковы по красоте, элегантности или размерам их отображения на экране. Нашей целью не является создание сайта, абсолютно идентично выглядящего на разных платформах, браузерах, мониторах всех размеров и разрешений, качества и гаммы, так как это было бы совершенно невыполнимо. Мы лишь стараемся обеспечить, чтобы все посетители сайта смогли работать с ним исходя из определенных условий и чтобы сайт для них выглядел более или менее оди^ наково.

Сгруппированные селекторы Когда одинаковые свойства присвоены нескольким элементам, можно применить одно описание к нескольким селекторам, сгруппировав их в списке, разделенном запятой: р, td, u l , ol, l i , dl, dt, dd font-size: small; }

{

Эта опция очень полезна для старых браузеров, не поддерживающих наследование в CSS.

Анатомия стилей

233

Наследование и его недостатки Согласно CSS, свойства дочерних элементов наследуются от родительских. Но не всегда происходит именно так. Например, рассмотрим следующее правило: body { font-family:

Verdana,

sans-serif;

}

Дочитав до главы 9 этой книги, вы уже знаете, что означает это правило. Элемент body будет использовать шрифт Verdana, если он установлен в системе пользователя. В ином случае будет использован шрифт семейства sans-serif.

Все детки Согласно принципам наследования в CSS, то, что относится к элементам более высокого уровня (в данном случае body), справедливо и для дочерних элементов (например, р, t d , u l , o l , l i , d l , d t , dd). Без всяких дополнительных правил все дочерние элементы тега body должны отображаться шрифтом Verdana или sans-serif, так же как и дочерние элементы этих дочерних элементов, и так далее. Именно так и обстоят дела в большинстве современных браузеров. Однако это не относится к браузерам, созданным в разгар пресловутой войны, когда поддержка стандартов не являлась приоритетом. В качестве примера можно привести Netscape 4, игнорирующие правило наследования и все правила, относящиеся к элементу body. (В IE/Windows наблюдалась такая же проблема вплоть до версии IE 6 - браузер игнорировал стили шрифтов в таблицах.)

«Не о б и ж а й т е Netscape 4» К счастью, можно обойти эту неприятность, используя принцип, который мы называем «Не обижайте Netscape 4»: body {

font-family: Verdana, sans-serif; } p, td, ul, ol, ul, li, dl, dtl dd { font-family: Verdana, sans-serif; }

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

234

Тташа 9. Основы CSS

шрифт Verdana. Конечно, такой подход несколько повышает трафик, но в некоторых случаях вы все же захотите использовать именно его. Кстати говоря, Netscape 4 является не единственным старым браузером, не понимающим правила наследования. Просто он является единственным, который до сих пор используют некоторые преданные пользователи.

Наследование' А что если вы не хотите, чтобы все элементы вашего сайта наследовали шрифт Verdana или sans-serif? Что если вы хотите, чтобы абзацы текста отображались в Times? Нет проблем. Создайте правило для р (выделено полужирным), и оно будет иметь приоритет над родительским правилом: body { font-family: Verdana, sans-serif; } td, ul, ol, ul, 11, dl, dt, dd{ font-family: Verdana, sans-serif;

font-family: Times, "Times New Roman", serif; }

И вы получите Times в ваших абзацах.

Контекстные (наследуемые) селекторы

Можно избежать класситсов и сохранить код четким и чистым, сделав стиль элемента зависимым от контекста, в котором он появляется. Селекторы, присваивающие стили таким способом, в CSS 1 называются контекстными, так как они присваивают стиль в зависимости от контекста. В CSS 2 такие селекторы называют наследуемыми, но работают они таким же образом. Для того чтобы выделить помеченный тегом <strong> текст курсивом и не отображать его полужирным только при появлении в списке, следует создать такое правило: li strong { font-style: i t a l i c ; font-weight: normal; }

Что делает это правило?

Анатс=

235

и его влияние на код: <р>В этом абзаце полужирным выделено слово <strong>KpacHbin </strong>.</p> <h2 Подзаголовок также красный.</п2> <h2>B этом подзаголовке полужирным выделено словом trong>cnraiH </strong>.</h2>

Вряд ли вы будете использовать контекстные селекторы, чтобы отображать курсивом полужирный текст в списках, однако вы можете использовать его для создания утонченных элементов дизайна, например для добавления к обычным элементам XHTML фонового изображения с отступами, для предотвращения наложения текста на рисунок. Но более вероятно, что вы создадите подобные эффекты с помощью контекстных селекторов id или c l a s s .

Селекторы id и к о н т е к с т н ы е селекторы id В современных разметках селекторы id зачастую используются в контекстных селекторах: #sidebar p { font-style:italic;

236

Глава 9. Основы CSS

Анатомия стиней

237

238

Глава 9. Основы CSS

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

Сочетание селекторов для задания эффектов Классы, идентификаторы и контекстные селекторы можно комбинировать для создания оригинального оформления. Например, на сайте The Marine Center, созданном студией Happy Cog, вместо обычного маркера списка используется маленькое изображение силуэта рыбы (Iister2.gif) - рис. 9.1. Ниже приведено правило CSS, указывающее списку класса i n v e n t o r y отображать изображение рыбы вместо обычной черной точки (и показывать диск в старых браузерах, неспособных отобразить изображение): ul.inventory { l i s t - s t y l e : disc

url(/images/common/lister2.gif)

inside;

Рис. 9.1. Классы, идентификаторы и контекстные селекторы можно комбинировать для создания визуальных эффектов. На сайте The Marine Center (http://marine.happycog.com) вместо обычного маркера списка используется маленькое изображение силуэта рыбы

-•..:••;••;•.•

Л И Й

239

Пользователи IE/Windows и Opera/Windows наблюдают еще один дополнительный (непредусмотренный) эффект: при загрузке страницы вначале в списке отображаются точки, затем превращающиеся в силуэт рыбы. Эффект похож на анимацию Flash или JavaScript, однако он получился совершенно случайно - просто таким образом IE и Opera для Windows загружают и отображают Web-компоненты. В других браузерах пользователь просто видит рыбу. Если вы внимательно следили за нашим повествованием, вы заметили, что изображение рыбы не появится в списке другого класса, если класс применен к другим элементам, отличным от списка. Изображение рыбы также используется в разделе покупок сайта (рис. 9.2) благодаря элементу класса c a r t i e r :

Рис. 9.2. Изображение рыбы также используется в разделе Покупки. Для этого не применяется тег <img>

240

Глава 9. Основы CSS

Вы можете ознакомиться с другими приемами, использованными для создания этого сайта, по адресу http://marine.happycog.com, где сохранены оригинальные шаблоны сайта (рис. 9.3). В следующей главе мы более подробно познакомимся с грамматикой CSS, пока же возникает вопрос: где находятся правила CSS? Они вставляются в XHTML-код или находятся в отдельном файле? Ответ уважаемый читатель найдет в следующих разделах.

Внешний, вложенный пни последовательный стинь

241

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

Внешние таблицы стилей Внешняя таблица стилей (файл CSS) является текстовым документом, существующим отдельно от XHTML-страниц, которыми он управляет. XHTML-страница подключает этот CSS-файл с помощью ссылки, расположенной в начале документа, или с помощью его импорта. Ссылка на таблицу стилей выглядит так: <link rel="Stylesheet" href="/styles/mystylesheet.ess" type="text/ess" media="all" />

Указатель ©import, используемый для импорта таблицы стилей, выглядит так: <style type="text/ess" media="all"> ©import "/styles/mystylesheet.ess" ; </style>

Или так: <style type="text/ess" media="all"> ©import url ("/styles/mystylesheet.ess"); </style>

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

Ссылка и импорт стилей для определения браузера Практически все совместимые с CSS браузеры поддерживают ссылку на CSSфайл, включая старые версии браузеров, поддержка CSS в которых выполнена не идеально. Использование @import работает только в браузерах версии 5.0

242

Глава 9, Основы CSS

и более новых. Таким образом, можно использовать @import, чтобы скрыть таблицы стилей от браузеров версии 4.0. Этот факт необязательно означает, что CSS будет скрыт от всех пользователей старых браузеров, как описано в главах 2 и 4. Наоборот, то, что некоторые браузеры понимают @import, а некоторые - нет, позволяет нам угодить им всем. Каким образом? Так как на сайте можно использовать несколько таблиц стилей, дизайнеры могут создать простой стиль, к которому можно обращаться посредством ссылки, и более изощренный стиль, который будет подключаться через импорт. Таблица стилей, управляющая простыми элементами вроде шрифтов, фона и цветов ссылок, будет отображаться во всех браузерах, даже в тех, которые лишь «притворяются», что «понимают» CSS. В таблицу стилей, используемую через импортирование, можно поместить более сложные правила CSS, которые могут отобразить более новые версии браузеров. Ваш XHTML-код будет выглядеть примерно так: <!DOCTYPE html PUBLIC "-7/W3C//dtd xhtml 1.0 Transitional//EN" "http://www.w3.org/TR/xhtmll/DTD/xhtmll-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>3aronoBOK</title> <link rel="Stylesheet" href="/ess/basic.ess" type= "text/ess" media="all"> <style type="text/ess" media="all"> ©import "/css/sophisto.ess"; </style> <meta http-equiv="Content-Type" content= "text/html; charset=windows-1251" /> </head>

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

Вложенные таблицы стилей Вместо того чтобы использовать внешний файл с правилами CSS, дизайнер может включить таблицы стилей непосредственно в XHTML-код: <!DOCTYPE html PUBLIC "-//W3C//dtd xhtml 1.0 Transitional//EN"

243

</style> <meta http-equiv="Content-type" charset=windows-1251" /> </head>

content="text/html;

В отличие от предыдущего способа, вложенные таблицы стилей не позволяют сэкономить трафик, так как пользователь загружает их каждый раз вместе с новой страницей. Даже если во всех страницах используются одинаковые таблицы стилей, все равно приходится загружать их каждый раз. Возникает вопрос, зачем вообще использовать вложенные таблицы стилей? Вот несколько причин: • если сайт состоит из одной страницы - маловероятно, но возможно; • пользователи сайта живут вне времени и пользуются IE 3. IE 3 стал первым браузером, поддерживающим некоторые элементы CSS, однако не умеющим распознавать и обрабатывать внешние файлы стилей. Если подумать - тоже не слишком вероятная ситуация; • дизайнер использует внешний файл со стилями для всего сайта, но ему необходимо создать отдельный стиль всего для одной страницы. В этом случае использовать вложенные таблицы стилей - отличный вариант. На самом деле это, пожалуй, единственный способ решить подобную задачу. При создании сайта i3Forum мы воспользуемся этим способом и добавим стиль к каждой странице, чтобы выделить элемент меню страницы, на которой находится пользователь; • дизайнер еще находится в процессе создания стиля и хочет немедленно видеть все сделанные изменения. Это является еще одной причиной использовать вложенные таблицы стилей. При разработке страницы или сайта (со смешанной разметкой или чистым CSS) очень удобно включить таблицу стилей в код страницы. После того как вы создадите именно тот внешний вид, который вам нужен, просто скопируйте этот код в отдельный файл и удалите его из кода страницы.

244

Глава 9. Основы CSS

В нашей работе над сайтом i3Forum мы так и делали - таким образом можно наиболее просто и быстро просмотреть изменения стиля. (Измените правило, перезагрузите страницу в браузере и посмотрите на результат.) После того как мы закончили работу над оформлением сайта с помощью CSS, мы удалили стили из раздела <head> страницы и поместили их в отдельный CSS-файл в подкаталоге /ess/ на сервере, после чего разместили ссылку на него на страницах сайта.

Последовательный стиль CSS можно применить к отдельным элементам, используя атрибуты CSS непосредственно на нужных элементах: <hl style="font-family: verdana, a r i a l , <img style="margin-top: 25px;">

sans-serif;">3аголовок</п1>

Говорить о какой-либо экономии трафика в данном случае не приходится. Наоборот, такой метод лишь «утяжеляет» страницу, и по эффективности его можно сравнить с устаревшими тегами <f ont >. Обычно его используют дизайнеры, не разобравшиеся до конца в возможностях CSS. Тем не менее при умелом использовании он может быть очень полезен.

Дизайн по методу «идеальных условий» Раньше, когда мы создавали разметку с элементами оформления в коде, мы проверяли наши страницы в самых старых браузерах из всех имеющихся у нас. Чтобы страница хорошо отображалась в нем, мы создавали многоуровневые вложенные таблицы, использовали неструктурные d i v вместо структурных h i , h2, li и р и делали многое другое, чего не делаем сейчас. После того как мы добивались хорошего вида страницы в старом браузере, мы проверяли ее в новых версиях, где обычно она также выглядела неплохо. Однако этот неплохой внешний вид достигался ужасной ценой - за счет трафика и правил семантики. Многие Webдизайнеры и сейчас работают так же - подгоняя страницу вначале под самый старый браузер, доступный им. Тем не менее такой метод более не эффективен. Вместо этого советуем вам в процессе работы использовать вложенную таблицу стилей и проверять ее действие в новейших версиях браузеров, например Mozilla, Chimera, Netscape 7, IE 6/Windows, IE 5/Mac или Opera 7. В таком случае вы сможете создать доступную, совместимую со стандартами страницу, экономящую трафик. После того как вы останетесь довольны созданной страницей, проверьте ее в других совместимых, но более старых версиях браузеров. Она должна выглядеть

Дизайн но яяетаду «идеальных условий»

245

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

От вложенной к внешней таблице стилей: метод двух таблиц Когда ваш сайт корректно отображается и работает во всех совместимых браузерах, все равно еще рано открывать самый старый браузер. Вместо этого скопируйте правила CSS в новый файл под именем basic.ess, загрузите его в каталог /ess/ сервера, удалите вложенные стили из кода и создайте ссылку на CSS-файл в разделе <head> вашей страницы: <link rel="Stylesheet" href="/ess/basic.ess" type="text/ess" media="all" /> Очистите кэш, перезапустите браузер и снова проверьте страницу, чтобы убедиться, что все правила были перенесены из кода во внешний файл без ошибок.

Тестирование и поддержка страницы в несовместимых браузерах Если все нормально, пора запускать несовместимый браузер, в котором вы хотите добиться корректного отображения вашей страницы. Все же остается маленький шанс на то, что ваша страница будет выглядеть в нем корректно без всяких доработок. В противном случае создайте новый файл под именем sophisto.css и начните перемещать в него те правила из basic.ess, изощренность которых, по вашему мнению, не воспринимается старым браузером. По мере копирования этих правил в sophisto.css удаляйте их из basic.ess. (Естественно, имена CSS-файлов могут быть любые.) Теперь загрузите sophisto.css в каталог /ess/ сервера и поставьте на него ссылку в коде страницы посредством ©import: <style type="text/ess" media="all"> ©import "/css/sophisto.css"; </style> Очистите кэш старого браузера, перезагрузите страницу. Теперь страница может выглядеть приемлемо. Если нет - потребуется перенести еще несколько правил из basic.css в sophisto.css. В конце концов ваш сайт будет выглядеть должным образом в новых совместимых браузерах и приемлемо отображаться в раритетных версиях начала века глобальной Сети.

246

Глава 9, Основы CSS

Например, сайт The Fox Searchlite (www.foxsearchlite.com), созданный Хиллманом Кертисом совместно с Happy Cog, использует два файла стилей для корректной работы в современных браузерах и отображения более простой в смысле дизайна версии в браузерах четвертой версии. В браузерах 4.0 сайт менее изыскан, но полностью доступен и выглядит удовлетворительно.

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

Преимущества двух стилей и разработки для «идеальных условий!» Проверяя наши страницы в новых браузерах, мы избавляем себя от необходимости ограничения нашей фантазии рамками устаревших браузеров. Мы можем создать хорошо выглядящие сайты со смешанной разметкой без необходимости «замусоривания» кода. Благодаря использованию двух таблиц стилей мы можем предложить пользователям старых браузеров максимально привлекательный сайт без необходимости урезать или ограничивать XHTML-код или CSS. Конечно, такой сайт не может похвалиться семантическим кодом, чистой CSS-разметкой, он не является авангардом Web-стандартов и не претендует на звание «единственный способ создания Web-страниц». Тем не менее это хороший метод совместимости со стандартами в переходном варианте. Использование двух стилей не ограничивается смешанной разметкой. Этот способ не менее эффективен и при чистой CSS-разметке, доступной нескольким поколениям браузеров. Цель его использования остается такой же - создание приемлемых вариантов сайта для браузеров различных версий. Теперь мы готовы к использованию CSS для завершения работы над сайтом i3Forum.

ТШШШШ10.CSSвдействии: смешанная разметка

главе 8 мы создали код смешанной разметки для сайта i3Forum, сочетая структурные элементы вроде <hl>, <h2> и <р> с неструктурными компонентами (XHTML-таблицы). Также мы использовали accesskey, элемент Пропустить навигацию и другие средства для повышения доступности сайта в нетрадиционных браузерах. В данной главе мы завершим создание сайта, применив CSS для оформления внешнего вида сайта и повышения его привлекательности без необходимости использования красивого текста в GIF, эффектов JavaScript, прозрачных GIF-изображений для создания отступов и других устаревших приемов. На рис. 10.1 мы видим шаблон первой страницы сайта после создания таблицы стилей. Как и все в дизайне, использование CSS состоит из нескольких этапов. В этой главе мы создадим CSS за два шага. На первом этапе будет выполнено 90% работы, на втором мы устраним ошибки и добавим окончательные штрихи.

Подготовка изображений Несмотря на использование Photoshop, нам не пришлось разрезать изображение на кусочки. На рис. 10.2 приведены шесть изображений, используемых при создании сайта. Три из них необходимы для оформления переднего плана: изображение астронавта, собаки и прозрачное GIF-изображение для логотипа, используемое в верхнем левом углу панели меню. Остальные три изображения используются для фона. Логотип Arrow.gif, являющийся растровой иллюстрацией, будет использован в стиле водяного знака в качестве фона. Изображение Bgpat.gif (рис. 10.3) состоит из одноцветных и прозрачных пикселей, чередующихся в шахматном порядке, - оно будет

248

Глава 10. CSS в действии: смешанна» разметка

использовано для фона в меню. Nopat.gif- изображение белого цвета - будет заменять фон кнопок панели меню, а также его можно использовать для информирования пользователя о его местонахождении с помощью вложенной таблицы стилей, добавленной к каждой странице. Ненужное изображение, часть 1. Строго говоря, одно из шести изображений, а именно Nopat.gif (рис. 10.2.), не является необходимым. Вместо него можно использовать CSS-правило b a c k g r o u n d : w h i t e . Тем не менее мы используем изображение для нашей панели nav, чтобы показать вам, как можно добиться эффекта замены одного изображения другим с помощью CSS.

Установка основных параметров

249

Установка основных параметров Теперь, когда наши изображения готовы, мы можем приступить к определению основных параметров внешнего вида с помощью CSS. Мы знаем, что на сайте будет использован белый фон, текст разного размера, шрифт Georgia (или другой

Установка основным параметров

251

Как уже упоминалось в главе 9, значение 0 не требует указания единиц измерения. И наконец, в нашем правиле мы использовали элемент внутреннего отступа padding для пользователей Opera.

Классы Hide и Block Далее с помощью двух простых правил мы выполним два очень важных шага: .hide { display: } img {

none;

display: block; border: 0; }

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

Правило для изображений Второе правило более полезное и менее сложное. Запись d i s p l a y : b l o c k ; указывает на то, что каждое изображение на странице будет отображаться не в строке, а как отдельный блочный элемент. Это можно сравнить с абзацем, отделенным промежутками и символом возврата каретки против тега <i> (курсив), который является строчным элементом. Блочные элементы располагаются в собственных «полях», и после них следует символ возврата каретки. Сообщив браузеру, что наши изображения являются блочными элементами, мы избавляемся от необходимости вставлять <br>, <br c l e a r = " a l l " > или другой подобный «мусор» перед изображениями или после них, а также отпадает необходимость размещать изображения в отдельных ячейках таблицы для сохранения разметки. (Мы более подробно коснемся этого вопроса в главе 11. Если вы хотите получить дополнительные сведения, прочтите статью «Изображения, таблицы и загадочные пробелы», размещенную на сайте http://devedge.netscape.com/viewsource/2002/img-table.)

252

Глава 10. CSS в действии: смешанная разметка

Этот прием кажется таким простым, что большинство из вас не обратит на него внимания, однако присвоение статуса block или i n l i n e элементу является чрезвычайно мощным оружием. Например, обычные ссылки можно превратить в кнопки посредством CSS. Добавив дополнительный селектор, можно будет задать вертикальный отступ для изображения, таким образом, нам потребуется лишь несколько строк CSS для достижения результата, ранее требовавшего нарезки, вложенных ячеек и прозрачных GIF-изображений. Прочтите еще раз этот абзац. Мы сообщаем вам, как добиться разметки, заменяющей 50 табличных ячеек и десяток нарезанных изображений, используя всего несколько строк кода и правил CSS. Далее, b o r d e r : 0; отключает рамки изображений, поэтому нам не придется в коде писать border=" 0". (Если нам не все равно, как будет выглядеть наша страница в не поддерживающих CSS браузерах, нам все же придется включить в код b o r d e r ^ " 0", что мы и сделали, объяснив это в главе 8.)

Цвета ссылок. Вводим псевдоклассы Обычно в HTML-коде мы задаем цвет ссылок с помощью атрибутов элементов body, например v l i n k = " #ССЗЗ 00 ". В современном Web-дизайне вместо этого мы можем использовать CSS. CSS также позволяет управлять состоянием hover, внешним видом просмотренных и активных ссылок. Более того, CSS предлагает нам нечто большее, чем простое изменение цвета ссылок. В CSS такие состояния ссылок называются селекторами псевдоклассов. С точки зрения CSS настоящими классами являются явно указанные атрибутом c l a s s элементы. Псевдоклассы зависят от действий пользователя или состояния браузера (:hover, : v i s i t e d ) . Есть также псевдоэлементы ( : b e f o r e и : a f t e r ) . В любом случае, используя четыре приведенных ниже правила, мы зададим ссылками цвет и не только (рис. 10.4-10.5): a-.link

{

font-weight: bold; text-decoration: none; color: #c30; background: transparent; } a:visited { font-weight: bold; text-decoration: none; color: #c30; background: transparent;

Установка основных параметров

253

Рис. 10.5. Когда посетитель наводит указатель мыши на ссылку, она становится ярко-оранжевой (здесь светло-серой) и подчеркнутой благодаря правилу CSS a:hover

Еще немного о ссылках и селекторах псевдоклассов В приведенном выше примере, возможно, вы впервые столкнулись со свойством t e x t - d e c o r a t i o n . При значении попе текст не имеет подчеркивания, если u n d e r l i n e - ссылка - будет подчеркнута. Еще это свойство может иметь значение over l i n e . В этом случае над ссылкой будет проведена черта. Можно комбинировать нижнюю черту с верхней: text-decoration:

underline overline;

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

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

254

Глава 10. CSS в действии: смешанная разметка

именно: l i n k , v i s i t e d , hover, a c t i v e (LVHA). Запомнить аббревиатуру для удобства можно таким образом - LoVe-HA! Для желающих понять, почему порядок имеет значение, советуем посетить http://www.meyerweb.com/eric/ css/link-specificity.html.

Неприятности с IE/Windows Стоит отметить, что даже самая последняя на момент написания книги версия IE для Windows несколько некорректно обрабатывает псевдоклассы hover и a c t i v e . Состояние hover, бывает, «зависает». Нажмите клавишу Назад в IE, и вы обнаружите, что последняя ссылка, на которую вы навели указатель мыши, осталась в состоянии hover. По той же причине вы обнаружите, что ссылка, по которой вы щелкнули, чтобы перейти вперед, осталась в состоянии a c t i v e . Возможно, это вам не понравится. Точно так же, если вы используете изображения для состояния а: a c t i v e , IE/Windows обработает их неверно. Если ваша аудитория включает пользователей IE/Windows (скорее всего, так и есть), вы можете полностью отказаться от использования а: a c t i v e или не делать ничего экстраординарного с этим псевдоклассом, как поступили мы. «Зависание» ссылок можно расценивать как ошибку или опцию, в зависимости от того, кого вы спрашиваете. Двести миллионов пользователей Windows, скорее всего, привыкли к такому положению дел, а многие полагают, что так и должно быть.

Описание других общих элементов В примере ниже мы видим правило «Не обижайте Netscape 4» в действии. Мы сообщаем браузеру, что сайт использует шрифт Georgia или альтернативный serif (рис. 10.6): р, td, 11, u l , o l , h i , h2, h3, h4, h5, h6 { font-family: Georgia, "New Century Schoolbook", Times,

serif;

}

Georgia, шрифт Microsoft, разработанный Мэтью Картером (Matthew Carter) и четко отображающийся даже при самых маленьких размерах, установлен в большинстве систем Windows и Macintosh. Шрифт New Century Schoolbook можно найти в большинстве систем UNIX, Times есть даже на самых древних компьютерах. В противном случае будет использоваться шрифт семейства serif. С помощью следующего правила мы сообщаем браузеру, что заголовки должны быть несколько больше, чем размер шрифта пользователя по умолчанию. Когда не указан базовый размер шрифта, браузер по умолчанию отображает

Установка основных параметров

255

256 f пава 10. CSS в действии; смешанная разю&жа

Еще немного о размерах шрифтов При установке относительного размера шрифта следует помнить, что пользователь иногда изменяет размер шрифта по умолчанию. Тогда, если, например, вы указали, что шрифт страницы должен быть меньше используемого посетителем по умолчанию, а он изменил размер шрифта и сделал его маленьким, ваш шрифт может оказаться слишком мелким. Например, если пользователь в качестве используемого по умолчанию шрифта выбрал Verdana llpx, ваш мелкий текст может быть 9рх или Юрх, что вряд ли будет удобно для чтения. Некоторые пользователи, конечно, могут подкорректировать размер шрифта, а некоторые могут не захотеть это делать, другие же могут просто не знать, как это делается. В большинстве компьютеров по умолчанию выбран достаточно крупный шрифт, и, если вы на свой странице укажите размер 0.85ет, это должно смотреться хорошо. Если пользователь увеличит размер шрифта по умолчанию, это не станет катастрофой и ваш сайт все равно будет смотреться неплохо, а пользователь заметит, что шрифт на нем несколько меньше, чем обычно. Однако, если пользователь выберет по умолчанию мелкий шрифт, ваш сайт может стать нечитабельным. Мы также можем указать размер шрифта для нашей страницы в пикселях: font-size:

13px;

Или так: font: 13px/1.5 Georgia, "New Century Schoolbook", Times, serif; В отличие от относительного размера в em, использование рх для указания размера шрифта работает с точностью 99,9% на всех платформах. Если же размер текста окажется слишком мелким для пользователя, он всегда сможет воспользоваться средством увеличения текста Text Zoom или Page Zoom, доступным во всех современных браузерах, за исключением одного. К сожалению, им является IE/Windows, в настоящее время самый распространенный браузер в Сети. Ирония в том, что именно Microsoft изобрела Text Zoom для IE 5/Мас в 2000 году. Однако это средство так и не добралось до Windows-версии браузера. Таким образом, если вы будете использовать пиксели для указания размера шрифта, вы рискуете сделать страницу недоступной пользователям IE/Windows с ослабленным зрением. Если же вы будете использовать em, как это сделали мы, вы рискуете разочаровать пользователей, установивших мелкий размер шрифта по умолчанию. Иными словами, что бы вы ни предприняли в данном случае, кого-нибудь вы все же разочаруете. Однажды мы решили вообще не задавать размер шрифта,

Остановка основных параметров

257

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

Чудеса высоты строки Давайте еще раз взглянем на указатель высоты строки в обсуждаемом нами правиле: line-height:

1.5;

Высота строки в CSS - это то же самое, что и отступ. Высота строки 1,5 означает отступ 150%. Можно пометить высоту строки 1.5ет, но в этом нет необходимости. До появления CSS мы могли лишь имитировать отступ с помощью неструктурного использования тегов абзаца, <рге> или вставки прозрачных изображений GIF размером в пиксель после каждой строки. Теперь мы можем забыть обо всех этих ухищрениях благодаря CSS.

Выравнивание по левому краю и головная боль И наконец, если вы еще раз взгляните на наше правило, то, возможно, зададитесь вопросом - зачем мы указали t e x t - a l i g n : l e f t . Ответ прост. Если не сделать это, в IE 6/Windo\vs текст может быть выровнен по центру из-за внутренней ошибки. Кстати говоря, эта ошибка отсутствует в IE 5/Windows, равно как и в каких-либо других современных браузерах. Ошибка проявляется спонтанно. Некоторые элементы отображаются слева корректно, другие - нет. Поэтому рекомендуем вам при необходимости выравнивать их по левому краю.

Еще один селектор Сейчас вы уже неплохо разбираетесь в языке CSS и поймете небольшое правило: #footer p { font-size: llpx; margin-top: 25px; }

Нам не придется объяснять, что здесь используется уникальный идентификатор id со значением f o o t e r в качестве селектора, и любой абзац, помеченный f o o t e r , будет иметь размер шрифта Прх и отступ сверху размером 25рх. Вам также не потребуется напоминать, что браузер уже знает, какой шрифт использовать, так как мы указали это ранее.

258

Глав»,

Установка разделов страницы Следующий набор правил задает основные разделы страницы. Мы расположили их рядом в нашем CSS-файле для облегчения дальнейшего редактирования и редизайна, мы также снабдили их комментариями, которые помогут в дальнейшем нам или нашим коллегам понять, для чего служат эти правила. Комментарии пишутся здесь почти так же, как и в HTML, но с некоторыми отличиями. Вслед за комментариями следует правило, указывающее, что основная область контента будет иметь белые поля слева и сверху размером 25рх (рис. 10.7), и правило, размещающее фоновое изображение (arrow.gif) вверху и в центре таблицы с идентификатором c o n t e n t (рис. 10.8).

Рис. 10.7. Отступы между навигационным меню, изображением и текстом выполнены с помощью одного правила CSS

Рис. 10.8. Изображение стрелки, стилизованное под водяной знак, является фоном для обеих таблиц

Установка о

?-амет§»ов

259

Достигнуть такого результата с помощью атрибутов фонового изображения ячейки таблицы было бы весьма затруднительно. Фоновое изображение охватывает сразу две ячейки - для этого нам пришлось бы разрезать его на кусочки, подогнать каждый фрагмент к отдельной ячейке и надеяться на то, что они составят единое целое. Кроме того, по умолчанию при использовании в контексте HTML-тега фоновое изображение собирается подобно мозаике, этого никак не избежать. Нам бы пришлось создать два прозрачных изображения, совпадающих по размеру с таблицей, и молиться, чтобы пользователь не изменил размер шрифта, что привело бы к полному разрушению разметки. Помимо этого, пришлось бы ограничить размер каждой страницы и, соответственно, объем контента. Благодаря CSS мы можем не думать о подобных вещах. Используемые правила гораздо компактнее и проще для понимания, чем их описание в нашей книге: /* Основные разделы страницы */ #primarycontent { padding-left: 25px; padding-top: 2 5px; #content { background: no-repeat;

transparent

url(images/arrow.gif)

}

Затем мы добавим правила для боковой панели: /* Атрибуты отображения боковой панели */ #sidebar p { font-style: italictext-align: right; margin-top: 0.5em; } #sidebar img { margin: ЗОрх О 15рх 0; } #sidebar h2 { font-size: lem; font-weight: normal; font-style: italic; margin: 0; line-height: 1.5; text-align: right;

center bottom

260

Глава 10. CSS в действии; смешанна» разметка

Первое правило гласит, что все абзацы, относящиеся к элементу с идентификатором s i d e b a r , будут выровнены по правому краю, отображены курсивом и будут иметь отступ сверху размером 0.5ет. С помощью второго правила мы задаем размеры полей для изображений, относящихся к элементу с идентификатором id, равным s i d e b a r : поле сверху будет размером ЗОрх, нижнее поле - размером 15рх, отступы справа и слева будут нулевыми (рис. 10.9). Подобные правила CSS облегчают нашу жизнь, так как благодаря им мы можем забыть об использовании множества пустых ячеек и прозрачных изображений GIF для создания отступов. С помощью третьего правила мы задаем заголовкам h2 шрифт, схожий со шрифтом, который используется для выносок и цитат в журналах (особенно красиво это смотрится в Windows Cleartype или Mac OS X Quartz), и не похожий на HTML-заголовки (рис. 10.10).

Рис. 10.9. Аккуратные отступы сверху и снизу изображения боковой панели получаются за счет использования полей элемента img. Изображения, помеченные в d i v значением s i d e b a r , будут выполнять это правило, другие изображения - нет

Рис. 10.10. Сноска на боковой панели, помеченная как заголовок h2, выглядит не как HTML-заголовок, а как цитата

262

Глава 1©*- С

ШВ

•

ЩЩШШ

263

Ненужные изображения (окончание). Удалив изображение из состояния ссылки при наведении на нее указателя мыши ( b a c k g r o u n d - i m a g e : n o n e ; ) , мы добились бы такого же эффекта белого фона при наведении мыши на ссылку, а также сэкономили бы трафик и уменьшили число используемых изображений. Немного далее в этой главе, при создании в панели навигации эффекта, указывающего пользователю его местонахождение, мы поступим именно так, без применения фонового изображения GIF. Тем не менее мы использовали такой прием, чтобы показать вам наглядно его возможности и чтобы вы смогли использовать его в своих дальнейших проектах.

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

РИС. 10.11. Эффекты при наведении указателя на элемент достигнуты применением псевдоклассов к ячейкам таблицы с идентификатором nav

Рис. 10.12. Когда посетитель наводит указатель мыши на элементы меню, фон становится белым. Для этого не используется JavaScript (хотя мы не видим в этом языке ничего плохого)

Проблема в том, что фоновый цвет ссылки состояния l i n k и v i s i t e d (см. рис. 10.1) заполняет только часть ячейки, а не все пространство. В дальнейшем мы попытаемся это исправить.

264

Глава fO« CSS в действии: смешанная разметка

Панель навигации на CSS: второй подход, первая попытка В первой попытке второго подхода мы несколько модифицируем правила для ссылок меню - зададим размеры активной области: #nav td a: link, #nav td a: v i s i t e d { background: transparent url(images/bgpat.gif) display: block; margin: 0; width: lOOpx; height: 2 5px;

repeat;

}

Как и ожидалось, благодаря этому правилу фон кнопок в правой части панели полностью заполнил ячейки. Однако фоновый цвет ячейки с логотипом также стал размером лишь 100х25рх (рис. 10.13). Такой размер подходит для маленькой ячейки, но он мал для ячейки с логотипом, размер которой - 400х75рх.

Рис. 10.13. Шаг вперед, два назад. Фон ячеек меню теперь занимает всю их площадь, однако фон ячейки с логотипом стал слишком мал

Каким- то образом сделанные нами изменения также уничтожили вертикальное выравнивание, заданное ранее. Элементы выровнены по вертикали внутри ячеек, но их контент - нет. Как видно на рис. 10.13, текст «кнопок» теперь «прилип» к верхним границам ячеек, вместо того чтобы «висеть» посередине. Такое расположение текста проявляется во всех используемых для проверки страницы браузерах и, следовательно, не является ошибкой одного из них. К счастью, при создании кода в главе 8 мы присвоили каждой ячейке уникальный идентификатор. Идентификатором ячейки с логотипом является home. Можем ли мы создать отдельное правило для home, которое бы имело приоритет перед правилом, устанавливающим размер фона ячейки 100х25рх? Ответ положительный: td#home a:link, td#home a : v i s i t e d { background: transparent url(images/bgpat.gif) repeat; width: 400px;

Панель навигации CSS: окончательный подход

td#home a:hover { background: white width; 400px; height: 75px;

u r l (images/nopat.gif)

265

repeat;

}

Благодаря этим правилам фон ячейки с логотипом стал нужного размера и сайт практически готов. Однако нам еще необходимо устранить ощибку выравнивания текста в ячейках «кнопок», которого мы надеялись достичь с помощью v e r t i c a l - a l i g n : middle. Мы сделаем это в окончательном подходе.

Панель навигации CSS: окончательный подход

В последнем подходе мы добились всего, чего хотели:

/* Компоненты панели навигации */ table#nav { border-bottom: Ipx solid #000; border-left: Ipx solid #000; } table#nav td { font: 1Ipx verdana, arial, sans-serif; text-align: center; border-right: Ipx solid #000; border-top: Ipx solid #000; } table#nav td a { . font-weight: normal; text-decoration: none; display: block; margin: 0; padding: 0; .' ... } #nav td a: link, #nav td a:visited { background: transparent url(/images/bgpat.gif) repeat; display: block; margin: 0; . width: lOOpx;

266

Глава 10, CSS в действии: стеш,

та

line-height: 2 5px; } #.nav td a : hover { color: #f60; background: white url(/images/nopat.gif) repeat; } td#home a:link img, td#home a:visited img { color: #c30; background: transparent url (/images/bgpat.gif) repeat; width: 400px; height: 7 5px; }

•

••"-..;

td#home a:hover img color: #f6.0;

{

background: white u r l ( /images/nopat.gif) width: 40 0px; height: 7 5px;

repeat;

}•

Что изменилось? Мы удалили инструкцию v e r t i c a l - a l i g n : middle. Затем мы удалили строку, указывающую на высоту кнопок в 25рх, и заменили ее на: line-height:

25рх;

Благодаря этому текст стал располагаться точно посередине. Не совсем понятно, почему этот метод сработал лучше предыдущего, главное - мы добились своего.

Окончательные штрихи: внешние стили и эффект «Вы находитесь здесь» Перед завершением работы над сайтом и его сдачи заказчику следует выполнить еще два шага. Мы должны переместить вложенные в код правила CSS в отдельный файл. Затем мы создадим эффект «Вы находитесь здесь» (рис. 10.14здания ните: цессом. ет 10.15), информацию Создание мы указывающий дополнительных После не будем эффекта того о изменять таблице как пользователю «Вы мы классов находитесь удалили стилей код, адля создадим сстили на помощью нашей здесь» егоCSS местонахождение этот панели является из ссылки: эффект, кода, навигации. каждая довольно используя на страница простым сайте. CSSполучаЗапомбезпросо-

Окончательные штрихи;: внешние стили и эффект иШы изменитесь здесь»

267

268

Глава 10. CSS в действии; смешанная разметка

Окончательные штрихи: внешние стили и эффект иВы находитесь з&еаы>

color: #сЗО; background: #fff; } </style>

269

Таким образом, каждая страница сайта содержит подобное правило, благодаря которому посетитель видит, на какой странице он находится, и для создания этого эффекта нам не пришлось менять код. Конечно, можно было бы изменить код каждой страницы или создать класс t h i s p a g e с элементом «вы находитесь здесь» и использовать его для игнорирования правил меню определенной ссылки. А зачастую дизайнеры поступают именно так. Однако, оставив код панели навигации нетронутым на каждой странице, мы имеем возможность вставлять одни и те же данные вновь и вновь посредством серверных приложений, что довольно удобно для небольших и средних сайтов. На сайте www.zeldman.com мы использовали такой же прием для оформления меню навигации и создания эффекта «Вы находитесь здесь» и SSI для вставки одинаковых XHTML-данных на каждую страницу. Но это уже другой сайт и другая история, а мы подошли к концу еще одной главы. В следующей главе мы более подробно расскажем о CSS, узнаем о некоторых ошибках браузеров и способах их обхода, сообщим о некоторых вещах, которые браузеры выполняют корректно, и расскажем о некоторых «упрямых» элементах, затрудняющих распространение Web-стандартов.

f f l M i

1 1 •

П е р е к л ю ч е н и е

DOCTYPE и поддержка стандартов

ак современные браузеры узнают совместимые со стандартами сайты? Каким образом они корректно отображают подобные сайты наряду с выполнением тяжелой работы по поддержке устаревших образцов искусства Web-дизайна? Ответ заключается в том, что большинство современных браузеров используют наш «старый добрый» DOCTYPE, с которым мы познакомились в главе 6. Этот элемент сообщает браузеру о режиме работы: то ли он будет функционировать в режиме стандартов (Standards), согласно спецификациям W3C, то ли в режиме уловок (Quirks), названном так потому, что для создания сайтов в былые времена приходилось прибегать к ухищрениям. Если вы хотите контролировать внешний вид своего сайта и его поведение - эта глава для вас. Интересно, что в браузерах на базе Gecko, таких как Mozilla и Netscape, режим стандартов несколько отличается от режима стандартов в Internet Explorer, и эти небольшие различия могут оказать огромное влияние на вашу разметку. Чтобы сгладить появление возможных проблем и сделать нашу жизнь еще более интересной, последние версии Gecko-браузеров вроде Mozilla 1.01+ или Netscape 7 имеют еще один, третий, режим, имеющий много общего с поведением Internet Explorer. В Gecko-браузерах третий режим, схожий с поведением IE, называется почти стандартным. Это название не стоит считать оскорблением в адрес режима стандартов IE, по крайней мере, мы не считаем, что оно было придумано с оскорбительным умыслом. Скорее всего, эксперты по стандартам Gecko хотели сказать, что поведение браузеров в данном случае несколько отличается от строгой буквы законов CSS. В этой главе разъясняется, как работают разные режимы, и приведены простые способы добиться требуемого внешнего вида сайта, несмотря на различия обработки CSS разными браузерами. Если вы создали переходный сайт

Сага и переделки

ЭСГУРЕ

271

со смешанной разметкой (таблицы и CSS) в XHTML, после чего некоторые браузеры стали по-другому отображать вашу разметку, и вы хотите понять, почему это произошло, - эта глава для вас. «Сага о переключении DOCTYPE», которую мы предлагаем вашему вниманию ниже, повествует о том, почему большинству браузеров требуется механизм переключения для выбора между режимом стандартов и уловок и как таким переключателем стал бедный DOCTYPE. Если вы всегда хотите добраться до истины, узнать, откуда что появилось и почему, - продолжайте чтение. Если вы желаете пропустить сведения, предназначенные «для общего развития», и перейти сразу к делу - переходите непосредственно к разделу «Управление браузером: переключатель DOCTYPE».

Сага о переключении DOCTYPE В конце девяностых годов прошлого столетия лидирующие на рынке производители браузеров осознали, что полная и корректная поддержка стандартов является важным желанием их клиентов, создающих и разрабатывающих сайты. Тогда они спросили себя, каким образом возможно создать новые, совместимые со стандартами браузеры, при этом не оставив за бортом разработанные по старым методам сайты? В конце концов, дизайнеры уже изучили все особенности Netscape Navigator и Internet Explorer и научились приспосабливаться под эти требования при создании сайтов. Конечно, Microsoft и Netscape хотели воплотить поддержку стандартов в своих браузерах, но так, чтобы не сделать существующие сайты полностью неприспособленными к жизни в условиях появления новых версий браузеров, - для новых программных продуктов это было бы подобно самоубийству. Следующий пример может прояснить сложившуюся тогда ситуацию. , В середине девяностых годов, когда ранние версии Internet Explorer стали частично поддерживать CSS 1, они обладали некоторыми ошибками. Первый блин всегда комом, и тем не менее мы благодарны Microsoft за желание поддерживать CSS в начале 1997 года. Однако десятки тысяч дизайнеров приспособились к имеющимся в IE 4.x и IE 5.x ошибкам и стали подстраивать свои правила CSS под них. Если в более поздних версиях браузера от Microsoft или его конкурентов эти ошибки будут устранены и браузеры начнут обрабатывать CSS корректно, дизайнеры останутся не у дел, к разочарованию пользователей, заказчиков и их самих. Что же делать?

272

Глава 1 1 . Переключение DOCTYPE и поддержка стандартов

Переключатель для включения и выключения стандартов Еще до того как Microsoft и Netscape стали выпускать совместимые со стандартами браузеры, поддерживающие их более корректно и полно, один дальновидный разработчик предложил выход из сложившейся ситуации. Этим человеком был Тодд Фарнер (Todd Fahrner), участник групп W3C по разработке CSS и HTML и соучредитель проекта Web Standards. В начале 1998 года Фарнер предложил производителям браузеров использовать механизм переключения, способный включать и отключать режим поддержки стандартов. В качестве такого переключателя он предложил использовать наличие или отсутствие DOCTYPE. «Если код Web-страницы начинается с DOCTYPE, велики шансы на то, что ее автор был знаком со стандартами и попытался создать совместимую с ними страницу», - рассудил Фарнер. Браузеры в таком случае должны будут обрабатывать эту страницу согласно спецификациям W3C. Соответственно, страница без DOCTYPE предположительно не сможет пройти проверку W3C (http:// validator.w3.org) и, вероятно, создана устаревшими методами, вследствие чего браузеры должны обрабатывать ее соответствующим образом, как это делали поколения, несовместимых со стандартами браузеров. Оставалась лишь одна проблема: на тот момент совместимых со стандартами браузеров просто не существовало. Весь мир ждал два года, чтобы узнать, может ли DOCTYPE стать ключом к поддержке стандартных и устаревших сайтов.

Появление переключателя DOCTYPE в браузерах В марте 2000 года компания Microsoft выпустила IE 5 Macintosh Edition на базе движка Tasman, созданного инженером Microsoft и сторонником стандартов Тантеком Целиком (Tantek 3elik). Браузер обладал корректной и почти полной поддержкой стандартов, включая CSS I, XHTML и DOM. IE 5/Macintosh также мог похвастаться инновационным средством Text Zoom, повышавшим доступность сайтов, и был первым браузером, использовавшим DOCTYPE для переключения между режимами. Создатели другого семейства совместимых со стандартами браузеров на базе Gecko обратили внимание на эти новшества (переключатель DOCTYPE и Text Zoom). В Gecko-браузерах, выпущенных вскоре после IE 5/Мас, включая Netscape 6, Mozilla, Chimera, имелось средство Text Zoom и поддержка переключения DOCTYPE. Они также могли похвастаться превосходной и детальной

Управление браузером; переключатель P0CTYPE

273

поддержкой Web-стандартов, ставшей возможной благодаря движку Gecko/ Mozilla (http://www.mozilla.org/newlayout). Когда на свет появился IE 6/Windows, он также поддерживал переключатель DOCTYPE. Было также добавлено свойство объектной модели документа DOM, с помощью которого можно узнать, включен ли режим стандартов для загруженного Web-документа (http://msdn.microsoft.com/workshop/author/ dhtml/reference/properties/compatmode.asp). O p e r a без переключателя. Вплоть до версии 7.0 браузер компании Opera Software под названием Opera не играл по общепринятым правилам: все страницы браузер пытался открывать как совместимые со стандартами независимо от того, как была создана страница. Также до версии 7.0 браузер не поддерживал D O M W 3 C , поэтому сайты, использующие D O M , не работают корректно в старых версиях Opera. К счастью, большинство пользователей Opera имеют привычку загружать новые версии браузера по мере их выпуска. Кроме того, начиная с Opera 7.0 браузер поддерживает переключение DOCTYPE, хотя компания пока и не опубликовала документацию по этой функции. (Работает ли поддержка DOCTYPE так же, как в IE? Как в Mozilla/Netscape? Или ни то и ни другое? Придется подождать ответа.)

Управление браузером: переключатель DOCTYPE Как уже было сказано ранее, все браузеры используют наличие или отсутствие в коде страницы переключателя DOCTYPE для выбора режима совместимости со стандартами или поддержки старого, неряшливого способа создания и отображения сайтов. В зависимости от браузера, использование DOCTYPE может слегка различаться, однако в целом все происходит примерно так, как предложил Тодд Фарнер в 1998 году, когда совместимые со стандартами браузеры были не более чем мечтой некоторых дизайнеров. Ниже приведено упрощенное описание работы данного принципа: » • XHTML DOCTYPE, который включает полный URI (Web-адрес), указывает IE и Gecko-браузерам, что страницу следует отображать в режиме полной совместимости со стандартами, обрабатывать CSS и XHTML в соответствии со спецификациями W3C. Некоторые HTML 4 DOCTYPE также вызывают в браузерах режим совместимости со стандартами, который подразумевает, что вы знаете, что делаете;

274

Глава 1 1 . Переключение DOCTYPE и поддержка стандартов

• использование неполного или устаревшего DOCTYPE либо полное его отсутствие говорит браузеру, что перед ним страница, написанная устаревшими методами, со всеми уловками и приемами, не соответствующими Web-стандартам. В этом случае браузер пытается отобразить вашу страницу в режиме обратной совместимости, обрабатывая CSS так, как это могло быть сделано в IE 4/5. Таким образом, чтобы указать браузеру, в каком режиме работать, просто добавьте в код DOCTYPE.

Три режима для сестры Сары По причинам, которые мы объясним немного позднее, новые Gecko-браузеры работают в трех режимах: обратной совместимости с устаревшими страницами, почти стандартном режиме (эквивалентном стандартному режиму IE) и в стандартном режиме (слегка отличающемся от стандартного режима IE). Также некоторые DOCTYPE включают стандартный режим в ранних версиях Gecko-браузеров и почти стандартный в новых версиях Gecko-браузеров. Для непосвященных это может звучать слегка запутано, но через несколько страниц вы поймете, что ситуация на самом деле еще хуже. Тем не менее на это есть свои причины, и, что более важно, есть простые способы обойти все эти сложности и создать страницу, корректно отображаемую не только в браузерах с разными способами переключения DOCTYPE, но и в браузерах вроде Opera 5/6, которые и вовсе не используют переключатель DOCTYPE. Оставайтесь с нами и продолжайте читать - вместе мы преодолеем все трудности. Перед тем как узнать о различиях браузеров, давайте познакомимся с их общими свойствами.

Полные и неполные DOCTYPE Браузеры, использующие переключение DOCTYPE, ищут в коде полные DOCTYPE. Иными словами, они ищут DOCTYPE с полным Web-адресом, например: http://www.w3.org/TR/xhtmll/DTD/xhtmll-strict.dtd. Следующий DOCTYPE включает стандартный режим в любом современном браузере, использующем механизм переключения: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " h t t p : //www. w3.org/TR/xhtmll/DTD/xhtmll-strict.dtd 11 > Этот DOCTYPE указывает, что мы используем XHTML 1.0 Strict, несмотря на то что в книге мы пропагандируем Transitional. Дело в том, что именно такой

Управление 6paf зершш г

275

DOCTYPE указывает браузеру на необходимость отображения страницы в режиме стандартов. Многие дизайнеры и визуальные Web-редакторы используют DOCTYPE, которые вместо стандартного режима включают в браузере режим обратной совместимости: <'DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 S t r i c t / / E N " "DTD/xhtmll-strict.dtd">

Каким образом этот пример отличается от предыдущего? Если посмотреть внимательнее на последнюю часть этого DOCTYPE (" DTD/ x h t m l l - s t r i c t . d t d " ) , вы увидите, что это относительная ссылка, а не полный URL Если выражаться точнее, это относительная ссылка на документ DTD на Web-сайте W3C. Если только вы не скопировали этот документ на свой сервер и не поместили его в указанный каталог, а так никто не делает, относительная ссылка указывает на несуществующий документ. Так как DTD находится на сайте W3C, а не на вашем, URI считается неполным и браузер переходит в режим обратной совместимости со старыми сайтами. (Пытаются ли браузеры на самом деле найти и загрузить DTD? Нет, они просто определяют неполный DOCTYPE по своей базе данных и переходят в Quirks-режим «уловок». Значит ли это, что сайт www.w3.org, использующий относительную ссылку на DOCTYPE, будет отображаться в браузерах в режиме «уловок»? Как бы иронично это ни звучало, но, скорее всего, это именно так. В конце концов, это на наши с вами проблемы.) Давайте еще раз взглянем на полную версию DOCTYPE, которая включает режим совместимости со стандартами в браузере: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtmll/DTD/xhtmll-strict.dtd">

Обратите внимание, что в конце тега приведен полный URL Если скопировать этот адрес в адресную строку браузера, то можно загрузить XHTML 1.0 Strict DTD во всей его непостижимой заумности и ознакомиться с ним. Так как URI в конце этого DOCTYPE указывает на определенное нахождение документа в Сети, браузеры признают такой DOCTYPE полным и переключаются в режим стандартов. Хотим подчеркнуть, что Internet Explorer переключается в режим стандартов при наличии любого XHTML DOCTYPE, включает он в себя полный URJ или нет. Все же мы призываем вас использовать XHTML DOCTYPE с полным URI, так как в ином случае такой DOCTYPE технически считается некорректным. В конце концов, зачем переключаться в режим стандартов, если ваша страница содержит некорректный код?

276

Глава 1 1 . Переключение DOCTYPE и поддержка стандартов

XML-пролог и IE6/Windows. В каждом правиле есть исключения. Даже при наличии полною XHTML DOCTYPE IE6/Windows перейдет в режим «уловок», если вы включите в код XML-пролог. Именно поэтому мы посоветовали вам не использовать его в главе 6.

Управление браузеров: переключатель Р0€?¥РЕ

277

Берегите ваши пальчики. Если вам не по себе от одной мысли о том, чтобы перепечатывать все эти DOCTYPE (а кому это понравится?), можете просто скопировать их из статьи "Fix Your Site with the Right DOCTYPE" с сайта A List Apart (http://www.alistapart.com/stories/ doctype).

Выводы: переключатели X H T M L DOCTYPE в IE и Gecko Давайте обобщим новые знания: • любой полный XHTML 1.0 или 1.1 DOCTYPE включает режим стандартов в совместимых версиях Internet Explorer (IE5+/Macintosh, IE6+/Windows) и в ранних версиях Gecko-браузеров (Netscape 6, Mozilla 1.0); • полный Strict XHTML DOCTYPE включает режим стандартов во всех указанных выше браузерах и более новых версиях Gecko-браузеров; • полный XHTML 1.0 Transitional или Frameset DOCTYPE включает «почти стандартный» режим в последних версиях Gecko-браузеров; • неполный DOCTYPE с относительными или отсутствующими URI включает Quirks-режим во всех браузерах, поддерживающих переключение DOCTYPE. Такие DOCTYPE также создают ошибки проверки CSS, но не создают ошибок проверки XHTML из-за внутренней ошибки службы проверки W3G XHTML либо из-за различий между службами проверки CSS и XHTML, в зависимости от того, кого вы спрашиваете. В общем, забудьте все, что мы сказали, кроме того что неполный DOCTYPE вызывает режим «уловок» и создает ошибки проверки CSS; • многие приложения для создания сайтов по умолчанию вставляют в код неполный DOCTYPE, что вызывает режим «уловок» в браузере и создает ошибки проверки CSS. Автор данной книги и другие участники Web Standards Project обращались к производителям популярных средств разработки сайтов с предложением вставлять по умолчанию полные DOCTYPE. Мы также настаиваем на том, чтобы на сайте W3C был опубликован список полных DOCTYPE. Пока же, если вы хотите убедиться в том, что ваш сайт вызовет режим стандартов, вам придется вручную отредактировать DOCTYPE при создании XHTML-страниц.

278

Глава 11» Переключение D0CYYPE и поддержка стандартов

П е р е к л ю ч е н и е DOCTYPE: трудности в деталях Переключение DOCTYPE не сводится к одному лишь XHTML. Как упоминалось ранее, некоторые полные HTML DOCTYPE также переводят браузер в режим стандартов. Например, IE переходит в стандартный режим (а последние версии Gecko-браузеров в «почти стандартный») при наличии полного HTML 4.01 Strict Doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Но и в IE, и в Gecko-браузерах полный HTML 4.0 DOCTYPE вызывает обратно совместимый режим «уловок». Такую разницу делает 0.1. Если такая непоследовательность подтолкнет вас к мысли перейти на XHTML - это как раз то, за что мы ратуем. Дополнительные сведения по DOCTYPE и последним версиям Gecko-браузеров можно найти в статье "Gecko's Almost Standards' Mode" no адресу: http:// devedge.netscape.com/viewsource/2002/almost-standards. Если в процессе чтения статья вам покажется чересчур сложной, остановитесь и забудьте все, что вы прочитали в ней. Как вы поймете из нашей книги, большинству из нас нечего волноваться относительно всех этих сложностей, так как мы создаем сайты с помощью XHTML 1.0 Transitional или Strict и у нас в запасе есть несколько простых CSS-решений, о которых мы поговорим ниже.

Да здравствует разнообразие браузеров! Режим стандартов Gecko отличается от поведения IE некоторыми деталями, и это может стать неприятным сюрпризом для неподготовленного дизайнера. Эта разница особо заметна и может стать очень неприятной при просмотре смешанной (CSS и таблицы) разметки в первом поколении Gecko-браузеров. После перехода с HTML 4.01 Transitional к XHTML 1.0 Transitional, не делая изменений в коде, кроме описанных в главе 6, дизайнер ожидает, что его сайт будет выглядеть так же, как и раньше. В конце концов, мы меняем лишь несколько тегов кода, а не дизайн. Тем не менее разметка их сайтов может выглядеть по-другому в ранних версиях Gecko-браузеров вроде Netscape 6.0 или Mozilla 1.0. Если дизайнер преобразовал сайт в XHTML Strict, разметка будет выглядеть иначе во всех Geckoбраузерах, старых и новых. Эти изменения вполне объяснимы, и есть очень легкий способ избежать появления неожиданных изменений в облике сайта.

Да здравствует разнообразие браузеров!

279

Пробелы вокруг изображений в Gecko На рис. 11.1 мы видим раздел ежедневных новостей сайта www.zeldman.com таким, как он был на протяжении нескольких лет, когда на сайте использовалась переходная разметка, сочетавшая CSS и таблицы. После преобразования из HTML 4.01 Transitional (и замене полного HTML 4.01 DOCTYPE на полный XHTML 1.0 Transitional DOCTYPE) сайт не изменился при просмотре его в Internet Explorer для Windows и Macintosh. Но в Gecko-браузерах между изображениями в таблице навигационного меню появились нежелательные отступы неизвестного происхождения (рис. 11.2-11.3).

280

Глава 1 1 . Переключение DOCTYPE и поддержка ста

Рис. 11.2. В ранних версиях Gecko-браузеров на странице появились нежелательные отступы

Рис. 11.3. Этот же рисунок, но в увеличенном виде, на котором явно различимы отступы

Рис. 11.4. Благодаря двум правилам CSS, описанным ниже, этот недостаток удалось быстро устранить

Одним правилом CSS убьем двум зайцев: убираем пробелы Для такого поведения браузера и появления отступов имеется весьма очевидная причина (см. врезку «Базовые линии PI вертикальные пробелы в стандартном режиме Gecko-браузеров»). Но, перед тем как углубляться в теорию, позвольте объяснить, как мы вернули навигационное меню к желаемому состоянию (рис. 11.4) в IE и Gecko-браузерах. Для этого потребовалось лишь два простых правила: img {display: block;} .inline {display: inline;}

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

Да здравствует разнообразие браузеров!

281

последовательно, как строка? С помощью второго правила (. i n l i n e ) мы создали класс, позволяющий нам сделать это. Изображения, которые следует обрабатывать как последовательные элементы, будут помечены следующим образом: <img class="inline" src="/image/example.png" /> Есть и другие способы добиться того же результата. Например, некоторые дизайнеры могут предпочесть использовать правило, указывающее, что если ячейка таблицы содержит только одно изображение, то его следует отобразить как блочный элемент: td img

{display:

block}

Благодаря одному простому правилу, меню навигации, которые обычно содержат по одному изображению на каждую ячейку, будут отображаться корректно и без пробелов, а другие изображения на странице будут отображены последовательно. Преимуществом этого метода является то, что в нем используется только одно правило вместо двух, также при его использовании отпадает необходимость присваивать классы некоторым изображениям, что серьезно экономит трафик. Каждый метод лучше подходит для определенной разметки. Ваш выбор зависит от дизайна сайта. Совет новичкам: попробуйте один способ. Если он не сработает, попробуйте второй. Возможно, вы даже придумаете свой собственный метод. Рождение «почти стандартного» режима Создание таких простых правил, как приведенные выше, занимает совсем немного времени и освобождает вас от переживаний по поводу того, как будет выглядеть ваш сайт в разных браузерах. Тем не менее, когда эта ошибка (появление пробелов) впервые появилась, а появилась она при переходе с HTML на XHTML, многие дизайнеры пришли к выводу, что виной этому является XHTML, другие возложили вину на Netscape 6 и Gecko-браузеры в целом. На самом деле стремление Gecko-браузеров добавить пробелы к изображениям без стилей является не ошибкой, а функцией (см. врезку «Базовые линии и вертикальные пробелы в стандартном режиме Gecko-браузеров»). Тем не менее дизайнеры не сразу поняли особенности этой функции и уж точно они не требовали ее появления. Чтобы угодить дизайнерам переходных сайтов, инженеры Gecko/Netscape создали «почти стандартный» режим, работающий как стандартный режим' Internet Explorer. Таким образом, при работе в этом режиме пробелы не появляются. Так как появление этих пробелов чаще всего возникает в переходных

282

Глава 1 1 . Переключение DOCTV

разметках, разработчики решили, что при использовании XHTML Transitional DOCTYPE будет активироваться режим Gecko «почти стандартный», тогда как Strict DOCTYPE будет активировать более строгий режим стандартов. (В конце концов, если вы создаете строгий код, вряд ли вы будете помещать изображения в ячейки таблиц.) Базовые линии и вертикальные пробелы в стандартном режиме Gecko-браузеров. Как описано ранее, IE и Gecko-браузеры в стандартном режиме по-разному обрабатывают изображения по отношению к предполагаемой сетке страницы. В режиме стандартов Gecko-браузеры определяют все изображения как последовательные элементы, если вы не указали в таблице стилей, что они блочные. Все последовательные элементы, такие как текст, располагаются на базовых линиях, чтобы предоставить место для подстрочных элементов букв, например «у» «д» и «j». Размер и расположение этой базовой линии зависит от размера и шрифта элемента, например от размера и шрифта текста абзаца, содержащего последовательное изображение. На рис. I 1.5 показан текст и последовательное изображение на базовой линии. В стандартном режиме Gecko всегда имеется пустое пространство под последовательными изображениями для обеспечения места для подстрочных элементов текста, неважно содержит блок текст на самом деле или нет. Более подробное описание этого эффекта можно найти в статье Эрика Майера "Images, Tables, and Mysterious Gaps" на сайте Netscape DevEdge (http://devedge.netscape.com/viewsource/2002/img-table).

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

Да здравствует разнообразие браузеров!

283

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

От «Да здравствует разнообразие!» д о f€@#$! Э т о $ # @ $ » Корректное поведение, хотя и несколько неожиданное, - это одно дело. Ошибки и недоделки браузеров - это совсем другое. В главе 12 мы познакомимся с общими ошибками браузеров и научимся обходить их. Мы также узнаем о важных аспектах разметки с помощью CSS.

•. Блочная модель, ошибки браузеров и обходные пути

оздать однажды, публиковать везде». Этот лозунг является священным для дизайна, основанного на Web-стандартах. Мы учим XHTML не для того, чтобы получить какую-нибудь премию. Мы делаем это, чтобы обеспечить работоспособность наших сайтов в браузерах персональных компьютеров, в текстовых браузерах, в программах для чтения текста с экрана и в карманных компьютерах сегодня, завтра и через 10 лет. Точно так же мы используем CSS не для получения ежесекундной выгоды вроде снижения трафика и уменьшения счета за текущий месяц. Мы делаем это, чтобы наши сайты выглядели одинаково в сегодняшних браузерах и в Netscape 14.0. Поддерживающие стандарты браузеры являются залогом развития всеобщей совместимости, воплощенной в реальности. Если бы Web-сайты по-прежнему просматривались только через браузеры Netscape или Microsoft версии 4.0, совместимость была бы недоступна для всех сайтов, за исключением самых примитивных. Если бы браузеры продолжали по-прежнему пропагандировать запатентованные технологии, будущее Сети как открытой платформы было бы под большим вопросом. К счастью, большинство браузеров, выпущенных за последние годы, можно назвать «совместимыми со стандартами». Но некоторые более совместимы, чем другие. В данной главе описаны способы сосуществования с этими превратностями совместимости.

Блочная модель и ее недостатки Принимая стандарт CSS 1 в 1996 году, W3C предложила, чтобы все объекты на Web-странице заключались в виртуальную рамку (Box Model), свойства которой можно было бы менять посредством правил. Не важно, является ли объект абзацем, списком, заголовком, изображением или общим элементом блочного

Блочная модель и ее недостатки

285

Рис. 12.1. Четыре области блочной модели: контент, внутренний отступ, граница, внешний отступ

286

Глава 12. 1

-ie mjtm

опыта использования CSS, вы можете предположить, что w i d t h : 400рх; относится ко всему блоку (исключая внешний отступ). В конце концов, именно так работают программы по созданию разметки страниц, так мыслят дизайнеры и так пользователи понимают разметку. Если вы создадите CSS-разметку, содержащую два d i v расположенных рядом, каждый размером 50% от ширины окна пользователя, вы будете ожидать сохранения их размеров после добавления границ и внутренних отступов. Но CSS работает немного по-другому. Точно так же, если вы являетесь производителем браузеров и пытаетесь внедрить поддержку CSS в свой продукт на заре появления стандартов, вы можете ошибочно применить w i d t h : 4 0 Орх; ко всему блоку (исключая внешние отступы) вместо одной только области контента, как диктуют нам спецификации стандарта. Сделать такую ошибку было бы очень легко, особенно если вы используете CSS 1 сразу же после появления такого стандарта. Пожалуйста, запомните эту мысль, мы вернемся к ней позднее. На самом деле блочная модель CSS является более сложным элементом и в какой то степени более проблематичным, чем можно ожидать, опираясь на здравый смысл, нормы графического дизайна и ранние попытки поддержки CSS браузерами.

Как работает блочная модель Согласно CSS, каждой из четырех областей (контент, внутренний отступ, граница и внешний отступ) можно присвоить значения. Для определения размера блока сложите значения размера области контента, внутреннего отступа и границ (рис. 12.2). Если размер области контента равен 400рх, внутренний отступ с каждой стороны составляет 50рх, толщина границы - 2рх, то общая ширина блока составит 504рх. CSS все равно, каким способом вы задаете значения. Например, вы можете указать ширину области контента равной 67% от окна браузера пользователя, внутренний отступ - 5ет, а толщину границ - 1рх. В таком случае общий размер рамки будет зависеть от окна браузера пользователя и размера текста по умолчанию. О блочной модели можно сказать больше, чем уместится в этом разделе. Например, верхние и нижние внешние отступы вертикально выровненных элементов иногда наползают друг на друга. (Если вы хотите разобраться в этом, налейте себе чашечку кофе или что-нибудь покрепче и откройте ссылку h t t p : / / www.w3.org/TR/REC-CSS2/box.html.) Кроме того, значения размера теряют свой смысл, когда блочный элемент пуст. Если вы укажете размер пустого блока равным 100% ширины и высоты страницы, на самом деле он составит 0%,

Блочная модель и ее недостатки

287

Рис. 12.2. Для определения размера блока сложите значения размера области контента, внутреннего отступа и границ (2рх + 500рх + 400рх + 2рх = 504рх)

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

Разрушение блочной модели Если вы внимательно читали, вы уже догадались, каким образом блочная модель разрушается в ранних версиях браузеров с поддержкой CSS, например в IE 4-IE 5.5/Windows. В этих браузерах и в IE/Mac до версии 5.0 ширина и высота области контента применяются ко всему блоку в целом (исключая внешние отступы). На рис. 12.3 показана такая модель рамки. В IE 4-IE 5.5/Windows, если ширина области контента составляет 400рх, внутренний отступ - 50рх, толщина границы - 2рх, общая ширина рамки составит 400рх, а не 504рх, таким образом, область контента будет уменьшена до 29брх (400 - 50 - 50 - 2 - 2). Чем больше значения внутреннего отступа и толщины границы, тем сильнее будет отличаться реальные размеры блока от вашей задумки и тем меньше будет область контента. Сотни миллионов людей на момент написания этой книги продолжают использовать IE 5.x/Windows, а десятки тысяч дизайнеров научились использовать некорректную блочную модель для этих браузеров. Они до сих пор применяют

288

Гиава 12. Ело^наи ходень, ошибки браузеров и ©бледные пути

Рис. 12.3. Модель рамки в IE 4-IE 5.5/Windows. Посчитаем: 400 + 2 + 50 + 50 + 2 = 400. Вот такая арифметика

эти знания на практике, создавая сайты с разметкой, неправильно отображающейся в браузерах, корректно обрабатывающих стандартную блочную модель от W3C, например IE 6/Windows, IE 5/Macintosh, Netscape 6, Netscape 7, Mozilla, Chimera, Kmeleon, Safari, Opera 5, Opera 6, Opefa 7. И, наоборот, дизайнеры, использующие корректные блочные элементы, создают разметки, пригодные для перечисленных современных браузеров, но их творения могут выглядеть ужасно или даже быть полностью непригодными для использования в IE 5.5/Windows и более ранних версий, которые, как мы уже сказали, все еще используют миллионы пользователей. Существует несколько решений, но наиболее часто используемый метод является детищем инженера компании Microsoft. Перед тем как перейти к описанию, давайте взглянем на положительные стороны блочной модели.

В защиту блочной модели Блочная модель в IE 4/5.x/Windows (и во всех версиях IE для Macintosh до 5.0), безусловно, отображается некорректно и неправильно относительно спецификаций CSS, но в этом есть определенная логика. В некотором смысле использовать такую схему даже проще и удобнее, чем определенную W3C блочную модель. Блочная модель CSS удобна при создании разметки, использующей абсолютные значения в пикселях, однако этот факт может мешать дизайнеру при создании разметки с процентными значениями, зависящими от размера монитора пользователя. Давайте рассмотрим пример простой разметки с двумя ячейками, сумма левой и правой колонок которой составляет 100% окна монитора посетителя.

Блочная кго&ель т ее недостатки

289

Такие разметки легко создаются с помощью HTML-таблиц и сложнее с помощью CSS. Обычно для создания такой разметки с использованием CSS дизайнер создает два элемента d i v и применяет свойство f l o a t для расположения одного рядом с другим: #nav { width: 35%; height: 100%; background: #666; color: #fff; margin: 0; padding: 0;

#maintext { width: 65%; height: 100%; color: #000; background: #fff; margin: 0; padding: 0; float: right; }

Здесь мы видим два раздела страницы: один служит для навигации, второй для содержимого. Как следует из f l o a t : r i g h t , раздел с основным текстом будет наплывать на правую часть навигационного раздела. Раздел с навигацией занимает 35% окна, область с основным текстом - 65%. Вместе они займут все окно целиком (65 + 35 = 100). На рис. 12.4 мы видим, что такой подход работает до тех пор, пока мы не используем значения внутреннего отступа и ширины границы. Использование границ является необязательным и зависит от дизайна, однако без внутреннего отступа страница выглядит довольно непривлекательно, текст двух областей некрасиво стыкуется друг с другом. Если вы добавите значения внутреннего отступа и толщины границ к такой простой разметке, она развалится прямо на ваших глазах. В некоторых браузерах элементы накладываются друг на друга (рис. 12.5). В других, из-за того что общая ширина разделов теперь превышает 100%, разметка становится настолько широкой, что появляется горизонтальная Неважно, какой размер имеет монитор, разметка всегда будетполоса шире прокрутки. экрана.

290

Глава 12*

Можно несколько исправить положение, задав значения внутреннего отступа и ширину в процентах, однако точно высчитать их довольно трудно. Для решения этой проблемы в CSS 3 есть предложение использовать свойство выбора метода определения размеров, которое позволяет дизайнерам самим выбирать предпочтительный метод указания размеров рамки. Пока же дизайнерам приходится прибегать к всевозможным уловкам. Например, задавать d i v без внутренних отступов и использовать для этого внешние отступы. Недостаток этого метода в том, что создаются нежелательные неструктурные элементы, цель которых - исправить неурядицы с разметкой. Строго говоря, в этом нет ничего смертельного. Помимо лишних нескольких байтов, какой вред нанесет создание нескольких неструктурных элементов нашей разметке? Практически никакого, однако дело в том, что этот способ

Блочная модель и ее недостатки

291

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

вновь возвращает нас к устарелому способу мышления, от которого мы стараемся избавиться. (Дизайн испорчен? Напишем дополнительный код!) С точки зрения стандартов такого рода мышление должно отправиться вслед за динозаврами. Тем не менее сложность и некоторые ограничения CSS 1/2 иногда заставляют нас делать подобные вещи. В IE 4/5 для Windows можно создать подвижную разметку с комбинированными значениями фиксированной длины и процентов без необходимости использования вложенных элементов div. Мы не хотим сказать, что браузеры IE 4/5/Windows являлись образцами стандартов, но у их механизма обработки блочной модели были свои плюсы. Существует способ создания гибкой разметки в CSS, сочетающей процентные и фиксированные значения, без использования дополнительных div.

292

Глава 12, Блочная коцепь, ошибки браузеров ш ©бзспциые пути

Трюк заключается в том, чтобы создать только один div, использовать страницу в качестве другого элемента и осуществлять связь между ними посредством f l o a t . Так как невозможно подсчитать точные общие размеры, значения приходится подгонять и невозможно точно создать 100% от окна. Когда сайт журнала "A List Apart" был переведен с HTML-таблиц на разметку CSS в феврале 2001 года, потребовались интеллектуальные усилия трех дизайнеров, включая автора этой книги, чтобы додуматься до этого способа. Оригинальный табличный дизайн (рис. 12.6) состоял из разметки с двумя разделами, с подвижной областью содержимого и фиксированной областью навигации. Каждый из нас достиг примерно одинаковых результатов с помощью CSS (рис. 12.7), используя метод, описанный в предыдущем абзаце. Окончательная ширина разметки составляла приблизительно 100%.

Блочная модель и ее недостатки

293

Стоит отметить, что сегодня создать подобную разметку гораздо легче, так как можно воспользоваться примером A List Apart и других CSS-сайтов. Обратите внимание, что CSS 2.1 устраняет некоторые отмеченные проблемы, а предложения CSS3 должны устранить их все. На момент же написания данной книги браузеры в большинстве своем поддерживают CSS 1 и частично CSS 21. Неурядицы с блочной моделью до сих пор остаются камнем преткновения для желающих создать определенные типы разметок. В интервью 2002 года эксперт по DOM Питер-Пол Кох (Peter-Paul Koch) так высказался по данному вопросу: «По логике, блок или рамка объекта измеряется 1

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

294

SIB и ®йш$щьт пути

от границы до границы. Возьмите любую рамку или коробку. Положите в нее чтонибудь меньшее по размеру и попросите кого-либо измерить размер коробки. Вероятнее всего, что человек измерит размер от границы до границы, никто не станет судить о размере коробки по величине ее содержимого. Web-дизайнеры, использующие рамки для хранения контента, заботятся о видимой ширине рамки, о расстоянии от границы до границы. Границы, а не контент являются визуальными параметрами рамки для пользователей сайта. Никого не волнует размер контента», (http://www.netdiver.net/interviews/peterpaulkoch.php) Слишком сложные или нет, спецификации остаются спецификациями. Производителей браузеров просят не улучшить эти спецификации, а создавать продукты, корректно и полно поддерживающие их, и сейчас большинство производителей так и делают. Как же в таком случае мы можем создать разметку, одинаково хорошо работающую как в современных, так и в старых браузерах?

Трюки с блочной моделью Тантек Целик, которого мы уже упоминали в нашей книге, предоставил одно, ставшее достаточно популярным, решение данной проблемы. Его метод, основанный на использовании некорректной обработки блочной модели в IE 5.x/ Windows, заключается в присвоении ложного значения ширины и последующей его замене настоящим значением (рис. 12.8). В следующем примере, взятом с http://www.tantek.com/CSS/Examples/boxmodelhack.html, корректным значением области контента является 300 пикселей, но IE/Windows неправильно «понимает» его и вычитает из этого значения 100 пикселей за счет границ и внутреннего отступа. Ниже приведено некорректное CSS-правило, которое можно использовать для всех совместимых браузеров: div.boxtest { border: 20рх solid; padding: ЗОрх; background: #ffc;* width: ЗООрх; }

Браузеры, корректно обрабатывающие CSS, создадут рамку, общей шириной 400рх (20 + 30 + 300 + 30 + 20 = 400). Устаревшие же версии IE/Windows отнимут от ЗООрх величину внутренних отступов и границ, создав рамку шириной ЗООрх с шириной области контента в 200рх (300 - 20 - 30 - 30 - 20 = 200). Поэтому мы зададим значение 400рх (общую требуемую ширину) и затем «собьем с

295

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

296

Глава 12. Блотнаи модель, ®шм&кт браузеров и обходные щгш

Браузеры Opera (по крайней мере, Opera 7) представляют еще одну загвоздку - они понимают селекторы CSS 2 и правильно обрабатывают блочную модель, однако имеют такую же ошибку обработки CSS, как и IE/Windows. Поэтому они могут также использовать ложное значение ширины в данном случае. Тантек предлагает устранить эту проблему использованием дополнительного правила, специально для Opera: html>body .content { width:300px; }

Теперь уже Opera не сможет пропустить истинное значение, так как оно указано более явно, а в CSS более явные правила всегда имеют приоритет перед более общими (то есть #menu p имеет приоритет перед просто р). Начиная с момента появления (в 2000 году) этот метод используется Webдизайнерами на тысячах сайтов с разметкой CSS, предлагая устаревшим браузерам ложные значения, а современным - истинные. Обратите внимание, что использование этого метода не требуется, когда значения внутреннего отступа и границ равны нулю. В зависимости от дизайна, использование этого правила также необязательно, когда внутренние отступы невелики и вам хочется создать слегка неряшливый вид сайта. Метод Тантека. Этот метод (иногда называемый методом Тантека) использует ошибку анализа CSS для «обмана» устаревших версий IE/Windows, некорректно обрабатывающих блочную модель разметки. В этом и других способах обмана мы используем одни стандарты для поддержки других вместо устаревших приемов обнаружения версии браузера пользователя или разветвления кода. Мы просто скрываем от старых браузеров то, что они не могут обработать. Более подробные сведения о том, как скрыть некоторые элементы от различных браузеров, можно найти по адресу: http:// w3development.de/css/hide_cssj4}mjDrowsers/summary.

Дефектный пробел в IE/Windows Чтобы не загружать вас чрезмерным объемом теоретических сведений, давайте рассмотрим более простые вопросы с менее сложными решениями, а именно проблему возникновения символов пробела в IE/Windows. На рис. 12.9 мы видим, как неожиданно появившийся пробел может испортить смешанную разметку. Не меньший урон он нанесет и чистой CSS-разметке.

Дефектный пробен в IE/Windows

297

</td>

Почему это происходит? Этот дефект проявил себя еще в Netscape Navigator 3.0 (если не раньше). Когда компания Microsoft решила создать конкурентноспособный браузер, инженеры компании имитировали многие особенности Netscape, включая эту. На момент написания этой книги браузеры IE/Windows вплоть до Ш б продолжали воспроизводить этот старый дефект Netscape. Решение? Удалите пробелы, символы переноса строки и отступы из вашего кода.

298

Глава 12* Бявчиан модель,

ле гйути

Этот дефект может проявляться не только в смешанных разметках, но и в CSS. Обратите внимание на следующий список, взятый с сайта www.zeldman.com в январе 2003 года: <div

id="secondarynav">

299

Рис. 12.10. С помощью правил CSS можно создать из списка элементов кнопки навигации. Код списка не должен содержать пробелов для корректного отображения в IE/Windows (www.zeldman.com)

300

Глава 12. Блочная модель, ошибки браузеров и обходные пути

background:

#399;

#secondarynav li a:hover { font-weight: normal; border-left: 2px solid #9cc; border-right: 2px solid #9cc; background-color: #5aa; color: #fff; text-decoration: none; }

Подобный код и правила CSS мы будем использовать для нашего редизайна в главе 16. Дополнительные сведения об использовании CSS для превращения списка в графические элементы навигации можно найти в статье Марка Ньюхауза "CSS Design: Taming Lists" (http://www.alistapart.com/stories/taminglists).

Ошибка свойства float в IE 6/Windows

Ранее в этой главе мы объясняли, как с помощью CSS-свойства f l o a t можно разместить один элемент страницы рядом с другим. Например, приведенное ниже правило указывает, что d i v с идентификатором maintext будет расположен с левой стороны боковой панели или другого элемента, размещенного вдоль правой кромки страницы:

301

#maintext { float: left; }

Правда, в данном случае лучше позаботиться о том, чтобы текст в этом элементе был коротким, так как в IE 6/Windows есть ошибка, из-за которой браузер обрезает длинные фрагменты текста в плавающем элементе div, таким образом, посетитель не сможет прочесть текст до конца, так как полоса прокрутки исчезнет. Для того чтобы увидеть текст целиком, пользователю придется перезагрузить страницу или два раза нажать клавишу F11. Вряд ли найдется много посетителей Web-сайтов, знаюш,их об этой уловке. Конечно, этот дефект затрагивает лишь определенную (и мы надеемся небольшую) часть пользователей IE 6, однако это все равно что говорить о небольшой в процентном отношении части китайцев. Впервые дефект был обнаружен в 2001 году, когда IE 6/Windows находился в стадии бета-тестирования и инженеры Microsoft попытались устранить его. Однако во время выхода этой книги в печать в 2003 году ошибка все еще имела место. Возможно, инженеры Microsoft не смогли воссоздать дефект в лабораторных условиях и узнать причину его возникновения, однако независимое сообщество дизайнеров, похоже, обнаружило не только причину возникновения ошибки, но и способ ее устранения.

Ступор в старых значениях Похоже на то, что у IE б имеются проблемы с подсчетом высоты элементов блочного уровня. Эдди Траверса (Eddie Traversa) с http://dhtmlnirvana.com обнаружил, что IE 6/Windows сохраняет в кэше значения, которые он высчитывает на одной странице сайта, и затем неверно применяет их ко всем другим страницам. Например, если высота d i v m a i n t e x t на первой странице сайта составляет ЗООрх и 1400рх на следующей странице, IE 6 все равно отобразит элемент высотой лишь в 300 пикселей. Ручная перезагрузка каждой страницы устраняет эту ошибку, очищая кэш от старых значений, но лишь до тех пор, пока посетитель не перейдет к следующей странице и не столкнется вновь со старыми значениями и недоступным текстом.

Скрипт - решение проблемы Первым шагом на пути к устранению проблемы является признание ее наличия. Второй шаг - это определения точной природы ошибки. Третьим шагом программиста Аарона Будмана (Aaron Boodman) из Youngpup.net стало

302

ьт

Глава 12. Блочная модель, .

создание небольшой функции на JavaScript, которая в браузере IE/Windows корректирует имеющееся свойство плавающего блока, благодаря чему страница обновляется и отображается правильно. Вот созданный Аароном скрипт: if (document.all && window.attachEvent:) window.attachEvent("onload", fixWinlE); function fixWinlEO { if (document.body.scrollHeight< document.all.content.offsetHeight) { document.all.content.style.display =

'block 1 ;

Вы можете скопировать этот код с http://www.alistapart.com/tightmen.js и свободно использовать его. Эти несколько строк могут помочь вам создавать CSS-разметки с плавающими элементами без опасений их неправильного отображения. В вашей версии кода замените все упоминания . c o n t e n t на идентификатор вашего плавающего div. Например, если имя вашего плавающего элемента - m a i n t e x t , ваш код будет выглядеть так: if (document.all && window.attachEvent) window.attachEvent("onload", fixWinlE); function fixWinIE() { if (document.body.scrollHeight< document.all.maintext.offsetHeight) { 1 document.all.maintext.style.display = 'block ;

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

Flash и QuickTime: объекты преклонения Многие из нас вставляют объекты мультимедиа, например ролики Flash или QuickTime, в создаваемые сайты. Для этого пока еще нет единого стандарта, обеспечивающего работоспособность этих роликов на всех платформах. Для понимания этого процесса нам придется рассказать историю, сравнимую по накалу страстей с произведениями Шекспира или итальянскими операми.

303

Вложенные объекты: история о высокомерии и мести Когда создателей оригинальных версий браузеров Mosaic и Netscape посетила мысль о предоставлении дизайнерам возможности включать изображения в Webстраницы, они «расширили» HTML, создав тег <img> для своих браузеров. W3C не одобрил это, посоветовав использовать вместо данного тега элемент ob j ect. Спустя всего пару лет мы видим миллионы созданных сайтов, на которых тег <img> живет и процветает, тогда как элемент <obj ect> канул в небытие. Затем появился модуль FutureSplash (позднее переименованный во Flash) и другие мультимедийные элементы вроде видеороликов в формате Real и QuickTime. И вновь W3C рекомендовал использовать общий для всех мультимедиа-объектов тег <object> для использования таких элементов на странице. Вместо этого специалисты Netscape создали тег <embed>, и по мере появления на рынке конкурирующих браузеров эти браузеры также стали поддерживать этот элемент. По мнению Netscape и Microsoft, пользователи ожидали от Web-сайтов богатый набор мультимедийных функций, поэтому от производителей браузеров зависело то, как этого достигнуть и заодно увеличить свою долю на рынке. По мнению же W3C, производители браузеров создавали свои теги и игнорировали идеальные спецификации стандартов. Какой же тогда был смысл в создании удобных, открытых стандартов, если компании-участники W3C не нуждались в них? Спустя годы W3C сможет отыграться на тех, кто игнорировал предлагаемые стандарты. (Ну хорошо, может быть «отыграется» - это слегка преувеличено. W3C просто создаст логичные и разумные стандарты. Для производителей браузеров их поддержка стала просто необходимой.)

Двойная месть W 3 C Первым актом мести W3C было полное отсутствие упоминания тега <embed> в каком-либо стандарте HTML. Несмотря на то что сотни тысяч дизайнеров использовали тег на миллионах сайтов, <embed> не был включен в HTML 3.2. Не был он добавлен и в HTML 4 или HTML 4.01, целью создания которого было включение в стандарт тегов, оставленных за бортом HTML 4. А так как XHTML 1 был основан на HTML 4.01, тег <embed> не был включен и в XHTML. Таким образом, любой сайт, использующий тег <embed>, не может пройти проверку в анализаторах HTML или XHTML.

304

Глава 12» Визитная тадень, сшибки браузеров и обходные нуги

Все именно так, вы не ошиблись. Миллионы использующих мультимедиа сайтов не отвечают спецификациям W3C из-за элемента <embed>. Как будто еще не насладившись местью, W3C исключил тег <img> из первой редакции XHTML 2.O. Хотите изображений? Используйте <object>. Хотите QuickTime? Используйте <object>. Так говорит W3C. Проблема в том, что <ob j e c t > еле-еле поддерживают некоторые современные браузеры и абсолютно не воспринимают все старые. А дизайнеры не прекратят использовать Flash и другие мультимедиа-объекты лишь потому, что W3C возражает (уж простите нас) против используемых ими тегов. Даже если дизайнер уважает и использует Web-стандарты, но хочет использовать на сайте мультимедийные элементы, какой у него остается выбор?

Палка о двух концах: объекты мультимедиа при поддержке стандартов В ноябре 2002 года Дрю МакЛиллан (Drew McLellan) из Dreamweaverfever.com совместно с участниками Web Standards Project провел эксперимент. В статье для журнала "A List Apart" МакЛиллан подверг резкой критике «замусоренный» код, используемый во всем мире для взаимодействия Flash и контента Web-страниц, предложив вместо этого чистый, совместимый XHTML-код (http:// www.alistapart.com/stories/flashsatay). Он отказался от использования элемента <embed> и заменил подобный код в стиле IE: classid="clsid:D27CDB6E-AE6D-llcf-96B8-444553540000

на совместимый код вроде этого: type="application/x-shdckwave-flash"

HTML-код, создаваемый Flash при публикации ролика, обычно выглядит следующим образом: <object classid=nclsid:D27CDB6E-AE6D-llcf-96B8-444553540000я ' codebase=http://download.macromedia.com/pub/shockwave/cabs/flash/ 11 swf lash.cab#version=6 , 0 , 0 , 0 width="400" height = "3 00 id= "movie" align="> <param name="movie" value="movie.swf"> <embed src="movie.swf" quality="high" width="400" height="3 00" name="movie" align=" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"> </object">

Flash и QuickTime: объем?ы преклонения

305

Такой HTML-код является «замусоренным» и «раздутым», однако он работает во всех браузерах с установленным модулем Flash. МакЛиллан предложил заменить его компактным и логичным XHTML: <object type="application/x-shockwave-flash" data="movie,swf" width="400" height=- 3 00"> <param name="movie" value="movie.swf" ./> </object> Версия МакЛиллана является не только логичной, компактной и корректной, но и воспроизводит ролики Flash в браузерах Netscape и IE. Увы, эти ролики нельзя воспроизвести потоковым методом в IE/Windows из-за какого-то внутреннего дефекта. Конечно, это не является проблемой, если размер ваших роликов не превышает нескольких килобайт. Если же Flash-файлы имеют большой размер, это становится существенным недостатком. Дрю МакЛиллан предложил решение проблемы с потоковым видео в IE/ Windows - использовать маленькие ролики Flash для загрузки больших. Похоже, что был найден совместимый со стандартами способ использования мультимедиа на сайтах. После проверки способа МакЛиллана во всех имеющихся браузерах "A List Apart" опубликовал статью Дрю МакЛиллана.

Ложка дегтя: сбой объектов К несчастью, после публикации статьи обнаружилась другая проблема. Вместо вложенного Flash-объекта некоторые пользователи видели лишь пустую текстовую область (рис. 12.11-12.12). В основном этот дефект проявлялся в браузерах IE/Windows (5, 5.5 и 6 версии), хотя большинство пользователей IE/Windows видели Flash-содержимое без ошибок. Подобная проблема также встречалась и в браузерах Konqueror и Mozilla под Linux. Какое число пользователей пострадало от этой ошибки? Сотни? Тысячи? Миллионы? Как бы то ни было, форум (http://www.alistapart.com/stories/ flashsatay/discuss), посвященный этой теме, вскоре заполнился сообщениями о множестве ошибок. Согласно опубликованным сравнительным данным о моделях обработки объектов браузерами (http://www.student.oulu.fi/~sairwas/object-test/results), IE/Windows и другие браузеры, иногда неожиданно отказывающиеся воспроизводить ролики Flash, по идее должны «понимать» и корректно обрабатывать элемент <obj ect>. В IE/Windows подобная проблема наблюдается и при использовании < o b j e c t > для публикации изображения, согласно рекомендациям

306

Глава 12, Блочная модель, ошибки браузеров и обходные

Рис. 12.11. Способ Дрю МакЛиллана позволяет с помощью корректного кода использовать Flash на Web-страницах, однако в некоторых браузерах, даже с установленным модулем Flash (рис. 12.12), возникает ошибка (http://www.alistapart.com/stories/flashsatay)

XHTML 2. Способ Дрю МакЛиллана работает для большинства пользователей, однако этого может оказаться недостаточно. Так как <obj ect> должен работать и работает почти во всех браузерах в большинстве случаев, некоторые дизайнеры используют этот метод. Но для остальных необходимость использовать на сайте мультимедиа по-прежнему не совместима с Web-стандартами.

У л о в к а н а JavaScript: d o c u m e n t . w r i t e Пытаясь использовать Flash и добиться совместимости со спецификациями XHTML, некоторые дизайнеры прибегают к определению браузера пользователя посредством JavaScript и функции document . w r i t e для скрытия тегов <embed> от службы проверки W3C: <!— используется для создания корректного XHTML с тегом embed —> <script type="text/javascript"> //<![CDATA[ if (navigator.mimeTypes && navigator.mimeTypes["application/xshockwave-flash"]){

307

Рис. 12.12. Установлен модуль Flash 5, используется корректный код, но все равно Flash-объект не воспроизводится

document .write ( '<embed src=" /тес1л.а/вашролик£ lash, swf "... Такой прием работает: Flash отображается корректно во всех совместимых с JavaScript браузерах (если только пользователь сам не отключил JavaScript в браузере). Служба проверки кода W3C считает такой код совместимым. Однако, как мы уже отметили в начале этой главы, обман служб проверки не является самоцелью. Это не то же самое, что и совместимость со стандартами. В том случае (маловероятном), если ваш клиент или босс настаивает на совместимости со стандартами и использовании на сайте мультимедийных объектов, этот метод станет вашим спасением. Но мы рекомендуем вам быть честными с клиентами или начальниками и изложить им простым языком имеющуюся проблему и методы ее решения. Мы живем в мире, где блестящие идеи сталкиваются с суровой действительностью. Невозможность создать совместимый с XHTML сайт, используя вложенные объекты Flash или QuickTime, является относительно небольшой проблемой. По мере того как браузеры будут учиться лучше обрабатывать <object>, мы сможем безбоязненно использовать этот тег для вставки мультимедийного контента в наши прекрасные, совместимые со стандартами Web-сайты.

308

Глава 12. Блочная модель, ошибки браузеров и обходные пугтш

Повседневный мир обходных путей Подобные описанным выше обходные методы помогают претворять в жизнь стандарты, несмотря на несовершенство браузеров и то, что некоторые продукты еще менее совершенны. Таким образом, подобные обходные пути помогают нам повысить качество контента, дизайна и удобства использования наших сайтов. Однако не все одобряют подобные способы. Некоторые считают, что, если браузер не поддерживает полностью или корректно определенные спецификации W3C, это проблема пользователей этих браузеров, и в этом случае следует избегать использования данного стандарта. Такие взгляды обладают рядом недостатков, среди которых: • если ограничивать себя спецификациями, полностью и безошибочно поддерживаемыми всеми браузерами, вы не сможете создать ни одной Webстраницы. Даже HTML 3.2 поддерживается полностью и абсолютно корректно не всеми браузерами; • правильное понимание и внедрение стандартов требует времени, а в условиях рынка время не ждет. Испытывая давление, разработчики иногда вынуждены выпускать на рынок продукты, не отвечающие всем тонкостям стандартов. Иногда создатели сами знают о том, что их продукты содержат ошибки, как в случае с Netscape 6.0 и IE 6.O. Если мы не приемлем даже мысли об использовании обходных путей, посетители наших сайтов будут страдать от этого без нужды; • иногда сами стандарты бывают несколько неясными, и в некоторые стандарты вносятся изменения уже после их публикации. Например, CSS 2: CSS 2.1 был создан на базе CSS 2 в 2002 году, так как оригинальная версия содержала несколько абсурдных и неработающих идей; • большинству из нас приходится мириться с ошибками старых браузеров, особенно если они до сих пор остаются популярными и широко используются, как IE 5.x/Windows. Читатели, обеспокоенные тем, что, рекомендуя им использовать подобные обходные пути, мы вновь возвращаем их в сомнительное с точки зрения морали положение, должны помнить, что все эти способы являются абсолютно совместимыми со стандартами. Мы не используем запатентованные средства или «замусоренный» код. Мы используем стандарты для поддержки стандартов.

Повседневный тшр обходных щгш

309

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

ГЛ ЯМ 13. Оформление текста

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

Размер имеет значение В операционных системах Windows, Unix и Macintosh используются разные шрифты, разные разрешения экрана и разные стили прорисовки - от пиксельных до сглаженных (как в Mac OS 9) и таких гладких, что текст похож на используемый в Photoshop (как в Mac OS X Jaguar и в Windows XP с Cleartype). Поэтому старый тег <f ont size=3> означает разные вещи во всех этих операционных системах, оказывая влияние не только на размер, но и на внешний вид. К сожалению, большинство правил CSS установки размера шрифта также создают текст различных размеров на разных платформах, несмотря на все старания производителей браузеров сгладить или свести к нулю межплатформенные различия, используя стандартный размер шрифта по умолчанию.

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

Кошмары у €

ада

311

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

Кошмары устаревшего подхода Тим Бернерс-Ли (Tim Berners-Lee), изобретатель Web и основатель W3C, рассматривал свое детище как средство легкого обмена текстовыми документами, поэтому он не включил инструменты для управления текстом в язык HTML. Как описано в глаЪе 2, изначально дизайнеры использовали < t t > , <pre> и <blockquote>, а также семантически бессмысленные теги абзаца для управления шрифтами, размещения элементов и имитации отступов. Затем они начали использовать изображения в формате GIF или Flash-изображения текста - эта практика, кстати, сохранилась и по сей день (рис. 13.1), так как зачастую опытные дизайнеры не принимают ограничения CSS или XHTML. К 1995 году, в связи с буйным расцветом коммерческих сайтов, возникла острая необходимость ввести какие-то средства для управления текстом. Netscape представила миру тег <f ont>, атрибутом которого был размер текста. Можно было указать размер шрифта абсолютным (<f ont size=2>) или относительным значением исходя из размера шрифта пользователя по умолчанию (<font s i z e =+l>). Дизайнеры вскоре после этого перестали использовать теги абзацев и другие структурные элементы, используя для управления оформлением сайтов сочетание тегов <f ont size...> и <br>. Чтобы не остаться за бортом, компания Microsoft подарила нам <f ont- f ace...>.

312

Тш&аЧЗш Оформление текста

Рис. 13.1. Все «слова» на этой странице (http://www.evilnation.be) являются векторной графикой Flash, a не обычным текаом. Таким образом, текст на этой странице не доступен для поисковых систем, сайт не доступен для альтернативных устройств и его содержимое нельзя скопировать через буфер обмена

Большинство читателей этой книги, вероятно, помнят то время и наиболее распространенные тогда проблемы, а именно различия между платформами. В Windows по умолчанию использовался шрифт размером 16рх разрешением 96ppi (pixel per inch). В Macintosh - 12px и 72ppi. Таким образом, шрифты, хорошо выглядящие на одной платформе, оказывались слишком крупными или мелкими на других. «Глупый Windows», - скажет дизайнер для Мае. «Глупый Macintosh», - скажет дизайнер для Windows.

Различия во взглядах Затем появились первые версии CSS, например в IE 3, что лишь усилило межплатформенные различия. Пункты (pts) являются единицей печати, а не разрешения

Наконец стандартный размер - надолго ли?

313

экрана, однако дизайнеры знакомы с этим понятием и многие решили указывать размер шрифтов на своих сайтах в этих единицах. В мире Windows шрифт 7pt имеет высоту 9рх, что является минимальным различимым размером. В Mac 7pt это 7рх, что делает такой шрифт абсолютно нечитабельным и таким же полезным, как пятое колесо у телеги. В 1997 году Microsoft.com выбрал шрифт 7pt (рис. 13.2), чтобы доказать мощь CSS своего браузера IE 3 для Windows и Macintosh. Это все равно что пригласить людей на премьеру фильма и перед этим сбить фокус проектора. Шрифт текстов сайта был нечитаемым в IE 4.x и Netscape 4 на Macintosh не изза проблем браузера, а из-за различий между платформами. Тодд Фарнер опубликовал скриншот, приведенный на рис. 13.2, на своем персональном сайте, чтобы доказать, что pt являются неприемлемой для Web-дизайна единицей измерения размера шрифта. Фарнер также отметил, что размер текста, заданный в рх и pt (в то время), нельзя изменить с помощью встроенного в браузер средства регулирования размера шрифтов. Причиной этого было не то, что CSS 1 воспринимал pt и рх как фиксированные единицы. Это было просто следствием решения производителей браузеров, первыми начавших поддерживать CSS. Пользователь мог изменить размер шрифта, заданный в em или процентах, но дело в том, что IE 3, IE 4 и Netscape 4 обрабатывали заданный таким образом размер шрифтов с ужасными ошибками. В то время единственным корректно работающим на всех платформах способом указания размера шрифтов были пиксели, не позволяющие пользователям увеличить или уменьшить размер шрифта. Спустя пять лет единственной надежной единицей измерения остается пиксель, а заданный им текст по-прежнему не может быть увеличен или уменьшен в IE/Windows.

Наконец стандартный размер надолго ли? Пытаясь преодолеть разногласия между платформами, создатели браузеров Netscape, Microsoft и Mozilla в 1999 году решили стандартизировать параметры размера шрифта по умолчанию (16px/96ppi) на всех платформах. Поступив таким образом, производители браузеров и пользователи могли бы избежать проблем разных размеров шрифтов по умолчанию на разных платформах и предотвратить появление сайтов с нечитаемым текстом.

314

Глава 13. i

e текста

Стандарт размера шрифта I6px/96ppi. В рассылке W3C в 1998 году Тодд Фарнер предложил стандартизировать размер по умолчанию в I брх для использования в Windows. Его рекомендации были приняты всеми лидирующими производителями браузеров в 2 0 0 0 году. Хотя он исходил из чисто практических интересов (он хотел убедиться в том, что все тексты на сайтах читабельны), в следующей цитате он отмечает вопросы, которые могут удивить вас: «Еще до появления Mosaic размер шрифта по умолчанию во всех популярных браузерах был установлен на 12рх. Я предлагаю изменить этот стандарт на I брх, так как текущий размер в I 2рх отображается различно на разных платформах. На компьютерах Мае он отображается как I 2рх, на Wintel PC - как I брх. Все масштабируемые значения размера шрифтов оперируют этими различающимися значениями. Единственным выходом для дизайнера, который хочет обеспечить постоянный размер шрифтов, является использование пикселей, что не очень удобно для пользователей и межплатформенной совместимости... Подходящим способом решения этой проблемы является установка в браузерах Мае (и X I I ?) «среднего» размера шрифта по умолчанию I брх вместо I 2pt. Таким образом можно обеспечить более безопасное использование масштабируемых шрифтов». Если дизайнеры полагают, что I брх - это слишком много для основного размера, зачем предлагать это значение для принятия в качестве стандарта? Одной из причин является то, что Мае - менее распространенная платформа, впрочем довольно мощно представленная в мире Web-дизайна (например, у меня Мае). Было бы нереально предполагать, что браузеры Windows/X I l изменят свои стандарты по умолчанию, чтобы подстроиться под Мае. Дизайнерам же кажется, что 1 брх — это слишком много просто потому, что они привыкли к 1 2рх на своих Мае. Читаемость на 9 0 % зависит от знакомства с оформлением контента, (http://lists.w3.org/Archives/Public/www-style/1 998Dec/003O.html) Два годя спустя в первом поколении совместимых со стандартами браузеров использовались рекомендации Ф а р н е р а . Размером текста по умолчанию в Internet Explorer, Netscape и Mozilla, на платформах Windows и Macintosh стало 1 6 p x / 9 6 p p i . Усилия Фарнера не остались напрасными. W 3 C согласился с предлагаемым размером пикселя, тесно связанным с концепцией 1 6 p x / 9 6 p p i , как и оговорено в предварительном рабочем варианте CSS 2 . 1 . Из приведенной ниже выдержки вы поймете, что W 3 C все еще озабочен средней длиной руки пользователя: «Рекомендуется, чтобы стандартный пиксель был хорошо виден на устройствах с плотностью 9 6 d p i с расстояния вытянутой руки. Если принять 28 дюймов за размер руки, видимый угол, таким образом, составит около 0 , 0 2 1 3 градуса». (CSS2.1 Working Draft, http://www.w3.org/TR/CSS21 /syndata.html#length-units)

Наконец стандартный размер - надолго пи?

315

Рис. 13.2. Тодд Фарнер опубликовал этот скриншот на своем персональном сайте, чтобы доказать, что pt являются неприемлемой для Web-дизайна единицей измерения размера шрифта (http://style.cleverchimp.eom/f ont_size/point/f ont_wars.gif)

Теперь Netscape 6+, Mozilla, IE 5+/Macintosh и IE/Windows предлагали пользователям одинаковые параметры размера шрифта по умолчанию. Если пользователь не менял свойства шрифтов, пункты, em, проценты и ключевые слова размера шрифта работали одинаково на всех платформах. Еще оставались определенные проблемы наследования и внутренние ошибки некоторых браузеров, но основное препятствие было преодолено. Увы, производители браузеров не объясняют, почему они делают то, что делают, а пользователи не изучают вопросы дизайна. Все преимущества

316

. Гиава 13. Оформление текста

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

Хорошая работа загублена одним щелчком Некоторая часть пользователей Macintosh, недовольная размером шрифта, который показался им крупным и непривлекательным, вновь переключила размер текста в своих браузерах на 12px/72ppi, отклонив все преимущества стандартизации и поставив себя в положение, когда часть сайтов будет недоступна. В Сети всем заправляет пользователь, даже тогда, когда он не осознает, что такое хорошо и что такое плохо. Когда такие сторонники 12px/72ppi становятся Web-дизайнерами, они создают сайты, отлично смотрящиеся на Macintosh, но никуда не годные в доминирующем мире Windows. Многие Macintosh-дизайнеры используют 12px/72ppi, от чего страдают их работа и пользователи. Конечно, многие пользователи Windows также считают 1брх слишком крупным шрифтом и устанавливают размер шрифта в своих браузерах ниже нормы. В таком случае размер шрифта, заданный в пикселях, остается неизменным, тогда как шрифт, заданный в процентах, em или ключевых словах CSS может пострадать. В данной главе мы рассмотрим все эти дилеммы.

Забвение: неправильная реакция на изменения в браузерах Пользователи, меняющие размер шрифта на более мелкий, просто хотели сделать просмотр сайтов более удобным для себя. Они были не единственными, не понявшими суть стандартов, чего от них никто и не ждал. Многие Webпрофессионалы также упустили суть, отчасти из-за того, что ни Microsoft, ни Netscape не дали пояснений. В частности, дизайнеры, полагающие, что браузеры всегда будут значительно различаться между собой внешним видом и поведением, и использующие для борьбы с этими различиями разветвление кода и обнаружение версии браузера пользователя, быстро сделали то, что у них получается лучше всего. До 2000 года, вместо использования пикселей для отображения текста одинакового размера в любом браузере на любой платформе, эти разработчики применяли пункты. Так как пункты отображаются по-разному на разных платформах, эти дизайнеры стали создавать различные таблицы стилей для каждой платформы с разными размерами шрифтов.

Наконец стандартный размер - надолго ни?

317

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

Мы все заказываем обед с цыпленком. Отлично, два сэндвича и вегетарианский обед. Нет, мы все будем курицу. Секундочку (разговаривает с одним браузером). А вы, значит, будете мороженое с сэндвичем, так! Курицу, мы все хотим курицу! Любите мороженое? Конечно, а кто его не любит! Курицу!! И взбитые сливки! Отлично, вот ваш заказ!

Большинство разработчиков, создававших подобные кошмары, далеко не глупы. На самом деле зачастую они являются высококвалифицированными, опытными и высокооплачиваемыми профессионалами. Их клиенты платят деньги за сложные сайты, требующие постоянной поддержки и обслуживания по все возрастающим ценам. Звучит нелепо, но именно так обычно все и происходит. В конце концов бюджет иссяк и клиент остался с устаревшим, бесполезным сайтом. Пытаясь отсрочить неизбежное, некоторые дизайнеры помещают на своих сайтах объявление «Оптимизировано для...». Это все равно что поместить на пачке сигарет предупреждение о вреде курения и ожидать превращения пачки в коробку с витаминами. Мы можем предотвратить этот хаос, поняв, что браузеры поддерживают одинаковые стандарты и решение проблемы иногда бывает очень простым. (То есть использовать одну таблицу стилей для всех браузеров и не пользоваться пунктами.) Вам повезло, вы купили эту книгу, и не повезло тем, кто считает, что все браузеры до сих пор ведут себя по-разному, и «решить» эту проблему можно путем усложнения кода. А никакой проблемы нет.

318

Гиава 13. С

^теиста

Chimera и Safari: отличная производительность, проблемы с размером На момент публикации этой книги новые браузеры для Macintosh OS X, несмотря на многие положительные черты и радужные перспективы, к сожалению, ставят крест на плодах 2000 года в отношении стандартов размера шрифтов. Созданные на базе Gecko, браузеры Chimera (Navigator) и Safari от Apple находились в стадии бета-тестирования во время написания этой книги, но уже завоевали множество поклонников. Оба браузера предлагают мощную поддержку CSS и других стандартов. Chimera особенно примечателен тем, что он сочетает совместимость со стандартами Mozilla/Gecko с качеством отображения текста и расширенными пользовательскими возможностями OS X. Когда вы будете читать этот абзац, Chimera может сменить название на Camino1 по некоторым юридическим причинам. Мы же продолжим называть браузер Chimera, поскольку именно так он назывался во время выхода книги из печати. К сожалению, ни Chimera, ни Safari не используют в настоящее время по умолчанию размер шрифта 16рх. В обоих продуктах установлен размер 14рх, что не соответствует ни нынешнему стандарту, ни предустановкам Macintosh до 2000 года. Похоже, что производители идут на уступки пользователям Macintosh, предоставляя им шрифт меньше стандартного, но все же не слишком мелкий, чтобы он стал нечитаемым. Видимо, они просто решили, что подобный размер окажется самым подходящим. Возможно, это как раз то, чего хотят пользователи Macintosh, но это скользкая дорожка. С помощью панели настройки в обоих браузерах (рис. 13.3-13.4) довольно трудно переключиться на шрифт 1брх, так как в предустановках его нет и можно лишь ввести значение вручную. Конечно, некоторые пользователи изменяют предустановленный размер шрифта текста, однако лишь немногие делают это из соображений совместимости со стандартами. Таким образом, пользователи этих обоих браузеров для OS X, не изменившие установки шрифта по умолчанию, вновь могут столкнуться с непредсказуемыми размерами шрифта на Web-страницах.

Нестандартный размер шрифта и доступность На рис. 13.5-13.10 изображен сайт i3Forum, который мы создали в главах 8-10. Мы использовали em, чтобы предоставить пользователям возможность менять размер шрифта, даже в IE 6/Windows. Обратите внимание, что высота страницы 6 марта 2003 года браузер действительно был переименован в Camino. - Прим. науч. ред.

Наконец стандартна

пи?

319

Рис. 13.3. Браузер Chimera (Navigator) для OS X на базе Gecko предлагает мощную поддержку стандартов, но, к сожалению, не использует по умолчанию размер шрифта 1брх

Рис. 13.4. Обладающий на удивление отличной совместимостью со стандартами браузер Safari имеет тот же недостаток

различается от браузера к браузера, а в бесплатной версии Opera (рис. 13.8) имеется пустое вертикальное пространство, предназначенное для баннеров спонсоров. Несмотря на эти небольшие различия, мы видим, что размер текста одинаков в Netscape 7/Macintosh (рис. 13.5), IE 5/Macintosh (рис. 13.6), IE 6/Windows (рис. 13.7) и Opera 7/Windows (рис. 13.8). Это говорит нам о том, что можно спокойно отказаться от приемов определения браузера пользователя и создания различных стилей для разных платформ.

320

Глава 1 В» Оформление тешста

Рис. 13.5. Сайт i3Forum использует em для указания размера шрифта. Здесь мы видим сайт в Netscape 7 на платформе Macintosh (www.i3forum.com)

Вы также можете заметить, что текст в Chimera (рис. 13.9) и Safari (рис. 13.10) значительно мельче, чем в других брузерах. Некоторые пользователи этих браузеров могут оценить этот сайт как не слишком удобный для восприятия. Конечно, они могут легко увеличить размер текста с помощью утилиты Text Zoom, однако не все пользователи знают, как пользоваться Text Zoom, а некоторым это может показаться просто неудобным. Мы можем лишь надеяться, что блестящие команды разработчиков, создавших Chimera и Safari, одумаются и установят размер шрифта по умолчанию 16px/96ppi. Мы же указали размер текста в em, что является прекрасным решением, когда все браузеры поддерживают одинаковый, стандартный размер шрифта по умолчанию.

Веда с единицами ems

321

Беда с единицами ems Сторонники повышения доступности сайтов и создатели CSS давно согласились, что наиболее удобной единицей для установки размера шрифта является em. К сожалению, то, что хорошо в теории, не всегда остается таким привлекательным в реальной жизни. Использование em бывает затруднено, причем не только из-за бразуеров, не использующих стандартный размер шрифта по умолчанию. Одной из проблем являются старые браузеры. Netscape 4 игнорирует единицы em и ех, примененные к тексту, несмотря на то что он воспринимает эти

322

Глава 13. Оформление тенета

же единицы, когда они относятся к высоте строки. IE 3 обрабатывает em как пиксели. Таким образом, 2 е т он воспринимает как 2рх. Конечно, сейчас уже почти никто не пользуется IE 3, но тем не менее. Также старые браузеры зачастую плохо обрабатывают наследование вложенных элементов, размер которых указан в em. Так как число пользователей Netscape 4 все время снижается, мы не станем углубляться в обсуждение дефектов этого браузера. Просто имейте в виду, что если вы рассчитываете на аудиторию со старыми браузерами и используете em (в особенности для вложенных элементов), ничего хорошего из этого не выйдет (рис. 13.11).

Пользовательский выбор и е д и н и ц ы ems Еще одной распространенной проблемой с em является то, что пользователь зачастую уменьшает размер шрифта, используемого браузером. Пользователи Мае включают полюбившийся им 12px/72ppi, пользователи Windows выбирают в меню Размер шрифта значение мелкий вместо средний. Такие настройки

Беда с единицами ems

323

делают любой текст размером менее lem практически нечитаемым. В 2002 году эксперт по CSS/DHTML Оуэн Бриггс (Owen Broggs) протестировал все доступные способы указания размера текста во многих браузерах и платформах, чтобы выяснить, что работает, а что - нет. Сделав 246 скриншотов, несмотря на желание доказать работоспособность em, он пришел к совершенно обратному результату (см. рис. 13.11). Единицы ems хорошо работают до тех пор, пока вы не указываете размер текста меньше, чем пользовательский размер по умолчанию. Этот способ удобен, если пользователи не меняют настроек браузера. Однако большинству дизайнеров и многим пользователям нравится более мелкий текст, и в некоторых случаях это обязательное требование хорошего дизайна. Многие пользователи полагают, что 16рх является неудобным для чтения размером шрифта, и изменяют настройки согласно своему вкусу. Когда при дизайне сайта используются единицы ems, дизайнерские и пользовательские корректировки размера

324

Глава 1 3 . Оформление текста

текста в сторону его уменьшения накладываются друг на друга, что может привести к совершенно нечитаемому размеру текста. Когда вы задаете размер текста в ems или процентах, вы надеетесь на удачу в непредсказуемом мире пользовательских настроек. То, что выглядит элегантно на вашем мониторе, может стать нечитабельным на мониторе пользователя. Если же вы считаете, что таким образом повышаете доступность, это чистый самообман. На сайте i3Forum мы постарались оградить себя от возможных неприятностей, используя размер шрифта, лишь немногим меньший lem. В ином случае (http://www.alistapart.com/stories/dao) вы можете использовать заданный в ems шрифт нормального или крупного размера. Это поможет вам избежать проблем с доступностью, вызванных слишком мелким текстом. Однако лишь очень малая часть дизайнеров работает со шрифтами 1брх или более крупными. Кроме того, в этом случае вы можете получить жалобы от

Веда с единицами ems

325

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

326

Гиава 13. Оформление текста

высадка на Луну в 1969 году была фальсификацией. «Слишком много реальности - это не то, чего хотят люди», - сказал Вуди Аллен или Т.С. Элиот. Кто бы ни сказал это первым - он был прав. Так чего же хотят люди? Возможно, они хотят, чтобы мы использовали один из двух способов, описанных в оставшейся части этой главы. Оба они работают более надежно, чем описанные ранее способы, хотя и не лишены своих недостатков.

Пиксель Наряду с некоторыми другими элементами CSS, пиксель (рх) одинаково хорошо обрабатывается как в новых, так и в старых браузерах, в совместимых со стандартами и нет, и на любой платформе. 13рх - это 13рх и в Windows, и в Mac OS, и в Linux/Unix. Установите размер текста в пикселях, и он будет одинаковым в Gecko/Mac OS X (рис. 13.12), IE 6/Windows (рис. 13.13) и в Opera 7/Windows (рис. 13.14). Преимущества пикселей не сводятся лишь к тексту. Размеры изображений также задаются в пикселях. Если изображение на нашей странице имеет размер 200х200рх, а левый внешний отступ мы зададим равным ЮОрх, мы будем уверены, что отношение изображения к отступу будет равным 2 к 1 и что все пользователи увидят изображение именно в таком виде. В Happy Cog мы называем основанные на размерах соотношения пикселизмом (pixelism). Для четких разметок использование пикселей является само собой разумеющимся. Если мы скажем, что высота заголовка составляет 25рх, левый отступ ЮОрх, а высота шрифта основного текста - Прх, все пользователи увидят нашу страницу именно такой, хотя то, как они увидят ее на самом деле, будет зависеть от разрешения и размеров экрана их мониторов.

Самая маленькая единица: абсолютно относительная При разрешении 1200x870 1рх выглядит большим на мониторе с диагональю 22 дюйма и маленьким на 17-дюймовом мониторе. В CSS lpx считается относительной величиной, так как размеры и разрешения мониторов различаются между собой. Это справедливо, так же как и то, что Юрх в одном углу экрана это все равно что Юрх в другом углу экрана или Юрх на другом мониторе. Пиксель всегда является самой маленькой единицей размеров любого экрана. Следует отметить, что большинство дизайнеров и пользователей считают пиксель

Пиксель

327

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

328

Глава 13. Оформление текста

Пиксель и Opera Некоторые версии браузера Opera отображают размеры, указанные в пикселях, меньшими, чем они есть на самом деле. Например, если вы указали размер текста llpx, Opera 5 для Macintosh отобразит его равным Юрх. Хакам Ли (Hekon Lie) - старший инженер Opera. Он также является отцом технологии CSS, за что ему признательно большинство дизайнеров. А также говорят, что Хакам Ли выступает за то, чтобы в CSS пиксель считали абстрактной величиной, а не самой маленькой точкой на экране, как понимает его большинство из нас. За это мы, возможно, менее благодарны ему, но, к счастью, большинство производителей браузеров относятся к пикселю так же, как и мы с вами. Некоторые утверждали, что такой способ обращения с пикселем в Opera основан на абстракции «средней длины руки», а не является дефектом Opera для Macintosh, который производитель не торопится исправить. Возможно, эти интеллектуалы и правы, однако мы заметили, что Opera 7/Windows воспринимает пиксели так же, как и другие браузеры (рис. 13.14).

Пиксель

329

Рис. 13.14. ...а также и в Opera 7/Windows

Учитывая то, что Opera 7 теперь поддерживает переключение DOCTYPE, некоторые наши читатели могут спросить, обрабатывает ли Opera 7 пиксели, как другие браузеры, только в режиме «уловок», продолжая воспринимать их абстрактно в режиме стандартов. Эти читатели слишком усложнили вопрос. На рис. 13.14 мы видим, что Opera 7 воспринимает пиксели точно так же, как все мы: на скриншоте показана страница XHTML 1.0 Transitional с разметкой CSS. Таким образом, мы почти уверены в том, что теперь Opera воспринимает пиксели, так же как и все другие браузеры, несмотря на все теоретические расхождения во взглядах. Иными словами, когда вы задаете размер шрифта в пикселях, большинство пользователей Opera увидят его таким, каким вы задумали, лишь некоторые пользователи старых версий Opera могут увидеть его немного мельче.

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

330

Глава IS» С

^текста

пикселях. На некоторых платформах этот закаленный в боях браузер иногда забывает, как обрабатывать пиксели, так же как дедушка иногда забывает имена внуков. Не спрашивайте нас, о каких именно версиях идет речь. 4.73 для Linux/UNIX? Или 4.79 для Windows 98? Мы не знаем и не хотим знать, нам все равно. Большинство версий Netscape 4 интерпретируют это понятие корректно, даже если почти все остальное они делают не так. Этот дефект Netscape 4 не должен особо беспокоить вас, он всего лишь является внутренней ошибкой, которую пользователи могут преодолеть, заменив своего динозавра на что-то новое иди - лучше - на Netscape, выпущенный в этом веке. Некоторые пользователи не делают этого. Одним из них может оказаться ваш начальник или заказчик. Если с помощью ближайшего тяжелого предмета вам не удастся убедить их в преимуществах современных, совместимых браузеров, советуем вам начать поиски новой работы. (После применения ближайшего тяжелого предмета на своем начальнике вам все равно придется искать новую работ)7, о чем вы только думали?)

Неприятности с пикселями Неприятности, возникающие при использовании пикселей, уже обсуждались в этой книге и по большому счету сводятся к следующему: пользователи IE/ Windows не могут изменить размер текста, заданный в пикселях. Если вы установили размер основного текста на вашем сайте равным 9рх, большинство пользователей при обращении к нему нажмет кнопку Назад быстрее, чем вы успеете моргнуть. Даже Нрх может быть слишком мелко для некоторых пользователей, в зависимости от выбранного шрифта (llpx Verdana выглядит лучше, чем 1 lpx Times), размера экрана монитора и разрешения, остроты зрения посетителя, контраста между текстом и фоном и наличия/отсутствия отвлекающего фонового рисунка. Для пользователей со слабым зрением такой сайт может оказаться недоступным. Также на ваш сайт может наткнуться какой-нибудь инженер САПР, использующий для просмотра 32-дюймовый монитор с разрешением 4000x3000, или дизайнер, который будет ругать вас за использование слишком мелкого текста. Если бы он на самом деле хотел решить проблему, он бы мог использовать браузер с опцией Text Zoom или Page Zoom. Если же он предпочитает пользоваться IE/Windows, можно просто включить опцию игнорирования размера шрифтов (как это сделать, описано ниже). Он даже мог написать пользовательскую таблицу стилей, подобную этой: html, body {font-size:

lem; }

Пиксель

331

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

Ни один размер не подходит всем На момент отправки этой книги в печать опции технологии Text Zoom исполнилось три года. Text Zoom позволяет решить проблему с пикселями. Эта технология была изобретена инженерами Microsoft для платформы Мае. Вы думаете, что к настоящему моменту Text Zoom уже используется и в IE/Windows? Ошибаетесь. Мы все ратуем за это. Однако теперь мы уверены в том, что скорее мир сгорит в пламени апокалипсиса, чем Microsoft внедрит Text Zoom в IE/ Windows. Вместо этого IE/Windows предлагает (рис. 13.15-13.16) опцию игнорирования размеров шрифтов, указанных на Web-страницах. Эта опция спрятана в Свойства обозревателя »• Общие »* Оформление, и о ее существовании мало кто знает. Тем не менее она позволяет пользователям с ослабленным зрением или с высоким разрешением мониторов просматривать сайты с удовлетворяющим их размером шрифта. Или, по крайней мере, она позволяет пользователям, которые найдут ее, просматривать сайты с удовлетворяющим их размером шрифта. Опция хорошая, спору нет. Однако такой подход - «Все или ничего» - отличается от возможностей Text Zoom (имеющейся в IE 5+/Macintosh, Netscape, Mozilla, Chimera, Kmeleon и Safari начиная с версии Millennium) или Page Zoom (имеющейся в Opera с самой первой версии). При отключении размеров шрифта теряется общий семантический смысл, который сохранен при использовании опций Text Zoom или Page Zoom. Это не страшно, если дизайнер использовал структурный код, но в настоящее врсцм в Сети доминирует именно неструктурная разметка. Структура текста пропадает при отключении размеров текста. Text Zoom и Page Zoom сохраняют структуру и соотношение размеров текста. IE/Windows - хороший браузер, MSIE б - очень хороший. Но полное игнорирование размера шрифта не может стать полноцен; ной заменой пользовательских функций изменения размера текста. Учитывая текущее лидирующее положение IE/Windows и его нежелание предоставить пользователям возможность изменять размер шрифта, использование надежного на всех платформах пикселя может стать искушением для вас.

332

Глава 13. Оформление текста

Рис. 13.15. Опция отключения размера шрифта на Web-страницах запрятана глубоко в настройках IE/Windows

Рис. 13.16. Если пользователь найдет ее, нужно выбрать пункт Ignore font sizes specified on Web pages (Игнорировать размер шрифтов, указанный на Web-страницах)

А может, и нет, так как в главе 15 мы познакомимся со способом, позволяющим дизайнерам использовать эти единицы измерения без опасений создать трудности пользователям IE/Windows с ослабленным зрением.

Кптчтые снова размера шрифта

333

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

Ключевые слова размера шрифта Не все знают, и еще меньше число дизайнеров используют имеющиеся в CSS 1 (и CSS 2) ключевые слова для указания размера шрифта, лишенные абсолютизма пикселей или непостоянства ems и процентов. Ниже перечислены эти семь ключевых слов, значение которых будет понятно любому человеку, хоть один раз в жизни покупавшему футболку (http://www.w3.org/TR/CSS2/fonts.html#valuedef-absolute-size): хх-small x-small. small medium large x-large xx-large

Чем ключевые слова лучше ems или процентов Как отмечалось ранее, при использовании процентов или ems всегда есть шанс их увеличения, что может привести к слишком крупному или мелкому тексту. Ключевые слова не накладываются друг на друга даже при вложенных элементах. Если <body> использует small, <div> - small и <р> - small, a p находится внутри div, который находится внутри body, все три размера шрифта не накладываются друг на друга, в отличие от ems и процентов. В результате текст все равно будет отображаться как small, а не x-small или хх-small. . Кроме того, по крайней мере в Gecko и современных IE-браузерах, xx-small не может быть меньше 9рх, что означает, что текст не может быть нечитаемым. Конечно, некоторым пользователям может быть трудно читать такой текст, но тем не менее он все равно будет оставаться читабельным. Как и ems, ключевые слова используют пользовательские настройки размера шрифта по умолчанию. В отличие от ems, ключевые слова никогда не могут быть ниже порога читаемости. Если (маловероятно, но возможно) размер шрифта пользователя по умолчанию установлен на Юрх, x-small будет равен

334

Глава 13. Оформление текста

9рх, а хх-small - тоже 9рх. Очевидно, что в таком случае х-small и хх-small будут выглядеть одинаково. Но вы не потеряете часть пользователей» Звучит заманчиво, не так ли? Мы указываем размер шрифта и не думаем о невозможности его изменения пользователями IE/Windows и вероятности появления слишком мелкого текста, недоступного для чтения. Ключевые слова сочетают в себе доступность и необходимость управления шрифтами. Так в чем загвоздка? Как всегда, ключевое слово - браузеры.

Изначальная проблема с использованием ключевых слов Семь ключевых слов для указания размера шрифта были некорректно внедрены в первые браузеры, пытавшиеся поддерживать их. Хотя можно сказать, что они были применены корректно, но результат получился настолько плохой, что пришлось внести изменения в последующие версии стандарта CSS. Тогда как Netscape 4 полностью игнорировал ключевые слова, Netscape 4.5+ и IE 3 отображали текст нечитаемым. Например, Netscape 4.5 и IE 3 отображали текст, помеченный хх-small, на три-шесть пикселей меньше порога читаемости. В случае с Netscape разработчики просто следовали рекомендациям W3C, гласившим, что каждый следующий размер должен быть в 1,5 раза мельче или крупнее предыдущего. Если small был Юрх, medium должен быть равен 15рх, х-small тогда будет равен 6.6667px, а хх-small - даже не спрашивайте. Затем W3C заменил коэффициент 1,5 на 1,2.

К л ю ч е в ы е слова и IE/Windows Тем временем внедрение ключевых слов в IE 4/Windows, IE 5/Windows и IE 5.5/ Windows было некорректным по-своему. В этих браузерах ключевые слова не соответствовали своим значениям. Small являлся средним размером, medium крупным и так далее. Как же могла произойти такая путаница? Инженеры, трудившиеся над IE для Windows, старались все сделать правильно. Помните семь тегов шрифта <f ont size> браузера Netscape, упомянутые в начале этой главы? Ну конечно, вы помните: <font size~l>, <font size~4> и так далее. Разработчики IE привязали эти теги к семи ключевым словам. В определенной мере это был логичный шаг, они постарались не оставить за бортом дизайнеров, «съевших собаку» на работе с этим тегами Netscape.

Ключевые слеша рвзтг.

335

Проблема в том, что размеры не соответствуют ключевым словам. В старых браузерах < font s i z e=3 > это размер medium по умолчанию в пользовательских настройках. В расширенном HTML-коде Netscape <font size=3> используется по умолчанию. По логике, этот размер должен был соотнесен с ключевым CSSсловом medium. К сожалению, в IE/Windows < font s.ize=3> соотнесен с smal 1, а не с medium, так как small стоит под номером 3 в списке начиная снизу. В конце концов IE 5/Macintosh, Netsape 6+, Mozilla и IE 6 научились понимать ключевые слова корректно. Но к том)7 времени, когда это произошло, миллионы людей использовали IE 5 и Netscape 4, неправильно обрабатывающие ключевые слова. Если теперь дизайнеры использовали ключевые слова корректно, размер шрифта отображался по-разному в IE 4-IE 5/Windows и Netscape 4. Если дизайнер намеренно использовал ключевые слова неправильно, шрифт отображался правильно в IE4-IE 5/Windows, но неверно в других браузерах и более новых версиях IE. Что же оставалось дизайнеру? Большинство из нас пришло к выводу, что ключевые слова являются всего лишь еще одной неработающей функцией.

Ключевые слова: метод Фарнера И вновь решение было предложено Тоддом Фарнером, а его работоспособность обеспечила трюк с моделью Box, созданный Тантеком Целиком. Вы можете узнать детали и историю создания этого метода в статье "Size Matters", опубликованной в "A List Apart" (http://www.alistapart.com/stories/sizematters). Посмотреть вариацию Happy Cog на тему реализации метода Фарнера можно по адресу: http://www.happycog.com/thinking/colophon.html. Суть метода заключается в следующем: • скрыть стили от браузеров 4.0 с помощью директивы ©import (глава 9). Так как браузеры 4.0 не «понимают» ©import, они проигнорируют таблицу стилей, содержащую правила CSS, которые они не смогут обработать. Пусть пользователи браузеров 4.0 видят текст такого размера, который они сами выбрали. При необходимости для них можно создать внешний файл стилей со значениями в пикселях; • с помощью уловки Тантека Целика для обработки модели Box предложитее IE 5.x/Windows ложные ключевые слова размера шрифта, а современным браузерам - истинные значения; • добавьте более конкретное правило CSS, чтобы ограничить пользователей Opera от его специфичных проблем.

336

Глава 13. Оформление текста

Метод в действии Ниже приведен простой пример. Мы хотим, чтобы текст нашего абзаца был small (на один шаг меньше medium). Совместимые браузеры отобразят текст как подобает, a IE 5/Windows придется обхитрить. Если мы попросим IE показать нам текст х-small, он отобразит такой размер, который другие браузеры называют small. Вот правило: Р { • font-size: x-small; /*ложное значение для WinIE4/5 */ voice-family: " \ " } \ " " ; /*обман чтобы WinIE4/5 думал, что правило закончено*/ voice-family: inherit; /*восстановление положения после обмана*/ font-size: small; /*истинное значение для новых браузеров*/ }

Так же как и в главе 12, теперь мы добавим правило для Opera. Так как селекторы этого правила более конкретны, Opera отдаст приоритет им и не будет использовать ложное значение, предназначенное для IE 4-IE 5/Windows: html>p { font-size: small; >

Если мы поместим эти правила в импортированную таблицу стилей, Netscape 4 не заметит их и не будет «сбит с толку». Если необходимо применить один размер к нескольким селекторам, то это можно очень легко сделать. Чтобы узнать как, посмотрите таблицу стилей по адресу: http://www.happycog.eom/c/sophisto.ccs. Можете использовать этот файл для своих проектов.

Ложка дегтя в бочке меда Описанный выше прием работает неплохо, однако и ключевые слова также иногда страдают от проблем, характерных и для em: шрифт может получиться слишком мелким из-за пользовательских настроек. В особенности это касается все тех же трех моментов: • пользователи Windows, установившие размер шрифта в окне Вид - мелкий вместо средний; • пользователи Мае, установившие размер по умолчанию равным 12px/72ppi или любой другой менее 16рх;

Кишчевые снова размера шрифта

337

• пользователи новых браузеров вроде Chimera или Safari, отказавшихся поддерживать крупный и неказистый, но совместимый между разными платформами размер 16px/96ppi. В целом же ключевые слова в сочетании с ©import и методом Тантека Целика могут оградить пользователя от неприятностей, вызываемых использованием em, так как они гарантируют, что размер шрифта не будет меньше 9рх. Однако, если пользователь по умолчанию выбрал слишком мелкий шрифт, medium на его экране будет мелким, как и все остальные размеры меньше medium.

Удобный способ: поиски продолжаются Спустя многие годы после появления Web у дизайнеров до сих пор нет надежного способа указания размера шрифтов, отвечающего как потребностям пользователя иметь контроль над страницей, так и желанию дизайнера придать сайту надлежащий вид. Было бы гораздо проще, если бы Microsoft разрешила пользователям изменять размер шрифтов, указанный в пикселях, как в IE 5/Macintosh, Mozilla, Netscape, Kmeleon и Opera. Однако скорее у Моби (Moby - «король техно») отрастут волосы, чем Microsoft перенесет свое изобретение для Macintosh в браузер для Windows. Вся эта путаница не является проблемой стандартов. Увеличение размера текста выходит за пределы CSS или любого другого Web-стандарта. Нет стандарта или закона, гласящего, что пользователи должны иметь возможность масштабировать текст на Web-страницах. Конечно, это подсказывает здравый смысл, однако он не является стандартом. Этот вопрос - проблема не только для дизайнеров, придерживающихся стандартов. Те, кто даже не слышал о Web-стандартах, страдают даже сильнее, результаты их деятельности еще более печальные. Не стоит завидовать дизайнерам, работающим исключительно с Flash. Они также страдают от проблемы различных разрешений экранов и сталкиваются с более трудными задачами повышения доступности сайтов, чем большинство из нас. Даже возможность увеличивать Flash-содержимое не гарантирует преимущества, так как, когда Flash-контент находится во фреймах, их границы могут помешать рассмотреть увеличенные изображения. Так что же делать? Иногда можно использовать пиксели и с помощью DOM обойти ограничения IE/Windows. В других случаях можно использовать метод Фарнера и ключевые слова. Выбор всегда остается за вами.

Основы доступности

оступность и стандарты имеют много общего. Оба эти явления должны обеспечивать доступность и возможность использования наших сайтов как можно большим количеством пользователей, читателей и клиентов. Доступность настолько тесно связана с другими стандартами, обсуждаемыми в этой книге, что в девяностых годах прошлого века W3C запустил специальный проект Web Accessibility Initiative (WAI) для помощи дизайнерам в повышении доступности их сайтов (http://www.w3.org/WAI/GL). WAI разделяет доступность сайтов на три уровня: самый легкий (Priority 1), требующий немного больших усилий при создании сайтов (Priority 2) и мастерский уровень (Priority 3). Суть этих уровней в том, что доступность, как и совместимость со стандартами, является континуумом, а не подходом вроде «все или ничего». Даже если мы еще не готовы к переходу на разметку CSS, мы можем сделать сайт совместимым со стандартам, используя смешанную разметку. Так же и с доступностью. Даже те из нас, кто ранее не сталкивался с приемами повышения доступности, могут улучшить свои сайты и достичь уровня Priority 1. Таким образом, наши сайты станут доступны тем, кто ранее не мог пользоваться ими. Во многих странах есть законы, наказывающие за ограничения доступа граждан с ограниченными физическими возможностями, в том числе и к средствам коммуникации. Некоторые подобные законы соответствуют требованиям Priority 1. Другие могут сбить с толку даже членов WAI, потративших годы на изучение проблем доступности. Третьи запутаны, четвертые прямолинейно-практичны. Многие законы игнорируются даже их создателями. Неудивительно, что дизайнеры и разработчики также не имеют четких представлений о них. В этой главе мы рассмотрим этот вопрос, развеем некоторые мифы и познакомимся с приемами и средствам, позволяющими на самом деле повысить доступность ваших сайтов, а также узнаем об их недостатках.

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

О доступности в книгах Многие книги были посвящены проблеме доступности. Многие из них отталкивают дизайнеров непривлекательными, нереальными моделями доступных сайтов и не применимыми на практике советами, вроде «никогда не указывайте размер шрифтов». Некоторые подобные книги вообще враждебно настроены по отношению к дизайну. У авторов других нет опыта разработки коммерческих сайтов. После знакомства с такими книгами у дизайнера может сложиться довольно непривлекательное мнение о доступности. Другие книги написаны со знанием дела, PI В НИХ чувствуется истинная приверженность идеям доступности. Однако они могут не заинтересовать дизайнеров, так как в основном нацелены на пользователей с ограниченными физическими возможностями. Например, в них описываются альтернативные средства для просмотра сайтов и методы ввода информации. Дизайнеры без физических недостатков могут почувствовать себя не в своей тарелке при чтении таких книг. На самом деле страх всевозможных физических недостатков зачастую отталкивает дизайнеров от самой проблемы доступности, поэтому подобные книги мы бы не стали рекомендовать особо впечатлительным дизайнерам. Мы рекомендуем следующие издания: •

Джо Кларк. «Создание доступных Web-сайтов» ("Building Accessible Web Sites", Joe Clark, издательство New Riders, 2000 год). Эта книга является не только наиболее полным руководством по созданию доступных сайтов, но и одной из наиболее привлекательных книг по Web-дизайну в целом. Из этой книги вы не только узнаете все необходимое относительно доступности сайтов, но и получите удовольствие от ее прочтения. Web-доступность от А до Я - вот что ожидает вас в этой книге профессионала, проработавшего 20 лет в этой области. Вместе с автором книги вы отправитесь в путешествие по изучению доступности: от таких простых вещей как использование атрибута a l t до мультимедиа-объектов; • Сборник «Создаем доступные Web-сайты» ("Constructing Accessible Web Sites", издательство Glasshaus, 2000 год), составленный из работ нескольких

340

Глава 14. Основы доступности

авторов, среди которых Джим Тэтчер (Jim Thatcher), Шон Лэйтон Хэнри (Shawn Layton Henry), Пол Боман (Paul Bohman) и Майкл Беркс (Michael Burks), похож на конкурс лучших в своем жанре журнальных статей, каждая из которых посвящена детальному рассмотрению одного из вопросов доступности. Обе эти книги заслуживают места на полке у всех дизайнеров, разработчиков, владельцев или менеджеров сайтов. Среди прочего прочтение этих книг поможет избавиться от распространенных ошибок и заблуждений, некоторые из которых мы рассмотрим ниже.

Распространенные заблуждения Когда дело касается доступности сайтов, многие в целом здравомыслящие дизайнеры и разработчики не могут придумать ничего другого, как вспомнить несколько изречений на тему служения своим клиентам. Если познакомить их с актом U.S. Section 508, часто они впадают в состояние, которое можно охарактеризовать как умственное помешательство. Сразу вспоминается один уважаемый Web-дизайнер, читавший лекции для профессионалов в нескольких учреждениях и на вопрос о доступности несший подобную чепуху: «Мы создаем высокотехнологичные сайты для элитных посетителей, которые интересны нашему клиенту. Вся эта доступность - это лишь небольшая часть рынка и., кхм.. наш клиент не против потерять этих нескольких человек. В конце концов, наш клиент производит высококачественные широкоформатные телевизоры. Вряд ли слепые будут покупать их...» На самом деле слепые люди могли бы приобрести такой телевизор для видящих членов своей семьи или партнеров, если бы они имели возможность оформить заказ или ознакомиться с характеристиками продукта на Web-сайте продавца. Более того, большинство пользователей, нуждающихся в доступных сайтах, не являются полностью слепыми и даже близко к этому не стоят. Многие пользователи обладают просто ослабленным зрением или страдают дальтонизмом, близорукостью, и любой из них должен иметь возможность приобрести высококачественный телевизор с большим экраном.

Слепой миллиардер Кроме того, поисковые системы, по сути, являются слепыми пользователями. Поисковая система Google, к примеру, является крупнейшим слепым

Распространенные заблуждения

341

«пользователем» Сети, дающим рекомендации в виде результатов поиска миллионам зрячих пользователей каждый день. Иными словами, Google является слепым миллиардером. Какой владелец сайта откажет в доступе потенциальным клиентам, желающим потратить несколько миллиардов долларов? С другой точки зрения, число граждан с ограниченными физическими возможностями в USA примерно равно числу проживающих в Нью-Йорке и Лос-Анджелесе. Разумно ли отказывать в доступе такому числу потенциальных посетителей?

Доступность не ограничена лишь плохим зрением Однако не стоит связывать доступность лишь с плохо видящими пользователями. Частично или полностью парализованные люди также могут захотеть купить телевизор и могут предпочесть сделать это скорее через Web, чем идти в обычный магазин. Доступные сайты могут использоваться и полностью здоровыми покупателями, использующими Palm Pilot или мобильные телефоны для доступа к Web. Иными словами, дизайнер, разработчик или владелец сайта, считающий, что слепые не покупают наши товары, упускает суть проблемы и сам остается за бортом. Он сам становится слепым и не видит всей аудитории, которой он отказывает в доступе, включая миллионы физически здоровых людей, которые могли найти его сайт посредством поисковой системы, если бы он приложил усилия для повышения доступности сайта. К сожалению, многие люди не понимают истинного значения доступности и не осознают реального числа пользователей, которым она необходима.

Туманные идеи Нам приходилось сталкиваться с разнообразными заблуждениями дизайнеров и разработчиков по поводу доступности, например с такими: • «Слушай, я дизайнер, я создаю красивые сайты. Как я могу сделать красивый сайт для слепого пользователя?» (Ответ: все средства повышения доступности не влияют на визуальный дизайн. Они используются в коде незаметно. Твой сайт может чудесно выглядеть и быть полностью доступным - рис. 14.1); • «Это проблема клиента, если он не упомянул об этом - нам все равно», сказал главный разработчик одного из крупнейших и известнейших Web-агентств незадолго до банкротства фирмы, остатки которого были

342

fnaea 14, С

кти

куплены мелкой компанией из Центральной Азии. Кстати говоря, он ошибался, считая доступность заботой клиента; • «Section 508? Это для правительства, мы же не государственные служащие», - мнение еще одного агентства; • «Один из членов нашего управленческого совета отвечает за это, мы ожидаем публикации официального издания этого закона», - сказал нам представитель одной из государственных организаций спустя год после вступления в силу Section 508; • «Мы работаем в Dreamweaver, инструменты повышения доступности, наверное, появятся в обновленной версии, да?» - поинтересовался у нас один дизайнер. (И да, и нет. Dreamweaver MX уже обладает многими функциями для повышения доступности, но вы должны уметь использовать их.)

Рис. 14.1. Этот сайт (http://www.spazowhanri.com) полностью отвечает всем требованиям U.S. Section 508 к доступности. Разве можно это сказать по внешнему виду? Конечно, нет, и в этом весь смысл

Заке;

343

Закон и разметка Сумятица в умах относительно доступности уже была высока, когда появился акт Section 508. (Обратите внимание, мы пишем с точки зрения граждан США и приводим примеры из их жизни, однако эти же принципы существуют и в других странах, независимо от местного законодательства.) Section 508 требует от Web-сайтов быть доступными для граждан с физическими недостатками - от слабовидящих до людей с ограниченными двигательными возможностями. (Подсказка: добавления атрибута a l t может оказаться недостаточно.) Столкнувшись с такими требованиями, многие дизайнеры сразу представляют себе текстовые сайты или непривлекательные, простенькие Web-страницы. Это не так. Изображения, CSS, табличная разметка, JavaScript и другие элементы современного Web-дизайна полностью совместимы с требованиями Section 508; просто над ними придется слегка подольше поработать. В этой главе мы познакомимся с некоторыми требованиями Section 508 и опишем, как вы можете сделать свои сайты красивыми и одновременно доступными. Section

5O8

Section 508 (рис. 14.2) является частью Реабилитационного акта (Rehabilitation Act) 1973 года, созданного, чтобы положить конец дискриминации граждан с ограниченными физическими возможностями. Принятые Конгрессом США в августе 1998 года поправки к акту (http://www.usworkforce.org/wialaw.txt) значительно расширили статью 508, касающуюся требований доступности к технологическим продуктам. Этот закон относится к компьютерам, факсимильным аппаратам, копировальным устройствам, телефонным аппаратам, банкоматам, автоматическим киоскам и всем устройствам, связанным с передачей, приемом или хранением информации. Он также относится и ко многим Web-сайтам. Статья 508 стала законом 21 июня 2001 года. Она напрямую затрагивает федеральные учреждения и организации, а также Web-дизайнеров, создающих для них сайты. Закон также относится ко всем бюджетным организациям и может быть утвержден для использования любым штатом. Многие из них так и сделали. Короче говоря, Section 508 относится к: • федеральным учреждениям и организациям (включая почтовую службу США); • всем связанным с ними организациям и подрядчикам;

344

Глава 14, Основы доступности

• финансируемым или основанным федеральным правительством организациям; • организациям, финансируемым штатами, принявшими этот закон.

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

Разоблачение мифов доступности

345

использовать людям с ограниченными возможностями передвижения. Мигающие страницы или яркие Flash-заставки могут вызвать приступ у людей, страдающих эпилепсией. Список можно продолжить. Статья 508 не запрещает использовать CSS, JavaScript, изображения или табличную разметку. Закон также не препятствует использованию медиа-объектов вроде роликов QuickTime и Flash, если вы соблюдаете требования, описанные в данной главе. Вполне естественно, что наиболее совместимые с требованиями Section 508 сайты лучше работают и выглядят в новых браузерах, чем в старых. Это не противоречит закону, так как пользователи всегда могут загрузить и обновить свои браузеры, ведь наиболее популярные браузеры распространяются бесплатно. Соответствие требованиям доступности и совместимость с Web-стандартами не только сделает ваш сайт доступным миллионам пользователей с ограниченными физическими возможностями. Им также смогут пользоваться миллионы пользователей карманных компьютеров, сотовых телефонов, альтернативных браузеров, и при этом у вас будет больше посетителей с поисковых систем. Больше посетителей, больше читателей, больше пользователей, больше участников, больше клиентов. Звучит неплохо. Так почему же дизайнеры, разработчики и владельцы относятся к Section 508 со смущением или неприязнью? Причиной этого являются мифы и заблуждения, укоренившиеся в их сознании. Позвольте нам развеять некоторые из них.

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

Миф 1: для доступности вам необходимо создавать две версии сайта Неправда. Если вы создаете дизайн по Web-стандартам и следуете определенным требованиям, ваш сайт будет доступен пользователям программ для чтения с экрана, карманных компьютеров, Lynx и старых браузеров и в то же время отлично смотреться в современных программных продуктах. Стандарты и требования доступности сходятся в том, что один документ должен подходить всем пользователям и читателям.

346

Глава 14, Основы д

Если вы создаете сайт только в Macromedia Director/Shockwave, то лишь в этом случае для соответствия требованиям Section 508 вам потребуется создание двух разных версий. Если вы думаете о доступности - используйте Webстандарты, и вы убьете двух зайцев одним выстрелом, a Shockwave оставьте для более подходящего применения. Обратите внимание, что новая версия Macromedia Director позволяет создавать более доступные фалы Shockwave. Крупные разработчики программного обеспечения всегда помогают вам соответствовать времени.

Миф 2: текстовые версии отвечают требованиям доступности Неправда. Благодаря современным технологиям практически любое содержимое Web-страниц можно сделать полностью или частично доступным, без ущерба для внешнего вида. (Запомните: вся работа происходит в коде страницы.) Переадресация пользователей к текстовой версии сайта подразумевает, что дальтоники являются слепцами, а люди с ограниченными возможностями передвижения не могут наслаждаться изображениями? Также, видимо, эти пользователи не нуждаются в коммерческих сайтах или электронных магазинах и не должны принимать участия в Web-форумах? Иными словами, устаревший подход и создание текстовых версий сайта не поможет никому. Более того, создание и поддержка отдельной версии сайта предполагает большие затраты, чем простое добавление нескольких тегов и атрибутов к вашим Web-страницам.

М и ф 3: доступность слишком дорого стоит Неправда. Сколько стоит создать ссылку Пропустить навигацию, как описано в главе 8? Сколько стоит использование краткого описания изображения в атрибуте a l t ? Эти задачи можно выполнить за несколько минут. Даже если у ваших дизайнеров почасовая оплата, нужно брать миллион за час, чтобы добавление функций доступности, отвечающих требованиям WAI Priority 1 или Section 508, стоило дорого. Конечно, более сложные сайты с высокой доступностью потребуют больших затрат, чем эти простые функции. Например, значительно дороже обойдется создание сайта с видеороликами QuickTime или Flash, но это требуется далеко не всегда. Плюс, как мы уже сказали, доступность - это континуум, соответствие основным правилам стоит копейки. На крупных сайтах, контент которых обновляют не разработчики, а редакторы, повышение доступности страниц выполняется за счет простого добавления

Разоблачение мифов доступности

347

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

Мы слишком заняты крупными расходами, чтобы потратить пару долларов с умом У нас есть один друг, он всегда покупает компакт-диски, послушать которые у него нет времени, и фильмы на DVD, которые он не успевает посмотреть. Он снимает целую студию, если вдруг захочет порисовать, хотя до этого мог не прикасаться к кистям и краскам года два. Он платит за все имеющиеся каналы кабельного телевидения, хотя он никогда не смотрит ТВ, так как любит ходить по клубам. Единственной проблемой его захватывающей потребительской жизни является боль в нижнем левом зубе. Она беспокоит его уже два месяца, но он «не может позволить себе сходить к дантисту». Мировоззрение нашего друга не отличается от отношения к реальности многих компаний. Те, кто жалуется на высокую стоимость доступности сайтов (а также обычно и на высокую стоимость внедрения Web-стандартов), зачастую тратят тысячи долларов на создание системы определения версии браузера пользователя, бесполезные скрипты, условные CSS, и даже условный HTML, как описано в главе 13. Они ни о чем больше не думают, кроме того, как потратить побольше денег, создавая 10 различных таблиц стилей для 10 разных браузеров, которым можно угодить всего одним файлом CSS. Но, вместо того чтобы потратить пару долларов на повышение доступности, они заявляют: «Это стоит слишком дорого». В феврале 2003 года разработчики сайта MSN.com (рис. 14.3) додумались создать отдельный HTML-код и CSS для Opera 7, отличающийся от используемого для Opera 5 и 6. Улучшили ли эти дополнительные файлы внешний вид сайта в Opera 7? На самом деле они даже ухудшили его (http://deb.opera.com/ howcome/2003/2/msn). Стоит ли говорить, что сайт не был полностью доступным согласно проверке в текстовом браузере (рис. 14.4) и бесплатной службе анализа доступности сайтов Watchflre's Bobby (http://bobby.cast.org/bobby/ bobbyServlet?URL=http%3A//www.msn.com/&:gl:::::wcagl-aaa). Microsoft является не единственной компанией, которая тратит огромные суммы на устаревшие методы, повышающие стоимость обслуживания сайтов,

348 Г шва 14. Основы доступности

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

Разоблачение шифов

доступности

349

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

Миф 4: доступность заставляет создавать примитивные сайты с простым дизайном Неправда. Изображения, табличная разметка, CSS, JavaScript, серверные технологии вроде РНР и другие элементы современного Web-дизайна прекрасно совместимы с WAI Priority 1 и требованиями Section 508. Можно также использовать технологии вроде Flash или QuickTime, если вы придерживаетесь требований, предъявляемых к ним (они описаны далее в этой главе). Все сайты, созданные агентством Happy Cog за последние два года, используют DOM, CSS или смешанную разметку, изображения GIF или JPEG и так далее, и все они проходят проверку служб анализа кода на доступность без сучка и задоринки. Важно: успешное прохождение подобных проверок не гарантирует то, что ваш сайт полностью доступен и совместим. Программный продукт ограничен в своих возможностях, настоящую проверку сайта на доступность может провести лишь человек. С другой стороны, несоответствие требованиям WAI Priority 1 или Section 508 указывает на то, что ваш сайт нуждается в доработке.

Миф 5: все сайты должны выглядеть одинаково во всех браузерах и устройствах Неправда. Как это вообще возможно? Естественно, наиболее отвечающие требованиям Section 508 сайты будут лучше выглядеть в современных браузерах, чем в старых. Это не противоречит закону, так как пользователи всегда могут обновить свои браузеры. Содержимое сайта должно быть доступным пользователю Lynx и программ для чтения текста с экрана, карманных компьютеров и других устройств. Визуальный дизайн не может существовать во всех этих условиях, и сайт не обязан выглядеть одинаково в разных браузерах. Из-за устаревших приемов, используемых для достижения одинакового облика сайта во

350 Тштшш Iвсех браузерах и платформах, сегодня мы имеем так много недоступных, некорректных, сложных в обслуживании Web-сайтов.

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

Миф 7: Dreamweaver MX / Watchf ire's Bobby может решить вопрос доступности Неверно. Любые приложения могут помочь, но не заменить человека в данном вопросе. Служба проверки кода Watchfire's Bobby (рис. 14.5), Cynthia Says™ Portal (http://www.contentquality.com) или UsableNet's LIFT (http:// www.usablenet.com) могут помочь вам проверить сайт на соответствие требованиям WAI или Section 508. Элементы LIFT, представленные в Dreamweaver MX, могут также помочь вам проверить сайт и сделать его более доступным. Но все эти средства и инструменты не являются волшебной палочкой или просто кнопкой, нажав которую можно сделать доступный сайт. Они являются лишь вспомогательными средствами для дизайнеров, желающих повысить доступность своих сайтов.

Разоблачение ти \

351

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

352

Тмшв 14, Основы доступности

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

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

Изображения Игнорирование дизайнерами атрибута a l t приводит к тому, что пользователи текстовых браузеров, программ для чтения информации с экрана и других нетрадиционных устройств и браузеров видят на экране вместо изображений чтото вроде [IMAGE] [IMAGE] [IMAGE] [IMAGE]. Отсутствие в тегах атрибута a l t также будет считаться несоответствием требованиям WAI и ошибкой службы проверки кода XHTML. Используйте атрибут a l t для каждого изображения (http://www.w3.org/WAI/GL/WCAG20/checkpoints.html) для описания его предназначения.

Пустой атрибут a l t - ваш друг Для изображений, не имеющих смысловой нагрузки, например прозрачных GIF-отступов (если вы все еще применяете их), используйте a l t = " , также известный как n u l l a l t . He следует запутывать пользователя, придумывая описания для таких служебных изображений. Используйте пустой атрибут a l t для изображений, имеющих только визуальную (не семантическую) нагрузку.

Используйте атрибуты alt, и м е ю щ и е смысл д л я ваших посетителей Постарайтесь использовать атрибуты a l t , понятные посетителям вашего сайта, а не только вам и вашим коллегам. Например, для логотипа, который служит также ссылкой на главную страницу, используйте атрибут a l t = "Главная страница нашей компании", а не a l t ="our_company__logo__rev3 " или a l t = "Логотип нашей компании". Для пользователя с ослабленным зрением будет не очень интересно узнать о том, что изображение, которое он не видит, является логотипом. Информация о том, что, щелкнув по нему, он вернется на

Советы но повышению доступности, элемент за элементом

353

главную страницу сайта, полезнее. Если все же вам очень хочется указать, что это именно логотип, можно сделать так: alt="Главная страница нашей компании [логотип]" Постарайтесь не использовать приложения, создающие атрибуты a l t вместо вас. Скорее всего, вы получите бессмысленные атрибуты, созданные из имен файлов: а^="лого_нашей_компании_32х32" Иными словами, никогда не заставляйте робота делать работу человека.

Не доверяйте приложениям выполнение работы человека Не стоит полагать, что с вашими атрибутами a l t все в порядке лишь потому, что ваш сайт прошел проверку Bobby's WAI или тесты на соответствие требованиям Section 508. Эти тесты может пройти любая страница, все атрибуты a l t которой имеют значение "миккимаус" или являются пустыми. Ни одна программа не сможет определить, подходят ли ваши a l t к используемым изображениям.

Атрибут a l t создан не д л я к о н т е к с т н ы х п о д с к а з о к Некоторые популярные браузеры ошибочно отображают атрибут a l t как контекстную подсказку, когда пользователь наводит указатель мыши на изображение. Несмотря на то что миллионы пользователей уже привыкли к тому, что a l t - это контекстная подсказка, это не очень хорошо по нескольким причинам. Текст a l t предназначен для повышения доступности сайта и не является элементом его «украшения». (Для контекстных подсказок можно использовать атрибут t i t l e . ) Требования W3C четко указывают на то, что текст атрибута a l t должен быть виден, только когда изображения недоступны Атрибут a l t задает альтернативный текст в тех случаях, когда изображение невозможно отобразить. Пользовательские устройства должны отображать этот текст, если они не поддерживают изображения или некоторые типы изображений либо если в браузере отключена функция загрузки изображений (http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.2).. Ни один браузер не должен показывать текст a l t , описывающий то, что зрячий пользователь и так видит. Но IE/Windows, например, поступает именно так (рис. 14.6), а впервые это было замечено в Netscape для Windows. Конечно, это не является проблемой, если только вы не начнете создавать «творческие» тексты a l t , которые не смогут выполнять свою основную функцию - объяснение сути изображений людям, которые не могут их просмотреть.

354

Глава 14. Основы доступности

Рис. 14.6. На первый взгляд кажется, что логотип аукциона eBay является ссылкой на главную страницу сайта, однако это не так (www.ebay.com). IE/Windows отображает текст атрибута a l t при наведении мыши на рисунок

Не использовать a l t д л я фоновых и з о б р а ж е н и й Новички в повышении доступности сайта часто спрашивают, следует ли использовать атрибут a l t для фоновых изображений. Это логичный и разумный вопрос, на который есть простой ответ - нет. На самом деле даже при желании у вас бы не получилось это сделать. В CSS нет атрибута a l t . (Например, нет атрибута a l t для фонового изображения в теге <body>.) Если же фоновое изображение несет важный смысл, который не дублируется основным текстом страницы, например, если весь текст вашей Web-страницы состоит из фразы «Он был честным человеком», а в качестве фонового изображения CSS служит портрет А. Линкольна, можно попробовать включить текст «Президент А. Линкольн» внутрь атрибута t i t l e элемента body или t a b l e summary, если используются таблицы. Или же можно вставить описание в тег n o s c r i p t , предположив, что те, кто не может просматривать изображения, используют не поддерживающие JavaScript браузеры.

QuickTime и другие потоковые медиаобъекты На сайтах, для просмотра которых требуются дополнительные модули, используйте одну четкую ссылку на требуемый модуль. Еслидля ссылки на необходимый модуль вы используете изображение, убедитесь, что оно имеет соответствующий текст a l t .

mm i

доступности, элемент за элементом

355

Для повышения доступности видеороликов QuickTime (или Real) используйте средства для создания титров или Web-стандарты вроде SMIL. Дополнительные сведения по этому вопросу можно найти в статье "SMIL When You Play That" (http://www.alistapart.com/stories/smil). Вас может вдохновить на это посещение сайтов WGBH Boston ( h t t p : / / main.wgbh.org/wgbh/access) и BMW Films (http://BMWFilms.com). M a c r o m e d i a Flash 4/5 Macromedia Flash 4 и Flash 5 предлагают ограниченные возможности по повышению доступности, например звуковые сопровождения, описывающие назначения кнопок навигации. Если вы не можете обновить продукт до Flash MX, используйте эти функции и альтернативные HTML-возможности. А лучше используйте Flash MX. Macromedia

Flash

M X

Выпущенная в апреле 2002 года Macromedia Flash MX предлагает значительно расширенный набор функций для повышения доступности, включая совместимость с программами чтения информации с экрана. К сожалению, большинство этих функций работает только под Windows, так как Flash MX использует Microsoft Active Accessibility Программы для чтения информации с экрана иногда некорректно называют голосовыми браузерами, по сути же, они являются браузерами, читающими текст вслух. В настоящее время функции доступности Flash MX понимают два лидирующих в этом сегменте приложения для чтения с экрана. Это JAWS от Freedom Scientific (рис. 14.7) и Windows-Eyes от GW Micro ( h t t p : / / www.gwmicro.com/press/flash.htm). Flash MX отвечает некоторым требованиям Section 508, включая следующие: • • • • • • • •

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

356

Гяаза 14, Основы доступности

Во Flash MX метки табуляции задаются через ActionScript, Macromedia-версию ECMAScript. Но все эти функции не будут работать сами по себе, если вы не научитесь применять их. Дополнительные сведения по созданию доступных Flash-сайтов можно найти в 'A List Apart", №143, в статье, посвященной Flash MX (http:// www.alistapart.com/issues/143). Авторы статьи Джо Кларк (Joe Clark) и Эндрю Киркпатрик (Andrew Kirkpatrick) из CPB/WGBH National Center for Accessible Media поближе познакомят вас с этими функциями Flash MX, их возможностями и ограничениями.

Советы по повышению доступности, элемент за энементо^

357

Дополнительные советы по совместимости Flash При использовании дополнительных модулей создайте ссылку на источник получения плагинов. Если вы используете изображение в качестве ссылки на требуемый модуль, добавьте соответствующий текст a l t . Если вы используете JavaScript для определения наличия или отсутствия плагина Flash, имейте запасной вариант, например явную ссылку на модуль, для тех, кто не использует JavaScript. Также, если вы используете JavaScript для определения поддержки Flash, убедитесь, что вы знаете, как это делать. Поймите, что, несмотря на ваши упорные, самые искренние попытки, некоторые пользователи не смогут просмотреть ваш Flash-контент.

Цвет Если цвет на ваших страницах несет смысловую нагрузку (например, выделение возможности нажатия тех или иных элементов), подстрахуйте его другими элементами (например, полужирным или подчеркнутым шрифтом). Если вы отключили подчеркивание через CSS, сделайте шрифт ссылок более жирным, чем обычный. Если вы сделаете так, постарайтесь избежать выделения полужирным текста, не относящегося к ссылкам. Если же разница между обычным текстом и текстом ссылок очевидна (например, текст черный, а ссылки белые), то выделение ссылок полужирным шрифтом или какие-либо другие дополнительные способы можно не использовать. Постарайтесь избегать упоминания цветов в вашем тексте. «Щелкните по желтому полю для перехода к справке». Такой совет будет бесполезен для тех, кто не видит цветов. При использовании сочетаний цветов или комбинации различных оттенков постарайтесь учитывать, что некоторые отличия цветов могут быть не видны дальтоникам. Вы можете проверить, в каком виде предстают ваши страницы перед дальтониками, посетив сайт http://www.vischeck.com. CSS Проверьте, насколько читаемы ваши страницы с CSS и без. Не беспокойтесь об изменении внешнего вида сайта с отключенными стилями, если только они не сделали его нечитаемым.

358

Глава 14. Основы доступности

Структурный к о д сохраняет смысл при о т к л ю ч е н и и CSS Если вы создаете структурированный XHTML-код, ваш сайт будет выглядеть хорошо даже с отключенными стилями (рис. 14.8-14.9). Пользователи получат структурный код, так же как они получают его при включенной или выключенной функции игнорирования размера шрифтов Web-страниц в IE/Windows, что обсуждалось в главе 13. Как мы уже не раз отмечали в книге, делайте упор на структуре и старайтесь избегать ненужных div. Код, подобный приведенному ниже, станет бессмысленным при отключении CSS: <div <div <div <div

class="header">3aronoBOK</div> class="copy">TeKCT</div> class="copy">TeKCT</div> class="copy1I>TeKCT</div>

?€1упност.й, эпемент si

359

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

Внимательней работайте с размером шрифтов Не стоит полагать, что вы делаете все правильно, используя em вместо рх (см. главу 13). Постарайтесь избегать фиксированных, заданных в пикселях размеров шрифта (см. главу 13) или используйте переключатели стилей на базе DOM,

360

Глава 14» Основы доступности

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

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

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

Обеспечьте альтернативу для посетителей, не пользующихся мышью Некоторые пользователи с ограниченными физическими возможностями могут использовать браузеры с JavaScript, но не в состоянии работать с мышью. Позаботьтесь об альтернативном коде для них: <input type="button" onclick="setActiveStyleSheet('default•); return false;" onkeypress="setActiveStyleSheet('default')/return false;" />

В предыдущем примере onkeypress является эквивалентом o n c l i c k для пользователей без мыши. Две строки кода мирно сосуществуют друг с другом. Альтернативный код невидим для пользователей с мышью. Да, кодирование одной функции двумя способами добавит несколько байт к вашей странице, но в этом случае вы получаете дополнительных посетителей, хоть и с ограниченными возможностями, вместо того чтобы оставить их за бортом.

Применяйте noscript д л я тех, к т о не пользуется JavaScript В разделе ежедневных новостей на сайте zeldman.com под властью JavaScript элемент form используется для предоставления доступа к предыдущей странице. Ниже приведен фрагмент подобного кода. Обратите внимание, что и onkeypress и o n c l i c k используются для перемещения пользователя на предыдущую страницу: <form action="foo"xinput type="button" value="Previous Reports"

Советы по повышению доступности, элемент з

361

onclick="window.location='http://www.zeldman.com/daily/ 0103c.shtml';" onkeypress="window.location^'http:// www.zeldman.com/daily/0103c.shtml';• /> </form>

Такой код годится для пользователей, поддерживающих JavaScript браузеров, и для тех, кто не отключает JavaScript принципиально. Но как быть с теми, кто не может использовать JavaScript? Для них можно создать простую ссылку с элементом no s c r i p t : <noscript> < р х а href =" /daily/ОЮЗс . shtml" >Previous Reports</ax/p> </noscript>

Ниже приведен весь код: <form action="foo"><input type="button" value="Previous Reports" onelick="window.location='http://www.zeldman.com/daily/ 0103c.shtml';" onkeypress="window.location='http:// www.zeldman.com/daily/0103c.shtml';" onmouseover="window.status='Previous Daily Reports.';return true;" onmouseout="window.status^'';return true;" /> <noscript> <p class="vsl5 l f xa href =" /daily/ОЮЗс . shtml">Previous Reports</ ax/p> тупа тями, </noscript> такой ных» отключающих </form> ка ный Постарайтесь Избегайте или нейзапутанным, ченным Тем, мере, GoLive-скрипты, кпрограммист, посетителей, со код. Web кто JavaScript. сниженным проверяйте Однако, исовершенно пользователей, не сгенерированных поддержку особенно использовать он пользователей несмотря определяющие зрением, такие прост не когда JavaScript. знаком скрипты как имеющих сгенерированные на он пользователей дважды простоту, снапечатан. сплатформу ограниченными JavaScript, в разных скриптов совместимые два.этот Любой браузерах Но, и нетрадиционных этот приложения браузер код как код дизайнер физическими отвечает сскажет JavaScript сможет пользователя. включенным вроде вам запросам показаться может устройств браузеры, любой Dreamweaver возмржноснаписать и По выклю«обычопыткрайслегдосно

362

Глава 14. Основы доступности

Больше читайте Взаимодействие между скриптами и доступностью является гораздо более обширной темой и выходит за рамки данной главы. Дополнительная информация по работе с JavaScript содержится в статье "Working with JavaScript" на сайте Apple Internet Developer (http://developer.apple.com/internet/javascript), a также на Web-сайтах вроде webreference.com и scottandrew.com.

Формы В начале этой главы мы рекомендовали вам два издания. В книге "Building Accessible Web Sites" есть целая глава, посвященная всем за и против создания доступных форм. Авторы "Constructing Accessible Web Sites" также посвятили целую главу достоинствам и недостаткам создания доступных форм. Из этого странного совпадения вы можете заключить, что создание доступных форм является чем-то довольно важным, и будете правы. Однако не стоит паниковать. Большинство относящихся к этому вопросу задач решаются довольно просто и прямолинейно. Например, связь полей форм с соответствующими метками (например, связь поля Поиск с меткой Поиск). Просто есть множество мелких деталей, связанных с этим вопросом, обсуждение которых выходит за пределы этой главы. После создания доступных форм проверьте их в Lynx ( h t t p : / / lynx.browser.org) или в JAWS. Поклонникам Macintosh потребуется Virtual PC (http://www.connectix.com/products/vpc6m.html) или настоящий ПК с JAWS. Пользователям Linux понадобится бесплатная программа для чтения данных с экрана, включенная в дистрибутив SuSE Linux 7.0 (www://www.hicom.net/ -oedipus/vicug/SuSEJblinux.html) или можно загрузить Speakup ( h t t p : / / www.linux-speakup.org/speakup.html).

Карта изображений Старайтесь избегать использования карт изображений. При необходимости их применения добавляйте к изображениям описание a l t и дополнительные текстовые ссылки.

Табличная разметка Используйте краткие описания таблиц (как это сделать, указано в главе 8), используйте CSS вместо вложенных таблиц, прозрачных изображений GIF и другого подобного «мусора».

Сопутствующие средства

363

Вот и все. Несмотря на то что вы могли подумать, что использование простых табличных разметок противоречит принципам повышения доступности, это не так. Ни WAI, ни Section 508 не запрещают их использование. Если возможно использовать CSS-разметку - выберите ее, если нет - не стоит слишком сильно переживать.

Таблицы, используемые для данных Используйте смысловые заголовки таблиц и столбцов, а с помощью кода задайте связь между ячейками с данными и заголовками столбцов. Например, для таблицы со списком актеров шоу «Музыкант» заголовком таблицы может быть слово «Актер», а связанные с ним ячейки могут содержать такие записи, как Роберт Престон, Ширли Джоунс, Бадди Хакет и так далее. Зрячий пользователь, использующий графический браузер, легко увидит связь между заголовком «Актер» и столбцом ячеек под ним. Однако пользователям программ для считывания информации с экрана требуется наличие дополнительного кода, указывающего на связь между заголовком и ячейками. Открыв страницу http://www.w3.org/WAI/wcag-curric/sam45-0.htm, можно ознакомиться с информацией WAI об использовании связи между заголовками и относящимися к ним ячейками таблиц (рис. 14.10).

Фреймы, апплеты Нет, просто скажите «нет».

Мигающие или мерцающие элементы Просто откажитесь от их использования. Возможно, вы никогда и не использовали теги <blink> или <marquee>, однако имейте в виду, что запрет на мигающие и мерцающие элементы также относится к Flash или QuickTime контенту.

Сопутствующие средства . Если вы создаете Web-страницы с помощью визуальных редакторов, следующие средства и инструменты помогут вам сделать ваши сайты более совместимыми с требованиями доступности: • SSB Insight LE и GoLive: бесплатный модуль SSB Insight LE для Adobe GoLive автоматически идентифицирует многие (но не все) нарушения требований доступности (http://www.adobe.com/products/golive/ssb.html);

364

Глава 14. Основы доступности

UsableNet LIFT и Dreamweaver: как уже упоминалось ранее, продукт LIFT от UsableNet для Macromedia Dreamweaver 4 предлагает множество опций для повышения доступности ваших сайтов. LIFT автоматически находит многие (но опять же не все) нарушения, связанные с доступностью. Существуют также и самостоятельные отдельные версии LIFT, последние версии также учитывают рекомендации по удобству использования от Nielsen Norman Group (http://www.usablenet.com/lift_dw/lift_dw.html); Dreamweaver MX: многие опции LIFT были встроены в Dreamweaver MX, включая проверку на соответствие требованиям Статьи 508, справочника по Section 508 и средствам для повышения доступности изображений, таблиц и фреймов. Помните: ни одно приложение не может обнаружить все ошибки или предложить единственно верное решение. Как молоток и гвозди, эти средства лишь помогают тем, кто знает, как их использовать;

Работа с Bobby

365

Функция LIFT в Microsoft FrontPage: 9 июля 2002 года компания UsableNet объявила об интеграции LIFT в Microsoft FrontPage, популярный визуальный редактор: http://www.usablenet.com/frontend/onenews.go?news_id=45. Тем не менее полагаем, что LIFT не избавит FrontPage от создания нестандартного, запутанного кода, но, как и в Dreamweaver MX, пользователи FrontPage смогут проверить свои страницы на совместимость с правилами доступности и улучшить свои сайты с этой стороны.

Работа с Bobby Используете ли вы указанные выше продукты или создаете разметку и код вручную, вашей следующей остановкой должен стать Bobby Accessibility Validator: http://bobby.watchfire.coni/bobby/html/en/index.jsp. Одно нажатие на кнопку, и Bobby проверит любую страницу на соответствие требованиям доступности, хотя некоторые нюансы могут и ускользнуть от него. Чтобы быть абсолютно уверенным относительно доступности ваших страниц и их соответствия требованиям WAI и Section 508, рекомендуем проверять их вручную. В отличие от служб проверки разметки и CSS от W3C, Bobby не выдаст в качестве результата проверки безусловный и четкий список ошибок и отчет о состоянии «здоровья» страницы. Вместо этого вам придется интерпретировать отчеты Bobby.

Анализ отчета «Если перечисленные ниже пункты Section 508 не относятся к вашей странице, значит, она прошла проверку Bobby на соответствие Section 508», - заявляет бесплатная онлайн-версия Bobby (или более мощная отдельная версия, доступная для приобретения) после проверки вашей страницы. Bobby никогда не выдаст сообщение такого рода: «Все отлично, эта страница на 100% совместима с рекомендациями WAI Priority 1», или с Section 508, или с любыми другими стандартами. Bobby просто не может так сказать. Bobby - это всего лишь программное приложение, которое использует для своей работы алгоритмы, выявляющие наличие или отсутствие определенных ошибок. И, как мы уже отмечали, многие недостатки могут ускользнуть от машины. Мы не сможем рассказать вам обо всех возможных ситуациях, которые могут возникнуть при проверке вашего сайта на соответствие требованиям доступности, однако мы приведем один пример, который поможет вам понять, как

366 f тжш 14* Основы доступности

следует воспринимать и обрабатывать отчеты проверок Bobby. При проверке с помощью Bobby смешанная (таблицы плюс CSS) версия сайта zeldman.com прошла тест на совместимость с Section 508, но на самом деле все зависело-от интерпретации созданного Bobby отчета. В нем имелся следующий пункт: «Рассмотрите возможность использования логичных меток табуляции для элементов управления формами, ссылок и объектов».

Табуляция: наш хороший друг атрибут tabindex XHTML-атрибут t a b i n d e x указывает порядок навигации с помощью клавиши табуляции. Если этот порядок не задан, посетители, не пользующиеся мышью, будут перемещаться с помощью табуляции между ссылками в порядке их размещения в исходном коде XHTML. Это может быть не слишком удобно при наличии множества ссылок или обширной области навигации, расположенной в начале разметки. Как и ссылка Пропустить навигацию и accesskey (описанные в главе 8), t a b i n d e x позволяет пользователям программ для чтения информации с экрана избежать недостатков последовательной навигации и быстро перейти к интересующему их содержимому сайта. Тогда как ссылка Пропустить навигацию позволяет игнорировать длинный список ссылок, a accesskey позволяет использовать «горячие» клавиши (по крайней мере, теоретически), t a b i n d e x предназначен для создания ярлыков быстрого доступа к различным частям страницы. Это можно сравнить с главами фильма на DVD - когда зритель может сразу перейти к сцене погони или повторить просмотр заинтересовавшей сцены. На коммерческих сайтах после создания порядка табуляции можно проверить результат на настоящих пользователях. На персональных сайтах или сайтах некоммерческих организаций это нельзя себе позволить. В таком случае продумайте пользовательский сценарий и порядок табуляции, основанный на этом сценарии, и дождитесь откликов от ваших посетителей.

Введение в порядок табуляции На рис. 14.11 показана старая смешанная разметка сайта и отмечен порядок табуляции до того, как был использован атрибут t a b i n d e x . Когда пользователи нажимали клавишу Tab, они просто перемещались от одной ссылки к другой, в том порядке, в котором они располагались в коде. На рис. 14.12

Работа с Bobby

367

показан отредактированный порядок табуляции, созданный с помощью t a b i n d e x , когда каждое нажатие Tab перемещало пользователя туда, куда он, возможно, хотел перейти на самом деле. На рисунке приведены числа, указывающие порядок табуляции, на самом сайте они не видны.

Прежде чем мы обсудим применение t a b i n d e x в коде (что доступно даже новичку), давайте взглянем на выбранный нами порядок табуляции и узнаем, почему мы сделали его именно таким. Возможно, этот порядок не самый лучший из всех возможных, но он иллюстрирует мысленный процесс, с которым вы столкнетесь при создании порядка табуляции для своих сайтов. После того как мы образно поставили себя на место посетителя, не использующего мышь, и представили, какие ссылки ему будут интересны и в каком порядке, мы пришли к идее создания следующего порядка позиций табуляции:

368

Тпава i4» Основы доступности

Рис. 14.12. После применения t a b i n d e x пользователь стал перемещаться по сайту с помощью клавиши Tab в новом порядке

1. При первом нажатии клавиши Tab посетитель переходит к заголовку страницы и одновременно ссылке на главную страницу, чтобы у него была возможность обновить ее или вернуться к главной странице с любого места сайта. 2. При втором нажатии пользователь переходит к кнопке, позволяющей установить на сайте размер шрифта и таблицу стилей по умолчанию. Целью этой опции является предоставление пользователям возможности изменить размер шрифта или сам шрифт (или и то и другое) для повышения доступности сайта. 3. Третья позиция табуляции переносит посетителя к другой подобной кнопке, позволяющей выбрать более крупный шрифт пользователям с ослабленным зрением, пользователям Windows, установившим «мелкий» размер шрифта по умолчанию, и так далее.

Работа с Bobby

369

4. Четвертое нажатие соответствует полю для ввода текста формы поиска. Установив форму поиска здесь, мы позволили пользователям избежать многочисленного нажатия Tab для пролистывания множества ссылок, чтобы добраться до поиска по сайту. 5. Следующая позиция переносит пользователя к кнопке начала поиска. 6. Шестая позиция табуляции, оставшаяся за рамками скриншота, перемещает пользователя к ссылке Предыдущие статьи, которая находится внизу страницы. Эта ссылка позволяет посетителям загрузить предыдущие статьи в обратном хронологическом порядке. 7. Седьмая позиция табуляции, также не уместившаяся на скриншоте, перемещает пользователей к кнопке К началу страницы, что позволяет им не пользоваться прокруткой. Особенно удобно это для тех, кто не пользуется мышью. После путешествия по этим семи отметкам табуляция возвращается к нормальному порядку, позволяя пользователю пройтись по всем имеющимся на странице ссылкам в порядке их нахождения в коде.

Создание и проверка Изменить порядок табуляции было легко. Мы просто присвоили значение t a b i n d e x всем необходимым элементам. Ниже приведен примерный фрагмент XHTML-кода кнопки установки размера шрифта по умолчанию перед применением t a b i n d e x : <form action="send"> <input type="button" /> </form> А здесь этот же фрагмент после внесения изменений: <form action="send"> <input type="button" tabindex="2" /> </form> Следующий нужный элемент следует пометить t a b i n d e x = " 3 " , затем tabindex=" 4" и так далее. Намного легче квантовой физики. После добавления этих атрибутов мы дважды меняли дизайн сайта zeldman.com, используя разметку CSS и структурный XHTML. Тем не менее вы по-прежнему можете наблюдать этот порядок табуляции и просмотреть исходный код на http://www.zeldman.com/daily/1002a.html. L.

370

Глава 14, Основы доступности

Большинство других приемов для повышения доступности так же легко понять и использовать. Типичные советы, которые может дать вам Bobby, - это добавление ярлыков для элементов и проверка страницы на доступность и читаемость при отключенных таблицах стилей. По мере вашего более близкого знакомства с правилами доступности вам потребуется все меньше советов, а по мере использования этих приемов Bobby будет предлагать вам все меньше подсказок. К сожалению, Bobby часто предлагает неверные советы. Например, если ваш сайт использует таблицы только для разметки, Bobby отреагирует на присутствие таблиц таким комментарием: «Если это таблица с данными (используемая не только для разметки), укажите заголовки для столбцов и строк таблицы». Таким комментарием Bobby отзывается на проверку любого сайта: «Если вы используете цвет для передачи некоторой информации, убедитесь, что она представлена и другим способом». Подобное поведение может несколько раздражать, поэтому многие эксперты предпочитают полагаться только на себя при проверке сайтов на доступность и не использовать Bobby или другие подобные средства. Но для тех из нас, кто не считает себя экспертом в данной области, Bobby может стать хорошим помощником, если не обращать внимания на его причуды. Средство проверки доступности сайтов Cynthia Says, появившееся во время работы над этой книгой (http://www.contentquality.com), предоставляет более широкий спектр тестов, чем Bobby, и, возможно, с ним будет более приятно работать. Не забывая поговорку о том, что повторение благотворно влияет на учение, мы хотим завершить эту главу еще раз, напомнив, что, даже успешно пройдя проверку Bobby, ваш сайт может оставаться недоступным. Не обращайте внимания на некорректные пункты отчета, но внимательно изучайте полезные советы.

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

Планирование доступное?1

|Ы

371

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

Доступность у вас на службе Предчувствуя внезапно выросший интерес к доступности среди владельцев сайтов, хотим предостеречь вас, что боязнь судебных исков не должна являтся основной причиной для повышения доступности сайтов. Модернизация сайта делает его доступным для многих новых пользователей, а какой сайт откажется от увеличения числа посетителей? Эти группы пользователей, которым было отказано в доступе к другим сайтам, будут признательны вам за внесение этих изменений в код сайта. Если другие электронные магазины недоступны пользователям с ограниченными возможностями или владельцам нетрадиционных средств доступа к Web, а ваш сайт выгодно отличается от других, догадайтесь, кто будет продавать свои товары этим пользователям? Не забывайте, что чем более доступным является ваш сайт для пользователей нетрадиционных устройств или граждан с ограниченными физическими возможностями, тем более доступен он и Google, AlltheWeb и другим поисковым системам, направляющим пользователей по вашему адресу. И наоборот, чем меньше доступен ваш сайт, тем меньше посетителей с Goggle и подобных систем он привлечет. A List Apart, zeldman.com и большинство других сайтов, созданных агентством Happy Cog за последние несколько лет, занимают высокие позиции в рейтингах поисковых систем не потому, что мы прибегаем к каким-то фокусам, а потому, что они сделаны доступными, со структурным кодом. Повышение доступности сайтов поможет вам глубже вникнуть в само понятие «дизайн». Использование таких приемов, как установка порядка табуляции, поможет вам расширить восприятие дизайна как простого украшения интерфейса сайта, вь! задумаетесь об обратной связи с посетителями и удобстве

372

Глава 14, Основы доступности

использования. Доступность является лишь одним аспектом понимания того, как создавать сайты, отвечающие потребностям пользователей. Кроме того, повышение доступности сайтов может повысить ваши навыки разработчика и позволит вам взглянуть на дизайн с нового ракурса. Изучение WAI, Section 508 и любых других требований по доступности повысит вашу ценность как грамотного дизайнера, поможет вам создать более привлекательный образ вашего Web-агентства и сделает ваши сайты доступными большему кругу пользователей. Разве не этого желает каждый владелец сайта и не к этому стремится каждый Web-дизайнер? Изучение и использование приемов повышения доступности поможет вашим посетителям достичь своих целей, а вам ваших.

Г л а м 1 1 . Работа со скриптами на основе DOM

начале компания Netscape создала JavaScript, и это было хорошо. Затем Microsoft представила JScript, отличавшийся от JavaScript. В битве сошлись две «армии», которых грозилось поглотить пламя DHTML. Спасение же пришло при появлении стандарта Document Object Model (DOM), первая редакция которого называлась DOM Level 1 (http://www.w3.org/TR/ 1998/REC-DOM-Level-l-19981001). И это без сомнений было очень хорошо. В этой главе мы познакомимся с объектной моделью документа от W3C и узнаем о том, как использовать его в работе, например, для отображения или скрытия контента в ответ на действия пользователя, настройки внешнего вида и доступности, создания динамических меню. Обещаем, что это совсем не сложно. •

Знакомство с DOM Так что же такое модель DOM? Согласно World Wide Web Consortium (http:// www.w3.org/DOM), DOM является независимым от браузера, платформы или языка интерфейсом, позволяющим программам и скриптам динамически обращаться к содержимому страницы и обновлять контент, структуру и стили документов. Затем документ может быть обработан и результаты этой обработки включены в имеющуюся страницу. Иными словами, DOM позволяет манипулировать стандартными компонентами ваших страниц (таблицами стилей, элементами кода и скриптами). Если сравнить Web-страницу с фильмом, XHTML был бы сценаристом, CSS - художником-постановщиком, скрипты отвечали бы за спецэффекты, а модель DOM была бы режиссером, руководящим всем процессом. Дополнительным преимуществом является то, что методология DOM не нагружает канал связи, поскольку деятельность скриптов на базе DOM происходит на стороне клиента, то есть в оперативной памяти компьютера посетителя. Эта технология остается работоспособной даже при завершении соединения с Internet.

374

Глава 1S, Работа со скриптами на основе DOM

Стандартный способ заставить Web-страницывестисебякакприложения Хотя этот вопрос и выходит за рамки нашей книги, отметим, что наиболее впечатляющим результатом использования динамической модели является возможность заставить Web-страницы вести себя как полноценные приложения. Например, посетитель может изменить порядок сортировки табличных данных, щелкнув по заголовку, точно так же как в MS Excel или в Macintosh Finder (приложении для Macintosh, позволяющем пользователям сортировать, копировать, перемещать, переименовывать, удалять и осуществлять другие операции над файлами и каталогами в их компьютерах), - рис. 15.1-15.3.

Рис. 15.1. В этом примере данные сортируются по названию альбома, когда пользователь щелкает по заголовку «Album» (http://glendinning.org/webbuilder/sortTable)

Рис. 15.2. Еще раз щелкнув по заголовку, можно изменить порядок сортировки. Новая таблица немедленно отображается, для этого не требуется отдельной страницы с результатами

Знакомство с

375

Рис. 15.3. Щелкнув по заголовку «Rank», можно вновь изменить вид таблицы, отсортировав записи по номеру. Вы можете просмотреть или загрузить другие демонстрационные примеры DOM с адреса http://glendinning.org/webbuilder

На обычных Web-страницах подобные действия требуют применения модели клиент/сервер, скриптов и загрузки новой HTML-страницы с результатами каждый раз после изменения порядка сортировки. Благодаря DOM такие операции можно провести независимо от наличия соединения с сервером. Спустя годы после загрузки страницы, показанной на рис. 15.1-15.3, имеющиеся на ней данные можно сортировать без необходимости соединения с сервером. Точно так же можно удалить из корзины список потенциальных покупок без уведомления сервера, пока пользователь не захочет купить что-то еще или осуществить поиск других продуктов. Можно предоставить возможность перевода текста страницы с одного языка на другой с помощью одного щелчка мыши (рис. 15.4-15.6). Скрипт на основе DOM изменяет данные в ответ на определенные действия пользователя. Это возможно благодаря тому, что все стандартные элементы Web-страницы доступны ему в любой поддерживающей объектную модель документа пользовательской среде. Иначе говоря, DOM позволяет манипулировать стандартными элементами страницы таким же образом, как ActionScript управляет компонентами Flash. Несмотря на скромность этих примеров, потенциал их использования безграничен. В течение многих лет дизайнеры, желающие создать выдающиеся сайты, использовали Flash или Java. Конечно, и сейчас эти средства остаются одним из вариантов, но по мере роста поддержки DOM браузерами у разработчиков появилась возможность создавать сложные и мощные Web-приложения, созданные полностью на стандартах, описанных в этой книге. В этой главе мы познакомимся с простыми задачами, решаемыми объектной моделью, отвечающими всем нуждам коммерческих или информационных

376 Г пава 15. Работа со скриптами на основе BQM

сайтов. Но похоже, что за DOM в сочетании с XML, XHTML, CSS и ECMAScript будущее Всемирной паутины.

Рис. 15.4. В этом примере от Дэвида Эйзенберга (David Eisenberg) перевод текста с испанского на английский осуществляется одним щелчком мыши (http://www.alistapart.com/stories/domtricks3)

Рис. 15.5. Знакомые с испанским языком пользователи могут увидеть перевод только непонятных слов или фраз

РИС. 15.6. Те, кто не говорит на испанском языке, могут увидеть полный перевод. Все операции происходят в браузере пользователя и не требуют соединения с сервером

Знакомств® с ПОМ

377

Где это работает С небольшими различиями W3C DOM поддерживается следующими браузерами: • • • • • •

Netscape 6 и последующими версиями; Mozilla 0.9 и последующими версиями; Chimera/Navigator начиная с версии 0.6; IE 5/Windows и более новыми версиями; IE 5/Macintosh и последующими версиями; Opera 7 (с определенной натяжкой можно сказать, что и все предыдущие версии браузера вплоть до Opera 4 поддерживают DOM, но не полностью. К счастью, большинство пользователей Opera часто обновляют свой браузер); • Kmeleon (но некоторые элементы отсутствуют); • Safari (браузер создан на базе Kmeleon, поэтому некоторые элементы объектной модели отсутствуют); • Konqueror (с некоторыми исключениями).

Несовместимая с D O M среда Какие браузеры не вошли в этот список? IE 4 (для Macintosh и Windows), но почти никто уже не использует IE 4. Браузер iCab, описанный в главе 8, также не вошел в список, что не является большой проблемой. Дело в том, что iCab даже не поддерживает интерактивные элементы на базе патентованных технологий, использующихся практически на всех сайтах. Также в списке нет и Netscape 4. Для некоторых это может стать непреодолимой преградой на пути к использованию DOM. Тем не менее через несколько страниц мы познакомим вас с простым приемом, позволяющим предложить альтернативный код пользователям Netscape 4 или любых других браузеров, совместимых с JavaScript, но не понимающих DOM. Что еще отсутствует в списке? Карманные компьютеры и мобильные телефоны пока также не «понимают» DOM, а текстовые браузеры вроде Lynx никогда не смогут этого сделать. Во многих случаях для этих пользователей можно компенсировать невозможность использования DOM, так же как вы делаете это для несовместимой с JavaScript среды. Для поддержки таких устройств выполняйте следующие действия: • используйте элементы < n o s c r i p t > , обеспечивающие альтернативный доступ (например, гипертекстовая ссылка вместо графической кнопки); • проверяйте сайты в Lynx, как описано в главе 14;

378

Глава 1

• используйте ссылки с действием r e t u r n f a l s e вместо ведущих в никуда «ссылок» j a v a s c r i p t : , например <а href =" j a v a s c r i p t : "...>. Ниже приведен фрагмент кода с сайта zeldman.com, активирующий переключатель стилей. Он начинается с простой ссылки (/about/switch/), а переключатель по событию o n c l i c k заканчивается r e t u r n f a l s e : <а href="/about/switch/" onclick="setActiveStyleSheet('default'); return false;" onkeypress="setActiveStyleSheet('default'); return false;" accesskey="w"> <img src="/i/file.gif" width="25" height="16"alt="Default style (white)." Title="Default style (white)." /> Поддерживающие объектную модель браузеры проигнорируют ссылку и запустят функцию по событию o n c l i c k . Несовместимые с DOM и JavaScript браузеры перейдут по ссылке к указанной странице (рис. 15.7), на которой объяснен принцип действия переключателей. (Среди других использованных на странице элементов есть наши старые друзья accesskey и onkeypress, призванные повысить доступность страницы.)

Проклятье полусовместимости Гораздо большие проблемы у вас могут появиться с включенными в список программными продуктами, чем с теми, кому не удалось в него попасть. Например, официально Opera 4, 5 и 6 поддерживают модель DOM, хотя это фактически не так. И эти браузеры не удается обхитрить описанным выше способом. Хотим предупредить, что мы не являемся сторонниками идентификации версии браузера пользователя, и, когда необходимо преподать содержимое сайта под иным «соусом», мы предпочитаем проверку на совместимость с каким-либо стандартом, а не определение версии браузера. Увы, ошибочное заблуждение Opera 5, б, заставляющее его думать, что он «понимает» DOM, не позволяет нам использовать и эти методы. Мы более подробно рассмотрим этот вопрос чуть ниже, но отметим, что старые версии Opera не являются единственной проблемой.

Подробнее о D O M Несмотря на то что все современные браузеры поддерживают объектную модель документа, они все делают это по-разному, что не слишком волнует дизайнеров, использующих приемы, описанные в этой главе, но является большой головной болью для разработчиков, стремящихся использовать DOM для создания сложных

Знакомство

379

Web-приложений. К счастью, для таких разработчиков Питер-Пол Кох (PeterPaul Koch) написал обзор DOM Compatibility Overview, в котором подробно рассмотрел все различия обработки объектной модели документа браузерами (http://www.xs4all.nl/~ppk/js/index.htrnlPversion5.html). В случае переноса страницы во время одного из частых обновлений сайта просто откройте http:// www.xs411.nl/~ppk. Кох также ведет бесплатную рассылку W3C DOM, подписчиками которой являются многие творческие дизайнеры (http://www.xs4all.nl/~ppk/list.html). Аббревиатура W3C в названии рассылки не предполагает, что она как-то связана с этой организацией, а служит просто для того, чтобы уточнить, что рассылка посвящена именно W3C DOM, а не другой объектной модели. Например, чтобы было понятно, что эта рассылка не для дизайнеров, интересующихся вопросами Microsoft IE 4.0/Windows DOM.

380

Занятная объектная модель В дополнение к описанным выше ресурсам Кох написал введение в DOM (http://www.xs4all.nl/~ppk/js/doml.html). Советуем ознакомиться с этим трудом всем тем, кто знает об объектной модели документа только понаслышке (или впервые услышал о нем из нашей книги). Ряд статей Дэвида Эйзенберга в журнале "A List Apart" является еще одним источником получения знаний о DOM (http://www.alistapart.com/stories/dom). После дружественного вступления и обучающего справочника Эйзенберг объяняет, как с помощью DOM отображать и скрывать компоненты (http:// www.alistapart.com/stories/dom2), создавать динамические меню (http:// www.alistapart.com/stories/domtricks2) и обновлять содержимое страниц (http:// www.alistapart.com/stories/domtricks3), подобно показанному на рис. 15.4-15.6.

Пожалуйста, DOM, не обижай браузеры Скрипты на основе объектной модели документа не принесут никакой пользы в браузерах, несовместимых со стандартом W3C DOM, и здесь главной проблемой является Netscape 4. Решением является проверка браузеров пользователей на совместимость со стандартом и в случае ее отсутствия использование альтернативного контента или альтернативных Web-страниц. К сожалению, иногда нам приходится идти на компромисс. Целью стандартов является использование одного контента для всех браузеров. В случае с HTML или XHTML мы можем добиться этого. В случае с CSS мы можем (глава 9) использовать метод двух стилей для отправки одинаковых файлов всем пользователям и директиву @import для защиты старых браузеров от стилей, которые они не поддерживают. В главах 12-13 мы научились обходить некоторые дефекты IE 5/Windows и старых версий Opera, чтобы использовать одни стили для всех браузеров без ошибок. Во всех этих случаях вы могли использовать одинаковые файлы для всех посетителей, несмотря на небольшие проблемы. Увы, в случае с DOM мы не можем поступить так же. Netscape 4 не поддерживает DOM даже частично, объективности ради стоит заметить, что W3C находилась в стадии работы над созданием DOM во время выхода Netscape 4. Если вы не Нострадамус, вы не можете внедрить поддержку того, чего еще не существует. Мы не можем от несовместимого с DOM браузера требовать поддержки DOM, так же как мы не можем требовать от курицы научиться пользоваться калькулятором. Что мы можем сделать - это проверить браузер пользователя

Пожалуйста, DOM, не обижай браузеры

381

на совместимость с DOM и в случае ее отсутствия использовать альтернативную страницу (или вставить альтернативный контент с помощью SSI, ASP или другого средства).

Суть DOM-модели Модель DOM была изобретена Дори Смит (Dori Smith) - www.dori.com - из WaSP в начале 2001 года в ходе кампании за обновление браузеров (глава 4). DOM можно использовать для решения множества задач, во многих случаях он может заменить устаревшую технологию определения версии браузера пользователя. Алгоритм работы DOM для проверки браузера пользователя довольно прост. После создания страницы добавьте следующий скрипт в элемент <head> вашего документа или в присоединенный файл JavaScript (js): if

(!document.getElementById) { window.location = "http://www.ваш_сайт.сот/ваша_страница/"

}

где /ваша__страница/ - альтернативная страница, доступная Netscape 4 или другому, несовместимому с DOM браузеру. Эта альтернативная страница может использовать JavaScript для имитации поведения «стандартной» страницы, или она может не содержать скриптов вообще - только контент, понятный любому браузеру. Возможно, эта альтернативная страница может вообще не содержать полезной информации. Вместо этого она может предложить пользователю загрузить Netscape 7 или другой, совместимый со стандартами браузер. Такой подход является устаревшим и может сильно огорчить пользователей Netscape 4, которые просто не могут установить новый браузер из-за корпоративных правил. Именно эта причина встала на пути кампании WaSP за обновление браузеров в 2001 году. К счастью, в настоящее время число компаний, заставляющих своих работников использовать этот устаревший, несовместимый со стандартами образец стремительно снижается. Тем не менее, если DOM-приложения являются неотъемлемой частью вашего сайта, вы можете лишь порекомендовать пользователям старых браузеров перейти на более совместимые продукты. На таких сайтах скрипт проверяет браузер пользователя на совместимость с DOM, чтобы уберечь их от контента, который они не смогут нормально отобразить, и предлагает посетителям ссылку для бесплатной загрузки более совместимого браузера.

382

Глава 15. Работа со скриптами на е

Упрощение динамических сайтов: для курящих и некурящих Если вы уже создали динамические страницы и компоненты страниц отличаются от браузера к браузеру, можно использовать DOM для подачи соответствующего контента несовместимым с данной объектной моделью браузерам. Также DOM может значительно упростить процесс управления контентом. Вместо того чтобы использовать один контент для Internet Explorer 5 под Windows, другой для Internet Explorer 5 под Macintosh, третий для IE 6, четвертый для Netscape б и так далее, можно просто создать два типа контента: динамический на основе DOM и статический.

Варианты кода В глобальном файле js код будет выглядеть так, как указано выше. При вставке скрипта в каждую страницу следует разместить его между тегами <head> и </ head>. На страницах XHTML I Transitional скрипт будет выглядеть таким образом: <script type="text/javascript" language="javascript"> <!- / / if (!document.getElementByld) { window.location = "http://www.ваш_сайт.сот/ваша_страница/" } // -> </script>

В документах X H T M L Strict можно также использовать глобальный файл js или вставить такой код: <script type="text/javascript"> // <![CDATA[ if ('document.getElementByld) { window.location = "http://www.ваш_сайт.сот/ваша_страница/"

}

// ]]> </script>

383

Зачем нужна DOM-модель Так как getElementByld является методом объектной модели документа W3C DOM, совместимые браузеры пропустят его из-за применения условного оператора if, неподдерживающие модель DOM браузеры не поймут getElementByld и перейдут к странице, содержимое которой им доступно. Переадресация JavaScript обнуляет список функции Назад в браузере, и это нехорошо. Но вам необязательно использовать в этой ситуации window. l o c a t i o n . Вы можете применить любой удобный вам и вашим пользователям способ.

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

Недостатки Как уже упоминалось ранее, этот способ не работает для старых версий Opera, которые думают, что понимают DOM. Вместо того чтобы перейти на предлагаемую страницу с простым контентом, эти браузеры сначала используют знакомый метод getElementByld, а затем «подвисают», будучи не в силах обработать открывшуюся Web-страницу. Как мы можем решить эту проблему? Мы не можем использовать старомодное определение браузера, так как по умолчанию Opera идентифицирует себя как Internet Explorer. Если мы используем альтернативную страницу для пользователей Netscape 4, мы можем разместить на нашей «стандартной» странице ссылку-приглашение для пользователей старых версий Opera проследовать на эту более простую страницу. Недостатком этого способа является то, что данная ссылка будет видна абсолютно всем пользователям, что негативно скажется на образе вашего сайта, а вас могут заподозрить в непрофессионализме. Помимо этого, ссылка вроде Пользователи Opera, нажмите здесь, может заставить и пользователей Opera 7 покинуть динамическую страницу, которую их браузер прекрасно поддерживает.

384 Г шва 15- Работа се скриптами на основе DOM

Так что же нам делать? Автор этой книги полагает, что делать ничего не надо. Если ваш сайт, использующий объектную модель, некорректно работает в браузере Opera б, пользователь этого продукта, возможно, сообразит, что пришло время обновить его на Opera 7 или более позднюю версию. И не стоит печалиться по этому поводу.

Отображение и сокрытие контента По многим причинам может понадобиться скрыть некоторый контент вашей страницы при ее загрузке, отображая его в ответ на определенные действия пользователей (рис. 15.8-15.11). Благодаря скриптам на базе DOM скрывать и отображать контент становится очень легко. На сайте zeldman.com левая боковая панель содержит множество ссылок на полезные сайты. Такое количество ссылок может слегка сбить с толку посетителя, поэтому при загрузке страницы они скрыты (см. рис. 15.8). Благодаря простому щелчку по гипертекстовой ссылке, они становятся видимыми (см. рис. 15.9). Еще один щелчок - и они вновь скрыты. Данный прием совсем не сложен в применении. В JavaScript в файл сайта (http://www.zeldman.eom/j/nu.js) нужно добавить одну простую функцию, которая с помощью нашего старого метода get Element By Id позволяет скрывать и отображать контент: // переключатель видимости function toggle( targetld ) {. if (document.getElementByld) { target = document.getElementByld( targetld ); if (target.style.display == "none") { target.style.display = " " ; } else { target.style.display = "none";

Во включаемом файле (http://www.zeldman.com/includes/outside2.html) хранятся ссылки на сайты третьих лиц, разметка и код для изменения состояния их отображения. В начале расположен абзац, связанный с функцией переключения, которой передается переменная o u t s i d e 2 . Текст, представленный внутри тега ссылки (Toggle E x t e r n a l s ) , предлагает просмотреть весь список:

Отображение и сокрытие контента

385

Рис. 15.8. Левая боковая панель содержит множеаво ссылок на полезные сайты, которые изначально скрыты от пользователя (www.zeldman.com) < р х а href="/" onclick=" toggle (' outside2.'); return false; " Цtie-"Hide or show Relevant Externals (below).">Toggle Externals</a>.</p>

В списке определений, который следует непосредственно за этим абзацем, элементу присваивается идентификатор o u t s i d e 2 и определяется правило CSS (" d i s p l a y : none; "), которое скрывает список, до тех пор пока не будет задействован переключатель: <dl id= n outside2 n style="display: none;"> <dt>Relevant Externals:</dt> <ddxa href="http://www.somesite.com" title="Description.">Имя сайта< / ax / dd>

Здесь мы использовали правило CSS (" d i s p l a y : none; "), но могли бы этого и не делать, а включить его во внешний файл стилей, указав, что идентификатор

386 0 0 0

Глав.

скриптами на основе DOM

штента

387

Сочетание приема показать/спрятать с другими методами Рассмотренный выше пример является самым простым применением возможности отображать и скрывать некоторые элементы. Данный метод можно применять для достижения разнообразных эффектов и решения всевозможных задач. Например, на странице выполненных проектов сайта агентства Happy Cog (рис. 15.10) изначально посетитель видит девять скромных изображений-значков, каждое из которых символизирует собой готовый проект. При щелчке по изображению (рис. 15.11) отображается текст, связанный с этим проектом. Кроме того, при наведении указателя мыши на изображение оно подсвечивается.

Рис. 15.10. Отображение и сокрытие элементов с помощью DOM можно легко сочетать с другими эффектами (http://www.happycog.com/projects)

388

Глава 15. Работа со скриптами на основе DON!

,'t 8fchttp://w\Artv>iappycog.com/projects/

Рис. 15.11. Здесь отображение и сокрытие элементов сочетается с традиционным эффектом выделения изображения при наведении на него указателя мыши

Мы вновь использовали функцию для отображения/сокрытия элементов, написанную для сайта zeldman.com, в основном файле JavaScript сайта Happy Cog (http://www.happycog.eom/j/h.js). Разметка http://www.happycog.com является немного более замысловатой, но ее концепция осталась такой же простой, как и то, с чем мы сталкивались ранее. Например, в навигационном меню мы используем функцию для отображения текста, связанного с элементом, идентификатор которого - chcopy. Ниже приведен фрагмент кода разметки и JavaScript с дополнительными функциями: <а href = • • /projects/" onclick=" toggle (• chcopy1 ); return false;"> <img src="/i/p/ch.gif" width="100" height="75" border="0" alt="Charlotte Gray." /></a>

С помощью дополнительного JavaScript создаем эффект при наведении указателя мыши на изображение с именем ch:

Динамические мтю

389

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

Динамические меню Динамические меню имеют как минимум четыре типа отталкивающих нас черт: • разработчики помнят ужасную работоспособность и вопиющую несовместимость DHTML образца 1998 года; • дизайнеры, вместо логики руководствующиеся своим эго, создают многоуровневые меню, которые только запутывают посетителей, а не облегчают перемещение по контенту; • непроверенные DHTML-меню, вызывающие ошибки и не работающие в наших браузерах, заставляют нас навсегда забыть об их применении; • созданные в визуальных редакторах динамические меню зачастую решают проблему кросс-платформенной, межбраузерной совместимости за счет невероятно запутанного, раздутого кода, увеличивающего размер страницы и заставляющего нас бесконечно ждать окончания ее загрузки. Зачастую DHTML воспринимается как устаревший и постыдный метод. Но DOM позволяет решить эти проблемы благодаря надежной работе с совместимыми браузерами и использованию компактного, структурного кода

390 Г пава 15* Работа со скриптами на пеннее D0M

и CSS для достижения своих целей. На рис. 15.12 приведен один из примеров компактных выпадающих динамических меню, использующих простой список, на рис. 15.13-15.14 показаны раскрывающиеся меню, взятые из раздела Using Lists for DHTML сайта Дэвида Линдкиста (David Lindquist) - http:// www.gazmgus.org/dhtml/?id=109. Все эти примеры предлагаются с файлами CSS и JavaScript, которые можно загрузить и использовать на ваших сайтах.

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

Repfr

391

Рис. 15.14. Структурный код, CSS, немного JavaScript. Все работает вместе под управлением D0M

шрифта остается пиксель. И в то же время этот метод вызывает наибольшие проблемы у пользователей IE/Windows. Что если бы вы могли предложить вашим посетителям выбор подходящего им стиля? Что если можно было бы изменить разметку, находясь на сайте? Согласно технологии CSS, все это возможно. CSS позволяет использовать для страниц не только стандартную (по умолчанию) таблицу стилей, но и альтернативные CSS-файлы. В интересах повышения доступности эти альтернативные стили могут предложить пользователю более контрастную цветовую гамму или крупный шрифт (рис. 15.15-15.16). Или же они могут полностью изменить облик сайта. Согласно рекомендациям W3C, браузеры должны предоставлять пользователю возможность выбирать альтернативные таблицы стилей, однако на момент написания книги этим могли похвастаться лишь Gecko-браузеры вроде Mozilla и Netscape 7. Вся сила и преимущества доступности альтернативных таблиц стилей так и могли остаться вне пределов досягаемости, если бы в 2001 году Пол Соуден (Paul Sowden) не решил проблему, догадавшись, что альтернативные таблицы стилей, как и все другие компоненты страницы, доступны через DOM. В статье "Alternative Style: Working with Alternate Style Sheets" журнала "A List Apart" (http://www.alistapart.com/stories/alternate) Соуден приводит код файла JavaScript (http://www.alistapart.com/stories/alternate/styleswitcher.js), позволяющий посетителям сайта загружать альтернативную таблицу стилей одним щелчком по ссылке, элементу формы или любому другому интерактивному компоненту. С тех пор тысячи дизайнеров и разработчиков используют этот код на коммерческих, общественных и персональных сайтах для повышения доступности (рис. 15.15-15.16), создания дополнительных визуальных эффектов или для того и другого (рис. 15.17-15.19). Прочитайте статью в ALA, загрузите исходный код - и вперед!

392

Глава 1S. Работа со скриптами на основе DOIVf

Рис. 15.15. Сайт электронной коллекции изображений Общественной библиотеки Нью-Йорка использует переключатели стилей для обеспечения доступности пользователям с ослабленным зрением (http://digital.nypl.org/mmpco)

Рис. 15.16. Когда пользователь щелкает по ссылке Larger, не только увеличивается размер шрифта, но также повышается контрастность страницы и исчезает привлекательный, но способный отвлечь пользователей со слабым зрением фоновый-рисунок

Переключатели стилей: доступность и выбор

393

Рис. 15.17. На персональном сайте Эрика Мейера используется этот же переключатель (www.meyerweb.com). На этом рисунке мы видим сайт с альтернативной таблицей стилей, в которой используются изображения природы

394

Глава 15. Рабата со скриптами на основе ВОШ

Еще больше о D O M В этой главе описана лишь крохотная часть возможностей, предоставляемых динамической объектной моделью документа, и способов ее использования на коммерческих, персональных или общественных сайтах. Можно использовать DOM для создания мощных Web-приложений, визуальных эффектов, повышения доступности и так далее. Вы можете найти множество методов использования DOM в Internet, в то время как хороших книг по этой теме еще немного.

. CSS-редизайн

этой главе мы соберем воедино все наши знания о разметке, CSS, доступности и DOM и используем их для редизайна сайта, чтобы добиться отделения структуры от оформления. Мы определим и решим задачи, отвечающие потребностям посетителей нашего сайта. После того как мы останемся довольны внешним видом и поведением нашего сайта, мы создадим доступные пользователям альтернативные разметки, использующие CSS и DOM. Несмотря на то что внешний облик сайта, рассматриваемого в этой главе, нельзя назвать выдающимся, важно обратить внимание на обсуждаемые методы, так как именно с их помощью будут создаваться многие сайты в ближайшем будущем и практически все в дальнейшем. В предыдущих главах мы изучили составные части «мозаики» стандартов, рассмотрели, как создавать сайты со смешанной разметкой, сочетающей современный и классический подходы. В этой главе мы приблизимся к обычной практике создания сайтов в будущем. В данной главе мы обсудим приемы создания CSS-разметки, от первых шагов по созданию основных секций страницы до более интересных задач, например создания кнопок меню из структурированного списка или создания эффектов при наведении указателя мыши на изображение без использования JavaScript или даже элемента img. В дополнение к описанию отдельных методов мы рассмотрим и разные способы мышления, например дизайн, основанный на правилах или на сетке.

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

396

Глава 16. CSS-редизайм

вы перед аудиторией в несколько тысяч человек или просто работаете для собственного удовольствия и радости членов своей семьи, - наличие персонального сайта является неоспоримым плюсом, особенно для экспериментов с CSS и другими стандартами, которые вы еще не готовы использовать в проектах заказчиков или своей компании. Кроме того, наличие персонального сайта поможет вам осознать, что вы не единственный в мире дизайнер. Создав такой сайт, вы присоединитесь к растущему сообществу ценящих стандарты дизайнеров и разработчиков, которые, на удивление, всегда рады помочь друг другу. Много раз, столкнувшись с какойлибо трудностью использования CSS, разметки или JavaScript, мы делились нашими проблемами на zeldman.com. Вскоре после этого мы получали множество откликов от читателей, предлагающих свои варианты решения проблемы. Точно так же после посещения сайтов других людей мы часто помогали им решить возникшие у них трудности. Созданный в мае 1995 года сайт zeldman.com предлагает своим посетителям различные руководства и справочники, новости, статьи о Web-дизайне и о том, что интересует нас. Дизайн сайта прост, минималистичен и отличается своеобразным стилем, его материалы любопытные и дерзкие. После редизайна сайт должен был сохранить этот образ.

1О важнейших задач Дополнительные требования к редизайну являются не такими специфичными. Они могут так же хорошо подходить к вашему сайту, как и к нашему. Ниже перечислены 10 важнейших задач нашего редизайна: 1. Сайт должен быть таким же доступным в текстовом браузере, каким он является и в последних версиях браузеров от Netscape, Microsoft, Opera и других производителей. Контент и основные функции сайта должны быть доступны в любой среде, разметка сайта должна корректно отображаться в любом совместимом с CSS браузере. 2. Код должен успешно проходить проверку на соответствие требованиям XHTML 1.0 Transitional и не должен содержать элементов оформления. Мы разделяем структуру и содержание, и это означает, что вместо несемантических элементов span и d i v можно использовать р и h i . Отсутствие прозрачных GIF, таблиц, кроме тех, что используются для хранения данных в табличной форме, отсутствие устаревших атрибутов вроде b g c o l o r или m a r g i n h e i g h t , а также нецелевого использования < b l o c k q u o t e > для форматирования и использования тегов <br />

Определение цепей

397

вместо структурных элементов, создающих такой же эффект и несущих семантическую нагрузку. 3. CSS должен успешно проходить проверку и быть настолько компактным, насколько это возможно. 4. Для обеспечения максимально корректной работы сайта во всех браузерах и устройствах сайт должен быть максимально доступным. Мы проверим наш проект на соответствие требованиям Section 508 (вместо этого можно выбрать любой другой стандарт или руководство по доступности, действующее в вашей стране). 5. Сайт должен сохранить узнаваемый внешний вид и образ без дополнительной нагрузки на канал связи или сервер, без чрезмерного использования скриптов или ненужных изображений. Сайт не должен «пожирать» ресурсы, но он должен сохранить свой стиль. Он будет создавать ощущение обновления чего-то знакомого, а не созданного с нуля нового. 6. Сайт должен обладать некоторой визуальной интерактивностью, чтобы возникало ощущение, как будто сайт живой. 7. По возможности для пользователей текстовых браузеров и нетрадиционных устройств доступа к Web необходимо использовать эквиваленты всех динамических элементов. (Иными словами, не стоит жертвовать доступностью в угоду чрезмерной интерактивности.) 8. Пользователи должны иметь возможность изменять облик сайта без потери стиля. 9. Текст должен легко читаться и на нем должен быть поставлен акцент, так как это информационный сайт, а не электронный магазин или еще чтото другое. Бережное обращение с текстом является важным для любого сайта, но оно абсолютно необходимо для сайта, который читается ежедневно, как газета. 10. Навигация должна быть четкой, интуитивно понятной и очевидной. Она может и, вероятно, будет содержать некоторые графические элементы, но также должна работать и в текстовой среде. Посетители, просматривающие Web-сайты последовательно, например использующие программы для чтения информации с экрана, должны иметь возможность пропустить навигацию и использовать для навигации структурные элементы, например компоненты списка. Конечно, можно придумать и дополнительные цели, но пока хватит и этого. В целом перечисленные выше требования должны быть частью любого проекта. Большинство из них следует использовать по умолчанию при создании любых сайтов, точно так же как по умолчанию предполагается, что продукты

398

Глава 16. €3$«редизайя

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

Методы и безумие К концу этой главы у нас будет сайт, по умолчанию использующий CSS-разметку (рис. 16.1) или альтернативную ее версию (рис. 16.2), которую посетитель сможет выбрать, щелкнув по ссылке. Создание альтернативной версии заключается в сохранении файла со стилями под другим именем и его редактировании. Сколько альтернативных стилей можно создать для одного сайта? Столько, сколько захотите.

399

Рис. 16.2. Сайт с альтернативным обликом в оранжевой гамме. (Здесь вместо оранжевого серый цвет, см. сайт)

Оба дизайна выглядят просто, ибо таковыми и являются, но, для того чтобы объяснить каждое используемое правило, потребовалась целая книга. В этой главе мы обсудим наиболее яркие и выдающиеся моменты этого дизайна и не будем просто перечислять все используемые CSS-правила и код XHTML. К тому же такое перечисление было бы несколько неуместным после того, как мы разобрали почти все используемые здесь приемы в главах 7-14.

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

400

Глава 16. CSS-редизайн

Вслед за созданием следует проверка. Создание кода, его проверка и отладка, тестирование сайта на сервере, до тех пор пока мы не станем уверены в том, что все обнаруженные ошибки устранены. Но в данном проекте мы не стали придерживаться подобного подхода. Вместо этого мы начали с создания набросков отдельных компонентов. Мы творили не на глобальном уровне, а на уровне модулей. (Вначале придумайте дверную ручку. Она подскажет вам, как должна выглядеть дверь. Шаг за шагом, вы сами не заметите, как создали весь дом. Эту идею модульного дизайна мы переняли у специалиста по созданию интерфейсов Джеффри Вина (Jeffrey Veen), являющегося давним сторонником такого подхода*) Мы решили, что разметка будет состоять из трех основных разделов. Придя к такому решению, мы сосредоточились на деталях. Какими будут элементы навигации? Как будут расположены абзацы по отношению к заголовкам? Если мы используем ссылки на сайты третьих сторон, будут ли эти ссылки видны при первой загрузке сайта или следует создать опцию включения и отключения их отображения? Почти всю работу мы проделали на уровне кода, а не в Photoshop. И мы сделали это на глазах у всех, изменяя сайт прямо на виду у читателей. Кому-то понравилось наблюдать за работой, заглядывая нам через плечо. Кто-то выражал недовольство некоторыми нововведениями, и их критика вдохновила нас на новые идеи. В какой-то мере все описанное в этой главе не было заранее спланировано и осознано, а было обнаружено в процессе создания. В некотором смысле все дизайнеры работают таким образом, просто заказчикам и пользователям не виден этот процесс, они знакомятся лишь с готовым результатом. Посетите сайт www.zeldman.com, чтобы ознакомиться с последней версией разметки, кода и CSS. Таблицы стилей можно посмотреть, открыв ссылку http://www.zeldman.eom/c/wh.css и http://www.zeldman.eom/c/or.css. Как и любой другой сайт, zeldman.com постоянно развивается, и к тому моменту, когда вы будете читать эту книгу, некоторые элементы дизайна могут измениться. Ну, довольно разговоров. Переходим к делу.

Установка основных параметров Мы решили, что наш шаблон будет состоять из трех основных разделов (рис. 16.3): • панель с логотипом вверху экрана, одновременно служащая ссылкой на главную страницу. Ее также можно будет использовать для основной навигации. Мы назвали эту область New menu (Новое меню);

Установка основных параметров

401

Рис. 16.3. Шаблон будет состоять из трех основных областей

• боковая панель слева будет содержать дополнительное навигационное меню. Форму поиска, пользовательские настройки облика сайта, ссылки и рекламу. Эту область мы пометили как Secondary nav (Дополнительная навигация); • и основная область контента, в которой будет отображаться основное содержимое сайта. После долгих творческих поисков мы решили назвать эту область Primary content (Основной контент). В коде нашей XHTML-страницы после DOCTYPE, объявления пространства имен и метаданных мы пишем наши первые строки: <div id="newmenu"></div> <div id="secondarynav"></div> <div id="primarycontent"x/div>

Устаинвма основных i

гр©в

403

Рис. 16.4. Привет, я боковая панель. Верхняя полоска создана с помощью CSS, полоска снизу, более темная, является изображением GIF, созданным в Photoshop

Таким образом, ширина области составляет 151рх (ЮОрх для контента, по 25рх отступы слева и справа, плюс 1рх на прерывистую границу справа). Мы применили описанный в главе 12 прием и предлагаем IE 5/Windows ложные значения, правило «Не обижайте Opera» мы используем, чтобы избежать проблем с блочной моделью в браузере Opera. Давайте рассмотрим некоторые моменты более подробно.

Расположение Часть правила, связанная с позиционированием области, выглядит так: #secondarynav / * float: position: left: 0;

{ left; * / absolute;

Строка, отвечающая за расположение, выделена полужирным; /* f l o a t : l e f t; * / является простым комментарием, поясняющим смысл этих правил. Первое правило ( p o s i t i o n : a b s o l u t e ; ) вырывает панель из общей структуры документа, второе правило (lef t: 0;) помещает область к левому краю экрана, прямо под областью основного меню.

404

Глава 16. CSS-peдизайн

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

404

Глава 16. CSS-peдизайн

Могли ли мы сделать это иным способом? Конечно. На самом деле в предыдущей версии разметки мы использовали для этого следующий подход (различия выделены полужирным шрифтом): #secondarynav { float: left; margin: 0 ; padding: 0 25px 25px 25px; background: #bdcdbd url(/i/2003/sbbot4.gif) repeat-x bottom left; border: 0; border-top: lOpx solid #95a580; border-right: lpx dotted #000; border-bottom: lpx dotted #000; width: 151px; /* ложное значение для IE4-4.x/Win */ voice-family: " \ " } \ " " ; voice-family: inherit; width: ЮОрх; /* истинное значение для совместимых браузеров •*/ }

Обратите внимание, что мы использовали f l o a t : l e f t ; . Почему же мы отказались от этого способа и выбрали вместо него абсолютное позиционирование области?

Неприятности с float, часть 9 9 9 К сожалению, как упоминалось в главе 10, некоторые браузеры с трудом обрабатывают float, включая невозможность добиться самого «плавания» элемента и тенденцию к ошибочному подсчету высоты таких областей по мере перехода пользователя от страницы к странице, из-за чего часть контента обрезается. Конечно, впользование та, последний большинстве DreamweaverFever.com решения пучину Увы, если используя размер ошибок проблемы недостаток абсолютного случаев экрана браузеров такой впервые является можно ипользователя Web способ, позиционирования и устранить способов Standards предложил решением вы рискуете меньше их сProject's помощью устранения, Дрю этойполной разрушить МакЛиллан для неприятности. Dreamweaver JavaScript, имитации оширины чемразметку лучше (Drew ноTask f lэто oстраницы. (Такой aне McLellan) tввергнет Force.) вашего , думать. похоже, способ сайИсвас из в

Установка основных параметров

405

Соглашение об именах файлов. Стремясь сэкономить трафик, мы стараемся использовать короткие имена файлов и каталогов: / i / вместо /images/; / j / вместо /javascript/; / с / вместо /ess/ или /styles/. Точно так же мы обращаемся и с именами файлов. Например, файл с изображением, используемым внизу боковой панели, назван sbbot.gif, а не sidebar_bottom.gif. Чем меньше символов мы используем, тем меньше байт будет выброшено на ветер. Вместо logo_banner.gif для названия файла с изображением логотипа и logo__banner__over.gif для изображения логотипа при наведении на него указателя мыши, мы использовали lb.gif и lbo.gif соответственно. Когда в именах файлов фигурируют числа, они означают версию. Таким образом, Ibo2.gif является второй версией логотипа.

Создание цветных панелей Еще раз взглянув на боковую панель, обратите внимание, что для фона мы использовали теплый серо-зеленый цвет (#bdcdbd) и расположили сплошной серо-зеленый (#95а580) блок толщиной Юрх поверх области с помощью CSSсвойства b o r d e r - t o p , благодаря которому можно создавать цветные блоки любой высоты: border-top:

Юрх solid #95а580;

Мы хотим расположить подобный блок и внизу области, но мы уже использовали свойство b o r d e r - b o t t o m для создания прерывистой рамки толщиной 1рх. Нельзя использовать два свойства b o r d e r - b o t t o m для одного элемента. Однако мы можем создать в Photoshop прямоугольное изображение подходящего размера, сохранить его в формате GIF (sbbot4.gif) и использовать в качестве фона, расположенного внизу слева боковой области, повторяющегося только по горизонтали ( r e p e a t - x ) , но не по вертикали ( r e p e a t - y ) . И именно так мы и сделали: background:

#bdcdbd url(/i/2003/sbbot4.gif)

repeat-x bottom l e f t ;

Теперь у нас есть боковая панель нужного размера и цвета, с тонкой прерывистой границей и цветными полосками толщиной Юрх сверху и снизу (рис. 16.4).

• 406

Гиава 16. С$5-редизайи

Проблема совпадения цветов Любопытно отметить, что невозможно добиться полного совпадения цветов между созданной в Photoshop нижней полосой панели и созданной с помощью CSS верхней, даже если напрямую скопировать цвет верхней полосы (#95а580) в палитру Photoshop. Из-за конфликтов между существующими технологиями полное совпадение цветов в Web просто невозможно. И вот почему: • все браузеры настраивают цветовую гамму перед отображением страниц. Вы можете настроить свой монитор как угодно, можете даже привести его гамму в соответствие с RGB (http://www.w3.org/Graphics/ Golor/sRGB.html), стандартом для Web. Но все равно браузеры исказят гамму страницы. В каждом браузере имеется своя гамма цветов, отличающаяся от гаммы других браузеров; • 16-разрядные системы не могут корректно воспроизвести ни один цвет, кроме белого и черного. В 16-разрядных системах Web-браузеры некорректно обрабатывают цвета CSS и цвета изображений. Более подробно этот вопрос рассмотрен Дэвидом Леном (David Lehn) и Хэдли Стерном (Hadley Stern) - http://hotwired.lycos.com/webmonkey/ 00/37/Index2a.html?tw=design. Мы постарались извлечь из этого противоречия некую пользу и выбрали для нижней полосы более темный цвет, который, на наш взгляд, более подходит к нижней кромке.

Пространство для контента Создание области контента довольно прямолинейно: #primarycontent { border: 0; border-top: Юрх solid #bdcdbd; padding: 0; margin: 0; margin-left:, 150px; width: auto; }

•

И опять мы использовали CSS для создания полосы шириной Юрх (bordert o p : Юрх s o l i d #bdcdbd;). Несмотря на отсутствие у нас эскиза или плана, сайт начинает приобретать определенный стиль. Мы отключили все остальные рамки, задали левый отступ, указывающий начало области содержимого

Установка основных параметров

407

там, где заканчивается боковая панель ( m a r g i n - l e f t : 150рх;), а также отключили все остальные внутренние и внешние отступы. Мы также указали нашей области контента заполнить все пространство экрана от края до края с помощью одного простого правила (width: a u t o ; ) .

Блок внутри блока Если бы мы хотели, чтобы текст нашего контента автоматически подстраивался под размер любого экрана и заполнял все окно браузера от края до края, мы могли бы покончить на этом со стилями контента и перейти к пиву с чипсами, но мы не хотим этого. (Мы хотим перейти к пиву с чипсами, но не хотим, чтобы текст заполнял экран от края до края.) В конце концов, удобный для чтения текст значится под номером 9 в списке наших основных задач. Один из -способов сделать текст удобным для чтения, как знает любой дизайнер, работающий с книгами или журналами, - это расположить его в колонках, не слишком широких, но и не слишком узких. Мы полагаем, что 400рх является как раз подходящей величиной для колонки текста. Кроме того, такой размер в сочетании с размером боковой панели не будет выходить за рамки окна даже на самых маленьких мониторах. Кто-то может подумать, что для этого нам достаточно будет лишь отредактировать p r i m a r y c o n t e n t , уменьшив размер до 400рх. Но этого недостаточно. При попытке это сделать в одном браузере контент прилипает к правому краю, а в другом отображается поверх боковой панели. Необходимо создать блок для контента шириной 400рх и поместить ее внутрь области p r i m a r y c o n t e n t . Для этого пишем следующее правило CSS: #bravefourhundred { margin: 0; border: 0; padding: 15px 2 5px; width: 450px; voice-family: " \ " } \ " " ; voice-family:inherit; width: 400px; } html>#bravefourhundred { width: 400px; ' }

Вы без труда узнаете в этом примере истинное значение (400рх), уловку Тантека, предлагающую старым версиям IE ложное значение и отдельное правило для Opera. Теперь давайте вставим в разметку наш блок brave fourhundred:

408

Глава 16. CSS-редизайн

Правила в основе дизайна Мы создали основу разметки, которая будет работать в любом браузере, выпущенном в этом веке, а содержимое сайта будет доступно любому пользовательскому устройству. И точка. По мере добавления в наш шаблон текста и изображений мы создадим правила, контролирующие некоторые элементы разметки и их взаимоотношения с другими элементами. Несмотря на то что наши действия кажутся простыми, ибо они таковыми и являются, мы постепенно и незаметно для себя переходим к дизайну, в основе которого лежит использование Web-стандартов. Мы не сможем рассмотреть все правила в таблице стилей (как уже упоминалось ранее, вы можете ознакомиться с ними по адресу: http://www.zeldman.com/ c/wh.css), однако давайте взглянем на одно из них, касающееся дизайна по Webстандартам: Р {

margin-top: 0; margin-bottom: lem; font: llpx/1.5 Verdana, Trebuchet, Lucida, Arial, sans-serif; }

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

Правила в а

йма

409

Это мелочи, но CSS-разметка вся состоит из таких деталей, которые составляют разницу между тщательно созданной аккуратной разметкой и небрежной разметкой, элементы которой могут отображаться в произвольном виде. Преимущество заключается в том, что контроль над разметкой может быть достигнут без необходимости возврата к несемантическому коду и повышению трафика. Такие мелкие правила зачастую помогают нам избавиться от использования в коде лишних атрибутов c l a s s . Например, правило абзаца, приведенное выше, избавляет нас от необходимости использовать нечто подобное: <р class="notopmargin"> Благодаря таким мелочам можно сэкономить гигантский объем трафика. По мере создания правил отображения для различных элементов страницы мы также внедрим инструкции для их взаимоотношений с другими элементами нашей страницы. Например, мы можем создать правило, которое не только будет отображать рамку толщиной в один пиксель вокруг всех изображений, но также будет вставлять отступ высотой Юрх внизу каждого изображения. С помощью селекторов id мы можем задать один тип рамки и отступа для изображений, относящихся к области «А», и другой - для изображений, относящихся к области «Б». CSS 2 даже позволяет нам изменять расположение элемента в зависимости от того, какой элемент предшествует ему: Р+Р ( text-indent: 2 em; margin-top: -lem; }

Это (р+р), бывает Мы

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

img+пЗ { margin-top:

15px;

}

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

410

Глава. 16. с

еайи

Кнопка На главную страницу и CSS-эффекты Чуть раньше мы создали область основного меню Newmenu высотой 31рх. После работы над созданием навигационного меню (описанной далее) мы пришли к выводу, что все элементы навигации можно расположить в боковой панели. А что же делать с этой областью? Мы решили разместить в ней кнопку возврата на главную страницу (рис. 16.6). Внешний вид этого элемента будет изменяться при наведении на нее указателя мыши. Изображения для кнопки будут вставлены посредством свойства фона CSS, а не с помощью тега <img>.

Кнопка На главною страницу ш CS?

411

zeidfnan.com Рис. 16.6. Одно из двух изображений, использованных для создания кнопки возврата на главную страницу сайта с CSS-эффектами при наведении на нее указателя мыши

Мы создали два одинаковых изображения в Photoshop, одно из которых показано на рисунке 16.6. В изображении по умолчанию текст светло-серый (#fdf8f2), при наведении указателя мыши на кнопку текст становится белым (#f f f). Оттенки цвета в книге были бы незаметны, поэтому мы привели для этого примера лишь один скриншот. Фон обоих GIF-изображений прозрачен, сквозь него будет виден фон элемента #newmenu. В нашу разметку, в область newmenu, мы вставляем d i v с идентификатором bannerlogoban: <div id="bannerlogoban"></div> Задаем ему стиль: #bannerlogoban { margin: 0; padding: 0; border: 0; width: бООрх; height: 31px; background: url(/i/2003/parts/lbo2.gif) }

no-repeat;

Ширина бООрх соответствует ширине изображения, высота 31рх - высоте изображения и содержащего его элемента (newmenu). Правило для фонового изображения такое: загружается второй рисунок (Ibo2.gif), чтобы при наведении на кнопку указателя мыши не было задержки в изменении облика кнопки.

Замена изображения по Фарнеру Мы создали кнопку, но пока она не функционирует. Мы хотим, чтобы кнопка отображалась в своем изначальном состоянии до того, как пользователь наведет на нее указатель. Следующий наш шаг может показаться слегка запутанным, он основан на концепции, созданной Тоддом Фарнером. Вначале мы создадим класс a l t , целью которого будет невидимость в CSS-среде: .alt { display:

none;

412

Гиава 16. CSS-редазайн

Затем мы создадим второй набор правил для ссылки на главную, стартовую страницу: #logoban

{

display: block; padding: 0 ; border: 0 ; margin: 0 ; background: url(/i/2003/parts/lb2.gif) no-repeat; width: бООрх; height:31px; } ailogoban:hover { background: url(/i/2003/parts/lbo2.gif) no-repeat; }

Первое правило загружает фоновое изображение (1Ь2 . g i f ) в изначальном состоянии. Второе правило указывает браузеру на необходимость отобразить новое (Ibo2 . g i f ) изображение при наведении на кнопку указателя мыши. Теперь давайте создадим требуемый код. Вначале придумаем некоторый текст, отображаемый в среде, не поддерживающей CSS: Zeldrnan.com. Web design news and entertainment since 1995. ISSN #1534-0309. Затем мы применим к этому тексту внутри элемента span класс a l t , чтобы спрятать его от совместимых с CSS браузеров: <span class="alt"> Zeldman.com. Web design news and entertainment since 1995. ISSN #1534-0309.</span> Этот текст будет виден пользователям программ для чтения информации с экрана и карманных компьютеров, но скрыт от совместимых с CSS браузеров. Далее мы поместим этот текст в ссылку на главную страницу, применим к ссылке идентификатор lo'goban и добавим атрибут t i t l e : <а id="logoban" href="/ H title="Zeldman.com. Web design news and entertainment since 1995."><span class="alt">Zeldman.com. Web design news and entertainment since 1995. ISSN #1534-0309.</spanx/a> Теперь у нас есть работающая ссылка. В совместимой с CSS среде она будет отображаться как изображение при наведении на него указателя. В несовместимых устройствах она будет представлять из себя простой текст с гиперссылкой. Теперь мы поместим всю эту красоту внутрь элемента с идентификатором bannerlogoban, созданного ранее:

Кнопка На главную с?ршшщу ш CSSo

413

<div id="bannerlogoban"><a id="logoban" href="/" title=" Zeldman.com. Web design news and entertainment since 1995."><span class="alt"> Zeldman.com. Web design news and entertainment since 1995. ISSN #1534-0309.</spanx/ax/div>

Немаленький кусок кода, но с точки зрения трафика этот способ более экономичен, чем использование элемента image, скриптов JavaScript или обработчиков событий onmouseover и onmouseout. Так выглядит готовый код, включая родительский элемент newmenu: <div id="newmenu"xdiv id="bannerlogoban"><a id="logoban" href="/ " title="Zeldman.com. Web design news and entertainment since 1995. "xspan class="alt ">Zeldman.com. Web design news and entertainment since 1995. ISSN #1534-0309. </spanx/ax/divx/div>

Мы могли бы сделать этот образец еще более компактным, отбросив один d i v и применив правила bannerlogoban к newmenu, отказавшись от d i v с идентификатором bannerlogoban. Однако, если нам когда-нибудь захочется добавить что-либо справа или слева от кнопки возврата к главной странице, то мы сможем сделать это, только если обеспечим автономность этого модуля.

Дополнительные способы применения метода Фарнера Изобретенный Фарнером способ можно использовать во многих ситуациях. Например, с помощью этого приема можно вставлять самые широкие изображения в середину подвижной разметки. Если пользователь развернет окно браузера во весь экран, ему станет видно все изображение целиком. В нашем же примере мы использовали этот метод для создания трех баннеров с эффектом, действующим не только на сами изображения, но и на их границы (рис. 16.7). Первоначальный код CSS был таким же, как и в предыдущем примере, только без дополнительных правил, создающих границы. Но эти эффекты поддерживают не все браузеры, к которым относятся Opera 6 и Netscape 7. Устранение

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

414

Глава 11

юинм

проблемы с этими браузерами создает ошибку в IE 5/Macintosh. Нам пришлось прибегнуть к посторонней помощи в лице Портера Глендиннга (Porter Glendinning). Благодаря его знаниям, методу Фарнера и нашим усилиям, мы создали следующий код CSS: /* баннеры без элемента img, благодаря Тодду и Портеру */ #bannerl, #banner2, #banner3 { margin: Ю р х 0' 0 0; padding: 0; • width: 10Opx; height: 2 5px;

Кнопка На гпшмую страницу и С$5-эффе1ст1»!

415

416

Глава 16. CSS-peдизайн

Данный способ работает во всех браузерах 20 века. Кроме того, он делает содержимое доступным для любого устройства или браузера, старого или нового. (Если таблица стилей прикреплена с помощью ссылки, этот метод не сработает в программе для чтения информации с экрана JAWS, которая почему-то читает вслух только видимую на экране информацию после обработки CSS. Но если импортировать таблицу стилей, текст не будет скрыт от JAWS.) С другой стороны, создавать эффекты для границ таким образом - не самое разумное решение. Можно добиться такого же результата, просто изменив цвет границ в Photoshop. Но все же поступать таким образом стоит хотя бы для того, чтобы убедиться в возможностях технологии. Как и раньше, напоминаем, что вы можете свободно использовать все таблицы стилей с нашего сайта. Скопируйте их и измените под свои требования.

Панель навигации CSS/XHTML Давайте теперь обратимся к нашей боковой панели, расположенной у левой кромки экрана. Давайте наполним ее содержимым, например расположим в ней навигационное меню. Строго говоря, панель навигации представляет собой список ссылок. Давайте создадим это меню, используя обычный немаркированный список:

Панель навигации €S$/XH?№

417

Так оформил бы список любой разумный человек. Увы! Для избежания появления ненужных пробелов (этот дефект описан в главе 12), необходимо и нам удалить из этого кода все пробелы и отступы, вот так: H

< u l x l i id=" secondary top "><a href="/ title="The Daily Report. Web n design news and info. ">daily report</ax/lixli id= glam"><a href="/glamorous/" title="My Glamorous Life: Episodes and recollections. ">glamorous</a></lixli id="classics"xa href="/ classics/" title="Entertainments, 1995&#8211;2002.">classics</a></ l i x l i id= "about"><a href=" /about/ " title= "History, FAQ and suchlike. ">about</ax/lixli id="contact "><a href="/contact/ " title="Write to us. ">contact</ax/lixli id="essentials"xa href="/ essentials/" title="Info for web designers. ">essentials</ax/lixli id-"pubs"xa href="/pubs/" title="Zeldman&#8217;s books and articles. ">pubs</ax/lixli id="tour"xa href =n /tour/" title="We may be coming to your town: personal appearances. ">tour</ax/lix/ul>

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

Добавляем стиль /* создаем кнопки */ #secondarynav ul { list-style: none; padding: 0; margin: 15px 0; border: 0;

> %

418

CSS-редизайн

isecondarynav li a:hover { font-weight: normal; border-left: lpx solid #000; border-right: lpx solid #000; background: #c90; color: #fff; text-decoration: none; }

Теперь рассмотрим эти правила, превращающие обычный список в меню управления кнопками: Оно снизу #secondarynav Это также margin: padding:• border: list-style: }задаются правило задает 0; 15px равными запрещает 0; ulнулевые none; 0; {15рх. границы отображать Далее: и отступы маркеры слева.и списка справа. (list-style: Отступы none;). сверху и

419

#secondarynav li { text-align: center; border-bottom: lpx solid #000; width: lOOpx; margin: 0; padding: 0; font: 10px/15px Verdana, Lucida, Arial, sans-serif; color: #000; background:

#eO861e;

}

Задав стиль родительскому элементу (ul) в предыдущем фрагменте, теперь займемся дочерними элементами - пунктами списка. Текст выравнивается по центру, ограничивается ширина, внизу каждого пункта списка создается сплошная черная линия. Эти линии, вместе с другими, которые будут описаны ниже, создадут эффект рамки или кнопки. Наконец, обратите внимание на значение высоты строки (15рх), указанное после значения размера шрифта (font: 1 Орх/ 15рх является сокращением, значение этого выражения идентично f o n t - s i z e : Юрх; l i n e - h e i g h t : 15px;). Мы задаем размер наших «кнопок» равным 15рх, текст в них будет выровнен по вертикали прямо по центру автоматически. (Для такого маленького простого правила оно делает довольно много.) #secondarytop, # t e r t i a r y t o p > { border-top: lpx solid #000; }

Это правило вставляет черную границу вверху элемента с уникальным идентификатором secondary t o p или t e r t i a r y top. Сейчас мы говорим только о secondarytop,если вы заглянете снова в код, поймете, что мы просто приводим этот фрагмент здесь еще раз: < u l x l i id="secondarytop"><a href="/" title-'"The Daily Report. Web design news and info. ">daily report</ax/li>

Вы увидите, что первый элемент списка также имеет идентификатор s e c o n d a r y t o p , Таким образом, этот элемент будет иметь черную границу сверху. Иными словами, у первой в списке «кнопки» граница есть как сверху, так и снизу. Довольно очевидное решение, если задуматься. Если бы мы к каждой кнопке применили границу сверху и снизу, линии стали бы наползать друг на друга и выглядеть нелепо.

Панель навигации CSS/KHTfiHL

421

</style>

Обратите внимание на рис. 16.8. Слева можно наблюдать эффект «Вы находитесь здесь», когда кнопка, относящаяся к странице, на которой находится пользователь, имеет более темный фоновый цвет (#сбО) и другой цвет шрифта (# f f f). Справа виден эффект, возникающий при наведении указателя мыши на кнопку.

Рис. 16.8. Благодаря волшебству CSS обычный список превратился в кнопки

С технической стороны наши комментарии < ! —, окружающие таблицу стилей, стали бы ошибкой в XHTML 1.0 Strict, но мы используем Transitional. Также эти комментарии вызвали бы ошибку, если бы мы выдавали страницу за a p p l i c a t i o n / x h t m l + x m l , но мы используем t e x t / h t m l . Объяснение того, почему эти элементы вызывают ошибку при обработке как XHTML 1.0 Strict, можно найти по этой ссылке: http://devedge.netscape.com/viewsource/2003/ xhtml-style-script. Соединив только что созданную нами панель навигации с баннерами, интерфейсом поисковой формы и элементами для переключения стилей сайта (которые мы создали, пока вы отвернулись), мы получаем результат, как на рис. 16.9..

422

Глава 16. €$$-редизайм

Рис. 16.9. Готовая боковая панель

Завершение работы Конечно, работа над разметкой не укладывается в рамки одной главы, даже такой большой, как эта. Необходимо повысить доступность элементов form, включая форму поиска. Добавить ссылку Пропустить навигацию, t a b index и acces skey. Создать элементы интерфейса для переключения стилей облика сайта (которые можно увидеть по центру панели на рис. 16.9). Необходимо создать сам альтернативный стиль (рис. 16.10), который в основном отличается цветовой палитрой. Также мы создадим дополнительную панель ссылок (рис. 16.11), которая скрыта до тех пор, пока пользователь не активизирует ее. После завершения работы над разметкой следует процесс отладки, который в данном случае является совершенно незначительным, так как все браузеры понимают использованные нами правила CSS. Тем не менее несколько затруднений может возникнуть, и их придется устранить. Например, в браузере Safari наблюдается некоторая задержка смены изображений при переключении с одного стиля сайта на другой (рис. 16.12-16.13). Справедливости ради стоит отметить, что на момент написания этой главы

Завершение работы

423

была выпущена лишь бета-версия Safari, прекрасно отобразившего наш сайт не считая данного дефекта. Более того, мы легко устранили эту ошибку Safari. Вот что произошло. В основной, белой разметке, как вы помните, используется фоновое изображение внизу панели (рис. 16.4, 16.9). В оранжевой разметке такого изображения нет (этого вы знать не могли, если только уже не проверили файл http://www.zeldman.eom/c/or.css). Но, когда Safari переключается на оранжевую разметку, он некорректно оставляет активным фоновое изображение белой разметки. Исправить это было легко. Для оранжевой разметки мы явно указали браузерам, чтобы они не использовали фоновое изображение. Это сработало. На рис. 16.14 показана панель в Safari после этой настройки CSS. Вот правило, которое мы изначально использовали для оранжевой разметки: background: #сбО;

424

Глава 16. CSS-редизайи

А вот правило, на которое оно было заменено для Safari: background-color: #сбО; background-image: none; Кроме Safari, это изменение было не нужно ни одному браузеру. Но эту неприятность с Safari удалось довольно легко исправить с помощью абсолютно корректного правила. Мы уверены, что в окончательной версии браузера этот дефект будет устранен. Как и всегда в Web-дизайне, отладка должна быть последним этапом, хотя в нашем случае отладка происходила по ходу дела, под наблюдением всех посетителей сайта. Ну что же, мы создали CSS-разметку, без таблиц, с доступной для выбора пользователям альтернативной версией и без помощи запутанного кода или

Завершение работы

425

Рис. 16.13. Особенно четко этот дефект заметен на боковой панели. Внизу панели должна быть только одна полоса другого цвета, а не две. Сравните с рис. 16.2-16.10

426

f n a s a 16» € § § * р в д ш а й н

Рис. 16.14. Небольшой CSS-трюк устранил неприятности с Safari

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

Приложение. Современные браузеры

ак мы отмечали в главе 1, когда мы говорим «современный» или «совместимый со стандартами» браузер, мы имеем в виду программный продукт, понимающий и поддерживающий HTML, XHTML, CSS, ECMAScript и объектную модель документа W3C (DOM). Эти основные стандарты помогают дизайнерам и разработчикам отказаться от устаревших способов создания сайтов. Пока еще ни один браузер не поддерживает стандарты идеально, и вряд ли когда-нибудь такое случится. Но в начале нового тысячелетия было выпущено немало браузеров, практически полностью поддерживающих основные стандарты. По мере обновления этих браузеров они будут совместимы со стандартами все лучше и лучше. На момент написания этой книги почти все пользователи в мире обновили свои браузеры и пользуются одним из перечисленных далее. Мы упомянули здесь лишь наиболее популярные браузеры и их положительные черты (и некоторые дефекты).

Совместимые браузеры: первое поколение Opera 7 Год выпуска: 2002. Поддержка HTML/XHTML: Да. Поддержка CSS: Почти полностью CSS 1, частично CSS 2. Поддержка ECMAScript /DOM: Да, первая версия Opera с поддержкой этих стандартов.

428

Приложение

Дополнительные факты: первая версия Opera, поддерживающая W3C DOM, первая по-настоящему совместимая со стандартами версия Opera. Как и предыдущие версии, Opera 7 имеет функцию Page Zoom. Opera

Год выпуска: 2005. Поддержка HTML/XHTML: Да. Поддержка CSS: Полностью CSS1 и CSS2, с небольшими исключениями CSS2.1. Поддержка ECMAScript/DOM: Поддержка всех последних спецификаций данных технологий, включая DOM 2. Дополнительные факты: Еще более функциональный браузер, поддерживающий все стандарты, включая мобильные технологии CSS Mobile Profile и др. Более широкая поддержка XML технологий, в том числе RSS. Netscape

Год выпуска: 1997. Поддержка HTML/XHTML: Частично. Поддержка CSS: Едва ли. Поддержка ECMAScript/DOM: Нет (даже не пытался). Дополнительные факты: Выпущенный в самый разгар войн браузеров, этот некогда могучий браузер создавался для поддержки собственных технологий, а не стандартов. Поддержка CSS неполная, ошибочная и слабая. Поддержка HTML также была не на высоте. Он не поддерживал DOM, так как этот стандарт еще не был создан, хотя, даже если бы он существовал, вряд ли бы он поддерживался изза тогдашней конкуренции. Netscape

Год выпуска: 2001. Поддержка HTML/XHTML. Да.

429 Поддержка CSS: Полностью CSS 1, большинство возможностей CSS 2. Поддержка ECMAScript/DOM: Почти полностью, хотя встречаются недостатки. Дополнительные факты: Браузер на базе Gecko, написанный с нуля для поддержки Web-стандартов CSS, XML, XHTML, DOM, ECMAScript (как и Tasman, Gecko является движком, созданным для поддержки стандартов, то есть Tasman - для Macintosh, Gecko - для PC). Ранние версии Netscape 6.0 имели некоторые недостатки, последующие версии стали лучше, Netscape 7.0 и более новые версии просто потрясающие. Имеется функция Text Zoom, поддерживает пользовательские и альтернативные таблицы стилей. Поддерживает блокировку «всплывающих» окон начиная с версии 7.01. Netscape

7.2

Год выпуска: 2005. Поддержка HTML/XHTML: Да. Поддержка CSS: Исчерпывающая поддержка CSS1, практически полностью CSS2. Поддержка ECMAScript/DOM: Поддержка всех последних спецификаций данных технологий, в том числе W3C DOM 2. Дополнительные факты: Последний релиз перед готовящимся к выходу Netscape 8.0, который сейчас находится в стадии бета-тестирования. Браузер предлагает пользователям высокую функциональность при полной поддержке стандартов. В продукте усовершенствованы интерфейс пользователя и дополнительные возможности. Mozilla

1.O

Год выпуска: 2002. Поддержка HTML/XHTML: Да. Поддержка CSS: Полностью CSS 1, большинство возможностей CSS 2. Поддержка ECMAScript/DOM: Почти полностью, хотя встречаются недостатки. Дополнительные факты: Браузер на базе Gecko с открытым исходным кодом. Имеет функцию Text Zoom. На базе Mozilla были созданы браузеры Chimera/ Camino и Phoenix.

430

Приложение

Safari

Год выпуска: Конец 2002. Поддержка HTML/XHTML: Да. Поддержка CSS: Поддерживает почти полностью CSS 1, многое из CSS 2, хотя иногда ведет себя странно. Поддержка ECMAScript/DOM: Почти полностью. Дополнительные факты: Создан Apple Computer для пользователей Mac OS X на базе движка KHTML. Легкий, быстрый, корректно отображает большинство сайтов. Имеется функция Text Zoom. На него пал выбор многих пользователей Мае. M S I E 4 Год выпуска: 1997. Поддержка HTML/XHTML: Лучше, чем Netscape 4, но тоже немного. Поддержка CSS: Более полно, чем Netscape 4. Поддержка ECMAScript/DOM: Нет (даже не пытался). Дополнительные факты: Выпущенный в самый разгар войн браузеров, этот браузер создавался для поддержки собственных патентованных технологий, а не стандартов. Несмотря на то что IE 4 с точки зрения стандартов лучше Netscape 4, он меньше заботит дизайнеров и разработчиков, из-за того что практически не используется. MSIE

5+/Macintosh

Год выпуска: 2000. Поддержка HTML/XHTML: Да. Поддержка CSS: Полностью CSS 1, частично CSS 2. Поддержка ECMAScript/DOM: Да. Дополнительные факты: Первый на рынке совместимый со. стандартами браузер, первая версия IE/Mac с корректной поддержкой JavaScript/ECMAScript, первый браузер, корректно отображающий блочную модель CSS. Имеет функцию

Современные браузеры

431

Text Zoom. Поддержка пользовательских таблиц стилей. Устаревший движок Tasman уже не отвечает современным требованиям. Поддержка DOM в IE 5/ Macintosh хороша, но не полна. Тем не менее браузер поддерживает основные функции DOM и неплох с точки зрения поддержки стандартов. MSIE

5/Windows

Год выпуска: 1999. Поддержка HTML/XHTML: Да, с небольшими исключениями. Поддержка CSS: Немного, с ошибками. Поддержка ECMAScript/DOM: Недостаточно. Дополнительные факты: См. IE 5.5. MSIE

5.5/Windows

Год выпуска: 2001. Поддержка HTML/XHTML: Да, с небольшими исключениями. Поддержка CSS: В основном (но с серьезными ошибками). Поддержка ECMAScript/DOM: Скорее нет. Дополнительные факты: Хороший браузер для своего времени, но менее совместимый со стандартами, чем остальные упомянутые здесь браузеры. MSIE

6/Windows

Год выпуска: 2001. Поддержка HTML/XHTML: Да. Поддержка CSS: Большинство CSS 1, частично CSS 2. Поддержка ECMAScript/DOM: Почти полностью, но патентованные технологии все еще приветствуются. Дополнительные факты: Наиболее совместимая со стандартами версия IE/ Windows. В настоящее время самый популярный среди пользователей браузер, так как он встроен в самую распространенную операционную систему.

Предметный указатель А Атрибут accesskey 217 alt 352 class 192 id 192 summary 216 tabindex 366

Б Базовая линия 282 Блочная модель 284 Блочный элемент 251 Браузеры совместимые со стандартами 38 современные 38

Меню динамическое 389 навигационное 261 Метаструктура 191 Метод Тантека 294 Фарнера 335, 413

н Наследование 233

Отступ внешний (margin) 285 внутренний (padding) 285

Дивитсы 202 Документ внешний вид 68 поведение 69 структура 66

Переключатель стилей 390 Пикселизм 326 Портфолио 143 Пространство имен 175

Размер шрифта 256 em 321 pt 312 рх 326 ключевые слова 333 large 333 medium 333 small 333 Разметка смешанная 197 табличная 197 Редизайн 395

Идентификатор 216

к Класситсы 200 Код разветвление 42 структурный 185 Кодировка 183 объявление 184 Кросс-платформенность 40

Предметный указатель Режим стандартов (Standards) 270 уловок (Quirks) 270

с Совместимость 115 заблаговременная 32 обратная 47 переходная 83 строгая 85 Ссылка абсолютная 223 относительная 223

CMS 128, 152 ColdFusion 162 CSS 68, 227 описание 229 значение 229 свойство 229 правило 229 разметка 143 селектор 195, 229 класса 237 контекстный 234 наследуемый 234 псевдокласса 252 D

DOCTYPE 94, 173, 271 неполный 275 полный 274 Document Object Model (DOM) 373 DTD 173

ЕСМА 31 ECMAScript 104 ESPN.com 20

Хостинг-компания 46

ш Шаблон 400

ю Юзабилити 112

я Язык разметки 66

F FrontPage 138

С Gecko 270 GIGO (Garbage In Garbage Out) 54 H Happy Cog 24

A List Apart 77 Active Server Pages (ASP) 162 Adobe GoLive 107

i3Forum.com 214 iCab 220

С Chimera 272, 318

J Java Server Page (JSP) 163 JavaScript 51

433

434

i стандартам

JScript 51 L

LIFT 138, 364 LVHA (link, visited, hover, active) 254 Lynx эмулятор 64 Иm

Macintosh OS X 121 Macromedia Dreamweaver 107 Macromedia Flash 110, 304, 355 Mozilla 272 |y Netscape DevEdge 21 Q Opera 273 p PHP 1 6 2 F H F

Text Zoom 94, 331

i b l

Q QuickTime 303

User Agent 40 *MJ W3C World Wide Web Consortium 30 WAI 338 Priority 338 Web Standards Project 35 Web-службы 131 Web-стандарты 32 Wired 151 WYSIWYG 91 ** XHTML 166 DIV 192 Frameset 276 SPAN 192 Strict 85, 169, 276 Transitional 169, 276 XHTML/CSS 69 X M L

1 1 9

объявление 176 приложения 123 пролог 276 язык RDF 127 RSS 127 XML-RPC 128 XSLT 126

•» RGB-код 229 _ S

Safari 318 Simple Object Access Protocol (SOAP) 131 Suck.com 58 .

Tasman 272

zeldman.com 195

Джеффри Зельдман

Web-дизайн по стандартам Главный редактор Захаров И. М. editor-in-chief@ntpress.ru Перевод Ковалев Г. П. Научный редактор Теремецкий А. В. Ответственный редактор Захарова И. И. Верстка Родионов Е. С. Графика Чеглоков В. В. Дизайн обложки Харевская И. А.

Издательство «НТ Пресс», 129085, Москва, Звездный б-р, д. 21, стр. 1.

Издание осуществлено при техническом участии ООО «Издательство ACT» Отпечатано с готовых диапозитивов в ООО «Типография ИПО Профсоюзов Профиздат», 109044, Москва, Крутицкий вал, 18.