Next OmniWeb to be based on Safari Engine?

An anonymous reader writes "A MacFixIt article includes a quote from the Omni Group's CEO Ken Case: 'The wonderful news for OmniWeb is that Apple has based it on a fast, compatible (and small!) rendering engine which is tuned for Mac OS X, and which they are making available to the entire Mac OS X development community! [...] This means that we may be able to reach our compatibility and speed goals for OmniWeb much more quickly than when we were working alone, and then return our focus to doing what we do best: providing a rich browsing experience. Thank you, Apple!'"

Comments

Serious question here...

[soapvox]

Ok so Omniweb is going to make a browser based off of Apple and Open Source work which is cool (like chimera based off of mozilla), would windows developers build better and different browsers based off of Explorer if Microsoft were to open its source and if so how would that hurt MS, I mean chimera to me actually enhances Mozilla (love them both). Thanks for any comments.

Re:Serious question here...

[grahamtriggs]

Actually, the open source status (or more accurately, not) of the internet explorer code is rather irrelevant to the development of windows browsers...

The rendering engine in IE is a component - you can embed it into other applications... theoretically at least, you can build your own rich browsing experience around it as you see fit (as evidenced by the MSN browser vs. IE)... exactly what hooks are available to you, and therefore how rich an experience you can create, I am not familiar with...

The 'big issue' with IE source is not one of how you can re-use the layout engine, but one of not being able to fix any bugs that exist, or to extend it's basic functionality (ie. more complete implementation of standards).

Re:Serious question here...

[Anonymous Coward]

There already are browsers based on IE rendering engine component for Windows without it being open sourced.

Re:Serious question here...

[babbage]

As a case in point, check out Crazy Browser. Like Phoenix or Chimera, Crazy Browser is a "new" web browser, but this one is built on the Internet Explorer instead of Gecko. CB (a silly name, but hey what can you do) enhances IE with features like tabbed browsing & popup blocking, and yet the download is only 700kb because most of the grunt work is done by the IE libraries, so the CB code is probably all interface stuff (it's freeware, but not open source, so that's just a guess).

Anyone interested in learning more about how IE can be extended (as closed source but semi-open APIs) may want to get in touch with the CB people, though I have no idea if they'd want to talk shop. *shrug*

(Annoyingly, you can't get to the CB home page without being forced to accept a popup for one of this company's other products, PowerIE. Some kind of toolbar thing, I dunno. It looks like it might be interesting but having to learn about it through a popup like this is rude -- but then I'm not typing this from a popup blocking browser, so I get what I deserve I guess. Amusingly, PowerIE -- nothing but an IE extension, not a whole browser like CB is -- has a download almost as big as CB itself, which I think nicely illustrates how much being able to use shared html rendering libraries can help things here...)

Re:Serious question here...

[kraksmoka]

i'm not a winblows junkie, but i can tell you that items like Kazaa and morpheus use explorer components (they gotta!), cuz they always give the same explorer script errors. i have also seen commercial real estate programs (Genesis2000, MLS interfaces) that use IE wrappers.

Re:Serious question here...

[Graymalkin]

If you've got VB on your system it is trivial to write a web browser using the IE component control. It is just an OCX wrapped around the IE rendering components. You can literally build your own IE web browser in VB in half an hour at the most. Between the WinSock and IE OCXs all you need to do yourself is build an interface and add some administrative controls. If anyone wanted to they could write an OCX for the Gecko engine and it'd be easily available from VB.

Re:Serious question here...

[momobaxter]

YOu need to view the popup, yet Power IE has a pop up blocker? I have a feeling they are going to screw themselves in the long run :)

Re:Serious question here...

[rixstep]

Yep. And you have to accept all the dirty tricks the component comes up with. Things are so much cleaner on a Unix box. Much less skulduggery. And all the vulnerabilities MS create, etc.

A remarkably mature attitude

[mithran8]

The one response you'd never expect from a commercial company that was just (superficially) trumped by a platform vendor: Gratitude. Kudos to Mr. Case for recognizing the long term potential and not griping about 'being cut off at the knees' or other shortsighted objections.

Re:A remarkably mature attitude

[styrotech]

Actually, OSX was already shipping with a 'full featured' browser. Now it will drop IE and will ship with a stripped down 'less featured' browser (still a pretty good one though by the sounds of it).

I would've thought that by itself (ie greater incentive for the user to install a 3rd party browser) would be a blessing for Omniweb - hardly being cut off at the knees.

Re:A remarkably mature attitude

[EccentricAnomaly]

The Safari BETA may be less full featured than IE, but when it ships with new Macs I have a feeling that it will be on par with IE, just much, much faster.

I like Omniweb's features and if it was as fast as Safari and rendered as many pages as Safari I would pay for Omniweb (actually I've already paid for Omniweb).

Right now I'm using Safari and Mozilla as a backup for the few pages that safari can't handle. IE is just too slow on my G3 to be usable.

Re:A remarkably mature attitude

[styrotech]

The Safari BETA may be less full featured than IE, but when it ships with new Macs I have a feeling that it will be on par with IE, just much, much faster.

Could be, but apparently Apple are keen to keep it small, fast and light. I can't remember which article I read that in though :)

Re:A remarkably mature attitude

[johnpaul191]

There was a time when Mac OS installs put IE and Netscape both on the machine. There is no reason they can not include Safari and something else. Honestly until Safari reaches full speed, i think they have to include something else.

Personally i do not like IE, and never did. After reading this article on slashdot about how IE cheats i see no need to ever use it. I can not wait till AOL totally dumps it and wed designers have to return to standards.

Even if i wanted to make a website totally IE happy, IE on Macs do not draw like IE does on a PC, and not having access to a PC leaves me no way to cater to the browsers quirks.

Re:A remarkably mature attitude

[ealar dlanvuli]

Well if it's small fast light and renders everything correctly, who cares? Now you have a small fast and light browser filling all your needs.

The point of a browser is to browse, not deal with the browser.

Re:A remarkably mature attitude

[SoupIsGoodFood_42]

The point of a browser is to browse, not deal with the browser.

But to browse, you have to deal with the browser ;)
The better the dealing, the better the browsing.

I'm still keeping my hopes on Chimera at the moment. But will watch Safari with interest aswell.
As for IE, I'd still keep it "just in case" if I didn't already need it as a web-designer for testing. But I certainly won't be using for daily browsing anymore.

Re:Errr...

[Twirlip of the Mists]

Nearly everything you said is wrong.

1. Yes, Safari is free. No, it is not open source. WebCore (which is KHTML plus some other stuff) and JavaScriptCore (which is KJS, more or less) are open source, and you can download them from here. WebCore is basically a software component, not an application.

2. OmniGroup is excited because Apple has given the OS X developer community a solid, fast, and very (though not yet perfectly) compliant HTML component. This will allow OmniGroup to write OmniWeb 5 (or whatever) around WebCore and JavaScriptCore-- which takes care of turning HTML into stuff on the screen and handling the JavaScript runtime and whatnot-- so they can spend all of their time and effort on the features. This is basically the story of Mozilla, Chimera, and Phoenix, and others. One rendering component, lots of apps built around it to suit different needs.

3. OmniWeb has some cool features that frankly don't belong in Safari: built-in regular-expression URL filtering, for just one example. Some kind of MDI ("tabbed") interface could possibly be another.

4. OmniWeb has never "force fed you banner ads." It's just a browser. You can use it for free, but OmniGroup prefers that you pay for it. No big deal.

Are we a little more clear now, at least?

Immediate development?

[Shishio]

So will OmniWeb's developers begin working with Safari code now, or wait until Apple refines it? Safari is still very much a beta browser and its compatibility, one of the features Omni seems to value, needs a lot of work. As mentioned in the article, some sites crash it outright.

I would think Omni would wait until a more stable (non-beta) release is produced before changing its own browser's direction.

Also, what engine is OmniWeb based on now? I used to use it, and it kept up with Explorer moderately well. Safari and Chimera would blow it away, of course.

Re:Immediate development?

[Twirlip of the Mists]

The great thing about WebCore is that it's entirely isolated from the browser itself.

Most of the bugs users have encountered in Safari have been in WebCore-- stuff not rendering properly. As Apple continues to improve WebCore, with community help, the reliability and performance of all WebCore-based browsers will climb. All you have to do to take advantage of a new version of WebCore is to link in the new framework when it becomes available. Then you're done.

So basically there's no reason for OmniGroup, or anybody else, to wait.

Re:Immediate development?

[fidget42]

I would think Omni would wait until a more stable (non-beta) release is produced before changing its own browser's direction.

I've played with Safari and the biggest "Beta" issue that I have noticed is in the supporting features. The cookie management is rather crude (all/none/self are the only choices), but it does an excellent (and FAST) job of rendering pages. I would love to have my copy of OmniWeb be based on this code.

Re:Immediate development?

[Twirlip of the Mists]

All you have to do to take advantage of a new version of WebCore is to link in the new framework when it becomes available.

