[Alku]
Testaa CSS-oppaan navigoinnin toimivuutta!
 
 Etsi sivuiltani: [Apua]

Käytetyn termilogia perustelut

Aiheet

Yleistä pohdintaa

Tietokonekieli on perinteisesti pyrkinyt hyvin konkreettisten sanojen käyttöön. Koska suomalainen ei käytä englantia äidinkielenään, tätä ei aina tule riittävästi otettua huomioon. Monilla on orpumus "kääntää" englanninkieliset konkreettiset sanat abstraktimpaan suuntaan. Tämä merkitsee myös sitä, että sanoille annetaan alkukielen termistä selkeästi poikkeava käännösvastine. Näin termin suomenkielisen vastineen läpinäkyvyys samalla menetetään.

Näin en ole halunnut toimia. Olen pyrkinyt pitäytymään nimenomaisesti termin konkreettisuuden ja läpinäkyvyyden alkukielen sanoissa. Esimerkkinä on sana arkki (sheet). Arkki tuo minullekin mieleen ensiksi paperiarkin, mutta sana on tarkoituksella konkreettinen. Arkki on tietokatkelmien konkreettinen säilytyspaikka.

Tietokonekieli vilisee vastaavan tapaisia konkreettisia sanoja. Kirjoitamme dokumenttipuusta ja juurielementeistä. Englannin kielessä kirjoitetaan taulukon päästä, vartalosta ja jalasta (THEAD, TBODY, TFOOT). Tietokoneen näyttöalan on ordemaalarin kangas (canvas). Näyttöruutua voidaan maalata (paint).

Konkreettisia ilmaisuja ei pidä ymmärtää sellaisina, että tiedemaailman pitäisi ne vaihtaa "hienompiin" tieteellis-teknisiin ilmaisuihin. Käyttöjärjestelmät käyttävät visuaalisia kuvakkeita eli ikoneja (icons). Konkreettisiin, elämänläheisiin asioihin viittaavat sanat ovat visuaalisten kuvakkeiden vastineita.

Myös tietokoneohjelmointi perustuu nykyisin konkretisointiin (olio-ohjelmointi). Windows käyttöjärjestelmässä käytetään sanaa kansio (folder), joka on hakemiston konkreettisempi (olio-ohjelmointiin) perustuva vastine.

Jotkut käytetyt sanat ovat jopa sangen arkisia kuten tag. Eräät jopa lähinnä puhekielisiä (esim. pop-up window). Sana tag on joissakin kirjoissa käännetty tarra. Se konkretisoisi muuten helposti liian abstraktiksi jäävää käsitettä. Tosin sen englanninkielinen käännösvastine ei ole tag vaan esim. sticker ja adhesive. Sanan tag voisi kääntää (merkintä)lappu. Asiallisesti käypä vaikkakaan ei aivan sanatarkka käännös olisi myös (merkintä)leima. Elementtejä "leimataan" kuin kaadettavaksi tarkoitettuja puunrunkoja. Englannissa on myös kuvaava käyttö ihmisistä:

he was tagged as stupid - häneen iskettiin tyhmän leima

Tuon sanan käyttäminen edellyttää samantapaista puolikonkreettista ajattelua kuin sanan arkki kohdalla. Arkkien ei tarvitse olla tehty paperista, mutta ne viittaavat kuitenkin konkreettisiin koodin sijaintipaikkoihin. Todennäköisesti amerikkalaiset ajattelevat asioita tuohon tapaan. Asioita osittain konkretisoimalla voidaan tehdään helpommin ymmärrettäväksi muuten liian abstrakteiksi jääviä käsitteitä. Ehkä emme Suomessa ole tottuneet tällaiseen konkretisointiin?

Oikeastaan vasta eurooppalaiset ovat alkaneet kehittää ATK-terminologiaa tieteellisempään (ja samalla abstraktimpaan) suuntaan. Esim. nykyisin Ranskassa W3C-organisaation (Bert Bos) luoma XSL-terminologia on varsin tieteellis-teknistä. Siinäkin on silti säilytetty tuttu sukuun ja sukulaisuussuhteisiin liittyvä vertauskuva. Tämä vertauskuva on säilyttämisen arvoinen.

[Alku]

Yksittäiset sanat

Canvas ja viewport

