One of the things that killed Macromedia Director Schockwave (remember that?) which was in many respects superior to Flash (SWF stands for "shockwave flash" -- Flash originally rode on Director's coat-tails) was too-frequent releases. As a Director coder you never knew what platform you needed to target and the end-user experience usually comprised being pestered to update their plugin before seeing your content.
Flash forward to 2010-11 and Google is doing the same thing with Android and Chrome (and Firefox is following suit). This is actually a BAD thing, even though we all have broadband, etc. now.
There's some kind of happy medium between significant, reasonably well-paced releases and shoving stuff out the door constantly.
"Real artists ship," but they don't spam you with incremental releases.
I am not aware newer browsers break backwards compatibility. Newer browsers usually work better at the things they were already good at. If you want to target a larger audience, pull your analytics and draw your line at the set you want to serve. Usually any reasonable line will cover mostly everybody.
This is the kind of excuse Microsoft uses - when you can't improve your software, you call it "stable" and "mature".
It's really not that hard to find examples of this. Chrome recently broke rounded corners, and they're about to break h.264 video. But it's certainly more fun to attack Microsoft in every post.
Chrome did not "break" rounded corners, they are various cases in which they arent perfect, but every time someone makes this argument they just point to "search the chrome bug tracker" as opposed to giving a specific breakage
They have decided not to support h.264 at a time when every developer had to already have implemented a fallback anyway, again its not broken.
> Chrome did not "break" rounded corners, they are various cases in which they arent perfect, but every time someone makes this argument they just point to "search the chrome bug tracker" as opposed to giving a specific breakage
Here's an example bug where the antialiasing was screwed up:
And here's one demonstrating the (much worse) problem that you could get completely different colours showing through, although the screenshot isn't great because it only shows a small issue, not the much more offensive result if you had a larger corner radius:
Spending literally one minute with Google would find you numerous related problems with screenshots attached.
Pretending this wasn't a problem with Chrome and related browsers is like an IE fan pretending that no-one ever really needed CSS hacks because (insert excuse here). There were numerous complaints about this for several months from practising web developers.
> They have decided not to support h.264 at a time when every developer had to already have implemented a fallback anyway, again its not broken.
If we all have to implement fallbacks anyway, why bother supporting any modern browser features at all?
They had H.264 support. They took it away. That means stuff that used to work in Chrome won't any more. It doesn't matter what words you use to describe that situation, the result is still the same.
You just repeated what I said, yes there are edge cases that are broken, no they are not entirely broken.
> If we all have to implement fallbacks anyway, why bother supporting any modern browser features at all?
because graceful degredation is how the web works, if we enforced every browser implemented every single thing exactly the same way then nothing would ever happen.
since firefox will never have implemented h264, chrome removing it is a step towards a consistent platform, not away from it.
Considering the repeatedly defensive position about ie and bringing up fairly minor points to criticize chrome, plus the fact you replied to this hours after it went of the first few pages, are you really not Elepsis and a microsoft employee?
I criticise Chrome because I don't think their approach is a sustainable one. As it happens, I have been on the wrong side of exactly that bug when it came to a client demo, and apparently what you regard as "not entirely broken" is different to what my paying clients regard as such.
As I told you in the other thread, I have nothing to do with Microsoft. Not everyone who disagrees with you, or indeed with the majority opinion in any given discussion, is a troll/sockpuppet/astroturfer. And this discussion is still on my HN home page right now, never mind when I posted my previous comment several hours ago.
h.264 was never a standard for browsers to implement. It is widely in use, yes, but not a standard. This is why there was such a huge issue over <video>, because Firefox, Opera, and Chrome didn't want h.264 in the standard.
Firefox and Opera have much larger marketshare, and they weren't implementing h.264. It was DOA as a "standard" long before Chrome dropped it.
No, it's not. There is a reason not to implement h.264 - it's patent encumbered and eventually there will be licensing costs that will make free implementations impossible.
There is a difference when company G takes a stand against a bad standard and company M that can't implement simple features correctly despite the fact that it can dedicate humongous resources to its development.
Yes, it is inconvenient, but I'd say it's more justified than the IE inconvenience. They didn't implement h264 because of concerns about how it would restrict distribution, worries about fees, and the fear of another patent encumbered (aka "free") format become standard. Microsoft didn't implement these features pretty much every other browser has because of...what, time constraints?
I think that might be true in cases where you're not building on such a widely distributed and incredibly backwards-compatible / gracefully-degrading platform such as the web.
That causes issues for being able to use the latest features, which is somewhat of a problem, but should not affect backwards compatibility. It means you have to possibly be aware of the OS features you use in your apps, but you don't have to worry about updating them due to some API being deprecated.
Shockwave / Flash / nearly every other application in the world tells you your software is old, and asks if you want to update it, and it will keep telling you this until you check the "don't tell me again" box. Which few people do. So instead they get irritated that it always pops up, and get used to clicking "no" because they didn't want to deal with it then, and don't want to deal with it now. A year passes, they get a virus through an old exploit, and they blame the software instead of their habits / their IT department's dogma (which is not always incorrect, but frequently problematic).
Chrome, on the other hand, keeps itself up-to-date in the background, at all times, and doesn't ask you to deal with it. It doesn't even inform you it's doing so, aside from a minuscule little up-arrow on the wrench that disappears on the next launch - no progress bars, no delay, no "restart now", no alerts, nothing. There's no question if someone's using version X or Y; they have the latest of their branch. Period. Or they'll get it in a day or two, and problem solved.
Transparent updates, especially when they're nigh-totally transparent, are in an entirely different world than "do you want to update yes/no/cancel". It's apples and granite, or oranges and wolverines - there's no comparison ("apples are sweeter than wolverines").
> Transparent updates, especially when they're nigh-totally transparent, are in an entirely different world than "do you want to update yes/no/cancel"
Transparent updates are great, until something goes wrong. What happens if someone manages to hijack the DNS entry to make 50 million Chrome installations download an update from a poisoned well? Or Google's quality control misses something and pushes out a buggy update that breaks Chrome's ability to reconnect and obtain a fix for that update? (This has already happened to companies the size of Skype and McAfee.) Or an update simply introduces a behavior that users don't want, like Microsoft using Windows Update to inflict WGA everywhere.
The net benefit of transparent updates is still probably greater than explicit updates, but both ways have costs and we shouldn't pretend that either is zero.
Don't those same problems also exist for explicit updates?
I suppose it's a mitigating factor on the part of requiring user opt-in, should a problem occur, but that's (IMO) only a fortunate side-effect. It's like saying that walking is better than driving, because if you run into something you'll only bruise your shins.
The problem with automatic and invisible update is this:
say you are using chrome in your company as the interface to an internal tool of some sort. Since the tool is used internally it's messy and one day chrome changes and now, automatically and invisibly, no-one can use it.
I'm not saying chrome's way doesn't have its upsides but there is also a good argument for mantaining older releases.
Point taken, but standard practice is to write correct code for a CSS bug, then write a 'hack' that works for that specific browser version.
On the other hand, if you're doing an intranet site with a company that only has one browser, you might have dispensed with writing correct code and only written the hack.
Its' temporarily practical in a time crunch, but not a good practice since the next update may kill your hack.
Note that there are also other cases where incompatible changes are made (e.g. ES5 is not exactly compatible with ES3 in various edge cases, CSS2.1 today is not quite compatible with CSS2.1 a year ago in edge cases, etc). The various standards groups an implementors try to minimize the damage from such changes, but it still happens at times.
Heck, Chrome 9 or 10, made major changes to the HTML parser to follow the HTML5 draft. Sites that depended on the old behavior (which different between browsers, so they presumably browser-sniffed and then sent different content to different browsers) likely broke. They certainly did in Firefox when Firefox changed to the HTML5 parsing algorithm.
This happens in the wild with Java updates. We have been burned twice with minor point versions that broke our app, that were pushed out automatically.
My impression was always that Macromedia acquired FutureSplash (shortened to Flash) when it became clear it could kill Shockwave, which was much slower (14Kbps connections then). Flash also had a rapid release cycle, which did not have any negative impact in its adoption and success, releases were backwards compatible. Chrome's adoption is certainly more significant now, also not affected by many releases. For Android, I'll wait and see.
Flash forward to 2010-11 and Google is doing the same thing with Android and Chrome (and Firefox is following suit). This is actually a BAD thing, even though we all have broadband, etc. now.
There's some kind of happy medium between significant, reasonably well-paced releases and shoving stuff out the door constantly.
"Real artists ship," but they don't spam you with incremental releases.