Komencaj kaj finaj markoj por la elementoj <head> kaj <body> estas devigaj. En HTML oni povis ilin, laŭ certaj reguloj, subkompreni, sed tio ne eblas en XHTML.
Ĉiuj nomoj de elementoj kaj atributoj havas minusklan formon, kaj devas esti ĝuste tiel skribataj. Antaŭe eblis mem elekti laŭplaĉe la usklecon, sed XML postulas distingadon inter minuskloj kaj majuskloj. Do, nepre <body>, ne <BODY> nek <Body> aŭ simile, nepre <p>, ne <P>, nepre <table rows="2">, ne <TABLE ROWS="2"> nek <table ROWS="2">, k.t.p.
Oni notu, ke ankaŭ stilfolio (ekz. CSS), kiu indikas la stilon de XHTML-dokumento, laŭe uzu minusklajn nomojn por nomi la stiligatajn elementojn.
Komencmarkoj kaj finmarkoj de elementoj devas aperi en logika ordo. Se ekz. <strong>-elemento troviĝas ene de <em>-elemento, kaj la komencmarko <strong>, kaj la finmarko </strong> devas esti ene de la <em>-elemento.
| Malĝusta | Ĝusta |
|---|---|
<em>teksto <strong>teksto teksto</em></strong> |
<em>teksto <strong>teksto teksto</strong></em> |
<a>vorto <em>vorto</a> vorto</em> |
<a>vorto <em>vorto</em></a> <em>vorto</em> |
Efektive misinterplektiĝo estis erara jam en HTML, sed estis tamen praktike tolerata de multaj TTT-legiloj. Sed XHTML estos uzata en multaj programoj kaj aparatoj, kiuj simple ne akceptos tiajn erarojn.
Ĉiuj elementoj, kiuj povas havi enhavon, devas havi finmarkon, kiu fermas la elementon. En HTML tiaj finmarkoj estis libervolaj por pluraj elementoj, sed jam en HTML estis konsilinde fermi ankaŭ tiajn elementojn por eviti problemojn en iuj legiloj.
| Malĝusta en XHTML | Ĉiam ĝusta |
|---|---|
Unua alineo<p> |
<p>Unua alineo</p> |
Dua alineo<p> |
<p>Dua alineo</p> |
Multaj alkutimiĝis rigardi <p>-markojn kvazaŭ dividilojn inter alineoj. Fakte <p> neniam estis tia dividilo, sed markilo por komenco de alineo.
Iuj elementoj estas malplenaj. Ekz. <br> (en HTML) markas finon de linio, sed post <br> ne sekvas teksto aŭ io alia, kiu estas parto de la <br>-elemento. La <br>-marko mem konsistigas la tutan elementon. Simile estas pri <img>, <meta> kaj kelkaj aliaj elementoj. En XHTML ankaŭ tiaj malplenaj elementoj devas esti eksplicite fermataj. Tio povas okazi aŭ per finmarko tuj post la komencmarko (ekz. <br></br>) aŭ per / antaŭ la fina > de la komencmarko laŭ XML-reguloj (<br />):
| HTML | XHTML |
|---|---|
<hr> |
<hr /> |
<br> |
<br /> |
<meta ...> |
<meta ... /> |
<input ...> |
<input ... /> |
<param ...> |
<param ... /> |
<img src="bela.jpg"> |
<img src="bela.jpg" /> |
Rimarku 1: Ĉi-antaŭe estas spaceto antaŭ ĉiu finanta /. Tia spaceto tute ne estas necesa laŭ la reguloj de XHTML kaj XML, sed estas praktike necesa, se oni volas, ke ankaŭ malnovaj TTT-legiloj komprenu la kodon. Ili tute ne scias pri tiaj finaj / en malplenaj elementoj, sed pro la aldona spaceto (kiu neniel estas erara en XML, nur tute superflua) ili feliĉe ignoras tiun signon, kaj tiumaniere XHTML-kodo povas funkcii kaj en veraj XHTML-legiloj kaj en jam ekzistantaj HTML-legiloj.
Rimarku 2: Kiel menciiĝis ĉi-antaŭe, ankaŭ eblas uzi plenajn finmarkojn por malplenaj elementoj (ekz. <hr></hr>). Nunaj TTT-legiloj tamen ne bone komprenas tiun varianton, kaj se oni volas konservi kongruon kun HTML-legiloj, oni do evitu tion preferante <hr /> k.t.p.
Rimarku 3: Se elemento, kiu povas havi enhavon (ekz. <p>) okaze estas malplena, oni povas en XHTML kaj XML ĝin skribi per unu memfermiĝanta marko, ekz. <p/> aŭ <p />. Tio tamen ne funkcias en malnovaj TTT-legiloj, kaj oni do skribu ekz. <p></p>, se oni deziras kongruon kun tiuj legiloj.
En XHTML oni ne rajtas ripeti atributojn ene de elemento.
| Malbona | Bona |
|---|---|
<p class="io" class="ioalia"> |
<p class="io"> |
(Se oni volas doni plurajn klasnomojn al unu elemento, oni skribu ĉiujn nomojn ene de unu sama “class”-atributo. Ekz.: <span class="io ioalia">. Estu tiam spacetoj inter la klas-nomoj. Oni tamen sciu, ke iuj malnovaj TTT-legiloj malbone komprenas tiajn indikojn pri pluraj klasnomoj.)
“Bonformeco” estas grava baza nocio en XML. La ĉefaj kondiĉoj, por ke dokumento estu bonforma, estas la ĵus klarigitaj reguloj kontraŭ erara interplektiĝo de markoj, pri ĝusta fermado de elementoj, kaj pri neripetado de atributoj.
XHTML-dokumento devas antaŭ ĉio esti bonforma. En iuj kuntekstoj bonformeco estas sufiĉa kondiĉo por ke la dokumento povu esti traktata. Ankaŭ aliaj reguloj gravas, sed la reguloj pri bonformeco estas la plej bazaj kaj plej obeendaj. La bonformecoreguloj estas komunaj al ĉiuj formoj de XML. Aliaj XHTML-reguloj estas propraĵoj de XHTML. Efektive bonformeco estas sekvinda ankaŭ en ordinaraj HTML-paĝoj, ĉar iuj TTT-legiloj tiam pli ĝuste kaj pli facile komprenas la kodon.
Valoroj de atributoj devas skribiĝi kun citiloj. En HTML iuj tiaj valoroj devis esti citataj, aliaj povis aperi sen citiloj. En XHTML la regulo estas pli simpla: Ĉiuj valoroj estu citataj. Oni povas laŭplaĉe uzi duoblajn ("...") aŭ unuoblajn (‘...’) citilojn (sed oni sciu, ke iuj tre malnovaj TTT-legiloj ne ŝatas unuoblajn):
| HTML | XHTML (kaj HTML) |
|---|---|
<img ... border=0> |
<img ... border="0" /> |
En HTML oni povis uzi simpligitan, “minimumigitan”, formon de iuj atributoj, kies valoroj estas nomataj “buleaj”. En XHTML oni povas uzi nur la plenan formon de tiaj atributoj.
Ĉiuj koncerncaj atributoj estas tiaj, kiuj povas havi nur unu solan valoron, kiu krome estas identa al la nomo de la atributo mem. Temas ekz. pri la atributo "selected" (de <option>-elementoj). La sola valoro por "selected" estas "selected"! La plena formo estas do selected="selected", kaj la simpligita formo estas selected (sen egalsigno kaj sen citiloj). Bedaŭrinde iuj erare faritaj HTML-legiloj konas nur la minimuman formon de tiaj atributoj, kaj ne komprenas la plenan formon (kiun ili devus unuavice kompreni!). Jen do detalo, kiu povas kaŭzi kongruproblemojn en iuj malnovaj (erare konstruitaj) legiloj.
| HTML | XHTML (kaj HTML) |
|---|---|
<option ... selected> |
<option ... selected="selected"> |
<td nowrap> |
<td nowrap="nowrap"> |
<input type="checkbox" ... checked> |
<input type="checkbox" ... checked="checked" /> |
<ul compact> |
<ul compact="compact"> |
<script> kaj <style>Ene de la elementoj <script> kaj <style> oni devas en XHTML eviti tiajn signojn, kiuj havas specialan signifon en HTML kaj XHTML, nome la signojn "<" kaj "&". Laŭ la principoj de XML oni povas tiujn signojn uzi ene de <script> kaj <style> nur se oni aldonas komence kaj fine de la elementenhavo specialajn indikilojn, kiuj montras, ke la enhavo ne interpretiĝu laŭ HTML-reguloj (komenca “<![CDATA[” kaj fina “]]>”). Ekz.:
<script type="text/javascript">
<![CDATA[
document.write("<b>Jen misinterpretebla teksto.</b>");
]]>
</script>Tiujn specialajn indikilojn tamen apenaŭ komprenas malnovaj TTT-legiloj, kaj tial necesas anstataŭe elturniĝi per aliaj rimedoj, se oni volas, ke ankaŭ tiaj legiloj komprenu. La plej simpla rimedo estas meti la enhavon de tiaj elementoj en eksterajn dosierojn, ekz. js-dosieroj por Javaskripta kodo, kaj css-dosieroj por kaskadaj stilfolioj. Ĝenerale tio estas bona uzo ĉiuokaze. Ekz.:
<script type="text/javascript" src="javaskripto.js"></script>
<link rel="stylesheet" type="text/css" href="stilfolio.css" />
id anstataŭ nameEn HTML oni povis uzi la atributon name por nomi dokumentopartojn, kiujn oni volis referenci en ligiloj (per #-simbolo). Oni povis ankaŭ uzi id por tiu celo. En XHTML oni tamen uzu nur id por tiaj referencoj. Se oni volas, ke ĉiuj malnovaj HTML-legiloj komprenu ligilojn al precizaj lokoj ene de paĝoj, oni uzu en XHTML ambaŭ atributojn kun la sama valoro.
| HTML | XHTML (kaj HTML) |
|---|---|
<a name="loko">...</a> |
<a id="loko" name="loko">...</a> |
<a href="#loko">...</a> |
<a href="#loko">...</a> |
Rimarku, ke la valoro de id-atributo devas esti unika ene de unu dokumento. Ne povas esti du elementoj kun la sama valoro por id en unu dokumento.
En HTML oni povis skribi numerajn signoreferencojn kaj dekume, ekz. å, kaj deksesume, ekz. å, å. En la deksesuma formo oni povis uzi komencan “x” (minusklan) aŭ “X” (majusklan) egale (ĝi indikas, ke temas pri deksesuma numero). En XHTML oni uzu nepre nur minusklan “x”. Oni do skribu nur å aŭ å. Deksesumajn ciferojn literformajn (A, B, C, D, E, F) oni povas plu skribi minuskle aŭ majuskle laŭplaĉe. Estas ĉiuokaze rekomendinde resti ĉe la dekuma skribo de tiaj signoreferencoj, ĉar iuj malnovaj legiloj ne komprenas la deksesuman skribon. Sed se oni servas XHTML-on kiel veran XML-on, oni ja povas uzi la deksesuman skribon, ĉar tiajn paĝojn komprenas ĉiuokaze nur modernaj legiloj.
En HTML oni povis indiki la uzatan lingvon (homan lingvon) de tuta dokumento aŭ de unuopaj elementoj. Tion oni faris per la atributo lang, ekz. <body lang="eo"> (indikas Esperanton). En XHTML oni tamen uzu xml:lang por la sama celo. Por kongruo kun malnovaj legiloj, oni uzu ambaŭ atributojn samtempe, ekz. <body xml:lang="eo" lang="eo">.
Kiam servilo sendas HTML-an dokumenton al legilo, ĝi ĉiam anoncas antaŭe, per t.n. “HTTP-ĉapo”, kiaspecan dokumenton ĝi sendas, per indikado de t.n. MIME-tipo. Por montri, ke temas pri HTML-dokumento, servilo sendas la jenon:
Content-type: text/html
La servilo samtempe povas anonci ankaŭ la signokodon uzatan en la dokumento, ekzemple:
Content-type: text/html; charset=UTF-8
Content-type: text/html; charset=iso-8859-1
Se la dokumento estas verkita laŭ XHTML 1.0, kaj se ĝi estas verkita por kongruo kun malnova HTML (laŭ la konsiloj ĉi tie), oni povas ĝin servi tute same (kun la sama HTTP-ĉapo). Tio funkcias tre bone.
Estonte oni tamen povos pli kaj pli servi XHTML-ajn dokumentojn al programoj, kiuj ne bezonas tian kongruon kun la pasintaj formoj de HTML. Oni povos servi XHTML-on kiel XML-on - eble eĉ enmiksante en la XHTML-an kodon aliajn specojn de XML (ekz. MathML por matematikaj formuloj). Se oni elektas servi XHTML-on kiel veran XML-on, oni uzu jenan indikon en la HTTP-ĉapo:
Content-type: application/xhtml+xml
Jam eblas tiamaniere servi XHTML-dokumentojn al la TTT-legilo Fajrovulpo. Fruaj versioj de Fajrovulpo (kaj ĝia antaŭulo Mozilo) havis iom da problemoj, sed novaj versioj de Fajrovulpo jam traktas XHTML-on servitan kiel application/xhtml+xml tute bone. Iam pli-malpli ĉiuj TTT-legiloj komprenos tian vere XML-an XHTML-on. (Oni ankaŭ povas uzi la MIME-tipon application/xml.)
Ekzistas nun ankaŭ pli nova versio de XHTML: versio 1.1. En tiu versio oni plene forlasis la kongruon kun malnova HTML, kaj la afero ruliĝu plene XML-e. Se oni elektas uzi XHTML-on 1.1, oni devas servi siajn paĝojn kiel application/xhtml+xml (aŭ kiel application/xml). Tio ankoraŭ funkcias nur en malmultaj TTT-legiloj. Efektive se vi legas tiujn ĉi paĝojn per tia moderna TTT-legilo, vi ilin ricevas ĝuste tiel. La kodo estas laŭ XHTML 1.1, kaj la MIME-tipo estas application/xhtml+xml. Sed ne estas facile aranĝi tiel, ke TTT-paĝoj serviĝas jen kiel XHTML 1.0 laŭ text/html, kaj jen kiel XHTML 1.1 laŭ application/xhtml+xml. Tiam oni bezonas atenti tion, kion sendas la TTT-legilo en la t.n. “Accept”-ĉapo (parto de la HTTP-ĉapo sendata de la TTT-legilo). Por realigi tion oni bezonas fari specialajn agordojn de la servilo, aŭ uzi apartan kodon en programlingvo kiel ekz. PHP aŭ JSP, kaj oni bezonas nemalmulte da specialaj scioj por tion fari ĝuste. Tial estas nuntempe por plej multaj plu rekomendinde uzi XHTML-on 1.0 laŭ text/html, aŭ eĉ malnovan HTML-on 4.01 laŭ text/html.
Estas kutimo doni al HTML-dosieroj la nomsufikson .html (aŭ la mallongan formon .htm). Principe oni rajtas uzi ĉian ajn sufikson, sed multaj serviloj estas agorditaj por rekoni la MIME-tipon laŭ la dosiersufikso. Plej ofte ili aŭtomate anoncas text/html, se la sendota dosiero havas la sufikson .html aŭ .htm. Tial, se oni volas servi XHTML-dokumentojn kiel ordinaran HTML-on, oni normale plu uzu la kutimajn sufiksojn. Tre multaj tamen supozas, ke oni devas ŝanĝi al .xhtml. Plej multaj serviloj tamen tute ne scias, kion signifas la sufikso .xhtml, nek kian MIME-tipon ili anoncu por tia dosiero. Ili tiam eble sendas ian ĝeneralan tipon, ekz. text/plain (= plata teksto), kaj la TTT-legiloj tiam eĉ ne provas trakti la dokumenton kiel HTML-on, sed simple montras la nudan kodon. (Iuj legiloj tamen provas mem diveni, ke temas pri HTML, sed tio principe estas miskonduto. Ili sekvu la anoncitan MIME-tipon.)
Do, se oni mem povas agordi, kiel la servilo traktu diversajn dosiersufiksojn, oni povas aranĝi la aferon laŭplaĉe, ekz. ekuzante la sufikson .xhtml, sed normale oni simple restu ĉe la tradiciaj sufiksoj .html kaj .htm. Se oni estonte volos ekservi la dokumentojn kiel application/xhtml+xml, oni devos verŝajne mem iel agordi la servilon, ke ĝi tiun MIME-tipon anoncu.
Rimarku, ke en la reto estas uzataj plej diversaj sufiksoj ĉe TTT-dokumentoj, ekz. .php, .js, .cgi, .asp... Normale ili ĉiuj tamen serviĝas kun la MIME-tipo text/html, ĉar la koncernaj serviloj estas agorditaj por tion fari. La uzata sufikso mem ne gravas. Gravas nur la MIME-tipo, kiun la servilo anoncas.
Tamen, se oni havas (X)HTML-dokumenton en sia propra komputilo, kaj ĝin legas rekte de la disko, sen interveno de servilo, tiam la uzata nomsufikso povas esti grava. En tiaj okazoj la operacisistemo ofte uzas la nomsufikson por rekoni, ĉu temas pri (X)HTML aŭ pri alia speco de dokumento. Se la operacisistemo ne rekonas la dokumenton kiel (X)HTML-on, oni eble devas mem aŭ ŝanĝi al alia sufikso, aŭ instrui al la operacisistemo la signifon de la uzata sufikso. Pri tio ne ekzistas ĝeneralaj reguloj aŭ principoj. Ĉiu operacisistemo havas siajn proprajn metodojn kaj tradiciojn.