Sanat piirtopinta ja kangas säilyttävät ilmaisun yleiskielisen merkityksen. Canvas on ensisijaisesti (öljymaaleilla maalaavan taidemaalarin) kangas; ajatuksena on se, että canvas on se pohja, jolle maalataan - vrt. paint, jota myös käytetään ATK-terminä).

Sen rinnalla käytetään sanaa viewport, joka käsittää tällöin vain yksittäisen kehyksen rajaaman ikkunan. Mikäli käytetään ns. virtuaalista työpöytää (virtual desktop), se voi olla suurempi kuin itse näyttöruutu. Tuossa tapauksessa viewport voi olla isompi kuin canvas. Ilman kehyksiä olevien dokumenttien suhteen canvas tarkoittaa useimmiten kuitenkin samaa kuin viewport. Mutta koska ne voivat tarkoittaa myös eri asiaa, käytän paria piirtopinta - katselukanava.

[Alku]
Common entity ja parameter entity

Parameter = muuttuja, (EuroWord96); parametri = suure, jonka muuttuminen vaikuttaa tutkittavaan asiaa, kun asiaan kuuluu varsinaisia suureita (WSOY:n Spectrum).

Ks. selitysyritykseni[S]. Ilmaisujen ongelmana on hyvän sivistyssanakirjan tarve. Henri Ruini kirjoittaa parametrientiteeteistä: Jäsennettyjä entiteettejä, joita käytetään vain rakennemäärittelyssä.

Henri Ruinin XML-sanasto: yleisentiteetti, parametrientiteetti.

[Alku]
CSS

Ne ovat sopusoinnussa CSS-logon kanssa (ks. selitystä ja logoa[S][Pw]).

Termien porrastetut tyylisivut ja porrastyylisivut etuna on myös se, että ne perustuvat HTML-tiedostoja varhaisempaan käyttöön ATK-terminologiassa. Termi tyylisivu on vakiintunut ATK-kieleen jo 1980-luvun puolivälissä DOS MS-Word mukana.

Termi porrastyylisivut perustuu siihen, että on jo olemassa termi porrasvalikko (cascading menu), joten nämä muodostaisivat parin:
Cacading menu => porrasvalikko.
Cascading style sheets => porrastyylisivut.

Sen rinnalla käytän termiä limitetyt tyylisivut, joka uudestaan käännettynä on aina cascading style sheets. Sen vastaavuus suhteessa alkukieliseen termiin on 1:1.

On huomattava, että sana tyylisivu ja sen monikko tyylisivut kuvastaa vain ja ainoastaan sitä, että samassa kokonaisuudessa voi määritellä useita yksittäisiä tyylikuvauksia. Sana tyylisäännöstö viittaa kuvausten määritystapaan. Mikäli tämä näkökulma olisi ollut merkittävä, alkuperäinen termi olisi ollut Cascading Style Rule Sets, CSRS. Sana säännöstö ei sovi attribuutin style sisällä oleville kuvauksille, jotka ovat yksi tapa hyödyntää tyylisivuja. CSS:n kohdalla pitäisi ensisijaisesti kirjoittaa kuvauksista. Juuri kuvaukset määrittelevät esitysasun - ne ovat CSS:n "sydänlyöntejä!" Kuvaukset liitetään yleensä sääntöihin, mutta ei välttämättä. Tässä suhteessa jopa spesifikaation selitys on hieman harhaanjohtava.

Myös sanan tiedosto käyttäminen on virhe. Se antaa väärän mielikuvan. Tyylisivuen ei suinkaan tarvitse olla ulkopuolisissa tiedostoissa vaan ne voivat olla myös dokumentin sisällä joko dokumentin HEAD-osassa tai erityisten tyyliattribuuttien sisällä. Yksittäinen tyylisivu voi sijaita fyysisesti eri paikoissa, mutta niiden muodostama dynaaminen kokonaisuus, tyylisivut määrittää dokumentin lopullisen ulkoasun.

[Alku]
Dtd

