B Mikä merkitys on Web-standardeilla

Aiheet

• Yleistä
• Syyt eri selainten läpikäymiseen
• Joitakin arveluttavia ohjelmointeja
• Terve kilpalu

Yleistä

Koska MS IE on yleisin selain, jotkut ajattelevat, että MS IE on sitten yleinen "standardi". Microsoft IE:n pitäminen "standardina" on virhe. Ei ole mielekästä, että WWW-sivujen tekeminen ja sen opetus perustuu vain yhden selaimen kulloiseenkin versioon, josta tehdään sen hetken mielivaltainen standardi.

Jos web-standardeja ei tunneta, voidaan ihmetellä, miksi jokin sivu toimii hyvin MS IE 5.5 Windows selaimessa, mutta ei Netscape 6.1+:ssa tai Opera 5.x+:ssa. Ensimmäiseksi useimmiten syyttää jälkimmäisiä selaimia. Todellinen syy on useimmiten kuitenkin siinä, että käytetty MS IE ei noudata tarkasti spesifikaatiota, mutta Opera ja Netscape noudattavat niitä kyseisessä tilanteessa tarkemmin.

Jos spesifikaatiot tunnetaan, tiedetään, mikä selain toimii väärin. Kun tämä asia tiedetään, voidaan yrittää ottaa huomioon selainten virheet ja tehdä sivut mahdollisimman hyvin toimiviksi eri selaimissa. Tämän sivuston tarkoituksena on auttaa ymmärtämään HTML, XHTML ja CSS spesifikaatioita.

Microsoft käyttää paljon epästandardeja toteutuksia MS IE -selaimessa ja muissa tuotteissaan. Lisäksi MS IE:ssä on aina otettu käyttöön keskeneräisiä, joskus vain alustavan keskustelun alaisia piirteitä. Esimerkkinä tällaisista on ns. XML-datasaarekkeet (XML data islands; käsittelen sitä eräässä englanninkielisessä HTML-kommentissa). Ne kuten eräät attribuutit (käsittelen niitä sivulla Help for HTML ALL menu) olivat aikoinaan ajateltu liitettävän tuleviin HTML-spesifikaatioihin kuten mahdolliseen HTML 5.0 spesifikaatioon. Em. spesifikaatio ei kuitenkaan koskaan valmistunut, sillä XHTML 1.0 tuli sen tilalle. MS IE 5.x toteuttaa siten eräiltä osin vain kuvitteellisen spesifikaation piirteitä. MS pyrki niiden toteuttamisella muiden selainvalmistajien edelle, mutta niistä tuli lopulta vain MS IE 5.x+:ssa toimivia epästandardeja toteutuksia.

Haluammeko tukea firmaa, joka käyttää paljon epästandardia koodausta, käyttää selain ja käyttöympäristöriippuvaisia komponentteja ja keskeneräisiä spesifikaatioita monopolisoidakseen (ja siten "varastaakseen") internetin itselleen? Epästandardit toteutukset myös tuhoavat niiden selainten mahdollisuuksia näyttää Web-sivut kunnolla, jotka noudattavat tiukemmin virallisia spesifikaatioita. Myös osittaiset ja virheelliset spesifikaatioiden toteutuksen ovat ongelma (tosin CSS2 on vaikea toteuttaa eikä mikään selain toteuta kaikkia CSS2:n visuaalisia piirteitä). Kaikki nämä asiat vahingoittavat internetin alkuperäistä ideaa kaikille avoimesta, käyttöympäristöriippumattomasta ja yhteisiä standardeja noudattavasta verkkoyhteisöstä! Yhteisten standardien noudattaminen luo vakautta ja niiden rikkominen jatkuvaa epävarmuutta ja lisääntyvää kaaosta. Siksi ei ole hyvä, jos yli 90% selaimista on Microsoftin tekemiä.

Netscape on tunnettu selain, mutta versiossa 6.0 on vakavia toimintaongelmia eivätkä ihmiset ole sitä juuri asentaneet. Uusimmat versiot ovat kuitenkin hyviä selaimia. Operan ongelma on edelleen, että sitä ei riittävästi tunneta. Sitä saa lähinnä vain netin kautta eikä moni viitsi vaivautua. Kun monet WWW-sivujen tekijät suunnittelevat sivunsa MS IE:n epästandardeja piirteitä hyödyntäen, Operan käyttäjän saavat väärän kuvan selaimesta (syyttävät selainta tilanteissa, joissa pitäisi syyttää sivujen tekijää).

Operan pääinsinööri on W3C:n entinen työntekijä (Håkon Wium Lie, CSS1-CCS2 spesifikaatioiden pääsuunnittelija), joka todella ymmärtää speksien merkityksen.

On toki sanottava, että myös Opera ja Mozilla Gecko -selaimet tukevat joitakin epästandardeja piirteitä (voit tutkia selainkohtaisia CSS-piirteitä erillissivulta ja HTML-piirteitä eräästä englanninkielisestä taulukosta). Mutta omien kokemusteni perusteella voin sanoa, että AOL/ Netscape/ Mozilla org. ja Opera Software yrittävät luoda selaimia, jotka tukevat olemassa olevia spesifikaatioita tiukemmin kuin MS IE. Jos näitä selaimia käytettäisiin enemmän Microsoft ei voisi käyttäytyä kovin ylimielisesti ja mielivaltaisesti vaan sekin kehittelisi selaimiaan tarkemmin olemassa olevia spesifikaatioita noudattaviksi. Opera Softwaren pyrkimykset perustuvat selkeästi internetin alkuperäisiin pyrkimyksiin:

Why do some Web pages render incorrectly in Opera?

The Opera browser is the strictest supporter of the W3C's technical standards in the browser market today. This is done to ensure interoperability between browsers and hardware manufacturers, meaning that a Web page made in accordance with W3C's recommendations is viewable with whatever browser-application an Internet user chooses. Unfortunately some Webmasters have been lead astray into making their sites specific to one or the other browser's proprietary standards. The result is that some sites effectively shut other browsers out, or their pages may look strange in them.

However, this is a transitional problem. With the advent of the wireless Internet, Webmasters must start complying to W3C standards, tai else their pages will not be accessible to the majority of the Internet population. The two dominant browsers on the PC's are too bloated to fit into small, handheld devices. Why does Opera always emphasize that it follows W3C's standards? Because we at Opera believe in an Internet where everyone can meet, innovate and thrive. For this to happen certain international standards must be followed by everyone. The World Wide Web Consortium (W3C) [www.w3c.org] develops interoperable technologies (specifications, guidelines, software, and tools) that make this possible. We don't want to own tai monopolize the Internet, we prefer an open Net where everyone is granted access and can thrive. For more information on Opera's values, take a look at Opera's Mission.

Tosin Opera tukee jonkin verran MS IE:n epästandardia koodausta, varsinkin Opera 7.0 Beta 1 tukee paljon MS IE:n selainkohtaisia JavaScript-laajennuksia, jotta ei olisi niin paljon sivuja, joihin Operalla ei ole asiaa. Mutta kun Operaa (tai Mozilla Gecko -selaimia, esim. Netscape 7.0) ei haeta, MS saa silti liikaa mellastaa. Tällöin on vaarana, että internetin alkuperäisperiaatteet pistetään maan rakoon - kun yksi firma monopolisoi internetiä ollaan aika kaukana internetin alkuperäisestä ideasta.

Suosittelen lukemaan tästä asiasta myös tämän sivu vastaavan englanninkielisen sivun, joka käsittelee WWW-standardeja vähän eri tavalla kuin tämä sivu eikä se ole tämän sivun käännös.

Syyt eri selainten läpikäymiseen

MS IE:n rinnalla pitää olla mahdollisuus aina opettaa myös muilla selaimilla. Syyt ovat seuraavat:

1. WWW ei ole alun perin ollut eikä se saa olla yhden firman yksityisbisnes vaan kansainvälinen ja avoin verkkoyhteisö. Suomessa oppilaitokset vahvistavat MS:n asemaa kaiken tavoin, vaikka oppilaitosten tehtävä ei ole tukea epätervettä monopoliasemaa.
2. WWW-suunnittelussa pitää antaa sellaisille selaimille mahdollisuus toimia hyvin, jotka pyrkivät noudattamaan yhteisesti sovittuja standardeja. Kaikki www-suunnittelijat eivät varta vasten halua tehdä sivuja väärin toimivan selaimen mukaisesti.
3. Microsoft ei omista WWW:n perusstandardeja. Tässä suhteessa MS IE:n asema on aivan toinen kuin esim. MS Wordin, joka käyttää Microsoftin kehittämää tiedostomuotoa. WWW:n perusstandardeja kehittää W3C (= Word Wide Web Consontium). Lisäksi on eräitä muita standardisointilaitoksia (kuten ECMA: se vastaa standardien skriptikielten kehittämisestä).
4. USA:ssa ja yleisesti maailmalla suhtaudutaan kriittisesti spesifikaatioiden rikkomiseen (Suomessa tuntuu olevan monopolimentaliteetti, koska on totuttu ALKOon jne. – Nokia voi muodostua samanlaiseksi kritiikittömästi suhtauduttavaksi "standardiksi). Mm. Harwardin yliopisto, Webstandards ja Webreviews organisaatiot tutkivat aktiivisesti selainten toteutuksia ja julkaisevat niiden toteutusvirheitä.
5. MS IE -selainten suhde standardien noudattamiseen muuttuu koko ajan. MS IE 5.5 on suhteellisen uusista selaimista eniten spesifikaatioista poikkeava ja niitä virheellisesti toteuttava selain. MS IE 6.0 Windows ja Microsoft IE 5.0 Mac noudattavat CSS2-spesifikaatiota sangen tarkasti toimiessaan ns. standard-compliant -moodissa (käsittelen Windows-versioiden pahimpia virheitä ja korjattuja piirteitä sivulla Taustat ja reunat). MS IE -selainten välillä ja suhteessa toisiin selaimiin on eroja ja tarvitaan aina vertailuselaimia (MS IE eri versioiden vertailu on hankalaa, sillä asennusohjelmat eivät salli useiden versioiden asentamista saman käyttöjärjestelmän alaisuuteen).
6. Jos sivusuunnittelu tehdään kulloinkin yleisimmän selaimen perusteella, seuraavassa versiossa korjatut virheet voivat tuottaa ongelmia. Sivuja joudutaan jatkuvasti muuttamaan selainten virheiden mukaan. Vain spesifikaation mukaan toimiminen takaa pitkällä tähtäyksellä toimivat ratkaisut. Vuosittaisten "standardien" mukaan eläminen on kaiken hiekalle rakentavaa lyhytjänteisyyttä.
7. Microsoft on itse mukana W3C työryhmissä (Working Groups) kehittämässä yhteisiä standardeja – siltä itseltään tulee myös edellyttää niiden noudattamista.

Joitakin arveluttavia ohjelmointeja

WWW:ssä käytetyt viralliset suositellut spesifikaatiot ovat pääosin W3C:n käsialaa (eräitä muitakin standardisointiorganisaatioita on olemassa). Virallisten spesifikaatioiden lisäksi on olemassa standardinomaisia lisäyksiä. Niitä tulisi arvioida WWW:n alkuperäisten periaatteiden mukaan:

1. Lisäysten tulisi olla käyttöympäristöriippumattomia.
2. Niitä pitäisi pystyä käyttämään kaikissa selaimissa.
3. Niissä on huomioitu WWW:n tietoturvaongelmat.

Näin arvioiden Java-sovelmat (Java applets) toteuttavat hyvin pitkälle WWW:n alkuperäisiä päämääriä. Java-sovelmien puolivirallinen asema näkyy myös siinä, että (X)HTML-spesifikaatioissa niitä varten on erityinen elementti (APPLET). Tosin eräisiin selaimiin Java-tuki täytyy hakea lisäohjelmana.

Eräät kaupalliset lisäohjelmat eivät näitä kriteerejä täytä. Se, että jokin piirre kuuluu virallisiin spesifikaatioihin, ei tee sen käyttöä ongelmattomaksi. Jos jokin piirre toimii vain tietyissä selaimissa ja sen tuen puute estää sivujen toimimisen selaimissa, jotka eivät sitä tue, tällaisen piirteen käyttö on ongelmallista.

Listaan muutamia sellaisia koodauksia, jotka ovat arveluttavia tietoturvaseikkojen vuoksi tai sen vuoksi, että ne toimivat vain tietyissä selaimissa:

• Visual Basic, koska sitä ei saa toimimaan kaikissa selaimissa eikä kaikissa käyttöjärjestelmissä. Jos Visual Basic skriptit ajetaan selaimessa automaatisesti se on uhka tietokoneen käyttöjärjestelmälle ja muille Visual Basic skriptejä tukeville ohjelmille. Skriptien vaatija edellyttää pitämään suhteellisen alhaista tietoturvatasoa.
• Muut ActiveX komponenentit:
  • Sitä ei saa toimimaan kaikissa selaimissa eikä kaikissa käyttöjärjestelmissä.
  • Siinä käytetään ohjelmointia, joka ei ole erityisesti suunniteltu internet-käyttöön toisin kuin JavaScript ja Java-sovelmat, joista on pyritty poistamaan tietoturvallisuuden kannalta ongelmallisia piirteitä. Vaikka ActiveX -komponenteissa on autentikointi, ne voidaan helposti rakentaa tuholaisohjelmiksi - toki tällaisten rakentajat on helppo jäljittää.
• DHTML. Sitä on sekä epästandardina että standardina. Myös standardien mukaan tehty DHTML on ongelma, jos sivustoilla navigointi on siitä täysin riippuvainen. Annan sivulla, joka käsittelee epästandardia CSS:ää joitakin moraaliperiaatteita.

Terve kilpailu

Sivujen tekijät voivat suosia joko tervettä tai epätervettä kilpailua. Netin tervettä kehistystä voidaan hidastaa laatimalla sivut vanhimpien selainten ehdoilla. Netin terve kehitys voidaan tuhota suosimalla ratkaisuja, jotka toimivat vain valtaselaimessa, MS IE:ssä.

Microsoft itse on näyttänyt ikävän huonoa esimerkkiä tunnistamalla omalla MSN-sivustollaan Operan ja antamalla sille CSS:n, jonka saa aikaan Opera-selaimissa huonon lopputuloksen. Kyseessä on rikollisluonteinen kilpailijan maineen tahraaminen - MS:n "moraali" muistuttaa virusten suunnittelijoiden moraalia.

Mielestäni ikävämpi piirre on käyttää standardien skriptien sijasta Visual Basic -skriptejä vain siitä syystä, että MSN:n sivusto ei toimisi täysipainoisesti muilla kuin MS IE -selaimilla.

Koska Internetin terve kehitys edellyttää standardeja, terve kilpailu on sellaista, jossa selainvalmistajia patistetaan standardien kehittämiseen ja niiden käyttämiseen reilulla tavalla.

Olen itse laatinut sivustoni erittäin pitkälle standardien mukaan. Sivustoni eivät toimi millään selaimella täysin suunnitellusti. Yksi syy on osoittaa, millaista voisi olla terveen kilpailun edistäminen.

Omalla sivustoillani eräillä Opera ja Netscape 6.1+/ vastaavilla Mozilla -selaimilla vierailevat voivat nauttia kiinteästä navigoinnista ja Opera 4.x+ ja Netscape 6.0+/vastaavilla Mozilla -selaimilla aina miellyttävästä sivun leveydestä. MS IE:llä vierailevat voivat nauttia pikavalikoista.

Kun jokin standardin mukainen ratkaisu ei toimi jossakin selaimessa, se voisi antaa toiselle selainvalmistajalle innoitteen tuotteen kehittämiseen. Kun sivuilla vierailijat näkevät eri lailla toimivia selaimia, he voivat oppia arvostamaan useita eri selaimia. Näin nykyinen Microsoftin monopoliasemaa vahvistava kehitys saisi terveempiä piirteitä.

Sellaisten piirteiden suosiminen, jotka voisivat tulla standardeiksi ja joista ei ole muille selaimille haittaa, voisi jossakin määrin käyttää - itse vierastan niitä. Annan epästandardia CSS:ää käsittelevällä sivulla varteen otettavia "moraaliohjeita". Vaikka sivuston tekijä tuntisi keitä ovat sivuston pääkäyttäjät, hänen tulisi olla tietoinen, että sivut voidaan löytää jonkin hakukoneen avulla. Sivujen tekijä ei voi tietää, mikä selain tai mikä käyttöjärjestelmä vierailijalla on. Sivustot, jotka on ensisijaisesti suunniteltu jollekin selaimelle pitäisi toimia ainakin jollakin tavalla niin monessa selaimessa kuin on järkevästi mahdollista.

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ä.

C Mitä käsitekaavioita ja termipuita CSS:ään liittyy

Aiheet

• Käsitekaaviot:
  • HTML/XML kommenttimerkkaus (comment tag)
  • Elementtimerkkaukset (element tags)
• Termipuut:
  • Tunnisteet (identifiers)
  • Merkintäkoodit (markup codes)

Käsitekaaviot

HTML/XML kommenttimerkkaus (comment tag)

Elementtimerkkaukset (element tags)

Termipuut

Tunnisteet (identifiers)

CSS:ssä on kahdessa merkityksessä tunnisteita. Ensinnäkin selaimen tulee löytää kuvauslohkoille kohde-elementit. Selain tarvitsee suhteessa päädokumenttiin elementti- ja sääntötunnisteita. Näitä voisi kutsua vaikka ulkoisiksi tunnisteiksi. Toiseksi CSS tarvitsee kielen sisäisiä tunnisteita, jotta selain pystyy lukemaan oikein yksittäiset tyylisivut. Selaimen tarvitsee tunnistaa käytetyt ominaisuudet. Se tarvitsee kielen sisäisten sääntöjen ja ominaisuuksien tunnisteita. Varsinaisten termien selitysten lisäksi olen täydentänyt listaa muualla havaitsemieni termien suhteen.

• element identifiers (elementtitunnisteet; ulkoisia tunnisteita):
  • element type names = elementtityyppien nimet (SGML:ssä ja XML:ssä generic identifiers)
  • specified element type identifiers (tarkennetut elementtityyppi tunnisteet):
    • class name = luokan nimi
    • id name = id:n nimi (IDentification = unique identifier)
    • attribute names = attribuuttien nimet
    • attribute names and values = attribuuttien nimet ja arvot
• at-rule names = at-sääntöjen nimet (kielen sisäisiä tunnisteita)
• property identifiers (ominaisuuksien tunnistimet; kielen sisäisiä tunnisteita):
  • property names = ominaisuuksien nimet
  • property keywords and units = ominaisuuksien avainsanat ja mittayksiköt (pituusyksiköt, prosenttiyksiköt, väriarvot, kulmat, ajat ja taajuudet)

W3C: CSS2: 4 CSS2 syntax and basic data types.

Merkintäkoodit (markup codes)

• Kuvaukset ja (kuvaus)ilmoitukset (declarations):
  • Xml-ilmoitus (xml declaration)
  • Dokumenttityypin kuvausilmoitus (document type declaration)
• Elementtimerkkaukset (element tags/ element markup codes):
  • alku- ja päätösmerkkaukset (tarkemmin käsitekaaviossa)
    • rajoittimet (delimiters)
    • elementtityypin tunniste eli elementin nimi (element type identifier/ element name = generic identifier)
• Kommenttimerkkaus (comment tags; tarkemmin käsitekaaviossa)
• Yleisentiteetit (common entities)
• DATA-lohkot (sections):
  • PCDATA
  • CDATA
  • RCDATA

Näiden lisäksi xml-ilmoituksen kaltaista merkintää käyttävät palvelinpuolen skriptit, esim. PHP3 (<?php ... ?>; ASP ja monet muut palvelinpuolen skriptikielet käyttävät sen sijasta <% ... %>).

D Mikä on (X)HTML-elementtien semantiikka

Aiheet

• Yleistä
• Tämän sivuston semantiikka
  • Rivinsisäiselementit
  • Lohkoelementit
• Muut elementit
• Semantiikan tärkeys kuulotyylisivuille

Yleistä

HTML-elementtejä pitäisi käyttää niiden alkuperäisen käyttötarkoituksen mukaan. Esitysasuun vaikuttavien elementtien sijaan pitäisi käyttää elementtejä, joilla on selvä semanttinen merkitys. Tosin jos halutaan tukea Netscape 4.x -sarjan selaimia esitysullisten elementtien käyttö on mielekästä tilanteissa, joissa annettu CSS ei jostakin syystä toimi (olen joutunut käyttämään niitä eräissä navigaatioelementeissä).

Englanninkielisissä teksteissä semanttisista niistä käytetään nimitystä phrasal (phrasal element = fraasielementti, fraasimainen elementti).

Mikä sitten on fraasielementti? Seuraava lohko antaa vastauksen:

Fraasielementti on sellainen tekstielementti, jolla on mahdollisimman mediariippumaton semantiikka. Olennaista elementillä on se, että se kuvaa vakiintunutta ilmaisutapaa eli fraasia. Elementin nimi on sisällöllisesti määritelty eli sisältöriippuvainen (ja sitä tulisi käyttää vain asianmukaisissa sisältöriippuvaisissa tilanteissa). Esimerkkinä tämä lohkositaatti (elementti BLOCKQUOTE), jossa ikään kuin siteeraan itseäni.

Ilmaisun fraasielementti ohella kirjoitan lauseke-elementeistä (phrase =lauseke), sillä elementtien perusolemus on tekstuaalinen, vaikka niiden sisään voidaan sijoittaa tekstin ohella myös grafiikkaa.

Lohkolauseke-elementeillä on aina enemmän tai vähemmän rakenteellinen merkitys, mitä rivinsisäiselementeillä ei ole. Semantiikan tärkeys koskee siten erityisesti rivinsisäiselementtejä. Käytän lähes yksinomaan Inline Phrasal eli rivinsisäisiä fraasielementtejä ja ilmaisen esitysasun CSS:llä ja CSS:n käyttöön liittyvällä elementillä SPAN.

HTML 4.01 ja XHTML 1.0 dokumenteissa jaksoissa, jotka tarvitsevat vain esitysasullisia ohjeita, tulisi käyttää DIV (division > div = jaos; lohkotaso) ja rivinsisäiselementtinä SPAN (span = säätöalue; rivinsisäistaso) elementtejä. Ne ovat yleiselementtejä, jotka on erityisesti suunniteltu esitysasun määrittämiseen CSS:n avulla (niillä on myös eräitä muita yleiskäyttöjä kuten kieliohitukset). Jos jotkin mediatyypit eivät tarvitse niitä, ne voidaan hypätä yli aiheuttamatta mitään harmia dokumenttien semantiikalle. Em. elementtejä voi käyttää mihin tahansa, sillä ne ovat yleiselementtejä, joilla ei ole tarkasti määriteltyä semantiikkaa (CSS:n ohella niitä voi käyttää mm. kieliohituksiin).

Tämän sivuston semantiikka

Koska HTML ei pysty kuvaamaan kaikkea semantiikka, olen käyttänyt lähinnä sopivia elementtejä. Tämän sivuston (sekä vastaavan englanninkielisen sivuston ja niiden Oppaan lisäsivujen) semanttisesti käytettyjen elementtien merkitykset ovat seuraavanlaisia:

Rivinsisäiselementit

• ACRONYM (= akronyymi, kirjainsana): jos jollakin termillä on lyhenne, käytän tätä elementtiä käsitellessäni lyhenteen merkitystä. CSS toimii ainakin MS IE 5.x+, Opera 4.x+ ja Mozilla Gecko (esim. Netscape 6.x+) -selaimissa ja ainakin Opera 5.x+, MS IE 5.5+ ja Netscape 6.x+ -selaimet pystyvät näyttämään elementtiin liitetyn title attribuutin, kun hiiri menee tekstin päälle. Opera 7.x laittaa border-bottom: 1px dotted, jos em. elementille on määritelty title attribuutti (sama koskee elementtiä ABBR). Esimerkki.
• DFN (definition > dfn = määritelmä): käytän tätä lyhennyksen määrittelyssä elementin ACRONYM yhteydessä.
• CODE (= koodi): ilmaisen tällä merkintäkoodeja (lähinnä elementtejä ja attribuutteja) kuten tässäkin listakohdassa.
• SAMP (sample > samp = (koodi)näyte): käytän tätä kaikentyyppisten kommenttien esittämiseen (esim. /* tämä on CSS-kommentti */), sillä ne ovat eräänlaisia (ainakin sivun laatijalle) kirjaimellisesti luettavaa koodausta.
• VAR (variable > var = muuttuja): käytän tätä ns. scripting language -koodauksen eli skriptien esittämiseen. Skriptithän perustuvat muuttujien (variables) käyttämiseen ja tämä elementti symbolisoi minulle koko kieltä (esim. getDocumentElement()).
• CITE (= lainaus): elementin BLOCKQUOTE sisällä käytän sitä sitaattina. Normaalitekstin sisällä käytän sitä myös ikään kuin termin, organisaation, henkilön, jakson or web-osoitteen nimen sitaattina. CITE on lähin käytettävissä oleva elementti ja sopii esim. Inline Phrasal kuvaamiseen varsinkin jos siinä käytetään isoja alkukirjaimia eikä vain pieniä kirjaimia. Käyttö on puhtaasti teknistä, ei esitysasullista.
• EM (emphasized > em = painotteinen): käytän tätä lähinnä osoittamaan korostetun termisitaatin, kun mainitsen tärkeän termin ensimmäistä kertaa (esim. structure).
• Q (quote > q = siteerata): tarkoitettu lyhyisiin sitaatteihin lohkojen sisällä, jolloin käytettäisiin maakohtaisia lainausmerkkejä (selaimen tulisi tehdä tekstin ympärille edes jonkinlaiset lainausmerkit). MS IE 5.x+ tunnistaa elementin, mutta ei lisää lainausmerkkejä. Elementti toimii Opera 4.x+ ja Mozilla Gecko -selaimissa suunnitellulla tavalla. Käytän tätä sanojen merkityksen selittämisessä sekä koodiesimerkkien kommenttiosissa.
  Testi - tämän tekstin tulisi olla punainen ja sen pitäisi olla lainausmerkkien sisällä ja sillä tulisi näkyä opasteksti.
• STRONG (= vahva (ilmaus)): sellainen korostettu teksti, joka ei ole termi.
  Huomautus. Rajanveto sen välillä, mikä on virallinen termi ja mikä termin selitys on suomen kielen kohdalla vaikeaa, sillä yhteisesti sovittua suomenkielistä ATK-sanastoa ei ole olemassa (sellaisia on kyllä tekeillä). Olen korostanut eri lailla selkeästi omat käsitteeni ja suhteellisen viralliset termit. Vastaava englanninkielinen sivusto on tältä osin selkeämpi.
• SUB and SUP (subscript > sub, supscript > sup = alaindeksi ja yläindeksi): käytän niitä vain semanttisesti kuten rivisisäisiä fraasielementtejä (Inline Phrasal), sillä se on niiden alkuperäinen käyttö (katso nootit elementille ABOVE jne.), vaikka Modularization of XHTML™ -dokumentaatiossa ne on luokiteltu Inline Presentational elementteihin. Elementtien luokittelu on ongelmallista, sillä ne ovat jotain esitysasullisten ja lauseke-elementtien väliltä. Niiden sijasta voitaisiin tosin käyttää rivinsisäisiä fraasielementtejä joidenkin semanttisten luokkien kanssa (esim. <var class="superscript">).

Lohkoelementit

• ADDRESS (= osoite): käytän alkuperäistarkoituksessa sivun lopussa oleviin yhteystietojen esittämiseen. Ilmaisen tällä elementillä myös asiakokonaisuuteen liittyvän web-osoite joukon eli tavallaan kyse on muille sivustoille johtavista yhteystiedoista. Esimerkki.
• BLOCKQUOTE (= lohkositaatti): käytän alkuperäistarkoituksessa, kun siteeraan jonkun henkilön tekstiä. Lisäksi näiden sisällä on useimmat pidemmät koodiesimerkit ikään kuin koodisitaatteina (elementti PRE ei aina sovellu niiden esittämiseen).
• PRE (preformatted > pre = esimuotoiltu). Esitän sillä joitakin koodiesimerkkejä tilanteissa, joissa se toimii paremmin kuin elementti BLOCKQUOTE. Elementin semanttinen merkitys on siinä, että koodin väliin jäävällä valkotilalla (white space) on merkitystä (teksti esimuotoillaan kooditasolla ja nimi PRE kuvaa elementin jäsentelyohjetta - se ei täytä fraasielementin ihanteita eikä se siten kuuluisi niiden joukkoon vaan se vaatisi oman luokituksen, mitä W3C ei ole katsonut aiheelliseksi tehdä).
• H1-H5 (heading > h) = otsikko. Sen sijaan että luodaa otsikoita sisäkkäsillä elementeillä (esim. <P><BIG><BIG>...) on paljon järkevämpää käyttää otsikkoelementtejä. Olen käyttänyt niitä systemaattisesti viidellä tasolla (alin taso on H6, jota en ole käyttänyt).
• DL (definition list > dl = määrittelylista). Elementillä DL sekä sen lapsielementeillä (DT ja DD) on vahva sementtinen käyttötarkoitus ja ne muistuttavat täten lohkofraasielementtejä BLOCKQUOTE ja ADDRESS. Käytän niitä joissakin sitaateissa. Käytän myös muita listaelementtejä useimmiten semanttisista syistä.
• P (paragraph > p = kappale). Vaikka elementti P on luokiteltu Modularization of XHTML dokumentaatiossa Block structural, käytän sitä vain tekstikappaleiden esittämiseen. Mielestäni sitä voi verrata elementtiin ADDRESS - sekä elementillä P että ADDRESS on vahva semanttinen merkitys ja molemmat ovat heikkoja rakenne-elementtejä. Kappale on perusfraasi ja BLOCKQUOTE jne. ovat erikoisfraaseja. Käytän CSS-sivuillani elementtiä DIV ensisijaisena rakenne-elementtinä. Suosittelen yleisestikin tätä käytäntöä.

Muut elementit

Joitakin teoriassa mahdollisia semanttisia rivinsisäiselementtejä en ole käyttänyt:

• ABBR (abbreviation > abbr = lyhenne): toimii testaamissani selaimissa vain Opera 4.x:ssä ja Mozilla Gecko -selaimissa (ei toimi edes MS IE 6.0 Windows -selaimessa). Elementin merkitys on suurin piirtein sama kuin ACRONYM.
  Testi - tämän tekstin tulisi olla punainen ja sillä tulisi näkyä opasteksti.
• KBD (keyboard data > kbd = näppäimistödata). Edustaa näppäimistödataa. Pitkään spesifikaatioissa ollut elementti, jolla ei ole minulle kuitenkaan mitään mielekästä käyttökohdetta.

Tarvitsisin lisäelementtejä (esim. NAME tai TERM) edustamaan virallisia nimiä ja termejä. Tiedän, että XML on suunniteltu tuomaan enemmän semantiikkaa Internetiin, sillä HTML ei voi koskaan täyttää kaikkia semanttisia vaatimuksia. HTML-elementtejä täytyy aina käyttää hieman alkuperäistä käyttötarkoitusta laajemmin. Kirjoittaisin mielelläni <term>Inline Phrasal</term>, mutta selainten tulisi käsitellä XHTML:ää kuten XML:ää ja liittää siihen CSS - ehkä tulevaisuudessa on näin mahdollista.

Semantiikkaa voisi ilmaista myös class attribuutilla, mutta se on tarkoitettu ensisijaisesti esitysasun kuvaamiseen. Tämän attribuutin käyttäminen semanttiseen tarkoitukseen ei ole kovin hyvä idea. HTML voisi toimia paremmin seuraavalla tavalla:

• Dokumenttien rakenne ilmaistaaan tietyillä lohkoelementeillä (DIV, TABLE ja listaelementit, esim. OL).
• Lomakkeet ovat suhteellisen yksinkertaisia.
• Kaikkien elementtien esitysasu kuvataan vain CSS:llä.
• Semantiikka ilmaistaan standardeilla lohko- ja rivinsisäisillä fraasielementeillä sekä omilla rivinsisäiselementeillä (omien lohkoelementtien käyttäminen toisi rakenteellisia ongelmia selaimissa, jotka eivät ymmärrä CSS:ää).

Semantiikan tärkeys kuulotyylisivuille

Jotta saat sekä hyvin toimivat visuaaliset että kuuloon perustuvat sivut, on tärkeää, että et käytä väärin elementtejä ja luo keinotekoisia turhan monikerroksisia monimutkaisia rakennelmia, joilla ei ole mielekästä semantiikkaa.

Jotkut suunnittelijat kehottavat käyttämään tyhjiä kappaleita, mikäli on tarvetta lisätä tyhjää tilaa. Minusta tämä käytäntö johtaa huonoon semantiikkaan, sillä tyhjä kappale ei ole semanttisessa mielessä todellinen kappale. Sen sijaan elementti BR merkitsee aina ylimääräistä rivikatkoa. Suosittelen sen tai CSS:n käyttämistä tilanteissa, joissa tarvitaan tyhjää tilaa. On tosin myös huonoa käytäntöä luoda kappaleita käyttämällä peräkkäin kahta BR elementtiä!

Kun puhtaasti visuaalisia esitysasullisia elementtejä (kuten B ja I) ei käytetä, rakenne on selkeä ja sisältö on helppopääsyinen. Olen pyrkinyt käyttämään elementtejä semanttisessa mielessä myös mahdollisia kuulotyylisivuja ajatellen. Olen käyttänyt myös attribuutteja title ja summary antaakseni lyhyen selityksen joistakin linkeistä, kuvista ja taulukoista (summary koskee vain kuuloon perustuvia selaimia, mutta title toimii myös useissa visuaalisissa selaimissa).

Sellaisia perinteellisiä HTML 3.2 elementtejä, joita ei suositella käytettäväksi HTML 4.0 dokumenteissa kutsutaan nimityksellä legacy (legacy = erityisjälkisäädös), esim. elementti FONT ja attribuutti align. Niillä on yleensä vain visuaalinen merkitys ja niitä tulisi käyttää mahdollisimman vähän (Modularization of XHTML dokumentaatiossa Legacy Module sisältää myös joitakin ei-esitysasullisia attribuutteja).

E Millaista epästandardia CSS:ää on olemassa

Yleistä

Epästandardia (engl. siitä käytetään yleensä ilmaisua proprietary) CSS:ää pitää lähestyä seuraavilta näkökulmilta:

1. Millaista epästandardia CSS:ää on olemassa voi olla vain selaimen omaan käyttöön tarkoitettua CSS:ää, jolla määritellään periaatteessa ihan mitä tahansa selaimen käyttämiä oletusmäärityksiä. Kyseessä ovat selaimen tyylisivut UA style sheets (UA CSS, UA = User Agent = asiakassovellus, joka on yleensä selain tai sitten jokin muu ohjelma, joka osaa käyttää tyylisivuja).
2. Erityisesti käyttöliittymän hallintaan tarkoitettu CSS, UI CSS (UI = User Interface). Tämä CSS voi olla joko itse selaimelle, selaimen käyttäjälle tai sivujen tekijän käyttöön tarkoitettua CSS:ää (käsittelen näitä näkökulmia lyhyesti sivulla 5). Sillä ei yleensä ole vaikutusta itse WWW-sivuun vaan se koskee esim. vierityspalkkien (scroll bars), hiiren kursorin jne. esittämistä.
3. Se voi koskea varsinaisten WWW-sivujen esitysasua.
4. Se voi olla sivujen tekijän (author) käyttöön tarkoitettua CSS:ää. Tällainen CSS voi koskea mitä tahansa, niin käyttöliittymää kuin sivujen esitysasuakin.
5. Se voi olla sellaista, joka ei tuota mitään ongelmia selaimille, jotka eivät sitä tue. Se voi myös aiheuttaa vakavia toimintahäiriöitä selaimille, jotka eivät osaa sitä tulkita.

Epästandardin CSS:n käyttöä tulisi välttää yleisillä www-sivuilla. Sitä voi mielestäni hieman käyttää, mutta mielestäni sen käytössä tulisi noudattaa seuraavia "moraalisääntöjä":

• Millaista epästandardia CSS:ää on olemassa ei saisi aiheuttaa minkään tyyppistä haittaa millekään selaimelle, joka ei sitä tue. Tämä on yleinen CSS:n käytön periaate, sillä CSS:ää käyttävät sivut tulisi laatia niin, että asiasisältö on luettavissa myös selaimilla, jotka eivät tue CSS:ää lainkaan. Sivujen toimivuus olisi testattava ainakin MS IE, Netscape/Mozilla ja Opera-selaimissa, mieluimmin mahdollisimman monessa selainversiossa.
• Mikäli selainkohtainen CSS auttaa sisällön lukemista tai se muita selaimia haittaamatta parantaa sivujen ulkoasua, sitä voi varauksin käyttää.
• Epästandardia CSS:ää on suositeltavaa käyttää vain intranet-sovelluksissa, joissa kaikilla on käytössään sama selain.
• Epästandardin CSS:n käytöllä ei tueta epäterveitä monopolisointipyrkimyksiä.

Epästandardin ja standardin CSS:n välimaastossa ovat keskeneräisten CSS3-ehdotelmien tukeminen. W3C kehottaa käyttämään keskeneräisiä ehdotelmia vain testisivuilla. Niidenkin käyttö olisi syytä rajoittua intranet-sovelluksiin. Eniten keskeneräisiä piirteitä on MS IE -selaimissa. Myös Netscape 6.x tukee hieman keskeneräisiä CSS3-ehdotelmia. En tällä sivulla käsittele niitä juuri lainkaan. Laitoin kuitenkin sivun loppuun luettelon selainkohtaisista ja CSS3:een ehdotetuista piirteistä, joita olen huomannut (tai joista olen lukenut) löytyvän MS IE 5.5, Netscape 6.1 ja Opera 5.12 -selaimista.

Huomautus 1. Epästandardin CSS:n haittoja on se, että viralliset CSS2 validaattorit ilmoittavat CSS-tiedoston olevan virheellinen. Jotta tältä harmilta vältyttäisiin, epästandardi CSS kannattaa määritellä erillistiedostoihin. Jollakin skriptillä voisi tehdä toiminnon, jolla se haetaan vain tietyn selaimen käyttöön. Tosin tämä ei lohduta Operan käyttäjiä, jotka voivat valita, minä selaimena Opera esittäytyy. CSS-tiedosto, jossa on epästandardia CSS:ää, voi aina aiheuttaa ongelmia joillekin Operan käyttäjille.

Huomautus 2. Jos tuetaan MS IE -selainten erityispiirteitä, olisi hienoa, jos tuetaan myös uusimpien Netscape/Mozilla ja Opera -selainten tukemia CSS-piirteitä. Ne tukevat sellaisia MS IE:ssä toimimattomia standardeja CSS-piirteitä, jotka tekevät em. selaimilla sivujen selaamisen erittäin miellyttäväksi. Asiallisesti suunniteltuna nämä piirteet eivät aiheuta minkäänlaisia ongelmia selaimille, jotka eivät näitä ominaisuuksia tue. Olen itse tukenut yhtä MS IE:n epästandardia erityispiirrettä ja monia vain Operassa ja uusissa Netscape/Mozilla-selaimissa toimivia standardeja piirteitä. Missään kohdassa en ole pyrkinyt MS IE -selainten toiminnan vaikeuttamiseen (olen kyllä tietoisesti tehnyt sivut niin, että ne eivät toimi optimaalisesti Nestscape 4.x -selaimissa).

UA ja UI CSS

Aiheet

• UA CSS Mozilla Gecko -selaimissa
• UA CSS Opera 4.x+ -selaimissa
• UI CSS

UA CSS Mozilla Gecko -selaimissa

Netscape 4.x:n jälkeen tulevissa selaimissa on paljon UA CSS:ää. Sitä on sekä käyttöliittymän että dokumentin esitysasua koskien. Netscape (ja sen Mozilla jne. nimiset kehittelyversiot) ovat mielestäni ensimmäisiä selaimia, jotka käyttävät UA CSS:ää CSS2 spesifikaation esittämässä käyttötarkoituksessa, nimittäin määrittelemään (X)HTML-elementtien oletusesitysasu. Oletusesitysasu on määritelty /res/html.css, res/forms.css ja /res/quirk.css tiedostoissa (/ = Netscape/Mozilla-selaimen perushakemisto).

Pääosin käytetty CSS on standardia. Ikävä piirre on kuitenkin se, että osa CSS:stä on määritelty avainsanalla !important. Tällöin sivujen tekijä voi joutua ihmettelemään, miksi hänen määrittelemänsä CSS ei toimi. Esim. koodi tiedostosta html.css:


frameset {
display: block ! important;
overflow: hidden;
}
...
iframe {
background-color: transparent ! important; /* (b=49779) */
border: 2px inset;
}


Millaista epästandardia CSS:ää on olemassa on UA CSS -tiedostoissa ihan ok, koska se on selaimen sisäiseen käyttöön, mutta sivujen tekijän toimintojen "kiusaaminen" !important avainsanalla on mielestäni väärin. Ei voi olettaa, että sivujen tekijä tietäisi tajuaisi käyttää samaa avainsanaa kumotakseen UA CSS-tiedostoissa olevan oletusarvon! Tuon piirteen lisäksi Web-suunnittelua hankaloittaa se, että elementti LI on standardia CSS:ää käyttäen määritelty siten, että sen eräiden ominaisuuksien arvot poikkeavat W3C:n suosituksista.

Tosin /res/quirk.css kohdalla tärkeyssäännön käyttö on ok, koska tarkoituksena on emuloida tietyillä DTD:llä Netscape 4.x -sarjan virheellisiä käyttäytymisiä. Tässä tapauksessa on myös oikein käyttää selainkohtaista CSS:ää luomaan standardien vastaisen lopputuloksen.

UA CSS:n olemassaolosta ja sen asiallisesta käytöstä ja muokkaamisesta voisi kaiketi mainita. En ole huomannut siitä mainintaa. Jos joku huomaa, ilmoittakoon asiasta.

UA CSS Opera 4.x+ -selaimissa

Opera 4.x+ ei käytä Netscape/Mozilla tavoin ulkopuolista UA CSS-tiedostoa (X)HTML:n määrittelemiseen. Tosin saamani s-postin mukaan Opera käyttää sisäistä UA CSS -tiedosta, joka ei ole saatavilla ulkopuolisena UA CSS -tiedostona jossakin Operan käyttämässä hakemistossa.

Opera käyttää ulkopuolisia UA CSS -tiedostoja muiden selaimen käyttämien tiedostotyyppien erityistoteutusten kanssa, esim. WML 1.x dokumenttien esittämiseen. Opera tallentaa UI CSS-tiedostot 5.1x versiossa alihakemistoon Styles (Opera 4.x tallentaa ne selaimen juurihakemistoon). WML-dokumenttien kohdalla epästandardin CSS:n tarkoituksena on elementin card esittäminen (position:deck), linkityksen toiminnallisuuden ja kuvien esittämisen toteuttaminen (ominaisuus -replace()). Epästandardin CSS:n käyttö tähän tarkoitukseen on ihan hyväksyttävää.

Olen antanut Opera Software -firmalle kuitenkin siitä moitteita, että se ei www-sivuilla ilmoita, että epästandardi CSS on nimenomaisesti UA CSS:ää. WWW-sivujen mukaan se on CSS:ää, jota - vaikkei se ole firman mukaan suositeltavaa - voidaan käyttää XML-dokumenteissa esim. linkkien saattamiseksi toimimaan (kyse on Opera 5.x -sarjan kohdalla aivan samasta CSS:stä, jota käytetään UI CSS -tiedostossa; Opera 4.x käytti hieman poikkeavaa epästandardia CSS:ää).

Tästä CSS:stä on hyötyä tilanteessa, jossa Netscape 6.x:lle on tehty *.xml dokumentti, joka käyttää XLink linkityskieltä, jota Netscape 6.x tukee mutta Opera ei. Jotta dokumentin linkitys toimisi edes osittain Operassa, CSS-tiedostoon on lisättävä Operan ensisijaisesti UI CSS käyttötarkoituksiin suunniteltua CSS:ää.

Toivottavasti Opera tukee joskus myös XML:n standardeja linkitysperiaatteita, jotta tästä epästandardista käytännöstä voisi tavanomaisissa XML-dokumenteissa päästä kokonaan eroon Näin Operan tukema epästandardi CSS olisi vain ja ainoastaan UA CSS:ää.

Olisi myös reilua, jos Opera Sofware ilmoittaisi, että Opera käyttää kaikkia Web-standardeja koskevilla sivuilla mainittuja CSS-piirteitä UA CSS -tiedostoissa (yksittäisten tiedostojen nimiä ei tarvitsisi mainita). Firma voisi myös mainita, että epästandardia CSS:ää pitäisi lähinnä vain intranet-systeemeissä, joissa Operaa käytetään oletusselaimena.

UI CSS

Kuten aiemmin on tullut esille, Operan ja Netscape/Mozilla-selainten epästandardi CSS ei ole tarkoitettu (ainakaan ensisijaisesti) yleiseen internetkäyttöön. MS IE:lle tehty epästandardi CSS poikkeaa periaatetasolla merkittävästi Netscapen ja Oparan epästandardista CSS:stä, sillä se on tarkoitettu nimenomaisesti WWW-suunnittelijoiden käyttöön, jotta WWW-sivut toimisivat suunnitellusti vain ja ainoastaan MS IE -selaimissa. Tämä periaate on vastoin internetin perusolemusta, sillä se on tarkoitettu yhteisesti sovittuja standardeja käyttäväksi verkkoyhteisöksi.

MS IE:n epästandardi CSS koskee merkittäviltä osin UI CSS:ään eli käyttöliittymään, kuten esim. vierityspalkkien värin määrittämiseen (esim. ominaisuus scrollbar-base-color: #603;). Periaatteessa epästandardi käyttöliittymää koskeva CSS on luonteeltaan sellaista, että se kuuluisi UA CSS:n piiriin, jolloin selaimen käyttäjä voisi määritellä oman selaimensa ulkoasua. Sovelluskohtaisen UI CSS:n käyttö yleisillä www-sivulla on periaatetasolla hieman arveluttavaa. Mutta mitään harmia vierityspalkkien värin määrittelemisellä ei ole muille selaimille. Siksi minäkin olen sitä käyttänyt "linkkikirjoissa" (CSS on erillistiedostossa). Koska CSS2 sisältää UI CSS:ää se, että Microsoft kutsuu näitä laajennuksiksi (extensions), on tässä yhteydessä aivan oikeutettua.

Vaikka selainkohtain UI CSS kuuluu periaatetasolla UI CSS:n piiriin, en vastusta sellaisen UI CSS:n käyttöä, joka ei haittaa toisten selainten toimintaa samoilla WWW-sivuilla. Selainvalmistajat voisivat itse asiassa reilusti kilpailla siitä, kenen UI CSS auttaa sivujen selaajaa sisällön ymmärtämisessä ilman, että sillä tahallisesti haitataan toisten selainten toimintaa samoilla sivuilla.

Operan UA CSS ei sisällä UI CSS piirteitä. Uuden Netscape/Mozilla-selaimen epästandardia UI CSS sisältää joitakin UI CSS piirteitä. Netsape 6.x ei tue ominaisuutta outline, mutta sille on olemassa epästandardeja vastineita. Periaatteessa näitä epästandardia vastineita voisi käyttää yleisillä www-sivuilla, vaikka se ei ole mitenkään suositeltavaa. Koska Netscape/Mozilla ei tästä mahdollisuudesta edes kerro, olisi ehkä epäkorrektia käyttää niitä.

Epästandardin CSS:n harmillisuus

Operan ja Netscape/Mozillan epästandardi CSS on CSS2:n syntaksin mukaista. Ainoastaan se on erilaista, että selainkohtaisten ominaisuuksien ja näennäisluokkavalitsinten nimet saattavat alkaa tavuviivalla (esim. Operassa -replace ja Netscapessa :-moz-dummy-option). Vaikka Operan tai Netscapen selainkohtaista CSS:ää lisäisi standardien CSS2:n joukkoon, se ei aiheuttaisi MS IE:lle syntaksiongelmia, tuskin muullekaan CSS:ää ymmärtävälle sovellukselle. Netscape/Mozilla dokumentin esitysasua koskevan selainkohtaisen CSS:n käyttö aiheuttaa kuitenkin sen, että esim. lomakkeet saa näkymään siinä eri tavalla kuin muissa selaimissa. Kysymys on kuitenkin vain pienistä ulkonäköjutuista, ei vakavista toimintaongelmista. Itse asiassa -moz- etuliitettä käyttävät ominaisuudet eivät ole (tai ainakaan useimmat eivät ole) epästandardeja ominaisuuksia vaan kokeellisia CSS3-toteutuksia. Koska lopullisessa CSS3-spesifikaatiossa ne saatetaan määritellä toisin kuin väliaikaisissa vedoksissa (working drafts) Mozilla Gecko -selaimet eivät tue niitä ilman etuliitettä.

Suuri osa MS IE:n epästandardista CSS:stä ei ole kuitenkaan millään lailla harmillista muille selaimille. Eräs s-postiystäväni näytti kuitenkin esimerkin, miten eräs MS IE:lle tarkoitettu CSS aiheutti Opera 5.x:ssä sen, että selain ei lukenut elementtiä H1 koskevasta CSS:stä edes CSS2:n mukaisia ominaisuuksia. Alla on katkelma s-postin kautta saamaani koodia:

h1 {
font-variant : small-caps;
font-size : 20pt;
...
margin-bottom : 1em;
color : #005a9c;
background : transparent;
/* alla oleva CSS on vain MS IE:lle tarkoitettua */
filter: progid:DXImageTransform.Microsoft.DropShadow (color: '#C0C0C0', offX=3, offY=2); }


Periaatteessa Operan pitäisi pystyä ohittamaan ainakin osan em. vain MS IE 5.5:n lukemasta CSS:stä, sillä selainten tulee jossakin määrin ennakoida tulevat speksit (forward compatible parsing -periaate). Näin Opera osittain pystyy, mutta ei joka suhteessa. Esimerkin tapauksessa on kuitenkin niin paljon CSS2-spesifikaatiosta poikkeavia piirteitä, että Opera Software ei ole osannut varautua niihin kaikkiin. Selvitin, mitä tuossa on CSS2 spesifikaation vastaista ja miksi Opera ei sitä pystynyt käsittelemään. Muutin ensin MS IE:lle tehdyn koodin ensin muotoon filter:progidDXImageTransformMicrosoftDropShadow(color: '#C0C0C0', offX=3, offY=2), jonka Opera osasi ohittaa. Sen jälkeen kokeilin kohta kohdalta muuttaa sitä ja tulos on seuraava:

1. Ensinnäkin filter:progid: on CSS2-speksien pohjalta virheellinen syntaksi, sillä CSS:n mukaan kaksoispiste tulee laittaa välittömästi ominaisuuden jälkeen (välilyöntejä toki saa käyttää) ja ominaisuuden arvo(t) tulee päättää puolipisteeseen. CSS2:n syntaksin mukaan progid pitäisi tulla puolipiste (filter:progid;). Tämä asia ei kuitenkaan sotkenut Operaa ja selain osaa ohittaa tämänkaltaisen CSS2-speksin vastaisen syntaksin. Selaimen tulee varautua, että tulevat spesifikaatiot sisältävät progid:... kaltaisia ominaisuuksien arvoja or että ominaisuudet voivat alistettuja muotoa ominaisuus:aliominaisuus:.
2. Ominaisuuksien arvossa on piste kohdassa DXImageTransform.Microsoft.DropShadow. Tämä on ratkaiseva tekijä. Opera luulee sitä todennäköisesti CSS-säännöksi, jolloin määrityslohko tulisi joko katkaista päätöskaarisululla (}) kohdasta DXImageTransform tai sen jälkeen. Jatko kuuluisi jo uuteen määritys- eli kuvauslohkoon. Kun lohko ei katkeakaan siitä, mistä selain olettaa sen katkeavan, se ei osaa löytää määrityslohkon päätöstä. Seurauksena on sitten se, että Opera ohittaa koko määrityslohkon eikä vain ominaisuutta filter. Tämän kaltaisia ominaisuuksien arvojen syntakseja saatetaan lisätä CSS3:een. Forward-compatible parsing -systeemin perusidea on se, että selain voisi ohittaa ominaisuudet, jotka voisivat mahdollisesti tulla tuleviin spesifikaatioihin. Ominaisuus alkaa CSS2:n mukaisella syntaksilla ominaisuus:arvo. Jos Opera löytää tuntemattoman arvon, mielestäni sen pitäisi yrittää etsiä päättävä koodi, ; tai }. Kun Opera ei löydä määrityslohkon päätöstä, se hylkää koko määrityslohkon. Tavallaan selain toimii kuitenkin aivan oikein. Opera Software ei ole vain varautunut siihen, että missään tulevassa spesifikaatiossa voitaisiin käyttää ominaisuuksien arvossa pisteitä. Operan todennäköinen logiikka kooditasolla on seuraava:

   progid:}
