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

Koonti 2

(Tämä koonti sisältää CSS-oppaan lisäsivut lukuun ottamatta sivua, joka käsittelee CSS-terminologiaa (siitä on oma koottu pitkä versio) ja erästä pitkää jatkosivua. Kooste on ensisijaisesti tarkoitettu tulostettavaksi ja luettavaksi offline-tilassa.)

B Mikä merkitys on Web-standardeilla

Aiheet

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[S]). Ne kuten eräät attribuutit (käsittelen niitä sivulla Help for HTML ALL menu[S]) 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ää[S]).

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[S] ja HTML-piirteitä eräästä englanninkielisestä taulukosta[S]). 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.

Opera Software: Press FAQ, Opera 7 for Windows Beta 2.

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[S] (käsittelen Windows-versioiden pahimpia virheitä ja korjattuja piirteitä sivulla Taustat ja reunat[S]). 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.
Standardit: W3C, ECMAScript.
Muita sivustoja: CSS Enhancements in Internet Explorer 6 Public Preview, Webstandards, Webreviews; Opera Software: Web specifications supported in Opera 5 - the details.

[Alku]

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:

[Alku]

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.

Opera Software: Why doesn't MSN work with Opera.

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:ää[S] 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.

[Alku]

B Mitkä ovat CSS2-spesifikaation ongelmia

Aiheet

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[S]).

W3C: Errata in REC-CSS2-19980512.

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.

[Alku]

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.

Laatikkomallin demonstrointi

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[S]).

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[Pw], 10.2 Content width: the 'width' property[Pw], 17 Tables, 17.6 Borders[Pw]; CSS3: User Interface for CSS3 (W3C Working Draft 16 Feb 2000).
Microsoft:CSS Enhancements in Internet Explorer 6 Public Preview.
[Alku]

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[Pw].

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[S] -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.

Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview.
[Alku]

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}
Testilohko

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.

[Alku]

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[S].

Lisäksi lomakkeissa on pieni ongelma reunojen suhteen (katso sivu Taustat ja reunat [S], 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.

[Alku]

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[Pw].

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

[Alku]

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.

[Alku]

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ä.
[Alku]

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

Aiheet

[Alku]

Käsitekaaviot

HTML/XML kommenttimerkkaus (comment tag)

kommenttimerkkaus (comment tag)
alkutunniste (open identifier) lopputunniste (end identifier)
merkintäerotin (markup open delimiter) kommenttierotin (comment open delimiter) kommenttierotin (comment close delimiter) merkintäerotin (markup close delimiter)
<! -- tekstiä -- >

[Alku]

Elementtimerkkaukset (element tags)

elementti (element)
alkumerkkaus (start-tag) loppumerkkaus (end-tag)
alku-
erotin
(open delimiter)
yleistunniste (generic identifier) loppu-
erotin
(close delimiter)
alku-
erotin
(open delimiter)
yleistunniste (generic identifier) loppu-
erotin
(close delimiter)
< HTML > Sisältö </ HTML >

[Alku]

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.

W3C: CSS2: 4 CSS2 syntax and basic data types[Pw].

[Alku]

Merkintäkoodit (markup codes)

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 <% ... %>).

[Alku]

D Mikä on (X)HTML-elementtien semantiikka

Aiheet

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[S] 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

Lohkoelementit

W3C: Modularization of XHTML™: Block Phrasal, Block Structural, Inline Phrasal, Inline Presentational.
[Alku]

Muut elementit

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

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:

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

W3C: Access for People with Disabilities; Modularization XHTML™: Legacy Module.

[Alku]

E Millaista epästandardia CSS:ää on olemassa

Aiheet

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

Sisältö yhtenä isona sivuna

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[S]). 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ä":

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

[Alku]

UA ja UI CSS

Aiheet

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.

[Alku]

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.

Opera Software: Web specifications supported in Opera 5 - the details.
[Alku]

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

[Alku]

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[S], 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.

W3C: W3C Specification - Scalable Vector Graphics (SVG) 1.0 (Candidate Recommendation 20000802).

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

[Alku]

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

Activating the Right Layout Mode Using the Doctype Declaration.

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[S]). 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.1Opera 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[S]). 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[S].
  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ä.
Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview; Mozilla org.: Mozilla Quirks Mode Behavior.

[Alku]

Erittely

Käsittelen yksilöidysti epästandardia CSS:ää ja CSS3:een ehdotettuja tuettuja piirteitä CSS-taulukoissa ja niiden kommenttisivuilla (Taulukko 1[S] Taulukko 2[S] Nootit 1[S] Nootit 2[S]). 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:

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

[Alku]

F Joitakin CSS-tiedostojen laatimisvihjeitä

Aiheet

Yleistä

Tästä sivusta on Opera 4.x+:aa ajatellen erityinen "diaesitysmuoto", kun käytetään kokoruutunäyttöä (näyttötilan vaihtaminen tapahtuu esim. F11-näppäimellä).
  • CSS kannattaa määritellä mahdollisimman pitkään erillistiedostoissa. Näin se on helposti päivitettävissä.

  • Uusimmat selaimet tukevat mediatyyppejä ja -ryhmiä[S]. Vähintään mediatyypit screen, projection ja print tulee ottaa huomioon.
  • Mediatyyppien käytössä tulee valita, käytetäänkö medialohkoja (esim. @media print {...}) vai media attribuutteja (esim. media="print").

  • Ainakin Netscape 4.x -sarjalle tulee tehdä omat tyylisivut (erityissivulla[S] on tarkemmat ohjeet).

  • CSS (kuten muukin koodaus, esim. JavaScript ja DHTML) tulee suunnitella niin, että sivujen asiasisältö on saavutettavissa kaikilla selaimilla, vaikka sivujen esitysasu vaihteleekin (käsittelen toisella sivulla WWW:n perusteita[S]).

[Alku]

Medialohkot