I feel kinda dirty replying to my own post like this, but I wanted to offer more details on this to anybody who's interested. I've just posted a journal article describing how to use custom-built JavaScriptCore and WebCore frameworks with Safari. In addition to being a really cool way to get in there and start playing with the new frameworks, this illustrates just how easy it's going to be for OmniGroup to build their browser.

At some point in the future, Apple may even choose to ship WebCore.framework and JavaScriptCore.framework as part of the core OS, so anybody can use them to render HTML and handle JavaScript in their Cocoa applications. (WebCore presents an Objective C interface, so it's callable from Cocoa, but not from Carbon. I think.) Of course, thanks to the way packages and frameworks work on OS X, anybody who wants to build their own version of WebCore or JavaScriptCore and ship it with their application is free do to so.

This is really exciting, y'all. This is the way free software is supposed to work.

Re:Immediate development?

[bpbond]

>I feel kinda dirty replying to my own post

You'll go blind if you do this too much...

Re:Immediate development?

[sniggly]

This is really exciting, y'all. This is the way free software is supposed to work.

Good posts! And I totally agree, I have been waiting for months for the release of KDE 3.1. I am a huge fan of KDE because the konqueror browser and its KIO slaves (allowing the thing to be browser, file manager, ftp, smb, sftp, nfs etc etc client all in one) have changed the way I can do my work for the better. Now apple is hopping on board and all their good work will trickle back into the KDE project.

All apple needs now is to plug some IBM g4s into their boxen!

I use OmniWeb ...

[daviddennis]

mainly because I like the way its rendering engine looks. Seems to me Omni is throwing away their main competitive advantage by using Safari's.

I'm using Safari right now, and the only thing I don't love about it is that the text doesn't look quite as perfectly polished as Omni's.

I'll miss OmniWeb's nicer looking text if that's really the direction they'll take.

Safari is my favourite user interface right away. Even though I understand the old-style ones, I particularly like their slick error messages. They're written in high-quality, clear language that even a novice is going to have no trouble understanding. For a choice example, try refreshing a page with a submitted form on Safari, and then try doing it with any other browser.

D

Re:I use OmniWeb ...

[Twirlip of the Mists]

I agree, but compared to Chimera, Safari is wonderful. I haven't spent much time with the WebCore code yet, so I'm not sure if the Quartz stuff is in there or in Safari itself.

Re:I use OmniWeb ...

[Twirlip of the Mists]

Even though I understand the old-style ones, I particularly like their slick error messages. They're written in high-quality, clear language that even a novice is going to have no trouble understanding. For a choice example, try refreshing a page with a submitted form on Safari, and then try doing it with any other browser.

For those without access to a Mac, here's the error message.

Are you sure you want to send a form again?

To reopen this page, the form you completed to open the page the first time must be sent again. This may cause the website to repeat actions it took the first time you sent the form.

[Cancel] [[Send]]

Re:I use OmniWeb ...

[daviddennis]

If my memory serves, Chimera's rendering deficiencies are very similar in appearance to Safari's.

Only OmniWeb does a perfect job at it, so I will be very sorry to see the original OW codebase go. On the other hand, they seem to have hit some kind of brick wall with the project - there haven't been improvements in some time. Hopefully this will help kickstart their efforts.

Thanks for reproducing the error message for me. It reminds me of why I really love Apple. Steve Jobs may be a jerk sometimes (as is Bill Gates), but he sure does deliver the goods (unlike Bill).

D

Re:I use OmniWeb ...

[b_pretender]

Although I agree that the error message does an excellent job describing the error, I have a nit to pick with any dialog box that specifically asks one question and doesn't set the buttons as answers to the question.

It's rather microsoftish. For example: Your preferences have changed. Would you like to restart to use your new preferences: [OK] [CANCEL]. Or even better, they try to word the error message around the buttons: Press OK to accept the new settings or CANCEL to discard the settings [OK] [CANCEL] rather than a much simpler: WOuld you like to accept the new settings? [YES] [NO].

Re:I use OmniWeb ...

[jd10131]

The Apple UI guidelines specifically disagree with you. Each button on a dialog is supposed to be a verb. Here is a page talking about it...

If you think about it, this makes sense. Imagine a dialog that says "You are using an outdated version of this program, do you wish to continue?" and "You are using an outdated version of this program, do you wish to exit?" If the buttons are labelled Yes/No/Cancel, I need to read the dialog carefully. If buttons are labelled "Continue" and "Exit" I am less likely to select the wrong button.

There are altogether too many times when I've triggered some Yes/No/Cancel dialog in Windows, I don't read the text carefully because I'm in a hurry, and I click 'Yes'.

Re:I use OmniWeb ...

[Graff]

It's rather microsoftish. For example: Your preferences have changed. Would you like to restart to use your new preferences: [OK] [CANCEL].

If you notice, all of the dialog box buttons in MacOS have verbs (action words) on them. Buttons are never specifically answers to questions, but are rather the action which will be taken when you click on them. For example, a traditional dialog box would say:

Your preferences have changed. Would you like to restart to use your new preferences?
[OK] [Cancel]

The proper MacOS dialog box would be something like this:

Your preferences have changed. Would you like to restart to use your new preferences?
[Continue] [Restart]

The traditional dialog box does not actually tell you what is going on when you press the button and it is easily confused with other dialog boxes that may be the same size, look the same, and have the same answers. For example, the following two dialogs could be confused and someone could accidently hit the wrong button thinking it was the dialog they expected:

Should I feed the fish?

[Yes] [No]

Should I eat the fish?

[Yes] [No]

A better set of buttons would be like this:

Should I feed the fish?

[Cancel] [Feed]

Should I eat the fish?

[Cancel] [Eat]

There is very little confusion there as to what action will be taken. Hit the [Feed] button and the fish gets fed, hit the [Eat] button and the fish gets eaten.

Re:I use OmniWeb ...

[Anonymous Coward]

Thanks for pointing that out, i was about to link to that page myself, and note that button labels should almost always be verbs.
It's nice that apple follows their own guidelines in that respect, even though they blatantly ignore the guidelines about when you should use textured windows (hint: apps like Safari and iChat shouldn't)

Re:I use OmniWeb ...

[uberpeon]

Mmm....lickable, verb activated fish....

Re:I use OmniWeb ...

[Josuah]

The metal interface is used for whatever applications Apple has decided belong in the "digital lifestyle" category. I suppose they decided to include Safari and iChat in this. Whether or not these applications deserve to be placed in there is a judgement call. I'm leaning towards no, but you have to admit that the metal interface is leaner and meaner than the regular Aqua interface.

Re:I use OmniWeb ...

[paploo]

Not to mention there isn't a Brushed Aluminum version of NSToolBar, so Safari's toolbar must be configured in totally roundabout ways (like menus and dialog boxes). If they used Aqua like they are supposed to, then they could use NSToolbar and get great, intuitive, and powerful functionality "for free".

(I should note that I use a registered version of OmniWeb, but am currently running Safari because it is faster. But I still like OmniWeb better and will probably end up back on it within 2 weeks. :) ) If there was just some way to auto-sync my bookmarks everynight when I go to bed. Guess it is time to dig out Ruby and write a script myself... but I don't want to parse the XML. :)

-Jeff

Re:I use OmniWeb ...

[splattertrousers]

WOuld you like to accept the new settings? [YES] [NO]

Or, since people read the button text before the message text, Would you like to accept the new settings? [Accept Settings] [Discard Settings]

Or, even better, no dialog box and just accept the settings and let the user undo if he made a mistake.

Or, even better, no dialog box and just accept the settings, and have a little slider in the settings window that lets the user slide back in time to any settings he had ever made.

Re:I use OmniWeb ...

[ealar dlanvuli]

I actually metalized all my applications, once everything matches it looks really slick. I have a strange feeling this is what some of the apple developers have, thats why they are so fond of it.

Re:I use OmniWeb ...

[Graff]

The one I HATE in wondows is when they change the save action on you.

