Проектування, компонування та подання форм за допомогою CSS

ID: 67209

Название работы: Проектування, компонування та подання форм за допомогою CSS

Категория: Лекция

Предметная область: Информатика, кибернетика и программирование

Описание: Можна сказати, що використання великої кількості маркерів class та id порушує принцип KISS (принцип збереження максимальної простоти). Проте складні компонування часто створюють конфлікти в каскадуванні – конфлікти, які найпростіше вирішуються додаванням до елементів маркерів...

Язык: Украинкский

Дата добавления: 2014-09-06

Размер файла: 863 KB

Работу скачали: 1 чел.

Тема № 8: «Проектування, компонування та подання форм за допомогою CSS»

ЗМІСТ

Вступ

Концепції, які представлені в цій темі

Перевизначення правил і маркерів

Нові елементи полів форми

Принципи проектування форм

Правило третин

Сітки

Рівні підтримки платформи

Проста контактна форма

Розмітка

Зміни щодо попередньої форми

Очевидні недоліки

Нові поля форми? Що це?

Починаємо з самого початку, закінчуємо готовою формою

Демонстрація 1

Демонстрація 1: супутні розгляди

Демонстрація 2

Демонстрація 2: супутні розгляди

Демонстрація 3

Демонстрація 3: супутні розгляди

Створення сітки

Демонстрація 4

Демонстрація 4: супутні розгляди

Правило третин

Демонстрація 5

Демонстрація 5: супутні розгляди

Демонстрація 6

Демонстрація 6: супутні розгляди

Демонстрація 7

Демонстрація 7: супутні розгляди

Демонстрація 8

Демонстрація 8: супутні розгляди

Демонстрація 9

Демонстрація 9: супутні розгляди

Демонстрація 10

Демонстрація 10: супутні розгляди

Демонстрація 11

Демонстрація 11: супутні розгляди

Демонстрація 12

Демонстрація 12: супутні розгляди

Створення рівнів підтримки платформи

Складні компонування форм на практиці (… замість теорії)

Резюме

Контрольні запитання

Таблиця: перетворення простих дробів у десяткові

Додаткове читання

Вступ

У темі міститься нова інформація про реалізацію форми і компонування інтерфейсу.

Концепції, представлені в цій темі

Перевизначення правил і маркерів

Можна сказати, що використання великої кількості маркерів class та id порушує принцип KISS (принцип збереження максимальної простоти). Проте складні компонування часто створюють конфлікти в каскадуванні – конфлікти, які найпростіше вирішуються додаванням до елементів маркерів, і написанням правил таблиць стилів, які містять декілька селекторів.

Найбільш складні компонування насичені граничними випадками, які часто найкраще обробляються за допомогою елементів id, які визначають вузький та унікальний контекст.

Нові елементи полів форми

Ефективній формі часто потрібно щось більше, ніж прості кнопки та текстові поля введення, так як досить поширене уявлення відповідей користувачів у вигляді варіантів вибору. Мова HTML надає кілька можливостей для розробників, які зустрічаються з такою вимогою.

Принципи проектування форм

Форми сайту є, зазвичай, вузловими пунктами взаємодії користувачів та збору даних. У зв’язку з цим, вони часто будуть критично важливими для успіху сайту, що вимагає самого ретельного розгляду при їх проектуванні.

Правило третин

Користувачі найчастіше звертають увагу на чотири спеціальні точки на канві (і лінії, які через них проходять). У темі розглядається цей феномен, і пропонуються кращі варіанти використання за допомогою CSS.

Сітки

Попередні теми показали, як забезпечити узгоджене оформлення тексту і отримати максимум можливого від використання прогалин. Ця тнема йде трохи далі, пояснюючи, як використовувати одиниці вимірювання em для реалізації певної міри узгодженості компонування, яку неможливо реалізувати без CSS.

Рівні підтримки платформи

Однією з поширених вимог для комерційних проектів є майже точне відтворення затвердженого дизайну сайту в одному або декількох браузерах. Ця стаття коротко досліджує причини, результати та процеси, пов’язані з реалізацією цієї вимоги.

Проста контактна форма

Контактні форми, які дозволяють відвідувачам сайту надсилати повідомлення e-mail прямо в папку вхідної пошти, широко поширені з очевидної причини: вони доступні будь-кому з активною адресою e-mail, і легко фільтруються у виділену папку пошти.

Розмітка

<ul>

<li id="nameField" class="required"><label for="realname">Name:</label><input type="text" name="name" value="" class="medium" id="realname" /><span class="note">required</span></li>

<li id="addressField" class="required"><label for="address">Email:</label><input type="text" name="email" value="" class="medium" id="address" /><span class="note">required</span></li>

<li id="subjectField"><label for="natureOfInquiry">General subject:</label>

<option value="support">Support</option>

<option value="billing">Accounts & billing</option>

<option value="press">Press</option>

<option value="other_q">Other questions</option>

</select>

</li>

<li class="required" id="acctTypeField"><label for="acctNone">Account type:</label>

<label for="acctSilver">Silver</label><input type="radio" name="acct_type" id="acctSilver" class="rInput" />

<label for="acctBronze">Bronze</label><input type="radio" name="acct_type" id="acctBronze" class="rInput" />

</fieldset>

<span class="note">required</span>

</li>