Medialohkojen edut:

  • Voit luoda yhteisiä määrittelyjä eri mediatyypeille, esim.:

    @media screen, projection {
    html {background-color:#603}
    body {background-color:white}
    }
    @media print, projection {
    h3.Break {page-break-before:always}
    }
  • Jos ryhmität sääntöjä ominaisuuksien arvojen mukaan, yhden arvon muuttaminen vaikuttaa mahdollisimman laaja-alaisesti, jolloin päivittäminen on mahdollisimman tehokasta. Esim.:

    blockquote.code, blockquote.cite, address, pre.code, div.code {border: 1px solid #603;}
    code, kbd, var, blockquote.code, div.code, pre.code {background-color:#cff}

Medialohkojen haitat:

  • Selain joutuu lataamaan yhden aina ison tiedoston. En ole havainnut kuitenkaan siitä johtuvia ongelmia.

  • Yksittäisen kohdan löytäminen on joskus vaikeaa suuresta tiedostosta, vaikka lohkojen välillä olisi paljonkin tyhjää tilaa.

  • Yksittäisen virheen huomaaminen on joskus vaikeaa. Erityisesti tulee muistaa välttää tekemästä virheitä lohkon päättävän kaarisulun kanssa. Ylimääräinen tai puuttuva kaarisulku katkaisee lohkon väärästä paikasta. Merkitse medialohkon päätös esim. seuraavalla tavalla:

    } /* mediatyyppien screen ja projection lohko päättyy tähän */
  • Medialohkot eivät toimi Netscape 4.x, Opera 3.x, MS IE 4.0 Windows ja MS IE 5.x Mac -selaimissa (jotkut selaimet hyppäävät medialohkon sisällön ohitse ja toiset lukevat sisällön riippumatta siitä, mitä mediatyyppiä ne koskevat).

[Alku]

Erillistiedostot

Erillistiedostojen edut:

  • Mikäli mediatyypit ovat omissa tiedostoissaan, yksittäisen tiedoston koko on pienempi kuin kuin yhdistetyssä tiedostossa. Muutettavan kohdan löytäminen on tällöin helpompaa.

  • Selainkohtaisten piirteiden huomioiminen on helpompaa.

  • Media-attribuutti (media="...") toimii myös MS IE Mac selaimissa.

Erillistiedostojen haitat:

  • Erillistiedojen avulla ominaisuuksien kokonaishallinta vaikeutuu, kun yhden kohdan muuttaminen ei riitä.

[Alku]

Teemat

Suunnittele niin, että suurin osa CSS:ää on yhteistä eri sivustoille. Määrittele perus CSS-tiedosto uusille selaimille (esim. basicScreen) siten, että se toimii uusilla selaimilla suhteellisen hyvin ilman JavaScript-tukea. Luo tämän jälkeen sivusto- tai selainkohtaisia tyylisivutiedostoja, esim.:

  • Väriteemoja. Jos sinulla on uusi Mozilla Gecko tai Opera 7.x -selain, voit vaihtaa (Mozilla Gecko -selaimissa View > Use Stylesheet) eri väriteemojen välillä kuten alla olevassa esimerkissä:

    <link rel="stylesheet" type="text/css" href="../Css/ThemeCSS.css" media="screen, projection" />
    <link rel="alternate stylesheet" type="text/css" href="../Css/ThemeCommon.css" media="screen" title="Yleisten sivujen väriteema" />
    <link rel="alternate stylesheet" type="text/css" href="../Css/ThemeHelp.css" media="screen" title="Apusivujen väriteema" />
  • Fonttiteemoja (font-size, font-family jne ominaisuudet).

  • Custom-tiedostoja. Suosittelen laatimaan perustiedoston täydellisesti CSS2:ta noudattavalle kuvitteelliselle selaimelle. Custom-tiedostot joko korjaavat selainten esitysvirheitä tai ne lisäävät selainkohtaisia erityispiirteitä (katso malliksi miten selaimia voidaan tunnistaa tämän sivun lähdekoodi tai toinen liitetiedosto[S]).

[Alku]

Tulostus

MS IE 5.5++ Windows ja Mozilla 1.0+ -selaimissa on minimaalinen ja Opera 4.x+ -selaimissa sangen laaja sivutetun median tuki. Kaikille em. selaimille voi määritellä page-break-after/before:avoid sivukatkojen kontrolloimiseksi. Alla on muutamia ohjeita sivukatkojen ja eräiden tulostukseen liittyvän CSS:n asettamiseksi:

  • Jaa sivut tiettyjä elementtejä käyttäen jaksoihin. Luonnollisia elementtejä tähän tarkoitukseen ovat otsikkoelementit H2-H6 riippuen siitä, mikä on sivujen pääotsikko (se on yleensä H1 or H2).

  • Laita reunustetuille erityislohkoille ja taulukoille page-break-before:avoid.

  • Voit määrittää automaattisen kontrollin Opera-selaimille väärien sivukatkojen eliminoimiseksi asettamalla elementeille tiettyjä luokkia, joille on määritelty page-break-inside:avoid.

  • Voit paljastaa Opera ja Netscape/Mozilla-selaimilla tietyt Web-osoitteen laittamalla esim. a.naytaTulostettaessa:before {content:" <" attr(href) ">"}.

[Alku]

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

Aiheet

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[S]). 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[S]):


	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[S]). 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");
WebFX: CSS Expressions.
[Alku]

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

Javascript-FX: Floating Div.

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.

[Alku]

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

Aiheet

Yleistä

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

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[S] ja englanninkieliseen sivuuni[S]).

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[S], CSS-taulukko 2[S]) ja niiden kommenttisivuista. Mallisivuista on olemassa oma liitesivu[S]. Eräät mallit ovat XML-dokumentteja. Käsittelen CSS:n liittämistä XML-dokumentteihin eräällä sivulla[S].

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[S], 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.

Elementit ja attribuutit
<LINK rel="stylesheet" media="..." ...>
<LINK rel=stylesheet=" media="screen" title="..." ...>

<STYLE media="..." ...>

Annan pääsääntöisesti aihepiirikohtaisen CSS:n elementtiä LINK ja dokumenttikohtaisen CSS:n elementtiä STYLE käyttäen, sillä kaikki mediatyyppejä tukevat selaimet ymmärtävät attribuutin media (en joka kerta käytä attribuuttia lainkaan, jolloin CSS koskee automaattisesti kaikkia esitysmuotoja). Koska Opera tukee "diaesitysmuotoa", olen käyttänyt attribuutilla media arvoja print, screen ja projection.

