Yay!

A few other places where Safari just isn't consistent and/or does non-intuitive things:

- Command-W closes tab, when every other app uses that keystroke to close the current window (in fact, it works this way within Safari itself until you turn tabs on). Perhaps use a shift modifier for tabs?

- Command-shift-W doesn't close all windows, tabs or not.

- There's no way to insert a tab in a textarea. I understand the need to tab between page elements, but could you maybe require a modifier to do it when entering textarea content, or make this an option as OmniWeb does?

- Safari doesn't seem to spell-check in textarea fields. I'm guessing this is a known thing, though.

- Brushed metal in a web browser is against Apple UI guidelines. Arguments against it have been done to death, though. :>

There is no public release with tabs.

Command-Option-W should calls all windows, not the shift variant.

"- Command-W closes tab, when every other app..."

Dear God no! It has escaped from from the Chimera/Camino mailing list. Somebody kill it before it's too late.

Oh the humanity!

Rumor has it that Panther will ditch Aqua in favor of a universal brushed-metal theme, and it's not unreasonable to assume that Safari 1.0 would be a cornerstone of Panther too. Personally, I welcome it -- those ribbed-for-her-pleasure Aqua stripes drive me up the wall.

(what does this have to do with anti-aliasing??!?)

keep up the good and fast work; and make Apple release a new beta as soon as possible. ;)

Yeah we need a new beta soon. Too many Mac users are using Safari v60 as their main browser and it is causing problems. Safari is making it appear like our sites are poorly designed, when it is actually the browser that needs to be fixed.

That being said, Safari is awesome and you are doing a wonderful job, if it comes to a question of waiting for Panther, please argue for another beta refresh in the meantime.

"Command-W closes tab, when every other app uses that keystroke to close the current window"

NO NO. I hate that. Many times in Mozilla/Chimera/Camino I have done that out of habit and lost a whole window full of sites. Please keep it the way it is.

I hope that the tab-closing behavior, whether in a hypothetical Safari release, or in Charango (or whatever it's called ;) stays as it is. It seems to me that the current behavior is the result of user testing, so I don't foresee it changing, fortunately.

For any default command - in this case, Command-W - the thinking must be that an action should behave in accordance with user expectation. Tabs change the user environment such that the action must change too. A user who opens 5 tabs expects what when they hit Command-W? If the entire window closes you can expect a period of shock and mourning, followed by anger, and eventually, war.

Peace.

I'm still wondering if AAing affects font metrics. Because if it does, then it absolutely must never be used on monospaced fonts (because it would un-monospace them).

OT: Will Safari ever render XML? I just tried loading an XML page (MIME type text/xml), and it was completely blank -- no [non-tag] content at all.

thanks,
-Walter

does this mean that safari will render fonts like every other cocoa app? Will fonts look like Camino? Right now, safari gets that nasty RGB residue all over ther fonts.

Also, when will safari ever let you go to a website like this:
http://user:password@www.site.com?

right not it just spits the user/pass request sheet back at you, this is annoying as hell....

And what about mpeg IN the browser? or at least redirect it to quicktime like the WMV plugin does with windows media player. I'd like to NOT download every mpeg everytime i watch a video.

Another thing i don't want, is my damn download window to open everytime i drag an image out of the browser, this is rediculous, clean it up.

And one last thing, can we PLEASE get an tab complete? This auto address filling is annoying as hell, i just want to go to www.macosxhints.com, not www.macosxhints.com/article.php?story=20021107063520493&query=chimera+clear+history, yes, i know if i have been to the root of the site then just the domain will show up, but i go to a lot of sites from netnewswire, so most of the sites i go to ONLY have the long URL paths. This is annoying, make it ONLY complete on tab like Camino. And NO we don't need to be able to tab from the address bar. Does that ever happen?

wow, didn't mean to rant, but it all just kept coming out.... just my couple of peaves with a great browser.

"And NO we don't need to be able to tab from the address bar. Does that ever happen?"

...Actually, yes. When you open a window and want to jump into the Google search box, you tab out of the URL box to do it.

> And NO we don't need to be able to tab from the address bar. Does that ever happen?

If you tab in the address bar, it switches to the google search bar. I've used that a few times. However, there is an option. Make it tab like normal if there is no autocomplete in question, but if you type something and there is an autocomplete possibility (and you wait the half second or so for the autocomplete stuff to show up), then tab should select the autocomplete. That seems like the best of both worlds to me.

Auto-complete for URL's is nice, and should continue to work as it does, where typing a few characters will bring up the full addresses. These should stay highlighted however, so that it's easy to delete. This is the current behavior.
While using Tab would be a bad way to break UI guidelines about forms and data entry, I believe that some key (perhaps if I hit enter instead of return, or something like that) will take me to the root site, rather than the full URL.
That would allow me to still not have to type it all, but to still get the full path, without having to try and remember it, like many other browsers do, only auto-completing to the next / which then makes you try to remember the arcane URL paths.
My 2¢ on that subject.

As for font handling, I unfortunately haven't gotten 68 to work to try it out. PLEASE, however, allow an option to turn off font smoothing (Anti Aliasing) COMPLETELY though, not just for monospaced fonts. This is one of my pet peeves about the current OS, and many text apps. It makes the text seam blurry, and hard to read and hurts my eyes after reading it for a while, unlike it used to. Anything under 24 point font should, in general, be much easier to read if it's not AA'd (unless the font isn't made well), and as a designer that will look for how this will show up in multiple platforms and formats, I need to be able to see that as well, and would prefer not to have to use another browser to do it.