<label for="availability">My account is unavailable:</label><input type="checkbox" name="is_down" id="availability" class="rInput" /></li>

<li id="messageField"><label for="messageBody">Comments:</label><textarea name="comments" cols="32" rows="8" class="long" id="messageBody"></textarea></li>

</ul>

</form>

Зміни щодо попередньої форми

Крім включення декількох нових елементів, в розмітку було додано кілька класів та ID, на які можна посилатися з таблиці стилів. Це дозволяє незалежно від контексту посилатися індивідуально на кожну форму, пару поле/значення і поле.

Нові ідентифікатори дозволяють також розрізняти поля, які повинні заповнюватися, і поля, які не повинні.

Нарешті, є кілька нових класів, які виводять вказівки про обсяг і типи інформації, яка повинна виводитися елементами форми, до яких вони приєднані. Ці класи роблять можливим застосовувати деталі компонування до кількох довільних елементів одночасно.

Очевидні недоліки

Варто відзначити, що “необхідні” теги на полях найкраще поміщати перед полем у порядку вихідного коду, щоб забезпечити користувачів програмного забезпечення легким зчитуванням екрану. Однак, потрібна властивість position для відповідного розміщення цих об’єктів. У зв’язку з цим, “необхідні” теги були поміщені після їх відповідних елементів управління в порядку вихідного коду (хоча і в тому ж контексті).

Нові поля форм? Що це?

Як було зазначено вище, існує ряд випадків застосування, які вимагають, щоб користувач міг вибрати з двох або декількох варіантів. Ці елементи описуються коротко нижче.

Вибір описів: input type = “checkbox”

<label for="availability">My account is unavailable: </label><input type="checkbox" name="is_down" id="availability" class="rInput" />

Питання реєстрації та відмови зазвичай обробляються такими елементами управління. Інший випадок їх застосування, коли потрібно довільно вибрати з декількох варіантів, наприклад, список особистих інтересів.

Вибір із взаємовиключних станів: input type = “radio”

<label for="acctNone">Account type:</label>

<label for="acctSilver">Silver</label><input type="radio" name="acct_type" id="acctSilver" class="rInput" />

<label for="acctBronze">Bronze</label><input type="radio" name="acct_type" id="acctBronze" class="rInput" />

</fieldset>

Така група дозволяє уявити поруч кілька варіантів, з яких можна вибрати тільки один варіант. Одним хорошим прикладом застосування безлічі радіо-кнопок є завдання оцінки з шкали 1-5 або 1-10.

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

Ці елементи управління отримали свою назву по кнопках механічного налаштування попередньо заданих радіостанцій автомобільної магнітоли. На відміну від програмованих попередніх налаштувань, звичайних для пристроїв з цифровою настройкою, механічні кнопки “попереднього налаштування” при натисканні, зазвичай, поміщають приймач в середині діапазону частот смуги налаштування.

Як прапорці (checkbox), так і радіо-кнопки (radio) дозволяють використовувати атрибут checked, який, якщо задано, активує елемент управління за замовчуванням, коли він виводиться перший раз.

Питання використання радіо-кнопок або прапорців має вирішуватися після розгляду ряду різних факторів. Якщо ви хочете, щоб користувач підтвердив суб’єктивний вибір (такий як реєстрація у списку поштової розсилки), то прапорці будуть, ймовірно, кращим варіантом. Якщо ви хочете замість цього, щоб користувач вибрав між двома об’єктивними варіантами (наприклад, скажімо, стать), то тоді краще використовувати радіо-кнопки.

Коли занадто багато варіантів вибору: select/option

<label for="natureOfInquiry">General subject:</label>

<option value="support">Support</option>

<option value="billing">Accounts & billing</option>

<option value="press">Press</option>

<option value="other_q">Other questions</option>

</select>

Елементи select і option пропонують результати аналогічні тим, які надає послідовність радіо-кнопок, займаючи при цьому значно менше місця. Вибір елемента select замість послідовності радіо-кнопок часто є питанням того, як використовується простір інтерфейсу користувача; довгий список географічних областей або відділів на сайті е-комерції зазвичай краще підходить для елементів select, в той час як більш короткі послідовності вибору (наприклад, так/ні, true/false, діапазон віку, діапазон доходу) повинні представлятися у вигляді радіо-кнопок.

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

Об’єднання послідовності елементів управління: fieldset

Основне призначення елемента fieldset полягає в завданні єдиного контексту послідовності тісно пов’язаних елементів управління (елементи управління text для номера телефону, елементи select для дати, і т.д.).

Починаємо з самого початку, закінчуємо готовою формою

Тепер, коли новий матеріал цієї теми окреслено в загальних рисах, прийшов час розглянути цей матеріал в дії – дванадцять наступних демонстрацій показують різні концепції дизайну і проблеми оформлення, які зустрічаються при розробці форми Web.

Читачам наполегливо рекомендується самостійно використовувати демонстраційний матеріал для експериментів з правилами таблиць стилів.

Ці демонстрації подано у порядку вихідного коду, а не в тому порядку, в якому були написані таблиці стилів. Причини і наслідки цього відхилення обговорюються надалі в темі.

Демонстрація 1

Починаючи з правила, яке містить html {margin: 0; padding: 0;}, перший крок полягає в оформленні body, що містить сторінку.

Так виглядає сторінка без додаткового оформлення.

І код відповідної сторінки.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

