With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change.
We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging: "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions." I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different.
Opera did land their first WebKit patch so they wanted to make a statement that they weren't getting out of core browser development altogether. Then again, the age of that bug just underscores one of the problems with WebKit. It took five and a half years to make a half-line fix! Now as a first commit it's a great one for the Opera team, since it lets them get the feel of the system and of course they had to write a few more lines of unit tests. But five years? Why so long to fix a trivial bug? Because fixing bugs doesn't make news.
Each release of Chrome or Safari generates excitement about new bleeding-edge features; nobody seems to worry about the stuff that's already (still!) broken. jQuery Core has more lines of fixes and patches for WebKit than any other browser. In general these are not recent regressions, but long-standing problems that have yet to be addressed. Opera probably doesn't have any more incentive to fix the common bugs than any of the other diners at the WebKit table -- especially when jQuery continues to cover up these mistakes. Instead, Opera will want to focus on their own bleeding-edge unique features, all while people complain about jQuery's "bloat".
When we started our jQuery 2.0 cleanup to remove IE 6/7/8 hacks, we were optimistic that we would also be able to remove some bloat from lingering patches needed for really old browsers like Safari 2. But several of those WebKit hacks still remain. Even when they have been fixed in the latest Chrome or Safari, older WebKit implementations like PhantomJS and UIWebView still don't have the fix. We've had to put back several of these as users reported problems with the beta. It's starting to feel like oldIE all over again, but with a different set of excuses for why nothing can be fixed.
We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging: "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions." I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different.
Opera did land their first WebKit patch so they wanted to make a statement that they weren't getting out of core browser development altogether. Then again, the age of that bug just underscores one of the problems with WebKit. It took five and a half years to make a half-line fix! Now as a first commit it's a great one for the Opera team, since it lets them get the feel of the system and of course they had to write a few more lines of unit tests. But five years? Why so long to fix a trivial bug? Because fixing bugs doesn't make news.
Each release of Chrome or Safari generates excitement about new bleeding-edge features; nobody seems to worry about the stuff that's already (still!) broken. jQuery Core has more lines of fixes and patches for WebKit than any other browser. In general these are not recent regressions, but long-standing problems that have yet to be addressed. Opera probably doesn't have any more incentive to fix the common bugs than any of the other diners at the WebKit table -- especially when jQuery continues to cover up these mistakes. Instead, Opera will want to focus on their own bleeding-edge unique features, all while people complain about jQuery's "bloat".
When we started our jQuery 2.0 cleanup to remove IE 6/7/8 hacks, we were optimistic that we would also be able to remove some bloat from lingering patches needed for really old browsers like Safari 2. But several of those WebKit hacks still remain. Even when they have been fixed in the latest Chrome or Safari, older WebKit implementations like PhantomJS and UIWebView still don't have the fix. We've had to put back several of these as users reported problems with the beta. It's starting to feel like oldIE all over again, but with a different set of excuses for why nothing can be fixed.
Comments
No, because it was a corner case bug that didn't affect anybody much, and the specs weren't clear even if it was a bug in the first place.
Maybe try reading the discussion under the bug fix on the tracker page.
The original paper by Garrett Hardin simply explored the idea. He did not use real data and it was not scientific in any way. It was a thought experiment. And generally proven wrong.
Why it it relevant to mention this? Because the article mentioned here about Webkit references it in some attempt to connect it to the idea that Open Source or Free Software is an example of Garrett's argument.
However, if anything, WebKit is a counter example in an interesting way. One typical example of given to TOC is global fishing. However, if anything, global fishing is an example of large corporations exploiting a resource owned by nobody (vs a resourced owned in common). In a similar fashion, WebKit might be an example of corporations exploiting code owned by nobody.
Incidentally, this is not the case for many Free Software projects (vs Open Source). Because Free Software projects ARE owned by a group of people in common. And typically the governing structure is less exploitative, and more cooperative than corporate controlled projects like WebKit.
I ask this because we spend a lot of time fixing bugs in each release, and if there are major problems we're missing, then I'd like to ensure they get triaged and investigated properly. But the complaint you write here isn't really actionable, because it's short on details.
Feel free to ping me directly -- pkasting@google.com -- and I will try to ensure someone takes a look at your issues.
Personally I wish canvas mouse location handling was done more consistently.
But watch out, the last ACID test focused on functionality that was controversial, or less than important. Mozilla was right not to prioritize their effect to solving the acid test. They had their own tests.
Furthermore webkit pisses me off because webdevs think they aim for 1 platform. You can't. Please recognize the web is defined by standards, please adhere to them, and please respect your users. They don't use chromium, they don't use opera, they don't use safari, they don't use firefox, they don't use IE.
WebKit isn't a browser, but a rendering engine, used by countless browsers. To compare an engine and other browsers seems like a dirty trick to exaggerate the numbers.
That said: Yeah, there still are many old bugs that need to be fixed. Most of them are corner cases, which don't affect too many users. But that makes it even worse, when you are one of those affected.
But even with that being true: This article isn't worth reading, even for a rambling.
The example of the lake is simply a case of more dilution. Doesn't the lake belong to the people of the country?
So now we have Safari, Chrome, Opera and other small players all using webkit. This is dangerous and it means the only big player left is Firefox to keep things dynamic. I can see it now, that Microsoft decides to change the browser core to webkit (since they are heading down to 15% share) and then we can really be in webkit hell.
I will stick with Firefox and encourage other to do the same to avoid this if at all possible.
The biggest issues in my experience are poorly defined points of the specifications and the tendency to remove features from the specs if they decide they're not being implemented fast enough. To much design by committee goes on instead of just having someone in charge.
I'll agree with other comments that to often exciting big features get all the attention while nobody works on the small things that would actually be more useful to most developers. This happens as much at the spec level as at the code level.
The other issue I've had is that developers are unwilling to change the spec to add new features, or fixes to bad specs, without getting something pushed through as the actual spec. I can understand the hesitation but it makes it difficult to advance things that might be useful or at least worth exploring.
(One example: I've several times tried suggesting an option for the password field to make it hash the username, domain name, and password together and submit this hash instead of the plaintext to the web server. Seems this would be helpful in stopping most password security issues but every response I've got has been negative. And it could end the annoying feature of most websites where they require some idiot specific combinations of characters required. You could even have a single password used everywhere in that case as it'd be salted before submission.)
First, of course it doesn't prevent replay attacks on the same site if someone intercepts network packets.
Second, site names may not be fixed. A site might rebrand or be accessible under more than one domain name, or a login might work across different sites (aol.com/aim.com, hotmail.com/live.com/msn.com, google.com/gmail.com, etc.) So the sites need to help by providing the authoritative, constant site name to use, otherwise this would need to be omitted for salting purposes, which makes the username/pw combo no longer unique across sites (as many users reuse both their username and password).
Third, users may log in from different devices, all of which would need to support this standard, and use the same exact hashing function. Until virtually all browsers support it, it really can't be used at all.
It would be a great idea for individual sites to implement in javascript, but that might be asking a lot, as so many don't even get the basics right (storing passwords in plaintext, not using ssl, etc.)