Yes, I know I'm being very picky. We all should be about what we use everyday. I'm a big fan of having options, as I know that a lot of people will want and prefer AA'd fonts, just as a lot will want to be able to turn it off (wish i could in the OS without having to use hacks too).

Sorry if that seamed like a rant last post, but I'm very passionate about things that I use all the time, and about having things that are customizable to my needs and uses, and will also work best for everybody else as well. This is one of the main reasons I started using a Mac...one of the reasons I loved the OS and programs...flexability and customizability BUILT IN....one of the reasons I got involved with Themes for the OS, even though Apple didn't support it...and one of the reasons why, although I think it's the best OS out there now, OS X and many of it's applications still bug me.

I know that had nothing to do with font smoothing, but it seamed somewhat appropriate in response to some of the previous comments.

Dave, keep up the awesome work, it was impressive to see how far Safari has come in such a short time while I was part of the seed team, and I can only hope that it will continue to gain ground as fast, thanks to your genius and expertise.

Hi Dave,

In your post above, you mention a hack that turns off AA. How/where do I get this hack. AA drives me nuts and my eyes hurt as well. I think AA looks great when I look at the text like you would look at a picture, but when I try to read it, I find it blurry and difficult to read (mainly the small fonts; not so bad with large fonts).

Thanks in advance.

"NO NO. I hate that. Many times in Mozilla/Chimera/Camino I have done that out of habit and lost a whole window full of sites. Please keep it the way it is."

An option would be appropriate. There are good reasons, it seems, to have it one or the other way, so let's have the choice.

The default, of course, should be to close the window with all tabs in it :-))

Jeff

Option-Tab will insert a tab in a textarea in Safari (and all other Cocoa apps for that matter).

ryan

How to avoid getting a headache
(Also known as : how to avoid antialiasing)

edit the file ~/Library/Preferences/.GlobalPreferences.plist

change AppleAntiAliasingThreshold to a nice big value (I use 22)

Unfortuntately, there are many broken applications (like Java, X11, Safari...) that dont respect the settings. I have reported the Java, X11 problems to apple, but they seem to be in no hurry to fix them

> For any default command - in this case, Command-W -
> the thinking must be that an action should behave in
> accordance with user expectation.

Tabs in web browsers are, really, a rather recent invention. They're also not available in 95% of the web browsers people are currently using. As (I presume) Safari will become the default web browser for Mac OS X, this argument doesn't really work.

The _average_ user expectation is that Command-W will close an entire window, not a tab. Changing this functionality to benefit 5% of the web browsing population at the expense of common behaviors known to the other 95% doesn't seem like a viable reason to leave it as-is.

Also:

Tabs (in general) aren't an uncommon interface element. They can be found in all sorts of applications, not just web browsers. I've seen plenty of "preference windows" that utilize tabs, and never before have I seen one that closes _and removes_ the current tab by hitting Command-W.

Even if you consider "those tabs", however common as they may be, somehow "different" than Safari tabs just because the latter contains content whereas the normal ones usually contain settings, there is prior art for this as well: MS Excel's "sheets" are essentially tab-like, and as far as I know they don't close with Command-W either. I'm pretty sure nobody can argue that that isn't a commonly used application.

There are occasions when it pays to break existing user interface paradigms, even if it goes against user interface expectations. However, this should be reserved for when the change in question will provide a dramatic increase in user productivity.

I'm pretty sure that for those users who haven't used Safari w/tabs yet - a browser that, technically speaking, isn't even available yet - any speed-up gained from hitting Command-W versus some other key equivalent will be negligable compared to the cost of unlearning a command that has been second nature to Mac users for well over a decade and a half.

The annoyance factor of having to re-load tabs is no different than that of having to re-open a document. As Safari will support tab-sets, in many cases you'll be able to get back to where you were with just a click or two.

...

The Mac has always benefited in the eyes of its proponents because it is predictable and internally consistent. I think it'd be a shame for Apple to ignore that, especially for a flawed "common implementation detail" that doesn't yet have any inertia at all.

I mean, seriously... This is Command-W we're talking about, not some esoteric feature that isn't, oh, exactly the same in nearly every other Mac program in existence. :>

Just to clarify, as I'm not sure I made this very clear:

>> For any default command - in this case, Command-W -
>> the thinking must be that an action should behave in
>> accordance with user expectation.

> As (I presume) Safari will become the default web
> browser for Mac OS X, this argument doesn't really work.

What I mean be this is this: Safari, for the vast majority of Mac users, WILL be the benchmark on which user expectation is based.

It can be hard to remember at times, but the average Mac user isn't looking around the web for beta Safari builds or even downloading legit copies of "alternative" browsers. I suspect that with many of them, Internet Explorer is the only browser they know, and it doesn't have tabs.

There quite simply isn't any prior user expectation to hold them down, other than that of Command-W working the exact same way in nearly every Mac application out there.

If you deviate from Camino or Mozilla, you'll confuse a few web geeks for, oh, a day or two. Deviate from standard Mac user interface standards and you're going to continually piss off long-term Mac users for as long as Safari exists.

On closing a window full of tabs by mistake: the solution is a single level of 'undo' on close window or close tab. Mmm Mmm.

"The _average_ user expectation is that Command-W will close an entire window, not a tab"

The average user expectation is that Cmd-W will close the current document, they're looking at - not all of them (tabs or no tabs).

Yes, consistency in human interface paradigms is a noble goal, but in the real world there are times when it should be sacrified for usability. This, I feel, is one of those times. Remember, consistency is enforced for the _sole reason_ of giving people a pleasant environment to work in. If you sacrifice usability in the name of consistency, you've lost sight of the goal. Want an interface that values consistency over usability? Try Windows XP and call me in the morning. Seriously.

Speaking for myself, when I discovered by accident that Command-W closed the frontmost tab and not the entire window, it was a pleasant surprise. Not to mention a great relief -- because I'd only meant to close the front tab, you see, and I'd hit Command-W out of sheer habit.

Besides, the present behavior is less dangerous than the proposed alternative. If you really want to get rid of the entire window with all its tabs, it's easy to hold Command and machine-gun the W. On the other hand, if you close the entire window when you just wanted to get rid of a single tab, that's a lot harder to undo.

(And if there _was_ an undo option, do you really think anyone would think to look for it in the midst of their righteous rage? Not bloody likely.)

QED.

Jeff, I'm not sure your MS Excel analogy is a good one. Excel's tabs are essentially slave to the document as a whole -- conceptually, each tab is part of the same document. You could probably make the same argument for individual layers in Photoshop documents, or even individual items in the "Source" list in iTunes (each source, after all, is just a part of the iTunes appliance).

It's a different story with web pages. You'll have a few tabs open that are related at best, but are from different sources and clearly belong to different documents. Depending on your browsing style, sometimes they won't even be related.

The way you interact with an Excel "sheet," and your perception of the way it relates to the document as a whole, is fundamentally different from your experience with tabs in a web browser. Therefore, there is no reason for Safari to take its human interface cues from the way Excel handles sheets.

That's how it works in my head, at least. But I'd wager most people see it the same way (without having to think about it).

Also, what possessed you to look to Microsoft Excel, of all things, for guidance on human interface principles? ;)

"...Actually, yes. When you open a window and want to jump into the Google search box, you tab out of the URL box to do it."

Safari does not open with the address bar focused. To tab to the google bar it takes 2 tabs.

"Foolish consistency is the hobgoblin of little minds" ... I think Emerson said that.

In any case, the most important rule for Mac developers is that any interface choice should be as non-destructive as possible. Closing all the tabs using Command-W is as destructive as possible ... you have to hunt through history to recover the pages you accessed creating additional work.

The tab interface collects web pages (the documents) together ... it is an interface nicety, it doesn't create a new meta-document. If you really want to get rid of all the tabs, click the bright red gumball on the upper left corner.

Jeff, that's ridiculous. Most users expect cmd-W to only close a tab. Tabs are really just window management so it really doesn't oppose any interface guidelines. And accidentally closing a bunch of tabs is normally detrimental.

Command-W does NOT close documents. Command-W closes windows.
That is what it should do in any application. Even in a Safari version that uses tabbed browsing.
Shouldn't be too hard to come up with a new shortcut for closing tabs.

Nope, nope, nope. Tabs are document windows (just grouped together). Close a tab (window) by Cmd-W, close the entire window by Cmd-Shift-W, as is the case now. Anything else is just crazy!
And, if people don't use tabs (i.e. non-'power' users), Cmd-W will close the window, as expected...

Whether it's literally true or not, in practice Cmd-W closes documents. The Macintosh is document-centric. Thus, in Safari, Cmd-W should close documents (represented in this case by a tab). QED

Amen... Browser Tabs are merely an alternative method of browser window management. Comparisons to tabbed preference panes or tabs in Excel are not valid, as has been pointed out already.

Tabs in tabbed browsers are just a way of managing multiple open windows. Whether you have tabs turned on or not, Cmd-W should do exactly the same thing: it should close the "window" containing the current web page. The window may be an actual separate browser window, or it may be a tab "window" inside a tab-container-window. Basically, I'm saying there is a one-to-one correspondence between web pages and windows in any browser. Tabs just unify or group the windows to conserve screen real estate.

So Cmd-W should not close one web page some of the time, and several other times. THAT would be inconsistent, especially with typical user expectation.

(And I'm talking about the variety of users that mostly USE the computer, as opposed to those who may only be trying to justify the bad decisions made in designing other tab-based browsers. ;-)

For those who advocate using Command-W to close tabs: What key equivalent should be used to close a window when there are no tabs open or they are turned off?

Jeff Campbell - you're looking at it all wrong. Cmd-W should close the current document. If you have no tabs open, or have tabs shut off, then it's simple. The window contains 1 document, so closing the document means closing the window. If you have tabs open, closing the document means closing the tab. It's really quite simple.

Also, I have to say, if Safari ever changed this so Cmd-W always closed the window, I'd probably stop using tabs in Safari because I'd keep closing the window when I meant to close the tab.

Please don't listen to Jeff Campbell. He hasn't made a single suggestion that wouldn't make things worse. :(

Kevin - YES! That's exactly why I stopped using tabs in Camino/Chimera. I got sick of accidentally closing the window.

(Kevin)

> Cmd-W should close the current document. If you have
> no tabs open, or have tabs shut off, then it's simple. The
> window contains 1 document, so closing the document
> means closing the window. If you have tabs open, closing
> the document means closing the tab. It's really quite
> simple.

Usually when things are so simple, you don't have to state it twice. :>

I guess we'll have to agree to disagree. I personally feel that while Command-W behaving differently from 99% of other Mac applications is bad enough, it's even worse when Command-W doesn't even work consistently within the same application.

But, it's clear that I'm not going to convince anyone of this who doesn't see it already. I guess we'll just have to wait and see what Apple ends up doing. :>

(Stephen)

> Please don't listen to Jeff Campbell. He hasn't made a
> single suggestion that wouldn't make things worse. :(

Wow. That's fairly rude.

How about we let Dave / Apple listen to everyone, and make their own decisions?

I've found that in general if an argument is unable to withstand criticism, it usually has someone pleading with other people not to even consider that criticism.

The posts regarding the non-destructive nature of the Macintosh are the most persuasive by far. We can get into long discussions of container-view models, or we can agree that the Macintosh philosophy, even more than consistency, is not to let the user easily shoot themselves in the foot.

Hmm, what do most of the comments here have to do about font handling? :-)

I've also suffered that "oh sh*t!" moment of cmd-w closing a tabbed window in Camino too many times. I hope that never becomes as easy to do in Safari, tho' perhaps it could be changed using NSUserKeyEquivalent?

On a different and less divisive topic, one of the trackback blogs had a GREAT idea, that I'm really surprised hasn't been done before. Dave, please get this implemented in Safari:

If a page (in tab or window) has a form on it that has been edited, don't allow the page to close without verifying the user wants to close it (the equivalent of the "dirty-bit" in many document-based applications). This wouldn't impede closing the vast majority of windows, only windows that have a partially filled out form (for instance, this one, until I hit submit).

Another great idea that has been mentioned is adding autocomplete functionality to text fields on the web page. So rather than autofilling the whole page, if I start typing my address in a field, an autocomplete list will drop down and let me select from the autocomplete items. This should not replace whole-page autofill, but supplement it.

Oh, and a nitpick - when a new bookmark is added, default to the menu, not the bookmarks bar. Given that people will probably bookmark more items over time than fit in the bar, it makes sense that the default location be where most bookmarks will go.

Just a couple more ideas how Safari could become the most elegant browser ever. :)

What's really ridiculous is this argument. Just make it an option in the prefs! There's obviously a big division between opinions. Everyone's putting the "average computer user" into this argument. The average computer users who I have seen don't even use keyboard shortcuts in the first place!

Make it an option. Yes, it can be best of both worlds in this case. (Any Safari UI programmers, are you listening?)

Sorry guys but Jeff is completely correct in his assesments. cmd-w should/will always close the front most window. If an application designer decides to try something new that application designer must realize how standards that have been in place for close to 15 years will effect that interface. In this case cmd-w will close all of your open tabs. What should happen is a keystroke for closing the TAB that way cmd-W still sticks to the standard and if there is more than one tab the user can just use the alternate Key stroke.

Actually Excel is quite a good example of some one trying a new interface and still being able to stick the standards. It may be from MS, but did actually get it right.

And so the individual who suggested to just "machine gun" through the tabs, this person has never suffered from any type of RSI or Carpal Tunnel. The less keys that I have to hit the better.

If we start putting all the new web pages into tabs in the document, what is next? Putting the menu bar down in the App also? Lets just all switch to Windows at that point.

Cheers All.

I'm going to have to weigh in on the side of Command-W closing the current tab rather than the whole window.

The way I see it is that the Command-W combination should close the current document context. In most situations, this does mean closing the entire window. However, the tab paradigm in browsers is something a bit different. In that case, each tab represents a unique document context rather than each window. Hence when tabs are enabled, Command-W should close the current tab.

In addition, I think it is a matter of conveniece. I would wager a goodly bit that in most instances, the person performing the combination only wants to close the current tab. It makes more sense for this to be Command-W than Command-Shift-W when it is going to be the more common of the two commands.

Various people asserting "the guidelines are this" or "the guidelines are that" are wrong. Command-W is defined to be Close... not Close Window, Close Tab, Close Application or anything else... just Close.

It's always been left to application developers to pick the least jarring action for it. In this case, that's obviously closing a single tab. Anything else allows you to lose data without review.

What a bloody mess tabs is causing. I'd like to thank Dave and the geeky tab folks from bringing this crappy thoughtless implementation to the Mac. Thanks Dave. Thanks Geeks.

Ugh...I didn't want to have to get in on this argument, but I have to admit that I have to disagree with the statement that the "Close" menu item is defined as just "Close".

Go take a look at the Aqua HI Guidelines.

- Close: Closes the active window.

That's right. It doesn't say "Closes the active whatever" or "Closes the active noodle", it says "Closes the active window".

Also something interesting below that (that doesn't really mean much):

- In a file-based application that supports multiple views of the same file, you can include a Close File command below Close Window, to close a file and all its associated windows. If possible, include the filename in the menu (for example, Close File ?Jerry?s Kids?). Shift-Command-W can be used as the keyboard equivalent for Close File.

That's kind of backwards of what we're talking about though, since I would use the term "file" as a webpage, and window as a window full of tabs.

(Now I'm going to hear a bunch of people saying the HI Guidelines don't mean anything, which in some ways is probably true)

When I hit Command-W, I am always expecting the active window to close, not an element of the active window. Why? Because it's been that way for a long, long time.

Regardless of what people think, I still stick by my original statement: It should be an option for the user to choose. I'm sure it would be quite easy to make a prefs option for this instead of a bunch of arguing and insulting on Dave Hyatt's blog (who doesn't work on the UI, remember?).

Hello,

when i used tabs in safari, i was very happy - they are a great way to handle multiple websites (I'm an ÜberUser aka WebDeveloper).
Later I want to close a tab (my actual document), and without big thinking, i pressed Cmd-W to close it. And? It works as expected, it closed, only the tab, so i could read next tab. Thanks Apple!

But I miss one thing. If another app (i.e. NetNewsWire) requests a website, I miss the option to set, that a new tab should be opened, not a new window - that brokes my tab-browsing-feeling...
Chimera do so... :)

I wasn't going to get into this off-topic tab stuff, but since the "tab people" are probably mentally tallying "votes" I have to chime in.
A tab is NOT a window.
Cmd-W closes a window.
My paint program allows multiple window views of a document, and Cmd-W does NOT close the document, it closes only the active window; if I have two window views of a single document, and I hit Cmd-W, only the frontmost window (view) closes. Cmd-W does not close a document; it closes a window.

Again, a tab is not a window. If you want window behavior, then use a window! Hello?

-Walter
Mac user since 1988 (Mac Plus running MultiFinder)

Oh, and I think there should be (an option for) a confirmation dialog on closing a window; it could even state whether there are multiple tabs, or a "dirty flagged" form.

-Walter

So, when you have your separate key combination (not command-W) for closing a tab, what do you do when you get to the last tab?

Does pressing this key close the last tab, and therefore the window? The HI purists wouldn't like this, because that's what command-W is for.

Or do you have to switch to using command-W if it's the last tab?

Either of these options seems silly to me. Sureley there has to come a time when common sense and usability has to come before slavish adherence to the HI Guidelines.

Oh, and why do you think they're called Guidelines?

==> Tabbed Browsing, Cmd-W vs. Cmd-Shift-W, etc.

There is no public Safari beta with these features. The beta seeds surely came with an NDA which you broke, so at least be clever enough not to talk about it in the blog of a developer.

Additionally, trying to convince hyatt to change the Tabbed Browsing implementation is worthless, because hyatt doesn't work on the interface at all, to my knowledge.

Use the good ol' Feedback link (once there actually _is_ a public build with Tabbed Browsing).

Lastly, Cmd-Shift-W vs. Cmd-W is a pointless debate either way, because it's Tabbed Browsing that's the problem (Tabbed Browsing is really just an awful workaround for a bad window manager, like Windows' or KDE's - too bad Apple decided to implement it to a reasonably good window manager like Aqua).

==> Brushed metal in Panther

That doesn't have anything to do whatsoever with Safari's Font Handling.

And, see above, hyatt is not going to remove Safari's brushed metal, because he didn't add it either.

==> XML rendering

"OT: Will Safari ever render XML? I just tried loading an XML page (MIME type text/xml), and it was completely blank -- no [non-tag] content at all."

What do you expect Safari to render, an XML tree? To render the actual content, a stylesheet is required.

A URL to your document in question would be helpful.

Have it undoable.

I try to do a short statement:
If tabs are a cool means to replace windows, we would obviously want that option in the OS not in some particular Application. As I am still sticking with v60, I don't know yet, but I don't want to rule it out.

At that point we would need shortcuts to both close tab and close window. (Cmd-Y perhaps?)

As for destructive actions its quite simple: Any action should be undoable. What if you hit Cmd-Q instead of Cmd-W by accident? Relaunching the app should bring you back where you have been before. (Even better, Cmd-Z should do that, as it should do for closing a window). As long as pages are in the history, they should be buffered.

Even the Finder will allow you to undo a lot by now. That makes sense in any application and it is obviously possible in a browser.

Users will eventually habituate to the new shortcut and will quickly learn that closing a window is undoable. (They might, however rightfully complain it isn't available in other apps.)

iSee

Good Lord...I think Dave should perform a little tap dance for us for really starting this stupid tab revolution that is causing inconsistencies in the user interface experience. How many browsers did you influence Dave? 3? 4?

Take it away...tap-dancin' Dave. Hope you're proud of yourself.

> There's obviously a big division between opinions.

This is dumb. There's not a big division. The vast majority agree that cmd-w closing a tab is the correct implementation. If you've used tabbed-browsing this is obvious.

> Everyone's putting the "average computer user" into this
> argument. The average computer users who I have seen
> don't even use keyboard shortcuts in the first place!
> Make it an option.

Yes, average users use shortcuts. But they generally do not manipulate the defaults. So getting the default correct is very important.

Soren, you're way off. Tabbed browsing is popular on MacOS precisely because MacOS window management is so poor. The Windows task bar may not be elegant but it provides direct access to every open window making tabs much less necessary on Windows.

Oh, that's completely ridiculous. The best thing about tabs is that those who don't like them are under absolutely no requirement to use them. Are you really criticizing Dave Hyatt for bringing an optional feature that many, many users love to the Mac? In his own blog? In the comments about an entry regarding font handling? Jeez that's some nerve.

Anyhow, Cmd-W (or Cntrl-W on Windows) to close tabs is the standard and accepted behavior on every single browser that implements tabbed browsing: Opera, Mozilla, Phoenix, Camino... And the discussion groups in all of them have had this same debate. In the end, every single one of them chose this behaviour because it most closely matches most users expectations, and was the least destructive activity for those who expected otherwise. To go against this would not only defy user expectation and risk destroying essential data for the user, but also contradict the behavior that millions of users have already come to expect from other browsers.

Incidentally, there was a time when I was on the other side of this debate. But after actually using a "cmd-w closes window" method, I realised it just plain didn't work. It was so intensely frustrating and unbelievably disruptive. I found that out the hard way.

"...Actually, yes. When you open a window and want to jump into the Google search box, you tab out of the URL box to do it."

and then:

"Safari does not open with the address bar focused. To tab to the google bar it takes 2 tabs."

I'm not sure what you two are doing - Google has javascript that moves the focus to the search box onLoad. Simply load their URL in the browser and you'll wind up with their site that has focus set in the search box.

I am in favor of command-W closing a single tab.

I'm also in favor of tabs being disabled by default. I think it's a great interface tool for people with small screens (like my iBook) where more windows mean more clutter, but it's not a feature for Mom and Pop Schmoe.

I would like Safari to support XML like Mozilla does -- if there is a stylesheet, rendr the XML. If not, show a tree.

I think that supporting http://user:pass@host/ is a good idea, as is http://user@host/ (which pops up only asking for the password).

There are a lot of good ideas in these comments, but WAY too many beligerants.

BTW, to turn on spell checking in a TextArea (like this one), control-click in the box, then choose Spelling->Check As You Type from the menu. This should be on by default in all OSX Apps.

Nicely stated, Mark.

Tabs are sort of inherently disabled by default so nothing needs to change there.

Jason - the Google Search box in the bar at the top of Safari, not on google.com

Wow. This is truly ridiculous. A fight over Cmd+W in a blog entry about font handling.

LOL ( This is the 61st comment but probablly the 59th Off-topic. )

I tired to warn you people but would anyone listen?
Nooooooo!
I guess I know how Cassandra felt.

"If tabs are a cool means to replace windows, we would obviously want that option in the OS not in some particular Application. [...]"

Exactly my opinion, too: I really hope Apple's "GUI team" (or whatever it's called) has some nice surprises for us on this front, hopefully even in time for Panther - it would be a great thing to finally make OS X's global window management better than Windows XP's!

'"OT: Will Safari ever render XML? I just tried loading an XML page (MIME type text/xml), and it was completely blank -- no [non-tag] content at all."'

'What do you expect Safari to render, an XML tree? To render the actual content, a stylesheet is required.'

Yes. I read somewhere (maybe w3.org) that unknown text/* types should be rendered as text/plain. And I did make a CSS stylesheet (see below), but I probably would need XSL(T?) to provide labels for the content...

'A URL to your document in question would be helpful.'

http://www.natural-innovations.com/site/profile.xml
http://www.natural-innovations.com/css/profile.xml.css

(I'm still developing it, and a DTD for it.)

Consistency is good but not at the expense of rendering / launching speed. It is almost an academic issue! If those use 8px font (roughly 7pt) in their websites, it is their problem.

Obviously, the management in Apple will give the speed more weight. Let's be real. I think more resources should be put into stamping out bugs (especially those in css) than thinking too much of this non-issue.

Hmm.

"This is dumb. There's not a big division. The vast majority agree that cmd-w closing a tab is the correct implementation. If you've used tabbed-browsing this is obvious."

Cmd-W was chosen for two basic reasons:

- it's directly next to Cmd-Q (quit)
- "W" means "Window"

Tabs aren't windows, and although NSTabView treats them as subclasses of windows (IIRC), they shouldn't act like subwindows in a window environment not designed for such (i.e. Aqua, Platinum, ...). Mac OS has always had a global menu bar, as opposed to most others' environment, and was always based on the assumption that MDI is a bad idea. TabbedBrowsing is essentially a simplifation of MDI.

I've tried to find out ( http://weblog.chucker.rasdi.net/?post=/usability/tabbed-browsing-solution-searching.blog ) why it was needed on Mac OS in the first place, and how to solve it. (To summarize: window switching needs to be more unified amongst apps, by providing GUI feedback for Cmd-~ / Cmd-Shift-~, and by optionally letting the mouse switch easily between windows, too.)

There is no definite answer to Cmd-W between Cmd-Shift-W other than what I've said before: the question shouldn't exist in the first place. Every window in Aqua should be a full window, with full management, provided by the OS, and not by an application-specific idea like TabbedBrowsing or Opera's MDI.

"Yes, average users use shortcuts. But they generally do not manipulate the defaults. So getting the default correct is very important."

This depends on the definition of average users. I think that most users do not know what they are, actually. ;-)

The latter quoted sentence is correct, though.

"Soren, you're way off. Tabbed browsing is popular on MacOS precisely because MacOS window management is so poor. The Windows task bar may not be elegant but it provides direct access to every open window making tabs much less necessary on Windows."

Eek. You're saying Windows has better window management than Mac OS?

The task bar's idea of showing one item per window may be right, but isn't actually followed by most apps (the keyword being MDI).

"it would be a great thing to finally make OS X's global window management better than Windows XP's!"

It is. Does Windows XP offer a zoom button? No.

Sören...that was a wonderful post...I agree completely.

=> "Lastly, Cmd-Shift-W vs. Cmd-W is a pointless debate either way, because it's Tabbed Browsing that's the problem (Tabbed Browsing is really just an awful workaround for a bad window manager, like Windows' or KDE's - too bad Apple decided to implement it to a reasonably good window manager like Aqua)."

Thank God some finally stated the obvious. At the risk of sounding insulting, I and about 25 Million other people use the Mac for a bunch of reasons, one of which is CONSISTANCY. CMD-W closes the front most window. Period. Do NOT deviate from a pattern that has been around for the last 15 or so years.

=>"This is dumb. There's not a big division. The vast majority agree that cmd-w closing a tab is the correct implementation. If you've used tabbed-browsing this is obvious."

No the vast majority have NOT spoken. A really small minority of the highly technical/Power user group has voiced an opinion. They are entitled to that Opinion. Now here is mine. Just because the Windowing env that you came from was different/inferior (IMHO - which _I_ am entitled to) do not bring those inefficiencies to my environment. Tabbs are only useful in certain circumstances and making up for an inferior window management style within a superior window management style is NOT one of those circumstances.

I have to put up with Tabbs in my IDE of Choice and it just breaks every freakin' Mac OS HIG that I know of. My hands and Fingers that have been trained for 15 years to do certain keystrokes end messing things up because some developer thought they would just "Try something new" and just caused chaos with the Application. This is the first app where I have to actually hit the help system just to figure out how to close a window. That is pitiful.

Now back ON topic. Maybe Web developers should consider that not everyone has a 20" monitor to view stuff and make the fonts 10pt at the minimum.
Cheers

Hate to tell you guys, Dave only works on the webcore, not the UI. So telling him about the tabs really doesn't do much at all.

I hate to tell you Michael that by telling Dave, he might pass the message on to the super-secret Safari team.

Obviously Apple isn't working on a new window management system in Panther or they'd have slapped the Safari team and said "Don't do that. We're working on something better."

If Apple really is working on a new window management system in Panther, then there isn't a whole lot of inter-communication within Apple...and Apple is allowing the Safari to waste time and resources creating this tab interface.

We already *are* off-topic. If hyatt wants us to stop right now, he should remove the comments as he has done before. He should probably turn off commenting anyway, because it's been abused to death.

"Does OS X offer a true, reliable, always-working-in-the-same-way-for-any-app window maximising feature (in addition to the excellent zoom feature)?"

No. Should it? No. It's called _multi_-tasking, not _single_-tasking. If you want a window manager that's as awful as that of Windows or as awful as almost all X11 window managers, go ahead and use them. If you want a window manager that (tries to) resize windows to _fit_, and _not_ to block the whole rest of the GUI, use Mac OS.

"Another example of crappy window management is this very blog window: e.g., every time I open it in the Safari Public Beta, then the next time I open a new browser window or restart the browser, the new window has the size and placement of this tiny (previous) blog window. Don't know if it depends on Safari or the OS - anyway, it's IMO a quite unacceptable behavior for a mature OS."

That's a Safari issue. Trying the same in Camino, it uses whatever normal (non-popup) window's previous size was.

... An addendum to better clarify...

The "blog window" I meant above is this "Comments" window; in particular, the problem described appears when I zoom this window (to better read the contents) and then, of course, close it: the next Safari window will then be the same size and placement of this one (even if the main weblog window has always remained unchanged in the background, of course), and trying to zoom it again will return the window to Safari's "default size", not the "main", user-defined size (in my case, almost full screen). Anyway, inconsistencies in window maximising and related things are one of the most annoying "bugs" in OS X, IMO.

OK, enough with windows... :-)

OK, just to catch up with tha last comment, which I missed...

"No. Should it? No. It's called _multi_-tasking, not _single_-tasking. If you want a window manager that's as awful as that of Windows or as awful as almost all X11 window managers, go ahead and use them. If you want a window manager that (tries to) resize windows to _fit_, and _not_ to block the whole rest of the GUI, use Mac OS."

Ehm... what has this to do with multitasking? I just want a consistent, elegant way of maximising windows in OS X (see, for example, when you use it with small-screen iMacs or laptops): it shouldn't be too difficult to implement! Remember the famous "Single Window Mode" in the pre-Public-Beta days? It was designed to reduce window clutter - à la tabs, BTW :-) - and has nothing to do with single- vs. multitasking: it's just about giving some more solid and elegant options to users. Maybe also to the so-called "switchers", who would definitely appreciate *some* of Windows' or Linux' most obvious features...

well, some X11 window managers are REALLY good to manage windows, different from windows or macos X but REALLY good too. (for example, window maker, blackbox and so on)

BUT

OSX has a REALLY good thing , it doesn"t "maximize" windows to the max, it FITS them to the size of the DOCUMENT.

it's really stupid to fit ALL the SCREEN when the document doesn"t specify that . for example a tiny picture, its window doesn't need to fit aAAaall the screen

it's the same with webpages, and safari does a good jobs in "zoom"

One thing : this "zoom" features has to be implemented by the developper (only the application can inform osX about the size of the document )
not all applications gives that. Camino for example will maximize to use all the screen (and I think it's not a good idea) whatever the webpage need to.

Apple advice to always use "intelligent zoom" when you click on the "zoom button" in an application.

Guys, you do realize that Opt+Zoom DOES in fact zoom to the whole screen? And that's not an app-controlled thing, it's system-wide, AFAICT

Kevin speakeths teh truth!

Thanks...now people can shut up.

You know you're a nerd when.............you get worked up over command-W

... And you also know that option-zoom isn't yet completely consistent among the various apps and/or app windows: some "maximise" in one way (leaving more or less screen border around the window), others maximise in a "true", Windows-/Jaguar-like way (i.e., filling the whole screen, except for a border before the Dock).

It's indeed the so famous "Mac-like" (!) complete consistency that is still rather lacking on this front...

First off......DANG YOU"RE ALL OFF TOPIC!

For whoever it was that asked, the "hack" I'm using to adjust the AA size (and turn it off in some other types of programs, that that plist edit won't do), is called Tinker Tool. It's also what I use to put my Dock in the bottom right of my screen so that the Applications folder is always in the same place (as is the trash).

As for option + zoom. In Safari it resizes all windows to either the default size, or to the zoomed size, in effect simply zooming all windows (and moving the normal browser windows to the top left starting point of the screen) rather than zooming the window (this comments window for example) to the full screen. At least this is the case under build 60 in OS X Server.

I will end with this (and hope you all do too, 'cause you're bound to be driving Dave nuts by arguing here). Options are a good thing, weather they be to turn on tabs and use them, or to turn off font smoothing completely, or any other feature you can think of. Through testing and thought, defaults are made that the average user will find the best (aka, tabs turned off until everybody gets used to them, font smoothing turned on, as the majority of people like it, etc...), but if we have the option to change it, we have nothing to complain about, and can only be happy about it.
Please everybody, don't argue about how things suck when they're not on by default, and many people think they're cool. As a developer myself, I can assure you that you'll eventually drive ANY developer to the response of "piss off and write your own then" if you keep mitching and boaning about what they're working on. I'm guilty of this to some degree for sure, as most people are, but I really can't thank skilled people like Dave (and the people who are working on other programs I use all the time) enough for all the hard work and time they've put into things. Options are good, and if we ask for them in a sensible manner AFTER bugs and other things are taken care of...we just might get them...but we must be patient and civil.

I think that the TabClose/WindowClose debate is going about it the wrong way. What needs to change is the Tabs. They seem to be too integrated into the window. Move them outside the windows, maybe down the left-hand side. This might be a little more intuitive and look more like seperate windows. Just one more off-topic thought.

Okay, I know Dave's not the guy for this but I thought I'd post my thoughts on the tabbed browsing keystroke issue since it's mentioned a lot here. I've never used tabs in a browser so please keep that in mind as you read.

If I had numerous browser windows open, with no tabs, then I would expect Command+W to close the front most browser window, each time I pressed it, until all windows were closed.

If I had a browser window with numerous tabs open then I would expect that Command+W would close the selected tab each time it was pressed and then, once you're down to one page and no tabs, Command+W would close the actual browser window.

If you wanted to close all tabs, and/or browser windows, you should press Command+Option+W. In a case, like in the previous paragraph, where there's a browser window with numerous tabs open, or even two browser windows with numerous tabs open in each, then I should be able to press Command+Option+W to close all the tabs as well as all browser windows, or click the browser window's close widget to close one browser window and all the tabs it contains.

I don't know how things work now with tabs in different browsers but, FWIW, this is what I'd expect the behaviour to be. No? There should also be a preference to determine whether Command+N opens a new tab or a new browser window.

Derren.

Derren, you're in luck because that's exactly how it works.

Anyway, I think we scared poor Dave away from his own blog. :(

re Autocomplete: It should be just like IE. The first thing to pop up should be root of the domain being autocompleted (whether or not you've ever visited the root). The next in the list, which you can arrow up and down in, is the full autocompleted URL. Another thing IE does that Safari could really use is autocompleting by title or bookmark title (a godsend when you remember a history page or bookmark's title but not its URL. in effect, it's a history/bookmark search feature) as well as always showing both title and URL in autocomplete results (for sites with useless unidentifiable URLs such as docs.info.apple.com/article.html?artnum=75150 - how am I supposed to distinguish that from 75159 or 75433?)

And please, God, DON'T hijack tab from the address bar!

Stupid question not relevant to this discussion, but perhaps somebody knows the answer.

I often type the wrong thing in the URL. Like www.cnn,com which obviously gets you nowhere. Is it at all possible to spell check this? (I usually discover it before the error box drops down, but then it's too late and I have to click "ok" and re-edit the URL).

Cheers,
Nick

nick, just type “cnn”

I agree with Nick. Sarari should spell check URLs such that mistakes like www.cnn.com can be caught and corrected to www.foxnews.com. :)

"Okay, I know Dave's not the guy for this"

Then why did you post it?

Speaking of printing, when will Safari stop spliting lines between pages? Or was this fixed in a hypothetical release?

Any chance that we can get the technical details on this bug fix? I've been trying to correct the same issue in my own applications that use ATSUI, and I would like to know exactly what was fixed.

Thanks,

Evan

I noticed the following thing with safari: safari seems to have problems (like konqueror) displaying html-pages which "stream" - like every html-chat without reload out there including mine :) does it. this means, that the page gets filled with posting over and over and never finishes loading. every browser handles this fine, but safari and konqueror only show this streaming page after stopping the transfer. is there any chance of getting this fixed? I don't know whether it's a safari/khtml-bug or whether there is something I can send with html-header, like a length.

other pages which are really long get displayed during the download process. so I think there must be a problem with the determination of file length or ending. at least, a chat-stream and a long html-page are both pages which should be displayed during download and only one of them gets. there must be a difference between them. but which? :)

ciao :)

When is the Flash Remoting issue going to be fixed? I hear that it's just an issue with binary posts (as in safari just doesn't have that). Should this really be that big of a deal to fix?

Now there is the internet. And I really appreciate people like you who take their chance in such an excellent way to give an impression on certain topics. Thanks for having me here.

オンラインカジノ

great page...im sure i'll come back...best regards

business grants