Mozilla Gecko -selaimet (esim. Netscape 6.x+) ja Opera 7.x+ tukevat vaihtoehtoisia tyylisivuja. Koska niistä ei ole mitään hyötyä, poistin ne käytöstä.

Käsittelen perusmäärittelyjä sivulla 2. Miten CSS liitetään Web-sivuihin[S] sekä eri esityslaitteille tarkoitettujen ns. mediatyypien käytön toimivuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

style

Käytän attribuuttia style aika vähän, sillä niistä on ongelmia Netscape 4.x -sarjan kanssa.

Käsittelen tätä attribuuttia sivulla 2. Miten CSS liitetään Web-sivuihin[S] ja Netscape 4.x -sarjan erityisongelmia eräällä sivulla[S].

class, id

Käsittelen näitä attribuutteja sivulla 4. Mitä ovat valitsimet, luokat ja id-attribuutit[S].

At-säännöt
@import

Käytin aiemmin runsaasti tuontisääntöjä. Koska Operalla - suosikkiselaimellani - ne aiheuttavat ongelmia attribuutin media kanssa, olen luopunut niiden käytöstä lähes kokonaan. Käytän niitä joissakin tilanteissa lähinnä sellaisen CSS:n tuomiseen, joka on yhteistä käytetyille mediatyypeille. Käsittelen at-säännön määrittämistä sivulla 2. Miten CSS liitetään Web-sivuihin[S] ja sen ongelmia sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

@media

Käytin medialohkoja aiemmin paljon, mutta pääsääntöisesti olen luopunut niiden käytöstä. Käytän nykyisin vain erityistilanteissa, sillä Microsoft Internet Explorer 5.0 Mac ei tue niitä.

Käsittelen mediatyyppien ongelmia sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

@page

Toimii ainakin Operassa. Käsittelen sääntöä sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

Tärkeyssääntö
!important

Vaikka tätä piirrettä nimitetään säännöksi, se liitetään ominaisuuksien arvojen joukkoon ja se on siten tavallaan enemmänkin ominaisuuksiin liittyvä asia. Netscape 4.x ei tue tätä piirrettä. Käsittelen sitä sivulla 5: Mikä on CSS:n prosessointijärjestys[S].

Valitsimet
*

Attribuuttivalitsimet (esim. [class="joku"]) toimivat ainakin uusissa Opera ja Mozilla Gecko -selaimissa. Käytän niitä visuaalisen isäinformaation luomiseen sekä joissakin tapauksissa myös MS IE:n ohittamiseen, milloin uusille Opera ja Mozilla Gecko -selaimille annetut samat ominaisuuksien arvot tuottaisivat ongelmia.

Käsittelen sääntöjä ja valitsimia sivulla 4. Mitä ovat valitsimet, luokat ja id-attribuutit[S].

elementti
elementti elementti
elementti.luokka, .luokka
#id, elementti#id
elementti[attribuutti="arvo"]
p:first-letter
:before, :after

Käytän näitä lähinnä tulostuksen ja Operan "diaesityksen" apuna luodakseni hyödyllistä lisäinformaatiota ominaisuuden content kanssa. Käsittelen näitä valitsimia sivuilla 4. Mitä ovat valitsimet, luokat ja id-attribuutit[S] ja 9. Miten CSS annetaan listaelementeille[S].

Ominaisuudet

Standardit CSS2-ominaisuudet (aakkosjärjestyksessä)
background jne.

Käsittelen background ja border ominaisuuksia sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille[S]. 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[S].

bottom

Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

color

Käsittelen ominaisuutta sivuilla sivulla 3. Mitkä ovat CSS:n mittayksiköt, värit ja avainsanat[S].

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[S].

cursor

Käytän sitä joissakin erityislinkeissä. Käsittelen ominaisuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

displayPerusominaisuuksia, jolla kontrolloin eri esitysmuotoja. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].
float

Käytän muutamien elementtien asemoimiseen, mutta en perusrakenteissa. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

font-family, font-size, font-style, font-weight

Käsittelen ominaisuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S] sekä fonttikokojen osalta sivulla 3. Mitkä ovat CSS:n mittayksiköt, värit ja avainsanat[S].

height

Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille[S].

left

Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

line-height

Käsittelen ominaisuutta sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

list-style etc.

Käytän aliominaisuuksilla. Käsittelen listojen ominaisuuksia sivulla 9. Miten CSS annetaan listaelementeille[S].

margin

Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille[S].

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[S] ja 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

orphansSe 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[S].
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[S]

overflow

Käytän joissakin taulukoissa taulukkosolun sisällön kontrolliin arvoa hidden. Käsittelen ominaisuutta sivuilla 10. Miten CSS annetaan taulukkoelementeille[S] ja 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

padding

Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille[S].

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[S].

position

Olen käyttänyt kaikkia mahdollisia arvoja. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

quotes

Katso ominaisuuden content kommentit.

right

Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

size

Omaisuus kuuluu ns. sivutettuun mediaan, jota käsittelen sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

table-layout

Käsittelen ominaisuutta sivulla 10. Miten CSS annetaan taulukkoelementeille[S].

text-align, text-decoration, text-indent

Käsittelen ominaisuuksia sivulla 6. Miten CSS:n annetaan teksteille ja CSS:n kohdentaminen eri medioille[S].

top

Liittyy ominaisuuteen position. Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

vertical-align

Käsittelen ominaisuuksia sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille[S].

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[S].

width

Käsittelen ominaisuutta sivulla 8. Miten CSS annetaan elementtien taustoille ja reunoille[S].

z-index

Käsittelen ominaisuutta sivulla 11. Mikä on CSS2:n Visuaalinen muotoilumalli[S].

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

[Alku]

I Miten luoda dynaamisia valikoita

Luontosivut

Aiheet

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

Sisältö yhtenä isona sivuna

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.

ECMA: ECMAScript language binding; W3C: Document Object Model (DOM) Level 1 Specification (Version 1.0, W3C Recommendation 1 October, 1998), Document Object Model (DOM) Level 2 Core Specification (Version 1.0, W3C Recommendation 13 November, 2000).

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.