DXImageTransform.Microsoft.DropShadow /* tämän jälkee Opera sitten edellyttäisi uutta jaksoa, joka alkaa kaarisululla ({) */
   tai
   progid:DXImageTransform}
.Microsoft.DropShadow

3. CSS-funktion edellä on välilyönti kohdassa DropShadow (color...). Välilyönti ominaisuuksien arvoissa merkitsee sitä, että yksittäisen ominaisuuden arvo päättyy ja välilyönnin jälkeen oleva arvo on uusi, samaan arvojoukkokokonaisuuteen kuuluva arvo. Selaimen pitäisi CSS2-syntaksin pohjalta ymmärtää DXImageTransform.Microsoft.DropShadow ja (color:...) olevan kaksi saman ominaisuuden arvoa. Tästä ei voi kuitenkaan olla kyse, sillä syntaksi arvo() on CSS2:ssa CSS-funktio, joka tulee ehdottomasti kirjoittaa yhteen. Kaiken järjen mukaan MS IE:n ymmärtämän ominaisuuden arvo pitäisi olla DropShadow(color...). Tämä on ratkaiseva tekijä. Uskon, että CSS3 ei voi sietää tätä, sillä tietokoneohjelmoinnin yleisperiaatteisiin kuuluu, että funktion nimi ja sitä seuraava suluissa oleva arvojoukko pitää kirjoittaa yhteen (CSS2:n ohella tätä periaattetta noudattaa mm. ns. JavaScript-koodaus). Tässä on kyse mitä todennäköisesti MS IE:n "velttoudesta" ja "lempeydestä" syntaksivirheitä kohtaan. Koska Opera ei syntaksivirheen vuoksi osannut päätellä, missä kuvauslohko päättyi, se hylkäsi koko säännön.
4. Toinen ominaisuus on toisen ominaisuuden arvona kohdassa (color: '#C0C0C0', offX=3, offY=2). Tällä ei ole merkitystä ja CSS3:een tulee tämänkaltaisia piirteitä. Näihin Opera ja muiden CSS1-CSS2:ta tukevien selainten pitää pystyä niihin varautumaan.

Kyse on osittain siitä, että Opera tekee virheitä, koska selain ei pysty ohittamaan tuntemattoman ominaisuuden syntaksivirheitä (tämä on korjattu 5.12 versiota uudemmissa selaimissa). Tein englanninkielisen testisivun, joka demonstroi ongelmia 2 ja 3. Mozilla 0.9 pystyy näyttämään oikein kuten myös Opera 6.0 Beta 1 Windows.

Tuon koodin laatija kirjoitti 28.09.2001, että välilyönti kohdassa DropShadow (color...) ja sen kuuluisi olla DropShadow(color...). Saamani s-postin mukaan MS IE 6.0 hyväksyy välilyönnin, mutta se on huono asia, sillä selaimen ei tulisi toteuttaa väärällä syntaksilla laadittua ominaisuutta vaan sen tulisi hyäpätä kyseisen ominaisuuden ohitse seuraavaan hyväksyttävissä olevaan ominaisuuteen or mennä määrityslohkon loppuun. Jos selain hyväksyy syntaksivirheitä, se vaikeuttaa koodin oikeellisuuden tarkistusta.

Näin ollen on periaatteessa mahdollista, että alla oleva koodaus on jonkin CSS3:een tehdyn ehdotelman mukaista:

filter: progid:DXImageTransform.Microsoft.DropShadow(color: '#C0C0C0', offX=3, offY=2)

Tuollaista syntaksia ei ole kuitenkaan ehdotettu missään CSS3-ehdotelmassa. Ainut CSS3-ehdotelma, joka tuntee ominaisuuden filter on SVG (Scalable Vector Graphics). Kyseessä on erityiskieli eikä kyseinen ominaisuus kuulu yleisesti käytettäväksi ehdotettuihin CSS3-ehdotelmiin. SVG:ssä käytetty syntaksi poikkeaa MS IE:n tukemasta syntaksista.

Tosiasiassa on siten kyse ihan epästandardista CSS:stä, vaikka näennäisesti Microsoft antaa WWW-sivuilla kuvan, että MS IE käyttää ominaisuutta filter jonkin CSS3-ehdotelman mukaisesti. Microsoft selittää ominaisuuden filter käyttöä seuraavasti (lisäsin tekstiin hieman korostuksia):

Filters often create effects that can be generated with script. This raises the question, "Why use filters if script can do the job?" There are several reasons for using filters. The most important is because they don't require script. For better tai worse, many HTML authors do not use scripting. Filters are a convenient package for the same functionality that scripting provides. Another benefit of filters is that they are easier to author and can be applied to entire classes of elements, because they use the declarative and inherited syntax of CSS.

Filters and transitions display properly only on systems that have the color palette set to display 256 colors tai more.

Almost any object can have filters applied to it. However, the object that the filter is applied to must have layout before the filter effect will display. Put simply having layout means that an object has a defined height and width. Some objects, like form controls, have layout by default. All other filterable objects gain layout by setting the height tai width property, setting the position property to absolute, tai setting the contentEditable property to true.

MS IE tukee kuitenkin eräitä aivan oikeasti CSS3:een tehtyjä ehdotelmia. Sinänsä on hyvä, että on testataan kokeiluluonteisia sovelluksia - yleiset WWW-sivut vain eivät ole oikea paikka näiden testien tekemiseen! Koska MS IE toteuttaa keskeneräisiä speksejä ja MS suosittaa niiden käyttöä WWW-sivuilla, se rikkoo W3C:n suosituksia keskeneräisten spesifikaatioiden käytöstä.

Löysin eräältä WWW-sivulta myös toisen esimerkin Microsoftin arveluttavista koodauksista:

<style fprolloverstyle>
A:hover {color: red; font-weight: bold}
</style>

Kyseessä on aivan normaali a:hover efekti. Vaikka kyseessä on epästandardi koodaus Opera 5.x ymmärtää sen. Fprolloverstyle-attribuutti on MS:lle tyypillinen täysin tarpeeton epästandardi MS-tuotteiden koodaus. Kyse ei ole jollekin selaimelle tarkoitettu koodaus, sillä informaatio on relavanttia vain sivuteko-ohjelmalle. Tällainen tieto pitäisi olla kuitenkin kommenttien sisällä. Saman asian voisi kuitenkin määritellä täysin standardilla tavalla:

<!-- fprolloverstyle -->
<style type="text/css">
A:hover {color: red; font-weight: bold;}
</style>

Yleensä vain editorille tarkoitettu koodaus (sitä on monissa sivunteko-ohjelmissa, erityisesti Adoben editoreissa) ei ole harmillista. Sivulla, jolla tällaisen attribuutin löysin, Mozilla 0.9 näytti kuitenkin sivun alun väärin. Kyse on todennäköisesti siitä, että uudet Netscape/Mozilla-selaimet toisinaan sekoavat elementtien päätösmerkkauksien kohdasta, sillä fprolloverstyle ei ole HTML 4.01 spesifikaation näkökulmasta asianmukainen attribuuttisyntaksi. Uudet Netscape/Mozilla-selaimet näyttävät edellyttävän, että attribuutit ovat kaksiosaisia eli ovat muotoa attribuutti="arvo" (jotkin vanhat HTML-spesifikaatiot käyttivät yksiosaisia attribuutteja, esim. <DL compact>). Jos em. epästandardi koodaus olisi vaikka <style fpstyle="rolloverstyle">, uudet Netscape/Mozilla-selaimet osaisivat todennäköisesti aina ohittaa epästandardin koodauksen ongelmitta. Tosin kun vierailin sivulla uudestaan, ongelmaa ei ollut. FrontPagen luoman fprolloverstyle kohdalla kyse on todennäköisesti ajattelemattomuudesta kuin tahallisesta kiusanteosta.

Yleisesti ottaen joillekin selaimille mahdollisesti haitallisen koodauksen luomisessa on kyse hallitsevan markkinaosuuden väärinkäytöstä. Kaikkien tiedossa on se tosiasia, että Microsoftin pyrkimykstä on saada täydellinen monopoliasema selainmarkkinoilla. Yhtenä keinona on epästandardien ja keskeneräisten spesifikaatioiden tukeminen. Niiden avulla MS pyrkii harjoittamaan "selainylivaltaterrorismia". Jos keskeneräisen spesifikaation käytöstä on ilmiselvää haittaa toisille selaimille, sitä ei mielestäni pitäisi käyttää internetissä. Tältä näkökulmalta katsottuna haitallisen koodauksen tahallinen laatiminen internetissä käytettäväksi tarkoitetuilla sivuilla on Microsoftin selainylivaltaterrorismin tukemista! Toivon, että jokainen tämän sivun lukija perehtyy laatimiini "moraalisääntöihin".

DTD-kytkimet

Eräällä tavalla selainkohtaisia piirteitä ovat myös ne, joissa spesifikaatioihin kuuluvien ominaisuuksien toteutukset ovat tahallaan spesifikaatioista poikkeavia. Uudet MS IE- ja Netscape/Mozilla- ja Opera-selaimet käyttävät DTD-kytkimiä, jolloin ilman DTD:tä tai tietyillä DTD:llä uudet selaimet toimivat eräissä suhteissa kuten vanhemmat, virheellisemmin toimivat selaimet. Uudemmat selaimet toteuttavat ylipäätänsä paremmin olemassa olevia CSS ja (X)HTML spesifikaatioita ja ne on suunniteltu toimimaan tarkemmin CSS ja (X)HTML spesifikaatioiden mukaan tietyssä moodissa.

Netscape/Mozilla-selaimessa tarkempaa moodia kutsutaan nimellä strict mode/ standard-compliant mode. Sen vastakohtana on quirks mode.

Microsoft kutsuu parempaa moodia nimellä standard-compliant mode, jolloin toinen moodin on vain se moodi, joka on toiminnassa, mikäli standard-compliant -moodia ei ole kytketty päälle. "Kytkinmekanismi" on MS IE 6.0 Windows, MS IE 5.0 Mac, Nescape 6.x/ vastaavissa Mozilla -selaimissa ja Opera 7.x -selaimissa.

Opera 7.5x ja uudemmat Netscape/Mozilla-selaimilla on itse asiassa vielä kolmaskin moodi melkein standandimoodi (the Almost Standards mode).

Kytkimen ehkä merkittävin liittyy width ja height ominaisuuksien laskemiseen MS IE -selaimissa. Windows-versioissa se ei vaikuta taulukoiden leveyden määrittelyyn. MS IE 5.0 Mac DTD-kytkin vaikuttaa myös elementin TABLE width-attribuuttiin. MS IE 5.0 Mac käsittelee standard-compiliant -moodissa em. attribuuttia samaan tapaa kuin vastaavaa ominaisuutta, mikä on HTML:n kannalta virhe (käsittelen tätä asiaa sivulla myös sivulla 10). Mozilla Gecko ja Opera 7.5x kohdalla taulukoiden width-ominaisuuden laskennassa standardimoodi ja melkein standardimoodi eroavat toisistaan.

Kytkin vaikuttaa MS IE:llä myös selainkohtaiseen CSS:ään. MS IE ei esim. hyväksy standard-compliant -moodissa värillisiä vierityspalkkeja. Tästä syystä sivuilla, jotka ovat IFRAME sisällä on DTD-määritys, joka ei kytke standard-compliant -moodia päälle. Muut sivut toimivat uusissa MS IE ja Netscape/Mozilla-selaimissa strict/ standard-compliant -moodin mukaisesti.

Olen havainnut muutia eroavuuksia ja olen lukenut niistä Web-sivuilta. Huomasin, että Nescape/ Mozilla määrittelee epästandardin käytöksen quirk.css avulla ja osa informaatiosta perustuu tähän UA-selaimen (UA) CSS-tiedostoon (näin aiheutettuja ero ei yleensä tarvitse testata). Olen saanut myös joitakin s-posteja. Alla oleva taulukko ei ole täydellinen, mutta se mainitsee joitakin mahdollisia eroja (mutta koska en ole henkilökohtaisesti testannut kaikkia asioita, siinä voi olla virheitä eikä taulukko erottele standardimoodia melkeinstandardimoodista):

	MS IE 6.0 Windows	MS IE 5.0 Mac	Netscape 6.2.1	Opera 7.x
Ensimmäisten BODY ja TD elementtien ylämarginaali on erilainen (elementin TD suhteen myös viimeisen elementin alamarginaalit ovat erilaisia), jos CSS:ää ei ole käytetty.			Kyllä (UA CSS)
width ja height ominaisuudet yleisille lohkoelementeille.	Kyllä	Kyllä
Ominaisuus width TABLE elementille.		Kyllä	(Ehkä)
Ominaisuus width TD ja TH elementeille yhdessä table-layout:fixed kanssa.	Kyllä	Kyllä
Määrittelyn display:inline-block tarve tavanomaisille rivinsisäiselemnteille yhdessä ominaisuuksien width ja height kanssa.	Kyllä
CSS:n määrittäminen elementille HR.			Kyllä (UA CSS)
Erilainen fonttikokojen hallinta otsikkoelementtien (H1 jne.) sisällä.			Kyllä (epäst. UA CSS)
Elementin PRE erilainen rivitys.			Kyllä (epäst. UA CSS)
Listaelementtien oletusesitysasu on erilainen.			Kyllä (UA CSS)
Erilainen näyttötyyppi (display type) MAP-elementille.			Kyllä (UA CSS)
Elementille IMG erilainen marginaali, jos kuvalla on align="left" tai align:right attribuutti.			Yes (UA CSS)
Erilainen prosenttiarvoisten korkeuksien käsittely taulukoissa ja kuvissa.			Kyllä
Erilaisesti käyttäytyvät taustaominaisuudet taulukkoelementeille.			Kyllä (UA CSS)
Useimmat tekstiin liittyvät ominaisuudet eivät periydy/periytyvät TABLE ja CAPTION elementeillä (font-size, font-weight, font-style, font-variant ja elementille TABLEtaulukoille text-align).			Kyllä (ositt. epäst. UA CSS)
Jos taulukoilla on reunustyylit inset tai outset, reunusväri perustuu joko taulukon tai sellaisen "esi-isäelementin" (anchestor) taustaväriin, jolla muu kuin läpinäkyvä väri.			Kyllä (tarvitsee testejä)
Ominaisuus empty-cells oletusarvoisesti piilottaa/ näyttää tyhjät solut.			Kyllä (UA CSS)
Reunuksellisen taulukkosolun reunuksen minimileveys on yksi pikseli.			Kyllä (tarvitsee testejä)
Perustaulukkolaadinta hyväksyy/hylkää ominaisuuden padding.			Kyllä (tarvitsee testejä)
Kelluvat taulukot eivät koskaan siirry/siirtyvät seuraavalle riville, jos ne eivät mahdu toisten kelluvien elementtien kanssa samalle riville (jos ne eivät siiryy toiselle riville, ne kasvattavat sivun leveyttä).			Kyllä (tarvitsee testejä)
Hieman erilainen oletusesitysasu INPUT elementeille.			Kyllä (UA CSS)
Selaimet esittävät font-size:xx-small - font-size:xx-large eri lailla (katso Model8c.html).	Kyllä			Kyllä
CSS-parseri hyväksyy epäkelpoja id- ja luokkavalitsinten nimiä.	Kyllä
CSS-parseri lukee @import vaikka se ei ole tyylisivun alussa.	Kyllä
CSS-parseri hyväksyy värin heksadesimaalivärejä, jotka eivät ala merkillä #.	Kyllä		Kyllä
CSS-parseri tulkitsee yksiköttömän numeron ikään kuin px (Netscape-selaimia koskien tämä ei koske ominaisuutta font-size koska Netscape 4.x toimi spesifikaation mukaan; yleisesti ottaen se ei koske line-height ominaisuutta eikä tilanteita, joissa numeroarvoilla on toinen merkitys).	Kyllä (mutta virheellisesti korjattu)		Kyllä
Selainkohtaisen CSS:n hyväksyminen.	Kyllä

Huomautukset:

1. Mozilla Gecko -selaimissa on myös joitakin HTML-elementtejä ja -attribuutteja koskevia asioita, joihin ei voi CSS:llä vaikuttaa. Olen pyrkinyt listaamaan sellaiset oletusmääritykset, jotka CSS:llä saa samaksi (yleensä se onnistuu standardilla CSS:llä, mutta joissakin tapauksissa voidaan tarvita epästandardia CSS:ää, jota Netscape/Mozilla-selaimet hyödyntävät runsaasti; selaimen CSS-tiedostoissa; Netscape/Mozillassa on periaatteessa mahdollista muuttaa epästandardilla CSS:llä standardin mukainen käytös epästandardiksi).
2. Mozilla org. sivuilla David Baronin mukaan perustaulukkolaadinta käsittelee leveyksiä moodista riippuen jollakin tavoin erilaisesti. Koska en itse havainnut eroja, laitoin tämän asian sulkeisiin. Periaatteessa Netscape/Mozilla ja MS IE 6.0 -selaimilla pitäisi olla elementille TABLE annetulla width ominaisuuden kanssa erilainen käytös standardiin pyrkivässä moodissa toimittaessa.
3. David sanoo myös sen, että Mozilla-selaimet käsittelevät hieman erilaisesti xx-small-xx-small arvoja. En huomannut mitään eroa font-size:xx-small - font-size:xx-large käsittelyssä. En siksi maininnut tätä kohtaa. Vaikutus voi olla eri selainversiossa erilainen ja Netscape 6.2.1:ssa ei ole juuri tätä eroa.
4. Davidin mukaan Netscape/Mozilla-selainten käytöstä tiettyjen lomakekontrollielementtien kanssa voi muuttaa myös JavaScript-koodauksella, mutta olen pyrkinyt listaamaan vain piirteet, joihin pelkkä DTD:n muuttaminen riittää.
5. Olen maininnut joitakin yksityiskohtia sivulla, joka käsittelee MS IE:n ongelmia.
6. Kytkeytymiskohta standardien mukaiseen moodiin on erilainen MS IE ja Netscape/Mozilla-selaimissa. Netscape/Mozilla-selaimissa strict mode alkaa HTML 4.0 Strict or HTML 4.01 Transitional dokumenttityypeistä. MS IE kohdalla standard-compliant mode alkaa HTML 4.0 Transitional dokumenttityypistä, jos URL ("http://www.w3.org/TR/REC-html40/loose.dtd") on annettu. Jos URL ei ole annettu, standard-compliant -moodi alkaa HTML 4.0 Strict dokumenttityypstä.
7. DTD-ilmoituksen täytyy olla aivan sivun alussa ilman, että mitään on sitä ennen. Minulla oli joillakin CSS-sivun sivuilla sitä ennen kommentti, jolloin MS IE ymmärsi XHTML 1.0 Transitional dokumentin siten, että standard-compliant -moodi oli pois päältä.

Erittely

Käsittelen yksilöidysti epästandardia CSS:ää ja CSS3:een ehdotettuja tuettuja piirteitä CSS-taulukoissa ja niiden kommenttisivuilla (Taulukko 1 Taulukko 2 Nootit 1 Nootit 2). Listattujen selainkohtaisten CSS-piirteiden lisäksi eräiden s-postien mukaan Netscape/ Mozilla käyttää paljon enemmän selainkohtaista CSS:ää mutta en listaa sellaista selainkohtaista CSS:ää, jota ei käytetä tiedostoissa (/res/html.css, /res/forms.css ja /res/quirk.css), jotka määrittelevät (X)HTML elementtien esitynasuja.

Alla on luettelo mainitsemistani selainkohtaisista piirteistä sekä CSS3:n lisäyksistä siinä järjestyksessä kuin ne esiintyvät em. sivuilla:

• MS IE 5.5:
  • Selainkohtainen (author) CSS sivulla CSS Notes 2:overflow-x, overflow-x, layout-grid, layout-grid-char, layout-grid-char-spacing, layout-grid-line, layout-grid-mode, layout-grid-type, ruby-align, ruby-overhang, ruby-position, writing-mode, ime-mode, background-position-x, background-position-y, word-wrap, scrollbar-3d-light-color, scrollbar-arrow-color, scrollbar-base-color, scrollbar-face-color, scrollbar-dark-shadow-color, scrollbar-highlight-color, scrollbar-shadow-color, zoom.
  • CSS3 ehdotelmat sivulla CSS Notes 2: layout-grid, layout-grid-char, layout-grid-char-spacing, layout-grid-line, layout-grid-mode, layout-grid-type, ruby-align, ruby-overhang, ruby-position, writing-mode, filter, text-autospace, text-justify, text-kashida-space, text-underline-position, line-break, word-break, behavior.
• Netscape 6.1:
  • Selainkohtainen (UI) CSS sivulla CSS Notes 1 (Netscape 7.0:ssa kaikkien selainkohtaiset piirteiden edessä on etuliite -moz-, esim. :-moz-viewport): :button-content, :fieldset-content, :-moz-display-comboboxcontrol-frame, :-moz-dummy-option, :-moz-dropdown-list, :-moz-focus-inner, :-moz-radio, :-moz-select-scrolled-content, :-moz-singleline-textcontrol-frame, :focused, :-moz-any-link, :first-node, :last-node, :-moz-list-bullet, :-moz-comment, :-moz-pi, :viewport, :viewport-scroll, :canvas, :scrolled-content, :wrapped-frame, :placeholder-frame, :-moz-page, :-moz-page-sequence, :-moz-anonymous-positioned-block [_moz-option-selected], [_moz-rs-heading].
  • Selainkohtainen (UI) CSS sivulla CSS Notes 2: -moz-binding, -moz-border-radius, -moz-box-sizing: border-box, -moz-box-orient, -moz-float-edge: margin-box, -moz-opacity, -moz-outline, -moz-user-focus, -moz-user-select, -moz-initial, text-align:-moz-center, text-align: start, font-family: -moz-fixed;, border-style: -moz-bg-inset, overflow: -moz-scrollbars-vertical + väriarvot invert, -moz-FieldText.
  • CSS3 ehdotelmat sivulla CSS Notes 1: @namespace.
• Opera 5.12:
  • Selainkohtainen (UI) CSS sivulla CSS Notes 2: position:deck, -replace, -set-link-source, -use-link-source, white-space:-pre-wrap.

Lisäksi mainitsen JavaScript-temppuja käsittelevällä sivulla arvon expression käyttöä.

G Mitä JavaScript-temppuja CSS:n kanssa voi käyttää

Aiheet

• Joustava leveyskontrolli MS IE:lle
• Kelluvat elementit ja muita temppuja

Joustava leveyskontrolli MS IE:lle

Kaikissa tilanteissa on mahdoton saada haluttu lopputulos vain CSS:ää käyttäen. Erityisesti Web-sivujen leveyden määrittely ongelmallista. Olisi toki suotavaa, että sivut toimisivat optimaalisesti kaikilla resoluutioilla. Vihaan seuraavan kaltaisia ilmoituksia:

Tämä sivusto toimii parhaiten 1024x768 tai sitä isommilla resoluutioilla.

Uusille Mozilla Gecko ja Opera-selaimille on äärimmäisen helppo luoda joustava leveyskontrolli. Pitää vain luoda dokumentin pääsisältöön liittyvälle elementille jokin luokka ja esim. seuravaankaltainen CSS (tässä tapauksessa sisältö on DIV elementin sisällä).

div.content {margin-left:auto; width:90%; margin-right:auto; max-width:620px}

Tämän CSS:n pitäisi sopia hyvin myös MS IE 6.0 Windows ja MS IE 5.x Mac -selaimille 800x600 tai sitä alemman näyttöresoluution omaavilla näytöillä, jos selaimet toimivat ns. standard-compliant -moodissa (selitän tämän moodin toisella sivulla). Koska MS IE ei tue max-width ominaisuutta tämä CSS ei sovi suurille näytöille (teksti jää ikävän leveäksi).

Tämän asian voi korjata JavaScript koodilla, joka sijoitetaan dokumentin BODY-elementin sisälle, miellään aivan sen alkuun tai viimeistään ennen sisältöelementtiä, johon viitataan. Se tunnistaa BODY-elementin leveyden käyttäen DOM-perustaista standardia metodia document.body.clientWidth. Jos leveysarvo on suurempi kuin 800 pikseliä silloin MS IE saa linkin CSS-tiedostoon (skriptin alussa on selaintunnistusehdot, joiden tarkoituksena on se, että skripti toimisi vain tietyissä MS IE -selaimissa; käsittelen selaintunnistusehtoja eräällä toisella sivulla):

	var nua, IE, OP, Gecko, Mac, ie_pos, IENu, IE6x, IE5x; 
	nua = navigator.userAgent;
	IE = (nua.toUpperCase().indexOf('MSIE')!=-1);  
	OP = (nua.toLowerCase().indexOf('opera')!=-1);
	Gecko = (nua.toLowerCase().indexOf('gecko')!=-1);
	Mac = (nua.toLowerCase().indexOf('mac')!=-1);
	ie_pos = nua.toUpperCase().indexOf('MSIE');
	IEnu = nua.substr((ie_pos+5),3);
	IE6x = (IEnu>=6.0);
	IE5x = (IEnu>=5.0);

if (IE5x && !OP&& !Gecko) {
	
	if (document.body.clientWidth>800) 
	{		
		if (IE6x || Mac)
		{		
		document.write('<lin'+
		'k rel=\"stylesheet\" type=\"text/css\"'+
		'href=\"../Css/basicWidthSetIE6x.css\"'+
		'media="\screen\" />');
		}
	}
}

Huomaa, että MS IE ei laske oikeanpuoleista vierityspalkkia leveysarvoon. Jos haluat asettaa täysikokoiselle MS IE:lle arvot, jotka sopivat 800x600 resoluutioiseen näyttöruutuu, oikea arvo on 780. Esimerkissäni arvo ei ole kriittinen.

Tavallaan lopputulos on hieman epästandardi, sillä LINK elementin tulisi olla HEAD elementin sisällä. Koska elementti tuotetaan JavaScript-koodauksella se jää vain tietokoneen keskusmuistiin eikä sitä tulosteta asiakirjaan, se ei haittaa dokumentin oikeellisuuden tarkistusta (elementin LINK sijasta olisi voitu tulostaa STYLE elementti tai muita HTML-elementtejä, jotka vaikuttavat asiasisällön leveyteen).

Kun selain on suuressa ikkunassa periaatteessa tarvittaisiin vain seuraava lisäys:

div.content {width:620px}

MS IE 6.0 Windows/ 5.x Mac käyttäytyisi kuten Opera ja Mozilla Gecko -selaimet lukuunottamatta tilanteita, joissa sivuilla vierailija muuttaa ikkunan kokoa. MS IE mittaa BODY-elementin leveyden joka sivulla vain kertaalleen. Jos vierailja on tullut esim. 1000 pikselin ikkunalla ja hän muuttaa sen 700 px ikkunakokoon, hän ei saa optimaalista CSS:ää.

Jotta saataisiin optimaalinen CSS, sivu tulisi ladata uudestaan. Jotta turhilta latauskerroilta vältyttäisiin, skriptin tulee testata, onko sivun lataaminen tarpeellista. Skriptiä tulee muuttaa seuraavalla tavalla:

...
function changeCSS()
{
	if (((document.body.clientWidth>800) && (originalwidth<800) 
	&& (originalwidth!=document.body.clientWidth)) 
	|| ((document.body.clientWidth<800) 
	&& (originalwidth>800) && (originalwidth!=document.body.clientWidth)))
	{
	window.location.reload(); 
	}
}	

