Додаток Б:
Зауваження про роботу, реалізації та розробці

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

B.1 Зауваження про неприпустимих документах

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

Однак з метою сприяння експериментів і сумісності між реалізаціями різних версій HTML рекомендується наступне поведінка:

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

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

Оскільки агенти користувачів можуть по-різному обробляти помилкові стану, автори і користувачі не повинні покладатися на певну поведінку в разі виникнення помилки.

У специфікації HTML 2.0 ( [RFC1866] ) відмічено, що багато агентів користувачів HTML 2.0 припускають, що документ, що не починається з оголошення типу документа, відноситься до специфікації HTML 2.0. Як показує досвід, це некоректне припущення, дана специфікація не рекомендує таку поведінку.

З міркувань сумісності автори не повинні "доповнювати" HTML наявними механізмами SGML (наприклад, розширюючи DTD, додаючи новий набір визначень комбінацій і т.д.).

B.2 Спеціальні символи в значеннях атрибутів URI

B.2.1 Символи, що не входять в набір ASCII, в значеннях атрибутів URI

Хоча URI і не включають символи, що не входять в набір ASCII, (див. [URI] , розділ 2.1) автори іноді вказують їх в значеннях атрібутоах, в яких має бути зазначено URI (наприклад, в атрибути, визначені як % URI; в DTD ) . Наприклад, таке значення атрибута href неприпустимо:

  <A Href="http://foo.org/Håkon"> ... </A>

Для обробки символів, що не входять в набір ASCII, в таких випадках агентам користувачів рекомендується:

1. Представляти кожен символ UTF-8 (див. [RFC2044] ) як один або кілька байт.
2. Виділяти ці байти за допомогою механізму виділення URI (тобто шляхом перетворення кожного байта в% HH, де HH - шістнадцяткова запис значення байта).

Ця процедура призводить до створення синтаксично допустимого URI (відповідно до [RFC1738] , розділ 2.2 або [RFC2141] , розділ 2), який не залежить від кодування символів , з використанням якої може бути закодований документ HTML, в якому вказано цей URI.

B.2.2 амперсандами в значеннях атрибутів URI

URI, побудований при передачі форми , може використовуватися як посилання типу якоря (наприклад, атрибут href для елемента A ). На жаль, використання символу "&" для поділу полів форми впливає на його використання в значеннях атрибутів SGML для поділу посилань на символи . Наприклад, щоб використовувати URI "http: // host /? X = 1 & y = 2" як посилання, його необхідно записати <A href="http://host/?x=1&#38;y=2"> або < A href = "http: // host /? x = 1 & amp; y = 2">.

Ми рекомендуємо розробникам серверів HTTP, і особливо розробникам CGI, забезпечувати підтримку використання ";" замість "&", щоб вирішити для атворов проблему виділення символів "&" в такій манері.

B.3 Зауваження щодо реалізації SGML

B.3.1 Розриви рядків

В SGML (див. [ISO8879] , розділ 7.6.1) зазначено, що розрив рядка, безпосередньо наступний за вихідним тегом, повинен ігноруватися, як і розрив рядка безпосередньо перед кінцевим тегом. Це застосовується до всіх елементів HTML без винятку.

Наступні два приклади коду HTML повинні представлятися однаково:

  <P> Паша дивиться телевізор. </ P>

  <P>
 Паша дивиться телевізор.
 </ P>

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

  <A> Мій улюблений сайт </A>

  <A>
 Мій улюблений сайт
 </A>

B.3.2 Вказівка даних не в форматі HTML

Дані скрипта і стилю можуть бути присутніми як содержімео елемента або значення атрибута. У наступних розділах описано розмежування між розміткою HTML і іншими даними.

вміст елемента  

Якщо дані скрипта або стилю є вмістом елемента ( SCRIPT і STYLE ), дані починаються безпосередньо за початковим тегом елемента і закінчуються першим роздільником ETAGO ( "</"), за яким слідує буква ([a-zA-Z]); зверніть увагу, що це не обов'язково кінцевий тег елемента. Тому авторам слід виділяти послідовності "</ 'у вмісті. Механізми такого виділення специфічні для кожної мови скриптів або таблиць шанували.

  <SCRIPT type = "text / javascript">
  document.write ( "<EM> Так працювати не буде </ EM>")
  </ SCRIPT>

  <SCRIPT type = "text / javascript">
  document.write ( "<EM> Так працювати буде <\ / EM>")
  </ SCRIPT>

  <SCRIPT type = "text / tcl">
  document write "<EM> Це буде працювати <\ / EM>"
  </ SCRIPT>

  "<EM> Це буде працювати <" & Chr (47) & "EM>"

