Categories
Mozilla

Does Firefox need to steal from Safari?

I’m a sucker for these kind of posts. I love users who share opinions, even if I disagree. There’s a blog post circulating about 9 things Firefox should steal from Safari. I’d like to go over it quickly:

1. Highlight the current text field

I agree. I really like the feature at least on the Mac. I’m not sure it really works in an application that wants to feel native to Windows, but I guess you can debate that for a long time. There was a stalled effort to do this in Bug 251198. There hasn’t been any activity there for a while. As I recall the general opinion around the web was lukewarm.

2. Font rendering

I personally agree that Apple’s font rendering is awesome. But there are many that think it’s an abomination. Joel on Software did a great writeup on font rendering recently that’s worth a read if your interested in the topic.

3. The Downloads dialog

I’m ambivalent on this point. I kinda like how Firefox shows where it’s downloaded. Other than that, I don’t see much of a difference. Then again, I don’t live in the download manager. The only thing I really care about is the download status. Perhaps that’s just me.

4. HTML rendering Speeds

There is a lot at play here. At a minimum David Hyatt’s post on speed testing is mandatory reading. A lot has been changed in Firefox 3.0, including a rewrite of incremental rendering and moving to Cairo. How will this effect performance both perceived and actual? I think it’s still to early to say.

5. The bug reporter

I’d love to know what people think about this one, considering I wrote reporter for Firefox. At over a half million reports, I think it’s been pretty successful despite being buried in a menu and pretty much unadvertised. I’d also love to improve it if someone has some UI enhancements to improve usability that make sense (I’m against change for the sake of change). We don’t show “the bug” by default in the toolbar. You need to customize the toolbar and add it yourself. Obviously it isn’t a feature worthy of such valuable screen real estate. Maybe it could be good to enable by default for debug/nightly builds? We talked about that at one time, but never took action on it.

6. The Find dialog

I hate the find dialog on the top, I think it belongs on the bottom. But I do agree that displaying the total number of results found would be a great little enhancement.

7. Detachable tabs

I still think this is such a Mac thing, but I do like it (I’m a Mac guy, so perhaps I’m bias). There was talk of this at one point. There is a mention of it in the brainstorming page for tabs, sidebar, windows for Firefox 3.0, as well as an old bug (Bug 113934). Currently you can drag a tab between windows, but it reopens in the new window (doesn’t carry the state).

8. Draggable images

Is this a problem in Firefox?

Update: I think it’s only an issue on the Mac.

9. Resizable Text Areas

I like the feature. There is an extension that will give you this functionality. Should it be part of the build? I’m really not sure. Definately not for text inputs (it mucks up at times making a mess), only text areas where it’s handy. Though I wonder if this feature exists in more browsers, will designers by start making text areas so small that we have to expand them all before we can use them?

16 replies on “Does Firefox need to steal from Safari?”

Regarding the detachable tabs, I read a comment in Bugzilla once that linked to a webpage where Adobe claimed to have patented the feature (presumably in Photoshop or something of that nature) and described it in maybe 100–200 words. The page is long since gone, and everybody’s doing it now, so I guess why not…

Does Firefox need to steal from Safari | Robert Accettura’s Fun With Wordage…

I’m a sucker for these kind of posts. I love users who share opinions, even if I disagree. There’s a blog post circulating about 9 things Firefox should steal from Safari. I’d like to go over it quickly:…

Regarding the resizable text areas, yes and I’m also suggesting to consider resizability of divs but definitely no select or other input elements.

I love the idea of highlighting the text field. That’s brilliant.

I really like how my fonts look in Linux.

I wish the downloads didn’t default to desktop, making me go change it to “ask” on every install. Other than that, it does exactly what I expect and want.

Can HTML ever render too slowly? I suspect this will be an issue forever.

The bug reporter. I’ve never used it manually, because I never see a bug except when it crashes, and then it gives it to me. I suspect we’re talking about different things though.

Find should stay where it is in Firefox I think.

About twice a year I find I want to detach a tab, so I have no strong desire for it. It probably wouldn’t bother me to have it in there though.

I don’t think I’ve ever dragged an image. 🙂

I think resizable text areas is clever, and useful when the site designer plans on the functionality. It could easily break things though I think, unless handled properly. TinyMCE allows for text area resizing, and I like it a lot when I’ve built for that.

Good list, thanks. 🙂

Font Rendering: Actually I don’t like the Font Rendering of Safari. Does not look native on Windows and does look “bold” everywhere.
There is a well written article called Texts Rasterization Exposures that discusses and criticizes Windows, Linux and Mac Font rendering, but why also proposes some viable alternatives (IMO) .

HTML rendering Speeds: Not an issue to me. It does not really matter if the rendering is 1sec better or worse.
What matters more (IMO) is the javascript speed, especially in light of Ajax and extensions. JS affects the UI responsiveness and that is what bothers me most. It will improve once Spidermonkey and Tamarin merge.
And later the JS engine will get hopefully some transparent threading.

Resizable Text Areas: This is something I really wished it was built-in.
Bad Webdesigners already make too small textareas; this is the reason resizable textareas as a browser feature was implemented in the first place.
Good webdesigners won’t make them tiny even if all those browers would the user let resize them, because they know that this would be annoying.
So I don’t think this will backfire.

The article you cite has gone offline due to database errors, so I can’t read the specifics, but…

Stan Shebs fixed the image dragging regression on the trunk (or at least the one Eric Shepherd described) a few days ago.

Right now Mac trunk page-rendering performance is about 2x slower than that on the 1.8 branch 🙁 (Only Camino is running Mac Tp on both branch and trunk–and on the same box, to boot–so you’ll have to accept our numbers 😉 )

Startup on the Mac takes twice as long on trunk, too (Firefox branch is using a PPC Xserve and Fx trunk is using an Intel Xserve, so again you have to look at Camino’s numbers if you want a meaningful comparison).

We get some benefits from Cairo et al. on the trunk, like better font rendering and support for languages which require complex text rendering, but becoming 2x slower to do that hurts. 🙁

Smokey Ardisson: I don’t need the Tp to tell me that. I’ve used the trunk builds on OS X, and they are to slow for me to reasonably use. Scrolling on some pages is worthless.

But it’s not even beta yet… so you can’t really use these benchmarks for the purpose of this post. This is in regards to release quality code, not nightly builds.

I see more focus on performance in the near future, especially now that many of the big rendering glitches are under control.

I agree with you on pretty much everything there.

I use Linux, Mac & Windows (in order of time spent) and I think that Mac fonts are clearly the best; the issue with Safari on Windows is not that the fonts look bad, but that they look out of place with the rest of the OS (then again, the whole browser looks out of place…). I’d rather see the fonts in the rest of the OS match Safari than vice versa…

I’ve been impressed by rendering speed on the FF3 nightlies; will be interesting to see if that speed keeps up in the final release, and also when more extensions are loaded.

Note that “parity-safari” and “p-safari” are used interchangeably, so this query actually gets you all such bugs. (p-safari seems to have been used the longest, and by more bugs, whereas partity-safari seems to be a recent deviation).

Apparently one p-safari bug has even been fixed!

Leave a Reply

Your email address will not be published. Required fields are marked *