Den bisarra webb-API:n som ingen bryr sig om

Spelet är enkelt: vilken är den konstigaste webbläsar-API:n du känner till?

Som frontend-utvecklare tänker du nog direkt på canPlayType(). Den metoden på HTMLMediaElement kan returnera tre värden: en tom sträng (nej), "probably" eller "maybe". Ett sannolikhetssvar inlindat i vaghet – det är lite av ett kaos.

Men det finns en annan API som verkligen visar webbens totala dedikation till bakåtkompatibilitet: History.pushState().

När du anropar pushState() ska du skicka med tre parametrar: state, title och url. State-objektet är logiskt – det låter din app återställa data när användare klickar på tillbaka-knappen. URL-parametern är praktisk för att uppdatera adressfältet utan att ladda om sidan.

Men den där title-parametern? Den ignoreras helt. Varje stor webbläsare kastar bort den utan pardon.

Så varför finns den över huvud taget?

År 2008, när History API:n först skissades, tänkte någon att webbläsare borde låta appar sätta en egen titel för varje historikpost. Idén var att din SPA kunde visa "Dashboard" i appen medan "Analysrapport" sparades i webbläsarens historik.

Det lät vettigt då. Men webbläsartillverkarna insåg snabbt att det skulle skapa förvirrande situationer – vad händer när en användare bokmärker en historikpost och titeln inte stämmer överens med det de ser i sina flikar?

Istället för att hantera den smärtan valde webbläsarna helt enkelt att ignorera parametern. Men då hade redan otaliga sajter byggt sina appar för att använda tre parametrar. Att ta bort den skulle knäcka sajter i produktion. Att göra den valfri skulle skapa förvirring med befintliga pushState(state, url)-anrop.

Så specifikationen gjorde något elegant: den döpte om parametern till unused och dokumenterade att den inte har någon effekt.

Det här är webbens smutsiga hemlighet – vi prioriterar bakåtkompatibilitet över nästan allt annat. Webben kommer att vrida sig i alla Richtningar (ibland bokstavligen) för att se till att kod från 2008 fortfarande körs i dagens webbläsare.

Den här filosofin är exakt varför vi förespråkar statiska sajter och beprövade webbteknologier på NameOcean. När du bygger något som behöver hålla – mediearkiv, dokumentation, landningssidor – då är stabiliteten i vanlig webbteknologi ingen begränsning; det är en funktion.

Samma princip gäller när du väljer domänregistrator eller hosting-leverantör. Du vill ha företag som förstår det långa spelet. Webben kommer inte någonstans, och teknologierna du bygger på idag bör fortfarande fungera om ett decennium.

Det finns en läxa här för utvecklare och startups: ibland blir det "fel" beslutet permanent inte för att det är rätt, utan för att för mycket hänger på det. Det är ingen bugg på webben – det är en funktion som håller miljontals sajter igång smidigt.

Nästa gång du stöter på en quirky API eller föråldrad parameter: kom ihåg att någon, någonstans, fattade ett beslut för år sedan, och nu är det inristat i webbens grundval. Respektera konstigheterna. De håller saker vid liv.