One quick comment about .ico files - if the root of the web server is protected, an authorization dialog comes up when Safari tries to load the .ico file. Every other browser silently fails, and for good reason:

Assume you have a web server where the root is protected, but users have access to individual directories on the server. Well, the way Safari works, for every page you load on the server, it will try loading the favicon from the root and pop up a spurious authorization dialog (which is confusing, since the page has already loaded just fine). An example is here:

http://www.hertelfamily.org/cgi-bin/dndboard/ikonboard.cgi

You can usually just iterate through the NSImageReps in a NSImage and remove the ones you're not interested in (some versions of OS X don't remove image reps when they're supposed to, so you may need to create a new image).

It'd sure be nice if the bugs in Cocoa were fixed though :-)

As long as you're working with NSImage, try this: http://lqgraphics.com/test/rgb16leraw.tif

It loads garbled on my system.

This is already rader # 3180130 but it would be nice for someone else to confirm it.

I've found that if you have a 32-bit colour version of a favicon.ico, Safari does not display the colours properly. Blues become purples, etc. I had to strip the 32-bit versions out of all of my favicon.ico files so that it would display properly in Safari. I reported this problem using Safari's bug reporter, so hopefully it will be fixed.

Does anyone else here think that the fonts on this page are very painful to read? It's not the color, but the size of them. I have to get within a few inches of the screen to see them.

My eyes hurt.

When I noticed Safari's implementation of the title attribute, I was so pleased I commented on it. It's preferable to a tooltip, because I don't have to wait around for it to show up, and it's better than the usual hack of replacing the contents of the status bar, because it doesn't occlude the link destination.

Tooltips take too long to show up when they're wanted, and they hide text unnecessarily when they're not wanted. Zeldman's grammatical concerns notwithstanding, the status quo is better than the proposed improvements.

The status bar just makes no sense though, because people *assume* it's going to show up in a tooltip. Like it or not, this is how people have coded their pages.

For example, it's insanely common to see "Click here." in a title attribute.

I expect tooltips myself, actually; putting it in the status bar diverges from expectations derived from other browsers' behaviour. Also, since the status bar is optional, and is off by default in Safari, title attributes may be missed there.

I've also noticed that text within acronym tags is italicized, which throws me off if nearby text is within em or i tags -- a common enough occurrence, I should think.

I can't say that Safari's current implementation of title attributes really bothers me. In fact, it didn't really bother me when they didn't show up at all, with the status bar turned off. You click, you go. What could be simpler than that?

Thank you, Ive posted this issue several times in different places. I just figured it was common sense to load the best bit image first.

