Создание уровней поддержки платформы

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

Реальность Web состоит в том, что пользователи используют множество всевозможных браузеров во всевозможных рабочих средах. Некоторые из них являются старыми, в то время как другие находятся на переднем крае развития. Некоторые выполняются на полнофункциональных компьютерах, в то время как другие выполняются на мобильных устройствах, таких как телефоны. Все они разработаны в определенных операционных системах, а затем перенесены на другие с различной степенью поддержки стандартов. За исключением Opera, все поставщики браузеров, поставляют продукты, которые создаются для использования вместе с другими продуктами в более обширных пакетах -- требование разработки, которое делает эти браузеры более сложными, чем требуется для единственной задачи просмотра Web. Как будто бы было недостаточно рассмотрения множества сильных и слабых сторон браузеров, но существует также вопрос ошибок -- ошибок системы безопасности, ошибок компонентов, и особенно ошибок визуализации. Пользователи Safari 3.x обнаружили, что в определенный момент документ демонстрации выявляет разрушительную ошибку визуализации в их собственном браузере. Лучшим способом разрешения таких вопросов является определение уровней поддержки. Такая практика была впервые провозглашена командой разработки интерфейса в Yahoo!, которые назвали его "Ранжированной поддержкой браузеров".

Обычно уровни поддержки попадают в четыре широкие категории:

1. Сайт выводится, как первоначально задумывался, в пределах возможностей этих браузеров, и все свойства полностью поддерживаются. Платформа разработки определяет, так называемый иногда уровень "A+".
2. Отклонение от предпочтительной композиции является очевидным, возможно в существенной степени; однако, сайт все еще можно использовать, и большинство, если не все, свойства сайта поддерживаются.
3. Сайт, предлагаемый пользователям этих браузеров, является настолько простым, насколько может поддерживаться без потери бренда владельца сайта, и свойства сайта вполне могут отключаться. Эти браузеры имеют обычно относительно небольшие базы установки, и предполагаются устаревшими, нестабильными, или неполноценными.
4. Называемый в документации Yahoo! как поддержка степени "X Grade", этот уровень поддержки зарезервирован для нетестированных платформ — обычно более новых браузеров с небольшими базами установки (часто Opera, естественно). После тестирования такие браузеры перемещают на более высокий уровень.

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

Сложные компоновки форм на практике (… вместо теории)

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

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

В качестве агента пользователя во время разработки использовался браузер Opera 9.6 для OS X; с учетом этой оговорки и отмеченных выше других замечаний, ниже представлен общий порядок, в котором изменения и дополнения были сделаны в таблице стилей:

1. Применяются стили документа (т.е., body)
2. Перезадаются значения по умолчанию списков, форм, и fieldset
3. Определяется набор текста
4. Объекты списка ограничиваются и очищаются (clear)
5. Метки (label) размещаются в целом
6. Определяется и нормализуется компоновка элементов управления формы (главным образом размеры)
7. Создается кнопка отправки
8. Задаются крайние случаи
9. Тестируются браузеры Safari и Firefox и изменяются значения таблицы стилей, чтобы отразить компромиссы (где возможно)
10. Тестируются браузеры Internet Explorer 6 и 7 и в условную таблицу стилей добавляются настройки свойство/значение

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

Заключение

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

Контрольные вопросы

• Какой тип обтекания у элементов управления формы, которые принимают ввод пользователя, и какие две характеристики делают их выделяющимися в отношении компоновки?
• Какие два атрибута отличные от value и disabled управляют настройками элементов управления формы до взаимодействия пользователя, и к каким элементам они применяются?
• Документ демонстрации обеспечивает требуемые поля. Напишите, по крайней мере, одно правило таблицы стилей, которое будет разом изменять внешний вид поля, которое содержит образец ошибки или пропуск ввода пользователя.
• Опишите по одному случаю использования для каждого из элементов управления select, checkbox, и radio. Обоснуйте каждое описание объяснением преимуществ, которое предоставляет сделанный выбор, при сравнении с другими возможными вариантами выбора.
• Используя сетевую ссылку, выбранную инструктором, найдите и кратко опишите альтернативы для input type="submit".
• Создайте элемент select, который позволяет выбрать несколько options, добавляя пару атрибут/значение multiple="multiple". После анализа поведения этого элемента, объясните, почему он редко встречается на производственных сайтах.

