I still love it. To this day it remains my primary browser, through its aged rendering, through its lockups on JS-heavy sites, through its dated icons, through everything. Because the UI of every other browser just feels wrong. Aside from Safari maybe, but Safari's tab bar makes it impossible to handle 50+ tabs.
Pick any of the main browsers, the main advance in the UI is the slimming down of controls. Even Opera went from a g'zillion toolbars down to a slim default interface. The rendering engines receive loads of attention while the basic browser UI is just plain boring and out dated. Camino doesn't really look that out of place even today.
Has Firefox gone completely native then on OSX? From what I can tell on Linux is that Firefox and Opera stand out (and even Chrome that shuns your system title bar..) These three apps are out of place on my desktop. At least Camino blended in.
he's one of the people who partly (because he's still over 10 tabs) gets the current bookmark-systems in browsers.
For most users the bookmarks seem to be broken/too complex. Never had the problem, maybe because I'm going crazy when I got over 10 tabs and want to get rid of them ASAP. :\
Just looking around reddit you easily pass the 50 tabs threshold.
Bookmarks are far from ideal (at least in firefox) and technically you don't need them today since the history works well in case you need to find something (just typing related terms on the address bar) but the history is erased quite often so it's better to have certain urls bookmarked and using the aforementioned address bar to find what you're looking for (or the search on the bookmarks manager). It works for me.
I have absolutely no idea what you're talking about. I don't use bookmarks, I used to put things in there and never find them when I needed them, so I've stopped doing that.
I'll actually put things in there when I want to remember them. Firefox makes it a little better because you can attach keywords to them to help you search later.
For a surprisingly long window of time, IE Mac was the best browser around. Apparently, it did not share a code base with Windows IE, which explains why IE Mac had all the features people were drooling over in 2001 like full PNG transparency and good CSS support. PNG support even included color correction, and IE Mac did not suffer from the "box model" bug that affected IE on Windows.
I think the Mac version of IE had something like 99% compliance on the first Acid test, before other browsers had robust CSS support. You could even find a copy of the Acid test in an easter egg in the browser.
It was a fantastic browser at the time, but didn't align with Microsoft's future interests and the development team was reassigned.
For all the woe brought upon the web by Internet Explorer 6, the "box model bug" is indeed the one thing it did right. It took far too long for everyone else to admit the error and move ahead with the box-sizing CSS spec.
In 2001 I, for the first time in my life, had access to Macs running Mac OS 9. While I didn't like the operating system much (I was using Linux and Windows at home, the idea of having to assign memory to application manually felt so 80s) I instantly fell in love with IE for Mac. Back then, in PC land, Netscape Navigator and IE 5.5 were the dominant browser, and IE for Mac supported all these fantastic CSS properties that I knew about, but that I could not use in NN4 or IE5.5. I spend hours buliding pure CSS websites without images, simply utilizing unicode fonts, and CSS properties. Ah, those were the days.
Unfortunately it had the most annoying bug in that it did not reload CSS files. Back in the day, I developed with a text editor on mac PowerBook and after changing one CSS statement, I had to close the browser and restart it.
Ehh, IE5:Mac may have been better than IE5:Win, and yes, its CSS and PNG support were ahead of its time, but it was still IE5.
IE5:Mac didn't have support for a lot of things IE6 had that we now consider standard, like :hover for links, for..in, Array.prototype.splice, XmlHttpRequest, contentEditable...
That and the fact that wine only runs on *nix, so it'd require another compatibility layer to provide POSIX and BSD functionality under classic MacOS. OSX didn't even exist at the time IE for Mac was written. They'd also have to come up with a visual theme layer so they could at least pretend it's a Mac program, long before they introduced one in Windows. All of that still wouldn't get them menu bar support, though. In hindsight, I didn't think it through at all when I mentioned wine.
They do have MS-Office ports for Mac, so that product was probably written with much better separation of concerns.
I find this extremely saddening because Camino offered the best native experience for OS X, with all the polish of a well-designed Cocoa app, on top of Gecko.
I want to like Firefox, I really do, but the experience on OS X is awful. It doesn't fit well with the aesthetic of a native Mac app, and certainty doesn't' function like one. Multi-gestures in Safari are so much smoother. About a month or so back when the Firefox team was soliciting feedback for something here on HN, one of the designers or developers at Mozilla had screenshots of a version of Firefox that looked really good. I went to go download the latest version and realized that the screenshots most have just been Photoshop comps or something.
I would have to agree with most of what is said here. I prefer Chrome (or even Safari) over Firefox on OS X. Chrome is faster (I need to work on a slow Internet connection many times) while Safari being the bundled browser has few features like Reader etc. which I don't want to use. I still have FF installed for back up purposes but I don't use it unless something is broken on Chrome or Safari (which doesn't happen a lot).
I find it extremely surprising that some sites (ex:Facebook) are (or were a few months back) displayed differently on Windows FF vs OS X FF.
did it look like this [1]? that's the UX nightly available at [2]. it's a new theme they're working on, but it's got a few versions to go before it makes it into stable. i'm loving it, but they're removing/changing a couple of customization features so people are freaking out. we'll see what the final product ends up looking like.
It's not just the user interface, it's that (for example) they don't QUITE completely ignore mac (emacs) keybindings (e.g. ctrl-a should move to beginning of PARAGRAPH, but either moves to the beginning of the visual line in the textbox, or highlights whatever you've searched for if you're that unlikely). This is far worse behavior, and it's been like this for years!
Actually this tab style dates back to at least Firefox 3. I didn't check further back. It looks like XUL can't do it the right way, and they don't care enough to do it right.
The one thing that drives me mad about Firefox on the Mac is it's Home/End behavior. Ever since migrating to the Mac, I have remapped the keys to work like on windows and Linux (operating on the current line instead of the current document).
You can do that using a custom key binding in ~/Library/KeyBindings.
Firefox ignores this and still insists on home/end working on the full document. But even worse: in the new Gmail compose window, not even Command-Left/Right works (it does in other Textareas - no idea what Google did here).
Now this might totally be a case of http://xkcd.com/1172/ but by the life of me, I cannot work without a way to move the cursor to the beginning of a line - especially when the keys that I usually use are so destructive (scrolling all the way to the top, making me lose my position).
This is the only reason why using Firefox is out of the question.
In the past, I patched some JS file inside the bundle, but now that Firefox updates so often and it's a signed binary, I can't really do that any more.
>The one thing that drives me mad about Firefox on the Mac is it's Home/End behavior. Ever since migrating to the Mac, I have remapped the keys to work like on windows and Linux (operating on the current line instead of the current document)
That's because Home and End keys on the Mac, like in the original UNIX, mean the beginning and the end of the document not the beginning and end of a line which is a Windows thing (and since Windows is the overwhelming presence, is commonly misunderstood as the keys themselves meaning that) and since most early Linux desktop environment's aimed to duplicate Windows, is also the default Linux behaviour now.
You will find this behaviour in all Apple provided applications as well.
> I cannot work without a way to move the cursor to the beginning of a line
Anything that doesn't override Cocoa's default key bindings will be able to use the emacs key bindings as well (Cntrl-A for the beginning and Cntrl-E for the end of the line)
>in the new Gmail compose window, not even Command-Left/Right works
> You will find this behaviour in all Apple provided applications as well.
not on my machine. As I said, I used ~/Library/KeyBindings/DefaultKeyBinding.dict to change it. If the OS provides a way to change defaults, I expect applications to respect that too - no matter the historical reasons.
> >in the new Gmail compose window, not even Command-Left/Right works
> cntrl-a and cntrl-e work.
Yes, but Command-Left/Right is something that worked on the Mac even since before OSX. I, again, see no reason why it wouldn't work here.
If the application overrides the defaults (which is fairly common ), your changing the defaults does nothing (for that application and for the keys that might have been overridden). It sounds like Firefox overrides the defaults completely but in it's override "map" keeps some of the functionality the same as the default.
I havn't used it but this claims it will change the Firefox behaviour as well (specifically make them behave like windows for the home and end keys)
I think cmd-left and cmd-right are used by Firefox for " back" and "forward" so those never work on Firefox (unless perhaps you go find where Firefox specifies its key bindings and change them)
>That's because Home and End keys on the Mac, like in the original UNIX, mean the beginning and the end of the document not the beginning and end of a line which is a Windows thing
Is it? I'm used to them going to the beginning and the end of lines on Linux.
The very next line you quoted tells you why that is the case on Linux now. if you used Linux in the late 90's, you will remember that a lot of the popular window managers/desktop environments aimed to make your transition from Windows 95 easier and the current Linux behaviour is a result of that.
> ...new Gmail compose window, not even Command-Left/Right works (it does in other Textareas - no idea what Google did here)
It drives me crazy too. At one point I used a workaround mentioned in the bug discussion[1], but I have no idea if it still works. I decided to support Mozilla/Firefox and just got used to control+a/e within Gmail.
CMD-Arrow (left,right,up,down) will move you to the beginning of the line, end of line, start of document,end of document respectively. I really miss these keys when I am on windows as I find it much less of a hand movement to do.
Since Camino is based off Firefox, is it possible to backport some of the OS X specific code? The primary reason why I'm still using Safari rather than Firefox is because it lacks Keychain support.
There have been two attempts that I know of (and probably more) to add keychain support to Firefox, once leveraging Camino’s code. The problem wasn't technical, but resistance from Firefox leadership to the idea. IIRC they were concerned about breaking the ability to move a profile folder from one OS to another.
I worked on Camino quite a bit in the early 2000s, it was a great experience. It's funny to think that we really felt we were contributing greatly to the appeal of Mac OS X by providing the kind of browsing experience Apple should have provided on the OS much earlier, given their focus on it being designed with the Web in mind.
Eventually Mozilla hired me to help re-write the Firefox port to Mac OS X because the product lagged so far behind Camino. Once I got deep enough into that project my Camino contributions dropped off. Dedicated volunteers carried on. I had forgotten that they still hadn't shut it down yet.
Anyway, congrats to Camino on the long run! It was a great option, particularly for earlier Mac OS X users, and a joy to work on.
One feature Camino ha and that I really miss in other browsers is that it displayed whether files in its download window were still there. That sounds rather trivial, but made it a perfect "file inbox", where I could quickly see whether I still needed to review/move a file.
And the fact that it was more in sync with the OS X desktop experience than Firefox (back in the days; got better) and Safari (brushed metal)...
Of course nowadays, a hierarchical tab sidebar is my one "exclusive" killer feature, and as of yet only Firefox has that (via add-ons).
Well that marks one more end of an era. With Camino folding up and Opera going with WebKit - Camino too was on the way to this with Gecko being out of the question - the browser field is getting to be a one-horse race (since all the cool kids are going with Chrome these days).
Arguable. Jolla uses Gecko with IPC embedding for their upcoming browser for Sailfish. Gecko is in no way out of the question. Mozilla are also working on the new Rust based browser engine (Servo).
I only stopped using Camino when I became dependent on some Firefox extensions (AdBlock, NoScript, eventually others). The big downside to Camino having a fully native UI was that it didn't have XUL support, so no cross-compatibility with FireFox extensions.
As soon as one of the Mac-compatible WebKit browsers can replicate the functionality of AdBlock Plus, NoScript, and BetterPrivacy, I'll quit using FireFox on OS X, because it's still noticeably non-native and has some persistent annoyances.
AdBlock Plus is available for Chrome and NotScripts replicates NoScript. I'm not sure what BetterPrivacy gets you that you can't do yourself by changing your cookie settings.
However, the author of noscript has said that it isn't technically possible to entirely replicate all of the features of noscript on chrome because extensions on chrome don't have the same kind of access as they do on firefox.
NotScripts is still only mitigating JS and not fully blocking it, at least last time I looked at the source (I also almost puked). Plus it lacks feates like clear click (anti clickjacking), ABE etc.
Camino was my preferred browser on my old Macbook because it was the simplest and most easy to use browser available. All other browsers were irritatingly complex by comparison.
Unfortunately/fortunately with browsers becoming more of an OS replacement, it makes it rather hard if not impossible for small teams to maintain them.
Aside from that, Mozilla backed out Gecko embedding a long time ago, which is why Camino still operates with a Firefox 3.6 Gecko. That makes maintainership futile when the browser can only fall further and further behind on its ability to simply render websites.
My opinion is that Google/Mozila is pushing HTML5 instead of plugins not because that's what's best for the web, but because exactly this-- it decreases the potential for competition.
If you really want to get a good conspiracy theory going, note that a lot of the main Camino people have worked at Google for many years now (longer than Chrome has existed), and the other main person went to Apple.
The whole reason Camino has been discontinued is that the components that make it easy to reuse Gecko in their competing product were removed from Gecko.
I'd like to see your source for that claim. At first glance it seems that popularity of Camino, both among its developers and its users, has been declining for years.
A big counter-example is Opera Software switching away from their own engine to WebKit/Blink.
Opera has a paid staff of full-time engineers, which makes rewriting a browser on top of a new engine a lot more feasible.
You're right in that if Camino had the developer time it had in its heyday it might have made the jump and survived, but the end of Gecko embedding is what made it impossible for Camino to continue to be maintained indefinitely by one or two people.
In what way does using HTML5 over plugins decrease the potential for competition? If anything it makes for more competition as the need for browser-specific plugins is removed.
A sad announcement, but the writing has been on the wall for a few years now (specifically, since Mozilla officially dropped support for embedding[0]).
I'm only surprised they waited this long to make it official.
Would it be such a sin to continue to use it for a while practicing safe browsing techniques? Or am I naive to think that I can avoid being harmed browsing trusted sites with my beloved browser?
Seemed to be a favorite for marketing campaigns thanks to it's minimal interface.
XUL was only part of the problem. Camino's goal was to make a browser that was designed for the Mac. Firefox's goal (once running on the Mac was added after the fact) was to make a cross platform browser that ran on the Mac. That's not just about UI toolkits, it drives basic decisions.
Firefox doesn't use Keychain because cross-platform trumped integration. Its localization (a different download for every language, instead of one multi-language binary like every Mac app) is "wrong" for the same reason. It doesn't integrate with the Me card in Address Book for form fill data for the same reason. It makes you set your accept-language list manually instead of using the identical OS-level list for the same reason. The list, some small and some large, goes on, and it all adds up.
It affects UI behaviors too. I don't know if they eventually fixed it, but for a while closing the last window would quit the app, which is against the platform guidelines for a multi-window app, and was widely hated by Mac users. The justification was that it was consistent with Windows Firefox.
Those of us who chose to work on Camino in our free time did so because it was the product we wanted to build, and Mac Firefox was clearly never going to be no matter how much effort we might have put into it. You can call it a waste if you like, but I think you'd be hard pressed to find someone who worked on Camino who regrets the time they spent on it, or considers it a waste.
As for it being an "obvious dead end", until Gecko embedding was deprecated there was no reason Camino couldn't have continued indefinitely. How is developing software that many people still love and use a dead end? Not everyone in the world views dominating the market as the definition of success.
Camino has been open source and developed entirely by a community of volunteers for most of its life. There were extensive instructions on getting involved on the website for many years. There was even a specific push to recruit new people a year ago to make the transition to WebKit so that it could continue to use a modern engine, which is the only way it could have survived once Gecko stopped supporting embedding.
If there were a community of people with the time/interest/skill to develop it further, the project wouldn't have shut down in the first place.
I learned about it just last year and forgot about it again until today. It's just not even much of an option if we're going to be honest, unless you want a minimal experience.
I think it was the only browser that really gelled with the 'Aqua' UI style. IE for Mac did so too, to an extent, but Camino had more advanced features.
Still the go-to browser for the diehards on NS/OS, I hear. I remember figuring out how to plumb in SSL and JS support just so I could access a butchered Dropbox...
I use it on an old PowerBook G4. It's the only way to have a reasonably up-to-date/secure browser (the other choice being TenFourFox) on PPC/Tiger Macs.
One rough edge is that it totally ignores my keyboard layout for keyboard shortcuts. It appears to use the Qwerty layout for shortcuts, even under a different layout.
“Camino is not receiving security updates” “Camino reaches its end” “Camino is no longer being developed”
I don’t like the tone of this press release. They make it seem like they’re not responsible for the lack of updates and that Camino died a natural death. They didn’t offer an explanation nor did they give any advance notice. Not very classy.
As a purely community-based open source project, no one is employed to work on Camino; all Camino developers are volunteers, working on Camino in their spare time, as a labor of love. While maintaining embedding in a fork of Gecko is theoretically possible, we don’t have the manpower for a sustained effort of that kind
Ah, that explains a lot. It also shows the shadow side of open source software development: if the developers get bored, they can just up and leave. If all the devs do so, the project is dead but there’s no one there to call it. Users aren’t owed any explanation.