Mozilla org.:What have *YOU* done for web standards today? Mozilla new layout engine
Are your JavaScript and CGIs ready for Nav5, IE5, and HTTP 1.1 CONTENT_TYPE? Get the latest info from Erick Krock.
Jos sinulla kysyttävää, ennen kuin kirjoitat Eric Krockille, katso ensin vastauksia.

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[S].

xFX JumpStart: DHTML Menu Builder.

Mikäli tunnet yhtään PHP:tä, olen yrittänyt tehdä eräälle toiselle sivulle mallin, jossa PHP:n avulla valikon päivittäminen[S] 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ä.

Macromedia;TecsOfTheWeb.Com: Using and Manipulating Dropdown Windows.

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

Nelonen, Yomi Media.

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.

CodeStyle: DOM1 Visibility menus

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

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[S], 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[S]. 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.

[Alku]

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[S] on päivämäärälista ja tunnistusesimerkkejä.

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


    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[S]

  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.

[Alku]

Käytetty JavaScript-koodaus

Aiheet

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:

Yleisiä huomautuksia:

[Alku]

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:

[Alku]

Ajastetut valikot

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


CSS-site

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.


    CSS-site

    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 (&nbsp;), 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.

Selainkohtaisia huomautuksia:

  1. Erityisesti Opera 5.x-6.x mutta myös MS IE saattaa sulkea ennalta arvaamattomasti alivalikot, jos vierailija selaa linkkejä ylös alas valitsematta mitään sivua. Opera 7.0 Beta1 -selaimessa ei ole stabiliteettiongelmia ajastettujen valikoiden. Valikot toimivat jopa vakaammin kuin MS IE -selaimissa.

  2. Opera 5.x-6.x eivät pidä toisen tason valikkoa täysin luotettavasti auki. Hiirtä tulee liikuttaa, jotta se pysyisi avoimena. Kun hiirtä liikuttaa toisen tason valikko tulee jälleen näkyviin. Koska hiiren liike voi avata sulkeutuneen valikon, käytös on vierailijan mielestä sangen epävakaa, vaikka stabiliteettiongelma on sangen pieni.

  3. Jos kolmannen tason valikossa onmouseout-tilassa ei olisi ajastusta vaan sen sijaan onmouseout="MM_showHideLayers(...,'Generic1','','hide');" ainakaan Netscape 6.1 tasoisella Mozilla 0.9:llä ei pääsisi lainkaan kolmannen tason valikkoon!

  4. Jos esim. kolmannen tason valikko AppendixesStandards suljetaan toisen tason valikon kautta antamalla komento MM_showHideLayers('AppendixesStandards','','hide'); lopputulos on se, että kolmannelle valikkotasolle ei voi päästä lainkaan MS IE 4.x Windows selaimilla, sillä selain toteuttaa säilytinelementille virheellisesti onmouseout-attribuutin (onmouseout vaikuttaa alueilla, joissa ei ole linkkejä, vaikka käytöksen tulisi olla riippuvainen säilytinelementin reunoista)! Jos sulkemisen toteuttaa ajastusfunktiolla piilota_valikot_nopeasti('AppendixesStandards'); Opera 5.x-6.x -selaimissa on taasen vaikeuksia sen kanssa, sillä se aiheuttaa ennalta arvaamatonta valikoiden sulkeutumista! Mielestäni seuraavat komennot toisen tason valikolle eivät ole kovin käyttökelpoisia:

    <div id="Appendixes" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Appendixes','','show');" onmouseout="piilota_valikot_hitaimmin('Appendixes'); MM_showHideLayers('AppendixesStandards','','hide');" >
    tai
    <div id="Appendixes" class="pageGroup" onmouseover="ajastin_pois(); MM_showHideLayers('Appendixes','','show');" onmouseout="piilota_valikot_hitaimmin('Appendixes'); piilota_valikot_nopeasti('AppendixesStandards');" >
  5. Selaimet toimivat paremmin, mikäli ajastus ei ole itse linkeillä (elementti A) vaan lohkolla, jonka sisällä valikoiden linkit ovat eli ns. esi-isäelementillä (anchestor element), säilytinelementillä (container element; säilytinlohkon täytealueet (padding) kuuluvat sen aktiiviseen alueeseen, mutta mahdolliset reunukset ja marginaalit eivät). Ajatuksen antaminen yksittäisille linkeille aiheuttaa välkyntää, linkit häviävät käytettävistä milloin missäkin tilanteessa eikä niitä saa välittömästi uudelleen auki - käytettävyys on ylipäätänsä huono! Erityisesti Opera 5.x-6.x:lla on ongelmia. Samat ongelmat ovat hieman lievempänä MS IE Windows -selaimissa. Valikoiden sulkeminen emoelementin avulla ei kuitenkaan toimi Opera 5.x-6.x:ssa aina odotetulla tavalla, mikäli ajastinfunktioita käytetään (selain saattaa sulkea valikon ennalta arvaamattomasti).

  6. Netscape 4.x -selaimissa linkkien säilytinelementteinä toimivat edellä mainitulla tavalla vain LAYER ja ILAYER elementit. Tämä on toinen niistä syistä, miksi käytän LAYER elementtejä. Jouduin käyttämään niitä Netscape 4.x -selaimilla myös siksi, että CSS ei toiminut kaikissa yhteyksissä JavaScript-koodauksen ja DIV elementtien kanssa kuten se toimii kaikkien muiden DHTML/DOM tukevien selainten kanssa. JavaScript toimii kuitenkin LAYER elementtien kanssa. Tosin minulla oli vaikeuksia saada JavaScript-koodaus toimimaan ensimmäisen haluamani LAYER elementin kanssa. Poistin JavaScript-koodauksen kanssa asemointiin liittyvän CSS:n vastaavalta DIV elementiltä (muut selaimet saavat sen linkitettynä). Lisäsin eräässä kehittelyvaiheessa muodollisia "valikoita" (<div id="foo" style="visibility:hidden"></div>), joita en enää tarvitse. Jouduin satunnaisissa tilanteissa tuotattamaan ylimääräisen LAYER elementin, jotta ensimmäinen valikkoihin liittyvä elementti toimisi oikein. Sain lopulta kaikki haluamani valikot toimivat LAYER elementtien kanssa. Olen tuotattanut LAYER elementtejä seuraavan kaltaisten skriptien avulla:

    <script language="JavaScript" type="text/javascript">
    <!--
    if (document.layers)
    {document.writeln('\<lay'+'er\ width=\"120\"\ visibility=\"hidden"\ top=\"66\"\ left=\"141\"\ id=\"MainPages\"\ bgcolor=\"white\"\ onmouseover=\"ajastin_pois(); MM_showHideLayers(\'MainPages\',\'\',\'show\');\"\ onmouseout=\"piilota_valikot_hitaasti(\'MainPages\');\"\>');}

    //-->
    </script>
  7. Saamani s-postin mukaan onmouseover tapahtumankäsittelijäattribuutit eivät aina toimi MS IE 5.0 Mac -selaimissa. Tästä syystä joissakin kehittelyversioissa joillakin sivuilla vain javascript:... komennot avasivat alivalikot. Jos mahdollista dynaamisten valikoiden toimivuus tulisi testata myös MS IE 5.0 Mac -selaimissa. MS IE 5.0 Mac -selainten kaltaisia ongelmia on kokemukseni mukaan Opera 4.x:ää, mutta niitä ei ole tarpeen ottaa huomioon.