<title>CSS Technique Demonstration: Forms</title>

</head>

<body>

<h3>Contact Us</h3>

<ul>

<span class="note">required</span></li>

<li id="addressField" class="required"><label for="address">Email:</label>

<span class="note">required</span></li>

<li id="acctTypeField" class="required"><label for="acctNone">Account type:</label>

<label for="acctSilver">Silver</label><input type="radio" name="acct_type" id="acctSilver" class="rInput" />

<label for="acctBronze">Bronze</label><input type="radio" name="acct_type" id="acctBronze" class="rInput" />

</fieldset>

<span class="note">required</span>

</li>

<li id="subjectField"><label for="natureOfInquiry">General subject:</label>

<option value="support">Support</option>

<option value="billing">Accounts & billing</option>

<option value="press">Press</option>

<option value="other_q">Other questions</option></select>

</li>

<li id="availabilityField"><label for="availability">My account is unavailable:</label>

<li id="messageField"><label for="messageBody">Comments:</label>

</ul>

</form>

</body>

</html>

Форма з застосуванням оформлення body.

Додані нові стилі оформлення:

body {

margin: 0;

padding: 1.714em;

background-image: url(images/bg_grid.gif);

font-size: 14px;

font-family: Helvetica,Arial,sans-serif;

line-height: 1.714em;

}

Демонстрація 1: супутні розгляди

Коли код XHTML подається з правильним Content-Type агенту користувача, який правильно його підтримує, в елементі html зображуються використовувані за замовчуванням margin і/або padding сторінки.
У тих випадках, які відрізняються від описаних у попередньому пункті, смужка пробілу шириною 10px поміщається по периметру сторінки; Opera робить це як значення padding, в той час як інші браузери масового ринку роблять це (трохи дивно) як значення margin. Демонстраційна таблиця стилів нормалізує результат.
Хоча багато будуть заперечувати проти значення розміру шрифту 14px, воно є невід’ємною частиною для різних властивостей боксів і типів, визначених де-небудь в таблиці стилів, виражених здебільшого у сьомих частках em. Для тих, хто хоче зрозуміти використовувану арифметику, в кінці статті наведено таблицю перетворення простих дробів у десяткові.
Значення 14px було вибрано, так як воно є найменшим розміром основного тексту, який може прочитати практично будь-який відвідувач, який використовує корекцію зору.
Оскільки одним із завдань даної теми є демонстрація роботи, яка відбувається на добре узгодженій сітці, на сторінку була додана фонова сітка з кроком 24 пікселя.

Демонстрація 2

Тепер, коли контейнери сторінки визначені, наступна пара кроків змінює або видаляє стилі агента користувача.

Оформлення основного заголовка і видалення небажаних прогалин.

Нові стилі оформлення:

h3 {

margin: 0 0 1.2em 0;

border-bottom: .05em solid rgb(0,96,192);

font-size: 1.429em;

line-height: 1.15em;

}

form {

width: 35.929em;

margin: 0;

}

ul {

margin: 0;

padding: 0;

list-style-type: none;

}

Демонстрація 2: супутні розгляди

Зміна розміру шрифту для заголовків відбувається по різному на різних платформах, але значення за замовчуванням завжди пропорційні значенню medium, що використовується для неоформленого тексту параграфа, і тому успадковується через каскадування. Завдання заданого тут значення полягає в тому, щоб змінити пропорцію, яка використовується за замовчуванням.
Вважається оптимальним використовувати h1 для першого заголовка на сторінці; тут ця практика ігнорується, так як в комерційному виробничому середовищі заголовок сайту часто має розмір шрифту на сторінці h1, а заголовок сторінки повинен розташовуватись нижче в ієрархії заголовків. У багатьох випадках ступінь виділення форми буде збігатися зі ступенем виділення іншого контенту або форм в тому ж документі.
Мета оформлення h3 полягає у створенні боксу контенту висотою 24 пікселя з смугою пробілу в 24 пікселя безпосередньо нижче, так щоб:

(((14 x 1.429) 1.15) + (20 x 0.05)) ≈ 24

14 * 1.429 ≈ 20; 20 * 1.15 == 23; 20 * 0.05 == 1;

(20 x 1.2) = 24

Необхідно задати значення width для form або для елементів списку, якщо елементи повинні бути правильно вирівняні без використання позиціонування. Використане значення породжує статичне значення 503 пікселя; розбіжність в один піксель (для заданого кроку атомарної сітки в 24 пікселя) є продуктом помилок, створюваних округленням і згладжуванням.
Використані за замовчуванням стилі агента користувача для списків варіюються від одного браузера до іншого. Internet Explorer задає для кожного елемента списку ліве поле в 40 пікселів і поміщає маркер пункту в отриманому вільному просторі, в той час як інші браузери використовують заповнення ліворуч блоку контенту форми як цілого. Як і з властивостями компонування, які змінюються у правилі body, це правило створене спеціально для нормалізації подання для різних браузерів.

Демонстрація 3

Тепер задання контейнерів для елементів форми.

Оформлення елементів списку (контейнери пар мітка/значення) і fieldset:

Нові стилі оформлення:

li {

clear: both;

height: 1.714em;

margin: 0;

}

fieldset {

height: 1.429em;

margin: 0 0 -.143em 0;

border: 0;

}

Демонстрація 3: супутні розгляди

