You'd think that a technology-oriented magazine like wired would at least try to aim for cross-browser compatibility in their infrastructure. But why bother, make your CMS Chrome-only a policy and free yourself of extra testing.
And it's not only wired. I've come across a lot of internal sites and intranets that are poorly tested on anything but Chrome. I know, it's not exactly the same thing as the old IE/ActiveX but it still grinds my gears when it happens.
>You'd think that a technology-oriented magazine like wired would at least try to aim for cross-browser compatibility in their infrastructure. But why bother, make your CMS Chrome-only a policy and free yourself of extra testing.
Makes total sense as an engineering tradeoff if you're not in the business of saving the web but publishing a magazine.
If Firefox had a larger market share, it would be easy to make the argument for cross-browser compatibility. But when Firefox is not even 12% of Chrome's usage globally http://gs.statcounter.com/ and likely much less for your customers it's difficult to appeal to ideals
There are a different and arguably smaller set of warts in 2017 compared to 1999 but that doesn't mean that it's easy to reproduce the exact layout, pixel for pixel, across Firefox, Edge, Opera, UC Browser, Safari, Chrome and other browsers in use.
Why is pixel-for-pixel similarity even desired? Is it even true across versions of the same browser, or different user settings (like window size or font size)?
Maybe, but those 12% (didn't check the numbers, I take your word for it) are much more sensitive about such discrimination. That's IE all over again...
I'd be more sympathetic if there weren't examples of Mozilla explicitly fighting against features supported by the other vendors. The classic example is Web SQL, an immensely useful API that Mozilla fought hard against and successfully lobbied to kill off. Chrome and Safari still support it. So for a wide swath of problems, you can either use WebSQL and drop FF support or hack around with a slurry of third party libraries and inferior APIs. Should all web developers be restricted because a vendor with relatively small usage insisted on not supporting features?
> This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path. [1]
The w3c requires a standard to have 2 or more independent implementations of a spec. Why should Mozilla or Microsoft be responsible for writing an independent implementation of SQLite just so webSQL can be a standard.
And on the flip-side, we have MathML which the Chromium team decided to drop, fighting against an incredibly useful and performant (in comparison to other Javascript-based implementations) feature supported by Firefox and Safari which made mathematics a first-class citizen on the web.
WebSQL does seem a little nutty to me. You’d perennially be in a state of wondering which SQL features it supported and which it didn’t. It would just introduce a whole other layer of browser incompatibilities as the browser vendors prioritized different features and performance optimizations.
Or, if you committed to keeping it simple and not chasing Postgres and MySQL, then there’s kinda no point. Just write a little SQL wrapper around LocalStorage.
In the end, that’s why we have LocalStorage—it’s simple. Like a file system. It means that you can have a clear sense of what browsers do and do not support.
I guess here’s a direct question: why do you prefer WebSQL over a tiny JS library that does the same thing?
Websites and -apps that run in just one browser are worse than ones that haven't yet switched to HTTPS. It is 2017. This has been going on for 20 years. Browsers are more like each other than ever before. There is no reason for this in a new app.
I always wondered why they branded Chromecast with Chrome, it has almost nothing to do with a browser besides the funny gimmick where you could show a web page through it. Maybe an implementation detail.
I suppose I get it now. It was originally just branding to promote a Chrome monopoly, and now it's an artificial exclusive feature. I love the idea of Chromecast but it's sad that it's still so closed off.
Nothing specifically. I was expanding the specific comment on an instance of Chrome-only compatibility into a general comment on other things Google has been doing to expand it's Chrome monopoly. Maybe the topic deserves a top level comment, sorry if it's placement offended your sensibilities.
To implement Cast support in an application, you have to link a closed source binary to your project. Google only provides binaries for iOS and Android (via Play Services), and has a closed source implementation in Chrome.
It shares a fraction of one property with IE6. It's nothing like IE6 in all other respects.
A quick refresher for those that perhaps was not around in those heady days: to build even moderately advanced (dynamic) web pages that were cross browser compatible was not merely a question of remembering to test in both, it was a significant engineering commitment. To add to the badness, Netscape in those years was frankly just not a very good browser, so it was not a particularly easy sell. Thus a lot of apps built in those years only (and quite rationally, too) targeted IE4, 5 and finally 6, Microsoft being very focused on backwards compatibility. IE7 was the first browser standards compliant enough to make cross browser development reasonably easy, also being the first browser in the line to have to compete with Firefox. It broke backwards compatibility, which is why IE6 ended up hanging around for so long and being so hated, even if was the DHTML API of IE4 that was the original culprit.
Today, there is no good excuse to build web apps that does not work in all the major browsers, it's just so (relatively) easy. But that was emphatically not the case 15-20 years ago.
Highlight of the article tucked in at the end there.