Exactly. If the options had been [Don't Save] [Save] then there would be very little confusion about what action is going to be taken.

One other cool idea in human interface design is to make the least destructive action the default action in any "dangerous" dialog box. For example:

Erase entire hard drive?
[[Cancel]] [Erase]

Yeah, it's a little pain to not have the [Erase] button highlighted automatically, but it's worth the safeguard considering you are talking about the potential loss of all of your data.

WebCore

[madcoder47]

can anyone direct me to an example of how WebCore is implemented?

I am trying to make a simple WWWView (its a subclass of NSView) in an Objective-C/Cocoa application I am building, and it seems that WebCore is just what I need to use.

The header files havent helped me much, as im not sure quite what the methods are to make the View a WebCore view.

I believe the correct class to use from the WebCoreFramework is WebCoreBridge, but when i do [[WebCoreBridge alloc] init] and assign the result to a WebCoreBridge *, the app dies with SIGTRAP.

Basically, I'm looking for help in getting a WebCore view in the GUI of an application i'm writing.

Right now Im sort of stuck.

if anyone knows how to implement the WebCore, please reply or email me (madcoder@madcoder.net)

Re:WebCore

[Twirlip of the Mists]

I can't give you the information you want, but I wanted to let you know that I've appealed to somebody who can. Dave Hyatt works on WebCore (he has a blog) and if anybody can provide a pointer to docs, he probably can.

The most likely answer is simply going to be no, there's no public documentation yet, and to wait before trying to do what you're trying to do. But you never know. I'll post if I get a response. (I'm sure Dave's very, very busy just now.)

Re:WebCore

[EccentricAnomaly]

I bet the omnigroup's dev lists will be a good place to look also. If Omni's team is learning webcore it seems like there will be a lot of good stuff on the lists....

Re:WebCore

[Teese]

Use the source.

source code to webcore found at http://developer.apple.com/darwin/projects/webcore /index.html

I haven't used or downloaded the source - so I'm not entirely sure its what your looking for, but use it for what its worth.

Re:WebCore

[King Babar]

I can't give you the information you want, but I wanted to let you know that I've appealed to somebody who can. Dave Hyatt works on WebCore (he has a blog [mozillazine.org]) and if anybody can provide a pointer to docs, he probably can.

Thanks for the link; Hyatt's blog gives some info on what kind of CSS support should be there (much of CSS2 and bits of CSS3), what the status of XML rendering support is (not yet), and that, yes, a bug they just fixed did prevent it from running the CSS1 test suite at w3c.org. Now all I have to do is convince them that the lack of type-ahead-links and type-ahead-find in web pages are truly important shortcomings in Safari...I'm afraid that tabs might be beyond their UI guidelines.

Re:WebCore

[Twirlip of the Mists]

Now all I have to do is convince them that the lack of type-ahead-links and type-ahead-find in web pages are truly important shortcomings in Safari

What are those? I'm not familiar with those features.

I'm afraid that tabs might be beyond their UI guidelines.

There's an extremely active discussion going on over in the Apple support forum about how-- if at all-- to implement a multiple document interface for Safari. There seem to be three camps on the issue: 1) Tabs are absolutely essential for browsing, and not including them is stupid. b) Tabs are bad and wrong, but some kind of multiple-document interface would be a good idea. iii) The best way to browse the web is with the good old single-document interface paradigm: one web page, one window.

Myself, I fall somewhere between b and iii. I think a multiple-document interface for browsing is a dumb idea-- once you look past the superficial details of how to arrange the widgets on screen, you run into a whole assload of inconsistencies and irregularities in the paradigm-- but I think so many people are clamoring for it that it makes sense to try to make it work. But I wouldn't vote for a MDI that's anything less than absolutely perfect. Better not to use MDI at all, even as an option, than to implement it in a bad or illogical way.

Re:WebCore

[King Babar]

Now all I have to do is convince them that the lack of type-ahead-links and type-ahead-find in web pages are truly important shortcomings in Safari

What are those? I'm not familiar with those features.

You get these in Mozilla. Imagine you're looking at www.yahoo.com. There are hundreds of links, and you can visually scan them easily. Now to choose the one you are looking at...you have to take your hand off the keyboard, and hit a relatively tiny link with something shaped too much like a hockey puck. Or you could just type some of the text in the link, and have Mozilla highlight it for you, hit return, and the browser will follow the link. This might sound weird, but I insist that you try it in a recent version of Mozilla. Once you've seen the light, you don't want to go back. It's that good. Notice that unless a text widget or the location bar has the focus, typing text does nothing usually, so doing so is (I think) a fairly intuitive act. Type ahead find in the page is...perhaps less intuitive unless you're a vi or "less" (the pager) junky. If you type /perfect (with the slash), you're asking Mozilla to find the text "perfect" anywhere in the page and go there. That's a micro-optimization of cmd-f, really. I like it, but it doesn't ruin my life not to have it.

I'm afraid that tabs might be beyond their UI guidelines.

There's an extremely active discussion going on over in the Apple support forum about how-- if at all-- to implement a multiple document interface for Safari. There seem to be three camps on the issue: 1) Tabs are absolutely essential for browsing, and not including them is stupid. b) Tabs are bad and wrong, but some kind of multiple-document interface would be a good idea. iii) The best way to browse the web is with the good old single-document interface paradigm: one web page, one window.

OK, so I suppose it's possible that there is a better UI notion than tabs waiting to be discoverd to do multiple-document interfaces, but choice iii is just insane. Look, if tabs bother you, then I guess you don't like multiple links on a web page either. In my mind, it's basically the same kind of thing; you want to see where you're likely to want to go and be able to make it happen with a minimum of fuss. Sure, I could cmd-~ my life away through a bunch of windows, but since most of them would be hidden, I can't easily tell what is there. With a row of tabs, I can just see everything in my working set, and then select a tab to go there (just like hitting a link in spirit). A secondary nice thing about tabs is that I personally use them to organize my browsing. Often, I have one window full of tabs that point to results of various BLAST searches on NCBI, another window with tabs that point to my course web pages and stuff like that, and third window that has stuff like, well, slashdot on it. Easy to go from window to window, and then from tab to tab; voila, my very own hierarchical web interface and no hands ever leave the keyboard. :-)

Myself, I fall somewhere between b and iii. I think a multiple-document interface for browsing is a dumb idea-- once you look past the superficial details of how to arrange the widgets on screen, you run into a whole assload of inconsistencies and irregularities in the paradigm

Look at Mozilla, or even the Apple home page that *explicitly* uses tabs as the navigational metaphor. The Apple home page looked weird for about 30 seconds, but then my only complaint was that the tabs were just a fakey image hack.

but I think so many people are clamoring for it that it makes sense to try to make it work. But I wouldn't vote for a MDI that's anything less than absolutely perfect. Better not to use MDI at all, even as an option, than to implement it in a bad or illogical way.

Well, sure, a bad implementation would suck. :-) But I really don't want to get into a situation where the perfect is the enemy of the good. There are some issues with the current Mozilla tab interface (cntrl-page_up to cycle through them is not a terrific choice), but I'd fix the obvious problems and put it in as an option in the Beta. They would get feedback on the feature, and I'd be surprised if it were less than strongly supportive.

Re:WebCore

[Twirlip of the Mists]

As far as the typing thing you described goes, I can honestly say that I've never even thought of something like that before. It doesn't strike me as something I'd ever use. I've almost always got one hand on the mouse anyway.

With a row of tabs, I can just see everything in my working set, and then select a tab to go there (just like hitting a link in spirit).

How is that different from the "Window" menu? Since "Window" is in the menu bar at the top of the screen, it's way easier to hit with the mouse. Two clicks (or a click-and-drag) gets you where you want to be. Granted, that's twice as many clicks as you'd have to use with tabs, but the Window menu doesn't have any of the bad implications that tabs have. There's no ambiguity between closing a window and closing a tab, for instance. You're also not limited in how long your window titles can be, because in the menu they're represented vertically instead of horizontally. When you pull down the Window menu, you get to see as much of each page title as will fit across your screen, dozens of characters at least. (When we all have 23" monitors, it'll be hundreds!)

Look at Mozilla, or even the Apple home page that *explicitly* uses tabs as the navigational metaphor.

Okay, if we're gonna get into this, we might as well get into it. Here's the problem with tabs.

In Chimera or whatever, a tab basically represents an invisible view. (Here I'm using "view" in the sense of NSView, a representation of in-memory contents on the screen, with a scroll bar and stuff.) Normally a view is bound to a window. Think TextEdit here. If you open a document, you get a window that contains a view of that document. When you close the window, the view is closed, too. The view doesn't linger around.

But tabbed browsing breaks the one-to-one link between views and windows. One window can have more than one view. In and of itself that's okay, except for the fact that no other application works like that. If I open two documents in TextEdit (for example), I get two windows. Close one, and the other stays open. Tabs don't work like that. If you close a window that contains three tabs, you lose not only the view you were actively looking at, but two other views that you weren't seeing at that moment. So you instantly have a user interface problem there.

So to solve that problem, let's completely separate views from windows. Views are now global, associated with an application instance. Any window can display any view. (What if you assign two windows to the same view, and then click a link in one of them? Well, both windows are going to update, of course. Does that make any sense? Intuitively, no. But in context of the detached-view metaphor, yes. So we'll go with it for now.)

So let's say you launch Safari. You get one view created for you automatically, and one window to show it to you. That view, in that window, loads your home page. But let's say you want to create a new view. (I would say a new tab, but we're not using tabs. I hope this isn't too hard to follow. It makes perfect sense in my head.) So you go to the menu and... what? What are you really doing? Creating a new view, or pushing the existing view to the back of some notional pile? What you really want to do is set the current view aside and create a new one, one that you can work with for a while before returning to this one again. How do we represent that in the form of a menu item? We could say "new view," but then you have to explain somehow what a "view" is. Remember, a view is invisible until a window is assigned to it, so "new view" really means to create something that you can't see. That's confusing. What if we approach it from the other angle? Rather than creating a new view, you're taking the one you're currently working with and setting it aside. Maybe the menu item is simply "set aside." I don't know; we can work out those details later. But this is a critical point!