Якщо хтось уявляє форму як послідовність рядків, то необхідність оформлення висоти кожного (рядка) для збереження сітки стає очевидною. Поля елементів списку задаються нульовими на користь Internet Explorer і для зручності вимірювання в інших випадках.
Оскільки для багатьох елементів у формі будуть задані значення float, елементам списку, що охоплює, присвоюється значення clear: both, щоб гарантувати, що кожен з них буде розташовуватись нижче свого попередника як само собою зрозуміле.
Окрім видалення рамки (яка є частиною використовуваного за замовчуванням стилю агента користувача), властивості компонування fieldset здаються заданими досить довільно. Фактично вони були задані після тестування в різних браузерах, що ще раз обговорюється коротко в примітках до Демонстрації 11.
У цьому місці не задаються ніякі значення display або float, що пояснює, чому контент fieldset конфліктує з наступним елементом управління select.

Створення сітки

Одним з найбільш значних підсилень гарного графічного дизайну (і разом з цим, хорошого дизайну інтерфейсу) є те, що об’єкти розміщуються з передбачуваними інтервалами. Ці інтервали зазвичай називають сіткою.

Як зазначалося вище, атомарна одиниця виміру демонстраційної форми має форму квадрата в 24 пікселя, але для отримання однорідного компонування потрібно щось більше, ніж розміщення елементів дизайну з невеликими, передбачуваними інтервалами.

Істинно ефективна сітка має такі характеристики:

Поля стовпців розміщуються на узгоджених інтервалах сітки у всьому документі.
Послідовні розділи в одному документі мають спільні верхні поля з об’єктами в сусідніх стовпцях.
Ілюстрації всередині компонування обрізуються або затінюються до розмірів, які дотримуються ширини як стовпців, так й інтервалів атомарної сітки.
Навіть у тих випадках, де контент потрапляє в єдиний стовпець, що містить елементи float, всі ці елементи будуть близькі за розміром й композицією.

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

Створення структури сітки в композиції

Більшість професіоналів для створення композицій компонування сайту використовують інструмент Adobe Photoshop, і однією з його переваг є легкість доступу до ліній сітки, які він надає. Для виведення атомарної сітки в Photoshop можна вибрати View → Show → Grid, що призведе до виведення ліній сітки з інтервалами, заданими в Guides & Grid Preferences. Накладення напрямних для таких об’єктів, як стовпці, реалізується потім вибором View → Rulers, перемиканням на інструмент Move, і перетягуванням вказівника з лінійки потрібним чином.

Реалізація сітки в таблиці стилів

Як зазначається у темі про оформлення тексту – що підкріплюється декількома правилами, включеними в демонстраційну таблицю стилів – кращим способом реалізації атомарної сітки в компонуванні є використання одиниць виміру em. Однак, лише цього буде недостатньо; оформлювач повинен також зберігати правильними свої перетворення простих дробів у десяткові при роботі з альтернативними розмірами шрифтів, пробілами і рамками.

Інша техніка реалізації сіток показана в демонстраційній таблиці стилів: створення маркерів class, які можуть посилатися на різні розміри елементів і стовпців в документі. При систематичному застосуванні ці маркери виконують велику частину роботи з реалізації сітки.

Демонстрація 4

Збереження об’єктів вирівняними по сітці означає привласнення властивостей компонування міткам і елементам керування форми.

Вирівнюємо два основних стовпця:

Нові стилі оформлення:

label {

display: block;

float: left;

clear: left;

width: 10.286em;

overflow: auto;

padding-right: 1.714em;

text-align: right;

}

input {

height: 1.143em;

border: .071em solid rgb(96,96,96);

padding: .071em;

line-height: 1;

}

Демонстрація 4: супутні розгляди

Всі елементи керування форми, включаючи текстові області й мітки, зображуються за умовчанням як елементи %inline.
Щоб створити погоджений лівий стовпець, елементам label необхідно присвоїти width; в “суворому” режимі візуалізації, задане значення padding вздовж сторони робить робочий пробіл між елементами управління та мітками достовірною реальністю.
Вирівнювання міток і елементів керування із загальним полем полегшує слідування формі. Цей факт й інші моменти композиції обговорюються як частина обговорення Правила третин – див. нижче.
У даний момент існують очевидні проблеми з формою:
Міткам (label), які приєднані до радіо-кнопок (radio), присвоюються такі ж значення display і float, як й іншим міткам (label) на формі. У парі з існуючими значеннями height і overflow, ці елементи конфліктують в деяких браузерах з наступною парою мітка-елемент керування.
У Safari 3 рамки текстових елементів управління зникають на цьому зображенні. Можна припустити, що це помилка візуалізації.
Елементи управління radio з’являються вирівняними відносно один одного в порядку вихідного коду; це відбувається, тому що проміжні елементи управління label знаходяться тепер в різному контексті перегляду.
Іншим цікавим моментом, який заслуговує на згадку, є присвоєння міткам overflow: auto. Прийом, що застосовується тут, можна описати як правило: якщо один елемент %block знаходиться усередині іншого, і за умови, що тільки для одного з них висота height визначена в статичних одиницях виміру або em, яка збільшується до відомого числа пікселів, то присвоювання overflow: auto іншому елементу – елементу без значення height – буде приводити до розширення його до height елемента з дискретним значенням height. Ця техніка використовується також у Демонстрації 11.