Asiallisesti kyse on nimenomaisesti dokumenttityypin kuvausilmoituksesta, sillä <!DOCTYPE...>-koodin jälkeen esitetä mitään kuvausta, vaan sillä ainoastaan ilmoitetaan, mistä löytyy dokumentin ulkopuolella oleva kuvaus. Kyse on viittauksesta (reference). HTML-dokumenteille on joukko standardi dokumenttityyppejä jotka ns. W3C organisaatio on määrittänyt, ja joita sivujen tekijöiden toivotaan noudattavan. Dokumenttityyppi ilmoitus on asiakirjan alussa, esim. <!DOCTYPE HTML PUBLIC "-//w3c//dtd html 4.0 transitional//en">. HTML-dokumenteissa dokumenttityyppi-ilmoitus ei kuulu varsinaiseen asiakirjaan, vaan sitä käyttävät joko ns. validaattorit (koodin oikeellisuuden tarkastajat) or selaimet, mikäli mukana on linkki dokumenttityypin määrittävään tiedostoon (DTD) kuten esim. "http://www.w3.org/tr/rec-html40/loose.dtd". Tällöin selain voi ladata sen muistiinsa. Ilmoituksen käyttäminen ei ole välttämätöntä, mutta silti erittäin suositeltavaa. XML-dokumenteissa DTD-tiedosto (sen käyttö ei ole pakollista) tuo selaimelle aina lisäinformaatiota ja se on joissakin tapauksissa välttämätön.

[Alku]
ID ja identifier

Identifier on myös monen muun kielen käyttämä termi. Ongelmana tämän sanan kääntämisessä on se, että CSS:ssä ja SGML:ssä sitä käytetään laaja-alaisesti. Javassa ja web-ohjelmointikirjoitekielissä (JavaScript, JScript ja ECMAScript) sitä käytetään rajoitetummin. Niissä se tarkoittaa käyttäjän yksilöimää koodin osaa (muuttuja, funktio ja olio). CSS:ään verrattuna sanan identifier merkitys on näissä kielissä lähempänä lyhenteen id kuin sanan identifier sisältöä. Javassa sama sana on syytä kääntää tunnus, sillä se yksilöi kielen kirjoittajan antamia nimiä.

Katso käsitekaaviosta kohta Tunnisteet[S].

[Alku]
Inline element

Käännökset rivinsisäinen elementti ja rivinsisäiselementti ovat alkukielen ilmaisun mahdollisimman selkeitä ja tarkkoja käännöksiä, jotka erottuvat selkeästi tietyksi termiksi. Jos sen laittaisi kolmiosaisena sanaliittona rivin sisäinen elementti, se ei erottuisi muun tekstin seasta alkukielisen termin käännösvastineeksi. Termien erottuvuutta voi testata kirjoittamalla pätkän tekstiä ja katsoa, miten termi toimii. Muutama esimerkki termien testaamistekstejä:

Kun kirjoitan jostakin rivin sisäisestä elementistä, et sinä välttämättä hahmota, että sanat rivin sisäisestä elementistä viittaavat alkukieliseen termiin inline element vaan luulet minun vain omin sanoin selittävän jotain asiaa.

Mutta kun kirjoitan sinulle rivinsisäisestä elementistä, alat jo miettimään, miksi kirjoitin yhdyssanan rivinsisäisestä - nyt sanaparista rivinsisäinen elementti tuleekin kielestä toiseen siirryttäessä läpinäkyvä termi. Vielä selvemmin termi erottuu, kun käytän sanaa rivinsisäiselementti. Siitä tulee myös selkeä pari lohkoelementille, jolloin voi kirjoittaa lohko- ja rivinsisäiselementeistä.

Suomen kieli tarjoaa mahdollisuuden sekä selittäviin ilmaisuihin että tarkkoihin termeihin: rivin sisäinen elementti => rivinsisäinen elementti => rivinsisäiselementti. Yhteen liimattujen termien ainoa ongelma on pituus, koska tavutus ei toimi internetissä. Vaihtoehtona on amerikkalaistyyliset väliviivat eli rivinsisäis-elementti, jolloin termi katkeaa kontrolloidusti (käytäntö on kuitenkin joissakin kohdin nykykieliopin vastainen).

Termien erottuvuuden vuoksi alkukielessä on kaksiosaiset termit ja vähän joka väliin väliviivoja, esim. first-child pseudo-class. Normaalikielessä sen voisi tietenkin ilmaista ilman väliviivoja, mutta jotta se erottuisi ATK-termiksi, amerikkalaiset käyttävät väliviivoja. Tämä periaate on vielä selvemmin esillä XSL-terminologiassa, esim. ancestor-of-self, joka normaalikielessä on ilman väliviivoja. Mielestäni on syytä keskustella amerikkalaistyylisten väliviivojen käytöstä ATK-terminologiassa samaisesta syystä, miksi Bert Bos (CSS ja XSL keskeisiä tekijöitä). Luulen, että Bert Bos ja kumppanit ovat ajautuneet esittämiinsä konventioihin pakon sanelemina. Suomessa tosin sanat eivät ole niin onnettoman lyhyitä kuin englannin kielessä. Yhtä paljon niitä ei ole syytä käyttää, mutta kylläkin tilanteissa, joissa termeillä on vaarana "liueta" muuhun tekstiin kuin lihaliemikuutio perunasoppaan. Toisaalta ne eivät saa olla liian kömpelöä suomenkieltä, jolloin termit ylierottuvat tekstin "nielemistä" haittaaviksi "klimpeiksi". Suomalaisten käännösvastineiden ei tarvitse olla yhtä kömpelöä kieltä kuin alkuperäistermien.

