Etsi sivuiltani:

	Aihepiiriluettelo > CSS-oppaan etusivu > Oppaan lisäsivut > B Mitkä ovat CSS2-spesifikaation ongelmia

B Mitkä ovat CSS2-spesifikaation ongelmia

Aiheet

• Yleistä
• Sisältöleveys
• Rivinsisäislohkot
• Sisäkkäisten lohkojen keskittäminen
• Lomakkeet
• Kutistetut taulukkoreunukset
• Katselukanava
• Plug-ins -sovellus CSS3:lle?
• CSS3:n tuomat korjaukset

Yleistä

CSS2 spesifikaatiossa on joitakin tiedettyjä virheitä, jotka on huomattu spesifikaation julkaisemisen jälkeen. Tällaisia korjauksia on mm. se, että spesifikaation on lisätty alaviivan (_) salliminen id ja class attribuuttien nimissä. Tämä on hyvä juttu sikäli, että JavaScript-koodauksessa on yleisenä tapana käyttää alaviivaa. Kaikki selaimet eivät sitä kuitenkaan vielä tue (katso mallisivu).

Näiden lisäksi CSS2:ssa on muutamia tärkeitä puuttuvia piirteitä, mikä voi johtua siitä että CSS1 suunniteltiin ensisijaisesti HTML-asiakirjoja varten. HTML-asiakirjoissa näkyvillä HTML-elementeillä on yleensä oletuksena tietty esitysasu ja käyttäytyminen. XML-elementeillä niitä ei ole ja tässä mielessä CSS on liikaa HTML-orientoitunut.

Joissakin suhteissa CSS2 on liian monimutkainen. Tätä seikkaa ei ehkä enää voida mitenkään korjata, mutta annan silti yhden ehdotelman, miten olisi voitu menetellä yksinkertaisemmalla tavalla.

Sisältöleveys

HTML:ssä sisältö määräytyy DTD:stä käsin eli sisältö on kaikki, mikä voi olla lapsielementtinä (suoranaisena sisältöelementtinä ilman väliin jääviä elementtejä) tai datana jollekin elementille (XML-dokumenteissa käytettyjen elementtien sisältöä ei ole välttämättä tarkoin määritelty). Yleensä sisältö on aloitus- ja päätösmerkkauksen välissä. Korvattavilla elementeillä se haetaan erillistiedostosta, joka sijoitetaan alkuperäisen elementin tilalle. Tässä tapauksessa jokin attribuutti ilmaisee korvattavan sisällön (esim. <IMG src="korvattavaSisalto.gif">). Koska sisältöleveys (content width) tarkoittaa nimensä mukaisesti elementin sisälle varattavaa konkreettista tilaa, siihen ei kuulu mahdolliset koriste-/ erotustarkoituksissa käytetyt reunukset (borders) eikä elementille määritelty täytealue (padding) - ne ovat vain elementeille annettuja lisäattribuutteja tai -ominaisuuksia.

HTML-attribuuteissa attribuutti width on toisinaan kokonaisleveys ja toisinaan sisältöleveys. Se on elementille TABLE kokonaisleveys (nimitän tätä arvoa englanniksi total width), jolloin attribuutin width arvoon lasketaan mukaan myös mahdolliset reunukset eikä pelkkä sisältö. Korvattavalle rivinsisäiselementille IMG se on sisältöleveys, johon ei lasketa mukaan mahdollisia reunuksia. Koska HTML:n attribuutit ovat elementtiriippuvaisia attribuutin width ei tarvitse olla laskettu samalla periaatteella.

CSS width-ominaisuus koskee sekä lohkoja että korvattavia rivinsisäiselementtejä. Koska elementtien käyttäytymistapaa voi muuttaa ja ominaisuuksia voi soveltaa lähes kaikille elementeille, CSS:n ominaisuuksien määrittelyperiaatteiden elemettiriippumattomia. CSS:n luojien (Håkon W. Lie ja Bert Boss) piti valita, joko content widht tai total width, mutta ei molempia.

CSS:ssä ominaisuus width on elementin sisällön leveys, ei sen kokonaisleveys. Elementti, jolla on sisältö on kuin "lahjapaketti", jolloin sisältö on "lahja" itse. Toivon, että alla oleva kuva voisi havainnollistaa, mitä sisältöleveydellä tarkoitetaan.

