XHTML™ Basic 1.1 - Друге Видання
Цей документ є не офіційним перекладом початкової
англійської версії
. Зверніть увагу на те, що оригінальна версія документа існує
тільки
англійською мовою. Цей переклад може містити неточності та помилки. Переклад виконав
Зайцев Дмитро
, 2011. за підтримкою сайту
latex pillow
. Коментарі до перекладу залишайте
тут
! | |
На головну
XHTML
Basic 1.1 - Друге Видання
Рекомендація W3C від 23 листопада 2010
Поточна версія:
Остання версія:
Попередня версія:
Версія з зазначеними відмінностями від попередньої версії:
xhtml-basic-diff.html
Попередня рекомендація:
Версія з зазначеними відмінностями від попередньої версії:
xhtml-basic-rec-diff.html
Редактори:
Шейн Мак-Керрон (Shane McCarron)
Applied Testing and Technology, Inc.
shane@aptest.com
Версія 1.1 Редактори:
Шейн Мак-Керрон (Shane McCarron)
, Applied Testing and Technology, Inc.
Масаясу Ішікава (Masayasu Ishikawa)
, (до березня 2007 року, за W3C)
Версія 1.0 Редактори:
Марк Бейкер (Mark Baker)
, Sun Microsystems
Масаясу Исикава (Masayasu Ishikawa)
, (до березня 2007 року, за W3C)
Шинічі Мацуї (Shinichi Matsui)
, Panasonic
Пітер Старк (Peter Stark)
, Ericsson
Тед Вугофскі (Ted Wugofski)
, Openwave Systems
Тошіхіко Ямакамі (Toshihiko Yamakami)
, ACCESS
Co.
Ltd.
Будь ласка, зверніться до сторінки
виправлень
для цього документа, де можуть бути приведені нормативні зміни до поточного документа. Див. також
переклади
Цей документ, також доступний в таких ненормативних форматах як:
PostScript версія
PDF
версія
ZIP архів
, та
Gzip TAR архів
W3C
MIT
ERCIM
Keio
), Всі права захищені. W3C дотримується правил
відповідальності
торгівельної марки
та
використання документів
Анотація
Тип документу
XHTML
Basic включає в себе мінімальний набір модулів, необхідних для типу документа який приймає мову
XHTML
(Розширювана мова розмітки гіпертексту), окрім того, він включає в себе зображення, форми, прості таблиці та підтримку об'єктів. Він призначений для веб-клієнтів, які не підтримують повний набір можливостей
XHTML
; наприклад, такі веб-клієнти як мобільні телефони, КПК (
PDA
), пейджери, та телеприставки. Даний тип документа надає досить широкі можливості для написання документацій.
XHTML
Basic розроблений в якості загальної бази, яка може бути розширена при потребі. Мета
XHTML
Basic полягає в тому, щоб служити спільною мовою, яка підтримує різні види програм користувача.
Дана версія (1.1, Друге видання), замінює собою версію 1.1, як це зазначено в
. До цієї ревізію, були додані схеми XML та
lang
атрибут. У оновлення з версії 1.0 до версії 1.1, були включені в мову декілька нових функцій, щоб краще обслуговувати спільноти малих пристроїв, які є одними з основних споживачів цієї мови:
Форми XHTML (визначені у [
XHTMLMOD
])
Внутрішні події (визначені у [
XHTMLMOD
])
Значення атрибуту для елемента
li
(визначено у [
XHTMLMOD
])
Цільовий атрибут (визначено у [
XHTMLMOD
])
Стиль елементу (визначено у [
XHTMLMOD
])
Стиль атрибуту (визначено у [
XHTMLMOD
])
XHTML презентація модуля (визначено у [
XHTMLMOD
])
InputMode атрибут (визначено у
Розділі 5
даного документу)
Визначення типу документа реалізується за допомогою
XHTML
модулів, як це визначено в "
Модулярізація
XHTML
" [
XHTMLMOD
].
Статус цього документу
Цей розділ описує статус даного документу на момент його публікації. Інші документи можуть заміняти цей документ. Зі списком поточних публікацій W3C та останньою ревізією цієї технічної доповіді можна ознайомитися в
індексі технічних доповідей W3C
на http://www.w3.org/TR/.
Цей документ є Рекомендацією W3C та замінює собою версію рекомендації XHTML Basic від
29 липня 2008
. Він відображає міжгалузеву угоду про безліч можливостей мови розмітки, які дозволяють авторам створювати більш якісні мережеві документи, що поставляються для широкого спектру пристроїв. Єдиними змінами в цій версії, є додавання реалізації XML Schema в мові розмітки та інтеграції
lang
для забезпечення кращої сумісності з програмами, призначеними для користувача, та допоміжними технологіями. Версія, яка показує конкретні зміни від попередньої рекомендації, доступна у
формі із зазначеними відмінностями
Цей документ був підготовлений
Робочою Групою
W3C
XHTML2
у рамках
діяльності
W3C
HTML
. Будь ласка, подивіться
Будь ласка, подивіться
даного документа Робочої Групою.
Будь ласка, надсилайте коментарі з цього документу, за адресою
www-html-editor@w3.org
архів
). За цією адресою недоречно відправляти електронні листи для обговорення. Листи для публічних обговорень надсилайте за адресою
www-html@w3.org
архів
).
Цей документ був розглянутий членами W3C, розробниками програмного забезпечення, а також іншими групами W3C й зацікавленими сторонами, та схвалений Директором у якості Рекомендації W3C. Це стабільний документ і може бути використаний в якості довідкового матеріалу або цитат в іншому документі. Роль W3C у розробці Рекомендації, полягає в залученні уваги до специфікації, і сприяти її широкому поширенню. Це підвищує функціональність і сумісність у Веб (Web)
Цей документ був підготовлений групою, що діє в рамках
патентної політики W3C від 5 лютого 2004 року
. W3C підтримує
публічний перелік відкритих патентів
зроблений у зв'язку з результатами діяльності групи; ця сторінка також включає в себе інструкції з розкриття патенту. Особи, що володіють актуальною інформацією про патент, що задовольняє
основним вимогам
, повинні розкрити цю інформацію згідно з
пунктом 6 патентної політики W3C
Зміст
1.
Вступ
1.1.
XHTML
для невеликих інформаційних пристроїв
1.2.
Передумови та вимоги
1.3.
Логічне обгрунтування
2.
Відповідність
2.1.
Відповідність документів
2.2.
Відповідність програм користувача
3.
Тип документу
XHTML
Basic
4.
Як використовувати
XHTML
Basic
5.
XHTML inputmode модуль
5.1.
Синтаксис значення атрибуту InputMode
5.2.
Поведінка клієнтської програми
5.3.
Перелік лексем
5.4.
Відношення граней моделі до XML Schema
5.5.
Приклади
6.
Вдячності
A.
Посилання
A.1.
Нормативні посилання
A.2.
Довідкові посилання
B.
Визначення типу документа
XHTML
Basic
B.1.
Запис для
XHTML
Basic у відкритому каталозі
SGML
B.2.
Драйвер
XHTML
B.3.
Налаштування
XHTML
Basic
C.
Визначення XML Schema в
XHTML
Basic
C.1.
Драйвер XML Schema в
XHTML
Basic
C.2.
Модулі схеми в
XHTML
Basic
C.3.
Налаштування
XHTML
Basic
1. Вступ
1.1.
XHTML
для невеликих інформаційних пристроїв
HTML
4 є потужною мовою для створення веб-документів, але його схема не бере до уваги проблеми, що стосуються невеликих пристроїв, у тому числі витрати на реалізацію (в потужності, пам'яті і
т.і.
) повного набору функцій.
Споживчі пристрої з обмеженими ресурсами в цілому не можуть собі дозволити забезпечувати виконання повного набору функцій
HTML
4. Оскільки, для доступу до Всесвітньої мережі потрібно повноцінний комп'ютер, велика кількість людей не може отримати оперативну інформацію та послуги за допомогою своїх споживчих пристроїв.
Оскільки, є багато різних способів як розбити на підмножини
HTML
, тому існує багато практично ідентичних підмножин визначені організаціями та компаніями. Без загальних базових наборів функцій, складно розробляти програми для широкого кола мережних клієнтів.
Сенс
XHTML
полягає в наданні такого типу документа
XHTML
, який може бути загальним для всіх спільнот
наприклад
, настільними комп'ютерами,
ТВ
, та мобільними телефонами), і цього буде більш ніж достатньо, щоб застосовуватися для створення простих документів. Нові типи документів для різних спільнот можуть бути визначені шляхом розширення
XHTML
Basic, таким чином, що документи на
XHTML
Basic входили би до числа коректних документів нового типу документа. Таким чином, документ
XHTML
Basic може бути представлений на максимальну кількість веб-клієнтів.
Визначення типу документа для
XHTML
Basic здійснюється на основі модулів
XHTML
визначених у Модулярізації
XHTML
XHTMLMOD
].
Для отримання інформації про найкраще застосування мобільного контенту, ви можете звернутися до[
MOBILEBP
].
1.2. Передумови та вимоги
Інформаційні пристрої орієнтовані для певних цілей. Вони підтримують особливості, необхідні їм для виконання функцій, для яких вони створювалися. Нижче наведені приклади різних інформаційних пристроїв:
Мобільні телефони
Телевізори
КПК
Торгівельні автомати
Пейджери
Автомобільні навігаційні системи
Мобільні ігрові автомати
Пристрої читання цифрових книг
Інтелектуальні годинники
Існуючі підмножини та варіанти
HTML
для цих пристроїв, включають в себе, Компактний
HTML
CHTML
], Мова розмітки для бездротових пристроїв [
WML
], та "Інструкції
HTML
4.0 для мобільного доступу" [
Інструкції
]. Спільними рисами цих типів документа є:
Простий текст (включаючи заголовки, абзаци та списки)
Гіперпосилання та посилання на відповідні документи
Прості форми
Прості таблиці
Зображення
Метаінформація
Цей набір особливостей
HTML
був відправною точкою для створення
XHTML
Basic. Оскільки багато розробників документів знайомі з цими особливостями
HTML
, вони складають корисну приймаючу мову, яку можна поєднувати з розміткою модулів з інших мов відповідно до методів, зазначеними в "
Модулярізації
XHTML
" [
XHTMLMOD
]. Так, наприклад,
XHTML
Basic може бути розширений за допомогою користувацького модуля для підтримки більш широкої семантики розмітки в певних умовах.
Мета
XHTML
Basic не полягає в тому, щоб обмежити функціональність майбутніх мов. Але оскільки, елементи в
HTML
4 (фрейми, розширені таблиці,
та інші
) були розроблені для такого типу клієнта як персональний комп'ютер, вони виявилися непридатними для багатьох не настільних пристроїв.
XHTML
Basic буде розширюватися, і використовуватися за основу. Розширення
XHTML
з загальними і основними наборами функцій, замість практично ідентичних підгруп або занадто великого набору функцій в
HTML
4, буде корисним, як для взаємодії в Мережі, так і для забезпечення масштабованості.
У порівнянні з багатою функціональністю
HTML
4,
XHTML
Basic може виглядати як крок назад, але насправді, це два кроки вперед для клієнтів, яким не потрібні всі функції
HTML
4 та для розробників документів, які отримують одну підмножину
XHTML
замість декількох.
1.3. Логічне обгрунтування
Цей розділ пояснює, чому деякі особливості
HTML
не є частиною
XHTML
Basic.
1.3.1. Презентація
Багато простих веб-клієнтів, які можуть відображати тільки шрифт фіксованої ширини. Двонаправлений текст, жирний шрифт та інші елементи текстових розширень також не підтримуються.
При створенні презентацій, рекомендується, щоб використовувалися таблиці стилів, які підходять пристрою.
1.3.2. Таблиці
Прості таблиці
XHTML
([
XHTMLMOD
], розділ 5.6.1) підтримуються, але можуть виникнути труднощі при відображенні таблиць на маленьких пристроях. Рекомендується, щоб розробники контенту слідували Принципам доступності мережевих документів 1.0 при
створенні доступних таблиць
([
WCAG10
], принцип 5). Зауважте, що в Модулі простих таблиць вкладені таблиці неприпустимі.
1.3.3. Фрейми
Фрейми не підтримуються. Фрейми залежать від інтерфейсу екрану і не можуть застосовуватися в деяких невеликих приладах, таких як телефони, пейджери та годинник.
2. Відповідність
Цей розділ є
нормативним.
2.1. Відповідність документів
Відповідним документом
XHTML
Basic є документ, який вимагає тільки засоби, описані в якості обов'язкових в даній специфікації. Такий документ повинен відповідати всім наступним критеріям:
Документ повинен відповідати обмеженням, виражених в
Додатку B
та
Додатку C
Кореневим елементом документа повинен бути

