Why Mozilla Is Committed To Using Gecko 632
Ars Technica has published an article about Mozilla's commitment to use the Gecko rendering engine instead of using Webkit, which was adopted by Apple and Google for use in the Safari and Chrome browsers. I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox. Why is Gecko worth keeping if it is outdated and bloated?
Why use Gecko? (Score:5, Funny)
Re:Why use Gecko? (Score:5, Funny)
Re: (Score:3, Funny)
So boring, and yet so close to mass appeal! All they had to do was name it WebK.I.T.T., and bring out the 'Hoff (*shakes head*)
Re:Why use GEICO (advertisement) (Score:5, Funny)
I never heard of Amica until a friend got rear ended by one of their customers.
Well that's a novel marketing approach...
Seriously, though, perhaps they save money by not blanketing the airwaves with commercials.
lite (Score:5, Insightful)
Why is Gecko worth keeping if it is outdated and bloated?
Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit
Re:lite (Score:4, Informative)
You're confusing Firefox-the-browser with Gecko-the-renderer. There's no reason Firefox couldn't have one process per tab, and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).
In short, pick something else to distinguish them. You're way off this time around.
Re:lite (Score:5, Informative)
and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).
Firefox does not use one process per browser window. Firefox uses one process per user profile.
Re: (Score:3, Informative)
Re:lite (Score:5, Informative)
Webkit doesn't specify that you have to use a separate process for each page. That's a Google Chrome feature.
Um, are you sure of that? (Score:5, Insightful)
First of all, WebKit itself doesn't impose the multi-process model that Google's Chrome uses. For example, Safari uses WebKit, and it runs as a single process.
With that cleared up, now, here's the more important flawed assumption in your post: that having the broswer use n processes to display n pages will require n times as much memory as doing it all with n threads in one process. That's far from true, because such a browser can be architected so that the processes use shared memory for all shared resources and state.
The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.
Amendment (Score:5, Insightful)
Actually, I take that back. The only real overhead is the OS overhead for separate processes.
The architectural choice of what memory contents should be shared between processes and which should be private aren't specific to the multi-process architecture. The same choices and tradeoffs exist in a multi-threaded application; you can choose between having each thread have its own copy of some piece of memory (uses more memory, but isolates each thread from the others), or have all the threads share it (uses less memory, but access must be synchronized, and any bugs involving that shared memory may make one thread bring others down).
That comic doesn't really tell us a lot. (Score:3, Informative)
Separating the browser into one process per tab only helps for the fragmentation problem in the case of memory that is truly private to each process. It doesn't help at all in the case of memory that's shared between processes. If that shared memory is managed as a heap like malloc and free do, it can still fragment. (And it's important to point out that the shared memory doesn't need to be managed like that; a custom memory management scheme tailored precisely to the way it's used could have zero fragme
Re:lite (Score:5, Insightful)
Maybe I'm missing something, but it doesn't seem incredibly shameful to me.
Re:lite (Score:5, Insightful)
IE 8 actually a process-per-tab (almost) model, like Chrome does. The logic of how to split tabs and stuff into different processes is different, but the general idea is the same. One thing Chrome does that IE doesn't, as far as I know, is that Chrome runs plugins like Flash in a separate process, while IE still keeps them in the tab's process.
The threads vs process distinction is very important, actually. Processes each get their own address space, while threads share an address space. This means processes can't write to each other's memory (except through things like shared memory segments), whereas threads can trample all over the other threads. A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer. If you really want reliability, you want processes instead. The downside is that processes are a lot heavier than threads.
Re: (Score:3, Funny)
The downside is that processes are a lot heavier than threads.
Kinda like yarn!
Process-per-tab protects you from rogue JIT (Score:4, Informative)
Chrome's doing JIT compilation of Javascript. [blogoscoped.com] In this context, separating the broswer into multiple processes protects you from bugs in the JIT compiler that produce native code that makes memory access errors.
Re:lite (Score:5, Insightful)
... unless there's thread contention, or memory corruption, or a deadlock, or they use a non-thread-safe library with a global lock, or one thread has to handle a signal, or there's a segfault, or....
Re:lite (Score:5, Insightful)
> How is that hard to see? It's not exactly a great insight.
Haven't done much multi-threaded programming, have you?
Say, one thread locks a mutex and hangs.
Whoops! Now all the other threads that want that mutex will wait forever!
How's THAT for great insight?
Repeat after me:
1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs
Re:lite (Score:5, Insightful)
Re:lite (Score:5, Insightful)
Given infinite resources to code and debug applications, that may be the case.
On the other hand, given realistic design specifications, given the current level of compilers and code verification, the advantage to spawning new threads all the time for processes that aren't super I/O intensive is quite often far overshadowed by the complexity introduced by doing that.
Obviously, it's a design decision, but threaded tabs simply put more onus on the developers to sit around troubleshooting race conditions and inter-thread communications, rather than actually focusing on user-oriented features and performance enhancements.
6 in one, half dozen in the other.
But you don't do yourself any service by dogmatically insisting on it, like it's a magic bullet.
You sig is funny btw
But I want to eat cookies all the time! I want to do it!!.
Yes... and threads too. :-)
Re:lite (Score:5, Insightful)
Re:lite (Score:5, Informative)
There won't be any locks
The difference of threads v.s. processes has nothing to do whether there are locks or not.
If you have a shared resource you must use locks - no matter if you use processes or threads.
I do not know about Chrome but I'd imagine it does not use shared resources (separate windows, sockets, etc.) which may or may not be a good thing (share cookies of several tabs?). Or maybe it locks only for a (provably) short time ("getGlobalCookie")?
Re:lite (Score:4, Interesting)
Building anything that is multi-threaded, even if un-intentional can cause issues... in this case, making the Class A's instance inside the method was the solution... in other cases locking is. Just depends.. it's just amazing how many people don't understand, or realize how these issues pop up.
Design matters (Score:5, Insightful)
1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs
Threading is only as hard as a bad design makes them. If you have to share data among threads so much that you have to put locks all over the place, that's really a tell-tale sign that the design isn't all that good to begin with. Really, the best threaded designs are almost like lightweight processes to begin with. Keep the number of points where data must be shared across execution chains low, and everything tends to fall into place.
Design really matters (Score:4, Interesting)
However the browser you write won't just be running your own code. It will be running code written by Adobe, Facebook 3rd party apps, and so on.
Given that, it's wiser to design your browser to use processes, so if you or somebody else screws up, the offending tab can be killed without affecting the other tabs, and also the memory used gets freed up (this is quite important given the large amounts of memory a tab can use nowadays).
You could in theory have your browser threaded, but use processes for the plugins, javascript and future junk^H^H^H^Hfeatures the W3C comes up with, but at that point how much do you really gain?
Why do you think Microsoft sees Google as the enemy? They are right. Google have just launched a new "operating system".
It's wise for Google's "operating system" aka browser to have process isolation, so that it is harder for one misbehaving instance to take down the rest.
Cooperative multitasking is so 1980s.
Re:lite (Score:5, Funny)
3. Threads introduce WHOLE NEW CLASSES of bugs
ah, so that's why MS is so keen on adopting multi-threaded programs.
1.Introduce new buggy software
2.Offer paid support for said software
3.Eventually fix old bugs but introduce new ones
4.Profit
Re:lite (Score:5, Funny)
Re:lite (Score:4, Insightful)
...it's trivial to figure that out. Let me explain it to you: you have tab A, and tab B. If tab A and B share the same thread, they will hang each other if one of them hangs. By putting them in separate threads, tab A and B can hang, but not affect each other.
How is that hard to see? It's not exactly a great insight.
Wrong, a misbehaving Thread can and will hang the entire process. If anything Threads will INCREASE the chance of hanging the entire browser, because correct Thread programming is HARD!
Re: (Score:3, Informative)
And because people confuse that, they tend to post misinformation.
IE8's tabs will be in separate processes despite what the grandparent said. This adds stability.
Re:lite (Score:5, Informative)
There is no excuse for a modern browser to not have this, especially in light of the fact that their main competitor (IE) is developing it.
Here's one excuse: complications when trying to have multiple processes render content on a single window in Mac OS X [mozilla.com] (mentioned near the end of the tab process isolation section).
It's not clear to me if this is impossible or really difficult to achieve, but I think it'll be interesting to see what Chrome does for Mac OS X.
Re: (Score:3, Insightful)
The only word that suffices to describe Firefox's lack of threaded tabs is "shameful". There is no excuse for a modern browser to not have this,
You do know that there are not currently any stable browsers with threaded tabs, don't you? There are exactly two browsers attempting this that are both in early betas. You speak as if it's been common for years and Fx is way behind the game.
Re: (Score:3, Informative)
Re:lite (Score:4, Informative)
I don't see why this was modded troll - it's a very accurate statement, even if it shows !Mozilla in a good light (even MS, *gasp*). I haven't used a computer with less than a gig of RAM in about five years, and a lightweight app is no good to anyone if it crashes every hour. Firefox has been relatively stable for me all things considered (except for some rogue JS at digg which I abandoned a while ago, I rarely have issues), but Chrome's approach of sandboxing tabs so they don't kill each other probably should have come around tabbed browsing 1.1.
It would be one thing if this approach bloated up Photoshop or something (as if PS wouldn't burst if it got any more bloated), but I spend ALL DAY with my browser open - dozens of tabs often spread across a couple windows. Firefox taking 400MB of my 4GB doesn't bother me considering how much of my time it gets (though since 3.0 and disabling Firebug, it's not usually near that bad), so taking a little more of my system's memory in order to significantly enhance stability is more than worth it.
Hell, even in my pre-Firefox days (actually, I think this was everyone's pre-firefox days, as I'd made the switch around the time of the old mozilla naming fights), I could almost emulate this by digging for that old setting somewhere in the bowels of explorer preference to make each IE6 window run it its own explorer.exe process. And as you might expect, the system as a whole became fantastically more stable upon doing so. IE6 was (and still is) as crash-prone as ever, but it wouldn't take out my other browser windows nor the main GUI process when one took a nosedive (the decision to make the browser and the desktop run in the same process by default has always been well outside the grasp of my understanding). In any case, that should have been a tip-off that each tab should have its own process. To be fair, that setting is so buried that I'm probably one of about five people in the world to have used it (hell if I still know where it is), but there was still an important lesson there.
Re:lite (Score:5, Insightful)
Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.
Oh that's why all those links were labeled "will crash your browser if clicked"! It makes so much more sense now. I kept expecting my browser to fail gracefully and continue operating and didn't realize I just wasn't supposed to click all those links listed as such.
In other news I would like everybody to stop running executables which crash. The OS shouldn't need to keep them isolated since you shouldn't be running applications which crash in the first place. /sarcasm
You must be a gymnast because you really had to bend over backwards pretty far to justify yourself.
Re:lite (Score:5, Insightful)
"Lack of threaded tabs is shameful" - Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.
Other good advice: don't get on a plane that's going to crash. Don't get on a boat that's going to sink. Don't work for a company that's going to go bankrupt.
"IE developing it" - Oh noes! We need this now, if IE has it then FF needs it! Guess we should go ahead and make FF IE5 complient then, since IE is as well. Forget that standards nonsense, IE has it so we need it.
When Internet Explorer, of all things, has new, useful, and (dare I say) innovative features that make people's lives easier and more productive, far ahead of Firefox, then either it's time for FF to stop resting on its laurels, or it's time to start giving the IE team some well-deserved kudos. Either way, attention must be paid.
If you're encountering enough lock-ups to cause you to need to be able to end a single tab's process regularly (which is pretty hard to do in Chrome with all the tabs having the same process name mind you) then have fun with your threaded tabs. Me, I'm just not going to open sites that are likely to lock up my browser. There aren't many out there, I haven't seen a single one in a couple of months.
Good thing Chrome itself includes a process manager that will let you end a specific process based on what the name of the tab is, how much memory it's using, how much bandwidth it's using, and so on. Pretty keen.
Your post reads like so much 'LA LA LA I CAN'T HEAR YOU!' that I'm forced to wonder why your emotional attachment to Firefox is so deep. Seriously, it's just a browser, lighten up.
Re:lite (Score:4, Insightful)
Allow me to return the favor..
1. FF3 Has never crashed on you and Chrome has. You said you've used FF3 for "over a month." That means you weren't using it in Beta. Chrome is still Beta. Apples meet Oranges.
2. "Don't open a tab that's going to lock up your browser." Wow. You know, you're right. No reason for modern OS's to use protected memory. Lets all go back in time 20 years and use shared memory. After all, don't run an app that's going to lock your OS.
3. "Guess we should go ahead and make FF IE5 complient then" You can just read about this one [wikipedia.org] on wikipedia.
4. "pretty hard to do in Chrome with all the tabs having the same process name mind you" ... huh? The chrome task manager uses the page title as the process name. Click on the page title you want to kill, press "end process" and you're done.
5. "There aren't many out there" You're on one right now. The new discussion system here has locked up FF2 on my system dozens of times. It doesn't happen as much anymore, but it still does when there's >500 comments and I'm reading at +1.
6. The truth is, having one process per web application makes sense. 20 years ago OS's transitioned from cooperative multi-tasking and shared memory space to preemptive multi-tasking and protected memory space. That change allows us to do everything we take for granted now, although it probably wasn't NECESSARY to meet the needs of the time.
Google is correct: Most of the "websites" we love and use every day are actually web applications. And when you're running 5 applications in one process, you're right back into the 1980s world of cooperative multi-tasking. And in FF3 if one tab decides to throw a JS alert() box, that thread is no longer "cooperative" and all JS execution on the other 4 tabs has stopped.
And no, today's applications aren't yet at the point where they NEED their own process. But who knows how web app development could be retarded by not giving developers the kind of environment that has proven successful for Win32 development.
The truth is that you'll probably see this in FF4. It IS the next major leap in browser tech. Tabs took us from dos-era one-page-at-a-time browsing into a Win3.1 era of "almost multitasking."
Now we're about to enter the "NT era." No use fighting it.
Re:lite (Score:5, Insightful)
that's not an argument for having a memory-hogging web browser.
yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.
there are much better uses for the increase in standard memory size in desktop computers. with computers as advanced as they are today, i should be able to have a web browser running in the background while i'm working in Photoshop, Illustrator, or other memory-intensive applications. even if you're not multi-tasking, the extra memory should go towards opening more tabs, running java applets, rendering flash applications, or streaming media.
there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.
there's no reason that an office secretary should require a dual-core CPU and 2 GB of RAM when all she really needs to use her computer for is checking e-mail, word processing, web browsing, and possibly edit spreadsheets or run slide show presentations like PowerPoint.
i mean, what good is increased CPU efficiency and cheaper memory when all of that is offset by increased hardware requirements for basic software applications? with the current energy-crisis, we ought to consider whether or not the average person should need to keep pace with Moore's law for simple computing tasks like web surfing or word processing. given the huge strides made in CPU efficiency, a modern web browser should be lean enough in its most basic configuration to be capable of running on a modern low-power PC.
it doesn't make sense to constantly upgrade one's computer just so all applications run just as slow as they did before.
Re:lite (Score:5, Insightful)
yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.
Why? I spend more time in the web browser--by far--than any other application. Email? 10 years ago I used a standalone email app, now I mostly use webmail. 5 years ago I used AIM. Now I use web chat. Picasa? Google documents? Between javascript advances, DOM, rich media, plugins, TABS, etc etc etc, today's browser does things not even imaged in 10 years ago.
Chrome's very purpose is to make the browser a more generalized application development platform. Heck, WEBKIT is used in the same way (and XUL, etc for Firefox). The web browser ain't just for HTML circa '97 anymore. The web browser is probably the single most important application for most users.
there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.
Exactly right. MS Office is a great example of this. The average user utilizes a very small percent of the functionality of Office, and yet everyone suffers the bloat. Can you honestly say that most people don't get anything out of a more rich browsing experience?
Re: (Score:3, Insightful)
i understand that the web has evolved quite a bit over the years--trust me, i know.
but when you discuss the relative importance of the browser compared to other applications, you still need to look at things in context:
one of the main benefits of the web as an application platform is that you can start accomplishing previous desktop computing tasks using a thin client. why is that? because with software as a service, all of the data processing is done server-side. all your browser needs to do is render the
Heterogeny (Score:5, Insightful)
Variety is the spice of life. If every browser used the same engine, there'd be no competitive spirit to improve it. Besides, when was a monoculture ever a good thing?
I've been using Konqueror for my primary browser for several years now, but still respect the Mozilla group and wish them the best of luck. As long as everyone follows the standards (which the Open Source browser folks have excelled at), the more the merrier!
Re: (Score:3, Insightful)
Gecko just had a major two-year-plus makeover, and it still isn't as good as Webkit. One could argue that Webkit of two years ago stacks up reasonably well with Gecko of today.
Mozilla spent so much time on rendering engine refactoring, and they want to focus on stabilizing 3, and then moving to Firefox 4.
Moving to a new rendering engine might seem daunting. I don't see Mozilla approaching the project themselves.
There is a new QT branch of Firefox, but even that isn't a proper QT branch. It uses QT widget
Re: (Score:3, Interesting)
As a has-been web developer and regular web user, I'm going to suggest that the advantages of having many browsers (or more specifically, rendering engines) is largely overstated.
I don't see that browsers have made any wondrous leaps of progress due to competition. In fact it seems that competition has stymied progress at times, as browsers had to attempt supporting incompatible features that grew out of attempts to one-up the competition. Companies that develop websites have to waste a lot of resources o
Re:Heterogeny (Score:5, Insightful)
As a current web developer, I develop with KHTML. When I like it, I verify that it looks the same under Gecko (and it always does). If it's a major change, I'll check it under MSIE and screw around with the CSS until IE manages to display it without barfing. I don't bother testing with Opera anymore because I've never once seen it fail on a valid page that renders under KHTML - it's just kind of assumed that it will work.
So with all the HTML engines out there, you only have to test two camps: MSIE and everything else. Adding another standards-compliant engine wouldn't increase my workload one iota.
Re: (Score:3, Informative)
Flash is an example of something that seemingly progressed well, perhaps faster than browsers, while having essentially no competition.
It's not quite what it seems to be...
You make some interesting points, and your point about Flash isn't entirely invalid, but Flash is also a great example of the sheer lunacy of pinning any kind of "web standard" on a single closed implementation from a single vendor.
Let's start with the basics: Flash is slow. Version 10 might finally get hardware acceleration -- OpenGL has been available for how long, again?
Firefox already uses Cairo, a cross-platform vector graphics engine, which already has some acceler
Re: (Score:3, Informative)
Re:Heterogeny (Score:5, Insightful)
Re:Heterogeny (Score:5, Insightful)
Re:Heterogeny (Score:4, Insightful)
Re:Heterogeny (Score:5, Interesting)
Your post is a perfect example of why designers constantly need to be kept in check. Looking really good is an admirable aim but is not an "excellent reason" to harm functionality. A designer's role is secondary to function. Making something which just looks good is an artist's job, not a designer's job. Designers have to make things which look good and work well. Failing at either one is a total failure. Many designers are frustrated artists and would love to be able to just make something pretty, which would be so much easier if the damn thing didn't have to work too.
Car designers hate having to have boots (trunks) which can hold a set of golf clubs, because it means cars have to have high, fat arses. They hate having to cater for tall people in the back seats because it ruins the roof line. They hate laws about how high your bumpers (fenders) need to be, the fact that an airbag makes the steering wheel fat and the need for fat pillars so the occupants don't get crushed to death in a rollover. The car industry is more mature than the web design industry and there's a lot more money at stake, so the wannabe-artists get weeded out, re-educated or (only they're phenomenally talented artists) set to work on concepts which don't really need to work properly. We need to get rid of the wannabe-artists from the world of web design too.
Sorry if designing for the web is a hard job, but the notion that the web should get harder for everyone to use so it's easier for a few wannabe-artists to design for is only appealing to wannabe-artists.
Re: (Score:3, Insightful)
Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?
A screen reader for the blind has to interpret standards compliant HTML differently to a visual web browser. The point of allowing clients to interpret the standards differently is that they can present the content in the way most suitable to the user, not the designer. We, the users, are more important than you, the designers.
Re: (Score:3, Insightful)
The idea that we can create a standard that makes a page work both functionally and prettily on both an iPhone and a quad-core machine with a 30 inch display is just stupid.
Layouts must be open to change. The disparity between iPhone and 30 inch display is impassable next to the disparity between even IE5 and Webkit.
Re:Heterogeny (Score:5, Insightful)
Re:Heterogeny (Score:5, Informative)
It's not common sense. The HTML standard doesn't say, for example, how form controls are supposed to be rendered visually - that's the job for either the browser or the underlying platform.
Ditto with fonts. A 12pt font can be one size on your device/platform, and different on someone else's.
Ditto with web pages themselves - the visual rendering is specified IN THE STANDARDS as being implementation-dependent. For example, a screen reader is free to render web pages as audio instead of glyphs and images.
Read the standards. They're posted at w3c.
Then learn proper design. A good workman doesn't complain about his or her tools.
Re: (Score:3, Insightful)
Re:Heterogeny (Score:5, Insightful)
Re: (Score:3, Insightful)
If you want guaranteed pixel-perfect control, use images. HTML allows you that much.
Re:Heterogeny (Score:5, Insightful)
Actually, I think a design that hangs off the edge of my browser window because I've got the window set narrower than 800 pixels is pretty ugly. I also think text too small to read is ugly, and gets really ugly when I force it to increase size.
Yet a web page (even Slashdot does it) that lays itself out to fit MY choices is beautiful.
The standards allow a little bit of wiggle room, but the user being in control of the "page" you're drawing on and to a certain extent the printer as well, adds a LOT more variation. If you take the control freak approach you will have ugliness. Possibly with the exception of people who use Windows and are used to their browser expanding to fill the whole screen.
Re: (Score:3, Insightful)
When I wear my web designer hat, I can almost agree with you. The various browsers can be pretty frustrating.
As a web USER, I couldn't disagree with you more. I like being able to bump up my font size. For the most part, what you are describing sounds like those sites that take a big flash file and put an html wrapper around it. I HATE those sites, but if you need pixel perfect - go for it.
Re: (Score:3, Interesting)
As a web USER, I couldn't disagree with you more.
Fair enough, but be aware I am speaking from my perspective as a user, not from a developer's perspective (I haven't done any web development since I toyed around making web sites back in the IE4/Netscape 4 days). When I go to a site, I want it to look the same on any reasonable combination of browsers and platforms. It's understandable if the mobile phone version isn't the same as the regular version, but the regular version had better damned well look the same whether I'm on a computer that uses Firefox,
Re: (Score:3, Informative)
Then I suggest you look into forms and faxes, because it's impossible. Even a problem as simple as screensize means a difference in layout. PDF and ps solved this whole perfect layout thing, but as it turns out, it's damn near impossible to write for.
Re:Heterogeny (Score:4, Insightful)
I'm a (former) web developer, not a designer. The only way to achieve pixel-perfect rendering is if your entire page is one big image. Can you make sure every line of text wraps at the same point on every browser on every platform with every combination of installed fonts and user-selected options? I'd be amused to see you try.
The most effective way I've found to design sites is for me to sit down with a designer, have them sketch and me point out what should stretch, what will change on different browsers, what they can control and most importantly what they can't control. After a few iterations of this with a designer they're generally pretty good at designing flexible layouts which look good, comply with standards and degrade properly. Designs which work on small and large screens. Designs which still look OK with images turned off. Designs which work if the user turns off CSS. Designs which work when a visually impaired person makes the fonts 4x the size or uses their audio browser. The better ones "get it" and relish the challenge and often go on to become highly competent at HTML and CSS so they can do all the front-end work themselves.
I was amazed how many still (this was a couple of years ago, but the web was a decade old by then) didn't know this stuff, they just worked in Photoshop and handed off designs to be coded up, expecting it to always look exactly they way their PSD did. Perhaps things have improved drastically in the past couple of years and the majority of web designers have added a text editor to their armoury, but judging by many of the sites I see that still hasn't happened.
first appropriate use! (Score:4, Interesting)
Yes, I did check Wikipedia to make sure a million angry slashdotters weren't going to kill me for its usage.
Re: (Score:3, Funny)
I'm a beggar, you insensitive super-hero!
The real question is ignored here... (Score:3, Insightful)
Re:The real question is ignored here... (Score:5, Insightful)
Re:The real question is ignored here... (Score:5, Interesting)
I think it's more that WebKit is the new buzzword in browser dev. Plus, Apple uses it, so it's *obviously* the holy grail. I think Gecko is fine; if it's the bloat, maybe the competition from WebKit will whip it into shape.
Re: (Score:3, Informative)
Ugly UI? Safari generally(*) uses the standard OS-supplied features.
That's specifically one reason why I don't generally use third party GUI browsers anymore (I use lynx or links once in a rare while). I like the idea of Firefox, but the UI is just "weird". It's close to, but not exactly the same as the real OS supplied UI. Maybe there is a variant of it that uses standard UI nowadays, I'm not sure. It at least used to be 'skinned' to be almost-but-not-quite the real UI, where things like control track
And God bless them (Score:3, Insightful)
for getting the kinks ironed out before they hit the rest of us!
Because... (Score:5, Informative)
It's required for the XUL based interface?
Woah... (Score:5, Insightful)
Why is Gecko worth keeping if it is outdated and bloated?
You've begged the question, there. The fact is that Gecko isn't outdated and bloated. Mozilla has kept the code up-to-date. They've improved rendering and javascript performance remarkably in recent Firefox releases.
Personally, I'd rather see alternatives being independently developed and improved; all the while competing with each other for mindshare and technical superiority. The alternative, of relying on a single rendering engine for all browsers, is a bad idea. History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering.
Re:Woah... (Score:5, Funny)
GOD DAMNIT! No, Begging the question is a logi... wait, you used it RIGHT?
*reads it again*
Okay... WHO ARE YOU AND WHAT HAVE YOU DONE WITH SLASHDOT!?
Re:Woah... (Score:5, Funny)
You must be old here.
Re:Woah... (Score:4, Funny)
Re:Woah... (Score:5, Interesting)
Ya know what I'd like to see? Standards revision. It's great to tote out "standards compliance" as the holy grail, but the problem is that there are plenty of things that the standard just does not define.. and those things get discovered by web developers who work around the issues and it never gets back to the standards drafters. For example, how do you prefetch images? For a long time there was no standard way. Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway? So no-one used it. Instead, they use the img tag and set the width and height of the image to 0.. unfortunately, the standard never said "if the width of the image is zero, thou shalt not render anything." Yeah, yeah, I know, should be implied, by some browsers render a white pixel and figure that's good enough.. the fact that this isn't good enough should be fed back to the standard and made explicit.
Thankfully the interest in Acid tests has taken on this role. Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!
Welcome to "Standards" (Score:3, Interesting)
Please do not take this negatively:
Ya know what I'd like to see? Standards revision.
And yet, they do revise them by working on and ratifying a new version.
It's great to tote out "standards compliance" as the holy grail, but the problem is that there are plenty of things that the standard just does not define.. and those things get discovered by web developers who work around the issues and it never gets back to the standards drafters.
That sounds nice, but you're advocating a moving target. Standards or recommendations would never be finished.
Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway? So no-one used it. Instead, they use the img tag and set the width and height of the image to 0.. unfortunately, the standard never said "if the width of the image is zero, thou shalt not render anything."
Just because *you* want it, doesn't mean others do.
Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!
I'm guessing you're a web developer. Therefore, you or your company have a demonstrated interest in the recommendations, which means you can sign up and be a member of the committees and advocate your changes and proposals for the next version
Re:Woah... (Score:4, Insightful)
Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway?
One that makes sense?
Out of curiosity -- when was the last time you used lynx? Or links2? Or w3m? Browsers don't even have to implement images at all.
Seems to me, about the best they can do is define what the behavior should be when implemented. So, I'd suggest just using the link tag -- it's not like your page will break if it's not implemented, it'll just be slightly slower.
And I've found that prefetching images isn't useful, most of the time. Let the browser cache do its job.
Thankfully the interest in Acid tests has taken on this role. Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!
Aren't the Acid tests documented?
Sure, it's easier if you only have to read the standards, but if you're just looking for a higher Acid test score, that seems like the obvious solution.
Re: (Score:3, Informative)
Modifying a value more than once in a single sequence point is undefined behavior [google.com].
Re: (Score:3, Insightful)
Remember when IE was the de facto standard? Remember how it stagnated and we were stuck with IE6 brokenness for years until Firefox came along and kicked their ass in gear? That's why we need competition. Having one single dominating platform will result in stagnation.
Re:Woah... (Score:5, Insightful)
Re: (Score:3)
More like Apples to steaming piles of horse crap.
Re:Woah... (Score:4, Insightful)
I prefer democracy. (Score:4, Funny)
Speak for yourself, I am a "web developer" (I fail to see how "programmer" doesn't suffice) and I prefer democratic control of software (software freedom) and letting a thousand flowers bloom. Software freedom can be messy but we're better off having that messiness than allowing any one implementation of something to dictate how things work.
Gecko, Mozilla and XPCOM (Score:5, Interesting)
The whole of the Mozilla code tree is tied into a framework called XPCOM. It is a Cross-Platform reimplementation of Microsoft's COM. The XPCOM influence is extremely pervasive throughout the whole of the Mozilla/Firefox/Thunderbid/Sunbird/Gecko code trees.
WebKit would not fit in very well with the existing ecosystem because it does not tie into the XPCOM framework which is used to tie all of the Mozilla group's projects together. A lot of the potential performance benefits of moving to WebKit would be lost because of all the bridging between WebKit and XPCOM that would be required.
Wheeeeeee! (Score:4, Interesting)
https://wiki.mozilla.org/Gecko:DeCOMtamination [mozilla.org]
Re: (Score:3, Informative)
Whoa there buddy. Close but no cigar.
XPCOM is by no means a re-implementation of MS COM. They share some basic ideas (and so does CORBA, if we're going that far), but "reimplementation" is not a word I would use.
Another thing to point out is that you can bridge almost any API into XPCOM. XPCOM and WebKit isn't an XOR, you could (probably) provide XPCOM interface to WebKit
It's NIH (Score:3, Insightful)
The Mozilla crew are still pissed at David Hyatt for choosing Konqueror over Gecko as "the best open source rendering engine available" when he defected from Mozilla to Apple.
That's why they will never consider WebKit. Too much pride.
Re:It's NIH (Score:4, Insightful)
That's why they will never consider WebKit. Too much pride.
Not because the enormous investment in XUL - including the wealth of third party themes / extensions / etc?
Webkit & Gecko have different goals & strengths. It would be impractical for firefox to switch. This a pragmatic decision & nothing to do with pride.
What is the writer talking about? (Score:3, Insightful)
He's going from talking about rendering engine (webkit/gecko) to talking about how great the features are in Chrome (not the rendering engine, the browser). Then back to rendering engine (gecko). What exactly is your topic?
Just a hunch, but the writer doesnt sound intelligent enough to know the features of a rendering engine.
Makes me wonder, too (Score:3, Insightful)
Recently, I'm seeing some indirect evidence of memory corruption in FF. After a while it fails to download images or connect to the network, for example. You restart the process and it all works like buttah again. Heck, Internet Explorer is more stable than this.
I guess fixing hard to repro bugs is far less glorious a job than bolting on a new JS interpreter (even though the old one was OK to begin with) or tweaking the UI.
Not really a serious question. (Score:5, Insightful)
I can understand why a third party, starting a project from scratch, might be disinclined to use Gecko; but Gecko seems to be very much on the worthwhile side of the "improve vs. scrap" question.
RTFA (more closely) (Score:4, Informative)
Mozilla IS Gecko (Score:4, Insightful)
Gecko is what they developed.
This is like having an article on Redhat's commitment to the Linux kernel.
As if they could just arbitrary change their flagship product to use the BSD kernel instead.
Or like discussing Microsoft's commitment to the Windows platform.
Just because unix/Linux-based kernels and software are becoming more popular in some circles does not mean that it is conceivable for M$ to drop the Windows kernel in favor of a *IX one.
If Gecko in Mozilla dies it will be because they have developed a better Gecko, or because Mozilla as a whole has died.
Re:Mozilla IS Gecko (Score:5, Insightful)
Security? (Score:3, Informative)
2008-09-05: http://milw0rm.com/exploits/6367 [milw0rm.com]
2008-09-05: http://milw0rm.com/exploits/6386 [milw0rm.com]
2008-09-05: http://milw0rm.com/exploits/6372 [milw0rm.com]
2008-09-04: http://milw0rm.com/exploits/6365 [milw0rm.com]
2008-09-03: http://milw0rm.com/exploits/6355 [milw0rm.com]
2008-09-03: http://milw0rm.com/exploits/6353 [milw0rm.com]
WebKit isn't touching my machine, thank you very much. Might throw Bunny(the fuzzer) at the codebase, though.
Re:Security? (Score:4, Interesting)
Reading those it is not apparent to me that they are due to WebKit issues. Are they?
Wait wait... (Score:5, Insightful)
Chrome is all new and bright and shiny, Firefox has some (plenty?) memory leaks, and all of a sudden we go from comparing browsers to making sweeping statements over their respective rendering engines? Why?
How is a rendering engine that scores 85% on ACID3 "outdated"? Why should Mozilla drop a codebase that is quite successful in the marketplace, and that they know intimately and have full control over in favour of one they don't know all that well and is controlled by Apple, just because it's (arguably) king of the hill right now?
Frankly, the summary is a troll -- and the article feels like little more than a jab at free clicks.
Re: (Score:3, Informative)
You're wrong. Some plugins and extensions have been ported to Webkit, but the thing keeps on crashing. I'm sure this will change, but Webkit is just not a stable platform to extend right now.
Re: (Score:3, Insightful)
Google has Android. Apple isn't putting Chrome on the iPhone. End of discussion.
Re:Gecko is not outdated or bloated. (Score:5, Insightful)
IE has had the same rendering engine, Trident [wikipedia.org], since IE4 (1997). MS may claim significant improvements in standards support, but in reality, they seem to only pick the bugs that have names. After five publicly available iterations (up to IE7), why is their overall standards support at least 25% below, on a feature by feature basis [webdevout.net], nearly every other rendering engine?
Plus, I have yet to hear anything to rebut the rumors that MS simply can't fix Trident because the code is such a mess, and they "don't want to break websites", which is one of the most backwards arguments for anything on any topic.
Re:Gecko is not outdated or bloated. (Score:4, Insightful)
Here is news for you: Every use of a browser has two users - one providing the content, one recieving it. MSIE has constantly failed the first half until IE8.