Huomautus. Mikäli jollekin elementeille voidaan laittaa reunukset myös HTML-attribuuttina border, nämä reunukset eivät kuulu elementin sisältöön eikä niiden tule muuttaa CSS:llä määriteltyjen elementtien dimensioiden laskentaperusteita. HTML-reunukset ovat vain elementin "koristeita" aivan kuten CSS-reunuksetkin. Mikäli CSS:ää ei ole määritelty width or border ominaisuuksia, mutta vastaavat tai vastaavankaltaiset HTML-attribuutit on määritelty, käytetään HTML-attribuuttien asettamia arvoja. CSS-arvot saavat kuitenkin etusijan, mikäli molempia on käytetty. CSS:ää pitää pystyä soveltamaan samoja laskentakaavoja noudattaen myös XML-dokumentteihin, joilla ei ole mitään esimääriteltyä laskentatapoja.

Content width -periaate soveltuu luontevasti kuville. Mahdollisesti juuri kuvien dimensioiden määrittelytapa oli lähtökohtana, kun valittiin mikä on mitoitusperiaate. Esim. erilaisista elementin IMG mitoitustavoista:

<IMG width="100" height="100" style="height:100px; width:100px">
<IMG border="1" width="100" height="100" style="height:100px; width:100px">
<IMG width="100" height="100" style="height:100px; width:100px; border:1px solid black">

Mitä tapahtuisi jo width ominaisuus ei olisi kuville content width vaan total width? Oletetaan että kuvan luonnollinen koko olisi 100x100 pikseliä, kun sille laitetaan border="1" tai border:1px solid black, miten tulisi menetellä? Ainakin border-ominaisuuden kanssa kuva pitäisi skaalata kokoon 99x99 pikseliä, jolloin lopputulos voisi olla ikävä. Miten tulisi menetellä border-attribuutin kanssa? Koska se ei ole CSS-määre, pitäisikö kuvan sisältöleveys säilyttää 100x100 pikselinä? Total widht -periaate olisi tuonut kuvien suhteen laskentaongelmia! Mikäli kuvan dimensiot olisi määritelty CSS:llä, kun kuvalle olisi lisätty reunat, olisi pitänyt muistaa lisätä kuvan leveysarvoa.

Taulukoissa content width -periaate tuo ongelmia, mikäli taulukoilla on reunukset. Myös prosenttiarvot ovat ongelmallisia, erityisesti width:100%, jolla yritetään luoda täysleveä taulukko. Total width -laskentaperiaate olisi ainakin taulukoissa ongelmattomampi. Opera 5.x tuntuu seuraavan tiukimmin CSS-spesifikaatiota siinä kun muut selaimet soveltavat HTML:n total width -periaatetta CSS:ään (ks. sivu 10).

Taulukoiden dimensioiden laskemisessa on myös muita ongelmia. Mitä tarkoittaa table {padding:10px}? Pitäisikö se hylätä? HTML 4.01:n DTD-tiedostojen mukaan elementin TABLE sisältö on vähintään yksi is TBODY (käytännössä useimmissa tapauksissa TR), jolloin teoriassa padding on TABLE ja TBODY tai jonkun muun elementin TABLE lapsielementin välissä (useimmiten kyseeseen tulisivat TABLE ja TR elementit). Tämä ei kuitenkaan sovi taulukkojen reunusmallien konsepteihin. Myöskään TR {margin:10px} ei sovi reunusmallien konsepteihin. CSS2-spesifikaatio kertoo, milloin border voidaan soveltaa ja milloin se pitää hylätä. Spesifikaation pitäisi selittää myös olosuhteet, joissa margin ja padding pitäisi hylätä. Spesifikaatio ei ole riittävän selkeä.

Yleisesti ottaen Microsoftin Windows-porukka yritti width-ominaisuuden toteutuksessa soveltamaan taaksepäin yhteensopivuus (backward-compatibility) -periaatetta width-ominaisuuden tulkinnassa suhteessa HTML width-attribuutteihin, josta seurasi epäyhtenäinen, virheellinen CSS-tulkinta. Tietyillä DTD-määrityksillä MS IE 6.0 Windows joko seuraa edellisiä Windows-versioita or (melkein oikein) CSS-spesifikaatioita.

