A historical look at lowercase defaultstatus
Browsers, thank heavens, take backward compatibility seriously.
Ancient websites generally work just fine on modern browsers. There is a way higher chance that a website is broken because of problems with hosting, missing or altered assets, or server changes than there is with changes in how browsers deal with HTML, CSS, JavaScript, another other native web technologies.
In recent memory, #SmooshGate was all about a new JavaScript feature that conflicted with a once-popular JavaScript library. Short story, JavaScript has a proposal for Array.prototype.flatten, but in a twist of fate, it would have broken MooTools Elements.prototype.flatten if it shipped, so it had to be re-named for the health of the web.
That was the web dealing with a third-party, but sometimes the web has to deal with itself. Old APIs and names-of-things that need to continue to work even though they may feel like they are old and irrelevant. That work is, surprise surprise, done by caring humans.
Mike Taylor is one such human! The post I’m linking to here is just one example of this kind of bizarre history that needs to be tended to.
If Chrome were to remove
defaultstatusthe code using it as intended wouldn’t break—a new global would be set, but that’s not a huge deal. I guess the big risk is breaking UA sniffing and ended up in an unanticipated code-path, or worse, opting users into some kind of “your undetected browser isn’t supported, download Netscape 2” scenario.
If you’re into this kind of long term web API maintenance stuff, that’s the whole vibe of Mike’s blog, and something tells me it will stick around for a hot while.
Direct Link to Article — Permalink
The post A historical look at lowercase defaultstatus appeared first on CSS-Tricks.
