Etsi sivuiltani:

	Aihepiiriluettelo > CSS-oppaan etusivu > Oppaan lisäsivut > E Millaista epästandardia CSS:ää on olemassa > Lisäsivu Array yhtenä isona sivuna

E Millaista epästandardia CSS:ää on olemassa

Yleistä

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

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

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

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

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

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

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

UA ja UI CSS

Aiheet

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

UA CSS Mozilla Gecko -selaimissa

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

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


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


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

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

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

UA CSS Opera 4.x+ -selaimissa

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

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

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

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

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

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

UI CSS

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

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

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

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

Epästandardin CSS:n harmillisuus

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DTD-kytkimet

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

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

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

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

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

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

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

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

Huomautukset:

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

Erittely

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

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

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

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

Ohjelmistokohtainen koodi

Aiheet

• Yleistä
• MSHTML ja "FPHTML"
• Adobe GoLive

Yleistä

Sen lisäksi, että selaimet tukevat epästandardia CSS:ää tai epästandardeja elementtimerkkauksia, tietyt ohjelmistot tukevat epästandardeja piirteitä. Osa piirteistä voi olla jonkun selaimen tukemia mutta osa on vain ohjelmiston omaan käyttöön.

Tarkastelen kahta tuntemaani tapausta. Ensimmäinen liittyy sekä HTML että CSS-koodaukseen. Jälkimmäisessä on kyse vain HTML-koodauksesta, joten sen mainitseminen menee hieman tämän sivun asian vierestä. Joissakin suhteissa toinen tapaus muistuttaa ensimmäistä. Asian vähäisyyden vuoksi en uhraa sille omaa liitesivua. Kyse on lähinnä jälkimmäisen tapauksen vertaamisesta edellisen kanssa.

MSHTML ja "FPHTML"

Microsoft kirjoittaa MSHTML:stä. Sitä tuottaa MS Office 2000 sovellukset. MSHTML:ssä on tavanomaisten HTML-merkkausten lisäksi ns. XML-saarekkeita (<xml> ... </xml>) ja Office-ohjelmille suunnattua epästandardia CSS:ää (monissa tapauksissa epästandin CSS:n etuliitteenä käytetään -mso- saamaan tapaan kuin Mozilla Gecko -selaimet käyttävät -moz- etuliitettä). Pääideana näyttää olevan se, että Office-tuoteilla luotu MSHTML voidaan muuttaa takaisin lähtöformaattiin, kuten esim. Word 2000 ja Exel 2000 -dokumenteiksi siten että muotoilut säilyvät paremmin kuin standardia HTML:ää käytettäessä.

MS Office 2000:n tuottama MSHTML oli itse asiassa Microsoftin ehdotus HTML 5.0 spesifikaatioksi. Siitä keskusteltiin W3C parissa, mutta ehdotus hylättiin.

Tapa jolla MS Office 2000 yhdistää HTML:n ja XML:n on siten nykyisin täysin epästandardi. Jos käytetään XML:ää koko dokumentin tulee olla XML:ää, ei vain saarekkeet. MS Office XP:n tuottaa samanlaista MSHTML-koodia, joka ei täytä muodollisesti XML-kriteerejä.

Office 11:n tulee tietynasteinen XHTML-tuki myös Wordille InfoPath-sovelluksen kautta.

MS IE 5.x+ ymmärtänee osan MSHTML:stä, mutta ei kaikkea. MS:n ajattelutapa näkyy CSS:n osalta siinä, että MS IE ei tue kunnolla sivutettua mediaa (kyse on käytännössä sivukatkojen tekemisestä tulostettaessa) mutta kun MSHTML otetaan Word 2000:een ja tulostetaan sillä, sivukatkot toimivat MS IE:tä paremmin erityisesti MS Office-sovelluksille tehdyn epästandardin CSS:n vuoksi. MSHTML-dokumentit on nimenomaisesti tarkoitettu tulostettavaksi MS Office tuotteilla.

MSHTML:ssä on erittäin suuri määrä pelkästään MS Office -ohjelmien sisäiseen käyttöön liittyviä merkkauksia. Poistin kerran puolet Word 2000:n luomasta kokonaiskoodimäärästä. Kun ottaa huomioon, että mukana oli tekstiä arviolta n. 70-80% merkkausten ja CSS-määritysten kokonaismäärästä oli erityistä MSHTML:ää.

MSHTML:n käyttö rasittaa Web-palvelimia syöttämällä internetiin selaimia ajatellen turhaa koodia. Jos Office tuotteilla tuotetaan MSHTML:ää ja tuotos lähetetään internetiin, internetiä käytetään tällöin ikään kuin MS Office tuotteiden intranetinä. Mielestäni MSHTML ei sellaisenaan kuulu internetiin vaan intranetiin. Saamani s-postin mukaan on olemassa ohjelmia, jotka muuntavat MSHTML:n tavalliseksi HTML:ksi, ainakin Microsoft Office HTML Filter 2.0.