Tosin termin erottuvuuden tarve vaihtelee eri. Kehysopetussivuilla käännän sanan attribute sanalla määrite, koska termin ei tarvitse olla "läpinäkyvä" eikä sillä ole suurta terminologista merkitystä. Vastaava sana tulee kääntää kuitenkin CSS-oppaassa attribuutti, jotta se selkeästi erottuisi termeistä elementti ja ominaisuus sekä yleisen kielenkäyttöni sanasta määrittely . Tähän liittyy myös se, että sanan properties käännös täytyy olla eri kuin attributes, sillä edellistä käytetään HTML-kielen kanssa ja jälkimmäistä CSS-määrittelyissä - molemmat termit voisi asiallisesti kääntää sanalla määrite, sillä molemmilla määritellään elementtien ulkoasua. Pari määrite - ominaisuus ei ole CSS-oppaassa riittävän selkeä. CSS-sivuilla tiettyjen termien tulee näillä sivuilla olla selkeästi läpinäkyviä siirryttäessä suomenkielisestä versiosta englanninkieliseen versioon or päinvastoin.

[Alku]
Meta

Tuli mieleen sellainen firma kuin Transmeta, jossa työskentelee Linus Torvalds ja jota rahoittaa Microsoftin toinen perustajista Paul Allen. Firma ei kerro mitään itsestään, mutta mielestäni firman nimi on erittäin paljastava. Muutamia ajatuksia, mitä Trans + Meta -arvoitus pitää sisällään (koska kyse on selkeästi arvoituksenomaisesta nimestä, nimen osat voi olla myös toisinkin päin):

Kalifornian piilaaksossa on muuten toinenkin "metafirma" - Metacreations, jonka eräät tuotteet (Bryce 3, Fractal Design Expression) ovat vallankumouksellisia ja ansaitsevat nimensä metaluomuksina - tosi näitä metatuotteita ei laajemmin tunneta, mutta ne edustavat alansa huipputeknologiaa. Itse käytän tällaista "metaohjelmaa" - siitä kerron piirrossivuillani[S][Pw].

Creature House, Metacreations.

[Alku]
Parent element

Termi emoelementti on oikeastaan metatermi tasoa, sillä sanaa emo käytetään hakemistoista (parent directory emohakemisto) eikä se estä kirjoittamasta lapsielementeistä (Child element) - äitiäkin voidaan kutsua "emoksi". Ilmaisun syvä luonne perustuu siihen, että tietokoneen tärkeintä osaa nimittäin sanalla emolevy (Mother board). Ilmaisu ei mene vain ohjelmisto- ja jopa laitetasolle - sanan avulla pystyy selittämään tietotekniikkaa laitetasolta ohjelmistojen pintatasolle asti ja se käy termistä melkein missä paikassa tahansa. Itse asiassa termi emo menee syvemmälle ATK-kieleen kuin vastaavat alkukieliset ilmaisut, sillä emolevy ja emohakemisto käyttävät eri sanoja (mother board - parent directory).

Sanan ainoa ongelma on siinä, että ancestor käännetään yleensä esi-isä. Se ei viittaa kuitenkaan millään lailla sukupuoleen vaan ainoastaan yhteen esivanhempaan. Jotta terminologian analogia olisi johdonmukainen, se pitäisi kääntää esiemo, jolloin saataisiin sangen johdonmukainen sarja esiemo - emo - lapsi - jälkeläinen. Sarja esi-isä - isä - lapsi - jälkeläinen on homogeenisempi kuin esi-isä - emo - lapsi - jälkeläinen. Seuraavaksi paras olisi esi-äiti - emo - lapsi - jälkeläinen.