So now you've got a window with two views. You can only look at one view at a time, of course, but if you should want to see two things at once you can open another window and pick the other view. And so it goes.

So you get to the point where you're done with one of the views. You want to get rid of it. You're not going to use it any more. What do you do? Close the window? No, remember, the contents of the window are persistent now. Closing a window doesn't make its view go away. So we have to come up with yet another new menu item. "Close view?" Yeah, I guess, but how can you "close" something that doesn't have any physical representation on screen? "Delete view?" That's not perfect either, but it'll do for now.

So where are we? Our users are having to spend a lot of time thinking about logical entities that have no physical screen representation: views. They're having to think about creating and deleting views. The old trick of simply closing a window doesn't get it done, because we've changed the way windows and their contents are related to each other.

All in all, it's a hell of a mess.

On the other hand, you can do everything you want to do right now with windows. Wanna click a link, but not read the resulting page right now? Open it in a new background window. (Command-shift-click; the request is in to make this a context menu item, too.) Wanna reduce desktop clutter? Minimize windows to the dock. Wanna get to any window in a single click? Use the "Window" menu to select it by title, just as you would a tab.

So the situation here is not a question of whether or not "tabbed browsing" (but without the tabs) would be good, or even possible. It's a question of whether it would, if perfectly implemented, provide some new feature or benefit that cannot currently be enjoyed by the users. The answer is no. So why go upsetting the whole goddamn user interface paradigm apple cart (no pun intended) to implement tabbed browsing, when it provides no new functionality?

Re:WebCore

[jericho4.0]

I agree with all of your points. I've been bitten many times by thinking I'm closing one view and losing 5 or 6 tabs in that window.

I still like tabs, though. And multi-button mice. Maybe sometimes you can break the rules.

One thing I thought of when reading your post. It's be nice that when I close a browser with tabs in it, it actually just becomes another tab in another open browser window, unless that's the last window.

Re:WebCore

[ealar dlanvuli]

After using Safari for a day, my view of tabs has completely changed. This is the first non tabbed browser I have used that allowed easy creation of new windows (apple+click or apple+shift+click) when following new links. It is also the first browser I have used that doesn't use a meg and a half of memory per window, or take longer than a 10th of a second to make a new window. With these features, tabs become redundant in Safari, I'll explain why below.

If you really think about it, tabs are an optimization seeking a metaphor. Origionally tabs were added when making a new browser window was a > .4 second affair, and really ate on the system resources. Also switching between windows in the same app on may operating systems is a nontrivial task. On osx one can simply use apple+` to switch windows in the same app. Tabs are really an optimization so you only have to have "one window", they are not in any way a document organization metaphor. How many times have you actually organized similar tabs in the same window? I'm guessing never. How many tabed browses out there even let you drag tabs between windows? I'm not noticing many. The real benifit of tabs are load-behind loading, and load-on-middle click. The other benifit is "group bookmarks". None of those traits are specific to tabs. I conclude then that the overwhelming love of tabs has more to do with the redicioulus cost of multiple window interfaces in most browsers/os's that are not relevant to Safari/osx. Thus it would be in apples best intrest to leave them out, and make the interface the most efficent web browser out there!

Re:WebCore

[2nd Post!]

What you are describing can be thought of as a stack!

So you remember the OS 9 tearable Application Switcher?

What if, instead of apps, they had a Website Switcher. Which, functionally, is similar to tabs. The drawback to tabs, right now, is that you cannot arrange them and cycle through them, so there is inefficiency in actually mousing to them, and they *also* don't show up in the Window menu.

If, however, you make tabs 'collapsable', in that you can move a window onto a stack and have them 'share' real estate, I think that would work.

In the sens of a stack, hitting 'close' would close the topmost window; makes sense, since that is the one the viewer is looking at, and closing a window that is not visible is going to be very error prone.

Likewise, creating a new 'view' should appear on the 'top' of the stack, but with a simple opt-select, can be dragged anywhere in the stack (it's only superficially a stack).

So now you've got 'views' and 'windows'. You can actually close windows, and kill all the views, or you can kill the views on layer at a time.

Oh, another metaphor! The Photoshop 'layers'. Or, the way Photoshop stacks tabbed windows atop each other.

I see nothing wrong itself with tabs or MDI. You can imagine each tab akin to an icon in the Dock, and the Site Switcher is akin to the Dock or the Application Switcher. People are not unuse to the idea now. New window will always create a single view, and you can drag views in and out of windows, and a window can store multiple views, each view selectable from a tab or from the Window->view menu (multiple views separated by a separator line). Again, it's no more complicated or difficult than the implementation of the Application Switcher, the Dock, Photoshop Layers, Photoshop Palette Windows, or even the tabs you find at the Apple website.

Re:WebCore

[billDCat]

and that, yes, a bug they just fixed did prevent it from running the CSS1 test suite at w3c.org.

Cool! I submitted that bug last night, as I am sure others did as well. It would be nice to believe that Apple responded that quickly to the bug reports, although it may have already been on their bug list.

Now to see if they act on the "bug" reports on the lack of tabs!

Re:WebCore

[gig]

Safari has a number of UI elements that replace tabs. Snapback in the address field and search fields takes you back to where you started surfing. You can also drag links to the Bookmark bar and then drag them off again easily, like a little shelf. The little book icon on the left of the Bookmark bar switches the window to a view of your Bookmarks and History, like lifting up a page to look at a TOC. Plus, it is FAST. I find myself just surfing rather than opening up a bunch of windows because pages appear instantly.

Also, the menubar is pervasive, so the History and Bookmarks menus are right there all the time in the same place. Safari also shows the URL's in your Address Book in the Bookmarks menu, so even without tabs, you find yourself having lots of clickable links right away, and plenty of room to put more.

It's a great browser.

Re:WebCore

[CwazyWabbit]

But tabbed browsing breaks the one-to-one link between views and windows. One window can have more than one view. In and of itself that's okay, except for the fact that no other application works like that. If I open two documents in TextEdit (for example), I get two windows.

gedit will open files in multiple tabs. Aside from that MDI was the way to go for a long time in the MS Windows world, before they decided that SDI was better. There are plenty of MDI applications out there, it's just not currently popular. But people have used them for years.

...when it provides no new functionality...

Tabs allow you to group related views, giving you an extra level of organisation over a single window per view.

Re:WebCore

[Alan Partridge]

I completely agree, and one of Omniweb's sweetest features to me is it's ability to open links behind your current window. I don't mind tabbed browsers, but auto sizing pages utterly destroy them. Apple have already giving us a fairly efficient window manager - all the browser should do is use it effectively.

No tabs for Safari please!

Re:WebCore

[SandSpider]

The basic gist of the problem is that you don't think tabbed browsing really works well. You list a lot of problems, and give lots of good theoretical reasons why they won't work, but the truth for me and many, many users is that Chimera's tabs work for us so much better than Safari's single windows. Period.

The advantage of tabs is enormous, and the only complaint I've heard is closing the window will lose many of your tabs. It's something you learn not to do, by and large.

You claim that no other Apple application uses Tabs, but you might want to load up Project Builder sometime to see that it's not really true. Tabs are useful in certain circumstances, and one of those circumstances is when you have a lot of information that you don't necessarily need side by side. The web is perfect for tabbing.

The paragraph about 'new views' and such? It means nothing to a user. It may be confusing to program, but so what? It's really, really useful. If you want to know the best way to program it, start with Chimera's implementation.

Of course, the best thing Apple could do for the success of Chimera is to not add tabbed browsing. Whatever other features, speed, or stability they might add, I and many others will go back to Chimera if Tabbed browsing isn't added to Safari.

=Brian

Re:WebCore

[NaugaHunter]

Now I'm really confused. Wouldn't multiple browsing windows be a multiple document interface?

And if what people want is easy flipping, why not enable keyboard menu commands and use the Window menu? {Ctrl-F1 and Ctrl-F2; typing 'Full Keyboard Access shortcuts for activating access' in Help should give more info, or view article 61466 from Apple Support.}

Personally, I'd think having a keyboard shortcut that pops up a Window list would be more useful than tabs - it wouldn't waste space, and would be quick and informative.

Re:WebCore

[Twirlip of the Mists]

I completely agree, and one of Omniweb's sweetest features to me is it's ability to open links behind your current window.

Safari can do this, too. Command-shift-click a link. OmniWeb has the feature in a context menu, unlike Safari, but that's the only difference.

(I may have mentioned this before. Pardon me if I'm being redundant; I just woke up.)

Re:WebCore

[ennerseed]

In Chimera tabbed windows, being the full window, are closed by "shift cmd w", and tabs are closed by "cmd w". Which actually, following previous Mac apps/os and I'm sure Apple guidelines, should be switched.
You can also close the tab by control clicking the tab. It seem to me to follow the previous apps/os implementing the small version of the close, minimize, and maximize buttons in the tabs would solve some of the problems that you speak of.
I guess the close button would close the tab. The minimize could send it to the Dock, for way later viewing? The maximize to bring the tab to a new window.
I realize that this changes the way it works for full windows. But its a tab it should have some differences, yet keep familiarity and some simplicity to the user.
It would be great to actually see this be brought to the entire os.

Re:WebCore

[Twirlip of the Mists]

If, however, you make tabs 'collapsable', in that you can move a window onto a stack and have them 'share' real estate, I think that would work.

You mean like the Dock? ;-)

I don't mean to be flip, but instead of trying to figure out new and different ways of doing things, spend a few minutes first trying out the built-in ways. You might just find that they get you right where you want to be without any additional hand-wringing at all.

I see nothing wrong itself with tabs or MDI.

What's wrong with it is that it's "different and same." Tabs/MDI is a different way of doing things. Different and better is okay; that's how innovation happens. Different and worse is terrible, of course, but one man's worse is another man's better, so sometimes it comes down to a judgment call. But different and same-- in other words, providing no new functionality but simply a different way to accomplish the same task or goal-- is bad. It makes your application bloated and confusing. Having two equivalent ways of doing the same thing can make novice users spend more time deciding which one to use than either one of them would have required. Faced with both "open in new window" and "open in new tab," a significant fraction of users will sit and stare at them and say, "What's the difference? Which one do I want?" which makes the whole experience no fun for anybody.

You can imagine each tab akin to an icon in the Dock, and the Site Switcher is akin to the Dock or the Application Switcher.

Heh. Or you could just use the Dock.

Re:WebCore

[Twirlip of the Mists]

gedit will open files in multiple tabs.

Not a Mac app. The fundamental strength of the Mac is that every Mac app works (more or less) the same as every other Mac app. On Windows, or even Linux, on the other hand, one application can often be completely different from another. This results in a bad user experience. It's hardly something to emulate.

Aside from that MDI was the way to go for a long time in the MS Windows world, before they decided that SDI was better.

As you yourself note, even Microsoft, who invented MDI, have since deprecated it in favor of SDI. To go back to MDI now is to go against a decade-long tide of UI development.

Tabs allow you to group related views, giving you an extra level of organisation over a single window per view.

Not to put too fine a point on it, but no, they really don't. You can't drag tabs from one window to another. You can't reorder tabs. You can't organize tabs either spatially or in relation to one other except by altering the order in which you open them. Windows, on the other hand, can be arranged in any way a user sees fit. They can be stacked, tiled, or cascaded to suit a user's needs. And easy access to an individual window is always there, via the Window menu. To reduce clutter, windows can easily (one keystroke or mouse click) be minimized to the dock, where they're represented not just by name (as in tabs) but by a real-time scalable thumbnail image.

In other words, windows let you do everything tabs let you do, and more, and better.

Re:WebCore

[Twirlip of the Mists]

The basic gist of the problem is that you don't think tabbed browsing really works well.

Just to clarify, I think that tabbed browsing at best provides you with the same functionality you could get through use of the Window menu and the Minimize function, only not as well. Since it's "different and same," I'm lobbying for its exclusion from Safari.

I don't care if other browsers implement it. But Safari is an Apple flagship application. It needs to have the highest degree of ease of use and UI consistency. Adding tabs will compromise that for no benefit whatsoever.

You claim that no other Apple application uses Tabs, but you might want to load up Project Builder sometime to see that it's not really true.

I claim that no other Apple application uses tabs to represent multiple documents in the same window. Project Builder uses tabs to represent different modes of the interface: build, find, debug, et cetera.

In Project Builder, the document is the project itself. When you open two projects at once, each one gets its own project window. (Depending on how your prefs are set up, there may be other windows as well.) Project Builder never puts two separate projects into the same window. Ever.

I'm starting to come to the conclusion that the people who like tabbed browsing most often come from Windows, where there's the issue of taskbar crowding, or UNIX, where opening a new window can be a significant investment of time and CPU cycles. I'm sure that's not always true, but I'm quite confident that the desire for tabs will disappear completely once a person learns how to use the Window menu, Minimize and the dock, and command-`.

