WebKit As Broken As Older IE Versions? 213
Posted
by
Soulskill
from the somebody-else-will-fix-it dept.
from the somebody-else-will-fix-it dept.
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?"
I can say, after having upgraded to mountain lion (Score:3, Interesting)
Re: (Score:2, Interesting)
Re:I can say, after having upgraded to mountain li (Score:5, Informative)
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 [apple.com]
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.
Re: (Score:3)
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.
Re: (Score:2)
Can you write up a bug at bugreport.apple.com with specifics of your hardware config, sites you see it on, etc.?
Re: (Score:2)
Already did.
Re: (Score:2)
197 replies on an Apple.com thread in 6+ months is indicative of an extremely small problem, I'd say, given the sample size of users running mountain lion. Personally, I've had my fair share of issues with my rMBP, but not this one, yet (knocking on wood...). Safari is my primary browser, too.
Also, users on the thread you link to clearly indicate the problem happens to them on prev-gen macbooks (i.e. non-retina) too.
Re: (Score:2)
Re: (Score:2)
Most likely video drivers. I've had screen flicker, things scrolling forward, jumping back, then forward again. Granted, I'm running on a heavily modified "unsupported" MacPro1,1, so not especially surprising in my case.
Re:I can say, after having upgraded to mountain li (Score:4, Insightful)
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.
Re:I can say, after having upgraded to mountain li (Score:4, Interesting)
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.
"i'm all for competition" (Score:2, Insightful)
Seeing as you need to use a Microsoft system to run any form of IE, then you have no competition with any other browser on other systems.
Re: (Score:2)
There were a versions of IE4 for Mac, Solaris and HP-UX.
Re: (Score:2)
Re: (Score:3, Insightful)
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 [rdeeson.com] . 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?
Re: (Score:2)
Please read what I wrote again. I don't think you understood it properly.
Except Internet Explorer Does not compete. (Score:2, Interesting)
Internet Explorer is bundled [not replaceable] on one platform Microsoft's. To compete it needs to exist on other platforms and be replaceable on its [not your] OS. As it stands it continues to hold back the innovation on the Web...the polar opposite of what would have happened it real competition exists. All it is is another incompatible product. The fact that XP users are such on Internet explorer 8 says it all.
Re: (Score:2, Flamebait)
How is it not replaceable? none of my customers, family, nor myself has IE on Windows as i uninstalled it and gave them their choice of Dragon or IceDragon. All that is left when you toss IE is the parts of the rendering engine used by HTML based help files that won't run without the IE engine but other than that little part its like IE never existed on our systems. And as others pointed out you no longer need crossover to run IE on Linux or mac, they have a pre-packed version you can easily run on those pl
Re: (Score:2)
IE is also tied to one platform, and even worse, tied to a certain version of the OS it is running on. People can perfectly well run either Chrome, Opera, Firefox etc on their XP, Vista and later machines, but if
Re:I can say, after having upgraded to mountain li (Score:5, Insightful)
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.
Re:I can say, after having upgraded to mountain li (Score:5, Informative)
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.
Re: (Score:2)
Very true - in fact IE4 was actually way more stable than NS4, and IE5 was a revelation when it came out. It wasn't that MS just used underhand practices (though they certainly did) but their browsers just had better engines. NS5 was terrible. they attempted to correct the biggest problem with NS4 which was that resizing it with JS and dynamic content would either crash the browser completely, or kill the JS engine and screw up the layout (unless you used the proprietary tag). IE4 at the time had no proble
Re: (Score:2)
Re: (Score:2)
Mozilla - the Official Opposition Party
New Math (Score:2)
Absolutely. If Opera were at an overwhelming 3% usage instead of just a stout 2%, this would already be done and dusted.
/s
Re: (Score:2)
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
What on earth are you talking about, IE still has 55% of the marketshare [netmarketshare.com] how on earth is webkit the dominant rendering engine at 17%-25% ? and how would a 2-3% market share that opera has make any difference?
having any dominant engine is bad, as you go from standards directing engines to the dominant engine imposing "standards".
There will always be one engine that has the biggest market share, what, you want them to be split evenly? There is absolutely nothing wrong with this. And it is very nice if the dominant engine was open source and anybody could use it for their own browser, because that will significantly lower the
Re: (Score:2)
Chrome and Safari have... unauthorized patches? At least that was the last time I checked either of them. There might be some "support", but make no mistake: Google doesn't want you to have AdBlock. And Apple doesn't want you to have anything that sets off their NIH alarm.
As for the rest, I haven't bothered with an alternative browser in years. Firefox is open enough, configurable enough, and extendable enough to meet all of my needs. When it becomes troublesome and has true alternatives that aren't, then I'll look for another browser.
Chrome has had extensions (including AdBlock) for quite some time now.
Web developers hate IE (Score:5, Informative)
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.
Re:Web developers hate IE (Score:5, Insightful)
"If you don't hate IE, then you haven't been building websites."
First website I built was around 20 years ago. Last website I built completed a couple of weeks ago.
I've been through pretty much every version of IE, Netscape, Firefox, Chrome, Opera, Safari, (and Mozaic). If you're not charging clients extra now for IE6/7 support, then you really need to look at your business practices. I don't "hate" any platform; I just charge clients if they need a platform supported. Of course, you're free to go on some religious or idealogical crusade in your spare time if you like, but getting emotional about a browser doesn't make much sense.
It's funny to me to hear people claiming IE6 is incapable of rending content etc, when we were making arcade style games, windowing systems, AJAX style requests (piggybacking data in cookies from image src requests) back with IE4 and NS4.
tl;dr Charge clients for the extra work, or get new clients. Don't work for free and then moan about it.
Re: (Score:2)
I stand corrected re building websites. However, you are granting my point. While IE6/7 can be ignored now, for years they were the "standard." It would not have been possible, then, to tell corporate clients: "The price for building your website is $X, but if you want it to look right on the PCs in your office, the price will be $X+10%." That extra 10% was just an extra cost of doing business, and an extra aggravation, in a world with IE6/7. My dislike for those browsers is not "religious or idealogical,"
Re: (Score:2)
I thought I was pretty much opposing your point. If you have to do more work for a client, charge them for it. It's like any piece of software development; agreeing the deployment platform(s) is a fundamental part of the technical planning stage. If I'm working on a mobile app, I need to know whether it's Android or iOS (or both), for embedded work I need to know the hardware platforms. For web development, the server architecture and browser/device support are pretty much top of the list. I always try to f
Re: (Score:2)
s/Do want/Don't want/ - doh!
Re: (Score:2, Funny)
Of course, you're free to go on some religious or idealogical crusade in your spare time if you like, but getting emotional about a browser doesn't make much sense.
You should use a better browser. It would have pointed out that spelling mistake for you, and even suggested the correct spelling. ;-)
Re: (Score:2)
I hate them all. Every browser out there either doesn't implement everything they should, or does so with bugs.
Firefox - Didn't support text-overflow until very recently. Of course most browsers still have issues with implementing it as per W3C draft that supports multiple lines. Improper calc() implementation, for example, 50%-30px fails and calculates to 20%, even when 1%!=1px.
Safari - Has issues with table layouts that may collapse to 0 width. Issues with column layouts.
Chrome - Too numerous to list.
Re: (Score:2)
Add firefox has an issue where an element with a margin contained in another element will use it's margin to space it away from any content outside of the container, and ignore the container, unless the container has a border or some combination there of. I reworked the section instead of trying to figure out the exact cause, but it only exhibited this problem in firefox, including 18.0.2.
Re: (Score:2)
The problem with IE is that it's hard to test, since both IE and Trident are not available for most platforms.
Out of all the PCs where I work and at home, none run windows, so it's not easy to test IE, while I can test Chrom{e,ium}, Firefox, Opera, etc on almost any desktop OS.
Re: (Score:2)
As I mentioned above. MS make VM images available to test content in various versions of IE for free. These can be used on OSX or Linux (and probably any other platform that supports the VMI format they use). Safari isn't available for Linux either, in case you forgot.
Re: (Score:2)
Safari uses webkit, and testing in chromium will usually suffice (I haven't come across safari-specific issues that can't be reproduced in chromium either).
And, yeah, sure, one of my development laptops has 1GiB RAM, another is a PowerPC. I can't even run a windoze VM there. I wouldn't do it if I could either.
Re: (Score:2)
You can easily run a windows VM on a machine with 1GB of Ram. I can run a windows VM on a Windows host with half that, and I suspect I could do it on a machine with 384MB or less, but I haven't tried.
Re: (Score:2)
Not being rude, but if you can't spend £150 or so on a PC with 4GB RAM for development, you're not charging your clients enough! Sounds like that laptop is so old it probably came with a version of Windows with IE5/6 on it anyway!
Re: (Score:3)
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.
Re: (Score:2)
I think it's a bit unfair to bash it and call it crap because you haven't spent any time using it. It actually has a very good console, profiler and step-through debugger that's at least as good as Firebug, or the Web Developer plug-in for FF. Personally I develop with Firefox or Chrome when I'm on web projects, but I have taken the time to find my way around IE's debugging tools too.
Re: (Score:2)
Nice to see I'm not the only one saying diversity is a GOOD thing. I hated when we had "Works best in IE 6" and I'll rail against "Works best in Webkit" because its bad for everybody...well except the malware writers, the day Webkit is the only one standing they'll probably be popping champagne corks because it will give them a big juicy target that runs everywhere.
While I haven't used IE since the days of the Mozilla Suite beta (I hated the UI of IE and having a giant target painted on it didn't make it an
Re: (Score:2, Insightful)
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.
Re:I can say, after having upgraded to mountain li (Score:5, Insightful)
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.
Hmmm (Score:3, Insightful)
Re:Hmmm (Score:4, Funny)
Betteridge's law of headlines: Any headline which ends in a question mark can be answered by the word no". [wikipedia.org]
Re: (Score:3, Funny)
I can see a front page paper now:
Is Betteridge's Law of Headlines True?
Peter Kasting's answer (Score:5, Insightful)
If you read TFA (haha!) make sure to scroll down to the comment of Pater Kasting (Chrome dev).
Re:Peter Kasting's answer (Score:5, Interesting)
Speaking as another professional web guy who's extremely frustrated with the current situation for very much the reasons in TFA, I find comments like Kasting's frustrating. Yes, there are bug reports. Yes, they have been there for a while, many years in some cases. Yes, the bugs are sometimes in really basic, everyday functionality. Yes, Chrome is by far the worst major browser for reliability based on the objective bug tracking metrics across all the projects I work on. Yes, it has been so consistently for a long time. And yes, there are comments on quite a few of those bug reports making it clear that even glaring problems aren't going to get fixed any time soon despite the developers being well aware of them. In my experience, absolutely everything Methvin said is true, and actually he's being rather kind.
Unfortunately, on most forums, if you suggest that this is the reality, even backing it up with citations of numerous bugs in basic functionality and even citing specific records in the relevant bug databases that go back years, it's a good bet that you'll be downvoted/moderated into oblivion, or just face the kind of "What, really?" reply Kasting posted as if it's hard to believe the almighty Chrome could actually be as bad as it is. This is the stereotype geek/OSS fanboi issue, where no amount of facts and actual evidence matter in most discussions.
I've given up even trying to file bugs for everything I find now. I'm sorry, I know it's not constructive, but my clients don't pay me to be someone else's beta tester, and since Chrome is often beta quality software I really would be spending a significant amount of my working hours just doing that.
Instead, these days we just say that we write to established web standards where possible but the only browsers we'll support officially are recent versions of IE. While these 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, and the necessary workarounds are well-established and stable because the goalposts don't move every six weeks. That's worth far more to someone developing real software for real clients than scoring X% in some artificial benchmark for supporting standards that don't exist yet, where X% is the box-ticking score but not the number of features that actually work.
Charge who? Google and Mozilla? (Score:3)
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
Re: (Score:2)
If you read TFA (haha!) make sure to scroll down to the comment of Pater Kasting (Chrome dev).
BTW, it was bit hard to find this, partly because it wasn't clear which of the two TFAs you were referring to (it's the first link to Methvin's blog post), so here's the response:
Re: (Score:2)
You are right. The amazing thing is that there is a ton of css embedded right in the html, so it would be trivial to fix. And they already mixed content and layout, so no (additional) harm done. And all it does is add a gradient to the sides of the page.
Re: (Score:2, Informative)
Peter Kasting said...
I'm a Chromium developer. It's not clear from your blog post: are the majority of the bugs you're complaining about things that are still broken on the WebKit trunk? Or things that you have to hack around because of the number of out-of-date WebKit-based UAs? If the former, are there bugs on file at bugs.webkit.org?
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.
And semi-answer from the article:
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
IOW, "OMG, people use rare UAs with outdated engine versions while main branch gets them fixed, and it's totally the same as when we waited 5 years between IE6 and IE7 and 3 between IE7 and 8 to get at least partial support of web standards and some engine fixes!"
Re: (Score:2)
And that was a perfect answer, because the problem is that some web developers are happy because there will me more webkit based browsers, thinking they will need to test less and this example shows that it doesn't matter if everyone use the same engine if everyone has forked versions with new bugs or old versions with old bugs
Whether WebKit is "broken" or not (Score:5, Interesting)
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.
Re: (Score:2)
Market share is not the only way to make a difference. Opera mattered because they were at the forefront of innovation, they came up with the stuff the others followed. That said, they are still going to develop Webkit, so this is not necessarily bad news. Also, Webkit being opensource it's not really possible to exploit its monopoly in any way, it would be just forked.
Re: (Score:3)
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.
I also have never cared about Opera as a web developer. However, the fact that they will now contribute to one of the three major engines, having a history of caring about web standards may end up being good for everyone.
While most are happy to cheer for IE's demise (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Yes, some of it is left behind for the Win OS to function, but the browsing capabilities/engine are taken out.
5 year old bug? (Score:4, Interesting)
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 [nist.gov]
[2] - http://web.nvd.nist.gov/view/vuln/search-results?query=jquery&search_type=all&cves=on [nist.gov]
As somebody whose life got destroyed by IE: (Score:2, Interesting)
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 iTar
Anti-competition (Score:2)
I might hate IE to death, but I would defend its right to exist to the grave for monopoly-weakening reasons right now.
Except Microsoft does not compete is abusively bundles IE, The damaged caused by Microsoft set innovation in the web space back years, if IE was a cross platform browser, not welded to their [not your] Operating system, I would agree. Unfortunately it only pollutes standards, without any of the positives that competition brings. Firefox and Chrome [and Opera] have been ahead for so long now its not even funny any more.
IE explorer should be destroyed with fire. So competition can continue unabated.
Re: (Score:2)
Monopoly? Perhaps the term you're looking for is "monoculture". No one has, or is ever likely to gain, a monopoly on Webkit. But, as Webkit grows more popular and pervasive, we could find ourselves with an unhealthy monoculture.
Of course, even that possibility is rather weak, because so many different people, for several different organizations, work on Webkit.
Re: (Score:3)
Monoculture goes hand in hand with standardization. You want things to work the same from system to system.
The only problem is when the dominant platform fails to implement the standard properly. But it's unfair to talk about "monoculture" as a fundamentally bad thing when we're talking about basic infrastructure--which HTML rendering is, in terms of making the Web work.
Re: (Score:2)
If Unite had been such a killer feature, it wouldn't have been dumped. Evidently, hardly anyone actually ended up using Unite once the hype died down.
Declaring Opera as dead as Nokia is weird to say the least. Nokia ditched their dying platform for a dead platform (Windows Phone still doesn't sell!). Opera is ditching their platform which is
So let me get this straight... (Score:5, Insightful)
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.
Re:So let me get this straight... (Score:5, Informative)
I'm the author.
So let ME get this straight: I get paid nothing for my work on jQuery, where we clean up behind all the major browsers so that people don't need to wait months or years for bugs to be fixed. We also report these bugs to the appropriate vendors with clear test cases; as you can imagine we get our share of crappy bug reports and don't want to do that to these guys. You would also like me to donate more time to become an expert at Webkit to the point where I can fix these bugs immediately on their side, despite the fact that several major well-funded companies (Google, Apple, BlackBerry, and now Opera) are paying people to (NOT) fix these bugs. Sorry, but one unpaid volunteer open-source job is enough for me.
I would love for all the WebKit contributors to get together and say, "We'll show that guy! HAHA we fixed all your bugs so THERE!" There are rumors, however, that Opera is laying off 200 engineers and I seriously doubt they'll keep a large staff of people on fixing WebKit bugs. I've emailed Peter Kasting privately and think he is sincere in trying to get some of these fixed though.
Re: (Score:2)
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.
So, by your reasoning, Opera, Apple and Google should all contribute workarounds for their respective browsers to jQuery as well? Methvin seems to have his own high profile Free and Open Source project to sink his time into so expecting him to contribute fixes to Webkit isn't any more reasonable than expecting Webkit authors to contribute fixes to jQuery. While people from either project contributing directly to the other may happen, it's probably not usually the best use of either side's time.
This is not a
Re: (Score:3)
...so don't write good C/C++.
Write a clear description of the problem, make an effort to understand the codebase you're complaining about, and figure out the right way to approach the problem that would fix the bug. Write it in plain English, then ask that someone implement it is proper well-written C/C++. That takes care of half of the debugging work, and shows that you're actually interested in seeing the problem resolved, rather than just reporting that odd thing you saw that one time.
My point is that if
Re: (Score:2)
make an effort to understand the codebase you're complaining about
In my experience, it typically takes 6-12 months for a professional software engineer joining a new large project to find their way around the codebase. And that's assuming they're doing it at work, probably with a mentor assigned to help them find their way and with other people within walking distance to ask for help on the tricky parts.
It simply isn't reasonable to expect people to understand the code base, or even the internal architecture, of a vast project like a modern web browser just in order to ge
Re: (Score:2)
To paraphrase a Chromium dev who commented on the article, what bugs? Nothing actionable was presented. It's one thing to wave our hands and talk about bugs, but we need to be able to point to specific things if we want anything to get done. Grousing for the sake of grousing solves nothing. In the case of IE's ancient bugs, those ones were well-documented, well-known by wide swaths of developers and users, and yet continued to go un-repaired release after release. That's quite a bit different from WebKit's
Re: (Score:2)
I think this blog post is only the beginning of the conversation. Hopefully, the invitation for discussion of details results in something constructive.
Jesus, what a crappy headline. (Score:5, Insightful)
"WebKit As Broken As Older IE Versions?"
Yes! Because any two things that are not perfect are equally bad. :-|
Re:Jesus, what a crappy headline. (Score:5, Funny)
On the Internet, it's Nazi's all the way down.
Quirky CSS (Score:2)
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:
"broken" isn't always bad (Score:3)
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.
Chrome is meh (Score:2)
Re:No really, it's jQuery that's broken (Score:5, Insightful)
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.
Re:No really, it's jQuery that's broken (Score:4, Insightful)
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.
Re: (Score:2)
Being that the reason that old school programmers make their own frameworks? :-)
Because they needed to fit an operating system in 14KB.
Re: (Score:2)
When you do real programming, do you implement your own printf()?
Because they needed to fit an operating system in 14KB.
Yes. When I wrote a Operating System tool (for a embedded application using Freescale's FlexOS), I did. Since I didn't needed a full blown printf implementation, I was able to save some precious kbytes, invaluable resource to be spent on code that make the user happier.
Look, pal. Read carefully what I said before; "When you spend less time writing your own framework than trying to use an already stablished one".
In absolutely no moment I even implied that every framework is evil.
Re: (Score:2)
Usually, frameworks are not written and maintained by one person. And thus, you are free to worry about your own code and its bugs, and have others worry about the framework's bugs (within reason, for crucial bugs you will of course need to worry about finding a viable workaround). Code reuse is a good thing, and no single person is smarter than > 1 person.
Also, frameworks do not usually change completely in less than a year, and the change that does happen is gradual - as long as you keep the framework you use up to date the learning curve is flat.
Yeah. Wordpress is the most secure platform to develop on, right?
The bigger the framework, more useless (for your current application) code on it. Code that can have bugs itself, and since you didn't wrote the code, you're just screwed up unless fix it yourself (what you probably would do faster if you were using your own).
If frameworks would usually change in less than a year, we would probably had less problems. But you're right, frameworks don't change in less than a year. Browsers, Operating Systems, Co
Re: (Score:2, Insightful)
Loading a 80KB library and adding yet another layer of interpreted code for something that takes five lines of javascript is also stupid.
What's worst is libraries that require jQuery to do stupid stuff like cross-fading. The browser doesn't support it? Screw it and just switch the images. If the browser is too old, the hardware is probably too old to do a smooth cross-fading too anyway.
Re: (Score:2, Informative)
Re: (Score:3)
Re:No really, it's jQuery that's broken (Score:5, Insightful)
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.
Re: (Score:2)
Let him say that to his customers and see how long they remain customers.
Re: (Score:2)
And when I'm spending time replicating jquery? Sure I can do it by hand, but tools like jquery can in many 'simple' cases make my development faster. The framework is probably going to be there anyways (designer might want it for part of his theme, etc). And unlike my scripts, by leveraging google to provide jquery, it is probably already cached on their browser.
Re: (Score:2)
So 90% of your time is spend writing things like "document.getElementById()"?
Re: (Score:2)
WTF? You clearly do not understand the purpose of using frameworks.
Re:No really, it's jQuery that's broken (Score:5, Insightful)
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.
Re:No really, it's jQuery that's broken (Score:4, Insightful)
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.
Re: (Score:2)
I hate to say it but web developers need to stop using "frameworks" and "libraries" to do simple things.
There's so many websites that load jQuery or TinyMCE for no good reason other than the developer was lazy.
I code everything by hand, if it doesn't work in some browser, then that browser's implementation is broken. There should be no need to write against jQuery and assume that the underlying browser isn't braindead or futureproof. If you're writing against the standards for HTML5, CSS3 and the DOM, then you're better off writing your own code. If you're just a code monkey who can be replaced at a moments notice, then by all means write against stupid frameworks so that you're easily replaced.
You obviously relish saying the above. However, the fact that many developers misuse jQuery is not a valid argument against jQuery itself any more than the fact that buffer overflows are rampant is argument against C or the fact that so many people write entire business applications in spreadsheets is an argument against the existence of spreadsheets.
Your argument also entirely misses the point, which is that Javascript code, whether in a widely used library or something you wrote just for your site, must f
Re: (Score:2)
Almost everyone agrees that the idea of frameworks is good.
Almost everyone used to agree that the world was flat. We know better now.
HTML, CSS and JavaScript can now do many of the basic jobs that used to make the popular frameworks and plug-ins useful, as standard. If you need to support older browsers that don't include the necessary functionality as standard, you can use a polyfill approach to get exactly what you need with minimal overheads.
I wouldn't necessarily go as far as the original AC who codes everything by hand, as I have no problem with using a librar
Re: (Score:3)
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.
Re: (Score:2)
You'll see it posted again (verbatim, most likely) in four or five days. And the commenters will be skewed the opposite direction in terms of support for the article.
Re: (Score:2)
Git off mah lawn!
Re: (Score:2)
jquery is a javascript library, but almost everything its doing is DOM manipulation, and I beleive the DOM part of it is part of the rendering engine?
I didn't look into it, but that would be how you could blame the rendering engine for affecting jquery.