Правило третин

Мал.1. Сцена ранньої весни в Портленді, Орегон. На цю фотографію були накладені лінії, що ілюструють Правило третин, зверніть увагу, як нижній правий перетин і лінії, які його формують, обмежують видиму діяльність.

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

Найпростіше пояснення цього феномену полягає в тому, що ці чотири лінії найближче відповідають сітці, яка слідує Золотому перетину, пропорції, яка дорівнює приблизно за значенням однієї шостої. Золотий перетин часто зустрічається в різних галузях математики і в природі.

Мал.2. Знімок з екрану msnbc.msn.com з накладеними першими сімома золотими прямокутниками. Розміри четвертого і п’ятого прямокутників ілюструють природу сітки компонування сторінки в цілому

Форма демонстрації була розміщена таким чином, щоб елементи керування форми були б вирівняні по лівому полю, розміщеному на одній третині відстані уявного правого краю форми як цілого; такий вибір був зроблений продумано. Значно менш продумана вертикальна композиція форми – коли в розрахунок приймається заголовок, текстові поля розбиваються на два рядки, описані в попередньому параграфі. Навіть якщо заголовок не враховується, необхідні поля відсікаються в самі верхні з цих рядків.

Важливий момент для оформлювача полягає в тому, що якщо Правило третин і сітку прийняти в розрахунок до початку роботи над таблицею стилів, то завдання нормалізації таблиці стилів може істотно спрощуватися.

Демонстрація 5

Щоб гарантувати, що створена сітка зберігається як по вертикалі, так і по горизонталі, необхідно розглянути деякі особливості. Ці зміни майже повністю мають косметичний характер.

Злегка змінюємо уявлення елементів управління textarea і select:

Нові стилі оформлення:

textarea {

height: 4.714em;

margin-bottom: .286em;

border: .071em solid rgb(96,96,96);

padding: 0;

}

select {

display: block;

float: left;

height: 1.571em;

font-family: Futura,'Century Gothic',sans-serif;

}

option {

font-size: 100%;

}

Демонстрація 5: супутні розгляди

На платформах Windows можна змінити елементи управління select, щоб видалити деяку скривленість, що робить їх більш схожими на текстові елементи управління.
Так як легкість використання зазвичай поліпшується, коли користувач має можливість розрізняти з першого погляду своє введення і решту форми, то шрифт, використаний для представлення значень форми, буде відрізнятися від шрифту, використаного в іншій частині форми. З цією метою ця демонстрація змінює перші з цих значень.
Каскадування, як правило не дотримується стосовно подання тексту в елементах керування форми, що є ще однією причиною, чому тут є кілька явних значень тексту/шрифту. Застосування inherit виключається з міркувань переваги та звички, але не з якоїсь об’єктивної причини.

Демонстрація 6

Попередня демонстрація маніпулює поданням деяких шрифтів; тепер необхідно закінчити цю роботу.

Нормалізуємо подання елементів управління text і налаштуємо результат каскадування на тексті елементів управління select.

Нові стилі оформлення:

input, textarea {

display: block;

float: left;

overflow: hidden;

font-family: Futura,'Century Gothic',sans-serif;

font-size: 1em;

}

input, textarea, select {

margin-top: 0;

font-size: 100%;

}

Демонстрація 6: супутні розгляди

У цій демонстрації ми бачимо перший випадок значень, які були свідомо відкладені убік для одночасного присвоєння кільком селекторам. Виняток значень border з цих правил є штучним утворенням виробничого процесу, який був виконаний в порядку відмінному від подання цих демонстрацій – момент, який обговорюється докладніше пізніше.
Як згадувалося вище, значення тексту та шрифту в елементах керування форми не отримують користі від каскадування. Ці правила призначенні для цієї проблеми. Отже, більшість різних елементів управління тепер відповідають бажаному компонуванню.
У зв’язку з поведінкою Internet Explorer 6 всіх елементів керування форми значення float задане як left. Це значення було вибрано за звичкою, яка отримана в результаті (неприємного) досвіду, але не є суворо обов’язковим.
При завданні значень block текстовим елементам управління проблема візуалізації в Safari, видима в двох попередніх демонстраціях, раптово вирішилася. Такі дивацтва зустрічаються досить часто при оформленні форм.
Так само як не були правильно нормалізовані значення border, не були нормалізовані і значення font-size; завдання значень 1em текстовим елементам управління і значень 100% елементів керування select було повністю довільним.

Демонстрація 7

Необхідно змінити ширину різних текстових елементів управління, яка використовується за замовчуванням.

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

Нові стилі оформлення:

.medium {

width: 11.714em;

}

select.medium {

width: 12em;

}

.long {

width: 20.429em;

}

.rInput {

border: 0;

}

Демонстрація 7: супутні розгляди