[Alku]

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:

Taustalaatikko

Varjolaatikko

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

Selainkohtaisia huomautuksia:

  1. Jos dynaamisten valikoiden rakenne on erityisen raskas olen havainnut, että siirryttäessä kolmannen tason valikoista toisen tason valikoihin MS IE 6.0 Windows (koskee todennäköisesti myös 5.x sarjaa) saattaa sulkea valikot ennalta arvaamattomasti, jos sisällysluettelo sulkee kaikki valikot onmouseover tai onmousemove attribuuttien avulla. Huomasin, etten ollut määritellyt z-index ominaisuutta dynaamisten valikoiden pohjaelementille ja sivun pääsisällölle. MS IE tuli epätietoiseksi mitä komentoa sen tuli seurata. Asetin ne ja toimivuus parani hieman, mutta ongelma ei kokonaan poistunut.

    Sain ratkaistua ongelman vain määrittelemällä koko valikolle aktiivisen taustalaatikon. Taustalaatikolle on järkevää asettaa joko onmouseover or onmousedown attribuutti koska onmouseout käytettäessä valikot sulkeutuvat kun vierailija ensin poistuu koko valikosta ja palaa takaisin johonkin taustalaatikon sisällä olevaan valikkoon. Värillisen taustalaatikon kanssa ei tullut ongelmia. Läpinäkyvä taustalaatikko toimi huonommin. Testeissäni onmousedown väriselle taustalaatikolle ja onmouseover sisällölle annettuna toimivat. Jos taustalaatikolle käytetään onmouseover attribuuttia sisällölle pitää asettaa joko onmousedown tai onclick attribuutit. Ongelmallisissa tilanteissa on järkevää ettei valikoita suljeta lainkaan asiasisällön kautta tai että asiasisällön kautta tapahtuvat sulkemiskomennot on suunniteltu niin, etteivät ne koske MS IE 6.0 -selaimia. Mikäli alivalikoille laitetaan varjolaatikot, sisällön kautta sulkemisessakaan ei tule ongelmia.

  2. MS IE 4.x Windowsissa valikon sulkeminen onmouseover or onmousemove attribuuttien avulla suoraan alla olevan sisällön kautta aiheuttaa sen, että alivalikot eivät pysy aina auki ja valikot ovat äärimmäisen epävakaita. Kokeilin onmousedown avulla valikon sulkemista mutta linkkejä on vaikea avata eikä sekään toimi toivotulla tavalla. Vain onclick attribuuttia voi käyttää valikon sulkemiseen alla olevan elementin avulla. Jos em. selainta halutaan tukea, sisällön kautta sulkeminen pitäisi toteuttaa ehdollisesti JavaScript-koodauksella document.write() metodia käyttäen niin, että tietyt attribuutit eivät koske MS IE 4.x Windows -selainta. Valikot saattavat jääjä auki, mutta se on parempi tilanne kuin se, että alivalikoiden linkkejä ei voi lainkaan käyttää.

    Alla olevassa esimerkissä funktion hideAllGroups() tehtävänä on sulkea kaikki avoimet alivalikot asiasisällön avulla. Seuraavan koodin lisääminen ennen dokumentin asiasisältöä alkua pakottaa kaikki dynaamisia valikoita tukevat selaimet sulkemaan ainakin jollakin tapahtumankäsittelijällä kaikki avoimet alivalikot (kaikki alla olevia tapahtumankäsittelijöitä ei tarvitse laittaa):

    
    <script language="JavaScript" type="text/javascript">
    <!--
    if (document.getElementById)
    {document.write('\<di'+'v\
     onmousedown=\"hideAllGroups();\"\
     onmousemove=\"hideAllGroups();\"\
     onmouseover=\"hideAllGroups(); \"\>');}
    
    else if (document.layers)
    {document.write('\<layer\ z-index=\"0\"\ 
     onmouseover=\"hideAllGroups();\"\>');}
    
    else if (document.all)
    {document.write('\<di'+'v\
     onclick=\"hideAllGroups();\"\>');}
    
    else {}
    //-->
    </script>
    Asiasisältö alkaa tästä...

    Jos valikon taakse laittaa taustaelementin ja/tai jokaiselle alivalikolle omat varjolaatikot, joilla ei ole em. selainta koskevaa tapahtumankäsittelijäattribuutteja, valikon voi sulkea asiasisällön kautta millä tahansa tuetulla tapahtumankäsittelijäattribuutilla, koska asiasisältö ei ole suoraan valikon alla. Taustaelementti ja/tai varjolaatikot toimimat tällöin "eristeenä" valikon ja asiasisällön välillä.

  3. Jos varjot on asemoitu absoluuttisesti määritellyn elementin pohjalta, Opera 5.x ei välttämättä asemoi niitä oikein. Käytä selainkohtaista CSS:ää Opera 5.x:lle tai älä käytä sisäkkäisiä asemointeja.

  4. Kuten aiemminkin on tullut esille kaikki rakenneratkaisut eivät toimi MS IE 5.0 Mac -selaimissa, minkä vuoksi yksinkertaisiin rakenteisiin pyrkiminen on eduksi (jos voit käydä lävitse englanninkielinen testisarja[S] MS IE 5.0 Mac -selaimilla).

  5. Valikoiden sulkeminen sisällön kautta edellyttää Netscape 4.x -selaimissa sitä, että varsinainen sisältö on LAYER or ILAYER elementin keskellä.

  6. Alivalikoiden sulkeminen sisällöstä käsin edellyttää sitä, että koko varsinainen sisältö on LAYER tai ILAYER elementtien sisällä.

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

TecsOfTheWeb.Com: Using and Manipulating Dropdown Windows.

[Alku]

Asemointi

Aiheet

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[S].

Selainkohtaisia huomautuksia:

  1. MS IE näyttää elementit, joilla on visibility:visible vaikka ne olisivat sellaisten elementtien sisällä, joille on määritelty visibility:hidden. Selaimen tulee toimia tällä tavoin. Opera piilottaa aina ja uudet Mozilla Gecko (esim. Netscape 6.1) -selaimet position:fixed käytäessä piilottavat virheellisesti tällaiset elementit (engl. testisivu[S]).

  2. Aluksi käyttämissäni dynaamisissa valikoissa viittaamani ominaisuudet eivät useimmiten toimineet testaamassani Netscape 4.x -selaimissa. Annan siksi esimerkkisivuilla vastaavat attribuutit skriteillä tuotetuille LAYER elementeille. LAYER elementillä ei ole position attribuuttia, mutta aiemmassa esimerkissä ollut <LAYER top="66" left="141"> tarkoittaa teoriassa samaa kuin CSS:ssä position:absolute; top:66px; left:141px (ja esim. z-index="3" tarkoittaa samaa kuin z-index:3) - tosin Netscape 4.x asemoi elementtejä vähän eri lailla kuin MS IE ja Opera. Koska LAYER elementit ovat epästandardeja tuotatin ne kaikki skripteillä.

  3. Kun asemoidaan valikoita, on syytä tutustua absoluuttisesti asemoitujen elementtien asemointiin liittyvät yleisohjeeni[S], jotta suuremmilta ongelmilta vältyttäisiin.

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

Kasaa
Kasaa
Laajenna
Laajenna
Luontosivut

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.

Selainkohtaisia huomautuksia:

  1. Kiinteän asemoinnin voi antaa attribuuttivalitsinten avulla, joita MS IE ei ymmärrä, jolloin vain uudet Opera ja Mozilla Gecko -selaimet toimivat sen mukaan:

    div.pageGroup, div#allPages {position:absolute} div[class="pageGroup"], div[id="allPages"] {position:fixed !important}/* Koska attribuuttivalitsimilla on alempi painoarvo kuin id-valitsimilla, kuvauksessa täytyy olla !important-sääntö. */
  2. Systeemi ei toimi aivan ihanteellisesti Opera 5.x-6.x -selaimissa (toimii kunnolla Opera 7.0 Beta 2 lähtien) eikä mitenkään MS IE 5.0 Mac -selaimissa. Se toimii ihanteellisesti ainoastaan uusimmissa Mozilla Gecko -selaimissa (lue puutteista tarkemmin selainten toimivuutta[S] käsittelevältä sivulta, tein myös testisarjan[S] osoittaakseni ongelmia).

  3. Kiinteästi asemoitujen elementtien sijaan voi käyttää JavaScript-koodauksella toteutettuja "kelluvia" elementtejä, jotka pienellä viivellä asettuvat paikoilleen. Toimivuus on kuitenkin jossakin määrin huonompi kuin kiinteästi asemoiduilla elementeillä. Käsittelen tällaisia elementterjä eräällä lisäsivulla[S].

  4. Vaikka Netscape 6.0 ei tue position:fixed asemointityyppiä huomasin yllätyksekseni, että se toimi position:absolute mukaisesti, joten Netscape 6.0 ei tuottanutkaan odottamiani ongelmia.

  5. Olen joskus nähnyt paikallaan pidettyjä valikoita. Koska selaimet nostivat/laskivat elementtejä toimivuus oli melko huono. En osaa opettaa sellaisten skriptien laatimista, jotka aikaansaisivat (ainakin osittain) paikallaan pysyvät elementit. Alla on osoite, josta saa valikon Andy Woolleyn tekemä Top Navigational Bar IV (ver. 3.3.19) nimisen valikon, joka on tietyillä asetuksilla useimmissa selaimissa (myös Opera 4.x-6.x) vakaa ja siirtyy rullauksen mukana (oletusasetuksilla valikko on Opera 5.x-6.x selaimissa epävakaa ja Opera 5.x on vaikeuksia ladata valikko).

    Määrittelemällä menu_arrays.js tiedostossa valikoille esim. ,,120,1,,style1,0,"left",effect,1,,1,,,,,,,,,, valikko pysyy näkyvillä ja seuraa hiiren liikettä kunnes toinen alivalikko avataan. Monitasoisissa valikoissa toimivuus on kuitenkin monissa selaimissa melko huono sillä alivalikot seuraavat emovalikkoa ärsyttävällä viiveellä. Toimivuus on paljon huonompi kuin position:fixed Mozilla Gecko -selaimissa. Tämän tyyppiset linkit toimivat parhaiten linkkinuolina, jotka vievät sivun alkuun (mallisivu[S]) ja edelliselle/seuraavalle sivulle. Tosin Andy Woolleyn Milonic sivustolla monitasoinenkin valikko toimi sangen hyvin Opera 7.x:ssä (paljon paremmin kuin MS IE 6.0 Windows:ssa) ja kohtalaisen hyvin Opera 6.x:ssäkin (valikko ei kuitenkaan ala toimimaan yhtä nopeasti kuin Opera 7.x:ssä). Valikko on aiemmin mainitsemani valikon uudistettu versio (lataamani versio oli 3.5.08 mutta nykyisin se on todennäköisesti uudempi). Versio 3.5.08 ei lataannu Opera 5.x:ssä aina lainkaan eikä mahdollisesti lataantuessaankaan sovellu Opera 5.x:lle. Tästä ongelmasta voi päästä kirjoittamalla JavaScript, jossa Opera 5.x saa vanhemman valikon (katso tämän sivun lähdekoodi[S]). Yleisesti ottaen tämän tyyppisten valikoiden ongelma on siinä, että ne toimivat vain JavaScript-tuki päällä. Itse valikkorakenne olisi parempi kasata serveripuolen ohjelmoinnilla, joilloin valikko voisi olla ainakin jonkin muotoisena aina käytettävissä. Kokeile PHP:n avulla[S] valikkorakenteen luomista.

  6. Sisällön päälle menemisen ongelmaa voisi periaatteessa helpottaa myös CSS3:een kuuluvalla läpinäkyvyyden (transparency) hallintaan liittyvällä ominaisuudella opacity (= läpinäkymättömyys), mutta yleinen tuki puuttuu em. ominaisuudelta. Netscape 6.2+/ Mozilla 0.9.4+/ vähintään yhtä uusille muille Mozilla Gecko -selaimille voi käyttää -moz-opacity ominaisuutta, joka on väliaikainen opacity ominaisuuden toteutus.

  7. Operan kanssa voisi kokeilla muitakin asemointityyppejä kuin top-left, mutta niiden toimivuus on muissa selaimissa heikko, joten en suosittele bottom-left, top-right ja bottom-right bottom-right asemointityyppien käyttämistä. Yksittäisiä linkkejä tai pieniä linkkikokonaisuuksia voi asemoida niiden mukaisesti, mutta ei dynaamisia valikoita.

[Alku]

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.

Resurssienhallinta

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

Auscomp, Macromedia, Sun Microsystems.

Flash- ja applettivaihtoehtojen edut ja haitat:

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.

[Alku]

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:

CSS-site

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

CSS-site

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:...}
CSS-siteCSS-site

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[S] 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ä.

Testisivu

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[S] 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.

#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[S]).

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.

Selainkohtaisia huomautuksia:

  1. Netscape 6.2+/ Mozilla 0.9.4+/ vähintään yhtä uusille muille Mozilla Gecko -selaimille saa CSS:llä aidosti läpinäkyvät hyvin toimivat teräväreunaiset valikot ja varjot -moz-opacity ominaisuuden avulla.

  2. Opera 6.x+ ja Safari (Mac) -selaimille saa hyvin toimivat puoliläpinäkyvät valikot ja varjot PNG-taustakuvilla (MS IE ei tue PNG-kuvissa läpinäkyvyyttä). (Mallikuva[S].)

  3. MS IE 5.5+ Windows -selaimille voi luoda läpinäkyviä valikoita ja pehmeäreunaisia varjoja epästandardia filter ominaisuutta käyttäen, mutta on huomattava, että MS IE 5.5:lle voi laittaa yhdelle elementille kerralla vain yhden efektin (linkki englanninkielisiin CSS-huomautuksiin[S]). Esim. pehmeät varjot voidaan luoda seuraavalla CSS:llä: filter:progid:DXImageTransform.Microsoft.Shadow(color='#777777', Direction=135, Strength=5);. Dynamic Drive:n kokoelmasta löytyy ZIP-tiedosto, josta löytyy filter ominaisuutta hyödyntävä mallivalikko (Top Navigational Bar IV). Valikossa on eräitä toimintaongelmia Opera kanssa, jotka olen maininnut aikaisemmalla jaksolla[S].

  4. Muille kuin uusille MS IE ja Mozilla Gecko -selaimille voi laittaa läpinäkyviä GIF-kuvia. Tietyt kuviot luovat karkeaa läpinäkyvyyttä.


Dynamic Drive: Top Navigational Bar IV; Macromedia; TecsOfTheWeb.Com: Using and Manipulating Dropdown Windows; xFX JumpStart: DHTML Menu Builder.

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

[Alku]

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

Aiheet

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:

Huomautus. Jos määrittelet näyttömedian (@media screen), muista myös kokoruutunäyttötila[S]. 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.

Opera Software: Opera Composer lets users customize their Web browser; Microsoft: Internet Explorer Administration Kit.

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.

Mozilla org.: Customizing Mozilla.

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[S]).