One thing I've noticed lately is that support for .ico files is kind of random too. For instance, there is a link tag that can point to the .ico file for a page.
I think safari is picking it up (but I can't seem to force it to try and reload it), but camino ignores it. I think mozilla does the right thing too.

Can't we have it both ways? Status-bar for instant access, and tool-tip for...well the way it's supposed to be. I can't wait for the tool-tips myself. I enjoy the new hypothetical opening of bookmark-collections into seperate tabs in this hypothetical v64 beta of Safari. And kudos to the clever guys who implemented the hypothetical loading-icon into the tabs too. Tabs are actually useful and snappy? now!

I actually have the opposite opinion of favicon support - resolution is most important, colour-depth is second-most: I *hate* scaled bitmaps (although if it was using the same algorithm that the Finder uses, it might not be too bad).

For the website I'm currently creating for a client, I dropped a favicon.ico in the root folder of the site for IE/Windows, and put a <link rel="shortcut icon" type="image/png" href="/images/favicon.png"> into the header of every page, for saner browsers.

Mozilla Keywords--It's amazing to see in how many ways Safari is being improved! After tabs, the last missing thing for me from Mozilla are the keywords (see explanation at http://www.mozilla.org/docs/end-user/keywords.html). I'd like this to be taken one step further: Any bookmark in the personal toolbar (or even in the bookmarks menu) should display this kind of behavior, i.e. you enter a text in the address bar and a click on the bookmark executes a query for whatever site you want. This would do away with the need for an extra Google text field, too.

Other feature ideas:
- A command to clear all caches/logs/histories (for privacy reasons) or something like: "non-logging mode on/off"
- A quick way to turn JavaScript on and off (akin to Opera's "short preferences")
- History displayed as a graph or tree (snapback already loosely goes in this direction)
- Several categories per bookmark, then you'd have some kind of clustering to quickly find what you want
- It'd be nice if one could navigate the bookmarks just like in the Finder's column display, too.
- Drag modifier keys: Important for picture links to indicate if one wants to drag the picture, the bookmark or the resource the links points to.
- The source URL as a comment in downloads
- A new file type for SINGLE bookmarks. The way the finder does it now is terrible: It uses the URL as the file name, making it impossible to add a description of the URL.
- Export bookmarks: There are several XML DTDs out there for exchanging bookmarks. Examples: XBEL (XML Bookmark Exchange Language), OPML (Outline Processor Markup Language), ...
- Web archives. This is advanced, and therefore maybe should be implemented as an external program: I'd like to see a step-by-step expansion of the tree to be crawled that can be human-directed through filters and queries.

I agree with Screwtape: I'd rather have an 8-bit bitmap delivered at its native resolution than a 16-bit bitmap scaled into a blog. One thing, unless I'm very far wrong, the MacOS X, and the Finder, aren't scaling bitmaps. The end result is, of course, a bitmap; but since OS X uses the grandson of Display Postscript in Quartz, the Finder actually has vector images to work with.

I too expect a tooltip, although I think Chimera ... er, Camino's implentation does pretty well. It pops the tooltip up immediately, from what I remember, but the tooltip doesn't fade out. Was this because of a custom hack to get proper tooltip behavior?

Oh, and it'd be nice to have a tooltip display the URL that a link will lead you to. Like has been mentioned before, the status bar is set to "off" by default, and there are plenty of misleading links out there (i.e. ones that'll take you to a porn site when claiming to take you somewhere else).

Oh and off-topic, and Safari still doesn't remember my inline spell-check preferences for my forms. This has been an outstanding issue ever since the initial release of Safari; please fix it for the next release.

This is a little off topic, but whomever decided to start implementing Emacs-style key bindings in Apple software should be applauded.

Mindlessly today I just did ctrl-a, ctrl-k to remove a line of text I was writing in Safari and it did what I expected. Then I tried the same in iChat.

Fantastic!

Hello,

Don't know if anybody mentioned it here already. But another problem with the bmp parser is that it doesnt support custom 8-bit palette's (which you can make with iconbuilder xp or the latest iconbuilder 4):

http://sbc.yahoo.com/favicon.ico

Dave - I'm pretty sure that NSImage doesn't support a 32-bit .ICO representation (24-bit color, 8-bit mask). I've seen no evidence of it in other applications (like Preview.)

It also sounds like there might be some problems with the current implementation reading the correct colortable information for the 8-bit resources. It's very common for .ICO files to have a custom colortable.

I've got the file format information if this would be helpful to someone on the Cocoa team. I had to reverse engineer it...

As far as which icon to display: I'd search for size before depth. This will end up with better quality:

1) Search 16x16 for 32-bit, then 8-bit, then 4-bit (don't bother with 1-bit .. very rare to see them in .ICO)

2) Search 32x32 for the same bit depths, and scale down to 16x16.

3) Search 48x48 for the same bit depths, and scale down to 16x16.

If you have any more questions about this, please feel free to contact me by e-mail: craig_at_iconfactory_dot_com

whatever you decide to do with title attributes and what-not, I hope Safari will still show the URL in the status bar - I *hate* it when I hover over a link to see where it's going to take me, but it won't say

Offtopic:

Dave, I've been working to update a current site to standards (namely CSS2 and XHTML1.1). So far, so good, except one thing. When I attempted to put two images in a floating element, they decided to go on top of each other, instead of side by side (as other browsers render it). Is this a Safari bug, or is this Safari being correct in rendering? Also, has this been fixed in any of the leaked betas (v62 or v64). I'm currently using v60. Thanks a lot.

kretorik

Oops...forgot. The URL for this is http://asdev.wwc.edu/samsandbox. It also explains the problem a *little* bit better.

kretorik

Why have a form field history? thats the main thing I miss when using my mac for browsing. IE for windows has this great feature of form field history so you can choose from past form field entries. Great for pages that you enter a number of diff. seaches.

Make it so...

san: I do think it's important to have some support for TITLE attributes. Most site designers might not do this, but I use them for any useful information about the link that doesn't fit nicely into the flow of the text surrounding the link: for instance, with a link to an image, I might specify in the TITLE that it is in fact an image. I want to provide users a good idea of what to expect before they click, especially for people with slow connections.

TITLE in the status bar is OK but not optimal because the user isn't looking in that direction.

I'm just glad that the era of assuming that ALT text will appear in a tooltip is over.

One thing I noticed about Safari: when you have a Flash movie in a tab, and you change away from it and then back to it, the Flash movie restarts from the beginning.

All macs come with one mouse button! It is really annoying that the click-and-hold functionality is NOT Available. Owning a laptop I am not always in a position to dedicate both my hands to cause the contextual menu to show.

For example, when I am holding my son with me, I have to use IE :( because It lets me surf with one hand.

Besides isn't click-and-hold for contextual menus a requirement in apple's HCI guidebooks?

Secondly why no syntax highlighting on the source code we web developers actually use the feature...

great work otherwise...

*Sigh*

I would hope that image ALT text is also gonna be shown in the tooltip, as well as the TITLE if there is one. To me that would be the "right thing". Yes?