Slashdot Mirror
WebKit As Broken As Older IE Versions?
An anonymous reader writes "It's not everyday that we get to hear about the potential downsides of using WebKit, but that's just what has happened as Dave Methvin, president of the jQuery foundation and a member of the core programming team that builds the widely used Web programming tool, lamented in a blog post yesterday. While most are happy to cheer for IE's demise, perhaps having three main browser engines is still a good thing. For those that work in the space, does the story ring true? Are we perhaps swearing at the wrong browser when implementing 'workarounds' for Firefox or IE?"
That my webkit browsers have been very poorly behaved; maybe it's just me... but images flicker, forms appear and disappear, sometimes pages just stop loading at random... each patch for mountain lion seems to repair it BRIEFLY... but it always comes back.
Isn't the answer to these always "No"?
If you read TFA (haha!) make sure to scroll down to the comment of Pater Kasting (Chrome dev).
It might be just you. I haven't noticed any of these problems, and each ML update makes Safari snappier (TM).
Must admit, although I primarily use Firefox or Chome; I have no problems at all with IE. I don't understand why people would "cheer for its demise". IE9 is a good browser, and I'm all for competition. Less competition in any space is generally bad for users, if things swing too far toward one engine we'll be in the same position we were when IE6 was the "standard" and people ended up only bothering to test on that browser. That causes stagnation.
Code, Hardware, stuff like that.
I still want to see three viable rendering engines competing in the browser world - and that's what we currently have.
I know there are a few people who live and die with Opera, but it didn't have enough market share to make any meaningful difference - its switch to WebKit is irrelevant to most of us.
#DeleteChrome
Frameworks to do simple things may be stupid, but it's just as stupid to write your own code every time too. It's hard to say which one is worse, but I'm going to say it's worse to never use a framework than to always use one unless your time has no value and you always write perfect code.
The point of using jQuery and other frameworks is you don't have to re-invent the wheel every damn time you want to do something. Yes, jQuery might be misused in many situations, but in alot of cases, it simplifies the coding so you're not rewriting what is already done.
I've never been a fan of MSIE, but to say "most" would cheer for its demise seems a little gratuitous. Competition is good.
That's nothing. Look[1] how long some Flash bugs have been around, or holes in MS Word, Active-X exploites, Windows exploits... it's all a matter of how much time you have to maintain the codebase, and what you prioritize.
Things with a 98% chance of never affecting anyone will go for a long time before getting the "half-line fix" just like any other software. Yes, including jQuery[2]
[1] - http://web.nvd.nist.gov/view/vuln/search
[2] - http://web.nvd.nist.gov/view/vuln/search-results?query=jquery&search_type=all&cves=on
Join the Slashcott! Feb 10 thru Feb 17!
Yes. Yes, we are.
I might hate IE to death, but I would defend its right to exist to the grave for monopoly-weakening reasons right now.
Webkit and the WhatWG expose the exact behavior that caused all those problems and a stalling of progress back then in the first place. Growing into a quasi-monopoly, having tons of non-standards-conforming "features" (remember the marquee tag?), being the preferred choice of the dumbest and most incompetent at making an educated choice, openly going against the W3C for iTard and PHB reasons (aka: "Ooooh, shiny bling!" and "People are too dumb anyway. Remove *all* buttons and options.") and also deliberately making standards for dumb and incompetent people (by re-introducing quirks mode aka glancing-over-utter-incompetence mode aka HTML5 instead of actually telling the author when the code has errors.).
We already know that can't end well. Let us not repeat that mistake.
P.S.: Seeing Opera first dump its amazing killer feature (Opera Unite), and then dumb their core engine, is a really sad sight. I declare Opera (the company) as dead as Nokia.
That my webkit browsers have been very poorly behaved; maybe it's just me... but images flicker, forms appear and disappear, sometimes pages just stop loading at random... each patch for mountain lion seems to repair it BRIEFLY... but it always comes back.
Desktop Chrome used to be a breath of fresh air a year or two ago, but now, my experience with every new release has been worse than with the previous version. I feel probably they are ignoring it for the Mobile Android and Chrome browsers because they feel it's more important to keep their lead there.
In my current position, I have definitely had to implement at the very least twice as many Chrome workarounds as IE in the last six months. I was very surprised to see Chrome behaving oddly and Firefox and IE rendering the pages identically, as prior to that time period, I had never seen Chrome and Firefox render a page in a substantially different way.
Most of the issues have revolved around Chrome "over-reacting" to what it perceived as an XSS attack.
According to the author, Opera should spend their time and money to fix old edge-case bugs in WebKit, but he shouldn't have any obligation to contribute patches himself.
Sorry sir, but that's not how open-source development should work. If you're going to spend time rebuilding your own codebase, evaluating whether a ton of old workarounds are still necessary because of missing "half-line fix[es]", you should consider spending some of that time contributing such simple patches upstream to improve the situation. With IE, that was never an option, but it is with WebKit. In an open-source stack, the only workarounds that should be accepted as the regular course of business are ones that are prohibitively difficult to implement in the dependency, or where the patches have been submitted and rejected.
What's most entertaining is the reference to the "tragedy of the commons" in TFA's title. Tragedy of the commons is not something being so commonly used that it's improved in places you don't like. Rather, it's where everybody using the common property thinks that maintenance is someone else's problem. Mr. Methvin, WebKit's maintenance is as much your problem as it is Opera's.
You do not have a moral or legal right to do absolutely anything you want.
I code everything by hand, if it doesn't work in some browser, then that browser's implementation is broken.
You say this like that somehow is a solution.
Pretty good is actually pretty bad.
This isnt a 'WebKit' problem, this is a Mountain Lion + Safari problem. Safari started implementing a lot more things to leverage the GPU in rendering and it did not turn out very graceful.
No, it is not just him. This corruption problem with Safari is a well known problem. It appears that this problem manifests strongly in the macbook retina. There are ongoing discussions about this in many forums, including apple's own:
https://discussions.apple.com/thread/4148522?start=0&tstart=0
As reported by many testers, these problems have NOT been fixed in the soon-to-be-released 10.8.3 update, and they are still present in the Webkit nightly. If you are not experiencing such problems, the most probable reason is that you're using a non-retina display.
If I clone myself, can I call it a thread?
If a girl winks to us, can I call it a race condition?
"WebKit As Broken As Older IE Versions?"
Yes! Because any two things that are not perfect are equally bad. :-|
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Webkit is open source, with an active community that cares about standards, has an explicit policy of trying to behave like other browsers where possible...
All evidence to the contrary. The number of "broken in latest Chrome" bug reports we've had coming out of QA recently is quite alarming. Things like certain tags not appearing in the layout at all, or massive layout gaps that don't appear in any other browser.
Personally, I think Chromium is moving too fast, and now Mozilla is following. Many of the bugs we've encountered were regressions, broken in Chome say 15, fixed in 17, and then broken again in 24.
I certainly spend more time dealing with webkit quirks than IE quirks these days, thanks to the demise of IE6 and IE7.
So far, few of the visual 'bugs' I've encountered in webkit have been strictly 'non-standard'.
They pretty much ll fall into two categories:
It only simplifies things by adding something that should be in the core language anyway but that doesn't include jqueryui. Which shouldn't be core functionality nor is it that nice to use unless you want a cookie cutter site appearance. Your right in that many professions don't abuse JS but a lot of people do use it unnecessarily and often ruining performance.
Probably unrelated to TFA, but I made an amazing discovery about the webkit-based browser Rekonq 0.8 in Kubuntu 11.10 - it doesn't show commercials in streaming video. Whatever mechanism is commonly used to insert commercials into a flash video stream - it doesn't work in this version of Rekonq. I'm talking youtube, ustream, livestream, social cam sites, porn sites, and television networks that stream their own shows - no commercials ever. It's glorious =)
I'm actually reluctant to upgrade in case this "bug" has been fixed.
It's inertia. IE6 was a terrible browser. IE7 and 8 were better, but not markedly so. IE9 was a total turnaround for Microsoft, and IE10 is keeping with that trend.
However, the damage is already done. On top of it being a Microsoft product and thus being automatically terrible, dangerous and likely to cause the death of a few Linux whackjobs, its bad reputation in the past has stuck to it like a skunk's stink. Is it deserved? Not anymore, no. But you probably have noticed by now that for all our claims of technology being a fast moving sector, a lot of the people working in it are old men shouting at you to get off their lawn ;)
Opera's shift to WebKit should concern everyone. It's likely a good decision for them, but it consolidates WebKit's position as the dominant rendering engine, and having any dominant engine is bad, as you go from standards directing engines to the dominant engine imposing "standards".
Ironically, it's Firefox which is still doing its job: never the dominating browser, but always a significant enough force to stop any one browser from entirely dominating. Those who think Mozilla's outlasted their welcome should think again.
I have no problems at all with IE. I don't understand why people would "cheer for its demise".
If you don't hate IE, then you haven't been building websites. For years, the standard process for me was to write perfectly valid HTML and CSS that would render the same way in every other browser, and then spend time screwing around with it until it looked correct in IE. It added 10%, easily, to the cost of every project, and I've read of others claiming 30% or more.
Q: What does the "B." in Benoit B. Mandelbrot stand for? A: Benoit B. Mandelbrot
You obviously haven't tried very hard. There are freely available VM images to test with various versions of IE : http://www.rdeeson.com/weblog/126/how-to-run-internet-explorer-7-8-and-9-in-linux-with-or-without-wine.html . Obviously you can use them with OSX or Linux.
Probably also worth mentioning that the OSX version of Safari doesn't render exactly the same as it does on Windows. It's also not any more available for Linux than IE is. Maybe that's "untestable" too, eh?
Code, Hardware, stuff like that.
That's a little dishonest. When IE6 was released in 2001 it was quite good. There was also virtually nothing else on the market as AOL let Netscape flounder for five years and the earliest viable releases of Mozilla were still two years away and Firefox another year after that. IE6 also did quite a bit to tighten up the standards compliance at that time, including fixing the box model. Everything leading up to that point was a huge mess of feature-ramming on the parts of both AOL/Netscape and Microsoft while the W3C slowly toddled along.
What Microsoft did that was blatantly stupid was to stagnate IE for five years between 6 and 7, effectively halting the development towards better standards compliance. And while Netscape at least had the excuses of recent acquisitions and bad project management Microsoft did this quite intentionally by all-but-disbanding the IE team entirely.
IE has come a long way since then. IE9 and especially IE10 are very usable browsers in terms of speed and compliance. They're not perfect, but nothing is. What we need above everything else is an accurate measure of compliance. The W3C HTML/CSS Test Suites are the perfect avenue for that, very narrow unit tests of specific rendering functionality. The problem is that it's not as pretty or fancy as some colorful ACID test.
It has nothing to do with the retina display. I'm seeing it on the non-retina current-generation MacBook Pro. I think it is limited to a single model of Intel GPU, though, as I don't see this behavior on any other machines, and it goes away if I lock my machine to use only the NVIDIA GPU.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Frameworks to do simple things may be stupid, but it's just as stupid to write your own code every time too.
Being that the reason that old school programmers make their own frameworks? :-)
There's something very wrong when you spend less time building your own framework than learning a well known and stablished one to do your task.
You can argue that a well known and stablished framework will save time on the long run. But I will counter-argue stating that this is only true if the guy knows the framework by heart - otherwise he will be screwed up on every single mistake did by someone's else.
It's better to "waste" a little time now and in every project in the future, than to waste a huge one now and then in the hope that somewhere the future I will be able to throw up a new system every week without hassle - what's is not going to happen anyway, because in less than a year everything is changed, and things will start to break, and the cycle starts again.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Here's a few reasons to use libraries and frameworks:
1) Development speed.
2) Browser support and testing.
3) Maintenance.
I'll let you figure out how they help in those situations - and there are many other reasons, on top of those.
developers need to stop using "frameworks" and "libraries" to do simple things.
Seriously, this is a really fucking stupid thing to say. Imagine telling a C developer to re-implement printf() for every application (and every platform it will run on) that needs to print a line of output.
Must admit, although I primarily use Firefox or Chome; I have no problems at all with IE. I don't understand why people would "cheer for its demise". IE9 is a good browser,
My issue with it is developer tools. Firefox has Firebug, Chrome has Firebug-clone built-in, and IE9 has some crappy popup window when you press F12 which confuses me. I generally develop with Firefox and Chrome and tinker with things to get it working in IE.
== Jez ==
Do you miss Firefox? Try Pale Moon.
People using the wrong tools for the wrong jobs is the problem - not frameworks in general.
Laziness is one of the hallmarks of a good programmer. It's also an incredibly useful trait for aligning with management and/or a client. A programmer who saves himself having to reimplement tedious and repetitive things is a programmer that is saving money.
Eight years ago for an internal project, I wrote all my own DOM wrappers from scratch. It was fast, I knew every inch inside and out, and it worked in all DOM compliant browsers. It took a bit of foresight and prep work to get there, but the payoff was sound. There weren't a lot of options out there at the time, so this was pretty much the only option.
A year ago I started a contract job for a client. I elected to use jquery as a standardized DOM manipulation tool. The actual application code from a developer/client perspective all worked roughly the same as the hand-tooled code from before - except I didn't have to write, and more importantly bill the client, for any of that time. The jquery element traversal utilities alone will save you so much time you won't even believe it.
In the end, both projects ended up with chunk of code being loaded by the browser to make fiddling the DOM in a cross platform manner easier and more reliable for the application code. In the first case, that cost the company money. In the second case, it was 'free'. In both cases, the browser is downloading a dependency 'framework' in order for the application to function.
Culture is more than commerce
What world do you live in that non-OSS software is bug-free?
Sorry, you don't seem to have actually read what I wrote before posting your reply. Here is the relevant part again:
"Just as important, the relatively few serious bugs in the more recent versions of IE tend to be well-known, and the necessary workarounds are well-established and stable because the goalposts don't move every six weeks."
I don't see how that equates to anything like what you wrote.
On with your next point:
What, besides your own prejudice, justifies supporting a browser that you admit has some serious bugs, and also does not properly implement the web standards?
And again with the twisting of words. Here to remind you is what I actually wrote:
"While [recent versions of IE] don't have all the bleeding edge shiny, the basic functionality does generally work very reliably, and actually IE9+ have a lot of the more useful recent developments anyway. Just as important, the relatively few serious bugs in the more recent versions of IE tend to be well-known...
I put the parts you twisted in bold for you so you can see where you went wrong.
In any case, I fail to see how making decisions based on extensive practical evidence constitutes prejudice. Prejudice would be, for example, saying I was going to advocate a browser that consistently shows up more bugs in basic functionality than all the other major ones instead of IE, just because the more buggy browser is not written by Microsoft.
And there is a difference between having a feature and supporting standards. I think if you're going to claim to support a standard, the feature should actually work. Chrome has had, and in many cases continues to have, obvious and fully reported bugs in CSS rendering. These include popular CSS3 effects like gradients and rounded corners not drawing properly under various conditions. They also include basic CSS 2.1 text styling problems like the infamous letter-spacing limitations, because Chrome still relies on its own very poor text rendering rather than using the far superior tools built into various host operating systems. It's not as if these kinds of issues are big secrets; some have been in the bug tracker for years with numerous people echoing the problem.
I don't see any facts or evidence in your post -- that would presumably detract from your trolling.
I was posting in support of TFA, not trying to make an independent case of my own.
However, I have made my own case based on my own evidence on several previous occasions on this forum and elsewhere. Unfortunately, even if you cite a bunch of specific issues, the response is rarely any better than your own: someone in denial of the situation who thinks anyone criticising their beloved browser must be trolling and can't possibly have actually experienced numerous documented and repeatable bugs, even though the bug tracker is a matter of public record and mere seconds searching it would confirm the kinds of bugs people are citing.
Charge for compatibility beyond IE, and charge for any time spent submitting bug reports.
Sorry, but I'm a professional, and as such I do the job my clients hired me for. If Google would like to hire me to help test their code, I'll be happy to quote them a suitable fee like anyone else. But right now, my real, paying clients typically hire me to produce web apps that work for contractually specified targets, not to provide subsidised debugging for someone else's product.
Today, those specified targets are usually something like IE8, IE9 and IE10, because with the deliberate policy by both Google and Mozilla to avoid stable versions and push updates every few weeks, it's difficult to specify support for Chrome or Firefox in any useful way in a contract even if you do want to. Without a stable platform to test against, there is no way to write acceptance criteria that are going to be relevant for more than one release cycle of those browsers, which for many projects isn't even time to run through the QA/release process fully.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.