значення атрибутів  

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

• ' "' Має записуватися як" & quot; "або" & # 34; "
• '&' Має записуватися як "& amp;" або "& # 38;"

  <INPUT name = "num" value = "0"
  onchange = "if (compare (this.value, & quot; Довідка & quot;)) {gethelp ()}">

B.3.3 Можливості SGML з обмеженою підтримкою

Системи SGML, відповідні [ISO8879] , повинні розпізнавати ряд можливостей , які не підтримуються всіма агентами користувачів HTML. Авторам рекомендується уникати ісопльзованія цих функцій.

B.3.4 Логічні атрибути

Авторам варто знати, що багато агентів користувачів розпізнають тільки мінімізовану форму логічних атрибутів, але не повну.

 <OPTION selected>

 <OPTION selected = "selected">

B.3.5 Зазначені розділи

Зазначені обрані варіанти грають роль, подібну конструкції #ifdef, яка розпізнається препроцесором мови C.

 <! [INCLUDE [
  <! - Це буде включено ->
 ]]>

 <! [IGNORE [
  <! - Це буде ігноруватися ->
 ]]>

В SGML також визначається використання розмічених розділів для вмісту CDATA, в якому "<" обробляється не як початок тега, наприклад,

 <! [CDATA [
  <An> приклад розмітки <sgml>, що не викликає
  <Проблем> під час запису <і т.д.
 ]]>

Сигнальним символом того, що агент пользвоателя не може розпізнати розмічений розділ, є вистава "]]>", коли агент користувача помилково використовує перший символ ">" як кінець тега, який починається з "<! [".

B.3.6 Інструкції по обробці

Інструкції по обробці - це механізм захоплення платформозавісімих ідіот \ м. Інструкція починається з <? І закінчується символом>

  <?  інструкція>
 

 <?>
 <? Style tt = font courier>
 <? Page break>
 <? Experiment> ... <? / Experiment>

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

B.3.7 Скорочена розмітка

Деякі конструкції SGML SHORTTAG дозволяють заощадити час на набір, але не додають виразних здібностей в додаток SGML. Хоча такі конструкції технічно не вносять двозначності, вони знижують надійність документів, особливо якщо мова розширено і включає нові елементи. Таким чином, в той час як конструкції SHORTTAG SGML, що відносяться до атрибутів, широко використовуються і реалізуються, ті ж конструкції, що відносяться до елементів, не поширені. Використовують їх докменти є відповідними документами SGML, але навряд чи будуть працювати з багатьма існуючими засобами HTML.

конструкції SHORTTAG:

B.4 Зауваження про содейтсвіі пошуковим машинам в індексуванні веб-сайту

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

Визначте мову документа

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

Вкажіть мовні варіанти документа

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

 <LINK rel = "alternate" 
  type = "text / html"
  href = "mydoc-fr.shtml" hreflang = "fr"
  lang = "fr" title = "La vie souterraine">
 <LINK rel = "alternate" 
  type = "text / html"
  href = "mydoc-de.shtml" hreflang = "de"
  lang = "de" title = "Das Leben im Untergrund">

Задавайте ключові слова і описи

Деякі індексуючі машин необхідно проводити пошук елементів META , в яких визначається розділений комами спис ключових слів / фраз або дається короткий опис. Пошукові машини можуть представляти ці ключові слова як результат пошуку. Значення атрибута name , знайдене атрибутом пошуку, не визначається в даній спеціфіаціі. Розглянемо наступні приклади,

 <META name = "keywords" content = "відпустку, Греція, сонце">
 <META name = "description" content = "Ідилічне відпустку в Європі">

Вкажіть початок набору