Повторний розгляд розмітки вихідного коду покаже, що кожному елементу управління було присвоєно class – одному з трьох, пов’язаних з шириною, елементів управління для тексту та елементів управління select, й інші класи для елементів, які залежать від введення покажчика/курсору, а не від введення клавіатури.
Класи для елементів управління необхідно ставити в основному тому, що Internet Explorer має обмежену підтримку для розвинених селекторів. У міру розвитку селекторів rInput class можна буде також легко замінити на input [type = "radio"], input [type = "checkbox"] … якщо поточні виробничі версії Internet Explorer взагалі будуть це підтримувати.
Завдання трьох можливих значень для текстових елементів управління абсолютно довільно, і залишається на розсуд дизайнера. У комерційних налаштуваннях деякі дизайнери створюють такі незвичайні компонування, що селектори class, такі як використовуються тут, будуть функціонально марні. Завдання id для кожної пари мітка/елемент управління надає найпростіше можливе посилання на кожен елемент форми – простота, яка є цінною при оформленні роботи дизайнера, який наполягає на своєму втручанні в кожному елементі компонування сайту.

Демонстрація 8

Кнопка відправки форми була млявою

Точно налаштовуємо позицію кнопки відправки форми.

Нові стилі оформлення:

.submitButton {

display: block;

clear: both;

width: 7.2em;

height: 2em;

margin: 0 0 0 16.8em;

border: 1px solid rgb(128,128,128);

padding: 0;

font-size: 10px;

text-align: center;

}

Демонстрація 8: супутні розгляди

Найбільша проблема, яка зустрічається при оформленні кнопок відправки, полягає в розміщенні їх точно так, як потрібно дизайнерові. Звичайна практика отримання необхідного виду полягає в ретельному припасуванні компонування і властивостей line-height; деякі розробники можуть знайти менш трудомістким використання замість цього заміни зображення (див. Бібліографію) або input type = "image".
На перший погляд завдання display: block для цього об’єкта здається надлишковим – і дійсно є надлишковим, якщо думати тільки в термінах єдиної форми на єдину сторінку. Проте в контексті всього сайту це може виявитися не надлишковим; багато сайтів і додатків мають кілька форм в одному документі з різними значеннями display.

Демонстрація 9

Розмістимо “необхідні” теги там, де вони повинні знаходитися.

Вирівнюємо “необхідні” теги до уявного правого поля форми, і змінюємо їх текстові властивості.

Нові стилі оформлення:

li.required span.note {

display: block;

width: auto;

float: right;

color: rgb(128,128,128);

font-size: .714em;

line-height: 2.4em;

font-style: italic;

}

Демонстрація 9: супутні розгляди

У своєму поточному стані елемент fieldset, що містить елементи управління radio, все ще є блоковим елементом, тому він поширюється до правого поля форми. У результаті тег, приєднаний до цієї множини елементів управління, зміщується нижче обчисленого нижнього краю fieldset.
Значення auto, що задається для width “необхідних” тегів, визначає, що вони не можуть бути ширше свого контенту.
Більш уважний розгляд арифметики, яка використовується для набору тексту “необхідних” тегів, покаже розмір шрифту в десять пікселів, і інтерліньяж в 24 пікселя (еквівалентний одній атомарній одиниці використовуваної сітки).
Структура, використана для індикації необхідних полів, створена з урахуванням інтерактивної взаємодії з користувачами; за допомогою різних класів, використаних на формі, можна перевіряти введення користувача за допомогою JavaScript, і змінювати оформлення міток, полів та/або тегів в налаштуваннях міток/елементів управління, які не були правильно оброблені користувачем.

Демонстрація 10

Нарешті прийшов час залагодити конфлікти елементів управління radio з полями під ними у порядку вихідного коду.

Вирівнюємо елементи управління radio та їх мітки по горизонталі.

Нові стилі оформлення:

fieldset label {

margin-right: .25em;

padding-right: 0;

line-height: 1;

}

fieldset .rInput {

margin-right: .75em;

}

fieldset label, fieldset .rInput {

width: auto;

display: inline;

float: none;

font-size: .857em

}

li.required fieldset {

width: 18.857em;

float: left;

}

Демонстрація 10: супутні розгляди

Основний результат цих правил, крім виконання косметичних налаштувань, полягає у зміні значення display елементів управління radio і checkbox знову на inline. Це робиться з метою уникнути труднощів, які виникають, коли вони стають плаваючими, як інші елементи input у формі.
Замість завдання display: inline відповідних елементів управління, вони залишаються “заміненими” елементами: строковими елементами з відомими під час виконання статичними розмірами (тобто, до того як браузер реально почне візуалізацію контенту). У зв’язку з цим, до цих об’єктів можна застосовувати поля.
Специфічна природа елементів fieldset – зокрема, те що вони є тільки елементами %block, спеціально призначеними для використання у формах – вимагає, щоб у цьому випадку застосовувалася дискретна ширина до будь-яких fieldset, що містить елементи управління, які вимагають активації користувача.
Демонстрація 11

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

Нові стилі оформлення:

#acctTypeField fieldset {

padding: .286em 0 0 0;

line-height: normal;

}

#acctTypeField .rInput {

margin-top: .167em;

}

#availabilityField label {

height: 3.143em;

padding-top: .286em;

line-height: normal;

}

#availabilityField .rInput {

margin-top: .286em;

}

#availabilityField, #messageField {

height: 1%;

overflow: auto;

}

Демонстрація 11: супутні розгляди