Таблица: преобразование простых дробей в десятичные

В следующей таблице цифры, находящиеся в скобках со звездочкой после них, бесконечно повторяются; например, 0.2(6*) эквивалентно 0.266666666666666… (6 повторяется бесконечно).

Ближайшие к нулю значения находятся в таблице слева, и приближаются к единице в таблице при движении слева направо.

Библиография

1. Бос, Берт, и др. 2007. Спецификация каскадных таблиц стилей уровня 2 ревизии 1 (CSS 2.1). Консорциум WWW. http://www.w3.org/TR/2007/CR-CSS21-20070719 и т.д. (доступно 28 мая 2008 г.).
2. Хеник, Бен. 2006. 12 уроков для тех, кто боится CSS и стандартов. A List Apart. http://www.alistapart.com/articles/12lessonsCSSandstandards (доступно 16 декабря 2008 г.).
3. Хоротон, Сара, и Линч, Патрик. 2002. Руководство по стилевому оформлению Web (http://www.webstyleguide.com/): базовые принципы создания Web-сайтов, 2-е изд., New Haven, Conn.: Yale University Press.
4. Knott, Ron. 2008. The golden section ratio: phi. Department of Mathematics, University of Surrey (UK). http://www.mcs.surrey.ac.uk/Personal/R.Knott/Fibonacci/phi.html (доступно 18 декабря 1008 г.).
5. Meyer, Eric. 2007. Formal weirdness. Meyerweb.com. http://meyerweb.com/eric/thoughts/2007/05/15/formal-weirdness/ (доступно 17 декабря 2008 г.).
6. Microsoft Corporation. msnbc.com. http://msnbc.msn.com/ (доступно 17 декабря 2008 г.).
7. Рагетт, Дейв, и др., 1999. Спецификация HTML 4.01. Консорциум WWW. http://www.w3.org/TR/1999/REC-html401-19991224 etc. (доступно 30 июня 2008 г.).
8. Рейнольд, Гарр. 2005. От золотого среднего к "правилу третей". Presentation Zen. http://www.presentationzen.com/presentationzen/2005/08/from_golden_mea.html (доступно 16 декабря 2008 г.).
9. Santa Maria, Jason. 2008. Making modular layout systems. 24 Ways. http://24ways.org/2008/making-modular-layout-systems (доступно 16 декабря 2008 г.).
10. Wikipedia. 2008. Fahrner image replacement. http://en.wikipedia.org/wiki/Fahrner_Image_Replacement (доступно 19 декабря 2008 г.).
11. Yahoo! Developer Network. 2008. Ранжированная поддержка браузеров. http://developer.yahoo.com/yui/articles/gbs/ (доступно 16 декабря 2008 г.).

Предыдущая статья — Оформление таблиц

Следующая статья — Плавающие элементы и очистка

Об авторе

Бен Хеник создает Web-сайты различного вида начиная с сентября 1995 г., когда он взялся за свой первый Web-проект как академический доброволец. С тех пор большая часть его работы была сделана в качестве фрилансера.

Бен является универсалом, его навыки касаются почти любого аспекта создания и разработки сайта, от CSS и HTML до проектирования и написания текста, и до PHP/MySQL и JavaScript/Ajax.

Он живет в Лоуренсе, Канзас с тремя компьютерами и без телевизора. Вы может прочитать больше о нем и его работе на сайте henick.net ( http://www.henick.net/).

Материалы этого курса имеют лицензию Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.