Etuliite tai Posthack

CSS-selaimen tuen lisääntyessä, mukaan lukien IE9-tiimin vaikuttavat edistysaskeleet, yhä useammat kirjoittajat tunkeutuvat CSS3:een. Kun he tekevät niin, he kohtaavat toimittajan etuliitteitä – ominaisuuksia, kuten -Moz-border-radius, WebKit-animation ja niin edelleen. Ehkä väistämättä on ollut jonkinlaista murinaa näistä etuliitteistä. Niitä on pyydetty hylkäämään tai kutistamaan kaikki toimittajakohtaiset etuliitteet yhdeksi etuliitteeksi, kuten betaversioksi. Ensisijainen takaisku on, että kukaan ei todellakaan halua kirjoittaa samaa asiaa neljä tai viisi kertaa peräkkäin vain saadakseen esimerkiksi elementin pyöristetyt kulmat.

Vaikka tällainen närästys on ymmärrettävää, se on täsmälleen käänteinen sille, mitä pitäisi tapahtua. Meidän pitäisi kehua myyjiä etuliitteiden käytöstä ja kannustaa heitä jatkamaan. Tämän lisäksi olen sitä mieltä, että etuliitteistä tulisi tulla keskeinen osa CSS-standardointiprosessia. En tee tätä toiston rakkaudesta, vaan halusta nähdä CSS:n kehittyvän johdonmukaisesti. Uskon, että etuliitteet voivat itse asiassa nopeuttaa CSS:n edistymistä ja jalostusta.

Katso kauhuissaan taaksepäin

Ymmärtääksemme, miksi meillä ylipäätään on toimittajaetuliitteitä, on opettavaista katsoa taaksepäin laatikkomalliin, joka melkein tappoi CSS:n ennen vuosituhannen vaihtetta. Epäjohdonmukaiset laatikkomallin toteutukset loivat kriisin. Välttyäksemme vaaralta meidän piti rakentaa täysin uusi toimintatapa merkintäominaisuuden päälle ja keksiä kokonainen hakkeri.

Kaikkea hauskanpitoa kaipaaville yleisön nuorille piiskaajille tapahtui seuraavaa: CSS:ää tukevien selaimien ensimmäisellä kierroksella Netscape otti käyttöön CSS-spesifikaatiosta löytyneen laatikkomallin. Tämä tarkoitti, että leveys ja korkeus tarkoittivat sisältöalueen leveyttä ja korkeutta. Mutta Internet Explorer otti käyttöön intuitiivisen laatikkomallin, mikä tarkoitti, että leveys ja korkeus ilmoittivat laatikon ulkoreunan mitat.

Kumpi näistä kahdesta on mielestäsi parempi, tosiasia on, että oli kaksi suurta selainta, joilla oli suuri käyttäjäkanta, jotka olivat täysin yhteensopimattomia keskenään. Oli 1990-luvun loppu, ja taistelimme helvetin lailla jättääksemme taakseen “tämän sivuston parhaiten katsottuna” -merkkien suo, ja meillä oli tilanne, jossa yhdessä selaimessa hyvin toiminut asettelu saattoi hajota kokonaan toisessa.

Ongelmaa pahensi se, että kumpikaan selain ei voinut muuttaa toimintaansa peilaamaan toista. Oletetaan hetkeksi, että IE-tiimi päätti muuttaa CSS-tukeaan vastaamaan eritelmiä. Tämä merkitsisi sitä, että kymmenet, jopa sadat tuhannet IE:ssä toimivat sivustot hajoaisivat kirjaimellisesti, visuaalisesti sanottuna “korjattu” versio. Vaikka standardiyhteisö olisi suositellut muutosta, muu maailma olisi kirjoittanut selaimen käyttökelvottomaksi. Ja vaikka työryhmä olisi päättänyt muuttaa määrityksiä vastaamaan IE:n käyttäytymistä, Netscape olisi silloin kohdannut täsmälleen saman ongelman.

Näin syntyi DOCTYPE-vaihto. Tästä ongelmasta syntyi koko “standarditilan” ja “oikeiden tilan” järjestelmä. Muiden ongelmien ratkaisut siirrettiin DOCTYPE-kytkemiseen, mutta laatikkomalli laukaisi sen. Ajattele sitä: koska kaksi toimittajaa teki asioita eri tavalla, selaimien on nyt ylläpidettävä kahta erilaista ensisijaista renderöintimallia ja valittava kumpaa ne käyttävät SGML-ilmoituksen perusteella, joka ei kerro mitään hahmontamisesta.

Lisäksi ensimmäinen CSS-hakkerointiaalto kehitettiin ratkaisemaan täsmälleen sama ongelma. Klassinen esimerkki genrestä kertoo sen nimessä: The Box Model Hack. Itse asiassa hakkerointi perustui virheisiin ääniperheen arvojen syntaktisessa jäsentämisessä, mutta kukaan ei koskaan kutsunut sitä ääniperheen hakkerointiksi. Hauska osa on, että tämä ei ollut ainoa tapaus, jossa laatikkomallin epäjohdonmukaisuus johti ongelmiin. Pian sen jälkeen, kun DOCTYPE-vaihto pelasti CSS:n, Explorer-tiimi otti käyttöön joitain CSS-paikannusominaisuuksia. Yksi heidän toteuttamistaan ominaisuuksista oli leike. Saatuaan läksynsä laatikkomallista brouhaha, Microsoftin insinöörit kiinnittivät erityistä huomiota eritelmiin ja tekivät sen, mitä se sanoi. Pian sen julkistamisen jälkeen CSS-työryhmä muutti merkittävästi tapaa, jolla leike toimi. Syntaksi näytti täsmälleen samalta, mutta tuotti hyvin erilaisia ​​tuloksia.

Jälleen kerran määritykset olivat ristiriidassa julkisesti saatavilla olevan selaimen toiminnan kanssa (tai halutessasi päinvastoin). Lopullinen ratkaisu oli palata aikaisempaan käyttäytymiseen ja luopua uudesta käytöksestä kokonaan. Tämä tekee leikkeestä tehokkaasti hyödyttömän missä tahansa elementissä, jonka korkeus ja leveys on arvaamaton – toisin sanoen missä tahansa normaalivirtaisessa, korvaamattomassa elementissä, kuten div tai kappale. Vaikka muitakin ratkaisuja ehdotettiin, ne eivät koskaan toteutuneet, ja leike kuihtui.