Re:WebCore

[Knife_Edge]

Wow. I had never looked at tabs this way before. Truly, Safari's window creation speed and ease of switching does make them much less necessary than they are in slower, clunkier browsers.

My feeling is that tabs are a feature that the average user is going to have difficulty understanding. I think Apple will implement this feature as turned off by default (and thus absent from the UI of each window) unless you specifically turn it on. 'Power' users will probably be satisfied by this, but as you so cleverly pointed out above, it is mostly unnecessary for Safari. I have been using tabbed browsers for over a year now but that does not mean I am not prepared to abandon them for a browser that does multiple windows right!

Re:WebCore

[SandSpider]

Just to clarify, I think that tabbed browsing at best provides you with the same functionality you could get through use of the Window menu and the Minimize function, only not as well.

Here I disagree. And I suspect we will continue to do so, but I neglected to mention this on my first post. The window menu doesn't allow you to see, at a glance, what sites you have up and active. And, in Mouse Time, click-drag-un/click takes a whole lot more time than just click. If there were, say, a floating palette of the currently active windows, that would almost be as good, but that takes up a lot more screen real estate than tabs.

Project Builder never puts two separate projects into the same window. Ever.

No, but it does allow you to have different documents within that project to be in the same window. You can flip between different source files and they show up in the same window. It's the same thing as tabs, but just using a file list instead of an actual tab.

Speaking of, it's also similar, conceptually, to the preview pane used in mail programs (such as Mail). It's a view that shows different documents in the same space, which is changed by the click of a button on an element that represents what the view will contain. It just uses a list rather than tabs, just like Project Builder.

=Brian

Re:WebCore

[Alan Partridge]

cool - I haven't played with it much yet...

Re:WebCore

[Twirlip of the Mists]

The window menu doesn't allow you to see, at a glance, what sites you have up and active.

Huh? Oh, you mean you have to pull it down, right? Okay, trade-offs.

And, in Mouse Time, click-drag-un/click takes a whole lot more time than just click.

Not actually true. Because tabs are at the top of the window (or side, or wherever) they present a very small mouse target that the user has to it. Hitting the menu bar is much easier, because it's essentially infinitely tall: just push your mouse forward until you get to the top of the screen; you don't have to be precise. The menu bar is easier and faster to use than tabs.

This, of course, ignores the important fact that the Window menu shows you all, or at least a great deal of, the titles of your windows, even on the smallest screen. Tabs can't do that.

No, but it does allow you to have different documents within that project to be in the same window.

Okay, then implement it Project Builder-style, with a pop-up list of pages or whatever. The net result will still be a feature that's harder to use and less effective than the SDI/Window menu way.

Re:WebCore

[spitzak]

I think the gist of this is that there are problems because overlapping windows and tabs work differently. Wasn't there some X window managers that made several windows into a set of "tabs"? For instance every xterm you ran would add a new tab to the xterm stack. If tabs are a good idea it seems like a solution like this where every program could take adavantage and there are well-defined ways to convert a "view" between a window and a tab is a good idea.

Re:WebCore

[2nd Post!]

How can I use the Dock? What I want is *one* HTML window with multiple HTML views.

The Dock gives me multiple HTML windows with one HTML view each, and one Moz icon with multiple Windows accessable via the menu.

An analogy would be how Mail.app keeps multiple emails but only provides one window, unless you double click on an email, and then giving you additional windows.

Mail's email list is ordered by date, since emails can logically be ordered by date received, though some people like to order them by priority, by sender, by subject, etc.

If we imagine a hypothetical web browser with a 'list' view, we could order sites by alphabet, date, user preference, or rank. Using this hypothetical web browser would not be any different than using Mail.app, theoretically.

What you would be doing *different* than the 1 window 1 view is that you are collapsing multiple sites into one 'browser'. The same way that iTunes is an mp3 browser, iPhoto is a photo browser, Finder is a file browser, Mail is an email browser, then Safari2 could be a 'website browser'.

Tabs are the implementation Mozilla uses, but it's not the only way. Having a drop down, having a list view, having a hierarchy, or a playlist view, etc, works. If you look at Safari, it already has this idea, in that bookmarks are available in a playlist like view. The difference is that, for performance reasons, Safari could 'preload' select special sites so that clicking on the bookmark would nigh instantaneously access the site, instead of loading off the web.

So I do believe the multiple website interface is workable, if only because iTunes, iPhoto, Finder, and Mail, as well as the Dock and Application Switcher, all seem to implement something structurally similar.

Re:WebCore

[Twirlip of the Mists]

What I want is *one* HTML window with multiple HTML views.

Sorry, you can't have that. ;-) What else do you want me to say? That's not the way windows work on a Mac.

The same way that iTunes is an mp3 browser, iPhoto is a photo browser, Finder is a file browser, Mail is an email browser, then Safari2 could be a 'website browser'.

No, that's not right. iTunes shows you a list of MP3's, iPhoto shows you a list of photos, but Safari does not show you a list of web pages. It would, if implemented in the way you describe, show you a list of views of web pages. Any view can display any web page. So the whole comparison to iTunes, iPhoto, et cetera breaks down. Safari just simply doesn't work like that, so it would be a bad thing to implement a similar UI.