Enkä yleisesti ottaen total width -periaate olisi ollut suunnittelijoille helpompi hallita, sillä kuville harva laittaa CSS:llä dimensioita, mutta valittu mikä valittu. Suunnittelijoiden kannalta olisi tosin ollut parasta, jos olisi kaksi erilaista leveysominaisuutta. CSS3:ssa onkin ehdotettu kahta eri mallia, miten width laskettaisiin (4.4 box-sizing (interpetation of width and height)). Ominaisuus box-sizing määrittää laskentakaavan. Oletuksena on content-box, joka vastaa CSS2:n nykyistä käytäntöä. Sen vaihtoehtona on border-box, joka vastaa HTML:stä usein käytettyä laskentatapaa, jossa border ja padding lasketaan mukaan width-arvoa määritettäessä. Tällöin <TABLE width="100%"> voitaisiin korvata <TABLE style="box-sizing:border-box; width:100%">. Erityisesti kaikissa prosenttiarvoilla annetuissa dimensioissa border-box olisi hyödyllinen.

W3C: CSS2: 8 Box model, 8.1 Box dimensions, 10.2 Content width: the 'width' property, 17 Tables, 17.6 Borders; CSS3: User Interface for CSS3 (W3C Working Draft 16 Feb 2000).
Microsoft:CSS Enhancements in Internet Explorer 6 Public Preview.

Rivinsisäislohkot

Tavanomaiset HTML-elementit voidaan jakaa käyttäytymisen suhteen kahteen pääryhmään, rivinsisäiselementteihin (inline level elements) ja lohkoelementteihin (block level elements). CSS2 pystyy useimmissa tapauksissa kuvaamaan oikein näiden elementtien käyttäytymisen sekä HTML että XML-dokumenteissa.

Ongelmana ovat eräät erityiset rivinsisäiselementit, jotka kyllä liikkuvat rivin mukana kuin fraasi, mutta jotka luovat ympärilleen suorakaiteen muotoisen lohkon. Tämän tyylisiä elementtejä ovat ns. korvattavat rivinsisäiselementit (replaced inline level elements).

CSS2 spesifikaatio selittää, kuinka selainten tulee sovittaa CSS:ää normaaleille, ei-korvattaville rivinsisäiselementeille (non-replaced inline level elements) kuten STRONG ja korvattaville rivinsisäiselementeille (replaced inline level elements) kuten IMG. Ero koskee erityisesti ominaisuuksien width, height, margin ja padding arvoja.

W3C: CSS2: 10 Visual formatting model details.

Vaatiessaan erilaista esitystapaa ei-korvattaville ja korvattaville rivinsisäiselementeille, CSS2 edellyttää, että selaimilla on tiettyjen elementtien suhteen käytös inline-block (rivinsisäislohko). CSS2:ssa ei ole kuitenkaan vastaavaa ominaisuuden display arvoa (display:inline-block), joka kuvaisi tämän käyttäytymistavan. Tosin tuon voi joissakin tilanteissa (osapuilleen) korvata display:inline-table, mikä ei semanttisessa mielessä ole aivan oikea menettely. Toimii ainakin Opera 4.x+:ssa, mutta ominaisuuden luonteesta johtuen width-ominaisuus ei toimi, joten display: inline-block olisi parempi.

CSS2-spesifikaation puutteiden vuoksi MS IE 6.0 Windows tukee display:inline-block. DTD:llä, jossa selain toimii ns. standard-compliant -moodissa, se on ainoa mahdollisuus luoda tavanomaisille rivinsisäiselementeille dimensiot (esim. <span style="display:inline-block; border:1px solid black; height:50px; width:200px">...</span>) siten, että elementin käytös on korvattavien rivinsisäiselementtien (esim. IMG) kaltainen. Koska muut selaimet eivät toistaiseksi tätä menettelyä tue, sen käyttö ei ole suotavaa. Testielementti.

Sisäkkäisten lohkojen keskittäminen

Kun lohkoelementille laittaa margin:auto, sen tulisi keskittyä vaakatasossa (ei toimi kaikissa CSS:ää ymmärtävissä selaimissa). Ajattelin, että se keskittäisi myös pystytasossa, mikäli lohko on toisen lohkon sisällä, esim.

div.ulompi {width: 150px; height:100px; border: 1px solid black; margin: auto; vertical-align: middle}
div.sisempi {width:100px; height: 50px; border: 1px solid black; background-color: yellow; margin: auto; vertical-align:middle; text-align:center}

Näin ei käykään, mikä on spesifikaation mukaan oikein. Taulukkoriveillä voidaan sisältö keskittää (<tr valign="middle">), mutta vastaava CSS-ominaisuus puuttuu yleisiltä lohkoelementeiltä, sillä vertical-align vaikuttaa vain rivillä olevien elementtien asemointiin samaan tapaan kuin text-align vaakatasossa. Automaattinen sisäkkäisten lohkoelementtien keskittäminen pystytasossa olisi suotava ominaisuus.

