Luettelen alla aihealueittain tekemäni aihepiirit. Paluulinkkeinä tähän aihepiiriin on tämä valikko ja sivun yläreunassa oleva linkki Aihepiiriluettelo.
| ||||||||||||||||||
![]() | Aihepiiriluettelo > CSS-oppaan etusivu > Oppaan lisäsivut > S Millaista terminologiaa olen käyttänyt > Käytetyn termilogian perustelut (lisäjakso a) |
|---|
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.
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.
Parameter = muuttuja
, (EuroWord96); parametri =
suure, jonka muuttuminen vaikuttaa tutkittavaan asiaa, kun
asiaan kuuluu varsinaisia suureita
(WSOY:n Spectrum).
Ks. selitysyritykseni
.
Ilmaisujen ongelmana on hyvän sivistyssanakirjan tarve.
Henri Ruini kirjoittaa parametrientiteeteistä:
Jäsennettyjä entiteettejä, joita
käytetään vain
rakennemäärittelyssä.
Ne ovat sopusoinnussa CSS-logon kanssa (ks. selitystä ja logoa![[S]](../Kuvat/buttons/S.gif)
).
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.
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.
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
.
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ä sanatrivin sisäisestä elementistäviittaavat alkukieliseen termiininline elementvaan luulet minun vain omin sanoin selittävän jotain asiaa.
Mutta kun kirjoitan sinullerivinsisäisestä elementistä, alat jo miettimään, miksi kirjoitin yhdyssananrivinsisäisestä- nyt sanaparistarivinsisäinen elementtituleekin kielestä toiseen siirryttäessä läpinäkyvä termi. Vielä selvemmin termi erottuu, kun käytän sanaarivinsisä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.
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):
metakäännös,
meta(tieto)liikenneja
metaliiketoimi
transon latinaa ja
metakreikkaa, jolloin sanat ovat toistensa synonyymejä ja kyseessä on hieno sanaleikki. Latinassa ja kreikassa sanoilla on kuitenkin eri vivahteita. Trans etuliitteenä (jollaisena se on nimessä Transmeta) merkitsee latinassa
toisella puolella olevatai
tuolle puolelle,
ylija meta
takanaeli eri merkityksiä kooten ja siten suomennettuna siinä sanotaan:
toiselta puolen, ylitse kaiken ja kaiken taakse. Siis sama perusidea kuin jos käännetään nimet osat toisin päin. Ainakin pyrkimyksenä on jonkinlaisen "metaprosessorin" luominen.
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]](../Kuvat/buttons/S.gif)
.
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ää.
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ä:
mark upHTML-elementtien ja niiden sisältämien attribuuttien muodostamasta kokonaisuudesta (sanoilla on hieman toisistaan poikkeavia kirjoitusasuja, joten
mark up=
markup).
markup tag.
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
) ja
Merkintäkoodit
).
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).
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. sanallamerkkaus.
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
.
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ä):
A = elementtityyppitunnisteoma = luokkatunnisteclass = luokka attribuuttivalitsimen
tunnisteenaclass="oma" = luokka + sen nimi
attribuuttivalitsimen tunnisteenatoinen = id-valitsimen tunnisteid = idattribuuttivalitsimen tunnisteena
id="toinen" = id+ sen nimi attribuuttivalitsimen tunnisteena
href = hreferäiden näennäisluokkien tunnisteena
href = attribuuttivalitsimen tunnisteenahref="joku.html" = attribuuttivalitsimen
tunnistetarget = attribuuttivalitsimen tunnistetarget="new" = attribuuttivalitsimen
tunnisteCSS-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:
merkintä(markup) että
tunniste(identifier).
Ks. käsitekaaviosta kohdat Elementtimerkkaukset
ja
Tunnisteet
.
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.
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ö):
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.
whitespacerinnalla ilmaisua
whitespace character(esim. Ecmascript standardissa). Kyseessä on yhden kirjaimen muodostama tyhjä tila tai sitä vastaava koodi. Tämän käännökseksi sopii esim.
valkoaluemerkki.
tila,
avaruus,
alue. Suomenkielessä
tilaalkaa kuinka pienestä tahansa päättyen äärettömyyteen. Tila voi olla joko kaksi- tai kolmiulotteinen - avaruuskin on tila. Kyseessä on tarkin mahdollinen käännösvastine. Yksi
whitespace charactermuodostaa tilan, samoin kuin tabulointien ja useiden rivikatkojen muodostama laajempi alue. Ongelmana ilmaisulla
valkotilaon se, että hindulaisuus käyttää vastaavantyyppisiä ilmauksia.
spacekääntäminen sanalla
alueon hieman epätarkempi, sillä alue tarkoittaa puhekielessä yleensä jotain aivan pientä suurempaa. Toisaalta jos määritellään alue =
yksi tai useampi merkki, sanaa
valkoaluevoidaan käyttää.
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.