Назвою простору імен за умовчанням в кореневому елементі має бути назвою простору імен
XHTML
Відкриваючий тег МОЖЕ також містити декларацію XML Schema, як зразок простору імен та XML Schema, як зразок атрибуту
schemaLocation
XMLSCHEMA
]. Такий атрибут буде асоціювати простір імен XHTML
зі схемою XML при URI
Кореневому елементу в документі має передувати декларація DOCTYPE. ППублічний ідентифікатор, якщо такий є, включений в декларацію DOCTYPE повинен посилатися на
DTD
, що знаходиться у
Додатку B
, використовуючи свій Формальний Публічний Ідентифікатор. Системний ідентифікатор може бути змінений відповідним чином.
"http://www.w3.org/TR/xhtml-basic/xhtml-basic11.dtd">
Підмножина
DTD
не повинна бути використана для зміни будь-якого параметру сутностей у
DTD
Документи XHTML Basic 1.1 ПОВИННІ бути позначені відповідно до MIME-типу "application/xhtml+xml", як це визначено в [
RFC3236
]. За додатковою інформацією щодо використання типів вмісту з XHTML, дивіться інформаційну примітку [
XHTMLMIME
].
2.2. Відповідність програм користувача
Програми, які призначені для користувача, повинні відповідати розділу "
Відповідність програм призначених для користувача
" специфікації
XHTML
1.0 ([
XHTML1
], розділ 3.2).
3. Тип документу
XHTML
Basic
Цей розділ є
нормативним
Тип документу
XHTML
Basic визначен як набір модулів
XHTML
Усі модулі
XHTML
визначені в специфікації "
Модулярізація
XHTML
" [
XHTMLMOD
].
XHTML
Basic складається з наступних модулів
XHTML
Структурний модуль*
body, head, html, title
Текстовий модуль*
abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var
Гіпертекстовий модуль*
Модуль списків*
dl, dt, dd, ol, ul, li
Модуль форм
button, fieldset, form, input, label, legend, select, optgroup, option, textarea
Модуль простих таблиць
caption, table, td, th, tr
Модуль зображень
img
Модуль об'єктів
object, param
Модуль презентацій
b, big, hr, i, small, sub, sup, tt
Модуль метаінформації
meta
Модуль link
link
Модуль base
base
Модуль внутрішніх подій
атрибути подій
Модуль сценаріїв
script
та
noscript
елементи
Модулі таблиці стилів
style
елемент
Модуль атрибуту стилю
Застаріле
style
атрибут
Модуль target
target
атрибут.
Примітка:
Цільовий атрибут розроблений для того, щоб бути загальною ланкою у зв'язуванні з зовнішнім середовищем (наприклад, фрейми, багатократні вікон, вікна браузера з вкладками); при відсутності такого зовнішнього середовища пов'язаного програмою призначеною для користувача, така програма може ігнорувати цільової атрибут. При наявності такого пов'язаного зовнішнього середовища, відповідність вимогам для цільового атрибуту визначені в кожному середовищі.
Автор документів повинен знати, що поведінка призначеної для користувача програми, для цільового атрибуту, залежить від багатьох факторів, таких як існування прив'язки середовища, обмеження доступних ресурсів, існування інших прикладних програм та налаштувань користувача (наприклад, pop-up блокувальники), та залежні від реалізації проектних рішень. При відсутності відповідності зовнішнього середовища, рекомендується, щоб автори не залежали від використання цільового атрибута.
Слід відзначити, що будь-яке залежне від реалізації використання цільового атрибуту могло б перешкоджати функціональної сумісності.
Ця специфікація також додає, що
lang
атрибут, приписують до набору атрибуту I18N, як визначено в
XHTMLMOD
. Атрибут
lang
визначається в
HTML4
. Коли цей атрибут і атрибут
xml:lang
визначаються у тому ж самому елементі, атрибут
xml:lang
має пріоритет. Коли обидва атрибута
lang
xml:lang
визначаються у тому ж самому елементі, у них ПОВИННО бути те ж саме значення.
(*) = Цей модуль є необхідним модулем
Базового мови XHTML
XHTML Basic також, використовує
модуль атрибуту inputmode XHTML
, як зазначено в цій специфікації. Цей модуль додає атрибут
inputmode
до елементів
input
textarea
модуля форм XHTML.
Нарешті, XHTML Basic додає атрибут
value
до елемента
li
модуля списку XHTML.
XML
1.0
DTD
доступний у
Додатку B
. Реалізація
XML
Schema доступна в
Додатку C
4. Як використовувати
XHTML
Basic
Хоча
XHTML
може використовуватися, як - проста мова
XHTML
з текстом, посиланнями, і зображеннями - призначення його простої схеми в тому, щоб використовуватися в якості базової мови. Базова мова може містити суміш словників, зібраних в один тип документа. Природно, що
XHTML
є базовою мовою, так як це те, до чого звикла більшість Веб-розробників.
При додаванні розмітки з інших мов до
XHTML
Basic, внаслідок цього тип документа буде розширенням
XHTML
Basic. Розробники документів можуть розробляти документи для
XHTML
Basic або скористатися перевагами розширень. Мета
XHTML
Basic полягає в тому, щоб служити спільною мовою, яка підтримує різні види програм користувача.
5. Модуль атрибуту inputmode XHTML
Цей розділ є
нормативним
Цей розділ спочатку був компонентом
XForms 1.0
, і був написаний Мартіном Дерстом.
Модуль атрибуту inputmode визначено, як
inputmode
атрибут.
inputmode = CDATA
Цей атрибут визначає тип інформації для поточного елемента.
У наступній таблиці наведено додаткові атрибути для елементів, визначених у іншому місці, коли модуль inputmode вибраний.
Елементи
Атрибути
Примітки
input&
inputmode (
CDATA
Коли базові форми або модуль форм обрані.
textarea&
inputmode (
CDATA
Коли базові форми або модуль форм обрані.
Атрибут
inputmode
надає
підказку
програмі користувача, щоб обрати відповідний режим введення, для введення тексту, який очікується у зв'язаному управлінні формою. Режим вводу може бути конфігурацією клавіатури, редактор засобів вводу (також, називається інтерфейс процесора) або будь-які інші налаштування, пов'язані з вводом на пристроях, що використовуються.
Використовуючи
inputmode
, автор може дати підказку програмі, яка спрощує введення форми користувачем. Автори повинні надавати атрибути
inputmode
там, де це можливо, переконавшись, що значення які використовуються, охоплюють широкий спектр пристроїв.
5.1 Синтаксис значення атрибуту
inputmode
Значення атрибуту
inputmode
є розділений пробілом список лексем. Лексема це послідовність літер алфавіту або абсолютні URI. Пізніше, можуть бути відокремлені лексеми від попередніх, зазначивши, що абсолютні посилання URI містять ':'. Лексеми чутливі до регістру. Всі лексеми, що складаються з літер алфавіту, визначені тільки в цій специфікації, в
5.3 Перелік лексем
(або наступника цієї специфікації).
Ця специфікація не визначає URI для використання їх як лексем, але дозволяє іншим визначати такі URI для розширення. Це може стати необхідним для пристроїв з режимами вводу, які не можуть бути покриті лексемами, визначеними тут.
URI повинен разіменовуватися до зрозумілому людині опису режиму ввода, пов'язаного з використанням URI в якості послідовності символів. Цей опис має описувати режим вводу, зазначений цією послідовністю символів, і де і як ця послідовність символів змінює інші лексеми, або сама змінюється іншими лексемами.
5.2 Поведінка клієнтської програми
При вводі в порожній елемент керування форми з атрибутом
inputmode
, клієнтська програма має обрати режим вводу, який вказаний у значенні атрибута
inputmode
. Клієнтські програми не повинні використовувати атрибут
inputmode
, щоб встановити режим вводу, коли елемент форми управління для вводу з текстом вже існує.
Щоб встановити відповідний режим вводу, коли елемент форми керування для вводу вже містить текст, клієнтські програми повинні спиратися на специфічні для платформи угоди.
Клієнтські програми повинні надавати всі режими вводу, які підтримуються (операційної) системою/пристроєм, якій вони запущені/до якого вони мають доступ, і які встановлені для постійного використання користувачем. Як правило, це тільки невелика частина режимів вводу, які можуть бути описані за визначеними в даній специфікації лексемами.
Зауваження:
Додаткові керівництва для реалізації клієнтської програми, можна знайти в
[UAAG 1.0]
Наступний простий алгоритм використовується, щоб визначити, як клієнтські програми порівнюють значення атрибуту
inputmode
до режимів вводу, які вони можуть забезпечити. Цей алгоритм не повинен здійснюватися безпосередньо; клієнтські програми повинні чинити так, якщо б вони використовували його. Алгоритм не призначений, щоб привести до "очевидних" або "бажаних" результатам для всіх можливих комбінацій лексем, але, у всіх випадках, призначений для отримання передбачуваної та правильної поведінки для часто зустрічаючихся комбінацій лексем.
По-перше, кожен з доступних режимів вводу представлений одним або кількома списками лексем. Режим введення може відповідати більше ніж одному списку лексем; наприклад, в системі, встановленої для грецького користувача, і "Грецький Верхній регістр" і "Користувацький Верхній регістр" будуть відповідати тому ж режиму введення. Не буде двох однакових списків.
По-друге, атрибут
inputmode
відсканований по всій довжині. Для кожного символу
в атрибуті
inputmode
, якщо в списках лексем, що залишаються, які мають доступні режими введення існує список лексем, який містить
, тоді всі списки лексем які мають доступні режими вводу та не містять
видаляються. Якщо список лексем, що містить символ
відсутній, тоді
буде проігноровано.
По-третє, якщо залишилися один або кілька списків лексем, і всі вони відповідають тим же режимам вводу, тоді буде обрано цей режим вводу. Якщо не залишився ні один зі списків (це означає, що його не було при запуску алгоритму), або якщо інші списки відповідають більш ніж одному режиму ввода, тоді жоден режим вводу не буде обраний.
Приклад: Припустимо, що список, списків лексем які мають доступні режими вводу, є: {"Кирилиця Великі літери", "Кирилиця малі літери", "кирилиця", "латина", "користувацькі Великі літери", "користувацькі малі літери"}, тоді такі значення
inputmode
обирають наступні режими: "кирилічний заголовок" обирає "кирилиця", "Кирилиця малі літери" обирає "Кирилиця малі літери", "малі літери Кирилиця" обирає "Кирилиця малі літери", "латинський Великі літери" обирає "латинь", але "Великі літери латинський" робить вибір між "Кирилиця Великі літери" та "Користувацькі Великі літери", якщо вони відповідають тому ж самому режиму ввода, і не обирає жоден режим ввода, якщо "Кирилиця Великі літери" та "Користувальницькі Заголовні літери" не відповідають тому ж самому режиму ввода.
5.3 Перелік лексем
Лексеми, визначені в даній специфікації, поділяються на дві категорії:
лексеми сценарію
та
модифікатори
. У атрибутах
inputmode
, лексеми сценарію завжди повинні перераховуватися перед модифікаторами.
5.3.1 Лексеми сценарію
Лексеми сценарію забезпечують загальне уявлення про набір символів, який охоплений режимом режимом вводу. У більшості випадків, лексеми сценарію відповідають безпосередньо
[Unicode
Scripts]
. Деякі лексеми співпадають з назвами блоку в Java-класі java.lang.Character.UnicodeBlock (
[Java Unicode Blocks]
) або з назвами блоку Unicode. Проте це ні як не означає те, що режим вводу повинен дозволити ввід всіх символів у скрипті або блоці, і також не означає, що режим вводу обмежується лише символами з конкретного сценарію. Наприклад, "Латинська" клавіатура не охоплює всі символи латиниці, і включає в себе знаки пунктуації, які не віднесені до латині.
Імена сценаріїв були взяті з версії 3.2 стандарту Unicode.
Лексема режиму ввода
Коментарі
arabic
Ім'я сценарію Unicode
armenian
Ім'я сценарію Unicode
bengali
Ім'я сценарію Unicode
bopomofo
Ім'я сценарію Unicode
braille
використовується для введення шаблонів шрифту Брайля (не для вказівки пристрою вводу даних шрифту Брайля)
buhid
Ім'я сценарію Unicode
canadianAboriginal
Ім'я сценарію Unicode
cherokee
Ім'я сценарію Unicode
cyrillic
Ім'я сценарію Unicode
deseret
Ім'я сценарію Unicode
devanagari
Ім'я сценарію Unicode
ethiopic
Ім'я сценарію Unicode
georgian
Ім'я сценарію Unicode
greek
Ім'я сценарію Unicode
gothic
Ім'я сценарію Unicode
gujarati
Ім'я сценарію Unicode
gurmukhi
Ім'я сценарію Unicode
han
Ім'я сценарію Unicode
hangul
Ім'я сценарію Unicode
hanja
Підмножина 'han' використовується у письмовому Корейському
hanunoo
Ім'я сценарію Unicode
hebrew
Ім'я сценарію Unicode
hiragana
Ім'я сценарію Unicode (може включати в себе інші японські сценарії, вироблені шляхом конвертації з хірагани)
ipa
Міжнародна фонетична транскрипція
kanji
Підмножина 'han' використовується в письмовій формі японського
kannada
Ім'я сценарію Unicode
katakana
Ім'я сценарію Unicode (повної ширини, не напівширина)
khmer
Ім'я сценарію Unicode
lao
Ім'я сценарію Unicode
latin
Ім'я сценарію Unicode
malayalam
Ім'я сценарію Unicode
math
математичні символи та пов'язані з ними символи
mongolian
Ім'я сценарію Unicode
myanmar
Ім'я сценарію Unicode
ogham
Ім'я сценарію Unicode
oldItalic
Ім'я сценарію Unicode
oriya
Ім'я сценарію Unicode
runic
Ім'я сценарію Unicode
simplifiedHanzi
Підмножина 'han' використовується в письмовій формі спрощеного китайського
sinhala
Ім'я сценарію Unicode
syriac
Ім'я сценарію Unicode
tagalog
Ім'я сценарію Unicode
tagbanwa
Ім'я сценарію Unicode
tamil
Ім'я сценарію Unicode
telugu
Ім'я сценарію Unicode
thaana
Ім'я сценарію Unicode
thai
Ім'я сценарію Unicode
tibetan
Ім'я сценарію Unicode
traditionalHanzi
Підмножина 'han' використовується в письмовій формі традиційного китайського
user
Особливе значення, що означає 'рідний' ввід користувача (наприклад, для введення її імені або тексту рідною мовою).
yi
Ім'я сценарію Unicode
5.3.2 Лексеми модифікатору
Лексеми модифікатору можуть бути додані до сценаріїв, які вони застосовують, щоб більш близько визначити вид символів, очікуваних в управлінні формою.
Традиційні комп'ютерні клавіатури не потребують більшості лексем модифікатору (дійсно, користувачі на таких пристроях були б досить здивовані, якби програмне забезпечення вирішило змінити регістр самостійно; CAPS lock для верхнього регістру може бути винятком).
Однак, лексеми модифікатору можуть бути дуже корисними, щоб встановити режими вводу для маленьких пристроїв.
Лексема режима вводу
Коментарі
lowerCase
нижній регістр (для двопалатних сценаріїв)
upperCase
верхній регістр (для двопалатних сценаріїв)
titleCase
регістр заголовку (для двопалатних сценаріїв): слова починаються з великих літер
startUpper
ввід починається із однієї великої літери, а потім продовжується з малими літерами
digits
цифри певного сценарію (наприклад, inputmode='thai digits')
symbols
символи, знаки пунктуації (підходить для конкретного сценарію)
predictOn
Текстовий прогноз ввімкнено (наприклад, для робочого тексту)
predictOff
Текстовий прогноз вимкнуто (наприклад, для паролів)
halfWidth
напівширина сумісності форм (наприклад, Katakana; застаріле)
5.4 Відношення граней моделі до XML Schema
Клієнтські програми можуть використовувати інформацію доступну в гранях моделі XML Schema, щоб встановити режим вводу. Відзначимо, що гранню моделі є жорстке обмеження на лексичне значення екземпляру вузла даних, і можна задати різні обмеження для різних частин елементу даних. Атрибут
inputmode
є м'якою підказкою про види символів, які користувач може, цілком ймовірно, вводити у форму. Атрибут
inputmode
надається в доповнення до граней моделі з наступних причин:
Набір допустимих символів, визначених у моделі, може бути настільки широким, що стає не можливо, вивести розумну установку режиму ввода. Однак, часто є свого роду символи, які будуть введені користувачем з високою ймовірністю. У такому випадку,
inputmode
дозволяє встановлювати режим вводу для зручності користувача.
У деяких випадках, можна було б отримати вхідний режим налаштування з моделі, тому що безліч символів, дозволених в моделі, тісно узгоджуються з великою кількістю символів, які охоплюються значенням атрибуту
inputmode
. Однак, таке утворення вимагає багато даних і розрахунків в призначеній для користувача програмі.
Малі пристрої можуть залишити перевірки моделей на сервері, але з легкістю зможуть перейти на ті вхідні режими, які вони підтримують. Можливість зробити ввід даних для користувачів простіше, має особливе значення на невеликих пристроях.
5.5 Приклади
Це приклад форми для вводу японської адреси.
Family name:
(in kana):
Given name:
(in kana):
Postal code:
Address:
(in kana):
Email:
Telephone:
Comments: