Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







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





Последний раздел демонстрации показывает разновидность стилей оформления, отложенных для 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 повторяется бесконечно).

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

x 1/x 2/x 3/x 4/x 5/x 6/x 7/x 8/x 9/x 10/x 11/x 12/x 13/x 14/x 15/x
  .5 - - - - - - - - - - - - - -
  .(3*) .(6*) - - - - - - - - - - - - -
  .25 .5 .75 - - - - - - - - - - - -
    .4 .6 .8 - - - - - - - - - - -
  .1.(6*) ..3*) .5 .(6*) .8(3*) - - - - - - - - - -
  .(142857*) .(285714*) .(428571*) .(571428*) .(714285*) .(857142*) - - - - - - - - -
  .125 .25 .375 .5 .625 .75 .875 - - - - - - - -
  .(1*) .(2*) .(3*) .(4*) .(5*) .(6*) .(7*) .(8*) - - - - - - -
  .1 .2 .3 .4 .5 .6 .7 .8 .9 - - - - - -
  .(09*) .(18*) .(27*) .(36*) .(45*) .(54*) .(63*) .(72*) .(81*) .(90*) - - - - -
  .08(3*) .1(6*) .25 .(3*) .41(6*) .5 .58(3*) .(6*) .75 .8(3*) .91(6*) - - - -
  .(076923*) .(153846*) .(230769*) .(307692*) .(384615*) .(461538*) .(538461*) .(615383*) .(692307*) .(769230*) .(846153*) .(923076*) - - -
  .0(714285*) .(142857*) .2(142857*) .(285714*) .3(571428*) .(428571*) .5 .5(714285*) .6(428571*) .(714285*) .7(857142*) .(857142*) .9(285714*) - -
  .0(6*) .1(3*) .2 .2(6*) .(3*) .4 .4(6*) .5(3*) .6 .(6*) .7(3*) .8 .8(6*) .9(3*) -
  .0625 .125 .1875 .25 .3125 .375 .4375 .5 .625 .625 .6875 .75 .8125 .857 .9375

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

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 г.).

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

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

Лекция 35:







Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

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

Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...





Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2024 zdamsam.ru Размещенные материалы защищены законодательством РФ.