Набори документів або уявлень систем обробки текстів часто переводяться в набори документів HTML. Для пошукових машин корисно вказати посилання на початок набору на додаток до потрапляння сторінки в результати пошуку. Ви можете допомогти пошуковим машинам з допомогою елемента LINK з атрибутом rel = "begin" і TITLE , як показано в наступному прикладі:

 
 <LINK rel = "begin" 
  type = "text / html"
  href = "page1.shtml" 
  title = "Загальна теорія відносності">

Надайте роботам інструкції по індексації

Люди можуть здивуватися, дізнавшись, що їх сайт проіндексовані роботом, і не отримав доступу до значної частини сайту. Багато Web-роботи пропонують адміністраторам Web-сайтів можливості обмеження дій роботів. Це досягається за допомогою двох механізмів: файлу "robots.txt" і елемента the META в документах HTML, описаного далі.

B.4.1 Пошукові роботи

файл robots.txt  

Коли робот переглядає Web-сайт, наприклад, http://www.foobar.com/, спочатку він перевіряє файл http://www.foobar.com/robots.txt. Якщо цей документ виявлений, він аналізує його вміст і смотрет, чи дозволено завантажити документ. Ви можете налаштувати файл robots.txt тільки для конкретних роботів і заборонити доступ до певних каталогів або файлів.

Ось приклад файлу robots.txt, який забороняє доступ до всього сайт всім роботам

  User-agent: * # застосовується до всіх роботам
  Disallow: / # заборонити індексацію всіх сторінок

Робот просто знайде файл "/robots.txt" URI на Вашому сайті, де сайт - це сервер HTTP, що працює на певній машині і порте. Ось деякі приклади розташування файлу robots.txt:

На одному сайті може бути один файл "/robots.txt". Точніше, не слід поміщати файли "robots.txt" в каталоги користувачів, оскільки робот їх не знайде. Якщо Ви хочете, щоб користувачі могли створювати свої власні файли "robots.txt", потрібно буде об'єднати їх усі в один файл "/robots.txt". Якщо Ви не зробите так, користувачі можуть використовувати замість цього тег Robots META.

Деякі поради: URI враховують регістр, і рядок "/robots.txt" повинна завжди бути в нижньому регістрі. Порожні рядки заборонені.

У кожного запису має бути рівно одне поле "User-agent". Робот повинен вільно інтерпретувати це поле. Рекомендується рядок без урахування регістру, що збігається з ім'ям і не включає інформацію про версії.

Якщо вказано значення "*", запис визначає політику доступу за замовчуванням для будь-якого робота, який відповідає іншим записам. У файлі "/robots.txt" не може бути кілька таких записів.

В поле "Disallow" задається частковий URI, який відвідувати заборонено. Це може бути повний або частковий шлях; будь-URI, що починається з цього значення, не можна буде завантажити. наприклад,

  Disallow: / help забороняє доступ до /help.shtml і /help/index.shtml, в той час як 
  Disallow: / help / заборонить доступ до /help/index.shtml, але дозволить доступ /help.shtml. 

Пусте значення параметра "Disallow" означає, що всі URI можуть завантажуватися. У файлі robots.txt повинно бути принаймні одне поле "Disallow".

Роботи і елемент META  

Елемент META дозволяє авторам документів HTML повідомляти роботам про те, чи може документ бути проіндексовані чи може він використовуватися для отримання додаткових посилань. Для цього не потрібно втручання адміністратора сервера.

 <META name = "ROBOTS" content = "NOINDEX, NOFOLLOW">

B.5 Зауваження про таблиці

B.5.1 Логічне обгрунтування дизайну

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

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

динамічне переформатування  

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

послідовне уявлення  

Для великих таблиць або повільних мережевих СОДІНЕНІЯ дуже важливим є послідовне подання таблиць. Агенти користувачів повинні мати можливість починати відображення таблиці до отримання всіх даних. Ширина вікна за замовчуванням для більшості агентів користувачів становить близько 80 символів, а малюнки для більшості сторінок HTML склад з урахуванням цього числа. Вказуючи число стовпців і включаючи умови управління шириною таблиці і шириною різних стовпців, автори можуть дават агентам користувачів підказки, щоб забезпечити послідовне уявлення вмісту таблиці.

