Uskon niin lujasti, että toimittajan etuliitteet ovat hyvä asia, että olen valmis ottamaan seuraavan loogisen askeleen. Niitä olisi vaadittava uusilta ominaisuuksilta, ja niiden olisi oltava mekanismi, jolla yhteentoimivuus ilmoitetaan. Tässä mitä tarkoitan. Oletetaan, että joku keksii uuden ominaisuuden nimeltä text-curl. Välittömästi kolme myyjää ottaa sen käyttöön.
Jokaisen niistä tulisi vaatia lisäämään toimittajan etuliite toteutukseensa. Näin ollen, katso tämän kaltaisia asioita Ajan myötä toimittajat tarkentavat toteutuksiaan vastauksena virheraporttiin ja työryhmän selvityksiin. Lopulta työryhmä päättää, että kaksi kolmesta ovat täysin yhteentoimivia. Nämä toteutukset saavat sitten tukea paljaan tekstin käpristymistä.
Siinä vaiheessa kirjoittajat saattavat päättää yksinkertaistaa tyylejään seuraavasti Sitten heti kun työryhmä katsoo -ms-text-curl-toteutuksen yhteentoimivaksi, etuliite voidaan jättää pois seuraavassa julkaisussa. Tässä vaiheessa CSS voidaan pelkistää yhdeksi riviksi ilman etuliitteitä. Jälleen hakkerointien määrä vähenee ajan myötä.
Tietenkin jokainen näistä toimittajista jatkaa etuliitteen ominaisuuksien tukemista, joten vaikka emme karsiisi etuliitteisiä rivejä, jokainen tukeva selain tunnistaa etuliitettömän ominaisuuden ja käyttää sitä (koska se tulee etuliitteen jälkeen). Kaikille selaimille, jotka käyttävät etuliitteellä varustettua versiota, joka ei onnistu pääsemään etuliitteettömään tilaan, sen oma etuliiteominaisuus toimii edelleen.
Vaikka CSS:ään ei koskaan enää koskettaisi, se jatkaa toimintaansa. Tämän jälkeen palataan hetkeksi siihen aikaan, jolloin työryhmä sanoi, että kaksi toteutusta olivat yhteentoimivia ja voivat siten jättää etuliitteet pois. Se palvelee kahta tarkoitusta. Ensinnäkin, kuten sanoin aiemmin, se merkitsee ominaisuutta riittävän yhteentoimivaksi standardiprosessin edistymisen mahdollistamiseksi.
Mutta toinen asia, jota se tekee, ja tämä on kiistatta tärkeämpää, on pakottaa myyjät ja työryhmä tekemään yhteistyötä yhteentoimivuuden määrittämiseksi tarvittavien testien suunnittelemiseksi. Nämä testit voivat sitten ohjata seuraajia ja auttaa heitä saavuttamaan yhteentoimivan tilan paljon nopeammin.
He voisivat kirjaimellisesti lähettää etuliitteellä varustetun toteutuksen yhdessä julkisessa betaversiossa ja pudottaa etuliitettä seuraavassa. Tämä kääntää tavan, jolla asiat nyt tehdään. Nykyisessä muodossaan prosessi on määritetty siten, että kun mikä tahansa CSS-moduuli saavuttaa ehdokassuositusvaiheen, toimittajat voivat pudottaa etuliitteet kyseisen moduulin ominaisuuksista. Mutta se vain avaa meille mahdollisuuden uudelle epäonnistuneelle toteutukselle ja tulevaisuuden hakkeroille virheen kiertämiseksi.
Kuten tässä ehdotetaan, moduulin sallittaisiin saavuttaa ehdokassuositus, kun sen kaikissa ominaisuuksissa on vähintään kaksi prefiksitonta toteutusta luonnossa. Kaikki sen jälkeen tulevat toteutukset alkaisivat etuliitteellä ja pudotettiin etuliitteellä, kun ne olivat luonnossa osoittaneet, että niiden etuliitteetön toteutus vastasi olemassa olevia etuliitteitä sisältämättömiä toteutuksia. Sen sijaan, että ne olisivat pieni uhkapeli, etuliitteettomat kiinteistöt olisivat yhtä lähellä takuuta kuin mikään tähän mennessä nähty.
Jos verkkostandardien historia on osoittanut meille jotain, hakkerointi on välttämätöntä. Lataamalla hakkerit etukäteen käyttämällä toimittajan etuliitteitä ja sisällyttämällä ne standardiprosessiin, voimme itse asiassa korjata joitain prosessiin liittyviä mahdollisia ongelmia ja mahdollisesti nopeuttaa CSS-kehitystä.
Joten seuraavan kerran, kun huomaat murisevan siitä, että kerrot saman asian neljä kertaa, kerran jokaiselle selaimelle, muista, että kipu on väliaikaista. Se on vähän kuin rokote, että rokote sattuu nyt, totta, mutta se ei todellakaan ole niin paha verrattuna sairauteen, jonka se estää. Ja tässä tapauksessa sinua rokotetaan pahaa usean vuoden jäsentäjähakkerointia ja selaimen haistelua vastaan. Kärsimme jo kerran tuosta pitkästä rutosta. Etuliitteet toimivat, jos niitä käytetään oikein.