For bookmarks, Safari's bookmark view works. Would that same view work for browser instances? Absolutely not.

Re:WebCore

[2nd Post!]

Sorry, my language is too imprecise.

iTunes only provides one playlist view at a time *unless* you double click on a playlist, and a new window opens up.

But clicking on each playlist brings up a different 'view' in the same window, so in that respect iTunes supports multiple views in one window.

In the *same* analogy sense, tabbed browsing, via tabs rather than playlists, supports multiple views in one window: Click on any tab, and a different view is presented.

So that's all I mean when I say that multiple views, one window, is workable for web browsing because it's already been implemented in iTunes, iPhoto, Mail, etc. One 'view' is active at a time, yes, but they do have a collection of alternative views switchable at any time. Does this sound like bookmarks? Perhaps, but implementation wise you can imagine that Safari2 precaches a select list of bookmarks so that when you click on the link it loads instantaneously. That is, theoretically, how tabbed view can be framed in a coherent and consistent interface, I believe.

Re:WebCore

[Graymalkin]

I discovered the same thing using Safari. My Powerbook has extremely limited screen real estate, I have 1024 horizontal pixels by 768 vertical pixels. With a menu bar and Dock (it takes too long for the Dock to pop up when I hide it) I lose some of that already valuable space. I thought Mozilla/Chimera's tabs were the best thing since sliced bread because I could option+click in Chimera to open a tab behind my current one. The downside to that is losing some screen real estate to the tab bar, Chimera is better than Mozilla at this but it is still an issue. So I started using Safari and discovered that shift+option+click worked fine for opening windows behind my current one and command+` did a fine job of switching between windows. Between those two keyboard shortcuts I dropped my reliance on tabs. A window behind my current one is easily accessible and I don't love screen pixels to a tab bar. The only thing I'm missing anymore is Chimera/Mozilla's password manager which I use extensively. I was thinking at first Safari would need tabs to replace Chimera but as you did I found tabs to be more of a hassle than they are worth.

Re:WebCore

[Twirlip of the Mists]

So that's all I mean when I say that multiple views, one window, is workable for web browsing because it's already been implemented in iTunes, iPhoto, Mail, etc.

Hmm. I still don't buy it. While what you're talking about could be done, I can't seem to think of a decent reason for it. There would be trade-offs, too; you'd have to have an iTunes/iPhoto-style sidebar, and those are always so wasteful of screen real-estate, not to mention being particularly unfriendly when dealing with long titles.

The bottom line is that the current way of doing things, despite your own preferences, is demonstrably better. The Window menu doesn't take up valuable screen real estate (lots of people are still running 1024x768 on their iBooks and 12" PowerBooks, remember), and it doesn't require users to deal with absurdly truncated titles.

So unless your idea brings some actual new features or functions to the table, I can't say I'd vote for it in a poll.

(It's better than tabs, though. Ugh. ;-) )

Perhaps, but implementation wise you can imagine that Safari2 precaches a select list of bookmarks so that when you click on the link it loads instantaneously.

No, prefetching is a bad idea. Most people still access the internet via modem, and prefetching a bunch of web sites-- or even just two or three-- can easily swamp a 56K connection for tens of seconds or longer. One of the great things about Safari is that it's so lightweight; launching it takes just a second or two even on a slower machine. (I have a 400 MHz G3 iMac here to prove it.) Adding a bunch of prefetching to the startup process would just bog things down.

Re:WebCore

[2nd Post!]

See, but prefetch is a *choice*

Quicktime gives you leeway by letting you tell the system your bandwidth and instant on settings.

In the same way Safari2 would know too... "Oh, he's not using his bandwidth" or "Hmm, he's got crappy bandwidth"

So this has rambled. Let me reiterate, then:

Perhaps a drawer or a pane for tabs/views/links/bookmarks. Personally I like a row of horizontal 'tabs' over a row of vertical 'links' but that's a quibble over interface layout' like the difference between a text only toolbar and a window attached menubar :D

Clicking in 'smart' bookmarks has nigh instantaneous response because the system has 'preloaded' the page. It will periodically check for a delta, and download it, according to your tastes and your bandwidth.

As per screen real estate, these tabs/views/links/bookmarks collapse into the 'Window' menu if they are active, 'Bookmarks' if they aren't. Clicking on a Bookmark opens the site; if the site is already open, it refreshes it.

Closing a view opens up the next 'smart' bookmark in the stack, sorta like turning pages or popping a stack.

Opening a view puts a new page on the stack.

Closing the last view closes the window.

Double clicking on a view pops open a new window. Closing the window doesn't get rid of a view until it is removed from the stack, however.

Re:WebCore

[ealar dlanvuli]

OH!!!! His line of thinking made me come up with an absolutely brilliant idea. A drawer containing all the sites linked to from the current page, you would pre-load just the html for the pages to get correct titles (it would only show the changing parts, since most sites have a pre or post-fix) and THAT would be usefull? You could get all the windows as a single pipeline after the main pageload has occured, canceling it the instant the user does something dealing with navigation.

Give me some feedback, I'm thinking I have a really good idea here.

Re:WebCore

[ealar dlanvuli]

I'm going to have to rebute you with the following, its the same thing I tell windows users who ignorantly persist they could not like a Mac.

Use Safari for two days (really use it... a few hours each day) and then analize weither you really desire tabs that much.

Re:WebCore

[marmoset]

Exactly. There was a great post here that talks about tabs as a hack to work around the fact that new window creation speed is so lousy in most browsers. The most impressive thing to me about Safari is how fast it pops open and populates new windows, even on my poky 450 MHz G3. I've been a Mozilla user since the 0.7 days, and later Chimera, so I had become pretty accustomed to tabs, but I can honestly say after 3 days of using Safari with it's InstaPop (tm) windows, I don't miss them.

Re:WebCore

[SandSpider]

I've used Safari from the second (give or take) that the download was available on Apple. I wrote all those messages in Safari, and I'm writing this message in Safari. I've been using a Macintosh since there was a Machintosh, so I'm quite fond of Apple Technology. I used Cyberdog and all of its component-based ilk, cause I thought it was super cool.

That being said, I will use Safari until the 1.0 version comes out, and if that version doesn't have tabs or something equally convenient, I'll almost certainly switch back to Chimera. If they put tabs in later, I'll probably switch back.

=Brian

Re:WebCore

[King Babar]

Safari has a number of UI elements that replace tabs. Snapback in the address field and search fields takes you back to where you started surfing.

OK, so my comment began its life as something of a screed, but now I think I see the way to get the good effects of tabs with none of the crufty side effects. The cool thing about tabs is that they give you visual feedback about where you have been that you decided you want to go back to, and ideally an easy way to get there. (Current Moz has issues with the last one.) What made the little lightbulb go on in my head was:

The little book icon on the left of the Bookmark bar switches the window to a view of your Bookmarks and History, like lifting up a page to look at a TOC. Plus, it is FAST.

The little icon does not impress me (the shortcut is option-command-B, but should be more accessible than that as we shall see). The notion of navigating through bookmarks the same as history the same as anything else...does.

First off, I'll note that right now, what I will call "Collections View" has some problems with keyboard navigation. You can't go from the left (Collections) column to the right or vice versa without using the mouse, and you can't "launch" (or revisit, see below) a URL by hitting carriage return, as you'd expect from something viewable and highlighted. It would also be nice to be able to type text in this view and have it work as the Apple File Selectors of old (incremental highlighting; push return and you select).

Now,here is my solution to the "Tabs are necessary but eveil problem". Note that the list of currently open windows is a very reasonable collection. As such, there should be folder in the Collections Column labelled "Current Windows" (or something) whose contents would appear as the list of current sites being visited and their URLs. In one way, this recapitulates information in the window list under "Window", except that it contains only the list and not the other stuff, is more flexible, does not require the use of the mouse not going to use a "Window" menu, and could easily handle dozens of entries. Now navigating the entries in the "Current Windows" collection has the intuitive meaning of helping you "visit" one of the current windows. Again, this should work just great because the list of current windows is the list of current pages and is emphatically a reasonable collection.

Now, if one were a "tabs" user, what you'd do in practice is hit option-cmd-B, navigate to the window=page=line of interest, and hit "Return". Navigation could be via arrow keys, but again I would strongly suggest also allowing users to type in names that would be highlighted (possibly incrementally) a la Mozilla's type-ahead find in page and like the old Apple file selector. Hitting carriage return then loads the URL and returns you to "page view"; hitting cmd-return loads it in a new window and returns you to page view.

There are several advantages of this over Mozilla's tabs:

1. There are no tabs. :-)
2. Each page can have a different size/shape window.
3. You use vertical space for navigation in collections mode generally, so now more current windows can be handled elegantly than in any plausible tabs interface, while none take up space unless you're navigating.
4. There is just one window per document after all. (Although all but one can be hidden)
5. Everything is achievable from the keyboard.
6. When in "bookmarks" view, typing text can be like "type ahead find" in Mozilla, or for Mac types, the way typing text in file selector dialogs used to work (incremental completion). The Mozilla way has the major problem now that you can only cycle through tabs, rather than directly address each one.
7. There's no confusion between closing a tab versus a window.
8. If "current windows" is a collection, you can manage/shuffle/whatever windows (=current pages) in the same way you can anything else that shows up as a collection.
9. Note that "show all bookmarks" view is, in fact, a mode, and an appopriately used mode. If it were made a powerful mode, people who wanted to use it that way would be rewarded while nobody else would ever be confused.

   I swear this has to be the correct way to deal with this. It's a better way than tabs, breaks no current UI rules that I know of, provides a lot of power without requiring people to use it...it just has to be the right way. Hey, you could then even select the contents of "Current Windows" and save them into a folder for later, or make bookmark them from this view, or what have you.

   So you've convinced me that Collections is a really great thing...if it were only done completely (include open documents) and with beefed up keyboard navigation.

   Let the flames begin:-)