Для послідовного уявлення браузеру необхідно число стовпців і їх ширина. Шириною таблиці за замовчуванням вважається поточний розмір вікна (width = "100%"). Це можна змінити, встановивши атрибут width-TABLE елемента TABLE . За замовчуванням всі стовпці мають однакову ширину, але можна визначити ширину стольбца за допомогою елементів COL до початку таблиці.

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

Авторам і раніше необхідна можливість уведомелнія агентів користувачів про те, чи слід використовувати послідовне уявлення або визначати розмір таблиці автоматично для відповідності осередки. У двухпрохідному режимі автоматичного визначення Рзмер число стовпців визначається на першому проході. У послідовному режимі число стовпців повинна встановлюватися з початку. Має сенс встановити для атрибута cols значення, яка дорівнює кількості стовпців, а не використовувати атрибути "layout" (наприклад, layout = "fixed" або layout = "auto").

Структура і уявлення  

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

Використовувані в даний час видавничі пакети надають дуже багаті можливості за поданням таблиць, і було б непрактично відтворювати ці можливості в HTML без перетворення HTML в складний текстовий формат типу RTF або MIF. Однак, в даній специфікації авторам пропонується можливість вибору з ряду широко використовуються під класів або типів кордону. Атрибут frame управляє зовнішнім виглядом рамки навколо таблиці, в той час як атрибут rules визначає вибір rulings в таблиці. Більш багатий рівень управління буде підтримуватися за допомогою анотацій за поданням. Атрибут style може використовуватися для визначення інформації про подання окремих елементів. Подальша Інфомрация про подання може задаватися за допомогою елемента STYLE в заголовку документа або за допомогою пов'язаних таблиць стилів.

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

Групи рядків і стовпців  

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

Слідуючи моделі таблиць CALS (див. [CALS] ), дана специфікація дозволяє групувати рядки таблиці в розділи заголовка, тіла і нижнього заголовка. Це спрощує надання інформації про відображення і може використовуватися для повторення заголовків таблиці при перенесенні таблиць або для забезпечення постійних заголовків при прокручуваному панелі тіла таблиці. У розмітці розділ нижнього заголовка поміщається перед розділом тіла таблиці. Така оптимізація використовується в CALS для роботи з довгими таблицями. Це дозволяє генерувати нижній заголовок, не чекаючи обробки всієї таблиці.

доступність  

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

B.5.2 Алгоритми рекомендованої компонування

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

Якщо атрибут width не вказано, візуальні агенти користувачів повинні використовувати при форматуванні значення по умочланію - 100%.

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

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

Алгоритм фіксованою компонування  

У цьому алгоритмі вважається, що число стовпців відомо. Ширина стовпців за умовчанням повинна бути однакова. Автори можуть створювати такий псевдонім шляхом вказівки відносної або абсолютної ширини стовпців за допомогою елементів COLGROUP або COL . Ширина таблиці за замовчуванням - все простір між лівим і правим полями, але її можна переобпределіть за допомогою атрибута width елемента TABLE або визначити з абсолютною ширини стовпців. При використанні як абсолютних, так і відносних ширини стовпців, першим кроком є ​​розподіл простору під стовпці з фіксованою шириною. Після цього простір, що залишився ділиться для стовпців з відносною шириною.

Одного тільки сінтакісіса таблиці недостатньо для гарантії відповідності значень атрибутів. Наприклад, число стовпців, яке визначається атрибутом cols, може не збігатися з числом стовпців, що визначаються елементами COL . У свою чергу, це може не відповідати числу стовпців, що визначається з елементів таблиці. Потім проблеми виникають, якщо стовпчики надто вузькі, і вміст не входить в клітинку. Ширина таблиці, зазначена в елементі TABLE element або COL , може привести до переповнення комірки. Агентам користувачів рекомендується коректно виходити і таких ситуацій, наприклад, шляхом перенесення слів і пересортовування і розбивки слів, якщо місця перенесення невідомі.

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

Алгоритм автоматичної компонування  

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