W3C: HTML 4.01: 14.3.1 Preferred and alternate style sheets.

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:

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[S] 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.

[Alku]

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

Aiheet

Yleistä

XML on suhteessa HTML:ään itsenäinen kieli. Sillä on toki HTML:n kanssa yhteisenä "emona" SGML[S][Pw] (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[S][Pw].

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[S]), 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[S][Pw] tukeminen on välttämätöntä.
  3. Riittävän laaja display-ominaisuuden tukeminen[S][Pw] 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[S]).

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 ([M][S][Pw]). 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 ([M][S][Pw]):
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. ([M][S][Pw]):

<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 ([M][S][Pw]):

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[S][Pw]).

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[S][Pw] 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[S]
.
Muut sivustot: Opera Software: Web specifications supported in Opera 5 - the details; Microsoft: XML Schema Refere.

[Alku]

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

Aiheet

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[S].

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:

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[S].

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.

Microsoft: Microsoft XML Parser, MSXML XSLT FAQ.

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?).
InDelv.

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)

HTML-kit Home Page, HTML-Kit Plugins page.

Muita sovelluksia

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

Saxon.

Testisivuja

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

W3C: XML Path Language (XPath) Version 1.0, Extensible Stylesheet Language (XSL) Version 1.0, XSL Transformations (XSLT) Version 1.0.
Muita sivustoja: Netscape, Opera Softaware.

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

