Бъдещето на Мрежата: XHTML 2.0. От Никълъс Чейс.
През годините HTML винаги ставаше все по-голям, никога по-малък, защото новите версии трябваше да поддържат съвместимостта със старите версии. Това ще се промени. На 5 август 2002 година, беше пусната първата работна чернова на XHTML 2.0 и голямата новина е, че съвместимостта с предишните версии отпада; езикът най-накрая може да продължи да се развива. И така, какво получава в замяна уеб разработчикът? Какво ще кажете за работещи форми и events, по-добър поглед върху фреймовете и дори йерархични менюта, които не изискват огромни количества JavaScript.
Тази статия хвърля предварителен поглед върху новите неща в XHTML 2.0 и как някой ден ще може да ви свърши работа. Читателите тярбва да са запознати с HTML и/или XHTML 1.0. Разбирането на Cascading Style Sheets (CSS) би било полезно, но не е задължително.
Сбогом съвместимост с предишните версии, здравей структура
Когато на 5 август 2002 World Wide Web Consortium (W3C) пусна първата работна чернова на XHTML 2.0, голямата изненада беше, че за разлика от неговите предшественици, липсва съвместимост с предишните версии. При предишните излизането на предишните препоръки, както беше при прехода между HTML 4.01 към XHTML 1.0 и по-късно към XHTML 1.1, промените се състояха в някои добавки; браузър, който можеше да чете XHTML 1.0 Transitional документи можеше да разбира също и HTML 4.01 документи. Нещата не стоят така с XHTML 2.0.
Ако преди две години бихте заявили, че днес ще видим една версия на HTML без таговете img и bold, огромното мнозинство от уеб разработчици биха ви погледнали с недоверие. Но ето, че това е факт. Не само, че XHTML 2.0 замества и формите, и фреймовете, но и премахва таговете b, i и img (също big, small и tt), и дори не одобрява br в подготовка на пълното му изхвърляне от една бъдеща версия. Но защо?
Причината е, че повечето от тези тагове са за представяне. Тяхната единствена цел е да дават инструкции на браузъра как трябва да изглежда съдържанието им, без да дават абсолютно никаква информация за това какво представлява съдържанието им. Ето например, да вземем тези две изречения:
Presentational elements are, <i>for the most part</i>, <b>gone</b>.
и
Presentational elements are, <em>for the most part</em>, <strong>gone</strong>.
Ако липсват стилове, изреченията изглеждат по един и същи начин в браузърите, но само второто дава информация защо. Всъщност, таговете em и strong присъстват в HTML от самото начало, но в продължение на години авторите до голяма степен ги пренебрегват, концентрирайки се върху външния вид за сметка на съдържанието.
Това не означава, обаче, че ако искате нещо да бъде удебелено или в курсив трябва да го подковете с тези два тага. Вместо това, цялата идея на изхвърлянето на презентационните елементи е да се завърши работата, която хората, изобретили CSS, започнаха, а именно съдържанието да бъде обозначавано с такъв код, който съответства на онова, което бива представяно; за да се направи нещо красиво трябва да се използват стилове. Например, Пример 1 използва класове, за да обозначава видовете съдържание.
Пример 1. Използване на стилове за задаване на видове съдържание
<html>
<head><title>Employee Notice</title>
<style type="text/css">
.duedate { color: red;
font-weight: bold; }
.holiday { color: green;
font-style: italic }
</style>
</head>
<body>
<h1>Notice</h1>
<p>Employees should take note of the
following important dates:</p>
<ul>
<li class="duedate">8/28/2002 (Progress reports due)</li>
<li class="holiday">9/1/2002 (Labor Day)</li>
<li class="duedate">10/28/2002 (Final reports due)</li>
</ul>
</body>
</html>
В тази страница, видът ден може да бъде идентифициран чрез самото съдържание, а браузърът може да използва информацията в класовете, за да го оформи, както е показано на Фигура 1.
Гледайки на нещата по този начин, тагът за прекъсване (br) не може да има никаква друг смисъл освен за оформление на представянето, защото всъщност той няма никакво съдържание. XHTML 2.0 не одобрява тага br за сметка на това препоръчва тага line. Тагът line определя един конкретен вид съдържание: ред текст или друго съдържание, което обикновено на края на реда има прекъсване. Примерно, текстът:
<p>
public class HelloWorld {<br />
public static void main (String[] args){<br />
System.out.println("Hello world!");<br />
}<br />
}
</p>
става:
<p>
<line>public class HelloWorld {</line>
<line>public static void main (String[] args){ </line>
<line>System.out.println("Hello world!"); </line>
<line>}</line>
<line>}</line>
</p>
По този начин в документа се появява реален обект, който представя реда, по същия начин, по който p тагът представя един абзац съдържание.
Защо всичко това е важно? Мрежата все повече се превръща в място, комуникацията се случва не само между хора, но между софтуерни приложения като например сървърите и търсачките. Освен това, дните, когато всички (или почти всички) използваха един и същи браузър отдавна са минало. Все повече, разработчиците редизайнват съдържанието за различни устройства като PDA и мобилни телефони. Системите активирани от глас не са толкова далеч. Структурното значение на съдържанието започва да става почти толкова важно, колкото и самото съдържание.
Секции
В момента, две от новите добавки към XHTML 2.0 са секциите и заглавията. HTML винаги е имал номерирани заглавия - от h1 до h6 - и според работната чернова от 5 август 2002 те все още не попадат под неодобрение, но това е просто въпрос на време. Вместо тях, XHTML 2.0 използва общи заглавия и секции. Например, секциите могат да бъдат вписвани една в друга (nested), като по този начин заглавията придобиват смисъл. Документ доскоро рендван чрез номерирани заглавия:
Пример 2. Номерирани заглавия в документ
<html>
<head><title>Adding sections</title></head>
<body>
<h1>The Web's future: XHTML 2.0</h1>
<p>by Nicholas Chase</p>
<h2>Good-bye backward compatibility, hello structure</h2>
<p>Why backward compatibility is over.</p>
<h3>Presentation versus Structure</h3>
<p>Using style sheets rather than presentational elements.</p>
<h3>Lines</h3>
<p>Line breaks are deprecated.</p>
<h2>Sections</h2>
<p>Creating more reasonable sections.</p>
<h2>Navigation lists and menus</h2>
<p>Hierarchical menus.</p>
<h2>Links, links, everywhere</h2>
<p>Adding links.</p>
</body>
</html>
може да бъде заместен с общи заглавия и секции:
Пример 3. Стандартни заглавия и секции
<html>
<head><title>Adding sections</title></head>
<body>
<section>
<h>The Web's future: XHTML 2.0</h>
<p>by Nicholas Chase</p>
<section>
<h>Good-bye backward compatibility, hello structure</h>
<p>Why backward compatibility is over.</p>
<section>
<h>Presentation vs. Structure</h>
<p>Using style sheets rather than
presentational elements.</p>
</section>
<section>
<h>Lines</h>
<p>Line breaks are deprecated.</p>
</section>
</section>
<section>
<h>Sections</h>
<p>Creating more reasonable sections.</p>
</section>
<section>
<h>Navigation lists and menus</h>
<p>Hierarchical menus.</p>
</section>
<section>
<h>Links, links, everywhere</h>
<p>Adding links.</p>
</section>
</section>
</body>
</html>
Тази структура дава две преимущества. Първо, на паяците на търсещите машини става много по-лесно да разбере значението на даден къс съдържание в зависимост от контекста, и второ - всякак секция е самостоятелен единица. В HTML, секцията започваше със заглавие и затова никакво друго съдържание, като например едно въведение, не можеше да се появи преди заглавието. Елементът section премахва това ограничение, защото всичко в него е част от секцията.
Навигационни списъци и менюта
Едно структурно допълнение, което би могло да донесе значителни ползи на уеб разработчиците е добавянето на навигационни списъци. Навигационният списък, обозначаван с nl тага, работи доста подобно на братовчедите си подреден списък (ol) и неподреден списък (ul), но с една разлика: елементите от този списък се появяват само когато списъкът е активен. По този начин, навигационните списъци се доближават много до йерархичните pop-up менюта, които са толкова популярни, защото дават много информация за навигацията без да заемат много място на екрана. Например, сайт на сапунена опера може да има подобно меню:
Пример 4. Употреба на навигационни списъци
<nl>
<name>Character Options</name>
<li href="stay.html">Stay</li>
<nl>
<name>Leave</name>
<li href="newjob.html">Job transfer</li>
<li href="divorce.html">Divorce</li>
<li href="fataldisease.html">Fatal disease</li>
</nl>
<li href="backburner.html">Back Burner</li>
</nl>
Когато потребителят активира името (Character Options), поделементите на списъка се появяват. Работната чернова не дава яснота по въпроса дали подсписъкът, като например Leave менюто, се появява, когато потребителят активира главния списък или трябва отделно да се активира и самият подсписък. Авторите могат да контролират изцяло това поведение чрез стилове и events. Във всеки случай, когато фокусът се премести извън главния елемент, елементите на списъка изчезват.
Връзки, връзки навсякъде
Може би сте забелязали, че макар да е замислен като меню, в предния пример няма a тагове. Вместо това елементът е поставен директно в тага li. Това не е специална възможност при навигационните списъци, а изцяло нова възможност в XHTML 2.0. Атрибутите отнасящи се до хипертекста - като href, target accesskey сега са част от Common Attribute Collection (Обща Колекция от Атрибути), която съдържа Core Attributes (Основни Атрибути: class, id и title), Internationalization Attributes (Атрибути за Интернационализиране: xml:lang, който замести lang в XHTML 1.1) и Events Attributes (Атрибути на Events), които идват от препоръката XML Events както ще видим по-долу.
Това означава, че можете да направите от всеки елемент връзка стига само да прибавите към него href атрибут, вместо да ви се налага да ограждате отделни елементи с a таг.
Означава ли това, че след четири години работа, XLink е бил внедрен и в XHTML 2.0? С една дума, не. Всъщност разликата между XLink и връзките според XHTML 2.0 е повод за спор между хората, които работят върху съответните препоръки и затова е възможно да има разлики между тази първа работна чернова и крайната препоръка. В това време, можете да възпроизведете функционалността на XLink до голяма степен, използвайки комбинация от функционалностите на XHTML 2.0, навигационните списъци и употребата на link елемента, както и Resource Description Framework (RDF).
Една свързана с XML препоръка, която успя да влезе и в XHTML 2.0 е XForms.
XForms
Езикът XML Forms (XForms) дава напълно нов поглед върху формите, поглед в който - както навсякъде другаде в XHTML - съдържание, структура и външен вид са напълно разделени. Една XForms страница указва модела, по който съдържа информация за самата форма и след това можете да разпръснете елементите на формата из цялата страница, вместо да ги заключвате в един единствен form елемент. Това означава, че дори можете да съчетавате елементи от различни форми в една и съща област от страницата. Можете да допълвате формата чрез отделен документ, към който се обръщате през XPath изрази в самите елементи на формата. Самите елементи на формата също представляват обекти от конкретен вид, вместо да описват начина, по който трябва да изглеждат в страницата. Когато обновявате данните в елемент от формата, се обновява и допълнителният документ. Когато потребителят изпрати формата, всъщност се изпраща и допълнителният документ. Да вземем за пример следната проста форма:
Пример 5. проста HTML форма
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Preference Form</title>
</head>
<body>
<h1>Preferences Form</h1>
<form action="myformprocessor.jsp">
<p>
Username: <input type="text" name="userid" />
<br />
Password: <input type="password" name="pass"/>
</p>
<p>
Area preference:
<select name="seatingpreference">
<option value="1">One</option>
<option value="2">Two</option>
<option value="3">Three</option>
</select>
</p>
<p>
<input type="submit" />
</p>
</form>
</body>
</html>
Пример 6 показва XForms версия на формата:
Пример 6. XForms версия на формата
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xforms="http://www.w3.org/2002/01/xforms">
<head>
<title>Preference Form</title>
<xforms:model>
<xforms:submitInfo method="postxml"/>
<xforms:instance xmlns="">
<preferences>
<person userid="">
<password></password>
</person>
<seatingpreference></seatingpreference>
</preferences>
</xforms:instance>
</xforms:model>
</head>
<body>
<h1>Preferences Form</h1>
<p>
<xforms:input ref="preferences/person@userid">
<xforms:caption>Username: </xforms:caption>
</xforms:input>
<br />
<xforms:secret ref="preferences/person/password">
<xforms:caption>Password: </xforms:caption>
</xforms:secret>
</p>
<p>
<xforms:selectOne ref="preferences/seatingpreference"
selectUI="listbox">
<xforms:caption>Area preference: </xforms:caption>
<xforms:item>
<xforms:value>1</xforms:value>
<xforms:caption>One</xforms:caption>
</xforms:item>
<xforms:item>
<xforms:value>2</xforms:value>
<xforms:caption>Two</xforms:caption>
</xforms:item>
<xforms:item>
<xforms:value>3</xforms:value>
<xforms:caption>Three</xforms:caption>
</xforms:item>
</xforms:selectOne>
</p>
<p>
<xforms:submit>
<xforms:caption>Submit Report</xforms:caption>
</xforms:submit>
</p>
</body>
</html>
Формите обикновено трябва да се валидират. С други думи, едно поле за данни трябва да съдържа валидни данни и т.н.. XForms използва XML Schemas за да поставя ограничения на изпращаната информация. В допълнение, можете допълнително да усъвършенствате функционалността на своята XForms страница, добавяйки XML Events, които също са включени в XHTML 2.0.
XML Events
Може би сте запознати с начините за използване на Events (събития) в една уеб страница, добавяйки събития като onclick и onmouseover. Вече няма такива. тези познати атрибути са заменени от интегрирания в XHTML 2.0 XML Events модул. XML Events предоставя стандартен начин, по който може да се указва действието, което трябва да се случи, когато се задейства дадено събитие. Предимството в това е, че не сте ограничени с предварително зададени събития като кликването с мишката. Вместо това, вие можете да дефинирате свои собствени събития и онова което да се случва, когато те биват задействани.
XML Events включва следните компоненти. Събитие, от сорта на кликване с мишката, е взето като цел. За пример ще вземем една такава страница:
Пример 7. Страница за клик
<html>
<head><title>Rides</title></head>
<body>
<ul id="ridelist">
<li href="monorail.html">Monorail</li>
<li href="Matterhorn.html">Matterhorn</li>
<li href="coaster.html">Roller coaster</li>
</ul>
</body>
</html>
потребителят може да кликне върху втория li елемент, Matterhorn. Когато това се случи събитието "кликване на мишката" пропътува от root на документа, до целта (li) и обратно. Последователността е:
(root) -- html -- body -- ul -- li -- ul -- body -- html -- (root)
Пътят до целта е известен като capture phase (фаза на улавянето), а обратният път - като bubbling phase (фаза, в която балончетата изплуват). (Не всички събития имат bubbling phase.) Във всеки момент от този път, събитието може да мине през обект, който е бил регистриран като наблюдател (observer), което означава, че той гледа кога ще се появи конкретното събитие и ако го види, изпълнява някакво конкретно действие. Наблюдател се създава чрез един listener. Примерно в следната последователност:
<ev:listener observer="ridelist" event="mousedown" handler="#myscript"/>
listener-ът прави ul елемента (или с други думи, целия списък)
наблюдател и затова, когато потребителят кликне върху някой от елементите
на списъка, наблюдателят (ridelist) изпълнява myscript. (Механизмът, по
който ще се извиква произволен скрипт трябва тепърва да бъде уточнен.)
XFrames
Руганите от край време фреймове също биват заместени в XHTML 2.0. Първата работна чернова на Xframes направи своя дебют на 6 август 2002, на следващия ден след като XHTML 2.0 обяви, че ще използва XFrames, и ще се опита да реши проблемите, които традиционните HTML фреймове създаваха. Повечето от проблемите изникваха около затрудненията при bookmark-ването и обновяването (refresh) на страниците, а и невъзможността на търсещите машини - които не поддържат фреймове - да индексират правилното съдържание.
В един XFrames документ, URI на включващото се във фреймовете съдържание, ще станат част от URI на общия документ. Например, следната страница от Пример 8 може да представя една HTML страница с три фрейма:
Пример 8. XFrames страница
<html>
<head><title>XFrames</title></head>
<body>
<row>
<frame id="header" />
<column>
<frame id="menu"/>
<frame id="content"/>
</column>
</row>
</body>
</html>
Обърнете внимание, че URI за всеки фрейм на са изрично указани, но всеки фрейм има свой уникален идентификатор. URI за този документ може да е следното:
site.xfm#frames(header=header.xhtml,menu=menu.xhtml,content=main.xhtml)
Тогава браузър, разбиращ XFrames може да свърже съдържанието на всеки един фрейм с уместния URI. Когато потребителят кликне една връзка и промени съдържанието на отделната страница, цялостния URI на страницата също се променя, като по този начин отразява реалното съдържание, което разглежда потребителя, а bookmarks и бутонът Back работят правилно.
Изображенията като обекти
Последната голяма промяна (към 5 август 2002) е премахването на img тага и заместването му с object тага. Всъщност object тагът е тук още откакто излезе HTML 4.01, но разработчиците го използваха основно, за да добавят мултимедия и Java аплети към страниците. Но той винаги е поддържал и изображения. Едно от основните му преимущества е, че ако браузърът не може да покаже даден обект, той показва съдържанието на обекта. Например, браузърът се натъква на следния snippet и се опитва да зареди филмчето. Когато не успее да направи това, той просто показва текста.
<object data="rides.mpeg" type="application/mpeg">
<object data="rollercoaster.jpg" type="image/jpg">
Jack tries to expand his horizons on the racing coasters.
</object>
</object>
Следващи стъпки
Единственото нещо, което е сигурно относно работната чернова на XHTML 2.0 от 5 август 2002 е това, че нищо в нея не е сигурно. Тя почти сигурно ще се промени докато стане препоръка, но целта - наблягане върху структурата и значението - вероятно няма да се промени. Ето защо е добра идея да хвърлите един поглед на страниците, които правите днес и да започнете да придобивате навика да използвате структура и стилове правилно. Използвайте кода, за да маркирате кое какво значи, а не как изглежда и използвайте CSS за останалото. В крайна сметка, мислете повече за структурата на своите документи и онова, което искате от тях да правят, а не непременно толкова много за начина, по който изглеждат.
Ресусрси
- Вижте последната версия на XHTML 2.0, за да разберете какво включва в настоящия момент.
- Открийте как можете да контролирате събитията във своите страници и във всеки XML документ, използвайки XML Events.
- Прочетете за следващото поколение уеб форми и XForms.
- Научете повече за XForms в тази статия, " Get ready for XForms" (developerWorks, September 2002).
- Хвърлете поглед върху XFrames.
- Вижте как е сглобен XHTML 2.0, като прочетете за Модуларизацията на XHTML, или прочетете Modularization of XHTML туториала в developerWorks Web Architecture zone (October 2001).
- Разгледайте коментарите Kendall Grant Clark относно XHTML 2.0 и Semantic Web в XHTML 2.0 The Latest Trick.
- Прочетете размислите на Bob DuCharme върху XLink и неговите предшественици в XLink: Who Cares?
- Свалете си X-Smiles, XForms браузър.
Информация за статията
Статия в категория Код
Ключови думи: xhtml, future, standards, xml, css, html, стандарти, w3c
Източник: The Web's Future: XHTML 2.0
http://www-106.ibm.com/developerworks/
Подобни статии
Търсене
Все още не можете да намерите онова, което търсите? Защо не пробвате с това малко поленце отдолу (подсказки: въвеждайте повече думи; пишете на кирилица; използвайте по-конкретни понятия.)