Inhoud
Deze sectie van het document bespreekt twee belangrijke gevallen die de internationalisatie van HTML beïnvloeden: specificatie van de taal (het lang attribuut) en richting (het dir attribuut) van tekst in een document.
Taal informatie die gespecificeerd wordt via het lang attribuut kan gebruikt worden door User Agents om de weergave te controleren op verschillende manieren. Sommige situaties waar auteur-ingestelde taalinformatie hulpvol kan zijn zijn onder andere:
Het lang attribuut specificeert de taal van de inhoud en de attribuutwaarden van een element; of het relevant is voor een bepaald attribuut hangt af van de syntaxis en semantiek van het attribuut en de betreffende bewerking.
De bedoeling van het lang attribuut is om User Agents de mogelijkheid te bieden om inhoud weer te geven op een betekenisvollere manier gebaseerd op geaccepteerde culturele praktijken voor een gegeven taal. Dit wil niet zeggen dat User Agents atypische karakters niet voor een bepaalde taal op een minder betekenisvolle manier moeten weergeven; User Agents moeten de best mogelijke weergave gebruiken voor alle karakters, onafhankelijk van de waarde gespecificeerd door lang.
Als karakters van bijvoorbeeld het Griekse alfabet voorkomen in het midden van Nederlandse tekst:
<P><Q lang="nl">Haar superkrachten waren het resultaat van γ-straling,</Q> verklaarde hij.</P>
dan zou een User Agent (1) moeten proberen om de Nederlandse inhoud weer te geven op een geschikte manier (bijvoorbeeld in de afhandeling van aanhalingstekens) en (2) zou de best mogelijke weergave moeten kiezen voor γ, ook al is het niet een Nederlands karakter.
Raadpleeg het deel over niet-weergeefbare tekens voor gerelateerde informatie.
De waarde van het lang attribuut is een taalcode die een natuurlijke, gesproken, geschreven taal identificeert of die gebruikt wordt voor de communicatie van informatie tussen mensen. Computertalen zijn expliciet uitgesloten van de taalcodes.
[RFC1766] definieert en verklaart de taalcodes die gebruikt moeten worden in HTML documenten.
Kort samengevat bestaan taalcodes uit een primaire code en een mogelijk lege reeks van subcodes:
language-code = primaire-code ( "-" subcode )*
Hier zijn enkele voorbeelden van taalcodes:
Primaire codes uit twee letters zijn voorbehouden voor [ISO639] taalafkortingen. Twee-letter codes zijn onder andere fr (Frans), de (Duits), it (Italiaans), nl (Nederlands), el (Grieks), es (Spaans), pt (Portugees), ar (Arabisch), he (Hebreews), ru (Russisch), zh (Chinees), ja (Japans), hi (Hindi), ur (Oerdoe), en sa (Sanskriet).
Elke twee-letter subcode wordt begrepen als een [ISO3166] landcode.
Een element erft taalcode informatie over volgens de volgende voorrangsregeling (hoogst naar laagst):
Content-Language: en-cockney
In dit voorbeeld is de primaire taal van het document Frans ("fr"). Eén paragraaf is gedeclareerd als zijnde in Spaans ("es"), waarna de primaire taal terug Frans wordt. De volgende paragraaf bevat een Japanse ("ja") zin, waarna de primaire taal weer Frans wordt.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<HTML lang="fr">
<HEAD>
<TITLE>Un document multilingue</TITLE>
</HEAD>
<BODY>
...Als Frans geïnterpreteerd...
<P lang="es">...Als Spaans geïnterpreteerd...
<P>...Opnieuw als Frans geïnterpreteerd...
<P>...Franse tekst onderbroken door <EM lang="ja">een stukje
Japans</EM>Frans begint hier opnieuw...
</BODY>
</HTML>
In de context van HTML zou een taalcode steeds door User Agents geïnterpreteerd moeten worden als een hiërarchie van tekens in plaats van een eenvoudig teken. Wanneer een User Agent de weergave aanpast naargelang de taalinformatie (door bijvoorbeeld style sheet taalcodes en lang waardes te vergelijken), dan zou er een exacte gelijke gevonden moeten worden, maar dan kan een gelijke primaire taalcode al genoeg zijn. Dus als de lang attribuutwaarde op "en-US" is ingesteld voor het HTML element, dan zou een User Agent de voorkeur moeten geven aan style informatie die in de eerste plaats overeenkomt met "en-US" en dan pas met de meer algemene waarde "en".
Nota. Taalcode hiërarchiën garanderen niet dat alle talen met een vaak voorkomend voorvoegsel begrepen zullen worden door degenen die welbespraakt zijn in één of meer van deze talen. Ze laten toe dat een gebruiker kan kiezen voor het algemene wanneer dat toepasbaar is voor de gebruiker.
Attribuut definities
Als aanvulling op het specificeren van een taal van een document met het lang attribuut kunnen auteurs willen specificeren wat de basis richting (left-to-right or right-to-left) van een stuk van een documenttekst is of wat de tabel structuur is, enz. Dit wordt gedaan met het dir attribuut.
De [UNICODE] specificatie wijst richtinggevoeligheid toe aan karakters en definieert een (complex) algoritme om te bepalen wat de gepaste tekstrichting is. Als een document geen weer te geven right-to-left karakter bevat, dan is een gepaste User Agent niet verplicht om het [UNICODE] bidirectionele algoritme toe te passen. Als een document right-to-left karakters bevat en als de User Agent deze karakters weergeeft, dan moet de User Agent gebruik maken van het bidirectionele algoritme.
Hoewel Unicode speciale karakters specificeert die handelen over tekstrichting, biedt HTML hogere-level opmaakconstructies die hetzelfde doen: het dir attribuut (niet te verwarren met het DIR element) en het BDO element. Om dus een Hebreews citaat uit te drukken is het meer intuïtief om te schrijven
<Q lang="he" dir="rtl">...een Hebreeuws citaat...</Q>
dan het equivalent met Unicode verwijzingen:
‫״...een Hebreeuws citaat...״‬
User Agents mogen het lang attribuut niet gebruiken om de tekstrichting te bepalen.
Het dir attribuut overgeërfd en kan terzijde geschoven worden. Raadpleeg de sectie over de overerving van tekstrichtingsinformatie voor details.
Het volgende voorbeeld illustreert het verwachtte gedrag van het bidirectionele algoritme. Het bevat Engels, een left-to-right schrift en Hebreeuws, een right-to-left schrift.
Beschouw het volgende voorbeeld:
engels1 HEBREEWS2 engels3 HEBREEWS4 engels5 HEBREEWS6
De karakters in dit voorbeeld (en in al de gerelateerde voorbeelden) worden in de computer bewaard op de manier waarop ze hier weergegeven worden: het eerste karakter in het bestand is "e", het tweede is "n" en het laatste is "6".
Veronderstel dat de overheersende taal van het document waarvan deze paragraaf deel uitmaakt Engels is. Dit wil zeggen dat de basisrichting left-to-right is. De correcte presentatie van deze regel zou dus zijn:
engels1 2SWEERBEH engels3 4SWEERBEH engels5 6SWEERBEH
<-------- <-------- <--------
H H H
------------------------------------------------->
E
De streepjeslijnen geven de structuur van de zin aan: Engels overheerst en een deel Hebreewse tekst is er in opgenomen. Om de correcte presentatie te bekomen is geen bijkomende opmaak vereist omdat de Hebreewse fragmenten correct omgekeerd worden door de User Agent wanneer deze het bidirectionele algoritme gebruikt.
Als aan de andere kant de overheersende taal van het document Hebreeuws is, dan is de basisrichting right-to-left. De correcte presentatie is daarom:
6SWEERBEH engels5 4SWEERBEH engels3 2SWEERBEH engels1
------> ------> ------>
E E E
<-------------------------------------------------
H
In dit geval wordt de hele zin gepresenteerd als right-to-left en de opgenomen Engelse zinnen zijn goed omgekeerd door het bidirectionele algoritme.
Het Unicode bidirectionele algoritme vereist een basis tekstrichting voor tekstblokken. Om de basisrichting van een block-level element te specificeren moet het dir attribuut van dat element ingesteld worden. De standaardwaarde van het dir attribuut is "ltr" (left-to-right text).
Wanneer het dir attribuut ingesteld wordt voor een block-level element, dan heeft het effect op het hele element en alle geneste block-level elementen. Instellen van het dir attribuut op een genest element vervangt de overgeërfde waarde.
Om de basis tekstrichting voor een volledig document in te stellen moet het dir attribuut ingesteld worden op het HTML element.
Voorbeeld:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <HTML dir="RTL"> <HEAD> <TITLE>...een right-to-left titel...</TITLE> </HEAD> ...right-to-left tekst... <P dir="ltr">...left-to-right tekst...</P> <P>...opnieuw right-to-left tekst...</P> </HTML>
Inline elementen erven daarentegen het dir attribuut niet over. Dit betekent dat een inline element zonder een dir attribuut geen bijkomend niveau van invoeging met betrekking op het bidirectionele algoritme opent. (Hier wordt een element beschouwd als block-level of inline gebaseerd op zijn standaard presentatie. Merk op dat de INS en DEL elementen zowel block-level als inline kunnen zijn afhankelijk van hun context.)
Het [UNICODE] bidirectionele algoritme keert ingevoegde karakterreeksen automatisch om volgens hun inherente directionaliteit (zoals geïllustreerd door de vorige voorbeelden). In het algemeen kan er slechts rekening gehouden worden met één enkel niveau van invoeging. Om meerdere niveau's van ingevoegde richtingswijzigingen te bereiken moet je gebruik maken van het dir attribuut op een inline element.
Beschouw dezelfde voorbeeldtekst als hiervoor:
engels1 HEBREEWS2 engels3 HEBREEWS4 engels5 HEBREEWS6
Veronderstel dat de overheersende taal van het document die deze paragraaf bevat het Engels is. Verder bevat de bovenstaande Engelse zin een Hebreewse sectie die gaat van HEBREEWS2 tot HEBREEWS4 en de Hebreewse sectie bevat een Engels citaat (engels3). De gewenste presentatie van de tekst is dus:
engels1 4SWEERBEH engels3 2SWEERBEH engels5 6SWEERBEH
------>
E
<--------------------------
H
---------------------------------------------------->
E
om twee ingevoegde richtingswijzigingen te bereiken, moeten we aanvullende informatie voorzien, hetgeen we doen door de tweede invoeging expliciet af te bakenen. In dit voorbeeld gebruiken we het SPAN element en het dir attribuut om de tekst op te maken:
engels1 <SPAN dir="RTL">HEBREEWS2 engels3 HEBREEWS4</SPAN> engels5 HEBREEWS6
Auteurs kunnen ook gebruik maken van speciale Unicode karakters om meervoudige ingevoegde richtingswijzigingen te bereiken. Om left-to-right invoeging te bereiken moet ingevoegde tekst omsloten worden met de LEFT-TO-RIGHT EMBEDDING ("LRE", hexadecimaal 202A) en POP DIRECTIONAL FORMATTING ("PDF", hexadecimaal 202C). Om right-to-left invoeging te bereiken met ingevoegde tekst omsloten worden met de karakters RIGHT-TO-LEFT EMBEDDING ("RTE", hexadecimaal 202B) en PDF.
Gebruik van HTML richtingsopmaak met Unicode karakters. Auteurs en ontwerpers van auteurssoftware zouden zich bewust moeten zijn dat conflicten kunnen optreden wanneer het dir attribuut simultaan gebruikt wordt op inline elementen (inclusief BDO) met de corresponderende [UNICODE] opmaakkarakters. Het ene of het andere zou bij voorkeur exclusief gebruikt moeten worden. De opmaakmethode biedt een betere garantie structurele document integriteit en verlicht sommige problemen wanneer bidirectionele HTML tekst bewerkt wordt met een eenvoudige teksteditor, maar sommige software kan beter gebruik maken van de [UNICODE] karakters. Als beide methodes gebruikt worden, dan moet grote zorg besteed worden om correcte nesting te verzekeren van opmaak en directionele invoeging of te niet doen, anders zijn weergaveresultaten niet duidelijk.
<!ELEMENT BDO - - (%inline;)* -- I18N BiDi over-ride --> <!ATTLIST BDO %coreattrs; -- id, class, style, title -- lang %LanguageCode; #IMPLIED -- taalcode -- dir (ltr|rtl) #REQUIRED -- directionaliteit -- >
Start tag: vereist, Eind tag: vereist
Attribuut definities
Attribute elders gedefinieerd
Het bidirectionele algoritme en het dir attribuut voldoen in het algemeen om opgenomen richtingswijzigingen af te handelen. Er kunnen zich echter situaties voordoen waar het bidirectionele algoritme resulteert in incorrecte presentatie. Het BDO element laat auteurs toe om het bidirectionele algoritme uit te schakelen voor geselecteerde tekstfragmenten.
Beschouw een document dat dezelfde tekst bevat als hiervoor:
engels1 HEBREEWS2 engels3 HEBREEWS4 engels5 HEBREEWS6
maar veronderstel dat deze tekst al in visueel juiste volgorde gezet is. Een reden hiervoor kan zijn dat de MIME standaard ([RFC2045], [RFC1556]) de voorkeur heeft voor visuele volgorde, hetgeen right-to-left karakterreeksen zijn die right-to-left ingevoegd worden in de byte stream. In een e-mail zou het volgende, inclusief de regeleinden, opgemaakt kunnen zijn als:
engels1 2SWEERBEH engels3 4SWEERBEH engels5 6SWEERBEH
Dit is in conflict met het [UNICODE] bidirectionele algoritme omdat dat algoritme 2SWEERBEH, 4SWEERBEH en 6SWEERBEH een tweede keer zou omkeren waardoor de Hebreewse woorden left-to-right verschijnen in plaats van right-to-left.
De oplossing in dit geval is om het bidirectionele algoritme te negeren door het E-mailfragment in een PRE element (om de regeleinden te behouden) en elke regel in een BDO element te steken, waarvan het dir attribuut ingesteld is op LTR:
<PRE> <BDO dir="LTR">engels1 2SWEERBEH engels3</BDO> <BDO dir="LTR">4SWEERBEH engels5 6SWEERBEH</BDO> </PRE>
Dit zegt tegen het bidirectionele algoritme "Laat mij left-to-right!" en zou de gewenste presentatie moeten produceren:
engels1 2SWEERBEH engels3 4SWEERBEH engels5 6SWEERBEH
Het BDO element zou gebruikt moeten worden in scenario's waar absolute controle over volgorde vereist is (bijvoorbeeld meertalige stuknummers). Het dir attribuut is verplicht voor dit element.
Auteurs kunnen ook gebruik maken van speciale Unicode karakters om het bidirectionele algoritme te negeren -- LEFT-TO-RIGHT OVERRIDE (202D) of RIGHT-TO-LEFT OVERRIDE (hexadecimaal 202E). Het POP DIRECTIONAL FORMATTING (hexadecimaal 202C) karakter beëindigd beide bidirectionele negering.
Nota. Herinner dat conflicten kunnen optreden wanneer het dir attribuut simultaan gebruikt wordt op inline elementen (inclusief BDO) en de overeenkomstige [UNICODE] opmaakkarakters.
Bidirectionaliteit en karaktercodering Volgens [RFC1555] en [RFC1556] zijn er speciale conventies voor het gebruik van "charset" parameterwaarden om de behandeling van bidirectionalteit aan te geven in MIME mail, in het bijzonder om een onderscheid te maken tussen visuele, impliciete en expliciete directionaliteit. De parameterwaarde "ISO-8859-8" (voor Hebreeuws) geeft visuele codering aan, "ISO-8859-8-i" geeft impliciete bidirectionaliteit aan en "ISO-8859-8-e" geeft expliciete directionaliteit aan.
Omdat HTML het Unicode bidirectionaliteitsalgoritme gebruikt, moeten geldige documenten geëncodeerd gebruik makend van ISO 8859-8 gelabeled worden als "ISO-8859-8-i". Expliciete directionele controle is ook mogelijk met HTML, maar kan niet uitgedrukt worden met ISO 8859-8, waardoor "ISO-8859-8-e" niet gebruikt zou mogen worden.
De waarde "ISO-8859-8" impliceert dat het document visueel opgemaakt is, misbruik makend van bepaalde opmaak (zoals TABLE met rechtse uitlijning en geen automatische regeleinden) om redelijke weergave te verzekeren op oudere User Agents die geen rekening houden met bidirectionaliteit. Zulke documenten voldoen niet aan de huidige specificatie. Indien nodig kunnen ze conform gemaakt worden aan de huidige specificatie (en tegelijkertijd correct weergegeven worden in oudere User Agents) door toevoeging van BDO opmaak waar nodig. In tegenstelling tot wat gezegd wordt in [RFC1555] en [RFC1556], is ISO-8859-6 (Arabisch) niet visueel geordend.
Omdat soms dubbelzinnigheden optreden in de directionaliteit van bepaalde karakters (bijvoorbeeld interpunctie-tekens) bevat de [UNICODE] specificatie karakters voor een correcte oplossing. Unicode bevat ook sommige karakters om controle te hebben over samenvoeggedrag waar dit nodig is (bijvoorbeeld sommige situaties met Arabische letters). HTML 4 bevat karakter referenties voor deze karakters.
Het volgende DTD fragment geeft enkele van de de directionele entiteiten:
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
De zwnj entiteit wordt gebruikt in blok samenvoeggedrag in contexten waar samenvoeging zal voorkomen maar waar dit niet zou mogen. De zwj entiteit doet het omgekeerde; het forceert samenvoeging wanneer het niet zou voorkomen, maar waaneer het zou moeten. Bijvoorbeeld de Arabische letter "HEH" wordt gebruikt om "Hijri" af te korten hetgeen de naam is van het Islamitische kalendersysteem. Omdat de geïsoleerde vorm van "HEH" lijkt op het getal vijf als het in Arabisch schrift gebruikt wordt (gebaseerd op Indic getallen), wordt de initiële vorm van "HEH" gebruikt om verwarring te voorkomen als "HEH" een laatste getal vijf in een jaartal is. Er is echter geen volgende context (er is dus geen samenvoegletter) waarmee de "HEH" kan samenvoegen. Het zwj karakter voorziet deze context.
Gelijkaardig bestaan er in Perzische teksten gevallen waar een letter die normaal samengevoegd wordt met een volgende letter niet samengevoegd zou mogen worden in een aaneengeschreven verbinding. Het karakter zwnj wordt gebruikt voor samenvoeging in zulke gevallen.
De andere karakters, lrm en rlm, worden gebruikt om directionaliteit te forceren tussen directioneel neutrale karakters. Wanneer bijvoorbeeld een dubbel aanhalingsteken voorkomt tussen een Arabische (right-to-left) en een Latijnse (left-to-right) letter, dan is de richting van het aanhalingsteken niet duidelijk (is het een citaat in de Arabische tekst of de Latijnse tekst?). De lrm en rlm karakters hebben een directionele eigenschap maar geen breedte en geen woord/lijn afbreekeigenschap. Raadpleeg [UNICODE] voor meer details.
Gespiegelde karaktertekens. In het algemeen spiegelt het bidirectionele algoritme karaktertekens niet, maar laat ze ongewijzigd. Een uitzondering zijn karakters zoals tussenzinnen (zie [UNICODE], tabel 4-7). In gevallen waar spiegeling gewenst is, bijvoorbeeld voor Egyptische Hierogliefen, Griekse Bustrophedon, of speciale design effecten, zou dit gedaan moeten worden met styles.
In het algemeen is het gebruik van style sheets om de visuele weergave van een element van block-level naar inline of vice-versa te veranderen duidelijk. Omdat het bidirectionele algoritme vertrouwt op het onderscheid tussen inline en block-level, moet speciale aandacht geschonken worden aan de transformatie.
Wanneer een inline element dat geen dir attribuut heeft getransformeerd wordt door een style sheet tot de style van een block-level element, dan erft het het dir attribuut van het dichtstbijzijnde parent block element dat de basisrichting van dat blok definieert.
Wanneer een block element dat geen dir attribuut heeft getransformeerd wordt door een style sheet tot de style van en inline element, dan zou de resulterende presentatie equivalent moeten zijn aan de opmaak verkregen door expliciete toevoeging van een dir attribuut (de overgeërfde waarde toegewezen) aan het transformeerde element.