[Alku]

M Millaisia ongelmia WAPpiin liittyy

Aiheet

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[Pw] 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>

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[Pw], 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.

[Alku]
[Alku]

N Millaisia CSS-totetusvirheitä selaimissa on

Aiheet

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

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[S][Pw], 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"[S][Pw]. Olen havainnut seuraavia virheitä epäkelvon tai tuntemattoman CSS:n hyväksymisessä:

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ä):

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

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[S][Pw].

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

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.

Webstandards, webreview.com.

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[S]).

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ä[S][Pw]). 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[S]).

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[S][Pw]. 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):

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[Pw].
Muita sivustoja: Webstandards [Pw]; Webreview[Pw]: CSS1 Master Compatibility Chart, CSS2 Selectors Support Chart; CSS Enhancements in Internet Explorer 6 Public Preview.

[Alku]

O Millaisia CSS-totetusvirheitä on MS IE -selaimissa

Aiheet

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

Bradsoft: TopStyle.

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.

[Alku]

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[S]).
  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. */
[Alku]

MS IE 5.5 Windows

Mokia ja puuttuvia piirteitä

Havaitsin MS IE 5.5:ssä seuraavia positiivisia seikkoja:

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[S]).

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:

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:

W3C: CSS1 Test Suite.

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[S][Pw].
  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:ää[S].