Тут також використовується overflow, як у Демонстрації 4; #availabilityField має label відомої висоти (height), а #messageField аналогічно textarea.
Використання маркера #acctTypeField для зміни значення padding для fieldset, яке він містить, цілком може бути занадто специфічним. Однак для цього потрібна тонка обробка при записі стилів, які можуть так легко піддаватися впливу стилів сусідніх елементів.
Інші правила в цьому блоці таблиці стилів роблять невеликі зміни в компонуванні, які всі були визначені в ході тестування. На жаль, години тестування і тонкого налаштування можуть не знайти поведінку, яку будуть виробляти ідентично складені елементи управління radio, як в Safari 3, так і в Firefox 3. Результатом є базова лінія на мітках (label) елементів управління radio, які не в порядку в Firefox 3. Звичайно можна сказати, що оформлення елементів checkbox і radio є чимось на зразок таємного знання.

Демонстрація 12

Всі попередні стилі оформлення були розроблені для Opera або Safari (вибирайте, обидва браузера ведуть себе відносно добре). Далі слідують правила спеціально створені для Internet Explorer, визначені у файлі CSS, приєднаному (link) в умовному блоці коментаря.

Робимо останню множину змін для Internet Explorer:

Нові стилі оформлення:

h3 {

margin-bottom: 1.2em;

}

li {

margin: 0 0 -0.214em 0;

}

select {

height: 1.429em;

}

textarea {

height: 4.571em;

}

fieldset {

height: 1.583em;

padding-top: 0.417em;

}

.medium {

width: 13.429em;

}

select.medium {

width: 13.714em;

}

.long {

width: 20.286em;

}

fieldset .rInput {

border: 0 !important;

}

#subjectField {

margin-bottom: -0.214em;

}

#availabilityField .rInput {

margin-top: 0.286em;

}

#messageField {

padding-bottom: 0.286em;

}

input.submitButton {

margin-top: 0.15em;

}

* html input, * html textarea {

float: left;

}

* html select {

font-size: 0.643em;

}

* html select.medium {

width: 21.364em;

}

* html textarea {

height: 4.643em;

}

* html #subjectField {

margin-top: 0.071em;

margin-bottom: 0;

}

* html #availabilityField label {

padding-top: 0;

}

* html input.submitButton {

margin: .1em 0 0 7em;

}

Демонстрація 12: супутні розгляди

Як можна бачити, всі показані вище стилі оформлення припускають невеликі відмінності в тому, як Internet Explorer каскадує розміри шрифтів та розміщення боксів.
Іншим об’єктом, вартим уваги, є селектор * html. Internet Explorer 5 і 6 є єдиними браузерами, які розпізнають цей селектор, що робить його ефективним низькопрохідним фільтром для правил таблиць стилів, призначених для цих браузерів.

Створення рівнів підтримки платформи

Останній розділ демонстрації показує різновид стилів оформлення, відкладених для Internet Explorer 6 і 7, і вимагає обговорення, наскільки широко різні браузери розглядаються сумлінною командою розробників сайту.

Реальність Web полягає в тому, що користувачі використовують безліч всіляких браузерів у всіляких робочих середовищах. Деякі з них є старими, в той час як інші перебувають на передньому краї розвитку. Деякі виконуються на повнофункціональних комп’ютерах, в той час як інші виконуються на мобільних пристроях, таких як телефони. Всі вони розроблені в певних операційних системах, а потім перенесені на інші з різним ступенем підтримки стандартів. За винятком Opera, всі постачальники браузерів, постачають продукти, які створюються для використання разом з іншими продуктами в більш широких пакетах – вимога розробки, яка робить ці браузери більш складними, ніж потрібно для єдиного завдання перегляду Web. Неначе б було недостатньо розгляду безлічі сильних і слабких сторін браузерів, але існує також питання помилок – помилок системи безпеки, помилок компонентів, і, особливо, помилок візуалізації. Користувачі Safari 3.x виявили, що в певний момент документ демонстрації виявляє руйнівну помилку візуалізації в їх власному браузері. Кращим способом вирішення таких питань є визначення рівнів підтримки. Така практика була вперше проголошена командою розробки інтерфейсу в Yahoo!, які назвали її “Ранжированою підтримкою браузерів”.

Зазвичай рівні підтримки потрапляють в чотири широкі категорії:

Сайт виводиться, як спочатку задумувався, в межах можливостей цих браузерів, і всі властивості повністю підтримуються. Платформа розробки визначає, так званий іноді рівень “A+”.
Відхилення від кращої композиції є очевидним, можливо в істотній мірі; однак, сайт все ще можна використовувати, і більшість, якщо не всі, властивості сайту підтримуються.
Сайт, що запропонований користувачам цих браузерів, є настільки простим, наскільки може підтримуватися без втрати бренду власника сайту, і властивості сайту цілком можуть відключатися. Ці браузери мають, зазвичай, відносно невеликі бази установки, і передбачаються застарілими, нестабільними або неповноцінними.
Званий в документації Yahoo! як підтримка ступеня “X Grade”, цей рівень підтримки зарезервований для нетестованих платформ – зазвичай більш нових браузерів з невеликими базами інсталяції (часто Opera, природно). Після тестування такі браузери переміщають на більш високий рівень.

Особливості процесу збору вимог, який формує визначення рівнів підтримки і розподіляє по них браузери, були б тривалими і нудними, і тому були виключені з цієї й так довгої теми.

Складні компонування форм на практиці (… замість теорії)

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