Word 97 yrittää luoda lähes standardia HTML:ää. Mikäli on käytetty lihavointeja tms. muotoiluja lopputulos on yleensä virheellinen, mutta helposti jollakin standardia HTML:ää tuottavalla ja HTML-koodausvirheitä korjaavalla ohjelmalla asianmukaiseksi saatettavissa.

Koska millään Office-tuotteella ei saa suoraan standardia XHTML:ää Office-ohjelmien sijaan internetiin tarkoitettu (X)HTML tulisi mielestäni tehdä asianmukaisia (X)HTML editoreilla. FrontPage 2000 ei ole asianmukainen HTML-editori, sillä se ei käyttää Windows-merkistöä eikä koodaa ääkkösiä internetiin soveltuvalla tavalla (esim. "ä" pitäisi koodata &auml; jne.), jolloin teksti ei näy oikein Mac-selaimissa. Saamani s-postin mukaan FP 2002:ssa on kohtalainen entiteettituki.

Ainakin jotkin FrontPagen versiot toimivat muussakin mielessä epäasiallisesti. Löysin eräältä Web-sivulta alla olevan koodin:

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

Kyseessä on aivan normaali a:hover efekti. Fprolloverstyle-attribuutti on täysin tarpeeton epästandardi "FPHTML" koodaus. Kyse ei ole jollekin selaimelle tarkoitettu koodaus, sillä informaatio on relevanttia vain sivuteko-ohjelmalle. Tällainen tieto pitäisi olla kuitenkin kommenttien sisällä. Koodista puuttui puolestaan type="text/css", joka olisi asiallista laittaa STYLE elementille. Tietyn tyylin mainitsemisen voisi määritellä täysin standardisti, esim. alla olevalla tavalla:

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

Yleensä informatiivisesta lisäkoodista ei ole haittaa vaan kyse on vain epäasiallisesta koodauksesta. On huomattava, että fprolloverstyle ei ole edes HTML 4.01 spesifikaation näkökulmasta asianmukainen attribuuttisyntaksi. Jotkin vanhat HTML-spesifikaatiot käyttivät yksiosaisia attribuutteja, esim. <DL compact>, mutta HTML 4.x lätien syntaksin tulee olla aina muotoa attribuutti="arvo" (lainausmerkit eivä ole aina välttämättömiä). Muoto <style fpstyle="rolloverstyle"> olisi jo vähän asiallisempi. Sivulla, jolla tällaisen attribuutin löysin, Mozilla 0.9 näytti sivun alun väärin. Kyse on todennäköisesti siitä, että uudet Mozilla Gecko -selaimet toisinaan sekoavat elementtien päätösmerkkauksien kohdasta. Ne näyttävät edellyttävän, että attribuutit ovat kaksiosaisia. Tosin kun vierailin sivulla uudestaan, ongelmaa ei ollut, joten selaimen ongelmakäytös saattoi johtua muista syistä.

En voi kuitenkaan suositella FrontPage 2002 vanhempien Microsoftin HTML-editorien käyttämistä. Uusimmilla FrontPage ja Macromedia Dreamweaver edutoreilla saa XHTML:ää, joten niitä voinee pitää erittäin suositeltavana WYSIWYG-editorina. Käyttämälläni HTML-Kit -koodieditorilla saa myös standardia HTML 4.0/HTML 4.01 tai XHTML 1.0 koodia.

Adobe GoLive

Samaan tapaan ohjelmiston sisäiseen käyttöön tarkoitetua koodia luo Adobe GoLive. Erona vain se, että mikään selain ei ymmärrä Adoben koodia vaan koodi on pelkästään editorin omaan käyttöön. Mainitsen Adoben koodeja eräässä englanninkielisessä kommentissa.

Olen löytänyt Adobe GoLiven tuottamia Web-sivuja, joissa n. 60% koodista oli selaimille turhaa - internetiä ajatellen turhan koodin määrä on suurusluokaltaan samaa luokkaa kuin MS Office sovellusten tuottama erityiskoodi. Olisi fiksua, jos Adoben tuotteissa olisi toiminto, jossa koodista siivostaan editorikohtainen koodi pois ennen kuin sivu lähetetään internetiin. En pidä GoLivea asianmukaisena HTML-editorina.

Osaakohan mikään softa poistaa Adobe GoLiven tuottaman turhan koodin ja luoda em. softan tuottamista epästandardista merkkauskielistä tavallista HTML:ää or XHTML:ää?