if (IE5x && !OP&& !Gecko) {
{
	var originalwidth = document.body.clientWidth;
	window.onresize = changeCSS;...

Nyt useimmin käytetyt MS IE -selaimet toimivat melkein yhtä hyvin kuin Opera ja Gecko -selaimet (voit ladata Web-sivustostani koko skriptin). Koska uudelleen lataus on hitaampaa kuin vain uudeellen muotoilu ikkunan koon muuttaminen saattaa aiheuttaa ylimääräisiä latausaikoja. Olen myös huomannut, että MS IE ei aina saa oikeaa CSS:ää (leveyttä on vaihdettu peräperään liian nopeasti).

Edellä esitetty CSS ei sovellu vanhemmille MS IE -selaimille ja MS IE 6.0 Windows -/ MS IE 5.x Mac -selaimille sivuilla, joissa selaimet eivät toimi standard-compliant -moodissa. Jos sisällölle on käytetty padding-left ja padding-right ominaisuuksia leveysarvot ovat aina erilaisia. Sen lisäksi vanhemmat MS IE -selaimet eivät tue oikein margin-auto. Ainakin MS IE 6.0 Windows jos se ei toimi standard-compliant -moodissa ja vanhemmat MS IE Windows -selaimet laskevat erityisesti prosenttiarvoiset leveydet väärin (en ole varma miten MS IE 5.x Mac käyttäytyy). Siksi alkuperäisen CSS:n pitäisi olla erilainen. Seuraava CSS antaa laajemmin toimivan ratkaisun:

div.content {margin-left:5%; margin-right:5%; }
div[class="content"]{margin-left:auto; width:90%; margin-right:auto; max-width:620px} /* Uudet arvot Opera ja Mozilla Gecko -selaimille käyttäen attribuuttivalitsimia, joita MS IE -selaimet eivät tue. */

MS IE 6.x Windows/5.x Mac -selaimille suuressa näytössä ja selainten toimiessa standard-compliant -moodissa voisi olla esim.:

div.content {margin-left:auto; width:620px; margin-right:auto}

Suuressa näytössä MS IE 5.x Windows -selaimille tarkoitettu CSS voisi olla esim. seuraava:

div.content {margin-left:100px; width:650px; margin-right:auto}

Jos tarkoituksena on keskittää sisältö vaakatasossa MS IE 5.x Windows -selaimille, sisällön pitäisi olla DIV elementin sijaan yhden CENTER elementin sisällä (<DIV align="center> ei saa aikaan oikeaa lopputulosta). Tällöin margin-left voisi saada arvon auto. On myös mahdollista tulostuttaa MS IE 5.x:lle JavaScript-koodilla CENTER-elementti DIV-elementin ulkopuolelle. Jos siltä jää puuttumaan päätösmerkkaus (</CENTER>), se ei haittaa selaimen toimintaa.

MS IE 5.x Windows -selaimia ajatellen skriptiin tulisi kohdan if (IE6x || Mac) {...} jälkeen lisätä seuraava koodi:

		else  
		{
		document.write('<lin'+
		'k rel=\"stylesheet\" type=\"text/css\"'+
		'href=\"../Css/basicWidthSetIE5x.css\"'+
		'media="\screen\" /><center>');
		}

Jos haluat soveltaa systeemiä Netscape 4.x -selaimille, käytä window.innerWidth metodia ikkunan leveyden asettamiseen (myös monet Opera-selaimet tukevat tätä metodia eivätkä aiemmin esitettyä DOM-perustaista metodia) ja selaimen tunnistukseen document.layers metodia.

Vaihtoehtona esittämälleni systeemille on monikerroksellisten taulukoiden luonti. Niillä toteuttu joustava leveyskontrolli ei toimi suunnitellusti Netscape 4.x -selaimissa enkä ole testannut toimivuutta Opera ja Mozilla Gecko -selaimissa. Monikerroksellisten taulukoiden käsittely on selaimelle hitaampaa kuin yhden DIV tai CENTER elementin käsittely ja rakenne muuttuu monimutkaiseksi. Tosin etuna on se, että avattua sivua ei tarvitse ladata uudelleen, jos ikkunaleveyttä muutetaan.

Joustavan leveyskontrollin ja muita dynaamisia CSS-määrityksiä voi luoda käyttämällä arvon expression() sisään (DOM-spesifikaatioon) liittyvää JavaScript-komentoja (toimii MS IE 5.0 lähtien). Koska muut selaimet eivät ymmärrä tätä tapaa, suosittelen, että muut selaimet saavat standardilla tavalla CSS:n. Alla esimerkki:

expression(document.body.offsetWidth - 110 + "px");

expression(document.body.offsetWidth - 110 + "px");

Kelluvat elementit ja muita temppuja

Toinen merkittävä puuttuva CSS-piirre MS IE Windows -selaimissa on position:fixed tuki. On mahdollista saada lohkot seuraamaan hiiren liikettä. Tosin JavaScript toimii huonommin kuin position:fixed. Sain Roy Whittlen skripti toimimaan sivuillani MS IE -selaimilla mutta en millään Gecko-selaimella (tosin esimerkkisivulla alareunaan asemoidut elementit katoavat näytöltä Opera-selaimia käytettäessä).

On myös syytä tiedostaa, että MS IE 5.x+ tarvitsee 5-10 kertaa tehokkaamman tietokoneen kuin Opera 7.x, jotta sivut toimisivat suurin piirtein yhtä hyvin. Erityisesti kelluvat valikot vaativat nopean tietokoneen.

MS IE tukee paljon selainkohtaisia temppuja. En suosittele niiden käyttämistä koska täysin selainkohtaiset sivusysteemit eivät kuulu internetin perusideaan. Ne mitä tällä sivulla olen käsitellyt liittyvät olemassa oleviin virallisiin standardeihin.

H Miten olen itse käyttänyt sivuillani CSS:ää

Aiheet

• Yleistä
• Peruskonseptit, säännöt ja valitsimet
• Ominaisuudet

Yleistä

Tämä sivu antaa vastauksia, mitä kannattaa CSS-piirteitä käyttää, joten se tavallaan jatkoa sivulle Usein esitettyjä kysymyksiä. Olen testannut kaikkia visuaalisia CSS2-spesifikaation piirteitä lukuun ottamatta eräitä fontteihin liittyviä ominaisuuksia (mainitsen niistä sivulla 12. Mitä muita erityispiirteitä CSS sisältää).

CSS:ään on jotakin selainkohtaisia epästandardeja laajennuksia. Microsoftin selaimissa ne on suunniteltu yleisesti käytettäviksi, mutta Opera ja Netscape-selaimissa lähinnä selaimen omaan käyttöön. Käyttöliittymää (user interface) koskeva selainkohtainen CSS ei ole haitallista selaimilla, jotka eivät sitä tue. Olen itse käyttänyt sivustoillani joskus ominaisuutta scrollbar-base-color (muuttaa vierityspalkkien värejä), vaikka juuri nyt en käytä varsinaisilla asiasivuilla mitään epästandardia piirrettä (muutamilla mallisivuilla em. ominaisuus on käytössä). Yleisesti ottaen Microsoftin epästandardien piirteiden suosiminen on arveluttavaa firman tuotepolitiikan vuoksi (tutustu WWW-standardeja koskevaan suomenkieliseen ja englanninkieliseen sivuuni).

Jotkut selaimet tukevat myös CSS3:een ehdotettuja piirteitä, joista yhtä olen käyttänyt. Löydät suhteellisen tarkat tiedot tuetuista CSS-piirteistä kahdesta englanninkielisestä taulukosta (CSS-taulukko 1, CSS-taulukko 2) ja niiden kommenttisivuista. Mallisivuista on olemassa oma liitesivu. Eräät mallit ovat XML-dokumentteja. Käsittelen CSS:n liittämistä XML-dokumentteihin eräällä sivulla.

Listaan tällä sivulle sivustoillani nykyisin käyttämäni CSS:n. Taulukoissa ei ole mukana vain demonstrointitarkoituksessa käytetyt piirteet. Koska sivustoni on esimerkkinä CSS:n käytöstä, olen käyttänyt sangen suuren määrän erilaisia CSS-piirteitä - kaupallisilla sivustoilla ei niin paljoa tuskin voi hyödyntää. Olen kuitenkin jättänyt käyttämättä eräitä toimimattomia, huonosti toimivia tai vähän tuettuja piirteitä. Kerron lyhyesti syyn, miksi en jostakin syystä käytä enää tiettyä piirrettä. Joissakin tapauksissa kuvaan myös syyt, miksi suosittelen jonkin piirteen käyttämistä.

Peruskonseptit, säännöt ja valitsimet

Peruskonsepteja on CSS:n liittäminen (X)HTML-dokumentteihin. HTML 4.01 spesifikaation pohjalta peruskonsepteihin kuuluu tavallaan myös käyttäjän tyylisivut, sillä spesifikaatio vahvasti suosittaa niiden tukemista.

CSS:n perusmekanismeja ovat myös erilaiset säännöt ja valitsimet. Osa niistä kuuluu aivan peruskonsepteihin, mutta osa kuuluu enemmänkin CSS:n edistyneisiin piirteisiin.

Ominaisuudet

Standardit CSS2-ominaisuudet (aakkosjärjestyksessä)
background jne.	Käsittelen background ja border ominaisuuksia sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille. Olen hyödyntänyt niitä sekä pikakirjoitteina että yksittäisiä aliominaisuuksia käyttäen.
border jne.
border-collapse	Käsittelen ominaisuutta sivulla 10. Miten CSS annetaan taulukkoelementeille.
bottom	Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
color	Käsittelen ominaisuutta sivuilla sivulla 3. Mitkä ovat CSS:n mittayksiköt, värit ja avainsanat.
content	Ominaisuus on erittäin hyödyllinen tulostuksessa ja Operan "diaesitysmuodossa". Yhdessä :before or :after näennäiselementtien kanssa sillä saa luotua uusilla Opera ja Netscape selaimilla hyödyllistä lisäinformaatiota. Generoin niillä myös automaattisesti ' -merkkejän. Käsittelen ominaisuutta lyhyesti sivulla 9. Miten CSS annetaan listaelementeille.
cursor	Käytän sitä joissakin erityislinkeissä. Käsittelen ominaisuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille.
display	Perusominaisuuksia, jolla kontrolloin eri esitysmuotoja. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
float	Käytän muutamien elementtien asemoimiseen, mutta en perusrakenteissa. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
font-family, font-size, font-style, font-weight	Käsittelen ominaisuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille sekä fonttikokojen osalta sivulla 3. Mitkä ovat CSS:n mittayksiköt, värit ja avainsanat.
height	Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille.
left	Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
line-height	Käsittelen ominaisuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille.
list-style etc.	Käytän aliominaisuuksilla. Käsittelen listojen ominaisuuksia sivulla 9. Miten CSS annetaan listaelementeille.
margin	Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille.
max-width, min-height, min-width	Kontorolloin näillä height ja width ominaisuuksien ohella lohkoelementtien dimensioita. Ne toimivat uusissa Opera ja Netscape-selaimissa. Käsittelen ominaisuuksiasivuilla 8. Miten CSS annetaan elementtien taustoille ja reunoille ja 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
orphans	Se estää ominaisuuden widows ohella Operalla tulostettaessa jonkin verran yksinäisiä rivejä. Omaisuudet kuuluvat ns. sivutettuun mediaan, jota käsittelen sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille.
outline (-moz-outline)	Käytän sitä erityislinkeissä dynaamisten valikoiden alapuolella Mozilla Gecko -selaimille. Ne selaimet tukevat outline ominaisuutta -moz-outline kautta. Se toimii CSS2-spesifikaation mukaan a:hover kanssa, mutta keskusteltuani erään selainkehittelijän kanssa ominaisuus outline ei ole tuettu suoraan, sillä täysi CSS2-toteutus epäonnistui. Tarkoituksenani on vain poistaa selaimen oma ääriviivamäärittely. Päämäärä toimii osittain. Opera 7.x+ tukee outline suoraan ja annan sen lomakekontrollielementeille :focus kanssa. Käsittelen ominaisuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille
overflow	Käytän joissakin taulukoissa taulukkosolun sisällön kontrolliin arvoa hidden. Käsittelen ominaisuutta sivuilla 10. Miten CSS annetaan taulukkoelementeille ja 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
padding	Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille.
page-break-after, page-break-before, page-break-inside	Kontrolloin näillä tulostuksen sivukatkoja sekä "diojen" vaihtamista Operan "diaesitysmuodossa". Viimeisin ominaisuus toimii vain Operan tulostusmediassa. Omaisuudet kuuluvat ns. sivutettuun mediaan, jota käsittelen sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille.
position	Olen käyttänyt kaikkia mahdollisia arvoja. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
quotes	Katso ominaisuuden content kommentit.
right	Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
size	Omaisuus kuuluu ns. sivutettuun mediaan, jota käsittelen sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille.
table-layout	Käsittelen ominaisuutta sivulla 10. Miten CSS annetaan taulukkoelementeille.
text-align, text-decoration, text-indent	Käsittelen ominaisuuksia sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille.
top	Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
vertical-align	Käsittelen ominaisuuksia sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille.
widows	Ks. ominaisuus orphans.
visibility	Käytän tätä ominaisuutta päänavigaatioelementissä piilottamaan jonkun linkin. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
width	Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille.
z-index	Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli.
CSS-piirteet
opacity	Mozilla Gecko -selaimet tukevat sitä kokeellisesti etuliitteellä -moz- (-moz-opacity). Käytän sitä dynaamisten valikoiden "varjoissa".
Epästandardit CSS-ominaisuudet
filter	Käytän sitä eräille MS IE -selaimille dynaamisten valikoiden varjoissa. Kyseessä on Microsoft IE 5.5+ Windows -selainten tukema erikoistehoste. Microsoft ilmoittaa sen tukemisen olevan CSS3-spefikaation toteutusta. Tämä ei kuitenkaan pidä paikkaansa. filter ei ole tarkoitettu graafisten erikoistehosteiden luomiseen tavanomaisille dokumenteille. Se kuuluu SVG-kieleen, jossa sen syntaksi on aivan toisenlainen kuin MS IE:n käyttämä. W3C: Scalable Vector Graphics (SVG) 1.0 Specification (Property Index).

I Miten luoda dynaamisia valikoita

Yleistä

Tämä sivu antaa vihjeitä monitasoisten dynaamisten valikoiden luomiseen. Ulkoasu-jaksossa on myös vihjeitä, joita voi soveltaa myös staattisiin valikoihin.

Miten luoda dynaamisia valikoita toimivat aluksi vain tietyissä Netscape ja MS IE -selaimissaepästandardilla JavaScript-koodauksella, jolle annettiin nimitys DHMTL (Dynamic Hyper Text Markup Language). Tuon ajan jälkeen W3C on standardisoinut mm. dynaamisten muutosten aikaansaavan koodauksen DOM-spesifikaatioissa (Document Object Model). Standardi koodauskieli on nimeltään ECMAScript ja JavaScript on standardia siinä määrin kun se noudattaa ECMAScript-standardeja.

Uusimmat selaimet tukevat DOMia vaihtelevassa määrin. Parhaiten standardit menetelmät on tuettu uusimmissa MS IE, Mozilla Gecko (esim. Netscape 6.1+) ja Opera 7.x+ -selaimissa. Myös Opera 4.x-6.x -selaimissa on kokeellinen DOM-tuki. Käyttämäni JavaScript toimii myös Opera 4.x:ssä, mutta kokemukseni mukaan dynaamisten valikoiden yleistoimivuus on em. selaimissa heikko. Valikot toimivat sangen hyvin Opera 5.x-6.x -selaimissa, mutta kaikki DOM-pohjaiset valikot eivät kuitenkaan toimi Opera 4.x-6.x -selaimissa. Ne tukevat myös joitakin MS IE:n laajennuksia.

Koska on täysin mahdollista luoda dynaamisia valikoita, jotka toimivat ainakin MS IE 4.0+ Windows, MS IE 5.x+ Mac, Netscape 4.x ja Opera 5.x+ selaimissa, keskityn tällä sivulla opastamaan sellaisten valikoiden luomista, jotka toimivat kaikissa em. selaimissa. Valikot saattavat toimia myös vanhemmissa MS IE Mac -selaimissa, mutta minulla ei ole tietoa valikoiden toimivuudesta näissä selaimissa.

Pelkästään Netscape 4.x huomioiva koodi ei toimi Netscape 6.x -selaimissa, sillä Netscape 4.x -selaimet käyttävät dynaamisissa valikoissa epästandardia metodia document.layers(), jota Mozilla Gecko -selaimet eivät tue. Ne eivät ei tue myöskään Netscape 4.x:n tukemia LAYER ja ILAYER elementtejä (sen sijaan niiden kanssa voi käyttää elementtiä IFRAME, jota periaatteessa voisi käyttää dynaamisissa valikoissa, mutta jonka käyttö on sangen ongelmallista). Valikot pitäisi rakentaa käyttäen metodia document.getElementById() (ehkä myös getDocumentElement() olisi joissakin tilanteissa mahdollinen metodi). Netscape-selaimissa toimivien skriptien pitäisi siten sisältää sekä Netscape 4.x että Netscape 6.x -selainten vaatimat metodit.

Dynaamisten valikoiden luomisesta selviää helpoiten eräillä kaupallisilla ohjelmilla. DHTML Menu Builder luo automaattisesti eri selainten tarvitsemat HTML-rakenteet ja CSS:n. Ohjelman vanhemmat versiot luovat epäkelpoa CSS:ää (uudemmat standardien mukaista). Jos CSS ei ole kelvollista, valikot toimivat joissakin selaimissa vain sellaisilla HTML dokumenttityypeillä, joissa selain ei toimi ns. standard(-compliant) -moodissa.

Mikäli tunnet yhtään PHP:tä, olen yrittänyt tehdä eräälle toiselle sivulle mallin, jossa PHP:n avulla valikon päivittäminen on suhteellisen helppoa. Tällä sivulla käsitellyt mallit ovat staattista HTML-koodia.

Tarkoitukseen on saatavissa ilmaisiakin skriptejä. Käyttämäni skripti näyttää olevan alun perin sangen uuden Macromedia Dreamweaverin tuottamaa (saamani s-postin mukaan skriptiä on käytetty versiosta 4.01 lähtien; skripti ei tosin ole sivuillani alkuperäisessä muodossa). Sen pääfunktion (MM_showHideLayers(), versio 3.0) hyödyntämistä opetetaan monilla Web-sivustoilla, esim. TecsOfTheWeb.Com. Vaikka perusskripti on erään kaupallisen sovelluksen tuottamaa, se on vapaasti käytettävissä.

Suomalainen tv-kanava Nelonen käyttää samaa skriptiä yksitasoisissa alivalikoissa. Sivusto käyttää kuitenkin Netscape 4.x -selaimille hitaita Java-appletteja. Antamalla hakusanaksi käyttämäni pääfunktion nimen, netistä löytyy paljon samaa funktiota käyttäviä sivustoja. Toinen esimerkki hyvin Operassa (ja todennäköisesti kaikissa muissakin uusissa selaimissa) toimiva valikko on myös Yomi Median sivustolla (se käyttää eri JavaScript-koodausta, mutta toimintaperiaate on samankaltainen).

Netistä löytyy myös on skriptejä, jotka toimivat Netscape 4.x ja vanhemmissa MS IE -selaimissa, mutta eivät Opera 4.x-6.x ja Mozilla Gecko -selaimissa (Opera 7.x tukee MS IE:n epästandardia DHTML:ää, joten siinä toimii ainakin osa vanhoille MS IE -selaimille toimivista valikoista). Eräät MS Frontpage versiot luovat valikoita, jotka eivät toimi kaikissa DHTML/DOM tukevissa selaimissa. Jotkut skriptit voivat toimia uusissa MS IE ja Netscape -selaimissa, mutta eivät vanhemmissa MS IE ja Netscape -selaimissa. Alla on Web-osoite, jolla opetetaan dynaamisia valikoita, jotka toimivat useimmissa DOM1 tukevissa selaimissa (MS IE 5.x+ Windows, Opera 4.x+ ja sangen uudet Mozilla Gecko -selaimet), mutta eivät vanhemmissa MS IE ja Netscape -selaimissa.

Myös MS IE 5.0 Mac tukee DOM1:tä. Webreview kirjoittaa selaimen tuesta seuraavasti:

A good portion of DOM1 is supported in IE 5 for the Mac (chunks of DOM1 core are missing). However, the DOM support in Mac and Windows IE 5 is not consistent. This code is not cross-platform, and the Macintosh engine, while perhaps better at implementing DOM 1.0, is not consistent with IE 5 for Windows in all areas.

Käyttämäni perusskriptin etu on siinä, että skripti toimii kaikissa selaimissa, jotka ylipäätänsä tukevat dynaamisia valikoita. Siinä on vaihtoehdot joko epästandardin DHTML:n tai standardin DOMin mukaan toimiville selaimille. Tällä sivulla olevat ohjeet perustuvat yhden valmiin skriptin käyttämiseen (siihen ei tarvitse välttämättä koskea lainkaan).

Selaimissa on kuitenkin erilaisia ongelmia, jolloin optimaalista ratkaisua on vaikea saavuttaa. Pääpaino on uusimmissa selaimissa, mikäli kaikkia selaimia tyydyttävää ratkaisua ei löydy. On periaatteessa mahdollista - mutta ison työn takana - luoda käyttämäni skriptin avulla "käsityönä" kauniin näköisiä useimmissa selaimissa toimivia dynaamisia valikoita. Jokainen voi itse päättää, mitä selainta hän aikoo tukea. Vanhimmille DTHML:ää tukeville selaimille saattaa olla mielekkäämpää antaa staattiset valikot. Selvitän erillissivulla, kuinka itse käyttämäni dynaamiset valikot toimivat eri selaimissa.

Mikäli käytetään jotain muuta koodia, dynaamisten muutosten täytyy perustua ominaisuuden visibility arvon vaihtamiseen, sillä Operassa ei toimi ominaisuuden display dynaamiset muutokset. Mikäli käytät jälkimmäistä tapaa, varmista edes se, että Opera saa käyttöönsä edes sen verran linkkejä, että navigoiminen on mahdollista ilman dynaamisia valikoita.

DHTML/DOM-valikot voi periaatteessa korvata joissakin tapauksissa myös käyttämällä dynaamisia näennäisluokkia (:hover, :active ja :focus) ja IFRAME elementtejä. Tein sivuja, joissa on näin luotuja kokeellisia alivalikoita. Testeissäni systeemit toimivat vain MS IE 5.5+ Windows, Netsape 6.1+ (pitäisi toimia myös vastaavissa muissa Mozilla Gecko -selaimissa), mutta eivät millään Operalla (tosin toimii melkein Opera 7.0 Beta 1:ssä). DHTML/DOM:in tavoin IFRAME ei toimi kaikissa selaimissa, minkä vuoksi selaimille olisi annettava mahdollisuus navigoida sivustoa myös ilman IFRAME-tukea. Koska ratkaisun toimivuusaste on heikko, en suosittele sitä kenellekään. Ainoa ratkaisun etu on siinä, että se toimii myös silloin, kun JavaScript-tuki on pois päältä. Pelkän CSS:n avulla voi kuitenkin luoda vain yksitasoisia dynaamisia valikoita kun DHTML/DOM valikot voivat niin monitasoisia kuin kussakin tilanteessa on tarpeellista.

Ongelmatilanteiden ratkaisut

Koska DHTML/DOM1 toimii eri asteisesti selaimissa, mielestäni DHTML/DOM:iin perustuvat valikot tulisi suunnitella siten, että sivut toimivat myös sellaisissa selaimissa, jotka eivät tue DHTML/DOM-skriptejä. Sivujen olisi syytä toimia myös tilanteissa, joissa JavaScript on poissa päältä. Olen havainnut tilanteita, joissa sivujen navigointia ei ole olemassa ilman sopivaa JavaScript-tukea. Syynä tähän on kaksi mahdollisuutta. Joko linkit luodaan "lennosta" JavaSript-koodauksella tai linkkien oletusarvo on se, että ne on piilotettu (nillä on oletuksena joko ominaisuus visibility:hidden or display:none). Pidän kumpaakin edellä mainittua ratkaisua huonona. Linkit saisi näkyviin, jos piilotus toteutettaisiin niin, että sivulle saavuttaessa kaikki valikot piilotetaan BODY-elementille annetun onload-attribuutin avulla. Tässä tapauksessa linkit olivat näkyvillä ilman JavaScript-tukea. Tämä ratkaisu ei kuitenkaan toimi, sillä dynaamisissa valikoissa linkit menevät muun sisällön ja mahdollisesti myös osittain tai kokonaan toistensa päälle.

Mielestäni parempia ratkaisuja ovat seuraavat:

1. Päälinkit toimivat kaikissa selaimissa ja niiden kautta pääsee sivuille, joissa on jatkolinkit. Tässä ratkaisussa dynaamiset valikot ovat vain alivalikkoja. Tässä tapauksessa on epäolennaista luodaanko alivalikkojen linkit JavaScript-koodauksella vai ovatko linkit aina olemassa itse sivulla, mutta JavaScript piilottaa/paljastaa ne tarvittaessa. Sekään ei haittaa, vaikka osa linkeistä olisi piilotettuna, kun JavaScript on pois päältä.

   Selainkohtaisia huomautuksia:

   1. Ei ole mitenkään mahdollista ratkaista kaikkia JavaScript koodaukseen tai servereihin liittyviä ongelmia, mutta jos esitysasu ei ole riippuvainen siitä, onko JavaScript-tuki päällä vai pois päältä sivuilla vierailija ei ihmettele, miksi sivun ulkoasu muuttui äkisti. Tässä mielessä tämä vaihtoehto on järkevin.

2. Valikoihin liittyvät LINK elementit tuotetaan skripteillä. CSS voidaan helposti räätälöidä eri selaimille sopivaksi. Alla on joitakin esimerkkejä mahdollista toteutustavoista:

   <script language="JavaScript" type="text/javascript">
   <!--
   function linkStyle(sStyleFile,sStyleMedia)
   {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
   href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');} /* Koodin lyhentäminen funktion avulla. Jatkossa tiedostonimi ja mediatyyppi annetaan funktion argumentteina. */
   
   if (document.layers)
   {linkStyle("layersNetscape4.css","screen");} /* Ehto Netscape 4.x -selaimille, jotka eivät tue DOM1:tä, mutta tukevat selainkohtaista DHTML:ää. Netscape 4.x -selaimille attribuutille media ei saa antaa yhtä useampaa arvoa (esim. screen,print). */
   
   else { /* CSS muille selaimille. Netscape 4.x -selaimilla on vaikeuksia monimutkaisten ehtolauseiden kanssa. On paras antaa sille yksinkertaisimmat mahdolliset ehdot. */
   if (document.getElementById) /* Tämä testaa tukeeko selain erästä DOM1:een kuuluvaa metodia. Ehto koskee kaikkia sellaisia selaimia, jotka tukevat käytetyssä skriptissä DOM1-jaksoa (Windows-käyttöjärjestelmässä sitä tukevat MS IE 5.0+, Opera 4.x+, Netscape 6.x+ ja vastaavat Mozilla -selaimet). */
   {linkStyle("layers.css","screen,projection");} /* Opera tarvitsee mediatyypin projection. Tulevaisuuden PDA-selaimet voivat tarvita myös handheld. */
   
   else if (document.all)
   {linkStyle("layers.css","screen");} /* Ehto kaikille sellaisille MS IE -selaimille, jotka eivät tue DOM1:tä, mutta tukevat selainkohtaista DHTML:ää. Koska käytetty CSS-tiedosto on sama kuin edellisessä testissä, ehto olisi voitu yhdistää edelliseen testiin käyttämällä muotoa (document.getElementById) || (document.all).*/
   
   else if (!(document.layers) && !(document.all) && !(document.getElementById)) {linkStyle("noLayers.css","screen");} /* Tuntemattomille selaimille, jotka eivät tue selainkohtaista DHTML:ää eivätkä standardia DOM1:tä. Jos ne tukevat CSS:ää, ne saavat staattiset, kerroksettomat linkkitaulukot. Tässä tapauksessa ehdot ovat tarpeettomia, mutta tämä on esimerkki poissulkevien ehtojen käytöstä. */
   
   else {} /* Lohkon päätös. Tämän kohdan voi jättää pois, mutta on hyvä tapa päättää ehdot tällä tavoin. */
   }
   //-->
   </script>

   <script language="JavaScript" type="text/javascript">
   <!--
   /* Tässä mallissa useimmat selaimet on tunnistettu selainkohtaisiin tietoihin perustuen. */
   function linkStyle(sStyleFile,sStyleMedia)
   {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
   href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}
   
   var IE4, OP, Gecko; /* On hyvä käytäntö listata yleismuuttujat. */
   
   IE4 =(((navigator.userAgent.indexOf('MSIE')!=-1) || (navigator.userAgent.indexOf('Internet Explorer')!=-1)) && (navigator.userAgent.indexOf('Mozilla\/4.')!=-1)); /* Koska uudemmat MS IE -selaimet esittäytyvät myös Mozilla/4.0 yhteensopivina tämä tunnistus soveltuu myös uudemmille selaimille. Jotkut MS IE -selaimet käyttävät MSIE asemesta Internet Explorer tunnistusjonoa. */
   OPua = (navigator.userAgent.indexOf('Opera')!=-1); /* Opera-selainten yleistunnistus. */
   op_pos=nua.indexOf('Opera'); /* Hae tietty merkkijono. */
   OPnu=nua.substr((op_pos+6),1);
   OPnu2=nua.substr((op_pos+7),1); /* Ensiksi määritellään, mistä kohtaa numeeristen arvojen laskeminen aloitetaan tietyn merkkijonon jälkeen. Numero 1 kertoo kuinka monia digitaaleja käytetään. Joissakin Opera 5.x+ Symbian OS (EPOC) selaimien esittäytymisjonoissa versionumeron edellä voi olla kirjain v, jolloin tarvitaan muotoa (op_pos+7),1. */
   OP=(OPua && ((OPnu>=4) || (OPnu2>=5))); /* Tunnistus Opera 4.x or uudemmille selaimille. Tässä tapauksessa numeerisia arvoja vertaillaan keskenään edellä olleiden muuttujien (OPnu ja Opnu2) avulla. Opera-selaimiamia voitaisiin tunnistaa myös käyttämällä ((navigator.userAgent.indexOf('Opera 5')!=-1) || (navigator.userAgent.indexOf('Opera\/5')!=-1) || (navigator.userAgent.indexOf('Opera\/v5')!=-1) || (navigator.userAgent.indexOf('Opera v5')!=-1)) kaltaisia tunnistusjonoja. Jos esim. Opera 5.12 (Windows) toimisi esittäytymismoodissa Esittäydy: Opera (engl. Identify as Opera) se antaisi tunnistusjonon Opera/5.12 ja muissa esittäytymismoodeissa se antaisi jonon Opera 5.12. Koska dynaamiset valikot toimivat kunnolla vasta 5.x lähtien Opera 4.x olisi mielekästä jättää huomioimatta. */
   Gecko = (navigator.product == ('Gecko')); /* Kaikille Mozilla Gecko perusteisille selaimille tarkoitettu tunnistus. Voidaan käyttää myös saman tyyppistä tunnistusta kuin edellä MS IE selaimille (navigator.userAgent.indexOf('Gecko')!=-1). */
   
   if (document.layers)
   {linkStyle("layersNetscape4.css","screen");} /* Netscape 4.x -selainten dynaamisten valikoiden CSS. Netscape 4.x -selainten tunnistus luomalla tunnistusjonoa koskeva muuttuja ei toimi. */
   
   else {
   if(IE4||OP)
   {linkStyle("layers.css","screen,projection");} /* Dynaamisten valikoiden CSS MS IE 4.0+ ja Opera 4.x+ -selaimille. */
   
   else if (Gecko)
   {linkStyle("layersGecko.css","screen");} /* Kokonaan oma tai täydennetty dynaamisten valikoiden CSS Netscape 6.x+/Mozilla -selaimille. Oman CSS-tiedoston tarve on hyvin pieni. Mikäli omaa CSS:ää ei tarvita, tunnistaminen on mahdollista yhdistää edelliseen ehtoon kirjoittamalla se muotoon (IE4||OP||Gecko). */
   
   else {}
   //-->
   </script>

   <script language="JavaScript" type="text/javascript">
   <!--
   /* Metodi- ja selaintunnistuksen yhdistelmä. Kun tunnistus perustuu tuettuihin piirteisiin saadaan mahdollisimman laaja tuntemattomien selainten kattavuus. Ainakin ensisijainen tunnistus pitäisi perustua metodien tukemiseen. Vain osa tunnistuksesta tulisi perustua selaimen nimeen tai muihin selainkohtaisiin tietoihin. */
   function linkStyle(sStyleFile,sStyleMedia)
   {document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\
   href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+sStyleMedia+'\"\ \/\>');}
   
   if (document.getElementById){
   
   var OP, Gecko;
   OP =(navigator.userAgent.indexOf('Opera')!=-1);
   Gecko = (navigator.userAgent.indexOf('Gecko')!=-1);
   
   if (OP)
   {...}
   
   else if (Gecko)
   {...}
   
   else
   {...}
   }
   
   else if (document.all)
   {...}
   
   else {}
   //-->
   </script>

   Selainkohtaisia huomautuksia:

   1. Jos on tarpeen tunnistaa MS IE -selaimet tarkemmin kuin edellä olleissa esimerkeissä, se voidaan tehdä esim. käyttämällä (navigator.userAgent.indexOf('MSIE 6')!=-1). Sen sijaan on huono idea tehdä versionumeroon perustuvia tunnistusyrityksiä, esim. navigator.appVersion.indexOf("5.")>=0. Versionumero voi tarkoittaa selaimen oman versionumeron lisäksi vastaavan Mozillan versionumeroa, Windows-käyttöjärjestelmän versionumeroa (esim. Windows NT 5.0) tai selaimen jakelukanavan versionumeroa (esim. AOL 5.0). Mahdollinen tunnistusjono voi olla esim. Mozilla/4.0 (compatible; MSIE 6.0; AOL 7.0; Windows NT 5.0).

   2. Jotkut MS IE -selaimen versiot käyttävät poikkeuksellisia versionumeroiden tunnistusjonoja, esim. MSIE+5.5+. Jos versionumeroa kysytään poikkeukselliset versionumerot saattavat jäädä huomioimatta.

   3. Yksilöinnistä puuttuu MS IE Windows ja Mac -selaimien erittely. Ne voi toteuttaa (navigator.userAgent.indexOf('Mac')!=-1) ja (navigator.userAgent.indexOf('Win')!=-1) ehdot lisäämällä. älä käytä käyttöjärjestelmien täydellisiä nimiä, sillä jotkut selaimet käyttävät esim. tunnistusjonoja Win32 ja Mac_PPC.

   4. Operalla on monta esittäytymismoodia ja ne useimmiten osittain "valehtelevat". Opera on yleensä esittäytymismuodossa Esittäydy: MSIE 5.0 (engl. Identify as MSIE 5.0). Opera saattaa saada huonon CSS:n tai se ei saa CSS:ää ollenkaan ratkaisuissa, jossa kysytään vain selainten nimiä ja versionumeroita riippuen tietenkin siitä, millä tavalla selaimet on tunnistettu. Tavat, joilla olen tunnistuttanut Netscape 4.x ja Netscape 6.x+ -selaimet ovat sellaisia, että ne eivät koske Operaa, vaikka selain teeskentelisi olevansa jokin Netscape-selain. Mikäli tunnistukset ovat sisäkkäisiä ne saattavat hidastaa skriptien käsittelyä.

   5. Operan todellista versionumeroa ei ole mahdollista tunnistaa navigator.appVersion.indexOf('5.')>=0 avulla koska Opera vain palauttaa sen selaimen versionumeron, joka se teeskentelee olevansa.

   6. Vaikka Opera olisi missä tahansa esittäytymismoodissa, ainakin sangen uudet versiot voi kuitenkin aina tunnistuttaa omalla nimellään, mutta tämä tunnistus tulee laittaa ennen muita selainkohtaisia tunnistuksia.

   7. Opera 4.x on herkkä sille, että kenoviivan (\) välilyönti merkitään kenoviivalla ja sen jälkeen on vain yksi välilyönti eikä ylimääräisiä rivikatkoja ole. Pienen virheen vuoksi Opera 4.x ei toteuttanut ensimmäisissä testeissäni JavaScript koodausta. Jos rivikatkot tekevät koodin selvemmäksi, koodi täytyy katenoida esim. seuraavasti:

      document.writeln('\<lin'+
         'k\ rel=\"stylesheet\"\ type=\"text\/css\"\'+
         'href=\"..\/Css\/'+sStyleFile+'\"\ media=\"'+
         sStyleMedia+'\"\ \/\>');
      
      

   8. Erään saamani s-postin mukaan Opera 3.x -selaimille ei voida varmuudella antaa CSS:ää, joka olisi tarkoitettu selaimille, jotka eivät tue selainkohtaista DHTML:ää tai DOM1:tä sillä selain ei aina ilmoittaisi selaimen omaa versionumeroa. En tiedä onko väite tosi. Ainakin Opera 3.62 EPOC ilmoittaa aina selaimen oman versionumeron.

   9. Kännyköiden kohdalla Symbian OS -selaimet käyttävät esittäytymisjonoissaan käyttöjärjestelmästä jonoa EPOC. Sikäli kuin tiedän vain Opera 5.x+ ovat selaimia, jotka tukevat dynaamisia valikoita.

      
      
      Opera for Symbian: General Opera information.

   10. Opera 4.x-5.x -selaimet kärsivät hieman toisessa, kolmannessa ja neljännessä vaihtoehdossa. Ne eivät lue JavaScript koodausta kun käytetään selaimen eteen- ja taaksepäin nuolia (tai muita vastaavia toimintoja). Mikäli vierailija ei valitse joka kerta uutta sivua em. selaimet näyttävät toisessa ja kolmannessa ratkaisussa linkit siten kun muut modernit selaimet näyttävät ne tilanteissa, joissa JavaScript on kytketty pois toiminnasta. Haitta koskee kuitenkin harvoja vierailijoita.

   11. Jos Mozilla Gecko -selaimet halutaan eritellä tarkemmin, suosittelen Build ID eli luontipäivään perustuvia lisätunnistuksia. Ne voidaan liittää esimerkeissäni käyttämiin tunnistuksiin. Esim. (Gecko && (parseInt(navigator.productSub)>=20011018)) koskee Netscape 6.1/ Mozilla 0.9.1 ja sitä uudempia selaimia. Jos haluat voit erottaa Netscape -selaimet Mozilla -selaimista esim. lisäehdolla navigator.vendor == ("Netscape7") ja antaa siten Netscape -selaimille eri päivämäärän kuin Mozilla -selaimille. Periaatteessa erottelun voisi toteuttaa myös tarkennetulla versionumerolla, esim. userAgent.indexOf('Netscape6\/6.1'). Netscapea käsittelevällä sivulla on päivämäärälista ja tunnistusesimerkkejä.

   12. Voit käyttää mallina käyttämääni kommentoitua lähdekoodikatkelmaa. Myös s-postiystäväni sivuilta löytyy lisää tunnistusmalleja.

       
       
       Tech.ratmachines.com: Selaintunnistusskriptejä (tekstitiedosto).

   13. Linux käyttöjärjestelmässä voidaan käyttää Konqueror-selainta. Selain kirjoittaa oletusarvoisesti selaimen nimen ja versionumeron ja se käyttää omaa esityskonetta. Tällöin se voidaan tunnistuttaa omalla nimellään, mutta mukaan on syytä laittaa lisäehto (käyttämieni esimerkkien pohjalta se olisi && !Gecko), sillä Konqueror-selaimen voi määritellä käyttämään Mozilla Gecko esityskonetta. Selaimen käyttäjä voi kuitenkin muuttaa esittäytymismerkkijonoa, joten selainta ei voi täysin luotettavasti tunnistaa.

   14. Kun suunnitellaan tunnistukset tulevaisuuden selaimien kanssa yhteensopiviksi, voi olla mielekästä eliminoida kirjainten "kastin" vaikutus selainten esittäytymisjonoissa. Laittamalla toLowerCase(). or toUpperCase(). ennen indexOf mahdollinen kirjainkoon vaihtelu ei haittaa (esim. toLowerCase().indexOf('win') toimii sekä jonojen Windows että WINDOWS kanssa).

   15. Käsittelen eräällä toisella sivukokonaisuudella PHP:hen perustuvia selaintunnistuksia

3. Kaikki linkit ovat itse sivulla, mutta kerrokset määrittelevät elementit tuotetaan skriptien avulla, jolloin kaikki linkit ovat näkyvissä, jos JavaScript on pois päältä. Alla on esimerkki aloitusmerkkauksista (niille pitää kirjoituttaa pariksi päätösmerkkaukset):

   <script language="JavaScript" type="text/javascript">
<!--
if (document.layers)
{document.writeln('\<lay'+'er\ id=\"Kerros1\"\ class="\pageGroup\"\...\>');}

else {document.writeln('\<di'+'v\ id=\"Kerros1\"\ class="\pageGroup\"\...\>');}
   //-->
   </script>

4. On myös mahdollista luoda kahden edellisen vaihtoehdon yhdistelmä. Tässä ratkaisussa suurin osa CSS:stä voisi olla päätiedostossa mukaan lukien suurin on kerroksiin liittyvästä CSS:stä. Vain pieni osa olisi erityisesti dynaamisille valikoille tarkoitetussa tiedostossa. Vaikka selain ei lukisi dynaamisille valikoille tarkoitettua CSS-tiedostoa, dynaamiset valikot voisivat toimia ainakin jollakin lailla, jos selain vain luo tarpeelliset elementit.

5. Valikossa on selkeällä paikalla linkki erityiselle linkkisivulle, josta löytyy jatkolinkit kaikille välttämättömille sivuille. Valikon ei tarvitse olla välttämättä oletusarvoisesti esillä. Valikon paikalla voi olla yksi linkki, joka vie erityiselle linkkisivulle, joka voi olla esim. suuri linkkitaulukko.

6. Tilanteissa, joissa JavaScript on pois päällä, tulee näkyviin vaihtoehtoinen linkistö. Perus CSS-tiedosto päättyy kohtaan, joka määrittelee dynaamiset linkit piilotettaviksi ja vaihtoehtoiset linkit esitettäviksi. Alla on esimerkki tällaisesta ratkaisusta:

   /* Seuraava CSS on basicScreen.css tiedoston lopussa: */
   #alternativeLinkSet {display:block;} /* Vaihtoehtoisen navigoinnin linkit. */
   #tableAllPages {display:none} /* Dynaamisten valikoiden linkit. */
   
   
   /* Seuraava CSS on layers.css-tiedoston alussa: */
   #tableAllPages {display:block}
#alternativeLinkSet {display:none}

   Selainkohtaisia huomautuksia:

   1. Jos CSS komentaa vaihtamaan ominaisuuksien arvoja paljon CSS:ää on useissa eri tiedostoissa, tilanne kuitenkin "stressaa" selaimia. Huomasin eräässä kokeilussa, jossa selaimen oli tarkoitus saada vaihtoehtoiset linkit tilanteessa, jossa JavaScript-tuki olisi pois päältä, että MS IE 5.0 Windowsilla sivu täytyi ladata uudestaan. Tämä saattoi liittyä CSS:ään (ja/tai servereihin), mutta ei välttämättä, sillä CSS oli osittain JavaScript-riippuvainen. Yksi keino - tosin ei välttämättä toimiva - tämän ongelman välttämiseksi olisi saattanut olla kirjoituttaa CSS skripteillä seuraavan esimerkin tapaisesti myös se, että vaihtoehtoinen linkistö piilotetaan ja dynaaminen linkistö näytetään:

      <script language="JavaScript" type="text/javascript">
<!--
      {document.writeln('\<sty'+'le\ type=\"text\/css\"\>');
      document.writeln('\<'+'!--');
      document.writeln('#alternativeLinkSet\{display:none\}');
      document.writeln('#tableAllPages\{display:block\}');
      document.writeln('--'+'\>');
      document.writeln('\<\/sty'+'le\>');}
      //-->
      </script>

   2. Edellinen ratkaisu ei poista toista ongelmaa, joka liittyy vaihtoehtoisiin linkkeihin. Vaihtoehtoisen linkistön toinen heikkous on siinä, että JavaScript- tuen poissa ollessa Netscape 4.x näyttää sekä vaihtoehtoiset linkit että dynaamisten valikoiden linkit, sillä JavaScript-tuen pois ottaminen kytkee pois päältä myös CSS-tuen. Myös selaimet, jotka eivät tue lainkaan CSS:ää saavat kaksi linkistöä.

Erilaisissa tavoissa antaa erilainen CSS tilanteille, joissa JavaScript tuki on päällä/ pois päältä on joitakin ongelmia, jotka voivat johtua servereistä, JavaScript-koodin käsittelystä tai CSS:n käsittelystä. Jos palvelin joutuu kasaamaan CSS:n monesta palasta, selain ei välttämättä saa sitä riittävän nopeasti, jolloin se saattaa esittää sivun virheellisesti. Jos yhteydet ovat hyvät, CSS:n ei pitäisi aiheuttaa ongelmia.

Käytetty JavaScript-koodaus

Aiheet

• Mallitiedostot
• Funktiot

Mallitiedostot

DHTML/DOM valikoissa JavaScrip-koodaus liittyy HTML ja CSS-koodaukseen. Systeemi tarvitsee toimiakseen yhden JavaScript- ja muutaman CSS-tiedoston sekä ohjauksen dokumentin HEAD-elementin sisään sekä BODY-elementin sisälle ns. tapahtumankäsittelijöihin (event handlers). Seuraavia mallitiedostoja (olen käyttänyt niitä suomen- ja englanninkielisillä CSS-sivuilla) voi käyttää apuna suunniteltaessa dynaamisia valikoita:

• Dynaamisten valikoiden JavaScript-tiedosto ../Menumodels/layers.js.
• Dynaamisten valikoiden CSS-tiedostot:
  • ../Menumodels/basicScreen.css. Dynaamisten valikoiden CSS on tiedoston alussa. Se soveltuu hyvin Opera 5.x+, MS IE 5.0+ ja Netscape 6.x/ vastaaville Mozilla -selaimille mutta ei optimaalisesti MS IE 4.0 Windows -selaimelle.
  • ../Menumodels/layersMozilla4.css. CSS Netscape 4.x -selaimille.
• Dokumentin head-osan koodaus, josta on kaksi mallia (viittaukset linkitettyihin tiedostoihin sekä osa tarvittavasta JavaScript-koodauksesta on näissä tiedostoissa):
  • ../Menumodels/AdviceMetaSu.inc (käytetty suomenkielisillä CSS-sivuilla; olen tehnyt tähän versioon muutamia uusia funktioita)
  • ../Menumodels/AdviceMetaEn.inc (käytetty englanninkielisillä CSS-sivuilla)
• Dynaamisten valikoiden koodi tiedostoina:
  • ../Menumodels/AdviceNavigationSu.inc (käytetty suomenkielisillä CSS-sivuilla; tässä versiossa on lyhyemmät funktiokutsut)
  • ../Menumodels/AdviceNavigationEn.inc (käytetty englanninkielisillä CSS-sivuilla)
• Esimerkkisivut:
  • ../Menumodels/NetscapeSuModel.html (suomenkielinen)
  • ../Menumodels/NetscapeEnModel.html (englanninkielinen)

Yleisiä huomautuksia:

• Nykysin vastaavat tiedostot ovat sivuillani hieman erilaisia. En enää käytä Netscape 4.x -selaimissa toimivia dynaamisia valikoita. Netscape 4.x saa else {} - Netscape 4.x ei tee yhtään mitää! MS IE 4.0 Windows ja MS IE Mac -selaimet, jotka tukevat MS IE:n epästandardia DHTML:ää on tuettu. Koodissa ei ole ajastusfunktioita, sillä ne aiheuttavat monissa selaimissa ongelmia. Jos et kaipaa Netscape 4.x tukea etkä ajastuksia voit ladata seuraavan yksinkertaistetun koodin:

  • http://netti.nic.fi/~tapio1/Navigoinnit/layersSimple.js.

• Jos et halua tukea sellaisia MS IE -selaimia, jotka tukevat vain selainkohtaista DHTML:ää, muuta koodia ja määrittele CSS ehdollisesti siten, että sellaiset MS IE -selaimet, jotka eivät tue DOM1:tä, saavat eri CSS:n. Minimikoodi on seuraava:

  function MM_showHideLayers() {if (document.getElementById)
  { var i,p,v,obj,args=MM_showHideLayers.arguments;
  for (i=0; i<(args.length-2); i+=3)
  {
  v=args[i+2];/* tätä kohtaa ei tule muuttaa muotoon
  i<(args.length-1); i+=2)... v=args[i+1], sillä silloin skripti ei toimi MS IE 5.0 Windows -selaimessa */
  {var Cmenu = document.getElementById(args[i]);
  v=(v=='show')?'visible':(v='hide')?'hidden':v;
  Cmenu.style.visibility = v;
  }
  }
  }
  else {} /* muodollinen päätös, joka ei ole välttämätön */
  }

Funktiot

Dynaamisten valikoiden linkit voivat olla itse sivulla tai ne voidaan tuotattaa JavaScript-koodauksilla or palvelinpuolen systeemeillä. Esimerkkisivuilla linkit ovat taulukoissa. JavaScript, jota olen käyttänyt määrittää vain sen, mitkä valikot paljastetaan/ piilotetaan ja millä tavalla paljastaminen/ piilottaminen tapahtuu.

Dynaamisten valikoiden toimintaidea on hyvin yksinkertainen. Sivun tekijä määritellään lohkoja, jotka toimivat dynaamisina valikkoina. Näille annetaan id-attribuutti, joilla on tapahtumankäsittelijöissä vastaava arvot eli parametrit (käytetään myös nimitystä argumentit). Yleisimmät tapahtumankäsittelijät ovat onmouseover, onmouseout ja onclick - viimeksi mainittu voidaan korvata href="javascript:" tilanteissa, missä ei tarvita tapahtumankäsittelyn ohella tavanomaista linkitystä). Opetan niiden käyttöä. Funktioita, jotka Web-suunnittelijan täytyy tunnistaa dynaamisten valikoiden suunnittelussa on vain kolme:

• Pääfunktio MM_showHideLayers(), jolle annetaan joukko kolmisarjaisia argumenttijoukkoja. Ensimmäinen vastaa id-attribuuttia, esim. MM_showHideLayers('Pages','','show') koskee elementtiä, jolla on id="Pages". Kolmas arvo koskee sitä, että piilotetaanko/paljastetaanko valittu elementti (se saa joko arvon hide tai show). Arvojoukkoja voi olla kuinka paljon tahansa ja jokainen argumentti erotetaan toisistaan '' merkeillä ja pilkuilla, esim. MM_showHideLayers('indexPages','','hide','allSites','','hide','Pages','','show');. Suosittelen, että käytät vain tätä funktiota.

• Ajastusfunktiot, esim. piilota_valikot_hitaimmin('MainPages'), joilla kontrolloidaan sitä, miten pitkäksi aikaa valikko jää näkyviin, kun hiiri poistuu aktiivisen linkin tai alueen päältä. Funktiosta on useita versioita. Olen muuttanut funktioiden nimet haluamakseni (jos muutat ajastusarvoja tai funktioiden nimiä suosittelen, ettet muilta osin koske JavaScript-tiedostoon).

• Apufunktio ajastin_pois(), jota käytetään ensiksi mainitsemani funktion yhteydessä ottamaan pois päältä ajastusfunktiot (mikäli linkille tai alueelle ei ole annettu missään olosuhteissa ajastusta tätä funktiota ei tarvita).

Ajastetut valikot

Sivujen tekijä sitten vain päättää, mitkä valikot toimivat milläkin tavoin. Alla on hieman editoitu kuvakaappaus englanninkielisestä esimerkkisivusta:

Valikossa on ajastinfunktioita ja se käyttää seuraavaa systeemiä (mukana on lyhenneltyjä koodiesimerkkejä):

1. Päävalikosta siirrytään toiselle tasolle joko liikuttamalla hiirtä oikealle (mikäli linkkiä tulisi vahingossa klikattua, siirrytään toiselta tasolta valitun sivuryhmän ensimmäiselle sivulle) tai klikkaamalla nuolissa () olevia linkkejä. Jonkun alivalikon valitseminen sulkee avoimet toisen tason valikot:

   <a href="index2.php3#Full" onmouseover="ajastin_pois(); MM_showHideLayers('indexPages','','hide','allSites','','hide','Generic','','show',...);" title="">Generic</a>
   tai
   <a href="javascript:ajastin_pois(); MM_showHideLayers('indexPages','','hide','allSites','','hide',...);" title="..."> <img src="..." title="..." alt="..."/></a>

2. Toisella tasolla valikosta poistuminen sulkee valikon hetken päästä ajastettuna. Toiselta tasolta siirrytään kolmannelle tasolle samalla periaatteella kuin ensimmäiseltä tasolta toiselle. Alla toisen valikon esillä pitävät ja sen sulkevat komennot:

   <div id="Generic" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Generic','','show');" onmouseout="piilota_valikot_hitaasti('Generic');">

3. Kolmannen tason valikko pitää toisen tason valikon avoimena. Kolmannen tason valikko voi sulkeua nopeasti kun valikosta itsestään poistutaan:

   <div id="Generic1" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Generic','','show','Generic1','','show');" onmouseout="MM_showHideLayers('Generic','','show'); piilota_valikot_nopeimmin('Generic1');">

Edellä esitetyllä ratkaisulla on sangen paljon yleisiä ja selainkohtaisia JavaScript-koodaukseen liittyviä ongelmia

Yleisiä huomautuksia:

1. Säilytinelementille annetuilla komennoilla on suurempi painoarvo kuin linkeille annetuilla komennoilla - säilytinelementin sisällä olevat linkit eivät voi muuttaa säilytinelementin määrittämiä show/ hide komentoja, jos komennot koskevat samoja elementtejä.

2. Edellä esitetyn ratkaisun yleinen ongelma on tietyissä tilanteissa kolmannen tason valikon sulkeminen tilanteissa, joissa vierailija siirtää hiirtä vasemmalle, jolloin hän ei käy lainkaan itse kolmannen tason valikossa.

   
   
   

   Jos vasemmalla ei ole mitään linkkiä, kolmannen tason valikko voi jäädä avoimeksi siihen asti kunnes vierailija siirtyy päävalikkoon. Siksi ajaksi kolmannen tason valikko jää näyttöruudulle "orvoksi". Tämän ongelman voi osittain ratkaista siten, että laittaa kolmannen tason linkin valikon avaavan linkin vasemmalle puolelle läpinäkyvän kuvalinkin tai muutaman kiinteän välilyönnin ( ), joka (yleensä) sulkee avoinna olevan kolmannen tason valikon. Alla on esimerkki kuvitteellisesta täytekuvasta (ns. spacer-kuva, joka on yleensä läpinäkyvä GIF-kuva):

   <a class="filling" href="#" onmouseover="ajastin_pois(); MM_showHideLayers('AppendixesStandards','','hide');"> <img src="../Kuvat/Css/spacer.gif" width="11" height="15" /></a>

   Tällaiset temput ovat mielestäni ärsyttävän keinotekoisia. Ongelmaksi jää se, että nopeat hiiren liikkeet vasemmalle saattavat jättää kolmannen tason valikoita näkyviin, koska aktiiviset alueet ovat pieniä. Selain ei yksinkertaisesti ehdi reagoimaan tapahtumiin.

3. Ylimääräinen aktiivinen täytekuva tarvitaan myös tilanteissa, joissa valikon alimmaisin linkki avaa alivalikon. Tässä tapauksessa alapuolella oleva piilolinkki sulkee viimeksi avatun alivalikon.

4. Jos funktiokutsut muodostuvat kovin pitkiksi ylläpitää, niitä voi koota uusiin funktioihin, esim. (tämä on suomenkielisessä mallisivussa):

   function hideThlMenus() /* Piilota kaikki kolmannen tason valikot. */
   {ajastin_pois(); MM_showHideLayers('GenericPreface','','hide',...);}

5. Olen havainnut selainten hitauden yleiseksi ongelmaksi. Laitoin siksi päävalikkoon muutamia sellaisia sulkemiskomentoja, joiden käyttö periaatteessa riittäisi toisen tason valikoissa.

Ei-ajastetut valikot

On kaiketinkin tullut ilmeiseksi, että edellä olleen esimerkin ajastinfunktiota käyttävässä "ratkaisussa" on mielestäni aivan liian paljon selaimen vakauteen ja sekä valikoiden sulkemiseen liittyviä ongelmia. Niistä voidaan päästä toisenlaisella suunnittelulla. Seuraavat ratkaisut toimivat paremmin:

1. Valikoilla on erityinen sulkemislinkki.

2. Valikot suljetaan tarvittaville sivustoille piilotettujen linkkien avulla.

3. Valikoiden sulkeminen tapahtuu silloin kun sivulla vierailija siirtyy asiasisältöön (dynaamiset valikot eivät saa olla tässä ratkaisussa varsinaisen sisällön keskellä). Sulkemisfunktioille ei tule laittaa ole ajastinta, sillä Opera 5.x-6.x toimivat hyvin vain jos ajastinta ei käytetä. Selaimilla saattaa ilmetä pientä viivettä ennen kuin ne sulkevat avoinna olevat valikot. Kyseessä on kuitenkin sangen harmiton viive, sillä selaimet aina sulkevat valikot kun vierailija liikuttaa hiirtä.

Edellisen listan kaksi ensimmäistä kohtaa ovat kuitenkin tarpeettomia. Useimmille selaimille luotettavimmin toimiva ratkaisu seuraavanlainen:

• Alivalikossa itsessään ei ole koskaan onmouseover, onmousemove tai onmouseout attribuuteilla toteutettuja sulkemiskomentoja.

• Alivalikot suljetaan onmouseover attribuutin avulla ilman viivettä päävalikosta tai edellisen tason valikosta käsin, mikäli edellisen tason valikko on olemassa.

• Sisältöön siirtyminen sulkee automaattisesti kaikki avoimet alivalikot onmouseover ja/tai onmousemove attribuuttien avulla.

• Sisällöstä käsin sulkemisen rinnalla tai sen vaihtoehtona on se, että valikon taakse avataan aktiivinen taustalaatikko, joka sulkee avoimet valikot. Taustalaatikossa voidaan käyttää myös onmouseout tapahtumankäsittelijää, jolloin valikko on auki niin kauan kuin ollaan taustalaatikon sisällä. Jos taustalaatikolla on onmousedown sisällöllä voisi olla onmouseover attribuutti (tavanomaiset tietokoneohjelmat sulkevat avoimet alivalikot mousedown-tapahtumalla). Kaikilla valikkotasoilla voi yksittäisille valikoille määritellä "varjolaatikoita", jotka seuraavat avautuvia valikoita.

  Tein kaksi hieman editoitua kuvakaappausta. Alla on ylempänä kuvakaappaus, jossa koko valikko käyttää yhtä vihreää taustalaatikkoa (alivalikoilla ei ole varjolaatikoita). Alemmassa kuvakaappauksessa on lisäksi alivalikoilla varjolaatikot. Monet selaimet toimivat taustalaatikon avulla luotettavammin kuin sisällön kautta sulkemisten avulla ja siten sen käyttö on suositeltavaa. Jos valikoissa on paljon "pullonkauloja", myös varjolaatikoiden käyttö on suositeltavaa (valikkokohtien Ohjesivut ja FAQ välillä on pullonkaula). Minulla on mallisivu, jossa koko valikolle on kaksi taustalaatikkoa. Toisessa mallisivussa jokaisella alivalikolla on omat varjolaatikot.

Jos tarkoituksena on että valikot sulkeutuvat automaattisesti onmouseover-attribuutin avulla nämä ovat ainoat mahdolliset tavat, joilla dynaamiset valikot toimivat mahdollisimman luotettavasti MS IE 5.x+ (Mac ja Windows), Opera 5.x+ ja Mozilla Gecko -selaimissa. Erityisesti ratkaisuni parantaa dynaamisten valikoiden toimivuutta Opera 5.x-6.x -selaimissa monitasoisia alivalikoita käytettäessä. Painotan kuitenkin, että kaikkien em. selainten kohdalla on todettava, että valikot toimivat niissäkin mahdollisimman virheettömästi. Myös MS IE:n käyttäjät voivat olla täysin tyytyväisiä ratkaisuuni. Mielestäni (vähintään) kolmitasoinen valikkosysteemi toimii hyvin vain, jos se täyttää seuraavat vaatimukset (valikkosysteemini täyttää kaikki nämä vaatimukset ainakin jollakin variaatiolla):

1. Alivalikot toimivat absoluuttisen vakaasti kaikissa tilanteissa. Esim. kun kolmannen tason valikko on auki, sen "emovalikkona" (valikko, joka avaa seuraavan tason valikon) toimiva toisen tason valikko pysyy luotettavasti avoinna.

2. Alivalikot eivät koskaan sulkeudu ennalta arvaamattomasti (lasken kaikki tilanteet, joissa valikko sulkeutuu, kun valikoissa vierailija on valikkolohkon sisällä ovat ennalta arvaamattomiksi tilanteiksi esim. tilanteen jossa vierailija selaa linkkejä ja valikko häviää alta).

3. Alivalikot eivät koskaan sulkeudu ennen kuin vierailija on ohittanut koko valikkolohkon.

4. Vierailtu alivalikko sulkeutuu kun vierailija siirtyy pois koko valikkolohkosta lukuun ottamatta tilanteita, joissa hiiri on paikassa, joka avaa seuraavan tason alivalikon.

5. Emovalikko on näkyvissä koko sen ajan, kun vierailija on viimeksi avatulla valikkotasolla.

6. Valikossa ei synny tilannetta, että alivalikko jää "orvoksi" (esim. kolmannen tason alivalikkon on orpo, jos se on näkyvissä tilanteessa, jossa sen emovalikko on piilossa).

7. Kun vierailija on mennyt minkä tahansa alivalikon viimeiselle alivalikkotasolle hän voi alivalikosta samaa "polkua" pitkin ensimmäisellä tasolla olevaan päävalikkoon.

Ratkaisuni erityisedut ovat seuraavat (monia niistä ei ole mahdollista välttää muilla ratkaisuilla):

1. Tässä ratkaisussa ei tule koskaan vakavia ajastinviiveiden aiheuttamia ongelmia.

2. Mitään ylimääräisiä keinotekoisia täytekuvia ei tarvita.

3. Erilliset sulkemislinkit ovat tarpeettomia.

4. Tapahtumankäsittelijäattribuuttien määrä voidaan minimoida ja onmouseout ei tarvita välttämättä lainkaan alivalikoiden sulkemiskomennoissa.

5. Valikot voivat olla hyvin monitasoisia ilman merkittäviä ongelmia. Olen käyttänyt neljätasoisia valikoita ja ovat toimineet yhtä virheettömästi kuin toisen tason valikotkin.

6. Tämä on äärimmäisen helppo ratkaisu Web-suunnittelijoille (heidän tulee kuitenkin tietää, missä selaimissa se toimii).

7. Jos valikon tekijä jättää linkkien ympärille tarpeeksi tyhjää tilaa (ja/tai valikoilla on taustalaatikot) valikon käyttäjä ei vahingossa sulje niitä. Tällöin nopeasti sulkeutuvat valikot tuntuvat sangen miellyttäviltä.

Ratkaisun rajoitteet ja haitat ovat seuraavat:

1. Ratkaisun ainoa merkittävä rajoite on se, että "mukavan pehmeitä" viiveitä ei ole käytetty. Windows XP:n käyttäjät ovat niihin tottuneet (en henkilökohtaisesti tykkää hitaasti ja pehmeästi avautuvista pudotusvalikoista. Selainten täytyy kuitenkin toimia internetissä paljon epävakaammissa olosuhteissa kuin tavanomaisten sovellutusten vakaassa käyttöjärjestelmässä. Ei ole järkevää pyytää Web-sivun toimivan kuin MS Word. Toki viiveajat haittaavat toisia selaimia vähemmän kuin toisia. Jos - kuten moni suunnittelija tekee - ei välitetä enemmän tai vähemmän heikentyneestä toimivuudesta jossakin selaimessa viiveitäkin voi käyttää.

2. Valikoita ei voi laatia siten, että viimeisimmän avatun alivalikkotason kokonaan ohitettua vain viimeinen alivalikkotaso häviää näkyvistä mutta edelliset alivalikkotasot jäävät näkyviin. Tällaista käytöstä vierailijat eivä kuitenkaan yleensä kaipaa, sillä jos edelliset tasot jäisivät aina näkyviin, ne täytyisi varta vasten käydä sulkemassa. Se loisi vierailijalle lisätyötä, mitä pidetään yleensä epämiellyttävänä piirteenä. Systeemissäni on aina mahdollista palata samaa polkua myöten päävalikkoon, mutta polulta "liukastuminen" sulkee kaikki avoimet alivalikot. Liukastuminen voidaan tosin haluttaessa eliminoida taustalaatikoilla.

3. Ratkaisuni pienenä haittana on se, että MS IE 4.x Windows -selaimelle paras mahdollinen ratkaisu edellyttää lukuisten varjolaatikoiden käyttöä. Varjolaatikoista on tiettyjä etuja myös muille selaimille. En kuitenkaan pidä järkevänä luoda niitä pelkästään MS IE 4.x Windows takia. MS IE 4.x Windows on harvinaiseksi käyvä selain ja tämän haitan merkitys vähenee päivä päivältä.

Mikäli haluat enemmän ohjeita suosittelen vierailemaan muilla sivustoilla. Löydät hyviä vihjeitä TechsOfTheWeb-sivustolta.

Asemointi

Aiheet

• Visibility & position
• Muut vaihtoehdot

Visibility & position

Kaikissa muissa DOM/DHTML tukevissa selaimissa paitsi Netscape 4.x -selaimissa asemointi perustuu yksinomaan CSS:ään. Kunnolla tuettuja ominaisuuksia ja niiden arvoja ovat position:absolute, top ja left. Näiden lisäksi sivujen suunnittelijoiden tulee määritellä pinotaso käyttäen ominaisuutta z-index, jos suurempi arvo merkitsee korkeampaa asemaa elementtien muodostamassa pinossa. Oletus näkyvyysarvo on yleisimmin päävalikolla visibility:visible ja alivalikoilla visibility:hidden. Näitä arvoja sitten muutetaan JavaScript-koodauksella.

Jos valikoita suljetaan sisällön kautta, sekä valikon pohjaelementille että asiasisällölle tulee antaa z-index ominaisuus, jotta valikot olisivat oikeassa pinotasosuhteessa myös varsinaisen asiasisällön kanssa. Mikäli pohjatason elementille ei ole määritellä pinotasoja, mikä tahansa jäljessä tulevan asiasisällön elementti, jolle on määritelty pinotaso tulee asettaa valikon yläpuolelle. Valikkoelementin sisällä olevat pinotasot ovat tällöin suhteessa vain keskenään eivätkä suhteessa Web-sivun asiasisältöön.

Tällä tavoin määritellyt elementit eivät vaikuta millään lailla toisten elementtien asemointiin. Esim. position:absolute; top:50px; left:50px; width:600px; height:400px; visibility:hidden vaikutus on käytännössä sama kuin sillä, että elementillä olisi display:none. Asemoituna ja piilotettuna linkit eivät lainkaan tilaa dokumentin muulta sisällöltä!

Esittämääni systeemiä voidaan käyttää kaikissa sellaisissa valikoissa, joissa elementeille voidaan etukäteen määritellä tietty paikka. Tyypillisin ratkaisu on pudotusvalikko, joita olen käsitellyt tällä verkkosivulla. Ratkaisun etu on siinä, että valikoiden aukaiseminen ei koskaan aiheuta koko dokumentin tai siitä suuren osan uudelleen muotoilun tarvetta. Omassa ratkaisussani vain määritellyt valikot paljastetaan niissä paikoissaan, joissa ne todellisuudessa ovat sivulla! Jos valikot tuotetaan "lennosta", ne eivät silloinkaan vaikuta millään tavoin dokumentin muiden elementtien asemointiin - vain valikoiden suorittamisen nopeus ja/tai luotettavuus muuttuu verrattuna linkkeihin, jotka ovat valmiiksi olemassa sivulla!

Koska minulla on samasta perusvalikosta useita eri versioita, kokosin asemointimäärittelyjä ryhmiin sen mukaan, mikä on valikoiden vaaka- tai pystyasemointi (valikoiden nimet ja ominaisuuksien arvot ovat nykyisin eri kuin esimerkissä):

/* toisen tason alivalikoiden vaaka-asemointi ja z-index */
#Generic, #MainPages,... {left:128px; z-index:19;}
/* kolmannen tason alivalikoiden vaaka-asemointi ja z-index */
#MainPagesAppendixes, #Generic1,... {left:266px; z-index:20}
/* kaikkien valikoiden pystyasemointi */
#Pages, #PagesEn,... {top:42px}
#MainPages, #Generic1,... {top:59px}
...

Käyttämissäni esimerkeissä on ollut monitasoisia valikoita. Vaihtoehtona olisi sisentää alemman tason valikkokohdat - alivalikot muistuttaisivat tällöin sisällysluetteloa - vertaa vaihtoehtoja kahden kuvakaappauksen avulla.

Kaikista kehittyneimmillä selaimilla toimii myös position:fixed asemointityyppi. Näin asemoituihin valikoihin pääsee koska tahansa. Olen havainnut, että position:fixed tuo suunnitteluun rajoituksia sillä ainoa järkevä systeemi on se, että päävalikko on pystytasossa ja linkit ovat allekkain. Jos käytettäisiin kaikki ankkurit aiheuttavat ongelmia sillä valikko peittää sisällön alun. Vierailijan täytyisi joka kerta hieman vierittää tekstiä ylöspäin kun sivun sisäisiä linkkejä olisi käytetty - vierailija olisi äkkiä vihainen kuin ampiainen ja kirosanoja piisaisi!

Jos on mahdollista syntyä tilanne, että valikko piilottaa osan sisällöstä, pitäisi olla mahdollista piilottaa koko valikko. Tietenkin tulee olla myös linkki, jolla saa piilotetun valikon uudestaan esille. Alla on muutamia kuvia mahdollista linkeistä, jolla päävalikon saa piilotettua ja paljastettua sekä kuvakaappaus valikosta, joka niitä käyttää.

Piilottamisen ja paljastamisen voi tehdä myös täysi- tai puoliautomaattisesti. Jälkimmäisessä tapauksessa onmousedown sulkisi sisällön kautta koko valikon. Se paljastaisi myös sivun (vasemmassa, oikeassa tai molemmissa) reunoissa olevat aktiiviset alueet, joilla on onmouseover, jotka tuovat valikon jälleen näkyviin.

Muut vaihtoehdot

Jos valikot määritellään aina samaan paikkaan ja saman kokoisina, valikoiden vaihdot voidaan periaatteessa toteuttaa visibility ominaisuuden arvojen muutosten sijasta z-index ominaisuuden arvojen muutoksilla. En osaa kuitenkaan sanoa, miten laajasti tämä ratkaisu on tuettu.

Sekä visibility että z-index ratkaisujen on siinä, että se ei sovellu valikoihin, joissa elementeille ei voi etukäteen määrittää tiettyä paikkaa. Tämän tyyppinen valikko on esim. Windowsin Resurssienhallinta, josta on alla kuvakaappaus.

Koska valikkoa voidaan laajentaa missä tilanteessa tahansa, pystytason asemointia ei voi määrittää etukäteen. Elementit pitäisi piilottaa/ paljastaa display:none ja display:block vaihdoilla. Kun elementeille on määritelty display:none niitä ei ikään kuin ole lainkaan koko dokumentissa. Kun niille määritellään display:block ne "raivaavat" itselleen oman tilan.

Ratkaisulla on erittäin ongelmallinen, jos valikoille ei ole varattu lainkaan tai niille on varattu riittämättömästi laajentumistilaa. Valikoiden avaaminen voi aiheuttaa jatkuvaa dokumentin uudelleen muotoilua. Se tuo selaimen toimintaan hitautta ja kaatumisriskin. Kuten olen tuonut esille, ominaisuuden display dynaamiset muutokset eivät ei toimi Opera 4.x-6.x -selaimissa. Vasta . Ymmärtääkseni juuri edellä esittämieni ongelmien vuoksi Opera Software on päättänyt, että sen valmistamat Opera 4.x-6.x -selaimet eivät tue ominaisuuden display dynaamisia muutoksia. Mielestäni display-ominaisuuden dynaamiset muutokset ovat ylipäätänsä huono ratkaisu kehyksettömillä Web-sivuilla, vaikka Opera 7.x+ ja muut modernit selaimet tukevat niitä.

Resurssienhallinnan tapaiset valikot soveltuvat oikeastaan vain kehyksiin, jossa valikko on omassa kehyksessään - sitenhän Windowsin resurssienhallintakin toimii! Vastaavan systeemin saa Java-appleteilla, esim. Auscompin tuotteilla. Java-applettien ongelmana on hitaus ja se, että monet selaimet eivät tue niitä vakiona. Sun Microsystemsin JRE on iso apuohjelma ladattavaksi modeemiyhteyksillä. Dynaamisia valikoita saa myös Flash-animaatioina. Macromedian tuotteiden lisäksi Flash-animaatioita saa muillakin ohjelmilla. Itselläni ei ole mitään kokemusta niiden käytöstä.

Flash- ja applettivaihtoehtojen edut ja haitat:

• Flash:
  • Edut:
    • Toimii samalla tavalla kaikissa selaimissa, joihin on asennettu lisäosa.
    • Valikko toimii luotettavasti - myös viiveaikoja käytettäessä!
  • Haitat:
    • Vaatii lisäosan. Jos se puuttuu, se on suhteellisen nopea asentaa.
    • Valikko on täysin riippuvainen lisäosasta.
• Appletit:
  • Edut:
    • Toimii samalla tavalla kaikissa selaimissa, joihin on asennettu lisäosa.
  • Haitat:
    • Vaatii lisäosan. Jos se puuttuu, se on erittäin hidas ladata verkosta.
    • Valikko on täysin riippuvainen lisäosasta.
    • Monet selaimet kaatuvat applettien kanssa.
    • Appletit lataantuvat modeemiyhteyksillä hitaasti.

Valikoiden luominen on suhteellisen helppo hoitaa kehyksissä myös siten, että JavaScript tai serveripuolen ohjelmointi luo "lennosta" alivalikon avaamisen yhteydessä kokonaan uuden valikkosivun. Tällaiset valikot toimivat myös Operassa.

• Edut:
  • Valikot toimivat samalla tavalla kaikissa selaimissa.
  • Valikot toimivat luotettavasti.
  • Sivut latautuvat nopeasti
• Haitat:
  • Monet eivät osaa tallentaa asiasivuja.
  • Monet eivät osaa tulostaa mielekkäästi.
  • Alisivujen merkitseminen suosikkilistoihin työlästä (joillakin sivustoilla tämä on kokonaan estetty).
  • Systeemi soveltuu hyvin vain sivuille, joissa on erityispalvelu, mutta joita ei tarvitse tallentaa ei tulostaa.

Ulkoasu

Mitä tulee valikoiden ulkoasuun ongelmat Netscape 4.x -selainten kanssa jatkuvat, koska CSS ei toimi kuin osittain käyttämäni dynaamisten valikoiden kanssa. Varsinkin linkitetyn CSS:n kanssa on vaikeuksia, sillä vain osa siitä toimii. Koska suora CSS toimi paremmin, käytän jonkin verran style-attribuutteja (olen tarvittaessa kumonnut niiden vaikutuksen käyttäen muille selaimille !important-sääntöä). Jouduin lisäämään jonkin verran ylimääräisiä elementtejä (esim. B ja IMG), jotta sain esitysasun riittävän hyväksi. Linkit tuntuivat kaipaavan FONT elementtiä, sillä edes style attribuutti ei aina toimi. Muille kuin Netscape 4.x -selaimille ulkoasu määräytyy pääosin ulkopuolisista CSS-tiedostoista käsin.

Mikäli Netscape 4.x -selaimia tuetaan, dynaamisen valikon HTML-koodi täytyy laittaa aivan sivun alkuun, sillä havaitsin, että Netscape 4.x kaatui, kun se oli keskellä sivua erään taulukon sisällä!

Mielestäni on järkevää asettaa id- or class-attribuutti jokaiselle linkille ja sen emoelementille tai taulukkosolulle, jonka sisällä linkki on (muista, että id-attribuutin arvojen tulisi olla sivukohtaisesti uniikkeja). Tällä tavoin voi sama valikko näkyä joka sivulla hieman erilaisena. Joka sivulla on tyylisivu, joka on sääntö, joka koskee avoinna olevaan sivuun viittaavaa linkkiä. Yksitasoissa dynaamisissa tai staattisissa valikoissa avoinna olevan sivun linkin voi joko piilottaa display:none tai sille määritellään erityiset color ja/tai background-color/ background ominaisuudet. Jälkimmäistä vaihtoehtoa voidaan käyttää myös monitasoisissa dynaamisissa valikoissa. Esim. tällä sivulla on seuraava CSS:

#Dy {background-color:#ffd700 !important; color:#303400 !important}

Se luo seuraavan kuvakaappauksen kaltaisen lopputuloksen:

Ominaisuuksille on asetettu !important eliminoimaan linkki- ja dynaamisten näennäisluokkien (a:visited jne.) vaikutus. Jos linkeillä ei ole alivalikoita, niille voi asettaa myös cursor:default. Merkkaamalla avoinna olevan sivun, sivulla vierailija ei niin helposti klikkaa avoinna olevaa sivua koskevaa linkkiä turhanaikaisesti. Samalla hän voi joka hetki tietää, missä kohtaa hän on valitussa sivuryhmässä.

Uudet Opera, MS IE ja Mozilla Gecko (esim. Netscape 6.x) -selaimet eivät tarvitse kuvalinkkejä, sillä asettamalla tekstilinkille display:block se näyttää ikään kuin kuvalta kuten alla olevassa kuvakaappauksessa (uusilla Opera ja Netscape -selaimilla koko elementti toimii aina linkkinä, mutta MS IE kohdalla toisinaan koko elementti on aktiivinen ja toisinaan ei; jälkimmäisessä tapauksessa display:block saa aikaan vain visuaalisen efektin, mutta vain teksti toimii linkkinä; jos MS IE:llä ominaisuuden width arvo on jokin muu kuin auto, linkit ovat aktiivisia koko käytettävissä olevalta leveydeltään lukuun ottamatta tilanteita, joissa linkit käyttävät ominaisuutta float eivätkä kaikki linkit mahdu samalle riville; ongelmasta voidaan päästä eroon myös lähinnä MS IE 4.x Windowsille esittämälläni tavalla).

Käyttämällä eräitä näennäisluokkia, on mahdollista saada sama lopputulos kuin JavaScript & tapahtumankäsittelijöillä, jotka vaihtavat kuvan or tekstilinkin taustavärin kun hiiri kulkee linkin ylitse/ohitse tai tekee muita toimenpiteitä. Optimaalisen lopputuloksen saavuttamiseksi tarvitaan esim. seuraavat ominaisuudet:

.pageGroup a {display:block; width:100px; height:15px; line-height:15px; margin-top:0; margin-bottom:0; padding-top:0; padding-bottom:0; font-size:12px} /* Ilman line-height ominaisuutta linkkien väliin saattaa jäädä pystytasossa tyhjää tilaa eivätkä tekstilinkit toimi täysin kuvalinkkien tapaan. Jos linkit ovat taulukkosolujen sisällä, myös taulukkosolut tarvitsevat line-height ominaisuuden, jotta saadaan hyvä lopputulos myös Mozilla Gecko -selaimissa (edempänä on tähän asiaan liittyvä koodiesimerkki). Pystytason margin ja padding ominaisuudet on mielekästä asettaa nollaksi, että linkit toimisivat samoin mahdollisimman monessa selaimessa. Fonttikoko kannattaa määrittää siten, että sitä on mahdollisuus isontaa 120%. */
.pageGroup span.link {background:...; padding-left:11px;...} /* Olen joissakin versioissa tekstilinkkien ympärillä elementtiä, joille olen taustaominaisuudet ja padding-left ominaisuuden. Tämä elementtikerros ei ole välttämätön. Suosittelen vain taustavärien asettamista, sillä taustakuva ei toimi kaikissa selaimissa. */
.pageGroup span.Link a:link {background:...; color:...}
.pageGroup span.Link a:visited {background:...; color:...}
.pageGroup span.Link a:hover {background:...; color:...}
.pageGroup span.Link a:active {background:...; color:...}
.pageGroup span.Link a:focus {background:...; color:...}

Koska display:block ei toimi kunnolla Netscape 4.x - ja MS IE 4.x Windows -selaimissa (ks. yllä oikealla puolella oleva kuvakaappaus MS IE Windows -selaimen toteutuksesta ja vertaa sitä vasemmanpuoleiseen kuvaan), ratkaisu ei ole tyylikäs Netscape 4.x - ja MS IE 4.x Windows -selaimissa. Medialohkoja käyttäen luoda CSS, jossa MS IE 4.x Windows ja Netscape 4.x eivät saa tekstilinkeille taustaominaisuuksia (minulla MS IE ongelmia käsittelevällä sivulla joitakin tähän asiaan liittyviä vihjeitä; koska laitoin tekstilinkeille taustaominaisuuksia, ne voivat näyttää em. selaimilla hieman rumilta).

MS IE 4.x Windowsille on tosin mahdollista saada sama lopputulos linkkien emoelementeille annetuilla tapahtumankäsittelijäattribuutilla. Mikäli myös alivalikoiden avaus- ja sulkemistoiminnot toteutetaan emoelementtien välityksellä saadaan illuusio, että linkit ovat koko leveydeltään aktiivisia, esim.:

var nav_over = "this.style.background='#cee8ea';";
var nav_out = "this.style.background='#ffffff';";
...
<div onmouseover="MM_showHideLayers('Generic','','show',...); eval(nav_over);" onmouseout="eval(nav_out);"><a onmouseover="MM_showHideLayers('Generic','','show',...);" href="..."></div>

Vastaavan ratkaisun lisääminen Netscape 4.x:lle kasvattaa koodimäärää rajusti, sillä tarvitaan (jälleen kerran) LAYER-elementtejä.

Tekstipohjaiset linkitkin toimivat kohtalaisen hyvin Netscape 4.x - ja MS IE 4.x Windows -selaimissa, jos linkeillä itsellään ei ole taustaominaisuuksia ja jokainen linkki on omalla taulukkorivillä siten, että sekä linkin vasemmalla että oikealla puolella on taulukkosolu, jossa on kuva ja keskimmäisen solun leveys määritellään kuvalla. Vasemmalla ja oikealla puolella olevissa soluissa olisi linkkejä, jotka avaisivat/ sulkisivat alivalikoita. Vasemmanpuoleisissa soluissa voisi olisi listanappeja. Tarvittaessa myös korkeusarvoja määritellään läpinäkyvillä täytekuvilla.

Edelleen jää jäljelle reunusongelma. Jos reunukset antaa CSS:llä Netscape 4.x jättää taustavärin ja lohkon reunusten väliin muutaman pikselin levyisen läpinäkyvän ruman täytealueen. Lisäksi on huomattava se, että vanhimmat Netscape 4.x -sarjan selaimet kaatuvat CSS-reunuksista. Kokonaisuutta ajatellen tämän eliminoimiseksi on paras keino määritellä taulukolle taustaväri ja luoda "reunukset" joka puolella sisältöä kiertävien taulukkosolujen avulla (soluissa voi käyttää rowspan ja colspan attribuutteja). En ole näin menetellyt kaikkien valikoiden osalta menetellyt vaan ainoastaan päävalikon kohdalla.

Jos taustaväri annetaan elementille LAYER ja sen sisään tulee elementti, jolla on reunukset, ei myöskään synny ongelmaa läpinäkyvistä täytealueesta. Alla on kuvakaappaus testivalikosta. Ratkaisin reunus- ja taustaväriongelmat ensimmäisen tason valikon kohdalla lisäämällä ylimääräisiä taulukkosoluja. Toisen tason valikossa on käytetty tuotettua LAYER elementtiä.

LAYER-ratkaisun etu on helppous ja se se, että myös taustakuvia voi käyttää eikä Netscape 4.x hajota niitä rumasti yksittäisiin taulukkosoluihin. Sillä on myös haittapuolensa. Kuvakaappauksesta näkyy, että taulukkorivien korkeus ei ole sama. Oikeanpuoleisen taulukon ympärillä on lohko, jolla on border ja padding ominaisuudet. Taulukon korkeus vaihtelee tällaisissa tapauksissa, vaikka niissä olisi yhtä monta solua. Ylimääräisten taulukkosolujen lisäetu on siinä, että pystydimensiot toimivat täsmällisemmin. Itse asiassa täsmällisesti toimivat täytealueet vaativat sisällön ympärille reunusten tavoin ylimääräisiä taulukkosoluja (tarvittavien palstojen määrä nousee tällöin seitsemään ja ylimääräisten taulukkorivien neljään).

Tekemässäni mallisivussa on päävalikoissa käytetty seitsenpalstaisia taulukkorivejä mutta alivalikoissa yksinkertaisempia kolmipalstaisia rakenteita. Kaikki valikot sekä yläoikealla valikoihin liittyvät linkkikokonaisuudet ovat skripteillä tuotettujen LAYER-elementtien sisällä. Alla on esimerkki menetelmästä miten luoda ylimääräiset taulukkorivit ja -palstat (koska täytekuvan luonnolliset dimensiot ovat 1x1 pikseliä, ei ole aina välttämätöntä määrittää sekä height että width attribuutteja).

<table summary="" cellspacing="0" cellpadding="0" border="0" bgcolor="white" width="126" >
<tr class="topCells">
<td id="cell1" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="1" /></td>
<td id="cell2" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="2" /></td>
<td id="cell3" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="11" /></td>
<td id="cell4" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="101" /></td>
<td id="cell5" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="8" /></td>
<td id="cell6" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="2" /></td>
<td id="cell7" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" height="1" width="1" /></td>
</tr>

<tr class="paddingCells">
<td rowspan="5" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" width="1" /></td>
<td rowspan="5"><img src="spacer.gif" border="0" alt="" width="2" /></td>
<td colspan="3"><img src="spacer.gif" border="0" alt="" height="5" /></td>
<td rowspan="5"><img src="spacer.gif" border="0" alt="" width="2" /></td>
<td rowspan="5" bgcolor="#303400"><img src="spacer.gif" border="0" alt="" width="1" /></td>
</tr>

<tr class="contentCells">
<td><img src="menuButton.gif" border="0" alt="" height="10" width="10" /></td>
<td>Ekarivi</td>
<td><img src="rightArrowr.gif" border="0" alt="" height="15" width="8" /></td>
</tr>

<tr>
<td><img src="menuButton.gif" border="0" alt="" height="10" width="10" /></td>
<td>Tokarivi</td>
<td><img src="rightArrowr.gif" border="0" alt="" height="15" width="8" /></td>
</tr>

<tr>
<td><img src="menuButton.gif" border="0" alt="" height="10" width="10" /></td>
<td>Kolmasrivi</td>
<td><img src="rightArrowr.gif" border="0" alt="" height="15" width="8" /></td>
</tr>

<tr class="paddingCells">
<td colspan="3"><img src="spacer.gif" border="0" alt="" height="5" /></td>
</tr>

<tr class="bottomCells">
<td bgcolor="#303400" colspan="7">
<img src="spacer.gif" border="0" alt="" height="1" /></td>
</tr>
</table>


Huomasin, että päävalikko toimi pääasiallisena testiselaimena käyttämässäni Operassa hieman hitaammin kuin aiemmin. Ainakin Opera kärsii monimutkaisemmasta rakenteesta, jolla ulkonäkö tuli paremmaksi Netsape 4.x -selaimissa. En suosittele luomaan käyttämääni rakennetta raskaampaa systeemiä. Jos käytetään perusratkaisuna kaksinkertaisia taulukoita laskin, että kohtuullisen hyvän lopputuloksen saamiseksi Netscape 4.x vaatii yli 50% prosenttia enemmän koodia kuin modernit selaimet. Minimikoodaukseen verrattuna Netscape 4.x takia saattaa tarvita lisätä yli kaksinkertainen määrä koodia! On siksi melko kyseenalaista tukea Netscape 4.x -selaimia.

Seitsenpalstainen taulukkorivi, joka oli päävalikon DIV-elementin sisällä, aiheutti uusille Opera, MS IE ja Mozilla Gecko -selaimille ongelmia taulukossa;. HTML-attribuuteista huolimatta taulukkorivit, täytekuvat ja itse taulukko on syytä määrittää CSS:llä. Testaamassani Netscape 6.1 tasoinen Mozilla 0.9 tarvitsi height ja width ominaisuuksien lisäksi matalille taulukkosoluille myös line-height ja font-size ominaisuudet (selain tuntuu olettavan, että solussa on aina järkevän kokoista tekstiä) sekä taulukolle table-layout:fixed. Alla on muutamia esimerkkejä miten sen voisi toteuttaa (osa CSS:stä on käytässä sivustoillani):

#Pages table, #PagesEn table {width:136px; table-layout:fixed} /* Kun käytetään kiinteää taulukonlaadintaa, yksittäisten solujen kokonaisleveys täytyy täsmätä taulukon kokonaisleveyden kanssa */
#cell1,#cell2, #cell3,... {height:1px; line-height:1px; font-size:1px}
#cell1 img, #cell2 img, #cell3 img,... {height:1px}
#cell1 img, #cell7 img, td#cell1, td#cell7 {width:1px}
...
#cell4 img, td#cell4 {width:105px}
...
.paddingCells td {line-height:5px; font-size:5px; height:5px}
...
div.pageGroup td {height:15px; line-height:15px; padding:0} /* Solut, joissa on itse linkit. Ilman tätä määritystä rivien korkeus ei ole sama kuin uusissa MS IE ja Opera selaimissa. Ratkaisu ei toimi kunnolla MS IE 4.x Windows -selaimissa, sillä vain osassa soluista rivikorkeus on oikein. */

Vanhanaikaiset HTML 3.2 -tyyppiset rakenneratkaisut aiheuttavat ylimääräistä työtä ja niitä on vaikea saada toimimaan oikein uusissa Mozilla Gecko -pohjaisissa selaimissa. Uusille selaimille olisi paljon järkevämpää poistaa ylimääräiset taulukkorivit (ja jos rowspan attribuutteja on käytetty) samalla myös ylimääräiset taulukkopalstat määrittämällä ylimääräisille taulukkoriveille display:none (päävalikon taulukoihin jäisi tällöin kolme palstaa). Jotta näin voi toimia ylimääräisille taulukkoriveille täytyy määrittää joko id tai class attribuutit (esim. tr.topCells, tr.paddingCells, tr.bottomCells {display:none}). Tällöin voitaisiin määrittää todelliset padding ja border ominaisuudet päävalikon säilytinelementille. Näin Netscape 4.x toimisi vanhanaikaisella HTML 3.2:n ohjauksella ja uudemmat selaimet modernimmalla CSS:n ohjauksella. Olen kuitenkin havainnut, että line-height ominaisuuden asettaminen ei aina auta saamaan haluttua lopputulosta Mozilla Gecko selaimissa (a test page).

Edellä esittämäni ratkaisu ei kuitenkaan toimi MS IE 4.x Windows -selaimessa, sillä selain ei tue display:none taulukkoriveille. Jos Netscape 4.x:n tarvitsemat ylimääräiset rivit ja pastat skripteillä, dokumentti ei ole rakennettu aivan (X)HTML spesifikaatioiden mukaisesti. En löytänyt MS IE 4.x Windows -selaimille tekstilinkkejä käytettäessä täysin tyydyttävää ratkaisua. Jos valikoita tuotetaan lennosta JavaScript-koodauksella (kuten DHTML Menu Builder tekee), ne voivat olla erilaisia Netscape 4.x ja muille selaimille. Mutta valikoiden tuotattaminen skripteillä on sekin ongelmallista.

Optimaalisen tyylikäs ja parhaalla mahdollisella tavalla toimiva lopputulos MS IE 4.x Windows ja Netscape 4.x -selaimille saadaan ainoastaan silloin, kun kaikki linkit ovat kuvalinkkejä. En muuta kuitenkaan kaikkia linkkejä kuvalinkeiksi niiden vaatiman ylimääräisen työn vuoksi. Kuvalinkkien suosijan ei mielestäni kannata koodata sivuja käsin, vaikka TechsOfTheWeb.Com sivusto opettaa, miten kuvia voi käyttää dynaamisissa valikoissa. Koska MS IE 4.x ja Netscape 4.x käytetään suhteellisen vähän ja ne ovat sangen virheellisesti toimivia selaimia, en koe niiden täysipainoista huomioon ottamista mielekkääksi. Suosittelen koodieditoria käytettäessä tekstilinkkien käyttöä täytekuvin täydennettynä. Mielestäni ainoa järkevä vaihtoehto tälle on tehdä valikot kaupallisilla ohjelmilla kuten Macromedia Dreamweaver ja DHTML Menu Builder. Tosin huomautan vielä siitä, että em. ohjelmilla tehdyillä valikoilla esiintyy todennäköisesti ainakin joillakin selaimilla stabiliteettiongelmia.

Valikoiden ulkonäköä voi luoda tyylikkäämmäksi laittamalla niille aidosti tai näennäisesti läpinäkyviä valikoita tai varjoja.

Selostan joitakin käyttöseikkoja myös selailuohjeissa - suurimmalla osalla sivuista on pikalinkki tähän opastukseen (kysymysmerkki ).

J Mitä ovat käyttäjän tyylisivut (User style sheets)

Aiheet

• Yleistä
• Miksi käyttäjän tyylisivut?
• Käyttäminen ja sen puutteet

Yleistä

Käyttäjän tyylisivut (user style sheets) eli käyttäjän CSS toimii sangen hyvin ainakin MS IE 5.x+ ja Opera 4.x+ -selaimissa. Se, millä tavoin niitä käytetään ja miten niillä voi kontrolloida sivujen tekijän ja käyttäjän vaikutusta sivun esitysasuun, on selainkohtainen asia.

Miksi käyttäjän tyylisivut?

Käyttäjän tyylisivuista on mm. seuraavia hyödyllisiä käyttötarkoituksia:

• Voit vaihtaa sivustoilla, joita sinun on vaikea lukea sivujen ulkoasun helpommin luettavaksi esim. vaihtamalla fonttityylin, suurentamalla fonttia, vaihtamalla tekstin ja taustan värejä.
• Jos käytät Opera 4.x+:aa voit asettaa sivun leveyden itsellesi sopivaksi. Voit käyttää vaikka tällä sivulla näkemääsi tyyliä. Tämä tyyli on käyttökelpoinen sivuilla, joissa teksti normaalisti valuu vasemmasta laidasta oikeaan laitaan.
• Useimmissa tapauksissa ne nopeuttavat sivujen selaamista. Mikäli haluat etsiä internetistä vain asiatietoa, suosittelen käyttäjän tyylisivuja.
• Ne ovat hyödyllisiä testivaiheessa.
  • Sivuilla on helppo kokeilla vaihtoehtoisilla esitysmalleilla. Nämä esitysmallit voi lähettää myös sivujen asiakkaalle tai antaa vaikka sivujen selaajan käyttöön.
  • Vajaille tiedostoille saa CSS:n, jolloin niidenkin esitysasua voi testata siirtämättä niitä palvelinohjelmalle.

Huomautus. Jos määrittelet näyttömedian (@media screen), muista myös kokoruutunäyttötila. Käytä sille omaa mediatyyppiä (@media projection) tai määrittele se yhdessä normaalin näyttömedian kanssa (@media screen, projection).

Kokeile tekemääni userCss.css -tiedostoa esim. menemällä CSS spesifikaation sivuille CSS:ni kanssa(linkki avaa uuden ikkunan).
Huomautus Tämä tiedosto on määritelty siten, että kaikki sivujen tekijän FONT elementit sekä sivujen tekijän määrittämät teksti- ja taustavärit menettävät merkityksensä. Tämä on välttämätöntä, ettei synny tilannetta, jossa tekstin ja taustan värit ovat samat tai hyvin lähellä toisiaan. Tiedosto on optimoitu Opera 5.x+:lle, sillä sen tarkoituksena on hallita sivulla olevan tekstin leveyttä.

Sivun leveyskontrolli toimii testaamistani selaimista vain Opera 4.x+, Konqueror (Linux-käyttöympäristö) ja Mozilla Gecko (esim. Netscape 6.1+) -selaimissa (erään kuvakaappauksen perusteella myös Mac-ympäristöön tehdyssä Safari -selaimessa). Tekemäni CSS ei kuitenkaan pakota kaventamaan taulukoita, joiden sisältö ei mahdu asettamaani ylärajaan (body {max-width:600px}). Jos taulukoita pakottaa tiettyyn maksimileveyteen, taulukkosolujen sisältö voi mennä toistensa pälle, jolloin se on lukukelvotonta.

Käyttäminen ja sen puutteet

Joissakin selaimissa (kuten MS IE 4.01 ja Opera 3.x), missä niitä tuetaan systeemi ei oikein pelaa. Minua ärsytti aikoinaan erityisesti se, että tekstityylin vaikuttavat ominaisuudet eivät toimineet kunnolla.

Asetusten muuttaminen

Kaikkien selainten kohdalla, jotka antavat määritellä käyttäjän tyylisivun tulee ensimmäiseksi määritellä (hakemisto)polku (path), josta CSS-tiedosto löydetään (sinun täytyy tehdä tosin se vain kerran, mikäli et halua vaihtaa käytettyä tyylisivua).

Asetusten muuttaminen on MS IE -selaimissa hieman vaivalloista, sillä ne joutuu hakemaan monen alivalikon kautta: Työkalut > Internet asetukset > Muotoiluasetukset (Tools > Internet options > Acessibility).

Myös Operalla alkuasetusten laittaminen on hieman vaivalloista: Tiedosto > Ominaisuudet > Asiakirjat (File > Preferences > Documents). Muuttaminen sujuu nopeammin, mikäli käytät apuna näppäimistöä: ALT + P > Documents/Asiakirjat - seuraavalla kerralla Opera on valmiiksi tässä kohdassa, joten alkuperäisasetusten palauttaminen sujuu nopeasti. Tämän jälkeen sinun tulee kruksaamalla määritellä, miten haluat tyylisivuen toimivan.

Seuraavilla kerroilla tyylisivuen käyttötavan muuttaminen on Operalla äärimmäisen helppoa, sillä Osoitepalkki (Address bar) -työkalurivillä on painike tätä varten. Opera 7.x -selaimissa kohdalla on lisävalikko, josta voi valita useita esimääriteltyjä tyylisivuja, joita voi käyttää yhtä aikaa. Osa näistä on tarkoitettu tosin vain Web-suunnittelijoille (monen mielestä ne eivät perusselaimeen edes kuulu vaan Web-suunnittelijoille tulisi olla oma selain) ja osa tavallisille selaimen käyttäjille.

Huomautus 1. Mikäli tyylisivuen käyttötapaa muutetaan kohdasta Asiakirjamuoto oletuksena (Document mode as default), tulee muistaa painaa Käytä (Apply), jotta muutos tulee välittömästi voimaan - muussa tapauksessa muutos vaikuttaa vasta avattaessa uusi ikkuna.

Huomautus 2. Saamani s-postin mukaan myös MS IE:hen saa kehittelyohjelmalla (development kit) lisäpainikkeen, olla käyttäjän tyylisivut saa nopeasti päälle/ pois päältä. Nykyisin myös Operaa voi muokata.

En löytänyt Mozilla Gecko selainten käyttöliittymästä kohtaa, jonka avulla voisi määritellä käyttäjän tyylisivutiedoston. Mozilla org. sivuilla opastetaan siirtämään /Chrome hakemisto alihakemistoon eräitä CSS-tiedostoja.

Tiedostojen täytyy sijaita tietyssä paikassa ja niiden tulee olla tietyn nimisiä eikä niiden nimiä tai sijaintia voi Operan ja MS IE -selainten tavoin vapaasti määritellä. Toivoisin Mozilla Gecko -selaimiin yhtä helposti käytettävät käyttäjän tyylisivut kuin mitä on Opera-selaimissa - ehkä kuitenkin liikaa pyydetty, sillä Mozilla Gecko selaimissa on melkoisesti poikkeava käyttöliittyä.

Erilaisen käyttöliittymän takia paras ratkaisu Netscape/Mozilla-selaimille olisi, jos View-valikossa olisi kohta User style sheets siten, että käyttäjä voisi valita usean tyylisivun väliltä. Selaimella tulisi olla helppo tapa määritellä useita tyylisivuja. Määrittelyt pitäisi löytyä polun Preferences > Appearance avulla.

Tosin Netscape/Mozilla antaa mahdollisuuden vaihtaa tyylisivuja (View > Use Stylesheet), mitä puolestaan Opera 3.x-6.x ja MS IE eivät tarjoa (Opera 7.x+ tukee vaihtoehtoisia tyylisivuja). W3C:n mukaan selainten tulisi tukea sekä käyttäjän tyylisivuen että vaihtoehtoisia tyylisivuja. Niiden toimivuus edellyttää attribuutin title käyttöä (esim. <LINK rel="alternate stylesheet" title="Alternate SS">; käsittelen tätä asiaa myös sivulla 2).

Ei-tuettuja piirteitä

Vaikka käyttäjän tyylisivut toimivat Opera 4.x+:ssa sangen hyvin, ne eivät kuitenkaan toimi yhtä hyvin kuin sivun laatijan tyylisivut. Seuraavat asiat eivät toimi Opera 4.x-5.11 -selaimissa:

• background-image.
• list-style-image.
• @media print ja ylipäätänsä tulostukseen tarkoitettu CSS.
• @media projection ei toimi Opera 6.0:ssa (se toimii ainakin Opera 5.x -sarjan selaimissa).

MS IE 5.5:ssä list-style-image ja background-image toimivat, mutta @media ja @page at-säännöt kaatavat sen (MS IE 6.0 ei kaadu niistä). Tulostusta ei voi kontrolloida käyttäjän tyylisivuilla MS IE 5.5:ssäkään. Dokumentin CSS:ää ei saa pois päältä, jotta voisi (Operan tavoin) käyttää vain käyttäjän CSS:ää.

Koska käyttäjän tyylisivu on tarkoitettu olemaan yksi tyylisivu, tuontisääntö (@import) ei toimi. Tämä voi olla tosin myös selaimen virhe.

!important

Ns. tärkeyssäännön (!important ks. sivu Prosessointijärjestys käytöllä ei käytännössä ole suurta merkitystä. MS IE:ssä selaimen asetuksilla voi hallita (karkeasti) värejä ja fontin esittämistä, mutta muiden ominaisuuksien suhteen tarvitaan tärkeyssäännön käyttämistä (esim. ul li {list-style-image: url(pallo.gif) !important;} antaa käyttäjän määrittelemille listakuville suuremman painon kuin sivujen tekijän määrittelemille listakuville). MS IE 5.5 tuntuu seuraavan CSS 2:ta, jonka mukaan sivujen käyttäjän tärkeyssääntö voittaa sivujen tekijän tärkeyssäännön.

Ainakin versioon 5.01 asti Opera-selaimet tuntuvat seuraavan sen sijaan CSS1:tä, jonka mukaan sivujen tekijän tärkeyssääntö voittaa käyttäjän tärkeyssäännön (tällä ei tosin ole kovin suurta merkitystä, sillä kaikki sivujen tekijän laatima CSS voidaan ottaa pois käytöstä). Opera 5.12:ssa käyttäjän CSS:llä on prioriteetti mutta Opera 6.0:ssa dokumentin CSS:llä. Näyttää siltä, että vain 5.1x -sarjan selaimet noudattavat tässä asiassa CSS2:ta.

K Miten XML-dokumenttien kanssa voi käyttää CSS:ää

Aiheet

• Yleistä
• CSS-tiedoston käyttö
• Linkitys ja muut XML-piirteet

Yleistä

XML on suhteessa HTML:ään itsenäinen kieli. Sillä on toki HTML:n kanssa yhteisenä "emona" SGML (lue myös XML:n selitys). Myös XML on metakieli, joka sisältää perussäännöt sille, miten XML-pohjaisia kieliä tulee rakentaa. Kieli on syntaksin osalta tiukemmin tyypitetty kuin HTML.

Toisin kuin HTML, XML ei itsessään omaa ainuttakaan muotoilukoodia. XML on puhdas merkintäkieli (markup language), jolloin kaikki aloitus- ja päätöskoodit (engl. start-tag ja end-tag) sekä tyhjien elementtien koodit ovat itsessään vain ja ainoastaan merkintäkoodeja. Dokumentin muotoilu ja sen esitystapa määräytyy käytetyistä apukielistä (esim. CSS ja HTML) käsin (tähän tosiasiaan perustuu myös se, miten olen kääntänyt sanan tag; ks. käännösvastineen perustelut.

Tällä kertaa tarkastelen sitä, miten XML-dokumentteja voi muotoilla CSS:n avulla. Oletuksena on myös se, että käytettyjä elementtejä ei kuvata millään muulla kielellä. XML:n elementeille voi luoda DTD tai XSD (XML Schema Document) -tiedostot, joissa kuvataan elementtien ja attribuuttien oikea käyttö. Niiden käyttäminen ei ole kuitenkaan välttämätöntä. Yhteistä kaikille XML-kielille on vain se, että niissä käytetään dokumentin alussa kuvausilmoituksia (declarations - selostan niitä (X)HTML nooteissa), esim.:

<?xml version="1.0"?>
<?xml-stylesheet href="XML.css" type="text/css"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

CSS2:een on lisätty joitakin piirteitä varta vasten XML + CSS -yhdistelmän toteuttamiseksi tarvittavia piirteitä. Näin ollen kunnollinen toteutus edellyttää seuraavien seikkojen toimivuutta, jotta selainta voidaan pitää XML + CSS -tason selaimena:

1. Standardin XML-syntaksin ja XML-periaatteiden noudattaminen.
2. XML:ssä ei ole samalla lailla yleisiä attribuutteja kuin HTML:ssä, joten yleisten attribuuttivalitsimien tukeminen on välttämätöntä.
3. Riittävän laaja display-ominaisuuden tukeminen niin että voidaan luoda ainakin yksinkertaisia taulukoita ja listaesityksiä.

Huomautus 1. Ensimmäisen periaatteen suhteen MS IE 5.0 -selainta ei voi pitää todellisena XML + CSS selaimena, sillä se tukee vanhentunutta virallista XML-tyylitiedosto syntaksia edeltäviin ehdotuksiin (proposals - niitä kutsutaan nimellä Working Drafts) perustuvaa <?xml:stylesheet ...?> määrittelytapaa. Spesifikaation mukainen syntaksi on <?xml-stylesheet ...?>, jota tukee MS IE 5.5. Tässä mielessä MS IE 5.5 on ensimmäinen Microsoftin valmistama selain, jota voi pitää XML-selaimena.

Huomautus 2. MS IE kuten myös Opera 4.x+ tukevat kuitenkin sellaisia CSS-sääntöjä, jotka on tarkoitettu vain HTML-dokumenteille (ks. sivu Valitsimet kohdasta Attribuuttivalitsimet).

Huomautus 3. Toisen ja kolmannen kohdan perusteella vain Opera 4.x+ ja Netscape 6.x -selaimia voi näillä perusteilla pitää kunnollisina XML + CSS-toteutukseen pystyvinä selaimina. MS IE 5.5 ei ole kunnollinen XML + CSS selain, sillä se ei tue välttämättömiä CSS2-piirteitä.

Muistutan vielä siitä, että tällä sivulla esimerkkinä käytetyt asiakirjat eivät ole täysin toimivia web-asiakirjoja. CSS on puhdas muotoilukieli ja XML on puhdas merkintäkieli. Lopputuloksena on XML-dokumentti ilman linkitystä ja XML:n kautta linkitettäviä elementtejä. XML ei yksinään ole edes hypertekstikieli. Toimiva XML-dokumentti tarvitsee linkityksen, jonka voi toteuttaa useammalla tavalla (en käsittele tässä yhteydessä linkitysmahdollisuuksia). Esimerkkidokumentit vastaavat lähinnä tavanomaista tekstinkäsittelyohjelmalla tehtyä dokumenttia.

CSS-tiedoston käyttö

Otan esimerkiksi dokumentin, joka käyttää saman nimisiä elementtejä kuin HTML-dokumentit. Annan esimerkkinä olevalle XML-dokumentille ainoaksi avuksi linkitettävän CSS-tiedoston (<?xml-stylesheet href="xml-sheet.css" type="text/css" ?>).

Jos tuotakaan ei anneta, MS IE 5.x näyttää dokumentin tekstitiedoston tapaisesti, mutta koodit on merkitty eri väreillä ja koodit on sisennetty (). Toisaalta jos linkitetty CSS-tiedosto ei sisällä mitään tietoa or tiedostoa ei löydy, kaikki teksti on lähes peräkkäin, esim. (olen antanut esimerkin sivulle tyylisivutiedoston, jota ei ole olemassa):

<?xml version="1.0"?>
<?xml-stylesheet href="xml-sheet2.css" type="text/css" ?>
<html>
<head>
<meta name="robots" content="noindex">meta1- elementti META -</meta>
...
<style type="text/css>Uutta tyyliä - elementti STYLE -</style>
<title>Problems in the new technology - elementti TITLE -</title>
</head>
<body>
<h2><a name="Uutta">Problems</a></h2>
<p><b>Structural solutions</b></p>
...

näkyy tähän tapaan ():
meta1- elementti META - Uutta tyyliä - elementti STYLE- Problems in the new technology - elementti TITLE - Problems Structural solutions ...
Elementtejä erottaa vain yksi välilyönti eikä elementin alkua tai loppua voi tietää.

Kun tyylisivuja käytetään lähes jokainen elementti pitää määritellä jollakin tavoin. Vain sellaiset tyhjät elementit, joiden perässä ei ole testiä, eivät tarvitse määrittelyä. Tässä on syytä muistaa myös se, että elementtien head ja body koodeilla ei ole mitään periaatteellista eroa, mikäli DTD-tiedostoa ei ole määritelty. Koska siinä ole myöskään standardisoituja elementtejä, voit vapaasti muuttaa head elementin sisällä olevien elementtien luonnetta normaalista elementistä tyhjäksi elementiksi tai päinvastoin. Voit kirjoittaa myös koodien <head></head> sisälle tekstiä eikä se ole mikään virhe. XML-dokumentille olennaista on vain juurielementti ja että sen sisällä olevat elementit ovat oikein muotoiltuja (well-formed).

Tämä sekä rajoittaa että laajentaa tyylisivuen käyttämistä. Toisaalta voit halutessasi näyttää esim. elementin title sisällön. Se ei ole todellinen TITLE elementti muuten kuin selaimille, jotka eivät ymmärrä XML-dokumentteja ja jotka tulkitsevat ne HTML:nä. Mutta XML-selaimessa se ei esimerkkidokumenteissani hoida edes tuota virkaa, koska elementin tehtävää ei ole kuvattu. Toisaalta et voi poistaa näytöltä ominaisuudella display:none tavanomaisesti käytettyä elementtiä meta, mikäli olet laittanut sen perään tekstiä, esim. ():

<meta name="robots" content="noindex" />meta1- elementti META -

Tuossa tapauksessa elementillä on tosin tehtävä, mutta se johdu elementistä itsestään, vaan siitä, että hakurobotit tunnistavat kyseisen elementin! Mutta jos antaisin sille esim. MS IE 5.0:aa koskevan tehtävän, elementti ei sitä toteuttaisi. Jos seuraava koodi olisi HTML-dokumentissa, selain siirtyisi automaattisesti toiselle sivulle. Esimerkkinä käyttämissäni XML-tiedostoissa niin ei tapahtuisi. Elementin attribuutit olisivat selaimelle sama kuin selain saisi luettavakseen attribuutti="0".

<meta http-equiv="refresh" content="0; url=../Teaching/XSL.html" />

Sama pätee myös HTML-elementteihin HR ja BR, mikäli niitä käytetään XML-dokumenteissa. Jos laitat elementille meta sekä aloitus- että päätöskoodit, voit käyttää sitä täysipainoisesti muotoilukoodina, vaikka HTML-dokumentin suhteen näin et voi toimia. Ilman sisältöäkin voi niitä käyttää rajoitetusti muotoilukoodeina (display:block saa aikaan rivinkatkon). Opera 4.x+:lla ja Netscape 6.x.llä voit määritellä meta:before ja meta:after säännöt, jolloin tyhjäkin elementti toimii laajemmin muotoilukoodina. Tyhjien elementtien käyttö muotoilukoodina on kuitenkin rajoittuneempaa kuin päätösmerkkauksellisten elementtien.

Seuraavassa on esimerkki CSS-tiedostosta, jossa myös elementti head ja sen sisällä olevat elementit on määritelty. Vain elementti meta on piilotettu ():

head {font-family:Verdana, sans-serif; display:block; background-color:aqua}
meta {display:none}
style {display:block; background-color:yellow}
title {display:block; background-color:yellow; border: 1px solid #660033}
body {font-family:Verdana, sans-serif; display:block}
h2 {font-size:21px; display:block; text-align:center;}
p {display:block; margin-top:1em;}

Nyt selain muotoilee dokumentin! Huomaa, että elementille P tulee määritellä sen marginaalit - muuten elementit ovat perä perää. Vasta tuon määrittelyn jälkeen sivu alkaa muistuttamaan HTML-dokumentteja! Määriteltyjen elementtien aloitus- ja päätöskoodit muuntuvat CSS:n avulla muotoilukoodeiksi. Todellisuudessa esimerkkidokumentti sisältää enemmän elementtejä kuin tuossa CSS-tiedostossa on kuvattu. Täysin määrittelemättömät elementit eivät vaikuta millään lailla dokumentin esitysasuun. Dokumentin esitysasusta puuttuu mm. elementin b määrittely.

Koska XML ei ole muotoilukieli, XML-elementit eivät itsessään jakaannu lohko- eikä rivinsisäiselementteihin (block level elements - in-line elements) - niiden olemassaolo määräytyy apukielistä käsin or DTD-tiedostoilla. XML:n näkökulmasta ei ole väärin laittaa lohkoelementiksi CSS:n avulla kuvattua elementtiä rivinsisäiselementin sisälle. Kun sivujen ulkoasu määritellään CSS:n avulla, sivujen tekijä joutuu itse vastaamaan oikeasta elementtien sijoittelusta. Elementtien sisäkkäisten suhteiden toimivuutta ei voi tarkastaa millään validaattoriohjelmalla, mikäli DTD-tiedostoa ei ole määritelty. Väärä sijoittelu saattaa johtaa siihen, että sivu muotoutuu epämääräisesti.

Toinen esimerkki. Otetaan esimerkiksi tiedosto, jolla on pääte xml ja sen sisällä on koodi:

<table>
   <tr>
      <td>tekstiä</td>
      <td>tekstiä</td>
   </tr>
</table>


MS IE 5.0 -selain joko näyttää tuon juuri tuon tapaisena, jos dokumentin elementeiltä puuttuu kuvaus. Yksikään noista koodeista ei toimi ilman kuvausta muotoilukoodina. XML:ssä tuo koodisarja on vain sarja tietyn nimisiä elementtejä ja on aivan sama vaikka niiden tilalla lukisi näin:

<taulukko>
   <taulukkorivi>
      <taulukkosolu>tekstiä</taulukkosolu>
      <taulukkosolu>tekstiä</taulukkosolu>
   </taulukkorivi>
</taulukko>


Voit periaatteessa määritellä CSS:n avulla, että elementti taulukko muotoillaan kuten HTML-elementti TABLE jne. Tosin muotoilu onnistuu vain Opera 4.x+ ja Netscape 6.x+ -selaimilla. MS IE 5.0 ei kykene muotoilemaan tuosta CSS:n avulla taulukkoa. Samoin em. selain ei pysty luomaan CSS:n avulla listaelementtejä (ks. sivu Muotoilut).

Mikäli XML-dokumenteissa halutaan käyttää taulukko- tai listamuotoisia esityksiä, MS IE 5.0 -selaimelle dokumentin muotoilu ja elementtien esitysasu täytyy toteuttaa XSL kielen avulla. Käytännössä loppudokumentti täytyy olla XHTML-dokumentti, jossa voi olla muiden XML-pohjaisten kielten elementtejä.

Linkitys ja muut XML-piirteet

Netscape 6.0 tukee jossakin määrin XLink-kieltä, joten sille saa toimivan linkityksen. Opera käyttää selainkohtaisia CSS-ominaisuuksia, joten linkityksen suhteen se ei ole kunnon XML-selain.

MS IE 5.5:lle saa linkityksen xmlns-attribuutin kautta. MS IE 5.5 tukee DTD-tiedostoja, joten tässä mielessä se on todellinen XML-selain. Opera ja Mozilla 0.7 eivät reagoi DTD-tiedoston virheisiin, joten ne eivät niitä lue. IE 5.5 tukee myös ns. skeemoja, joten kaikki piirteet huomioon ottaen sitä voi pitää kehittyneimpänä XML-selaimena.

Mikään selain ei tosin ole ihan kunnollinen, sillä edes jossakin määrin kunnon XML-toteutus edellyttäisi:

1. Opera 4.x+:n tasoinen display-ominaisuuden toteutus ja yleisten attribuuttivalitsimien tukeminen.
2. MS IE:n tasoinen DTD ja/tai skeema-tuki.
3. Mozillan tasoinen XLink-toteutus.

Huomautus 1. XSL-tuki ei ole välttämätön selaimelle, sillä XSL:ää on mielekästä käyttää vain serveripuolella. Tosin mikäli selain eli käyttäjäsovellus (UA) sitä tukee, systeemien testaus helpottuu. CSS on paljon tärkeämpi UA-puolella.

Huomautus 2. On muistettava, että eräät seikat ovat vielä keskeneräisiä, jolloin ne voivat muuttua. Tällöin selain voi tukea niitä viralliseen spesifikaatioon nähden epästandardilla tavalla. Tällä hetkellä on aivan mahdotonta, että olisi olemassa täysin XML-tason selain. Tosiasiassa selaimet ovat Working Draft -tasolla.

W3C: XML Linking Language (XLink), XSL Transformations Version 1.0 (XSLT), Schema Modules.
Muut sivut: CSS notes 2.
Muut sivustot: Opera Software: Web specifications supported in Opera 5 - the details; Microsoft: XML Schema Refere.

L Mikä on XML:n ja XSL:n nykytilanne

Aiheet

• Yleistä
• MS IE 5.x
• InDelv
• HTML-Kit
• Muita sovelluksia
• Testisivuja

Yleistä

XSL:n nykytilanne on parantumassa. Se pitää jakaa kahteen osaan, muunnoskieleen ja varsinaiseen tyylikieleen.

Jos ajatellaan XSLT (eXtensibe Style Sheet Language Transformation) kielen perusolemusta, se ei ole varsinaisessa mielessä tyylisivukieli. Se on pikemminkin yleinen muunnoskieli (XTL eli eXtensible Transformation Language), jolla toki voi generoida tai muuntaa tyyleihin liittyviä elementtejä ja attribuutteja.

Sitä voi käyttää myös XML-muunnoksissa, joissa ei ole mitään tekemistä tyylien kanssa. Muunnokset voi useimmissa tapauksissa hoitaa serveripuolella muilla muutoksia toteuttavilla kielillä, vaikka muunnoskielenä XSLT on sangen selkeä. Olemuksensa vuoksi kieltä pitäisi käyttää mielestäni vain serveripuolella, sillä sen käyttö selaimessa muuttaa selaimen eräänlaiseksi palvelinohjelmaksi.

XSLT ei määrittele ainuttakaan tyyleihin liittyvää elementtien käyttäytymistapaa. XSLT:tä käytettäessä tyylin määrittelevät lopputuloksen elementit, attribuutit ja dokumentissa mahdollisesti käytetty CSS.

Varsinaisena tyylikielenä XSL:ssä on XSL-fo (fo = formatting objects = muotoiluobjektit). Toisin kuin CSS:ssä lopullisessa dokumentissa esitysasua, sisältöä ja rakennetta ei eroteta toisistaan. Tässä mielessä sen käyttäminen on tavallaan paluuta HTML 3.2 -tyyppiseen ajatteluun.

Jos XSL-fo dokumentti luodaan käsin, se merkitsee rakasta koodausta. Sitä ei ole kuitenkaan tarkoitettu toimimaan sellaisenaan vaan osana erilaisissa muunnoksissa yhdessä XSLT:n kanssa: XML > XLST > XSL-fo > PDF/RTF/TEX/DVI tai jokin muu dokumenttityyppi, joka tarvitsee ns. rivinsisäisiä sisäisiä tyylejä (inline styles). XSL-fo ei sovellu XHTML-dokumenttien tyylikieleksi.

Vaikka XSL-fo kieltä voidaan käyttää osana erilaisissa muunnoksissa, mielestäni muutoksetkin voitaisiin hoitaa toisella tavalla. Lue kommenttini sivulta Cascading Style Sheets with Transformation.

W3C on tehnyt vuoden 1999 lopussa XSLT ja XPath suositukset eli spesifikaatiot. W3C suosittaa CSS:n käyttämistä silloin kuin mahdollista ja XSL:n käyttämistä vain silloin kun on pakko. CSS on tarkoitettu myös WAP-laitteisiin, mutta niissä ei ole sille vielä tukea. XSL olisi järkevä sellaisissa tapauksissa, että sama dokumentti lähetettäisiin tietokoneille ja WAP-laitteille serverin tekeminä XSL:n avulla toteutettuina muunnoksina. Spesifikaatioiden ja ohjelmien puutteellisuuden vuoksi tämäkin on kyseenalaista.

MS IE 5.x

Vaikka XSLT-kieli kuuluu yksinomaan palvelinpuolelle, mutta jos sitä tuetaan, se tulee toteuttaa spesifikaation mukaan. MS IE 5.0 tukee vanhentunutta (vuodelta 1998) olevaa XSL-ehdotelmaa, jonka pahimmat puutteet ovat seuraavat:

• Ei ole kunnon linkitystä
• Ei ole kunnon lajittelua (xml:sort ei toimi ja sen sijaan MS IE käyttää ordered-by attribuuttia, jota ei enää löydy uusista spesifikaatioehdotelmista)

MS IE:lle tehty XSL on todella kyseenalaista, sillä se on epästandardia. XML-tuki on tuotu markkinoille liian keskeneräisenä.

Testatessani InDelv-ohjelmalla tehtyä sivuja, MS IE näytti vain valkoisen taustavärin. Microsoftin yleinen toimintaperiaate näyttää olevan tuoda markkinoille aina uusia keskeneräisiä systeemejä ennen kuin entisetkään toimivat kunnolla.

Ongelmana on se, että ns. "official" versioon liitetään kokeilun alla olevia piirteitä, joita ei kuitenkaan voida päivittää riittävän usein. Tämä pilaa uusien järjestelmien toimivuutta ja uskottavuutta. Keskeneräisistä systeemeistä pitäisi tämän vuoksi olla erillisiä kokeellisia (experimental) versioita, joita päivitetään säännöllisesti. Lue tähän asiaan liittyvä valituslauluni.

MS IE 5.5:stä lähtien MS IE -selaimissa pitäisi olla spesifikaation mukainen toteutus. Aikaisemman version vanhentunut ja spesifikaation mukainen toteutus vaatii konversion.

InDelv

Latasin kyseisen nimisen kanadalaisen InDelv-ohjelman, jossa on mukana sekä selain että editori. Ohjelma tukee uusinta 1999 ehdotelmaa, joka on siis lähes lopullinen. Selaimessa on ajan tasalla olevat ohjeet. Samat ohjeet tosin löytää myös uusimmista W3C spesifikaatioehdotuksista. Ohjelmasta saa koeversion.

Melkein täydellinen XLink ja XPointer toteutus. Tukee muotoiluolioita formatting objects (fo).

Ohjelma kaatui MS:lle tehdyistä XSL-tiedostoista. Joistakin se näytti vain tekstin mutta ei muotoilua. MS IE 5.0:lle tekemistäni XSL-tiedostoista se ei näyttänyt mitään.

Varoitus. Mikäli sinulla on ennestään Java 1.x virtual machine asennettuna, poista alihakemisto /jre InDelv-hakemistosta. Ohjelma kaatuu, mikäli se löytää kaksi Java-tuki tiedostoa.

Ohjelma näyttää HTML-dokumentit puutteellisesti. Sen XSL-tiedostoissa on seuraavia yleisiä erilaisuuksia tai ongelmia suhteessa MS 5.0:aan:

1. InDelv nimiavaruustiedot ennakoivat standardia:

   <xsl:stylesheet xmlns:xsl='http://www.w3.org/XSL/Transform/1.0' xmlns:fo='http://www.w3.org/XSL/Format/1.0' result-ns='fo'>

   MS viittaa vanhentumassa oleviin tietoihin:

   <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns:fo='http://www.w3.org/XSL/Format/1.0' result-ns='fo'>

2. Text() InDelvin mukaan väärin käytetty MS:n tavoin. Ohjelma ei tarvitse sitä. Todennäköisesti vika MS IE:n.
3. MS IE sekoilee joistakin fo-object-määrittelyistä, vaikka se ei niitä ymmärrä (esim. elementti P). Vika MS IE:n.
4. InDelv ei toteuta kunnolla XSLT-piirteitä. Esim. elementti P ei toimi näin:

   <xsl:template match="p">
<p style="display:block; margin:10pt; width:100%">
<xsl:apply-templates />
</xsl:template>

5. Fo-XSL:lle ei ole määritelty riittävästi ominaisuuksia (poikkeavat jostakin syystä CSS:n ominaisuuksista - mikähän vitsi siinäkin on, että samat ominaisuudet kirjoitetaan joskus eri lailla?).

HTML-Kit

HTML-kit -ohjelmaan on mahdollista rakentaa omia valikoita. Siihen saa mm. XSL(T)-valikon, mutta se perustuu vanhentuneeseen W3C XSLT spesifikaatioehdotukseen vuodelta 1998 (virallinen W3C:n suositus on marraskuulta 1999). Se on tarkoitettu vain MS IE 5.0 varten, sillä siinä on useita sovelluskohtaisia ominaisuuksia, jotka eivät toimi muissa kuin em. selaimessa. En suosittele sen lataamista. Tein paremman valikon. Se on saatavissa zip-tiedostona. Jotta voit muokata sitä helposti, lataa HTMK-Kit -ohjelman sivuilta myös Plugins Generator.

Sille on olemassa tekemäni CSS-valikko. Saat sen zip-tiedostona (sinun täytyy ehdottomasti lukea ensin README_NOW.txt tiedosto). Se löytyy myös HTML-kitin sivuilta (sieltä saa myös lähdekoodin)

Muita sovelluksia

Myös eräitä muita on saatavissa ja muutamia kommentteja:

• Koala - yli vuoden vanha. Lisäksi vaikeakäyttöinen. Ei minusta mielekästä käyttää.
• Saxon, jonka pitäisi tukea uusimpia suosituksia. Täten erittäin suositeltava ohjelma.

Testisivuja

Tein eräästä sivusta useita versioita, joiden pitäisi näyttää suurin piirtein samanlaisilta:

• HTML-versio - MS IE 5.0 näyttää eräässä kohdin sinisen reunuksen, mutta ei sen keskellä listaelementtejä, mutta muu muotoilu toimii.
• XML + CSS -versio - MS IE 5.0 pystyy luomaan dokumentille vain sangen vaatimattoman struktuurin (yksikään listakuva ei näy); kuvaa lukuun ottamatta tiedoston rakenne pitäisi olla HTML-version kaltainen). Mozilla 0.6 (Netscape 6.0) ja Opera 4.x tai uudemmat näyttävät tämän sivun melko oikein.
• XML + XSL(T) + CSS -versio - MS IE 5.0 pystyy luomaan vain XSL:n avulla XML-dokumenteille kunnon rakenteen ja esitystavan. Linkitys ei tosin toimi ja MS IE 5.0 tukee epästandardia XSL:ää. Monet selaimet tekevät ei-tuetusta XML:stä kauniin puumaisen rakenteen. Opera sen sijaan panee kaiken yhteen pötköön. Puurakenetta ei tietenkään edellytetä, mutta onhan se hauska olla olemassa.
• Jonkinlainen InDelv-ohjelmalla toimiva XSL-fo -versio - ongelmia on vielä jäljellä, mutta toimii jollakin lailla InDelv XML-sovelluksella; linkitys toimii, mutta esitysasussa on puutteita.
• Kuva siitä, miten selaimen tulisi näyttää sivua - saat kuvasta käsityksen myös siitä, mitä MS IE 5.0 ei pysty CSS:n avulla näyttämään.

Kokonaisuutta ajatellen toimivuus on paljon pahempi kuin CSS:n kohdalla.

M Millaisia ongelmia WAPpiin liittyy

Aiheet

• Yleistä
• Mediatyypin handheld ongelma
• Linkkikuvat
• Skriptit

Yleistä

Sivujen saattamiseksi toimimimaa WAP-laitteissa (Wireless Access Protocol) CSS:n kanssa on kaksi vaihtoehtoa. Ensimmäinen ja paras vaihtoehto on se, että selaimella on kunnollinen CSS- toteutus. Toinen vaihtoehto on se, että WAP-palvelin ymmärtää CSS:ää. WAP-selain voisi lukea ensiksi seuraavan osan sivua:

<LINK rel="stylesheet" media="handheld" href="handheld.css">
<LINK rel="stylesheet" media="print" href="print.css">
<LINK rel="stylesheet" media="screen" href="screen.css">

Nuo tiedostot sisältävät ilmoitukset, kuinka sivuja pitäisi käsitellä kännykkätietokoneyhdistelmissä, palm pilot ja muissa pienissä laitteissa sekä tietokoneruudulla. WAP-palvelin voisi pitää tiedostot muistissa ja niiden perusteella tulostaa sivun (media="print" kontrolloisi tulostusprosessia.

Olen kuullut, että WAP-palvelin poistaa isoja kuvia. Tämä prosessi on kuitenkin sivujen tekijän kontrollin ulottumattomissa. Jos palvelin voisi ymmärtää CSS:ää, sivujen tekijä ja palvelin voisivat kontrolloida sivujen esitysasua. Samat sivut voisi tehdä sekä WAP-laitteille että tavanomaisille tietokonenäytöille siten, että sivujen tekijä aina tietäisi miltä ne eri laitteissa näkyvät.

Mediatyypin tunnistus on kaiken perusta. Koska CSS2 ottaa huomioon CSS2 WAP-laitteet, olisi hyvin suotavaa, jos WAP-palvelimet voisivat tukea CSS2-teknologiaa.

Media tyypit

Mediatyyppi handheld on ongelmallinen, koska pienlaitteiden kyky käsitellä grafiikkaa on rajallinen (katso taulukko sivulta6 ja sen jälkeen oleva lyhyt selitys).

Mediatyyppiä tty ei voi käyttää, sillä se on tarkoitettu kaiken tekstinä näyttäville selaimille. Pitäisikö olla erityinen mediatyyppi mobile_phones? Tällöin tyyppi handheld koskisi vain vain palm pilot ja ja muita pieniä käsissä pidettäviä pientietokoneita.

Linkkikuvat

Kuviin perustuvat linkityssysteemit ovat ongelmallisia. Kuvia ei pitäisi käyttää linkkielementtejä. Kuvien tulisi olla kuvia ja linkkien linkkejä. Erityisen ongelmallisia ovat ns. kuvakartat. Kuvakarttasysteemit pitäisi tehdä seuraavasti tai ne tulisi voida korvata CSS:ään perustuvalla systeemillä:/p>

• Linkitys on piilotettu, jos selain käyttää mediatyyppiä handheld tai tty käyttämällä CSS-ominaisuutta display:none (katso lähemmin sen käyttämisestä sivulta 11).
• Niiden sijasta voisi käyttää kerrostettuja taustakuvia. Elementin sisällä, jolla on tausta on laitettu taulukon sisään. Taulukossa on oikeaan paikkaan vievät linkit. Taulukolla on toisen tason taustakuvat. Pohjaelementillä ja taulukolla on tietty luokka. Sitten koko systeemin voisi esittää aivan eri näköisenä kämmenlaitteissa. Suurten kuvien sijasta voitaisiin käyttää pieniä kuvia.

Tällä tavalla olisi helpompaa ja joustavampaa luoda linkityssysteemejä kuin kuvakarttoja käyttäen. Tosin linkit olisivat aina suorakaiteen muotoisia. Vanhempien selainten käyttäjät eivät näkisi kuvia lainkaan. Ei ole mitenkään mahdollista määritellä vaihtoehtoisia HTML 3.2 tasoisia taustakuvia kaikille elementeille. Tämä ei ole kuitenkaan mikään perustavalaatuinen kysymys, sillä useimmat selaimet tukevat CSS:ää.

Jos samoja sivuja käytetään kämmenlaitteissa ja isoilla tietokoneruuduilla mielestäni kuvakarttoja ei pitäisi käyttää lainkaan. Suosittelen niiden sijasta muita ratkaisuja. Kuvalinkeillä tulisi aina olla vaihtoehtoinen tekstilinkki. Ne voitaisiin kätkeä versiossa (media="screen"), joka on tarkoitettu normaaleille tietokoneille. Selaimet, jotka eivät CSS:ää ymmärrä näyttäisivät ne. Siksi myös vaihtoehtoisten linkkien tulisi näyttää sangen hyviltä.

Skriptit

Monien mielestä epämiellyttävin piirre voi olla se, että monet skriptit ovat harmillisia. Optimaalinen ratkaisu voisi olla se, että niitä ei käytetä lainkaan. Skriptejä voitaisiin käyttää siten, että ne voisivat olla eri laitteille erilaisia. Olen tehnyt ehdotelman, että mediasääntö koski myös skriptejä.

Monet skriptit ovat hyödyllisiä, mutta toiset täysin turhanaikaisia. Kuvienvaihtoskripteistä on helppo luopua. Minulla oli kerran navigointikehyksissä noin 150 linkkiä. Ne käyttivät seuraavan kaltaista CSS:ää:

:link {...}
:visited {...}
.joku_class a:hover {...}
.joku_class a:active {...}
.joku_class a:focus {...}
.joku_class a:hover img {...}
.joku_class a:active img {...}
.joku_class a:focus img {...}

..., .some_border a:hover, ... {display:block;margin-right:1px;text-decoration: none}

Jos olisin korvannut navigaatioelementtien kuvat neljällä skriptien tapahtumakäsittelijöihin liittyvillä kuvilla olisin tarvinnut 600 kuvaa. Yleisenä tapana on käyttää vain kahta tapahtumaa (OnMouseOver / onMouseOut). Tällöin kuvien minimimäärä olisi ollut n. 300 kuvaa. Maksimimäärä olisi ollut The 750 kuvaa (viisi eri tapahtumankäsittelijää). Nämä kuvat olisivat mahdollisesti vieneet noin megatavun (1 MB) verran kovalevytilaa. CSS:n kanssa tarvitisin vain muutama kilobitin (Kb). Verrattuna suureen kuvamäärään se melkein ei mitään.

Ja jos halaisin tehdä pieniä muutoksia vain pienet muutokset CSS-koodissa riittäisivät. On erittäin helppo muuttaa rajattoman määrän linkkejä muutamassa minuutissa. 300-750 kuvan tekeminen veisi paljon aikaa. Lisäetuna on se, että CSS ei aiheuta harmia sivujen käytettävyydelle pienissä laitteissa.

CSS säästää hyvin paljon graafista työtä! On mahdollista luoda halvalla sivuja tavanomaisille tietokoneille ja kämmenlaitteille. Graafikot voisivat luoda linkeille ja niiden emoelementeille muutamia taustoja. He voisivat myös luoda taustoja koko sivulle ja tehdä muutamia peruskuvia. Töitä olisi kuitenkin paljon vähemmän verrattuna HTML 3.2 -tasoiseen suunnitteluun.

Tämä tarvitsee kuitenkin asennemuutosta, sillä vanhimpien selainten käyttäjät kärsisivät. Mutta nopeudessa kaikki voittaisivat. Kaikki saisivat vähemmän kuvia ja vähemmän epävarmasti toimivia skriptejä. Jos lopputulos ei käytetyllä selaimella tyydytä internetistä saa ilmaiseksi paremman selaimen.

Kuvienvaihdon korvaava CSS2-systeemi toimii nykyisin vain MS IE and Mozilla Gecko -selaimissa. Opera selaimissa, jotka ovat vanhempia kuin Opera 7.0 Beta 2 toimii vain taustavärit, mutta taustakuvat eivät vaihdu ns. dynaamisia näennäisluokkia käyttäen.

N Millaisia CSS-totetusvirheitä selaimissa on

Aiheet

Tämä sivu on jaettu jaksoihin, jotka sisältävät seuraavia aiheita:

• Yleistä (introjakso)
• Selainkohtaisia seikkoja (jakso 1)
  • Microsoft Internet Explorer
  • Netscape Navigator
  • Opera
  • Muutamia demonstraatioita joistakin selainten puutteista
• Vanhimpien selainten CSS-virheitä (jakso 2)
  • Havaitsemani virheet
  • Netscape 4.04:n virheet
  • W3C:n virheellisiä testisivuja
  • MS IE:n virheet
  • Opera-selainten virheitä
  • Netscape 6.0:n virheitä
  • Virheiden ohituskeinoja

Yleistä

Selaimet tekevät virheitä ja niistä puuttuu ominaisuuksia. En tässä yhteydessä käy lävitse yksityiskohtaisesti selainten virheistä. Voit lukea myös toisen sivun, joka käsittelee selainten virheitä.

Olennaista on myös itse välttää virheitä. MS IE 4.x-5.5 Windows sallii melko paljon virheellisiä määreitä. Tämä on ongelmallista, sillä toiset selaimet eivät niitä samassa määrin salli. Ylipäätänsä tulevaisuuden selaimet sallivat aikaisempaa vähemmän virheitä. CSS-määrittelyt kannattaa tarkistuttaa W3C organisaation koodintarkastusohjelmalla (validator).

Vaikka kaikki uudet selaimet eivät juuri hyväksy virheitä jopa selaimet, joiden tulisi toimia tietyillä DTD:llä ns. standard(-compliant) -moodissa tiukasti spesifikaatioiden mukaisesti, hyväksyvät epäkelpoa/ selaimelle tuntematonta CSS:ää (jos ne eivät toimi standard(-compliant) -moodissa ne hyväksyvät enemmän virheitä). Näillä selaimilla on ns. "DTD-kytkin". Olen havainnut seuraavia virheitä epäkelvon tai tuntemattoman CSS:n hyväksymisessä:

• Netscape 6.2.1 hyväksyy #-abc {...} ja #-abc {...}.
• MS IE 6.0 Windows ei tue position:fixed, mutta se tunnistaa sen ja muuttaa arvon fixed arvoksi static. Jos selain ei tue jotain arvoa, sen tulisi käsitellä sitä ikään kuin laittomana arvona eikä asettaa tilalle oletusarvoa. MS IE 6.0 hylkää kuitenkin position:fixes, mikä osoittaa, että epäkelpojen arvojen hylkääminen osittain toimii.
• MS IE 6.0 Windows ei tue arvoa inherit, mutta se asettaa joissakin tilanteissa sen tilalle oletusarvon. MS IE saattaa vaihtaa myös kokonaan epäkelvon arvon oletusarvoon. Alla olevissa tapauksissa se vaihtaa kokonaan epäkelvon arvon inherits oletusarvoon none vaikka sen tulisi vain hylätä jälkimmäinen ominaisuus:

  MS IE 6.0 windows lukee sekä
  <div style="border: 3px solid green">ulompi<div style="border: 3px double blue; border-bottom-style:inherits;">sisempi</div>ulompi</div>
  että
  <div style="border: 3px solid green">ulompi<div style="border: 3px double blue; border-bottom-style:inherit;">sisempi</div>ulompi</div>
  ikään kuin
  <div style="border: 3px solid green">ulompi<div style="border: 3px double blue; border-bottom-style:none;">sisempi</div>ulompi</div>

Opera 7.x -selaimissa on MS IE:tä suppea-alaisempi kytkin ja vanhemmista kytkin puuttuu kokonaan. Siksi Opera-selainten täytyy tehdä joitakin kompromisseja, koska Web-suunnittelijoilla on pahoja tapoja suosia epäkelpoa CSS:ää erityisesti JavaScript-koodauksissa. Opera hyväksyy ainakin seuraavat virheet (mainitsen myös sen, voisiko Opera Software mielestäni muuttaa selaimen käytöstä):

• Opera 6.0 hyväksyy #-abc {...}. Opera Software voisi muuttaa tässä kohdin selaimen käytöstä.
• Opera 6.0 hyväksyy yksiköttömiä arvoja, esim. position:absolute; top:10; left: 10. Operan täytyy hyväksyä näitä koska ne ovat niin yleisiä. Jotta Opera voisi toimia edes joskus 100% CSS2-spesifikaation mukaan, selain tarvitsisi tässä kohdin DTD-kytkimen (toinen asia, jossa Opera tarvitsisi DTD-kytkintä on fonttikoot xx-small-xx-large; ks. Model8c.html).
• Opera 6.0 saattaa vaihtaa epäkelvon arvon oletusarvoon seuraavankaltaisissa tilanteissa: border:1p solid black. Opera hylkää kuitenkin border:some solid black, mikä osoittaa että lukuun ottamatta epäkelpojen yksiköiden vaihtamista oletusarvoihin, epäkelvon CSS:n hylkääminen toimii yleisesti ottaen sangen hyvin. Opera Software voisi muuttaa tässä kohdin selaimen käytöstä. Se voisi tarvita tälle asialle DTD-kytkimen.

tyylisivut ja niiden säännöt tulisi organisoida erittäin systemaattisesti. Itselläni on ollut ongelmia, koska sivuni eivät alunperin niitä käyttäneet. organisointi on vähän niin ja näin, mistä johtuu toisinaan seuraavia ongelmia.:

• Pienet kirjoitusvirheet ovat vaikea löytää ja niillä voi olla iso merkitys.
• Yksi muutos voi vaikuttaa moneen paikkaan - eikä aina tajua, mihin kaikkeen se vaikuttaa.
• Vaikuttavien arvojen löytyminen voi olla vaikeaa.

Vihje. Tee kaikista käyttämistäsi CSS-tiedostoista index.css, jolloin voit tarkistaa ne kaikki kerralla! Katso malliksi testi CSS-tiedostoni lähdekoodi tekstitiedostona.

Aiemmilla sivuilla olen tuonut esille toimivia ratkaisuja ja englanninkielisellä sivullani niitä on lisää: Illegal definitions and hints to avoid problems.

Löydät tarkemman tiedon selainten virheistä Webstandards organisaation sivuilta. He antavat mm. ns. "Top ten" -listan selainten virheistä. Erään dokumentaation selainten CSS1-toteutus virheistä löydät Webreview-firman sivuilta.

Selainkohtaisia seikkoja

Microsoft Internet Explorer

Arvioitsen MS IE 5.x -selaimet CSS2-tason mukaisesti, vaikka se ei edes lupaa täyttä tukea kaikille CSS2 tason ominaisuuksille. Yleisesti ottaen MS IE 5.x -selaimissa on vain keskinkertainen CSS-tuki ja selain on ollut minulle tässä suhteessa pettymys. Vain osa MS IE 4.01 olleista selkeistä CSS1 -tason virheistä on korjattu. Selaimista myös puuttuu tärkeitä CSS2-tason piirteitä. Ylipäätänsä siis CSS-tuen tason on vain osittainen.

Suurin ongelma on se, että Windows-selaimissa on perustavalaatuisia CSS-toteutusvirheitä (lue sivulta Miten CSS annetaan elementtien taustoille ja reunoille).

Microsoft on kuitenkin tehnyt merkittäviä parannuksia 6.0-sarjaan (myös MS IE 5.0 Mac on hyvä selain). Selain toimii tietyillä DTD:llä tuettujen ominaisuuksien osalta hyvin pitkälle olemassa olevia standardeja noudattaen. Tarkempi analyysi virheistä ja korjauksista on erillissivulla.

Netscape Navigator

Netscape 4.0x -selaimissa on todella ikävän huono CSS-tuki - se on yksinkertaisesti kamalan huono selain tässä suhteessa (lue vihjeeni, miten Netscape 4.x -selaimen kanssa voi pärjätä). Netscape 6.x+ -selaimissa on sangen hyvä CSS-toteutus! Selainten ydin on Mozilla Gecko esityskone (rendering engine) ja ytimeltään samoja selaimia saa eri nimillä (kuten esim. Mozilla, Galeon ja Phoenix). Mozilla Gecko -selaimissa on lähes virheetön CSS1-tason ominaisuuksien käsittely ja sangen laaja CSS2-tuki. Dynaamisen näennäisluokan :hover toteutus voi kuitenkin tuottaa web-dokumenttien tuottajille ongelmia, sillä Mozilla Gecko -selaimet (kuten myös uusimmat Opera-selaimet) toteuttavat sen laajemmin kuin monet muut selaimet (lue englanninkielinen kommentti sivulta CSS notes 1).

Opera

Opera 5.02:ssa on sangen hyvin toimiva CSS2-tuki ja se toistaa kaikki CSS1-piirteet (Opera 4.02:sta puuttuu on :visited tukeminen). Opera antaa uskoa CSS:n toimivuuteen. Operan CSS-toteutuksessa ei ole lainkaan vakavia virheitä.

Uudemmat versiot toteuttavat enemmän CSS2:een liittyviä piirteitä, mutta standardien noudattamisen tarkkuudessa on pieniä puutteita. Joissakin suhteissa vanhemmat selaimet noudattavat paremmin speksejä kuin uudemmat. Spesifikaatioiden noudattamisen taso on kuitenkin yleisesti ottaen sangen hyvä.

Muutamia demonstraatioita joistakin selainten puutteista

Seuraavassa on pieni listaelementtitesti, jossa olen merkinnyt käytetyt tunnistettavat hahmot (matching patterns) ja valitsimet (selectors; nimien merkitys on selitetty sivulla Mikä on CSS:n prosessointijärjestys. Testi selvittää myös osaako selain CSS2 tasoisesti määritellyn porrastetun valintajärjestyksen (cascading order). Niistä selaimista, joita olen testaillu vain Mozilla Gecko ja Opera 7.x+ -selaimet ovat selvittäneet testin virheettä (on mahdollista, että myös Safari ja Konqueror-selaimet selviäisivät yhtä hyvin):

• UL LI: Tämän listaelementin pitäisi olla oranssin värinen (pallo.gif; ).
  1. UL LI OL>LI: Tämän listaelementin pitäisi olla decimal eli numero 1. Mikäli se ei ole, selain ei tue first-child -valitsinta.
  2. Toinen first-child -tason listaelementti - tässä pitäisi olla numero 2.
     • UL LI OL UL LI:first-child: Tämän listaelementin pitäisi olla upper-roman eli kirjain I. Valinta koskee vain listan ensimmäistä elementtiä, sillä mukana on :first-child näennäisluokkavalitsin. Mikäli kyseistä lisävalitsinta ei olisi, tässä pitäisi olla lower-alpha eli kirjain a yleisemmän säännön UL LI OL UL LI perusteella.
     • UL LI OL UL LI: Tämän listaelementin pitäisi olla lower-alpha eli kirjain b.
  • UL LI OL+UL LI : Tämän listaelementin pitäisi olla punainen (pallo-punainen.gif; ). Mikäli se ei ole, selain ei tue täysin adjacent sibling -valitsinta (määrittelyn kommentti.
    • .CssSite UL LI UL LI LI: Tämän listaelementin pitäisi olla kuva smile.gif (). Mikäli se ei ole, selain ei ymmärrä luokka-tarkennettuja tunnistettavia hahmoja.
  1. [class="test"]: Tämän listaelementin pitäisi olla kuva ok.gif (), koska on käytetty täsmällistä attribuuttivalitsinta. Mikäli se on jokin muu, selain ei ymmärrä attribuuttivalitsimia.
  2. #test: Tämän listaelementin pitäisi olla kuva plane.gif (), koska on käytetty id-valitsinta (id selector), joka ohittaa kaikki tunnistettavat hahmot.
  3. body [id="test2"] ja #test2: Myös tämän listaelementin pitäisi olla kuva plane.gif (), koska on id-valitsin ohittaa myös sellaiset attribuuttivalitsimiin perustuvat tunnistettavat hahmot, jotka viittaavat samaan kohtaan kuin id-valitsin. Tunnistettava hahmo antaisi tähän kohtaan kuvan ok.gif ().

Tälle kappaleelle on määritelty rivinsisäinen tyyli ja näiden sanojen ympärillä pitäisi olla reunukset. Mikäli näin ei ole, selain ei tue kunnolla rivinsisäisiä elementtejä. Jos MS IE -selainta yrittää "huiputtaa" antamalla lohkoelementeille kuuluvan ominaisuuden, lopputulos on ikävän näköinen. Reunustettu teksti ei pysy samalla korkeudella muuhun tekstiin nähden - kuten saatat havaita! Lohko-ominaisuuden lisääminen muuttaa tekstin toisinaan lähes normaalisti käyttäytyväksi lohkoelementiksi. Selain yrittää pitää tällöin tekstin aina yhtämittaisena. Mahdollisen rivikatkon sattuessa ei salli samalle riville muuta tekstiä. Käytös on siten toisinaan yleisten rivinsisäis- ja toisinaan lohkoelementtien (DIV ja SPAN) kaltainen - aina kuitenkin virheellinen. Erään s-postin mukaan MS IE käsittelee rivinsisäiselementtejä eräänlaisina erityislohkoina, mikä selittää tuota virhekäytöstä. MS pyrkii versiossa 6.0 korjaamaan asian. Seuraavassa jaksossa on aiemmin tekemäni sivu, jossa käsittelen hieman vanhempia selaimia.

W3C: CSS validator.
Muita sivustoja: Webstandards ; Webreview: CSS1 Master Compatibility Chart, CSS2 Selectors Support Chart; CSS Enhancements in Internet Explorer 6 Public Preview.

O Millaisia CSS-totetusvirheitä on MS IE -selaimissa

Aiheet

• Yleistä
• MS IE 4.x Windows
• MS IE 5.5 Windows
  • Mokia ja puuttuvia piirteitä
  • Epästandardi CSS
• MS IE 6.0+ Windows
• MS IE 5.0+ Mac
• Ohitukset

Yleistä

Erittäin hyödyllinen sovellus MS IE -selainten CSS-tuen tutkimiseen on Bradsofttin TopStyle (Lite-versio on ilmainen), joka listaa kaikki MS IE -selaimissa toteutetut CSS-ominaisuudet ja niiden arvot. Tosi mikään testaamani versiot ei mainitse at-sääntöjä kuten esim. @font-face. Sovellus antaa paljon toteutuksiin liittyviä vihjeitä.

En käsittele MS IE 4.x Windows vanhempia MS IE -selaimia koska en voi asentaa tätä vanhempia versiota tietokoneeseeni. Windows 98 mukana tulee MS IE 4.x -selain (tarkka versionumero on 4.76). On aina olemassa ihmisiä, jotka eivät koskaan päivitä käyttäjärjestelmän mukana tulevia selaimia, minkä vuoksi sivujen tekijöiden on jollakin tasolla otettava huomioon vanhoja selaimia.

MS IE 4.x Windows

MS IE 4.x esittää tavanomaisen CSS:n suhteellisen hyviä ja siinä on useimmat MS IE 5.5 Windows -selaimessa esiin tulevat mokat (käsitten niitä edempänä). Selaimiin liittyy kuitenkin seuraavia huomionarvoisia erityisseikkoja:

1. Selaimet eivät tue @media at-sääntöä, mutta media attribuutti on tuettu.
2. Siinä on erittäin vakavia clear ja float ominaisuuksien toteutusvirheitä:
   • Selaimet toteuttavat float monesti niin, että ne sijoittavat kelluvat elementit omille riveilleen vaikka rivillä olisikin tilaa. Tästä seuraa turhia rivinvaihtoja.
   • Jos samalla rivillä on monia kelluvia elementtejä selain ei osaa jakaa niitä useille riveille.
   • clear aiheuttaa yksinäisiä kelluvia elementtejä vaikka selaimet voisivat periaatteessa pitää elementit samalla rivillä. Tästä aiheutuu ylimääräisiä rivivaihtoja.
   • Kelluvat elementit saattavat kasvattaa emoelementin korkeutta.
3. Virheellisten tunniste (id) ja luokkavalitsimen hyväksyminen eroaa uudemmista versioista (katso malli).
4. Ei tue pseudoelementtejä :first-letter ja :first-line (koskee myös MS IE 5.0 Windows).
5. Marginaalien kanssa käytettynä ominaisuus width toimii huonommin kuin uudemmissa versioissa.
6. display:block ole tuettu muute kuin vastakohtana display:none. Jos luonnostaan rivinsisäiselementteinä käyttäyvät elementit määritellään lohkoiksi, ne käyttäyvät aina rivinsisäiselementteinä.

Koska MS IE 5.0 Mac ei tue @media at-sääntöä vaan se ohittaa kaiken CSS:n, mikä on medialohkojen sisällä lisäämällä tuntemattoman mediatyypin voi luoda jaksoja, jotka vain MS IE 4.x lukee (esim. a test element):

@media MSIE401 {#testMSIE401 {color:red !important; text-decoration:none !important}}/* Tämä on tuntematon mediatyyppi ja tarkoitettu MS IE 4.x Windows -selaimille. Huomaa, että Opera 4.x+ tukee mediatyyppiä projection, joten älä käytä tät mediatyyppiä tähän tarkoitukseen. Jos tyylisivu käytää esimerkiksi mediatyypiä screen ja siihen lisätään mediatyyppi tty saadaan sama lopputulos. */

MS IE 5.5 Windows

Mokia ja puuttuvia piirteitä

Havaitsin MS IE 5.5:ssä seuraavia positiivisia seikkoja:

• Table-layout:fixed toimii hienosti. Se vähentää merkittävästi viiveaikaa ennen kuin mitään näkyy näytöllä.
• Selain tukee :first-letter ja :first-line näennäisluokkia.
• Rivinsisäiselementeille määriteltyihin reunuksiin liittyvät mokat on melkein korjattu. Sanoilla "Rivinsisäiselementeille määriteltyihin reunuksiin" on nätit reunukset. Tosin ominaisuus height aiheuttaa virhekäyttäytymisen kuten tapahtui vanhemmillakin versioilla (esimerkki).

MS IE:ssä on vakavia CSS1 toteutusvirheitä. BODY ja HTML määriteltyjen reunusten toteutus on virheellinen. Lohkoelementeille määriteltyjen dimensioiden laskeminen on vakasti virhellinen. Käsittelen näitä mokia sivulla Miten CSS annetaan elementtien taustoille ja reunoille).

Myös float ja clear ominaisuudet toimivat virheellisesti (koskee myös MS IE 6.0 Windows; MS IE 4.x for Windows on enemmän virheitä). Jos ominaisuutta clear on käytetty, MS IE saattaa muuttaa sisällössä edempänä olevat kelluvat elementit aiempien kelluvien elementtien yläpuolelle. Arvoilla left ja right ominaisuus float pitäisi siirtää elementti mahdollisimman ylös (kuitenkin niin, etteivät kelluvat elementit mene aiempien kelluvien elementtien yläpuolelle), mutta MS IE siirtää elementit usein hieman alaspäin. MS IE saattaa kopioida/siirtää osan kelluvan elementin sisältöä elementin ulkopuolelle. Mokista huolimatta ominaisuus float on käyttökelpoiinen. Seuraava kuvakaappaus osoittaa clear ja float ominaisuuksiin liittyviä ongelmia:

• Clear ja Opera 5.12 (Netscape 6.2 näyttää samalla tavalla).
• Clear and MS IE 6.0 (Mozilla 0.9 (Netscape 6.1 level) renders at the same way).
• Ominaisuuden float virhetoteutus MS IE 6.0:ssa.

CSS1-toteus oli pettymys, sillä oletin että MS IE 5.5 olisi selvinnyt W3C:n CSS1 Test Suite yhtä hyvin kuin Opera 4.x ja Netscape 6.0, jotka selvisivät testistä melkein virheettömästi (ainakin selkeästi paremmin kuin MS IE 5.5). MS IE 5.5 ei näyttänyt ainakaan seuraavia testisivuja virheettömästi:

• Selain hyväksyy virheellistä CSS:ää. Listaan nämä virheet toisessa listassa (kohdat 2-5) ja virheet koskevat seuraavia sivuja sec11, sec14, sec15 and sec71.
• Jotkut marginaali-, täyte- ja asemointiominaisuudet eivät toimi oikein: sec412, sec43, sec44.
• Jotkut elementille HTML annetut ominaisuudet eivät toimi: sec45.
• Arvo small-caps ei toimi oikein: sec524.
• Sanavälistys ei toimi: sec541.
• Osittainen display:list-item toteutus (lohkolaatikko on ok, mutta mutta neliön muotoinen listamerkki puuttuu): sec561.
• Osittainen white-space toteutus (white-space:pre ei toimi): sec562.

MS IE 5.5 pitäisi hylätä virheellinen CSS, mutta se hyväksyy seuraavan virheellisen CSS:n:

1. Hyväksyy virheellisiä ominaisuuksien arvoja:
   • MS IE esittää esim. seuraavan elementin ikään kuin sen reunukselle olisi määritelty arvo 1px (style="border: 1p solid #636"):
     reunustettu rivinsisäiselementti.
     CSS2.n perusteella sen tulisi hylätä virheellinen arvo 1p ja näyttää reunat oletusarvon perusteella eli MS IE:n pitäisi esittää reunat seuraavasti (border: medium solid #636):
     reunustettu rivinsisäiselementti.
   • Se hyväksyy virheellisiä fonttikokoja, esim. {font-size:15} ja näyttää ilman arvoja annetun fonttikoo ikään kuin fonttikoko olisi annettu pikseleinä ({font-size:15px}). Look at an example.
2. Se hyväksyy heksadesimaalisia väriarvoja ilman että arvo alkavat merkillä #.
3. Se hyväksyy @import at-säännön, vaikka sääntö ei olisi tyylisivun alussa.
4. Se hyväksyy virheellisiä id ja class attribuuttien nimiä.
5. Tuleviin versioihin liittyvä yhteensopivuus (forward compatible parsing) ei toimi.

Huomautus. On todella huono asia, että MS IE 5.5 hyväksyy paljon virheellistä CSS:ää, sillä Netscape- ja Opera-selaimet eivät hyväksy yhtä paljon virheellisiä määrityksiä. Sivujen tekijä saattaa luoda CSS:ää, joka toimii vain MS IE -selaimissa. Itse asiassa olisi toivottavaaa, jos selaimet voisivat tarkistaa CSS:n ja huomauttaa koodausvirheistä. Tämä olisi paljon parempi ratkaisu kuin virheellisen CSS:n hyväksyminen (virheellisen CSS:n hyväksymisestä seuraa ongelmia myös tuleviin versioihin liittyvien yhteensopivuusseikkojen kanssa).

Myös MS IE 5.5:n CSS2-toteutus oli pettymys. MS IE 5.5 ei ole todellinen XML + CSS selain, sillä se ei tue eräitä tärkeitä piirteitä (käsittelen niitä myös sivulla Miten XML-dokumenttien kanssa voi käyttää CSS:ää.

CSS2-toteutuksesta puuttuu ainakin seuraavat piirteet:

• Monet display ominaisuuden arvot (run-in | compact | marker | table | inline-table | table-row-group | table-row | table-column-group | table-column | table-cell | table-caption). Kaikki CSS1-tason arvot on toteutettu ainakin joten kuten, mutta ei ole mahdollista luoda XML-dokumenteille HTML 4.x:n taulukkorakennetta CSS:n avulla koska puuttuu joidenkin olennaisten display ominaisuuden arvojen tuki. Tämä on erityisen haitallista siksi, että Opera 4.x+ ja Netscape 6.x+ -selaimet antavat mahdollisuuden luoda XML-dokumenteille taulukkorakenteen CSS:n avulla - katso esimerkki. Opera 5.x tukee ainakin display-ominaisuuden arvoja: inline | block | list-item | run-in | compact | table | inline-table | table-row | table-cell | table-caption | none.
• Muutamat CSS2:n taulukkomalliin (CSS2 table model) liittyvät ominaisuudet ja niihin liittyvät arvot (caption-side, empty-cell, visibility:collapse). Puuttuvat piirteet eivät ole kovin olennaisia.
• Jotkut sivutettuun mediaan (paged media) liittyvät ominaisuudet ja niihin liittyvät arvot (page, size, marks) ja yksittäiset arvot (esim. avoid). Puuttuvat piirteet eivät ole peruspiirteitä.
• Max-height, min-height, max-width ja min-width. Nämä ominaisuudet tekisivät mahdolliseksi määritellä joustavat leveys- ja korkeusarvot. On todella huono asia, että MS IE ei tue näitä ominaisuuksia, sillä ominaisuuksien tuki tekisi mahdolliseksi hyvin yksinkertaiset sivurakenteet. Tosin MS IE -selaimille on mahdollista luoda JavaScript-koodauksella toiminnallisuus, joka muistuttaa max-width ominaisuutta (käsittelen tätä asiaa eräällä toisella lisäsivu).
• position:fixed.
• Erillisten taulukkosolujen malli (separate borders model) toimii vain osittain (esim. border-collapse: separate; border-spacing: 15pt; ei toimi).
• caption-side.
• Attribuuttivalitsimien tuki puuttuu kokonaan (esim. a[target="_top"] {background-color:#ffc} ei toimi).
• Selaimessa on vain CSS1-tason hahmontunnistus ja siitä puuttuu kaikki CSS2-tason (esim.Netscape 6.x+ -selaimissa on kunnon hahmontunnistustuki ja ne lukevat kaiken CSS:n jota olen laittanut virhetestisivulle. It has a special test for pattern matching).

Lisäksi huomautan, että MS IE 5.5 tukee ominaisuutta overflow sangen hyvin, mutta overflow:auto tulisi luoda vierityspalkit vain kun se on ehdottoman välttämätöntä. Moka on kuitenkin sangen pieni.

Yleisesti ottaen MS IE 5.5:ssä on suhteellisen keskinkertainen, ei missään nimessä hyvä CSS-tuki.

Epästandardi CSS

Microsoftin tuotesuunnittelun ikävä piirre on ollut se, että firma on keskittynyt epästandardien ratkaisujan luomiseen sen sijaan että olisi tehnyt kunnollisen olemassa olevien standardien toteutukset. Käsittelen epästandardia CSS:ää erillisellä sivulla. Alla on linkki eräälle Web-sivulle, jossa kommentoidaan tätä asiaa.

MS IE 6.0+ Windows

MS IE 6.0:ssa ei ole paljon uusia CSS-toteutuksia. Koskien CSS2:een mutta ei CSS1:n liittyviä piirteitä Microsoft ilmoittaa, että vain min-height tuki taulukkoelementeille on lisätty (ominaisuus ei toimi tavanomaisilla lohkoilla). Yleisesti ottaen MS IE 6.0:sta puuttuu samat CSS2-piirteet kuin MS IE 5.5:täkin. Sen sijaan Microsoft on tosissaan yrittänyt toteuttaa CSS1:n kokonaan ja saada olemassa olevan CSS2-toteutuksen vastaamaan CSS2-spesifikaatiota.

Microsoft on onnistus tässä sangen hyvin. Muutamista mokista huolimatta MS on todella yrittänyt luoda standardin mukaisen CSS-toteutuksen kun standard-compliant -moodi on käytössä niin sanotun DTD-kytkimen avulla. CSS2-spesifikaation toteutusyritykset koskevat pääosin tilanteita, joissa selain toimii standard-compliant -moodin mukaisessa. Standard-compliant -moodissa MS IE 6.0 tukee tulevia ehdotelmia mutta ei epästandardeja laajennuksia.

DTD-kytkin luo myös ongelmia, sillä MS IE 6.0 Windows saattaa näyttää sivut melko eri lailla kuin MS IE 5.5 Windows. Asiat, joita käsittelen sivulla 8 ja jotka koskevat dimensio-ongelmia on syytä ottaa huomioon. Seuraamalla ohjeitani on mahdollista, MS IE 5.5 Windows, MS IE 6.0 Windows, MS IE 5.0 Mac and uudet Opera and Netscape/Mozilla Gecko -selaimet näyttävät sivut suunnilleen samoin tavoin kaikkia dokumenttityyppejä käytettäessä.

Selain tekee myös standard-compliant -moodissa maininnan arvoisi virheitä. Melkein kaikki CSS1-tason mokat/puuttuvat piirteet on korjattu/lisätty. Alla on lyhyt CSS1-spesifikaatioon liittyvä lista:

• CSS1-toteutus on melkein täydellinen, koska seuraavat ominaisuudet/ominaisuuksien arvo, jotka eivät toimineet/toimivat bugisesti MS IE 5.5 -selaimessa toimivat nyt W3C's CSS1 Test Suite -testisarjassa: margin, padding, font-variant:small-caps, word-spacing, display:list-item ja white-space:pre.
• Ominaisuudet float ja clear toimivat samalla lailla virheellisesti kuin MS IE 5.5 -selaimessa (W3C:n testi ei paljasta kaikkia virheitä).
• Ominaisuus width ei toimi aina oikein. body {width:100%} aiheuttaa toisinaan turhia vaakavierityspalkkeja. Ominaisuus ei toimi oikein taulukoissa.
• Jos selain toimiin standard-compliant -moodissa ei hyväksy useimpia CSS-syntaksivirheitä, joita MS IE 5.5 hyväksyy. MS IE 6.0 hylkää standard-compliant -moodissa toisinaan virheellisesti koko kuvauksen, kun vain osa siitä on virheellistä, esim. border:1p solid black (1p on virheellinen ominaisuuden arvo). Mutta toisinaan se korvaa tuntemattoman arvo ominaisuuden oletusarvolla. Esim. tilanteessa border:3px solid double; border-bottom-style:inherit selaimen pitäisi ohittaa sille tuntematon arvo border-bottom-style:inherit eikä korvata inherit oletusarvolla none. MS IE 6.0.n käytös on tässä suhteessa.

Huomautus. Koska MS IE 5.5 toteuttaa virheellisesti height ja width tavanomaisille rivinsisäiselementeille (esim. STRONG), MS IE 6.0 tukee CSS3:een kuuluvaa näyttötyyppiä display:inline-block. Jos selain toimii standard-compliant -moodissa tämä CSS täytyy antaa jotta tavallisille rivinsisäiselementeille saa. Viittaa ominaisuuteen mikä merkitys on web-standardeillalla, joka käsittelee CSS2-spesifikaation ongelmia.

MS IE 5.0+ Mac

MS IE 5.0 for Mac eroaa monessa suhteessa MS IE 5.5 ja MS IE 6.0 Windows -selaimista. MS IE 5.0 Mac -selaimessa on DTD-kytkin kuten MS IE 6.0 Windows -selaimessa. MS IE 5.0 Mac saattaa siten näyttää sivut niin, että lopputulos on joko lähempänä MS IE 5.5 Windows tai uusia Opera ja Netscape/ Mozilla Gecko -selaimia.

Yleisesti ottaen siinä on parempi CSS2-toteutus kuin MS IE 5.5 Windows -selaimessa. Sitä tulee siksi verrata pikemminkin MS IE 6.0 Windows kuin MS IE 5.5 Windows -selaimeen. MS IE 5.0 Mac eroaa MS IE 6.0 -selaimesta ainakin seuraavissa kohdissa:

• Se ei tue @media. Mediatyypit täytyy antaa media-attribuutin avulla.
• Se ei tue sivutettua mediaa.
• MS IE Mac tukee position:fixed, jota käsittelen sivulla 11.
• DTD-kytkin vaikuttaa ominaisuuteen width myös taulukoissa.
• DTD-kytkin ei vaikuta fonttikokoihin xx-small-xx-large. MS IE Mac näyttää eri ne lailla (katso mallisivu).

Ohitukset

On tilanteita, joissa jokin yhteinen CSS-tiedosto ei sovi kaikille MS IE versioille. Selainten erilainen @media tuki antaa mahdollisuuden ohittaa jokin selain. Jos sama ohitus tarvitaan sekä MS IE 4.x Windows että MS IE 5.0 Mac -selaimille, sama CSS täytyy antaa useaan kertaan.

Ominaisuuksien antaminen tuntematonta mediatyyppiä käyttäen voidaan antaa yksilöllinen CSS MS IE 4.x -selaimille:

/* MS IE 5.0 Mac ei lue mitään medialohkon sisällä olevaa sääntöä, mutta MS IE 5.+ Windows hylkää vain tuntemattomat mediatyypit. */
@media tty {
foo {} /* MS IE 4.x Windows ohittaa tämän säännön ja lukee vain tätä sääntöä seuraaat säännöt. */
#IE4 {...}
}

Tämä soveltuu myös uudemmille selaimille kuin MS IE 5.0 Mac sillä Microsoft on lopettanut Mac-selainten kehittämisen. Järkevin tapa räätälöidä CSS erilaisille MS IE versioille on tehdä yksi iso yhteinen CSS-tiedosto, joka soveltuu ainakin jollakin tasolla kaikille selaimille (katso mallilähdekoodikatkelma). Jos on tarpeen jotkin versiot saavat omat CSS-tiedostot, joissa on selainkohtaisia muutoksia.

Ohitukset voi hoitaa myös selainkohtaisilla kommenteilla, jotka muut selaimet tulkitsevat tavallisina kommentteina ja siksi ne toimivat MS IE 5.x+ -selaimissa, esim:

<!--[if IE 5]>
...
<![endif]-->

Huomautus. Jos tarkoituksena on antaa Opera 4.x+ -selaimille kokokuvaruutumoodissa sama CSS kuin uusille MS IE -selaimille, on syytä noudatta ohjeita, joita annan Operaa käsittelevällä sivulla. On myös syytä ottaa huomioon ohjeet, joita annan käsitellessäni dynaamisia valikoita.

P Millaisia CSS-totetusvirheitä on Netscape/Mozilla-selaimissa

Aiheet

Tämä sivu on jaettu jaksoihin, jotka sisältävät seuraavia aiheita:

• Yleistä (introjakso)
• Netscape 4.x:ään liittyviä ongelmia (jakso 1)
  • Netscape 4.x:n ohittaminen
  • Ilman linkitystä
  • Erityisen ongelmallisia piirteitä
  • Muita vihjeitä
• Netscape 6.x+:aan liittyviä ongelmia (jakso 2)

Yleistä

Käsittelen ensiksi hieman Netscape 4.x -sarjan selaimia ja toisessa jaksossa uudempia selaimia.

Netscape 4.x:ään liittyviä ongelmia

Netscape 4.x:n ohittaminen

Suoran CSS.n (style="...") liittäminen on ongelmallista. Toisaalta sen käyttö on huono asia, sillä Netscape 4.x saattaa kaatua tai käyttäytyä omituisesti. Toisaalta sen käyttö on joskus välttämätöntä, koska linkitetty CSS ei aina toimi. Havaitsin tämän asian testatessani dynaamisia valikoita. Jos suora CSS ei sovi muille selaimille, ne voivat saada ulkopuolisten CSS-tiedostojen avulla sopivan CSS:n, jos ulkoisissa tiedostoissa olevissa CSS-kuvauksissa käytetään !important sääntöä. Sääntöä käytettäessä on kuitenkin syytä välttää säännön ylikuormittamista (moneen kertaan uudelleen määrittämistä), sillä selaimet eivät aina hyväksy ylikuormitettuja sääntöjä.

Monissa tilanteissa on järkevää ohittaa Netscape 4.x -selaimet. Periaatteessa ne voi ohittaa käyttämällä tuotisääntöäe ja yhdistämällä se JavaScript-koodaukseen. Koska Opera 4.x+ -selaimisa on moodi Identify Mozilla 4.x/Esittäydy: Mozilla 4.x skriptin ehto tulisi laatia siten, että Opera ei lue Netscape 4.x:lle tarkoitettu aCSS:ää. Koodi tulee kirjoittaa seuraavaan tapaan:

<script language="JavaScript" type="text/javascript">
<!--
if (document.layers) /* Mitkään muut kuin Netscape 4.x -sarjan selaimet eivät tue tätä metodia, joilloin Opera kuten muutkin selaimet ohittavat lohkon, joka on tämän ehdon jälkeen (annan edempänä toisen vaihtoehdon) */
{document.write('\<\lin'+'k\ rel=\"stylesheet\"\ type=\"text/css\" href=\"Netscape4xStyle.css\"\>'); }
//-->
</script>
<style type="text/css">
<!--
@import url(muilleSelaimille.css);
-->
</style>

Sain tämän perusvihjeen Sam Marshallilta, mutta olen selaintunnistuksen suhteen muuttanut tunnistustapaa. Systeemi toimii nyt kaikilla selaimilla. MS IE, Opera ja uusien Netscape/ Mozilla Gecko -selaimilla ei haittaa mitään, vaikka JavaScript-tuki olisi kytketty pois päältä. Vain Netscape 4.x tarvitsee sitä ja tyylisivut eivät toimi Netscape 4.x -sarjan selaimissa, jos JavaScript ei ole päällä. Joissakin tilanteissa osa CSS:stä saattaa olla järkevää antaa JavaScript-koodin avulla. Käsittelen tällaisia tapauksia eräällä lisäsivulla, joka käsittelee dynaamisia valikoita.

Edellisesessä esimerkissä mainitun käytännön ongelmana on se, että medialohkojen avulla toteutettuja mediatyyppivalintoja ei voi käyttää, jos tarkoitus on se, että CSS toimii myös Mac -selaimissa. MS IE Mac (koskee ainakin versioon 5.0 asti) ei nimittäen tue medialohkoja (@media {...} vaan se hyppää kaiken medialohkojen sisään kirjoitetun CSS:n ohi.

Opera-selaimissa on toinen erityisongelma. Se lukee aina kaikki @import at-säännön sisältämän CSS kaikille mediatyypeille, jos ei nimenomaisesti ole kerrottu mitä mediatyyppiä sääntö koske (koskee ainakin versioon 5.11 asti). Mediatyyppitarkennin (esim. @import url(...) screen;) toimii vain harvoissa selaimissa. @media ja @import at-sääntöjä ei tulisi käyttää ollenkaan, jos tarkoituksena on luoda CSS kaikille meditatyyppejä tukeville!

Parempi vaihtoehto samasta perusideasta on luoda Netscape 4.x -sarjan selaimille omia CSS-tiedostoja ja laittaa kommentit sellaisten tiedostojen ympärille, joita Netscape 4.x ei pidä lukea. Alla esitetty tapa tekee mahdolliseksi mediatyyppien toimivuuden myös Mac-selaimissa (koodi on tarkoitettu XHTML-dokumentteihin):

<script language="JavaScript" type="text/javascript">
<!--
if (document.layers)
{document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text/css\"\ href=\"../Css/basicNetscape4.css\"\ \/\>');
document.writeln('\<lin'+'k\ rel=\"stylesheet\" type=\"text/css\"\ href=\"../Css/Netscape4SomeOtherSite.css\"\ \/\>');}
//-->
</script>
<script language="JavaScript" type="text/javascript">
<!--
if (document.layers)
{document.write('\<'+'!\-\-'); } /* Jos kommentteja ei luoda kahdessa osassa selaimet saattavat käsitellä niitä virheellisesti! Jos \-\- sijasta kirjoitetaan -- tarkistuspalvelu tulkitsevat koodin siten, että dokumenteissa on käytetty sisäkkäisiä kommentteja, jotka eivät ole sallittuja. */
//-->
</script>
<link rel="stylesheet" type="text/css" href="../Css/CssSitePrint.css" media="print" />
<link rel="stylesheet" type="text/css" href="../Css/CssSiteProjection.css" media="projection" />
<link rel="stylesheet" type="text/css" href="../Css/CssSiteScreen.css" media="screen" />
<script language="JavaScript" type="text/javascript">
<!--
if (document.layers)
{document.write('--'+'\>'); }
//-->
</script>

Olen havainut, että ensimmäisten ja viimeisten Netscape 4.x -sarjan selainten välillä on suuri luotettavuusero. Netscape 4.04 kaatuu hyvin helposti mutta Netscape 4.79 suhteellisen vakaa. Oletettavasti myös Netscape 4.6x on suhteellisen vakaa. Jos on tarpeen, on mahdollista myös tehdä eri CSS eri Netscape 4.x -sarjan selaimille. Alla olevassa esimerkissä Netscape 4.0x-4.5x ja uudemmat Netscape 4.x -sarjan selaimet saavat erilaisen CSS:n:

<script language="JavaScript" type="text/javascript">
<!--
if (document.layers)
{document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text/css\"\ href=\"../Css/basicNetscape4.css\"\ \/\>');}
//-->
</script>
<script language="JavaScript" type="text/javascript">
<!--
/* Koska tässä tapauksessa tarvitaan tarkempi CSS, prosessiin kuuluu kaksi osaaecause. Tavoitteena on, että Opera voisi ohittaa kaikissa olosuhteisa Netscape 4.x -selaimille tarkoitetun CSS:n */
if (navigator.userAgent.indexOf('Opera')!=-1){} /* Koska Opera havaitsee tunnistusmerkkijonon, joka sopii sille se ohittaa seuraavan lohkon siinäkin tapauksessa että se teeskentelisi olevansa Netscape 4.x -selain. Toimii luotettavasti ainakin Opera 4.02+ lähtien. Vanhemmat Opera-selaimet eivät aina anna tätä tunnistusmerkkijonoa, joten niitä ei voi luotettavasti tunnistaa tällä tavoin. Periaatteessa myös document.getElementById voitaisiin käyttää, mutta saamani s-postin mukaan Netscape 4.x -selaimilla on toisinaan vaikeuksia ei-tuettujen metodien kanssa. */

else if (navigator.appName.indexOf("Netscape")!=-1 &&
navigator.appVersion.indexOf("4.7")>=0) /* Ilman ensimmäistä ehtoa lohko voisi koskea myös Opera-selaimia, jos ne esittäytyvät Netscape 4.7x -selaimina. */
{document.writeln('\<lin'+'k\ rel=\"stylesheet\" type=\"text/css\"\ href=\"../Css/Netscape4CssSite.css\"\ \/\>');}
//-->
</script>

Huomautus. JavaScript-koodauksen avulla on mahdollista tunnistaa myös muiden asioiden kuin nimen tai versionumeron perusteella, esim. näytön värisyvyyden ja koon perusteella ja siten luoda näytön ominaisuuksiin perustuvia CSS-tiedostoja. Sen sijaan vain harvat selaimet tarjoavat mahdollisuuden valita oletustyylisivun ja vaihtoehtoisen tyylisivun välillä. Voit etsiä JavaScript esimerkkejä yleisillä hakukoneilla (kuten Altavista ja Google) esim. avainsanoilla javascript+window+color depth jajavascript+window+size.

JavaScript-koodauksen vaihtoehtona on serveripuolen koodaus, joka ei ole riippuvainen siitä onko JavaScript-tuki päällä vai ei. Mutta serveripuolen koodilla ei voi testa, mitä piirteitä eri selainten JavaScript-tulkit tukevat, joten metodeihin perustuvat tunnistukset eivät toimi. Ainakin Opera voi helposti saada virheellisen CSS:n. JavaScript-koodauksella on helpompi ottaa huomioon tilanteet, joissa JavaScript-tuki on poissa päältä. Käsittelen sekalaisilla tietotekniikkaa käsittelevillä sivuilla PHP:llä toteutettua selaintunnistusta.

Ilman linkitystä

Voit käyttää ilman linkitystä:

• Perus fonttityyli yleisille lohko- ja rivinsisäiselementeille.
• Määrittelyt taulukoiden normaaleille soluille ja otsikkosoluille.
• Elementin BODY taustaominaisuudet ilman taustakuvan asemointia (vanhimmat versiot eivät hyväksyneet monitasoisille BODY elementin sisällä oleville elementeille taustamääreitä).

Annan kaksi esimerkkiä, miten määritellä CSS Netscape 4.x -selaimille:

• Nämä voi antaa Netscape 4.x:lle.
• Näitä ei voi antaa, because they don't work properly with Netscape 4.x.

Erityisen ongelmallisia piirteitä

Kun yritetään luoda hyvä lopputulos erityisesti seuraavat asiat ovat ongelmallisia:

• Elementin SPAN käyttö täytyy testata, sillä selaimen käytös on virheellinen. Pahinta on se, että tekstit voivat mennä toistensa päälle. Elementti sentään joskus toimii.
• Lohkoelementeille annettu background-color ominaisuus toimii virheellisesti. Jos reunuksia ei ole taustaväri tulee vain osaan elementtiä. Reunoja käytettäessä Netscape 4.x tekee aina läpinäkyvän täytteen reunusten ja sisällön väliin (tämän ongelman ratkaisemiseksi on sentään jotain tehtävissä ja käsittelen ongelmaa vielä edempänä).
• Jos kuville antaa border ja width ominaisuudet ne käyttäytyvät oudosti.

Koska et voi tehdä seuraaville asioille yhtään mitään suosittelen määrittelemään CSS:n niin, että Netscape 4.x ei lue niitä tai se saa ne vain joissakin tilanteissa:

• Vaaka-asemointia text-align:justify voi käyttää vain hyvin yksinkertaisissa dokumenteissa.
• Elementeille BODY ja HTML ei pidä antaa reunuksia, sillä selain kaatuu niitä käytettäessä. Netscape 4.04 kohdalla myös muille elementeille annetut reunukset saattavat kaataa selaimen - ylipäätänsä Netscape 4.04:lla on erittäin vakavia ongelmia monimutkaisten CSS-määrittelyjen kanssa. Ongelman ydin on monitasoiset reunukset omaavat sisäkkäiset elementit (uusimmat 4-sarjan selaimet, esim. Netscape 4.79, eivät kaadu tästä syystä). Yhden tason reunukset eivät kaada selaimia. Jos sivuilla on yksinkertainen rakenne ja sivut ovat suhteellisen lyhyitä BODY-elementille voi antaa reunukset. Yhtenä reunusongelmana on vielä se, että selain ei eri värejä eri elementin reunoille.

Muita vihjeitä

• Jos haluat yhtenäisen taustavärin lohkoelementeille ilman näkyviä reunuksia määrittele taustaksi täysin läpinäkyvä GIF-kuva taustakuvaksi. Periaatteessa toinen vaihtoehto on määritellä border:none. Vanhat Netscape 4.x -sarjan selaimet saattavat kaatua määrittelystä. Niille monitasoiset taustaominaisuudet ovat aina ongelmallisia, jolloin myöskään GIF-kuviin perustuva ratkaisu ei toimi. Jos on tarpeen tee useita CSS-versioita eri Netscape 4.x -sarjan selaimille. CSS:n sijaan on mahdollista käyttää sisäkkäisiä taulukoita. Niiden avulla voi luoda myös nättejä reunustuksia. Tosin taustakuvat toimivat paremmin ILAYER ja LAYER elementtien kanssa. Koska ne ovat selainkohtaisia, olen käyttänyt joissakin dynaamisten valikoiden malleissa sivun yläreunassa lyhyillä JavaScript-koodauksilla tuotettuja LAYER elementtejä.
• Koska tärkeyssääntö ei toimi on mahdollista antaa CSS ensin yleisimmin käytetyille selaimille ja sitten Netscape 4.x -sarjalle.
• Jos määrittele BODY elementin fontin, tulee määritellä ainakin elementit TD ja TH (myös muut elementit saattavat tarvita määrittelyjä), koska perityminen ei toimi kunnolla. Koska periytyminen toimii vain osittain joissakin tapauksissa tulee määritellä tarkkoja tunnistettavia hahmoja, esim. p code, blockquote cite {font-size:small} (olen havainnut, että p, blockquote, code, cite {font-size:small} ei antanut toivottua tulosta).
• Testasin pikselimääritettyjä (näytöllä) absoluuttia fonttikokoja Netscape 4.x Windows -selaimessa käyttäen Verdana fonttia välillä 8px-16px. Tämän otannan perusteella joka neljäs fonttikoko on oikein (testissä fonttikoot 8px, 12px ja 16px). Seurauksena on myös se. että joka neljäs pikselimääritetty fonttikoko puuttuu kokonaan (testissä fonttikoot 11px ja 15px). Muut arvot ovat pikselin verran liian pieniä.
• Käytä kappaleille aina päätösmerkkauksia, sillä vaaka-asemoinnit eivät toimi ilman niitä. (Vaikka päätösmerkkauksia käytettäisiin selaimet tekevät siltikin joskus virheitä.
• Jos määrittelet listoille listakuvat määrittele list-style-type systemaattisesti siten, että joka listatasolla on eri listamerkki, sillä Netscape 4.x ei osaa käyttää listakuvia. Listojen kanssa ei toimi juuri mikään CSS. Vain ensimmäisen tason listakohtien väriä voi vaihtaa.
• Testaa huolellisesti ominaisuuden float käyttö (yksinkertaiset määrittelyt toimivat - testaa toimivuutta CSS1 Test Suite avulla).
• Tee suhteelliset viittaukset taustakuviin eräällä englanninkielisellä ohjesivulla antamieni vihjeide mukaisesti (sivulle ei ole paluulinkkiä tältä sivulta - käytä vaihtoehtoisia ikkunoita).
• Tunnistettavat hahmot toimivat listoissa vain osittain. Jos tekstiominaisuudet eivät toimi elementille LI käytä tekstin ympärillä DIV elementtiä. Määritä sitten ominaisuudet elementille DIV tai määritä fonttiin liittyvät ominaisuudet emoelementille (OL tai UL).
• Täyte- ja marginaaliarvot eivät toimi elementille LI, mutta voit ensin määritellä ne elementeille OL ja UL. Voit sitten ohittaa ne tuontisääntöä käyttäen, jolloin uudemmat selaimet voivat käyttää eri arvoja.
• Havaitsin, että kuville annetut margin ja padding ominaisuudet saattavat muuttaa kuvan paikka täysin käsittämättömällä tavallaproperties.
• Lomakkeissa toimivat vain muutamat ominaisuudet. SELECT ja OPTION elementeille annetut reunusominaisuudet tuhoavat elementtien toimivuude kokonaan ja selaimet saattavat kaatua.
• Yksinkertaisia määrittelyjä käytettäessä ainoa ärsyttävä piirre liittyy A-elementtiin. Netscape käsittelee <A name="anchor_name"> ikään kuin näennäisluokkana vaikka sen ei tulisi niin menetellä. Vain attribuutin href (esim. <A href="some.html">) tulisi vasta linkkinäennäisluokkiin. Tälle virheelle voidaan tehdä seuraavia asioita (helpointa olisi määritellö id attribuutti lähimmälle aloitusmerkkaukselle (muulle elementille kuin A); valitettavasti Netscape 4.x -sarjan selaimet eivät ymmärrä attribuuttia id ankkureiden tunnistimine vaan ainostaan CSS ja JavaScript tunnistimina):
  1. Jos et haula linkkien tulevan alleviivatuiksi määrittele pelkkä elementti A (a {text-decoration:none}), jolloin myös <A href="some.html"> ei saa alleviivausta.
  2. Käytä vanhanaikaisella tavalla attribuutteja <BODY link=""...>. Kaikki näennäisluokat ovat sitten linkitetty vain muille selaimille.
  3. Liitä aloitus- ja päätösmerkkaus yhteen, esim. < A name="anchor_name"></A>. Ongelmana tässä on se, että näin tulisi aina muistaa menetellä! Tosin ilman sisältöä olevat ankkurit eivät toimi joissakin vanhoissa selaimissa.
  4. Käytä aina jotain luokkaa (esim. class="name"), jonka määrität siten, että sillä ei ole alleviivausta (text-decoration:none). Myös tällä menettelyllä on sama ongelma kuin edellisellä eli näin tulisi aina muistaa menetellä).

W3C: CSS1 Test Suite: 5.5.25 float.

Lista CSS1 Test Suite esiin tulevista virheistä on hirvittävän pitkä ja sen tulisi olla itse asiassa paljon pidempikin, mutten ollut varma kaikesta, mitä listaan kuuluisi laittaa.

Muista. Netscape 4.x:n CSS-toteutus on monessa suhteessa hyvin huono. Varmasti monessa suhteesa samalla tasolla kuin MS IE 3.02 (merkittävimpänä erona on se, että se tukee useimpia CSSP (P = position = asemointi) piirteitä (CSSP on nykyisin osa CSS2 spesifikaatiota). Dokumenttien perusstruktuurien tulisi perustua HTML 3.2:een. Netscape 4.x:ää pitäisi käsitellä lähinnä HTML 3.2 kykenevänä selaimena, jolle voi antaa hieman CSS:ää.

Netscape 6.x+:aan liittyviä ongelmia

Netscape 6.0:ssa on paljon huonompi CSS-toteutus kuin uudemmissa versioissa ja Mozilla 0.9+:ssa. Se ei tue position:fixed. Sille saattaa joutua tekemään oman CSS:n. Alla on yksi tapa, jolla voidaan selaimen päivämäärää (Build ID) perustuen erotella Netscape/ Mozilla selaimia toisistaan.

<script type="text/javascript" language="Javascript">
<!--
Gecko = (navigator.product == ('Gecko'));
Date1 = (Gecko && parseInt(navigator.productSub)>=20020728);
Date2 = (Gecko && parseInt(navigator.productSub)<=20020727);
if (Date1){
document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\ href=\"..\/Css\/MozillaUusimmat.css\"\ media=\"screen\"\ \/\>');}
if (Date2){
document.writeln('\<lin'+'k\ rel=\"stylesheet\"\ type=\"text\/css\"\ href=\"..\/Css\/MozillaVanhemmat.css\"\ media=\"screen\"\ \/\>');}
//-->
</script>

Em. esimerkissä "erotuslinja" kulkee tiettyjen Mozilla 1.1:n / Netscape 7.0 aliversioiden kohdalla. Esim. Mozilla Gecko -selainten tukema kokeellinen CSS3-toteutus -moz-opacity kaatoi Netscape 6.0:n ja se toimi huonosti Netscape 6.1 tasoisessa Mozillassa ja Netscape 6.2.1:ssä. Tuosta ja eräästä toisesta syystä laitoin omissa CSS-tiedostoissani yhden erotuslinjan juuri edellä esitettyyn kohtaan (voit tutkia käyttämääni lähdekoodikatkelmaa).

Netscape 6.x+:n päiväykset (Build ID) ja vastaavat Mozillan versionumerot ovat seuraavat:

• Netscape6/6.0: Gecko/20001108 (perustuu Mozilla 0.6 -selaimeen).
• Netscape6/6.01: Gecko/20010131 (selain ei perustu mihinkään tiettyyn Mozilla versioon vaan on lähinnä edellisen version korjausversio).
• Netscape6/6.1: Gecko/20010726 (perustuu Mozilla 0.9.1 -selaimeen).
• Netscape 6.2: Gecko/20011019 (perustuu Mozilla 0.9.4 -selaimeen).
• Netscape 6.2.1: Gecko/20011128 (Mozilla 0.9.4.1).
• Netscape 6.2.2: Gecko/20020314 (Mozilla 0.9.4.2).
• Netscape 6.2.3: Gecko/20020508 (Mozilla 0.9.4.3).
• Netscape 7.0: Gecko/20020823/20020730 (jälk. Mac; perustuu Mozilla 1.0 selaimeen vaikka sillä on suurin piirtein sama päiväys kuin Mozilla 1.1 -selaimella (Gecko/20020826); siinä on joitakin Mozilla 1.1:een tehtyjä korjauksia; se esittäytyy (kuvitteellisena) rv:1.0.1 Mozilla (tarkistus)versiona).

Päivämäärien sijaan voi käyttää Mozillan versionumeroa. Alla kaksi Mozilla Gecko -selainten tunnistusjonoa ja niiden pohjalta tehty tunnistusehto:

Netscape 6.2.1:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
Mozilla 0.9.4:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128

Moz094=(navigator.userAgent.indexOf('0.9.4')!=-1);

Tosin tuon tyyppiset tunnistukset eivät toimi Netscape 6.0 kohdalla, sillä se ilmoittaa vastaavan Mozilla-selaimen eri tavalla, kuten alla olevasta tunnistusjonosta käy ilmi (laitoin alapuolelle mahdollisia tunnistusjonoja:

Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0

navigator.userAgent.indexOf('m18')!=-1 /* En tiedä koskeeko tämä Netscape 6.01 -selainta. */
navigator.userAgent.indexOf('Netscape6\/6.0')!=-1 /* Koskee myös Netscape 6.01 selainta. */

Koska on olemassa erityyppisiä Mozilla versioita (esim. Mozilla 0.9.1 ja Milestone 18), Build ID -tyyppiset tunnistukset ovat kattavampia. Joka tapauksessa Mozilla Gecko -selaimet on mahdollista erotella niin tarkasti kuin kulloinkin on tarpeen.

Jos haluat voit erottaa Netscape -selaimet Mozilla -selaimista esim. lisäehdolla navigator.vendor == ("Netscape7") ja antaa siten Netscape -selaimille eri päivämäärän kuin Mozilla-selaimille, esim.:

NetscapeGecko = ((navigator.vendor == ('Netscape6') || navigator.vendor == ('Netscape7'));
...
else if (Mozilla101&&NetscapeGecko)
...
else if (Mozilla11&&!NetscapeGecko)

Gecko-selainten erottelemiseen on paljon syitä. Esim. joillakin Netscape 6.1+/ vastaavilla Mozilla -selaimilla position:fixed määriteltyjen elementtien sisällä olevat position:absolute määritellyt elementit eivät asetu oikein. position:fixed määritelty esi-isäelementti luo säilytinlohkon, josta käsin position:absolute määritellyt elementit tulisi laskea, mutta eräät versiot eivät ota position:fixed määritellyn elementin asemointia aina oikealla tavalla huomioon. Alla olevassa Mozilla 0.9:llä otetusta kuvakaappauksessa position:absolute asemoitujen linkkien tulisi asettua keltaisen position:fixed asemoidun lohkon sisälle (testieni perusteella tämä virhe on korjattu ainakin Netscape 6.2.1 lähtien).

div.pageGroup, div#allPages, div.allPages2, div#PagesFi, div#PagesEn {position:absolute} /* PagesFi ja PagesEn ovat lohkon allPages jälkeläiselementtejä */
div[class="pageGroup"], div[id="allPages"], div[class="allPages2"] {position:fixed !important}
div#allPages {left:6px; top:1px;}
div#PagesFi, div#PagesEn {z-index:17; left:2px; top:2px;} /* ne Mozilla Gecko 0.9 -pohjaiset selaimet, joita olen testannut laskevat näiden lohkojen asemoinnin elementin HTML yläoikealta jättäen huomioimatta asemoinnin, joka on annettu kiinteästi määritellylle DIV-elementille, jonka id-attribuutin arvo on allPages */

Uusimmillakin versioilla on joitakin ongelmia dynaamisten valikoideni esittämisessä (lue ongelmista eräältä englanninkieliseltä testisivulta).

Jotta elementit asemoituisivat oikein kaikissa moderneissa selaimissa, Gecko-selaimille saattaa tarvita määritellä ehdollinen CSS. Sitä tulisi laatia kuitenkin mahdollisimman vähän. Suosittelen lukemaan myös Opera and MS IE selaimia koskevia ongelmia käsittelevät .

Sellaiset ja dynaamiset alivalikot, jotka toteutetaan vain CSS:n avulla eivät Netscape 6.0 -selaimissa toimi (ks. mallit) eivät toimi. Se ei ole kuitenkaan mikään merkittävä ongelma, sillä dynaamiset valikot on paljon järkevämpää toteuttaa DOM1:n mukaisella JavaScript/ ECMAScript + CSS -koodauksella (käsittelen niitä tarkemmin toisella sivulla).

Em. ongelma liittyy IFRAME elementtiin, jonka kanssa monilla Netscape 6.x/ Mozilla selaimilla on vaikeuksia (z-index ominaisuus ja asemointi eivät toimi kunnolla). Jotkut versiot eivät asemoi niitä oikein. Netscape 6.0 tulostaa ne vaikka niille olisi määritelty display:none. Netscape 6.1+-6.2.1 kaatuvat tulostettaessa sivuja, jos sivuilla on näille elementeille määritelty display:none niiden piilottamiseksi. Kaikki IFRAME elementtiin liittyvät ongelmat on ratkaistu uusimmissa Mozilla Gecko -selaimissa.

Netscape 6.1+:ssa on hieno normaalin näyttöesityksen CSS-toteutus. Oikeastaan suurin ongelma selaimen kohdalla on se, että se tarvitsee enemmän CSS:ää kuin muut modernit selaimet, sillä sen HTML-oletusasetukset eivät ole identtiset MS IE - ja Opera-selainten kanssa. Seuraavat asiat on erityisesti huomattava:

• Mikäli taulukkorivien korkeuden tulee olla ehdottoman tarkkoja, line-height tulee määrittää, joissakin tapauksissa myös ylimääräinen font-size määritys on tarpeen (huomasin nämä seikat määritellessäni dynaamisia valikoita).
• Mikäli muutetaan listojen ja listakohtien täyte- tai marginaaliarvoja, sekä padding että margin ominaisuudet tulee määritellä, sillä Netscape 6.x hoitaa oletussisennykset padding ominaisuuden avulla eikä marginaalien määrittämisellä kuten muut selaimet.

Q Millaisia CSS-totetusvirheitä on Opera-selaimissa

Aiheet

• Yleistä
• Opera 5.+:n ongelmia

Yleistä

Koska Opera on vasta 5.0 versiosta asti saatavissa puoli-ilmaisena mainosrahoitteisena (adware) käsittelen lähinnä vain Opera 5.x+ -selaimia. Viittaan Opera 3.x -sarjaan vain sikäli, että miten sivut voi saada toimimaan siinä edes siedettävästi.

Opera 5.+:n ongelmia

Operassa on erittäin hieno erilaisten medioiden tuki, mutta juuri niiden käyttöön liittyy eräitä ongelmia, jotka tulee tietää. Olen maininnut joitakin näkökulmia sivulla 6. Jotta sivut toimivat hienosti sekä näytöllä että printattuna, em. sivulla mainittujen seikkojen vuoksi on otettava huomioon myös seuraavat asiat:

1. Selain tukee media="projection". Jos näytölle tarkoitetut tyylisivut on annettu media="screen" tai vastaavia medialohkoja käyttäen selain ei saa kokoruututilassa lainkaan CSS:ää. Jos sinulla on Opera 4.x+ ja painat F11-näppäintä CSS-sivut näyttävät merkittävästi erilaisilta (minulla on joitakin ohjeita sen käyttöön ja joka sivulla lyhyet ohjeet tässä tilassa navigoimiseen).

2. Opera käyttäytyy virheellisesti, jos mediatyypit annetaan seuraavilla tavoilla:

   • Jos viitataan samaan tiedostoa seuraavaan tapaan:

     <link media="screen" type="text/css" href="Screen.css">
<link media="projection" type="text/css" href="Screen.css">
     <!-- Sen sijaan seuraava toimii: -->
     <link media="screen, projection" type="text/css" href="Screen.css">

     Ongelmana alimmassa on se, että Netscape 4.x ei tue useita yhtä aikaa annettuja media-attribuutin arvoja. Mikäli tietty tyylisivu on tarkoitus antaa sekä Opera että Netscape 4.x -selaimille, mediatyypille projection tulisi antaa eri CSS-tiedosto.
   • Jos medialohko ei täsmällisesti viittaa annetun media-attribuutin arvoon:

     <link media="screen, projection" type="text/css" href="Screen.css">
     ...
     /* Ei toimi seuraavien medialohkon kanssa: */
     @media screen {...}
@media projection{...}
     /* Se toimii vain seuraavan medialohkon kanssa:*/
     @media screen, projection{...}

     Ratkaisun ongelmana on se, että toisinaan samaa tiedostoa voi tarvita sekä yhden että useamman mediatyypin kanssa. Tällöin tarvitaan useita medialohkoja samalle CSS:lle. Esim. jotta medialohkot toimisivat sekä <link media="screen, projection" type="text/css" href="Screen.css"> että <link media="screen" type="text/css" href="Screen.css"> kanssa täytyy laittaa samalle CSS:llä kaksi medialohkoa:

     @media screen {
#linkSet a {color:red}}
@media sceen, projection{
#linkSet a {color:red}}

   • Attribuutti media ei toimi oikein @import at-säännön kanssa, mikäli tuontisäännölle ei ole annettu mediatyyppiä (esim. @import url() print;). Se taasen ei toimi kaikissa selaimissa (Opera-selaimissakin vasta 5.10 versiosta lähtien).

   • @media ei toimi Opera 3.x -sarjassa.

3. Mediatyypillä projection on ongelmana pitää "diat" yhtenäisinä. Jotta ylimääräisiltä sivukatkoilta voitaisiin välttyä annan kaksi ohjetta:

   • Kirjoita tiukkaa koodia. Taulukoita ja listoja lukuun ottamatta olen kirjoittanut aloitus- ja päätösmerkkaukset peräkkäin.
   • Jos selain on katkaissut dian ensimmäisen kappaleen sisällä tai jälkeen olen lisännyt tyhjän DIV elementin, jolle olen antanut class-attribuutin (olen määritellyt mediatyypeille print ja screen div.noScreen {display:none}).

Medialohkoja voi käyttää tilanteissa, joissa MS IE 4.0 Windows halutaan antaa tietty CSS, jota ei anneta uudemmille selaimille. Samoin niillä voi kirjoittaa sellaista CSS:ää, jota ei haluta Netscape 4.x ja MS IE 5.0 Mac -selaimille, sillä kyseiset selaimet ohittavat kaiken medialohkojen sisällä olevan CSS:n. Olen antanut esimerkin sivulla, joka käsittelee MS IE ongelmia. Kun suunnittelee mediatyyppien käytön viisaasti, niillä saa aikaan erityisesti Operalla hienoja ratkaisuja.

Toinen merkittävä ongelma on se, että kiinteästi or absoluuttisesti määriteltyjen elementtien kanssa z-index ei toimi aina oikein. Ongelma koskee aina tiettyjä upotettuja objekteja (ne on upotettu Web-sivuille OBJECT, APPLET ja EMBED elementtien avulla) sekä Opera 6.x asti myös lomakekontrollielementtejä (EMBED, IFRAME, INPUT, ISINDEX, OBJECT, SELECT, TEXTAREA). Näiden elementtien päälle ei voi laittaa tekstiä tai kuvia. Ongelman voi välttää siten, että suunnittelee sivut niin, että ongelmalliset elementit ja muu sisältö eivät mene milloinkaan päällekkäin - erityisen huolellinen tulee olla position:fixed määriteltyjen elementtien kanssa. Uusituissa sivuissa navigoinnit ovat oikeassa ja vasemmassa reunassa ja muu sisältö keskellä, jolloin ongelmia ei juuri synny. Lomakekontrollielementtien suhteen ongelma on korjattu Opera 7.0 Beta 1:ssä.

Selaimella on myös pieni ongelma visibility-ominaisuuden kanssa. Opera piilottaa aina elementit, joilla on visibility:visible, jos ne ovat sellaisten elementtien sisällä, joille on määritelty visibility:hidden (ks. engl. testisivu) (MS IE 6.0 Windows toimii aina oikein, mutta uudet Netscape/ Mozilla -selaimet joskus väärin). Asia on korjattu Opera 7.0 Beta 2:ssa.

Opera 5.x ja Opera 7.0 Beta 2 saattavat vaakatasossa asemoida väärin sisäkkäiset absoluuttisesti asemoidut elementit. Ominaisuus left ei aina toimi. Opera 6.x:n kohdalla havaitsin, että position:absolute + sisäkkäin relativiisesti asemoiduista elementeistä asemointi ei toiminut sisimmille elementeille.

Lisäksi position:fixed suhteen on eräitä erityisongelmia (jos sinulla on Opera 5.x+ minulla on testisivu, joka demonstroi näitä ongelmia):

1. Yhdistelmä position:fixed + position:absolute ei toimi virallisissa Opera 7.0x -selaimissa (Beta 2:ssa sisäkkäiset absoluuttisesti asemoidut elementit eivät toimi oikein). Seurauksena on mm. se, että kiinteästi asemoitujen elementtien sisällä olevien linkkien taustavärit eivät :hover tilassa pysy aina hiiren liikkeen mukana.

2. Asemointi right käytettäessä Opera 7.0 Beta 1 - Opera 7.01 saattavat siirtää elementin liikaa oikealle ja Opera 7.02:ssa elementti saattaa joskus piiloutua.

3. Opera 6.0x -selaimissa padding-top ja padding-bottom ominaisuudet elementille BODY vaikuttavat bottom ominaisuuteen. Esim. div#fixedNavigation {position:fixed; bottom:0; left:0;} yhdessä body {padding-top:50px; padding-bottom:50px;} kanssa aiheuttavat sen, että kiinnitetty elementti on 100px (katselu)ikkunan alareunasta (tätä ongelmaa ei ole 5.x-sarjassa). Tämän ongelman voi välttää, mutta ainakaa Opera 7.0 Beta 2:ssa ongelmaa ei ole (en ole testannut Beta 1:ssä).

4. Asemoidun elementin sisällä oleva kiinteästi asemoitu elementti rullautuu sivun mukana (tätä ongelmaa ei ole Netscape 6.1+:ssä; Opera 7.0 Beta versioissa elementti saattaa häviää kokonaan näytöltä tai sen paikka muuttuu hieman mikäli elementtiä klikataan). Tämän ongelman voi välttää samalla tavalla kuin seuraavakin ongelma.

5. Jos kiinteäksi määritelty elementti (esim. position:fixed; bottom:0; left:0; z-index:3) on pitkällä asiakirjan sisällä, se saattaa hävitä kokonaan näytöltä. Kokeilin Opera 7.0 Beta 2:lla eikä ainakaan tällä sivulla ongelmaa esiintynyt. Ongelma voidaan välttää, jos vain sivun alussa olevia elementtejä määritellään kiinteiksi ja ne ovat elementin BODY välittömiä lapsielementtejä.

6. Jos kiinteäksi määritelty elementti on ikkunan alareunassa, min-height ominaisuutta ei voi käyttää. Korjattu Opera 7.0 Beta 2 lähtien.

7. Dynaamisten valikoiden suhteen position:fixed -kiinnitetyt valikot eivät toimi niin kuin niiden pitäisi (ja kuten ne toimivat Netscape 6.1+ ja muissa vastaavissa Mozilla Gecko -pohjaisissa selaimissa). Tätä ongelmaa ei voi kiertää, mutta se on korjattu Opera 7.0 Beta 2:ssa.

8. Jos kiinteästi määritellyillä elementeillä on taustakuvia, Opera 7.x -sarjaa vanhemmat selaimet rullaavat ne sivun mukana ellei taustakuvia ole määritelty kiinteiksi (background-attachment:fixed). Jos ne on määritelty kiinteiksi Opera laskee niiden paikan CSS2-spesifikaation vastaisesti elementin sijainnin perusteella. Asia on osittain korjattu Opera 7.0 Beta 1:ssä, sillä taustakuvia ei tarvitse määrittää kiinteiksi (asemointi ongelma on jäljellä, mutta Opera 7.0 Beta 2:ssa sekin on korjattu). Tämän ongelman voi ratkaista vain määrittelemällä ehdollisen CSS:n.

9. Jos linkeille on määritelty dynaamiset näennäisluokat (a:hover ja a:active) ja niille reunukset, reunukset toivat vain sivun alussa. Ongelma on korjattu Opera 7.0 Beta 2:ssa.

10. Jos kiinteiksi määritellyillä elementeillä on position:absolute määriteltyjä jälkeläiselementtejä, tämä asia tuo ongelmia joidenkin Mozilla Gecko -selainten kanssa (kyse ei ole Opera vaan joidenkin Mozilla Gecko -pohjaisten selainten virheestä). Tätä ongelmaa ei voi kiertää muuten kuin määrittämällä joillekin Gecko-selaimille ehdollinen CSS, jossa asemointi on määritelty position:fixed avulla (koska Gecko-selainten välillä on keskinäisiä eroja position:absolute ei anna yhtäläistä lopputulosta kaikille niille Gecko-selaimille, jotka tukevat position:fixed).

11. Position:fixed ei toimi 5.x-sarjassa elementeille IFRAME, OBJECT ja EMBED, mutta asia on korjattu 6.x-sarjassa.

12. Lomakekontrollielementit liikkuvat pystysuunnassa pikselin verran kun sivua vieritetään. Asia on korjattu Opera 7.0 Beta 1:ssä.

13. Sivun sisäiset linkit eivät toimi aivan odotetusti. Minun täytyi laittaa sivun alkuun viittaava linkki () välittömästi ankkurin (<a name="Top" id="Top"></a>) jälkeen, sillä muutoin Opera ei mennyt täsmälleen sivun alkuun. Asia on korjattu Opera 7.0 Beta 1:ssä.

Kolmas maininnan arvoinen piirre on xx-small-xx-large ominaisuuksien sangen outo toteutus, joka lähinnä muistuttaa MS IE 5.x Windows -selainten toteutusta (ks. Model8c.html).

Koska Opera-selaimissa ei yhtä laaja-alaisesti toimivaa toimintamoodia (jonkintasoinen "DTD-kytkin" tulin 7.x -sarjaan) kuten uusissa MS IE ja Netscape 6.x+ selaimissa, se ei joissakin toteutuksissa voi toimia yhtä tiukasti CSS2-spesifikaation mukaan kuin MS IE 6.0 Windows ns. standard-compliant -moodissa. Opera kaipaisi laajempialaista DTD-kytkintä.

Käsittelen pienempiä puutteita eri asiayhteyksissä, niistä voi lukea esim. seuraavilta sivuilta:

• Sivustojeni toimivuus eri selaimilla.
• Sivulla 7 käsittelen linkkeihin liittyviä ongelmia.
• Sivulla 8 käsittelen joitakin taustakuvaongelmia.
• Sivulla 10 käsittelen ominaisuuden width ongelmista taulukoissa.

Koska Opera on visuaalinen selain, se ei luonnollisestikaan tue CSS2 kuulotyylisivuja. Laajimpana CSS2:n visuaalisen median tuen puutteena voidaan pitää sitä, että selain ei tue @font-face at-sääntöä. Muut puutteet ovat siellä täällä olevia joidenkin yksittäisten arvojen ja eräiden sääntöjen tuen puuttumisia, jotka olen maininnut englanninkielisissä CSS-taulukoissani (taulukko 1, taulukko 2).

Mikäli Opera on tarvetta tunnistaa ja antaa sille osittain oma CSS, eräällä toisella sivulla on selainten tunnistusvihjeitä.

Opera 7.0 Beta 2:ssa on muista selaimista poikkeavia asetuksia:

• Jos Opera 7.0 Beta 2 määrittelee sekä list-style-type että list-style-image Opera esittää kaksi listamerkkiä, jos list-style-type ominaisuuden arvo on muu kuin none.
• Jos taulukoille ei ole määritelty soluvälejä, oletusarvona on nolla (muissa selaimissa 2 pikseliä).

Opera 7.x -sarjan selaimet tulostavat sivut huonommin kuin 6.x-sarjan selaimet. Beta 1:ssä tulostus on kohtalainen, mutta ainakin 7.03:een asti huono seuraavissa suhteissa:

• Reunukset eivät tulostu (toimii Beta 1:ssä).
• :first-letter tulostuu väärin. Väri voi tulla näyttöesityksen mukaan ja 7.x -sarjassa asemointi on usein pielessä (asemointi on korjattu Opera 7.10:ssä).
• Teksti voi mennä päällekkäin (samaa ongelmaa lievempänä on toisinaan myös näytölläkin; ongelma on on ainakin osittain korjattu 7.10:ssa).

R Millaisia CSS-editoreita on olemassa

Käsiteltävät editorit/sovellukset

• PageBuilder
• HTML-Kit
• Amaya
• Top Style
• StyleMaster
• Netscape 6.x
• Macromedia Dreamweaver 4.0
• DHTML Menu Builder

PageBuilder

PageBuilder on koodieditori, jossa on hyvä CSS1-tason velho (wizard). Ainoa CSS2-tason lisäys on pseudoluokka hover (sekään ei johdu spesifikaatiosta vaan MS IE selaimesta, joka otti sen käyttöön sovelluskohtaisena laajennuksena).

Ohjelma käyttää sisäisenä selaimena MS IE:tä (versio 3.02 tai uudempi). Se on sangen halpa Shareware-ohjelma.

HTML-Kit

Ilmaisessa HTML-kit koodieditorissa on kaikki CSS2-tason ominaisuudet. Ongelmana on se, että CSS-valitsinlistassa on kaikki HTML 4.0 elementit eli sellaisetkin, joihin ei voi sovittaa CSS-sääntöjä. Toisaalta lista ei sisällä pseudo-luokkia ja -elementtejä kuten PageBuilderin lista. Syynä on se, että CSS:lle ei ole tehty omaa listaa. Ohjelmaan on kuitenkin saatavissa CSS:ää ajatellen plug-ins -tiedostoja.

HTML-kit sisältää täydellisen HTML-tason elementti- ja attribuuttiluettelon. Se ei hae tiedostonimiä ilman plug-ins -tiedostoja. PageBuilderin tavoin sisäisenä selaimena toimii MS IE.

Ohjelma muuntaa HTML-dokumentit XHTML tai XML-dokumenteiksi sekä korjaa elementtien virheet plug-ins -ohjelmalla, joka tulee asennuspaketin mukana. Siihen saa ohjelman suunnittelijan tai muiden tekemiä muita plug-ins -ohjelmia kuten:

• CSS1-editori (CSS1-tason ominaisuudet ja puuttuu näennäisluokkien- ja elementtien valinta, mutta niitä pitäisi voida lisätä editoimalla CSS_ref.txt -tiedostoa - ohjelma ei reagoinut tekemiini muutoksiin)
• Kuvien haku
• Tiedostojen haku (puutteelliset toiminnot)
• Perl code menu
• PHP3 koodivalikko
• CSS-validaattori (W3C tekemä, kirjoitettu Javalla)
• Tekemäni CSS-valikko. Saat sen Zip-hakemistosta.
• Mukana on myös eräs XSL(T)-valikko, joka perustuu vanhentuneeseen W3C XSLT spesifikaatioehdotukseen vuodelta 1998 (virallinen W3C:n suositus on marraskuulta 1999). Se on tarkoitettu vain MS IE 5.0 varten, sillä siinä on useita sovelluskohtaisia ominaisuuksia, jotka eivät toimi muissa kuin em. selaimessa. En suosittele sen lataamista. Tein valikon, joka perustuu nykyisiin suosituksiin. Se on saatavissa zip-tiedostona. Jotta voit muokata sitä helposti, lataa HTMK-Kit -ohjelman sivuilta myös Plugins Generator.

Suosittelen, että tarkastat sivusi silloin tällöin W3C HTML-validaattorilla. HTML-kit -ohjelmassa on HTML-Tidy plug-ins sovellus. Sen avulla saa korjattua kaikki syntaksivirheet. Sen vanhemmat versiot eivät ole kuitenkaan varsinaisia validaattoreita, sillä ne sallivat joidenkin sovelluskohtaisten attribuuttien käytön. Uusin versio ei enää epästandardeja attribuutteja tai elementtejä hyväksy, joten se on lähes online-validaattoripalveluiden tasoinen (epästandardeista piirteistä varoittamisen saa kuitenkin pois päältä). HTML-Kit ohjelman avulla voi testata sivun myös jollakin online-validaattoripalvelulla.

Amaya

W3C:n tekemä Amaya näyttää sivut WYSIWYG muodossa ja toimii itse selaimena. Myös siinä on CSS2-tason tuki, mutta se ei pysty näyttämään kaikkia ominaisuuksia oikein. Tosin se luo tyyliattribuutteja, tyylisääntöjä ja käsittelee tyylisivuja.

Ohjelma voi olla hyödyllinen uusien spesifikaatioiden testauksessa, sillä siihen laitetaan kokeellisia uusien spesifikaatioiden toteutuksia (MathML, SVG ja XLink).

Ohjelman haittapuoliin kuuluu se, että se kaatuu helposti. Ohjelma ei myöskään koodaa skandinaavisia erikoiskirjaimia (ä jne.) oikein.

Top Style

Parhaana pidetty editori on käyttöliittymältään MS Office 97 -tyylinen Bradsoftin valmistama TopStyle. Ohjelma tukee CSS2 spesifikaatiota. Siinä annetaan myös ohjeita, mitkä ominaisuudet toimivat eri selaimissa. Jotkut CSS-ominaisuudet puuttuvat versiosta 1.50, mutta ne on lisätty versioon 1.51. Version 1.50 validaattori ja "siivooja" (sweeper) tekee pahojakin virheitä. Olen tehnyt useita virheraportteja ja ohjelman tekijä lupasi korjata virheet ainakin versioon 2.0, mutta en ole testannut toimivuutta, sillä olen asentanut itselleni vain ilmaisen kevytversion (Lite), josta puuttuu mm. validaattori ja siivooja.

StyleMaster

Testaamani 1.5 -versio sisältää melkein kaikki CSS2 visuaaliseen näyttämiseen liittyvät säännöt, ominaisuudet ja niiden arvot. Mukana sangen hyviä opastuksia. Ei sisällä kuuloon perustuvia ominaisuuksia. Se ei sisällä myöskään validaattoria.

Kevytversio merkitsee kuitenkin virheelliset ominaisuudet punaisella (tosin jos tyylisivussa on @media, se merkitsee ensimmäisen säännön virheellisesti punaisella). Huomaa, että se merkitsee tärkeyssäännön lihavoidulla punaisella.

Netscape 6.x

Netscape 6.x on selain, joka käy melkein vertailuselaimena sille, miten selainten tulisi näyttää CSS (siinäkin on tosin omat virheensä). Se toteuttaa lähes kaikki visuaaliset CSS-ominaisuudet.

Pakettiin kuuluu hyvin CSS:ää tukeva WYSIWYG-editori (testasin Mozilla 0.7:n mukana tullutta editoria) - ehdottomasti markkinoiden paras sen suhteen, miten lähellä editoitava tila on lopullista HTML 4.01 ja CSS2 standardien mukaista esitystapaa. Mutta siinä ei ole helppoa tapaa lisätä CSS:ää. Jotta ohjelmaa voi käyttää täytyy avata ensin selain. Vaikuttaa siltä, että se käyttää selaimen esityskonetta sivun esittämiseen.

Se laittaa mukaan yleisentiteetit toisin kuin MS IE -selaimen mukana tuleva MS FrontPage Express. Ohjelma laittaa ankkureihin vain name-attribuutin, vaikka XHTML:ssä pitäisi käyttää myös id-attribuuttia. Ohjelma lisää koodin melko lailla valkotilaa (white space), mistä kaikki eivät pidä. Koodin kääntäminen XHTML-muotoon olisi lisäksi toivottava piirre.

Macromedia Dreamweaver 4.0

Dreamweaver on CSS:n suhteen WYSIWYG-editoriksi vaatimaton - kaukana Mozilla 0.7:n tasosta. Dreamweaverista puuttuu CSS-piirteitä (esim. position:fixed ja :focus).

Kerrosten (layers) asettelu on ongelmallinen. Ohjelma käyttää oletusarvona niiden luomisessa elementtiä DIV, jolle se antaa ominaisuuden position:absolute. Dreamweaver asettaa kerrokset niin kauan oikein, kun ne ovat elementin BODY lapsielementtejä (tai niiden ympärillä on elementti, jolla ei ole marginaalia tai täytettä suhteessa BODY-elementtiin). Mikäli kerroksen luova elementti on sellaisen elementin (esim. taulukkosolun) sisällä, joka luo marginaaleja suhteessa BODY-elementtiin, systeemi menee pieleen, koska kaikki selaimet toteuttavat kerrokset tässä tilanteessa väärin. CSS2-spesifikaation perusteella asemointi tulisi laskea lähimmästä lohkotason säilytinelementistä (container element) käsin, mutta mielestäni Dreamweaver ei niin tee eli sekin toimii väärin.

Dreamweaverin pitäisi aina muuttaa elementin DIV paikkaa, jotta kerrokset toimisivat aina oikein. Ohjelman käyttäjän täytyy osata tämä tehdä ja hänen tuleee tietää, miten selaimet todella toimivat ja pitää tietää, miten koodia editoi kooditasolla, jotta se todella toimisi (ks. myös eräs CSS-nootti.

CSS-editori on alkeellinen (TopStyle on paljon parempi siihen tarkoitukseen).

HTML:n suhteen ohjelma tekee sivun ominaisuuksien suhteen omia attribuutteja, jotka eivät toimi missään selaimessa (esim. <BODY tracingsrc="joku.gif" tracingopacity="23">). En ymmärrä niitä (ehkä jokin väliaikaiskäyttö).

Ohjelma ei myöskään huomauta, mitkä ovat spesifikaatioiden mukaisia attribuutteja ja mitkä selainkohtaisia. Jotta koodi toimisi, täytyy tuntea spesifikaatiot j