Щоб намітити в загальних рисах послідовність демонстрацій на основі тимчасової шкали, було б необхідно підтримувати журнал (або зберігати таблицю стилів в системі контролю версій) – що ніколи не робилося. До того часу, коли цей недогляд був помічений, ця стаття була і так занадто прострочена, щоб виправляти це.
Представлення згідно з порядком вихідного коду істотно полегшує створення документів демонстрації – ще одна поступка ідеалу практиці.
Так як вихідна таблиця стилів демонстрації була написана зі значною (якщо не вичерпною) турботою про нормалізацію і порядок вихідного коду – як і має бути для всіх виробничих таблиць стилів – представлення демонстрації в порядку вихідного коду гарантує, що тим студентам, які хочуть “бачити вихідний код “, буде значно легше зрозуміти сенс того, що реально робиться.

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

Застосовуються стилі документа (тобто, body)
Перезадаются значення за замовчуванням списків, форм і fieldset
Визначається набір тексту
Об’єкти списку обмежуються і очищаються (clear)
Мітки (label) розміщуються в цілому
Визначається і нормалізується компонування елементів керування форми (головним чином розміри)
Створюється кнопка відправки
Задаються крайні випадки
Тестуються браузери Safari і Firefox і змінюються значення таблиці стилів, щоб відобразити компроміси (де можливо)
Тестуються браузери 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
2	.5	-	-	-	-	-	-	-	-	-	-	-	-	-	-
3	.(3*)	.(6*)	-	-	-	-	-	-	-	-	-	-	-	-	-
4	.25	.5	.75	-	-	-	-	-	-	-	-	-	-	-	-
5	.2	.4	.6	.8	-	-	-	-	-	-	-	-	-	-	-
6	.1(6*)	.(3*)	.5	.(6*)	.8(3*)	-	-	-	-	-	-	-	-	-	-
7	.(142857*)	.(285714*)	.(428571*)	.(571428*)	.(714285*)	.(857142*)	-	-	-	-	-	-	-	-	-
8	.125	.25	.375	.5	.625	.75	.875	-	-	-	-	-	-	-	-
9	.(1*)	.(2*)	.(3*)	.(4*)	.(5*)	.(6*)	.(7*)	.(8*)	-	-	-	-	-	-	-
10	.1	.2	.3	.4	.5	.6	.7	.8	.9	-	-	-	-	-	-
11	.(09*)	.(18*)	.(27*)	.(36*)	.(45*)	.(54*)	.(63*)	.(72*)	.(81*)	.(90*)	-	-	-	-	-
12	.08(3*)	.1(6*)	.25	.(3*)	.41(6*)	.5	.58(3*)	.(6*)	.75	.8(3*)	.91(6*)	-	-	-	-
13	.(076923*)	.(153846*)	.(230769*)	.(307692*)	.(384615*)	.(461538*)	.(538461*)	.(615383*)	.(692307*)	.(769230*)	.(846153*)	.(923076*)	-	-	-
14	.0(714285*)	.(142857*)	.2(142857*)	.(285714*)	.3(571428*)	.(428571*)	.5	.5(714285*)	.6(428571*)	.(714285*)	.7(857142*)	.(857142*)	.9(285714*)	-	-
15	.0(6*)	.1(3*)	.2	.2(6*)	.(3*)	.4	.4(6*)	.5(3*)	.6	.(6*)	.7(3*)	8	.8(6*)	.9(3*)	-
16	.0625	.125	.1875	.25	.3125	.375	.4375	.5	.5625	.625	.6875	.75	.8125	.875	.9375

Додаткове читання

Бос, Берт, і ін 2007. Специфікація каскадних таблиць стилів рівня 2 ревізії 1 (CSS 2.1). Консорціум WWW. http://www.w3.org/TR/2007/CR-CSS21-20070719 і т.д. (Доступно 28 травня 2008 р.).
Хенік, Бен. 2006. 12 уроків для тих, хто боїться CSS і стандартів. A List Apart. http://www.alistapart.com/articles/12lessonsCSSandstandards (доступно 16 грудня 2008 р.).
Хоротон, Сара, і Лінч, Патрік. 2002. Керівництво по стильовому оформленню Web: базові принципи створення Web-сайтів, 2-е вид., New Haven, Conn.: Yale University Press.
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).
Meyer, Eric. 2007. Formal weirdness. Meyerweb.com. http://meyerweb.com/eric/thoughts/2007/05/15/formal-weirdness/(доступно 17 грудня 2008).
Microsoft Corporation. msnbc.com. http://msnbc.msn.com/ (доступно 17 грудня 2008).
Рагетт, Дейв, та ін, 1999. Специфікація HTML 4.01. Консорціум WWW. http://www.w3.org/TR/1999/REC-html401-19991224 etc. (Доступна 30 червня 2008 р.).
Рейнольд, Гарр. 2005. Від золотого середнього до “правилом третин”. Presentation Zen. http://www.presentationzen.com/presentationzen/2005/08/from_golden_mea.html (доступно 16 грудня 2008 р.).
Santa Maria, Jason. 2008. Making modular layout systems. 24 Ways. http://24ways.org/2008/making-modular-layout-systems (доступно 16 грудня 2008 р.).
Wikipedia. 2008. Fahrner image replacement. http://en.wikipedia.org/wiki/Fahrner_Image_Replacement (доступні 19 грудня 2008 р.).
Yahoo! Developer Network. 2008. Ранжируваних підтримка браузерів. http://developer.yahoo.com/yui/articles/gbs/ (доступно 16 грудня 2008 р.).