Lomakkeet

Se tosiasia, että CSS2:n kirjoittaja eivät ole perusteellisesti pohtineet XML-asiakirjojen esittämistä näkyy erityisesti lomakkeissa. Saadakseen paremman esitystavan lomakkeille, kirjoittaja ovat lisänneet paljon uusia piirteitä CSS3:een (katso viimeinen sivu.

Lisäksi lomakkeissa on pieni ongelma reunojen suhteen (katso sivu Taustat ja reunat , mutta se on todella pieni. Olisi kuitenkin suotavaa, että CSS3 voisi määritellä ensisijaisesti sovellettavan esitystavan lomake-elementeille, vaikka selainten ei olisi pakko sitä seurata.

Kutistetut taulukkoreunukset

Olen keskustellut kutistetuista taulukkoreunuksista (the collapsing border model (CSS2 17.6.2; ominaisuus border-collapse:collapse) joidenkin selainsuunnittelijoiden kanssa.

W3C: CSS2: 17 Tables.

Olen samaa mieltä heidän kanssaan, että malli on liian monimutkainen ja sekava. Erityisesti systeemi, miten ratkaista reunojen konfliktitilanteet on liian monimutkainen. Se on sangen vaikea toteutus selaimille ja sivujen tekijöiden on erittäin vaikea muistaa, miten selaimen tulee toimia yksittäisissä tilanteissa. Olisi hyvä, jos voitaisiin kehittää vaihtoehtoinen yksinkertaisempi malli, joka voisi olla seuraavanlainen:

1. Taulukkosolujen reunukset prosessoidaan porrastetun järjestyksen (cascading order) ja etenevän "maalauksen" (progressive rendering) mukaisesti. Kun selain lukee taulukkoa, se alkaa vasemmasta ylälaidasta ja päätyy oikeanpuoleiseen alalaitaan. Taulukkosolut voisivat saada reunukset tämän mukaisesti.
2. Kaikki säännöt, joita on konfliktitilanteita varten kuvattu kohdassa Border conflict resolution kumotaan lukuun ottamatta sääntöä, jonka mukaan levein reunus saa etusijan.
3. Sivujen laatijalle annettaisiin mahdollisuus antaa jollekin reunukselle korkein prioriteetti ominaisuudella z-index, joka kumoaisi luonnollisen järjestyksen. Jos reunuksilla on sama z-index arvo, porrastettu järjestys ja etenevä maalaus määrittelisivät reunukset.

Mielestäni tämä yksinkertaisempi malli antaa sivujen tekijälle vapauksia. On kuitenkin huomattava, että table-layout:fixed aiheuttaa sen, että selain ei lue koko taulukkoa kun se alkaa maalata sitä. Selaimelle tulisi jättää oikeus hylätä ominaisuudet, jotka tuottavat ongelmia etenevälle maalaukselle (selain ei voi muuttaa taulukon lopussa olevien taulukkosolun leveyttä).

Katselukanava

Koska katselukanava (viewport) on määritelty väljästi CSS2 spesifikaatiossa, selaimilla on erilaisia tulkintoja siitä. Opera ei laske vierityspalkkeja (scrollbars) katselukanavaan, mutta Netscape laskee. Tästä seuraa se, että position:fixed; bottom:0; right:0 on eri asia näissä selaimissa.

Plug-ins -sovellus CSS3:lle?

Koska CSS2:ssa on muutamia vakavia puutteita, kestää pitkän ajan, ennen kuin ne korjataan yleisesti käytetyissä selaimissa. Paras ratkaisu olisi se, että joku tekisi ns. plug-ins -sovelluksen, joka voitaisiin asentaa selaimiin.

CSS3:n tuomat korjaukset

Esitän vielä kootusti mielestäni merkittävimmät korjaukset, joita CSS3 tuo CSS2:n puutteisiin:

1. Kunnollinen lomake-elementtien käsittely.
2. box-sizing, jolloin esim. <TABLE width="100%"> toteuttamiseen, koska CSS2:n mitoitusperiaatteilla ei saa eräissä tilanteissa samaa lopputulosta.
3. display:inline-block, jota voitaisiin käyttää myös IMG elementin kanssa, koska display:inline ei tosiasiassa vastaa elementin IMG käyttäytymistä.