Ilmaisu ympäryselementti käy aputermiksi. ATK-kielissä on kuitenkin hyvin usein mukana periytyminen. Sen kanssa sopii yhteen sukuun perustuva metafora. CSS-terminologiaa ei pidä myöskään eristää omaksi saarekkeekseen, jolloin yleinen ATK-kielten metafora on syytä säilyttää. Samoin läpinäkyvyys kielestä toiseen siirryttäessä on syytä säilyttää.

[Alku]
Tag

Sana merkkaus jäsentyy muuhun terminologiaan HTML- ja XML-kielten nimien kautta. Molemmat ovat merkitsemiskieliä (markup languages), joiden käyttämät elementit tarvitsevat merkintäkoodeja. Koska merkintäkoodeja on usean eri tyyppisiä, käytän elementtiä koskevista merkintäkoodauksista nimeä elementtimerkkaus.

Tätä voi perustella myös SGML-spesifikaatiolla. SGML-terminologiassa tag tarkoittaa erityisesti elementin rakennekoodausta esittävää merkintäkoodia:

Markup that describes the structure and other attributes of a document in a non-system specific manner, independently of any processing that may be performed to it. In particular, SGML descriptive markup uses tags to express the element structure.

Tag on sanan markup osajoukko. Tämä tulee esille eräissä englanninkielisissä teksteissä:

NCSA.

Kun suomenkielessä liitetään sanaan merkintä tarkennin eli kirjoitetaan elementtimerkintä, sen alkukielinen vastine on element markup. Sitä ei juuri voi ymmärtää muuta kuin ilmaisun markup tag synonyymiksi. Tag ja markup eivät ole kuitenkaan toistensa täydellisiä synonyymejä, vaikka tag on sinänsä oikein käännettynä merkintä. Sanaa tag käytetään kuitenkin myös eräissä sanaliitoissa, kuten comment tag. Jos halutaan erottaa sanojen markup ja tag käännösvastineet toisistaan, tulee käyttää jotain muuta sanaa kuin merkintä, esim. merkkaus. Sanan merkkaus eteen voi liittää tarvittaessa tarkentimen, esim. alkumerkkaus, kommenttimerkkaus ja elementtimerkkaus jne.

Ks. käsitekaaviosta kohdat Elementtimerkkaukset[S]) ja Merkintäkoodit[S]).

Tämä käännösvastine mukailee myös yleiskielisiä sanoja osoitelappu, hintamerkintä tms., joissa englannin kielessä käytetään sanaa tag. Termi elementtimerkkaus luonnollinen käännös takaisin englannin kieleen on element tag. Vastaavuus alkukieleen on niin lähellä 1:1 kuin järkevästi ottaen on mielekästä. Elementtien merkkaus on kooditasolla sangen konkreettinen toimenpide. Myös merkkauksen lopputulos on useimmissa tapauksissa dokumentin lukijan nähtävissä. Voisin kannattaa jopa niinkin konkreettista käännösvastinetta kuin (merkintä)leima.

Suomessa ainakin Helsingin yliopisto käyttää sanaa tunniste (Arto Wikla, Ohjelmoinnin perusteet Java-kielellä, s. 238, samoin Henri Ruini XML-sanastossaan).

Henri Ruinin XML-sanasto: t.

On tietenkin selvää, että elementin nimi ei toimi tunnistimena SGML-pohjaisissa kielissä ilman alku- ja päätöserottimia. Ilmaisu on sikäli oikein, että selaimen toimintamekanismin kannalta elementin alku- ja loppumerkkaukset toimivat tunnisteina. Sana tunniste ei kelpaa sanan tag käännösvastineeksi, mutta sillä voidaan selittää sanan tag sisältöä, esim.:

Jotta elementit erottuvat tekstistä, niillä täytyy olla jokin tunniste. Siitä käytetään englannikielessä nimeä tag, joka voidaan suomentaa esim. sanalla merkkaus.

Koska englanninkielisissä erilaisten spesifikaatioiden (SGML, CSS2, XML-kielet) teksteissä sanalla idenfier on eri merkitys kuin sanalla tag, sanan tunniste käyttö sanan tag vastineena on ristiriidassa englanninkielisen ATK-terminologian kanssa.

Sanalla identifier on usein tarkennin. SGML:ssä käytetään mm.termiä generic identifier, jolla tarkoitetaan elementin nimeä (termi on epätarkka, sillä oikeastaan sen tulisi kuulua generic element type identifier). Siinä sanotaan näin:

generic identifier (GI) = A name that identifies the element type of an element

Lisäksi SGML sisältää ison joukon muita tunnisteita (owner identifier, notation identifier, owner identifier, public identifier, registered owner identifier, system identifier, text identifier, unregisterd owner indentifier).

Sanaa identifier käytetään CSS2:ssa SGML:n tapaisesti kaikista kielen tarvitsemista tunnisteista. Myös siinä elementtityypin nimi on tunniste (esim. BODY). Elementin nimen ohella elementtitunnisteena voi toimia myös jokin attribuutti, kuten seuravasta CSS2 4.13 sitaatistakin käy ilmi (class ja ID liittyvät attribuutteihin):

In CSS2, identifiers (including element names, classes, and IDs...

Ks. käsitekaaviosta kohta Tunnisteet[S].

Kun sana identifier liittyy elementteihin, se on siis sekä SGML:n että CSS:n terminologiassa vain jokin elementin aliosa, ei koko elementin alku- tai loppukoodaus. Sana tunniste palauttaa uudestaan käännettynä sanan identifier. Elementtitunniste palauttaa sanan element identifier. Kummatkaan eivät ole sanan tag teknis-tieteellisiä synonyymejä.

Jokaisella kielellä tuntuu olevan hieman poikkeava käyttö sanalle identifier, mutta yleisesti se liittyy nimiin. Javassa sillä on rajoitetumpi käyttö kuin CSS:ssä, sillä vain ohjelmoijan itse käyttämiä nimiä kutsutaan tunnisteiksi. Javassa ja JavaScript -kielissä identifier voidaan kääntää (yksilöivä) tunnus.

CSS-opetuksessa sanojen tag ja idenfier käännösvastineiden tulee ehdottomasti olla SGML ja CSS2 spesifikaatioiden mukaisia. Paitsi että sanan tag kääntäminen tunniste on terminologinen virhe, se lisää jo entuudestaan ylirasitetun termin tuomia käsiteongelmia. Kyse on yksinkertaisesti siitä, että sanan tag kääntäminen on sanalla tunniste luo epämääräisen, paljon sekaannuksia aiheuttavan ATK-terminologian!

Kun kääntää tag on tunniste, se on vähän sama kuin kääntäisi watercraft = vene. Vene on toki vesikulkuneuvo, mutta niin on myös laiva ja ilmatyynyalus. Laivassa on lisäksi joukko pelastusveneitä. Laiva siis voi sisältää useita vesikulkuneuvoja. Samalla tavalla tag voi sisältää suuren joukon erilaisia tunnisteita. Väännetään lopuksi vielä rautalangasta malli, mitä kaikkia tunnisteita seuraava elementtimerkkaus voi sisältää:

<A href="joku.hml" target="new" class="oma" id="toinen">

Tämä elementtimerkkaus on seuraavien tunnisteiden "rahtialus" (kyseisiä tunnisteita voidaan käyttää CSS-säännöissä):

CSS-opetus ei yksinkertaisesti onnistu kunnolla, jos sanaa tunniste ei käytetä juuri täsmälleen siinä merkityksessä, jossa spesifikaatio sitä itse käyttää! Jos toisin yrittää, tulee sekavaa termipuuroa, joka sekoittaa oppilaan pään ihan totaalisesti! Jotta voi selittää täysin yksiselitteisesti, mitä merkitsee pattern matching, oppilaan täytyy yksiselitteisesti tietää, mitä tarkoittaa CSS2 spesifikaatiossa sana tunniste.

Käyttämäni sanan merkkaus etuja ovat:

Ks. käsitekaaviosta kohdat Elementtimerkkaukset[S] ja Tunnisteet[S].

Tagi/tägi on siinä mielessä hyvä, että sillä ei ole ylimääräistä "taakkaa". Koska se ei ole käännös vaan väännös, se on täydellisen läpinäkyvä kielestä toiseen siirryttäessä. Sanalle tag ei voi antaa "fiksua" täysin muista termeistä erottuvaa suomenkielistä vastinetta. Muista erottuvan vastineen täytyy olla samaan tapaan suhteellisen arkista kielenkäyttöä kuin mitä sana tag itsessään edustaa. Sanan merkkaus ainoa "haitta" onkin sen arkisuus (lähin lievästi muihin termeihin sekoittuva käännösvastine on merkintä tarkennettuna tilanteeseen sopivalla etuliitteellä).

Huomautus. Monissa ATK-kielissä alku- ja loppukoodaukset luovat muotoilukoodeja. Näin ei ole kuitenkaan asianlaita HTML- eikä varsinkaan XML-asiakirjoissa. XML-dokumentissa kaikki elementit ovat itsessään vain sisällyksettömiä merkkauksia. Elementtien merkitys täytyy aina kuvata jollakin tavalla. HTML-dokumenteissa HEAD-osan elementit eivät ole muotoilukoodeja vaan ne sisältävät tai rajaavat ilmoitus- ja ohjelmointikoodauksia. Runko-osan elementin A aloitus- ja päätösmerkkaukset ovat vain paikan merkitsemistä. Ne ovat eräänlaisia kirjanmerkkejä. Kaikki XML- ja HTML-dokumenttien elementtien alku- ja loppumerkkaukset sekä tyhjien elementtien koodit ovat silti elementtimerkkauksia.

Jos elementtien merkinnät selkeästi muotoilevat dokumenttia, voi niistä yksittäistapauksissa käyttää myös ilmaisua muotoilukoodi. Haluan kuitenkin korostaa, että tag ei yleisesti ottaen ole visual formatting code (tai minkään muunkaan muotoilutavan koodaus) vaan teknisessä mielessä vain elementtimerkkaus.

[Alku]
White-space, whitespace, whitespace character

Se on alkuperäistermin mahdollisimman suora käännös. White-space väliviivalla tarkoittaa tekstin esittämiseen liittyvää ominaisuutta, miten selain käsittelee välilyönneistä aiheutuvia tyhjiä välejä elementtien aloitus ja päätöskoodien välillä:

...this property declares how whitespace inside the element is handled.

Ominaisuus white-space ei koske käyttäjän tekemiä ylimääräisiä rivikatkoja, koska niihin liittyvät elementit BR ja HR.

On myös syytä huomata, että sanalla white-space ei tarkoiteta koodissa olevia tyhjiä alueita, jotka jätetään huomioimatta. CSS:ssä on kyse ominaisuuksista, jotka on tarkkaan spesifioitu. Tuo väliviiva on laitettu juuri siksi, että ominaisuus nimeltään white-space erottuisi sitä kuvaavasta ilmaisusta whitespace ja koodikielessä käytettävästä sanasta whitespace. White-space on ominaisuuden erisnimi. Ominaisuuden selittämisessä spesifikaatio viittaa sanan whitespace yleiseen käyttöön tekstialueissa sekä sisältää linkin sanan käyttöön CSS-ohjelmoinnissa. Ohjelmakoodissa whitespace tarkoittaa sellaisia alueita, jotka jätetään käsittelemättä kuten ylimääräiset välilyönnit, rivikatkot ja rivinpalautukset. CSS-koodauksessa saa jättää tyhjiä alueita ominaisuuksien väliin, mutta mielellään vain yksi välilyönti. Ominaisuuksien luettelemisessa voi laittaa ";"-merkin jälkeen rivikatkoja.

Whitespace ja white-space kuvaava siten eri asioita (jälkimmäinen on jonkinlainen kuvaannollinen (ja löysä) edellisestä merkityksestä johdettu sanan käyttö):

  1. Lähdekoodin whitespace.
  2. Näytöllä toteutunut "graafinen" ominaisuus white-space.

Näiden välinen ero on saman luonteinen kuin CSS-ominaisuuden display, johon CSS2 spesifikaatiot kirjoittavat heittomerkit, ettei se sekoittuisi eri ohjelmien näyttöruudun ominaisuuksiin (display properties) - display properties on eri asia kuin display properties aivan samaan tapaan kuin CSS:n ominaisuus white-space on eri asia kuin whitespace (myös display on ominaisuuden erisnimi). On tietenkin harmillista kuin yleisen terminologian sanat ja tarkkaan määritellyt ominaisuudet ovat terminologisesti näin lähellä toisiaan ja spesifikaatioihin joudutaan luomaan keinotekoisia erotteluita.

Ominaisuus pre kasaa tekstin laatikkomaiseksi, jolloin tyhjiä sanavälejä tulee mahdollisimman vähän. HTML elementeistä saman tekee elementti PRE. Elementin PRE käyttäytymisestä Steven Hunter kirjoittaa mm.:

NOTE: References to the "beginning of a new line" do not imply that the renderer is forbidden from using a constant left indent for rendering preformatted text. The left indent may be constrained by the width required.
[Alku]