На першому проході перенесення рядків відключений, а агент користувача контролює мінімальну і максимальну ширину кожного осередку. Максимальна ширина визначається найширшої рядком. Оскільки розбивка рядків відключена, абзаци обробляються ка кдлінние рядки, якщо тільки вони не розбиті за допомогою елементів BR . Мінімальна ширина визначається найширшим елементом тексту (словом, зображенням і т.д.) з урахуванням початкових отсутпов, маркерів і т.д. Іншими словами, необхідно визначити мінімальну ширину, яка знадобиться осередку в отдльеном вікні без переповнення. Дозвіл агентам користувачів розбивати слова зменшить необхідність в горизонтальній прокрутці і обрізання вмісту комірки.

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

Для вирівнювання символів вмісту осередки цей алгоритм зберігає три значення мінімуму / максимуму для кожного осередку: Left of align char, right of align char і unaligned. Мінімальна ширина стовпчика: max (min_left + min_right, min_non-aligned).

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

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

Межує таблиці і поля між осередками повинні включатися в призначену ширину стовпців. Є три випадки:

1. Мінімаьлная ширина таблиці дорівнює або перевищує обсяг пам'яті, доступний. В даному випадку призначте мінімальну ширину і дайте користувачам можливість горизонтальної прокрутки. Для перетворення в абетку Бройля потрібно буде замінити осередки посиланнями на повний вміст. За угодою це проводиться перед таблицею.
2. Максимальна ширина таблиці входить в обсяг пам'яті, доступний. В даному випадку встановіть максимальну ширину стовпців.
3. Максимальна ширина таблиці перевищує обсяг пам'яті, доступний, але мінімальна ширина таблиця його не перевищує. В даному випадку знайдіть різницю між доступним простором і мінімальною шириною таблиці, назве її W. Назвемо D різницю між максимальною і мінімальною шириною таблиці.

   Для кожного стовпця зробіть d рівним різниці між максимальною і мінімальнйо шириною цього стовпчика. Потім встановіть ширину стовпця рівній мінімальній ширині плюс d раз по W понад D. Це дозволить зробити стовпчики з більшою різницею між мінімальною і максимальною шириною ширше колонок з мнеьшей різницею.

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

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

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

При використанні двопрохідні алгоритму компоновки положення вирівнювання за замовчуванням під час відсутності явного або успадкованого атрибута charoff може визначатися шляхом вибору позиції, яка була б центром рядки, для якої ширина до і після вирівнюючого символу були б максимальними значеннями для будь-якої з рядків в стовпці, для якого align = "цей символ". Для послідовної компонування таблиць за замовчуванням використовується charoff = "50%". Якщо кілька осередків в різних рядках одного стовпчика використовують вирівнювання, такі осередки повинні вибудовуватися за замовчуванням, незалежно від того, який символ використовується для вирівнювання. Правила обробки об'єктів, занадто великих для стовпчика, застосовуються, якщо явне або успадковане вирівнювання призводить до ситуації, коли дані перевищують призначену ширинустовпця.

B.6 Зауваження про формах

B.6.1 Послідовне відображення

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

Послідовно відображення документів призводить до деяких проблем щодо переміщення по клавіші Tab. Евристика переходу фокуса на tabindex з найнижчим значенням в документі на перший погляд здається досить логічною. Однак це має на увазі необхідність очікування отримання тексту всього документа, оскільки до цього tabindex з найнижчим значенням може змінитися. Якщо пользоваетль натискає клвішу tab до цього, агентам пользоателей має сенс перемістити фокус на нижчий доступний tabindex .

Якщо форми пов'язані з клієнтськими скриптами, можуть виникнути додаткові проблеми. Наприклад, обробник скрипта для даного поля може звертатися до поля, якого ще не існує.

B.6.2 Майбутні проекти

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

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

Іншим можливим розширенням буде додавання атрибута usemap для елемента INPUT для використання в клієнтських навігаційних картах, якщо " type = image". Елемент AREA , відповідний розташування клацання, визначає передане на сервер значення. Щоб уникнути необхідності зміни серверних скриптів він може використовуватися для розширення елемента AREA і вказівки значень x і y для використання в елементі INPUT .

B.7 Зауваження про скрипти

B.7.1 Зарезервований синтаксис для майбутніх макросів скриптів

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

  attribute = "... & {тіло макросу}; ..." 

Практики макросів скриптів в даний час  

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

Обробка атрибутів CDATA відбувається наступним чином:

1. Синтаксичний аналізатор SGML оцінює всі об'єкти SGML (наприклад, "& gt;").
2. Потім ядро ​​скриптів оцінює макроси скриптів.
3. Нарешті, результуючий рядок символів передається в додаток для подальшої обробки.

Обробка макросів відбувається при завантаженні документа (або при перезавантаженні), але не відбувається при зміні розміру документа, перемальовуванні і т.д.

 
 <BODY bgcolor = '& {randomrbg};'>

 
 <BODY bgcolor = '& {if (Date.getHours> 18) ...};'>

 
 <MAP NAME = foo>
  <AREA shape = "rect" coords = "& {myrect (imageuri)};"  href = "& {myuri};"  alt = "">
  </ MAP>

 
 <IMG src = "bar.gif" width = '& {document.banner.width / 2};'  height = '50% 'alt = "банер">

  <SCRIPT type = "text / javascript">
  function manufacturer (widget) {
  ...
  }
  function location (manufacturer) {
  ...
  }
  function logo (manufacturer) {
  ...
  }
  </ SCRIPT>
  <A Href='&{location(manufacturer("widget"))};'> widget </A>
  <IMG src = '& {logo (manufacturer ( "widget"))};'  alt = "logo">

 
 <IMG src = "& {logo (manufacturer (& quot; widget & quot;))};"  alt = "logo">

B.8 Зауваження про фрейми

Оскільки Унійних імені цільового фрейму не гарантована, воно підходить для опису поточної практики пошуку фрейму з даними цільовим ім'ям :

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

B.9 Зауваження про доступність

Якщо автор не встановив атрибут alt для елемента IMG або APPLET , агенти користувача повинні самі ставити альтернативний текст, який вираховується в наступному порядку:

1. Якщо вказано title , в якості альтернативного тексту повинно використовуватися значення цього атрибута.
2. В іншому випадку, якщо інформація про заголовку дається в заголовках HTTP при завантаженні включеного об'єкта, в якості альтернативного тексту повинна використовуватися ця інформація.
3. В іншому випадку, якщо у включеному об'єкті є текстові поля (наприклад, зображення GIF мають тектсовие поля), інформація, витягнута з текстових полів, повинна використовуватися в якості альтернативного тексту. Оскільки агентам користувачів для отримання текстової Інфомрация може знадобитися завантаження всього об'єкта, вони можуть використовувати економічніші підходи (наприклад, обговорення вмісту).
4. В іншому випадку, якщо відсутня будь-яка інша інформація, агент користувача повинен використовувати в якості альтернативного тексту ім'я файлу (без розширення).

Якщо автор не встановив атрибут alt для елемента INPUT , агенти пользователяей повинні обчислювати альтернативний текст в наступному порядку:

1. Якщо вказано title , в якості альтернативного тексту повинно використовуватися його значення.
2. В іншому випадку, якщо зазначений атрибут name , в якості альтернативного тексту повинно використовуватися його значення.
3. В іншому випадку (кнопки відправки і скидання) в якості альтернативного тексту повинно використовуватися значення атрибута type.

B.10 Зауваження про захист

Якоря, впроваджені зображення і всі інші елементи, що містять URI в якості параметрів, можуть привести до разименовиванію URI у відповідь на введення користувача. В даному випадку слід розглянути питання, описані в [RFC1738] , розділ 6. Широко використовуються методи відправлення запитів форми - HTTP і SMTP - забезпечують невисокий ступінь конфіденційності. Провайдери інформації, що запитують через форми важливу інформацію - особливо за допомогою елементів INPUT , type = "password" - повинні попереджати своїх користувачів про невиосокй ступеня захисту.

B.10.1 Питання захисту для форм

Агент користувача не повинен відправляти файли, відправку яких користувач не запросив явно. Таким чином, агенти користувачів HTML повинні підтверджувати всі імена файлів, які використовуються по умочланію, які можуть бути вказані в атрибуті value елемента INPUT . У скріитих керуючих елементах імена файлів вказувати не потрібно.

В даній специфікації не міститься механізму шифрування даних; воно повинно проводитися будь-якими іншими механізмами захищеної передачі даних.

Після завантаження файлу обробляє агент повинен відповідним чином обробити і зберегти файл.