Re:WebCore

[King Babar]

The window menu doesn't allow you to see, at a glance, what sites you have up and active.

Huh? Oh, you mean you have to pull it down, right? Okay, trade-offs.

Pull-down menus are a particularly annoying trade-off in my mind. The mouse is always slower than the keyboard. But this is okay, since I realized moments ago that there doesn't have to be one. The list of open windows is a perfectly reasonable collection to track (at least as reasonable as History), and could be navigated under what you might call "Bookmarks" view (what you get when you click the book icon or hit option-command-B). Done correctly, this provides a perfectly useful alternative to tabs that I'm getting excited about, as suggested in the post I just made about this.

Really, once I realized what you could potentially do with the bookmarks view this way (it ain't there yet), I knew this was the right answer. :-)

Re:WebCore

[Phroggy]

It seems to me that there are two reasons for tabbed browsing:

1) to compensate for poor window navigation - it's too hard to keep track of and switch between open windows, so we use tabs, instead of trying to fix the operating system (window manager) so we don't have this problem across other applications. It's hard to switch between multiple windows in a word processor or spreadsheet app too, but the workaround only exists in some browsers.

2) opening a new tab is far faster than opening a new window. I can only assume this is because the code to open a new window isn't optimized for speed, while the code for opening a new tab within an existing window is, and since the developers use tabs, this won't change.

That said, I'm using tabs in Mozilla right now, because of these reasons.

I hate to say this, but I won't be surprised if Microsoft gets it right in the next version of Windows. XP is already working on addressing this issue, although from what I've seen so far it's not there yet.

Re:WebCore

[King Babar]

No, that's not right. iTunes shows you a list of MP3's, iPhoto shows you a list of photos, but Safari does not show you a list of web pages.

I didn't realize that people had gotten so close to the answer I suggested. Safari does not show you a list of web pages (it could). It does show you a list of windows in the windows menu; if that list were also a collection in collections view, voila; keyboard accessible, fully visible (no constraint on menu width either!) display of open windows; the moral equivalent of tabs (only better) just one keycombo away. (Sorry to harp on this again...)

For bookmarks, Safari's bookmark view works. Would that same view work for browser instances? Absolutely not.

Ah, but bookmark view also works for history, for collections of URLs generally. Unlike the original poster, I only care about it also showing open windows, too. The only change I can see needing to be made is to make it clear that the viewer is looking at a list of windows rather than (in essence) a list of URLs.

If mixing a list of windows in bothers you, then an actually better idea might be to bind option-cmd-w to show a view of the current window list alone. Since we already have bookmark view, window view hardly seems a stretch. Then it's just like the list contents of the window menu, only keyboard navigable, able to show full-length titles (and URLs for that matter), better able to handle long lists of windows, non-dock cluttering, and just good, clean, fun. :-)

Re:WebCore

[nehril]

the desire for tabs will disappear completely once a person learns how to use the Window menu, Minimize and the dock, and command-`.

while the arguments against tabbed browsing are elegant and theoretical, you have to come down to the user level reality at some point. I've told lots of my (non-technical) friends about mozilla and how cool it is, and they really didn't give a rats ass. I told them about tabs, and they still didn't. internet explorer was good enough. Even some of my technical friends didn't really care enough to switch.

then I SHOWED them tabs in action. google search: open in new tab, superfast navigation, don't lose your place. Everyone who saw this was floored. Then I showed them how to bookmark a set of related tabs.

After the tabset bookmark demo, they ALL switched to mozilla. 100% adoption rate among very non technical people based on a 60 second demo. (I have a "daily" bookmark that in one click simultaneously opens slashdot, arstechnica, google, nytimes.com and news.google.com.) No long mouse travel times to the dock or the "windows" menu. no need to remember keyboard command combos. no need open a menu to find a hidden list of windows.

Since I work as a computer consultant, I've had a chance to run this demo on about 80-90 people in the past year. Apple would do well to listen to real users and not to textbooks.

You can continue to cite all the theory about the equivalency of quad-clicking through window menus, but in my experience tabs are a "killer app." I know I won't use safari if it doesnt have tabs, and I'm not alone. there's something right about tabs!

OmniWeb's adoption problem...

[bill_mcgonigle]

...has always been that they're behind the curve on standards. I don't blame them, they have a small team and do a good job with that they can render; it just doensn't render the most modern stuff.

Their application is second-to-none, but I use Mozilla because I need to render the latest stuff (oh, and tabs). I would send in my registration fee if their renderer was current.

This is a great move for them. If the guys who wrote their renderer are reading - you did a great job, it's just that customers ask the impossible of a small team.

Omniweb not as far along?

[WatertonMan]

The implication of this quote is that the underlying renderer Omniweb 5.0 was supposed to have wasn't as far along as many thought. Presumably they are keeping their high level interface stuff. But to completely switch rendering engines at this stage is a fairly significant change.

Re:Omniweb not as far along?

[EccentricAnomaly]

Omniweb uses Objective-C and Cocoa. A main benefit of Objective-C is supposed to be that the code is modular and switching out objects is easy.

From my limited experience with Objective-C, I don't think switching renedring engines will be that big a deal for Omniweb.

Re:Omniweb not as far along?

[nevershower]

Ya, but a pretty easy one to make. Once you have your GUI, you can make a browser quickly with WebCore. Then all you need is features that complement the "browsing experience". This is what Apple has done with Safari, and what Omni will do with OW. Hopefully this will allow more feature innovation since the rendering engine is taken care of.

This is really interesting since there are a hell of a lot of browsers out there for OS X (IE, Chimera, Mozilla, OmniWeb, Netscape, iCab, Opera, and now Safari). This may lead to even more browsers, so you should be able to find one that fits your style.

Re:Errr...

[Phexro]

"OmniGroup is excited because Apple has given the OS X developer community a solid, fast, and very (though not yet perfectly) compliant HTML component."

Well, uh, KHTML is already under the GPL. Shouldn't these guys be thanking the KDE Project for writing the code in the first place?

In fact, since Apple based WebCore/JavaScriptCore off GPL code, they must make the code public. I'm not so sure that they would have released the code back to the community if it was under a BSD-style license.

Don't get me wrong - I think it's great when corporations enhance existing FOSS projects. I just think that the gratitude is misplaced in this instance.

Re:Errr...

[Twirlip of the Mists]

Well, uh, KHTML is already under the GPL. Shouldn't these guys be thanking the KDE Project for writing the code in the first place?

Sure, appreciation all around. But from OmniGroup's perspective, what Apple did was more significant. (Not more important, not better, just literally more significant.) Apple removed the dependency on Qt and created an Objective C API for KHTML. That was a ton of work, not to be underestimated. Without it, KHTML wouldn't have been of any use to any Mac developer.

In fact, since Apple based WebCore/JavaScriptCore off GPL code...

Let's be precise. KHTML and KJS (and by extension WebCore and JavaScriptCore) are LGPL, not GPL. This is an important distinction. If either of those components had been GPL only, Apple would not have been able to use them.

steve's love for omniweb

[krel]

I'm surprised Apple didn't hire the omniweb people, they may not be the fastest, but they can do some darn fine cocoa web browsing. I understand that back in NeXT, steve used and liked omniweb.

Re:steve's love for omniweb

[Anonymous Coward]

When all you've got is cat food, it tastes pretty good. There were two browsers on NeXTStep for all of about five minutes.

Re:steve's love for omniweb

[rjrjr]

It is very difficult to image the Omnis as willing to be bought or hired.

Re:steve's love for omniweb

[jcr]

OmniWeb
NetSurfer
SpiderWoman
And of course, the original www.app.

The web started on NeXTSTEP, and we had plenty of choices for browsers.

-jcr

WebCore and WebKit (Re:Immediate development?)

[Anonymous Coward]

The really cool thing about this is the potential that Apple would make the WebKit framework (currently inside Safari.app) a public framework. That framework includes cocoa classes that look like they can be embedded anywhere in a cocoa app (e.g., WebView exists and is a subclass of NSView that looks like it supports subviews and a data source model for getting its HTML). The API looks like it has been designed with great care and is cleanly concept-compatible with the rest of Cocoa. Very nice! (I know this from using the class-dump utility that dumps out Objc headers from binary Objc code).

This would be a big improvement over the current HTML rendering capabilities in cocoa. I can think of about 10 apps I would write with that right now!

(For now, I'm sticking with Chimera.)

WebCore and JavaScript Core aren't about drawing

[Anonymous Coward]

A lot of posters here think WebCore and JavaScriptCore are about drawing to the screen. They aren't. There is another framework called WebKit that contains the Cocoa classes that bridge into the Core frameworks.

This stuff from Omni seems pretty silly to me. If these web frameworks are made public (they are private, without header files and inside the Safari app right now), then all they need to do for OmniWeb 5 is to drop a WebView into their existing UI and toss their rendering engine. That should wipe out about 90% of their code. Why bother at that point?

I'm a little biased against OmniWeb. As an old-time NeXT developer, one of my happiest moments was the point when I became able to use a NeXT-derived system and NOT browse with OmniWeb! Their UI design is great and broke some new ground in terms of bookmark management and search (Sherlock was a complete rip-off of their search panel that is no longer part of the app. Kind of ironic how Sherlock has been a clone of another app in two generations now!). Unfortunately, their HTML rendering was never very satisfying (4 was better though).

Re:Errr...

[Anonymous Coward]

If Apple releases a new version of Safari, with an improved WebCore and JavaScriptCore, will a future OmniWeb 5 (based on WC/JSC) inherit this improvement? Or will OmniWeb need to release there own copy of the new WC/JSC?

In other news ...

[pvera]

Microsoft is about to unveil Internet Explorer 7 for Mac OS X, which will be based on the Apple-enhanced KHTML engine.

Re:Errr...

[Twirlip of the Mists]

Depends.

WebCore.framework and JavaScriptCore.framework work like DSO's or DLL's, if that means anything to you. The difference is that a framework can be bundled inside an application or available externally. If you look in /System/Library/Frameworks, you'll find stuff like AppKit.framework, which every application on your computer (Cocoa, anyway) links to at run time. If Apple puts WebCore and JavaScriptCore (and maybe WebKit) in the operating system-- in other words, puts them in /System/Library/Frameworks in a future version of OS X-- then programs like OmniWeb will be able to link to them at run time. Future improvements to those frameworks will apply to those programs automatically.

But as of right now, WebCore and the others aren't part of the OS. They're bundled right inside Safari. If Apple decides to leave them out of the OS, then OmniGroup will still be able to use them, but they'll have to distribute the frameworks inside of the OmniWeb package. In that case, updates to the frameworks would have to go from Apple to OmniGroup to the user.

I imagine Apple is going to make WebCore et al. part of the operating system real soon. It's just too darned useful; even apps like Project Builder need to be able to parse HTML to display documentation and whatnot. The million-dollar question is whether they're going to do the same thing with WebKit. If so, expect to see about a hundred special-purpose Cocoa web browsers for OS X in the first week after release. It'll be so easy to write your own web browser, what with PB and IB and all, that you'll hardly be able to avoid it! ;-)

no choice

[srelan]

We (old NeXT users) didn't really have a choice. Omniweb was pretty much it. And Mosaic under X11 on NeXTStep (not pretty)....

Re:Errr...

[PotPieMan]

The code is LGPL, not GPL. Plus, they are thanking the KDE project:

(fwd) Greetings from the Safari team at Apple Computer
Fwd: Our changes to KHTML and KJS

Re:Errr...

[jericho4.0]

'It'll be so easy to write your own web browser, what with PB and IB and all, that you'll hardly be able to avoid it! '

After I got over how fast Safari was, I relized that the browser itself is nothing. It probably took longer to write the bookmark importing scripts than anything else. I expect frequent updates.

Re:Errr...

[tuxzone]

Gratitude is never misplaced,

said the wise man.

Many people just find them useful

[metalhed77]

I don't have any high minded philosophical ideals when i praise MDI browsing. I just don't see a need to have multiple browsing windows open. It clutters up the taskbar, mostly, makes reading multiple sites simultaneously harder and I find it, personally, to be cleaner simply.

Consider this, to use the MDI mozilla browser with two pages, when I want to change pages, I only have to click one button on the top. When I use an SDI UI I have to click on some other browser window, which reorders the entire stack of windows i allready have out, and have to relocate my mouse on the new window. PLUS if I want to find the old window, I have to find it burried next to a myriad of other apps. MDI is the future. OC i dunno how this translates to mac, i'm using windows

Re:Many people just find them useful

[Twirlip of the Mists]

It clutters up the taskbar, mostly

The what? ;-) We are talking about Macs here, after all.

When I use an SDI UI I have to click on some other browser window, which reorders the entire stack of windows i allready have out, and have to relocate my mouse on the new window.

Nope. All you have to do is go to the menu bar, pull down the Window menu, and choose the title of the window you're looking for. Same amount of work as involved in using a tab.

PLUS if I want to find the old window, I have to find it burried next to a myriad of other apps.

Nope. The window you were just using is always the window right below the one you're currently using. Cool how that works, huh?

MDI is the future.

Heh. No, dude, MDI is the way-off distant past. Microsoft introduced it with the original Windows, and it's hung around with ever-decreasing persistence ever since. Even Microsoft has largely abandoned it now; Word has been an SDI application since at least Office 2000, and possibly before that.

MDI is a throwback, a regression. A mutation, if you will. ;-)

Re:Get this:

[BitGeek]

He is being silly, Mac users make up closer to %45 of the consumer market.

IF you were meant his number was too high-- well, its worth noting that it is a far more supported number than the claim that they only make up %5 of the market-- an out right lie, and fabrication that has no basis in reality.

The Nazis found that if you repeat the same lie often enough, people start believing it-- so we have the same thing here-- Windows is "%95 of the market", taxes are not theft, social security has a "trust fund", the government helps the poor (poverty is government's greatest triumph) etc.

And all these statements sound absurd to people who believe what they are told to believe-- even when these beliefs contradict objective reality. And they do.

Its amazing how well that works, though.

Re:Errr...

[BitGeek]

I'm not so sure that they would have released the code back to the community if it was under a BSD-style license.


Well, that's a silly concern since they realeased their commercial operating system even though it wasn't under the BSD license- it was owned by them free and clear.

How soon people forget that Apple is the first, and so far, only company to open source its commercial operating system.

And not only does it help scores of open source projects around the world (as well as make use of them- after all that is the POINT of open source) but it does work to make it so that people who want to can run completely Open software on their platform more easily without paying apple any money,-- by supporting X11, and other stuff they don't ahve to that goes against their bread and butter OS sales.

Gee, I wonder why. They sure are GREEDY those bastards!

And yet all you Open source self-proclaimed advocates still hate them. could it be that you really don't care bout open source so much as you love linux? (Not bashing you, Phexro, just the broader group that irrationally hates apple becuase it "doesnt support open source.")

Re:Get this:

[mr_burns]

He was saying that laptops were 30% of the share of mac sales. Not that macs were 30% of computer industry sales.

Those numbers are totally legit, you just didn't read the words around them.

Safari is Konqueror/KHTML!!!!

[oever]

Apple is giving away something they haven't started themselves. The Safari engine is a forked KHTML engine from the KDE project. Read Apple's e-mail about this.

I'm very pleased to see that the KHTML rendering engine is being used on Apple and even better, that Apple is behaving as a good citizen and is publishing their modifications of the KHTML GPL-ed code. The modifications seem to be pretty good. Here's to hoping that KDE and Apple will start working on a common codebase for the engine.

Misinformation Warning

[Llywelyn]

I doubt this is intentional, but if you go under preferences for OmniWeb, under compatability, there is a nice little spot where you can adjust what browser it tells the website it is.

I have been able to conduct online banking through that means without any problems whatsoever.

New windows in the background

[capmilk]

OmniWeb actually has a Preferences setting that automatically sends new windows behind the current one. Very nice, indeed. :)

Tabs Tabs Tabs

[gnugnugnu]

Couldn't agree with you more.
Tabs are overrated.

Re:Get this:

[jamesmrankinjr]

He is being silly, Mac users make up closer to %45 of the consumer market.

Do you have a reference for this?

Best,
-jimbo

Re:Errr...

[lexarius]

I Am Not A Cocoa Developer, but don't cocoa apps check the systemwide frameworks for newer versions before linking into their bundled versions? At least, that was the idea of it (or so I heard). So if Apple released an update that put WebCore and the rest into the system frameworks, OmniWeb with included framework bundles would automatically start using it and then they can just stop bundling it in newer versions. Right? Maybe? No? Or perhaps if I were to move these frameworks into my system frameworks folder manually...?

Re:Errr...

[Twirlip of the Mists]

No, I don't believe so. The point of bundling a framework with your application is to prevent a change in a system framework from breaking your app. In Windows-land this is sometimes called "DLL hell." So your app will always use a bundled framework, if available.