CSS2-toteutuksesta puuttuu ainakin seuraavat piirteet:

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[S]. Alla on linkki eräälle Web-sivulle, jossa kommentoidaan tätä asiaa.

Webreference, Webstandars.
[Alku]

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[S]. 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[S] 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:

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[S] tämä CSS täytyy antaa jotta tavallisille rivinsisäiselementeille saa. Viittaa ominaisuuteen mikä merkitys on web-standardeillalla, joka käsittelee CSS2-spesifikaation ongelmia[S].

W3C: CSS1 Test Suite.
Microsoft: CSS Enhancements in Internet Explorer 6 Public Preview.
[Alku]

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[S] 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:

[Alku]

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[S]). 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]-->
Msdn: About Conditional Comments.

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

[Alku]

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

Aiheet

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

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[S]. 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[S][Pw] 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[S].

Edellisesessä esimerkissä mainitun käytännön ongelmana on se, että medialohkojen[S] 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ä[S] toteutettua selaintunnistusta.

Webreference (the color depth), Javascripter (the size of the window), Sam Marshall (United Kingdom; ensimmäisen vihjeen antaja).

Ilman linkitystä

Voit käyttää ilman linkitystä:

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

Erityisen ongelmallisia piirteitä

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

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:

Muita vihjeitä

W3C: CSS1 Test Suite: 5.5.25 float[Pw].

Lista CSS1 Test Suite[S][Pw] 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:ää.

[Alku]

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[S]).

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

DevEdge: Netscape Gecko User Agent Strings; Mozilla org.: user-agent strings.

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 */
Mozilla 0.9

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

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[S] and MS IE[S] 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[S]) 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[S]).

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:

[Alku]

Q Millaisia CSS-totetusvirheitä on Opera-selaimissa

Aiheet

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.

[Alku]

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[S]. 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[S] 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[S] 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[S]. 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[S]) (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[S] -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 ([Alku]) 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[S]).

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[S]. Opera kaipaisi laajempialaista DTD-kytkintä.

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

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[S], taulukko 2[S]).

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

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

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:

[Alku]

R Millaisia CSS-editoreita on olemassa

Käsiteltävät editorit/sovellukset

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.

Taf Web Software.

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:

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.

W3C: HTML validator.
Muita sivustoja: HTML-kit Home page, HTML-Kit Plugins page.

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.

W3C: Amaya, MathML 1.01, Scalable Vector Graphics (SVG) 1.0 Specification.

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.

Bradsoft: TopStyle.

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.

Western Civilization.

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[S] 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.

Netscape.

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[S].

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 ja selaintoteutukset (HTML-Kit tiedottaa, kuuluvatko elementit ja attribuutit tiettyihin spesifikaatioihin vai ovatko ne selainkohtaisia). Selaimen lomake-elementtivalikko on puutteellinen (Netscape 6.0 tukee kaikkia muita lomake-elementtejä paitsi poistuvaa ISINDEX elementtiä).

Dreamweaver on näppärä joissakin kohdin (upotetut objektit, kehyssetit, rolloverit jne. pikatoiminnot), mutta ei takaa haluttua lopputulosta millään selaimella. Sivustokartta (site map) puuttuu ilmaiseditoreista ja jotkin pikatoiminnot, mutta muuten ilmaiseditoreilla saa saman aikaiseksi.

Ikävin piirre on se, että vie paljon käyttöresursseja. Ohjelma toimii monessa koneessa tahmeasti.

[Alku]

DHTML Menu Builder

Monet sovellukset luovat selainkohtaista DHTML:ää, jonka toimivuus on rajallista. Dynaamiset valikot ovat eräitä parhaimpia DHTML:n avulla saatavia ratkaisuja sovelluksia. Niiden luomisesta selviää helpoiten ostamalla DHTML Menu Builder ohjelman, jolla voi luoda DHTML/DOM valikoita kaikille selaimille, jotka niitä osaavat käsitellä (esim. Netscape 4.x, Netscape 66.x, MS IE 4.0+ Windows ja Opera 5.x). Se 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[S].

xFX JumpStart: DHTML Menu Builder.

 
[Alku]
   
Copyright Tapio Markula 1999-2003, Salo (kotisivu, s-posti - lisää s-postiosoiteeseen pisteellä erotettuna nimeni, Tapio Markula) (@dnainternet.net) - ei julkiskäyttöön ilman sopimusta.
Get Expression!
Editori, jolla saa luotua standardit täyttäviä HTML ja XML dokumentteja. Tämän sivuston sivut on useimmissa tapauksissa tarkastettu Dave Raggetin (W3C) tekemällä HTML-Tidy apuohjelmalla ja satunnaisesti W3C-organisaation virallisella koodintarkastusohjelmalla. Useimpien sivujen syntaksin pitäisi olla sopusoinnussa W3C:n XHTML 1.0 spesifikaation kanssa. Testaa tämä sivu!
Informaatiota selaimista, jotka näyttävät tai tulostavat tämän sivuston parhaiten.
[Hae Opera] [Hae Mozilla!]
CSS-opasta on viimeksi muutettu 20.12.2004