Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Upgrades Apple

Safari Beta Updated 174

Posted by pudge from the let-us-go-surfing-now dept.
LenE writes "Safari has been updated to Beta 6, and is available via Software Update. New in this version is XML support, more speed, and many bug fixes. The download is 2.4 MB and doesn't require a restart." From the notes: "The Safari Update 2-12-03 improves the compatibility with popular web sites based on Safari user feedback, further improves the performance of loading web pages and Flash content, adds support for XML, increases standards conformance and delivers improved application stability. The update also enables access to web sites that offer self-signed security certificates."
This discussion has been archived. No new comments can be posted.

Safari Beta Updated More

Safari Beta Updated

Comments Filter:
  • I've been browsing for about an hour now using the new version without a crash! Wahoo!!!!

  • Many bugs were fixed, and CSS improved *a lot* (Score:5, Informative)

    by King Babar ( 19862 ) on Wednesday February 12, 2003 @04:52PM (#5290910) Homepage
    Yes, you can run the w3c.org CSS1 tests now. But more importantly from my perspective (:-)) is that Eric Meyer's css / edge stuff [meyerweb.com] now almost completely works. The only abject failure there is the second "ragged float" demo, [meyerweb.com] and even that one is pretty close.

    As far as styling XML goes, your XML apparently does have to have the DOCTYPE stuff set up correctly. This means you get no joy with the stuff on the w3c Styling XML [w3.org] site; safari won't display the xml files there at all.

    Oh yeah: it's a bit faster...not that you're likely to notice.

  • also seems to launch faster, at least on my ibook 600. Working good so far!

  • File size decreases (Score:5, Interesting)

    by wcbrown ( 184278 ) on Wednesday February 12, 2003 @04:55PM (#5290928) Homepage
    As noted by Bill Bumgartner [weblogs.com], file size of the package has gone from 7.2MB to 6.9MB.

    I haven't seen file size increase with upgrades. The Safari developers should be proud.
  • It seems to do exactly what it claims to, though I'm finding the last beta handles my page refreshes better. This version seems to just keep reloading them over and over, which means it isn't loading at all.

    I would hold off on this download.

  • Tabbed Browsing (Score:5, Insightful)

    by Cokelee ( 585232 ) on Wednesday February 12, 2003 @05:15PM (#5291083)

    I'm not sure if anyone realizes this, but Apple typically does NOT like Multiple Document Interfaces -- essentially what tabbed browsing is. For this reason I do NOT see them adopting tabs, ever. Even if every other KHTML browser has them. I may be wrong, but I believe using tabs would be a design flaw to Apple.

    I'm still reading through their HIG to see if they warn against it.


    • tabs good (Score:5, Interesting)

      by djupedal ( 584558 ) on Wednesday February 12, 2003 @05:44PM (#5291285)
      The HIG, as I recall, doesn't mention tabs as evil. While Apple may not deploy tabs on the system level, we can look to Excel for tabbed worksheets as a long standing example, and to Airport Admin for a more recent usage. For a more public example, you only need to visit Apple.com [apple.com]

      Safari will have tabs...sooner or later, and Cupertino will not slide into the Pacific as a result.

      • Re:tabs good (Score:5, Insightful)

        by Cokelee ( 585232 ) on Wednesday February 12, 2003 @05:54PM (#5291361)
        The HIG, as I recall, doesn't mention tabs as evil. While Apple may not deploy tabs on the system level, we can look to Excel for tabbed worksheets as a long standing example, and to Airport Admin for a more recent usage. For a more public example, you only need to visit Apple.com

        Safari will have tabs...sooner or later, and Cupertino will not slide into the Pacific as a result.

        Excel was NOT created by Apple, it was created by MICROSOFT.

        The Airport Admin software CANNOT be document-oriented it contains NO documents

        Apple's website is a SINGLE document. Every tab is not a NEW window it is a LINK to another page. Web Design and UI's are not equal.

        Also, I wasn't being a sensationalist. I didn't call tabs evil, and I didn't say Apple's beloved home at Infinite Loop would slide into the Pacific Ocean. I simply said they don't implement MDIs, and ya know what, they don't.

      • The HIG, as I recall, doesn't mention tabs as evil.

        There's tabs and then there's tabs. Tabs as a UI control are okay; there's a section of the HIG describing how to use them. But tabbed browsing is simply one implementation of a multiple-document interface (MDI). The HIG does specifically call out MDI as being evil.

        See, the Mac got where it is today by establishing a fairly simple desktop metaphor and sticking with it. The metaphor says one document, one window. Windows on the screen are like pieces of paper on the desktop.

        we can look to Excel for tabbed worksheets as a long standing example

        A long-standing bad example, you mean. I think you'd be hard-pressed to find anybody who would be willing to go on record as saying that tabbed worksheets are a good UI.

        and to Airport Admin for a more recent usage [also the Apple web site]

        I don't mean to be rude, but if we're going to have a constructive conversation about tabbed browsing you're going to have to wrap your head around the fact that tabs qua tabs and tabs as an MDI implementation are two completely different things.

        Safari will have tabs...sooner or later

        Safari will not have tabs. Not as the default, not as an option for power users, not at all. If somebody else wants to construct a browser that implements some kind of MDI interface, they're free to do so. Hell, they can even use WebKit to do it, once it's released. But Apple will not release a browser that so flagrantly violates the standards that got them where they are today.

        (Sorry, I guess that got a little strident. I'm watching The West Wing as I write this, and Sorkin always pushes my prose over toward the purple end of the spectrum.)
        • Why, To'tM, you know I listen when you speak. My examples were just to show that tabs aren't new, and the various implementations (good or bad) only show we're bound to see them continue. I happen to depend on them, now, for browsing. Otherwise, I can take or leave them.

          I'll give in, just cause it's you. I'd like to know whence your authority on Safari comes, tho, but only to satisfy my own curiousity. I don't doubt your feedback, thanks.

          I'm now wondering how long it will be before we see HTML that opens a new tab... [target=_tab_new]
          • My examples were just to show that tabs aren't new, and the various implementations (good or bad) only show we're bound to see them continue.

            That's specious reasoning at best. One example of a bad user interface-- two if you count Mozilla/Opera/Chimera tab-based MDI-- does not a trend make.

            If anything, the overall trend is away from MDI toward SDI. Microsoft Word for Windows used to be an MDI application; as of Office 2000, it wasn't. The same is true of lots of Windows applications. MDI doesn't work, so it's being abandoned.

            There are no real examples of MDI on the Mac, of course, because the Mac HIG always proscribed MDI in favor of SDI.

            I'd like to know whence your authority on Safari comes, tho, but only to satisfy my own curiousity.

            A three-way combination of inside info, extensive knowledge of Apple's UI guidelines over the years, and a level of confidence bordering on hubris.

            I'm now wondering how long it will be before we see HTML that opens a new tab

            Oh, sure, let's go right back to the bad old days of browser-specific HTML. "I'm sorry, but you must use a browser with a shitty multiple-document interface implementation in order to view this site." That'd be great... ;-)
            • hubris...ah yes.

              As for bad html. I thought we agreed that since IE allows sloppy html, we were going to blame the singer, not the song. joke...
            • My examples were just to show that tabs aren't new, and the various implementations (good or bad) only show we're bound to see them continue.
              That's specious reasoning at best. One example of a bad user interface-- two if you count Mozilla/Opera/Chimera tab-based MDI-- does not a trend make.

              I think a better way to argue about this is to decide what problem it is that needs to be solved, figure out to what extent current tabbed browsing solutions do or do not solve them, and then do the *right* thing. :-)

              Personally (and surprisingly to me) I find that I miss tabs less in Safari than I would have expected. It turns out that *one* problem that tabs solve in Mozilla is the problem that raising and repainting browser windows takes just enough time to be irritating. Safari gets around this by being much faster.

              That said, speed alone does not solve every problem. A general problem with any application that includes multiple windows is simply managing all of the windows, making it clear which is which, and allowing you to navigate between them conveniently. Here, the biggest problems with just using multiple windows are that when you have a non-trivial number open, they overlap so you can't immediately see all of the relevant content to raise the one you want (or even all of the titlebars). Further, while there are "nice" ways to cycle through multiple windows (cmd-~, best read here as "I command you to twiddle" :-)), you can get to scenes like that in Toy Story II where our porcine hero must go "around the horn" on the remote to locate the right channel (here window).

              Now, there is a method to do this already in the interface, namely the list of open windows in the pull-down "Window" menu. This solution has its own set of problems. The "Window" menu now exposes a much wider pull-down menu surface, but it will never be wide enough to show the full title. (This is a major problem with the Mozilla tabbed browsing interface, made worse by the fact that the list is presented horizontally rather than vertically.) Another problem with the Window menu solution is that, especially for fast typists, pull-down menus are too slow.

              Ironically, Apple sort of/kind of recognized some of these issues more completely when it came to the (surprisingly similar) issue of bookmarks. So I now have a dozen or so bookmarks on my "bookmark bar", and they are arranged horizontally and scroll off the screen. Not great. But then there's "Bookmark View" (option-cmd-B) which provides me with the obvious solution: a scrollable list of essentially full-width bookmark entries! And even some keyboard navigation! But then it craps out: you can use the arrow keys to highlight a bookmark entry, but then there is no way to go to that bookmark without using a mouse. The obvious answer would be "hit return", but somebody at Apple has apparently assumed that what I would usually want to do in that case is *edit* the bookmark name rather than *use* the bookmark itself. Bleah. Keyboard navigation for "bookmark view" really needs to be fixed. Then it will be heaven on earth.

              And when "Bookmark Heaven" has been achieved, all that Apple has to do is give us "Windowlist Heaven" arranged along exactly the same principles. Hit (say) option-cmd-W and go to "Open Window View". Navigate to your open window, and you're there. This simultaneously solves the visibility problem, the "title space" problem, and the "fast navigation" problem.

              The only problem it does not solve that Tabs could solve is the "Hierarchical Organization" problem. When I am running BLAST searches on ncbi.nlm.nih.gov, ideally I want all of that stuff separated from my more "usual" browsing. With tabs, I just have a "Blast Window" filled with tabs related to that stuff, and a "Regular window" filled with tabs related to the usual stuff. The window list solution alone does not solve this one. What could help is what amounts to making the list of windows hierarchical (I guess like bookmark folders).

              In short, we need a (potentially hierarchical) "Window list" view that allows robust keyboard navigation. Everybody can benefit, nobody needs to use, and the interface is within UI guidelines and common sense.

              I'm now wondering how long it will be before we see HTML that opens a new tab
              Oh, sure, let's go right back to the bad old days of browser-specific HTML. "I'm sorry, but you must use a browser with a shitty multiple-document interface implementation in order to view this site." That'd be great... ;-)

              Ooh--I know; we could call it "frames". Wait a minute; that's taken. Uh...let's call it "framelets" and make it twice as confusing as frames, and provide a <noframelets> tag that allows us to handle people with pathetically out-of-date browsers. :-) (Man, that *was* a pretty scary idea...)

        • > But tabbed browsing is simply one implementation
          > of a multiple-document interface (MDI). The HIG
          > does specifically call out MDI as being evil.
          > See, the Mac got where it is today by
          > establishing a fairly simple desktop metaphor
          > and sticking with it.

          Where the Mac is today? You mean with ~3% market share for sales? ;-)

          When you say that tabbed browsing is a form of MDI, and MDI is evil, you run the risk of sounding pedantic. People don't buy computers or software because it matches some Ivory Tower's idea of what is a good interface. They buy because it fits their needs the best.

          I have been a Mac user for a while, and when I first heard about tabs in Chimera, I had no idea why anyone would want them. However, once I tried them, I learned that tabs work best for me. I like to load different sites into different browser windows, and then load sub pages for a particular site in tabs in the same window. It keeps things neater and allows me to quickly go back to my place without having to sit through a painful page reload. To me, three windows with three tabs is more organized that nine windows spanning three different web sites.

          Maybe tabs aren't the only solution for this, but I'd like to see something that effectively replaces the functionality and still meets with the HIG-nazis' idea of what is good design.

          Perhaps the case is in general MDI is not a good idea, but there are specific cases where it is a good idea -- like when you're browsing the web.

          Safari's product managers need to realize that there are a significant number of people who will never switch to Safari full time until it has two things:

          1. Tabbed browsing (or something that substitutes the functionality)
          2. Support for the Mac OS keychain
      • AS TotM noted, tabs are just one way to represent a Multiple Document Interface. My personal preference for getting to this is not with tabs in the Mozilla / Excel vein, but drawers in the Mail.app / Calculator.app vein. With a hierarchical display of sections like open windows, bookmarks. history pages, etc, and (ultra wish list) with page thumbnails as icons), you could get a much richer interface than the simple row of buttons that you get in these hip modern browsers. If Safari ever moves to a MDI style (or at least, the option for such a style), my hope is that drawers end up being the way to get there.
    • [i][b]Apple typically does NOT like Multiple Document Interfaces[/b][/i] Although it has something unnervingly like the MDI with Project Builder. Project Builder has all sorts of odd interface features, such as close buttons that are "flat" representing a MDI document. It also misses many important UI features for a compiler/debugger, although that's a different issue. Anyway my point is that "panes" in Project Builder are an obvious exception to this.

      I do wish Apple would improve Project Builder. Why the most essential application for the system - its development environment - is as weak as it is remains a mystery to me.

      • I don't know what your standard for comparison is, but Project Builder is an excellent IDE in my opinion. Yes, the tabbed-window, paned-window, multi-document editor thing is hard to use and confusing, but you can change the way PB handles its windows in the preferences.
        • I actually don't mind the MDI in Project Builder. My main complaints with Project Builder are limited debugging features. For instance try having persistant watch variables between trips to the debugger. There is no "search" pane but instead you have a modal window.

          Compare this to Visual Studio where you have tabbed persistent watch/expression panes. You have a nice toolbar with a search field that can search either the current document or all files in your document.

          There really is no comparison between Visual Studio and Project Builder. I suppose a lot of this depends upon what kind of code you are using. Still I honestly wonder how people can stand tracking bugs down with Project Builder. I wanted to go full time with OSX for my development but ended up sticking with XP just because of this.

          Codewarrior is better in some ways - its debugger is better for instance. But it still doesn't hold a candle to Visual Studio. It is also amazingly slow unless you can use precompiled headers extensively.

          I'd made numerous suggestions to Apple and was excited when the last version of Project Builder came out. Sadly the actual debugging IDE had few changes. Perhaps some don't mind. Undoubtedly these folks don't mind printfs or using gdb. But it just isn't worth the hassle.

          This is a rant slightly off topic though. So my apologies for conflating the MDI issue with Project Builder's other flaws. My original point was just that Project Builder does use MDI so the original person's point was demonstrably wrong. You are right though that Apple has made it so many aspects of the MDI are optional.

          • Let me preface this by saying that I have not done any Obj-C debugging in years.

            The GUI debugger for PB is just a layer over gdb. It is unfortunate that it does the worst of both worlds: keeps you from having to learn gdb while hiding it's amazingly powerful features. As is the case with many GUI-less tools, gdb may be one of the most powerful debuggers there are - but the learning curve is damn steep.

            Yes, it is possible to save breakpoints - you just have to edit your .gdbinit file. Does that suck? Yup, but that's how it is.

            I hope that they do get around to integrating more of the powerful features of gdb with the GUI, but historically, this has been low priority. All the 'old time coders' know how to use the gdb commands and are used to it. It's really too bad.

    • Re:Tabbed Browsing (Score:3, Informative)

      by code shady ( 637051 )
      While I haven't seen any explicit warnings against using tabs with the brushed metal interface (but then, I haven't read all of the HIG), i also believe that apple will NOT implement tabbed browsing in safari.

      The textured windows where "designed specifically for use by--and is therefore best suited to--applications that provide an interface for a digital peripheral, such as a camera, or an interface for managing data shared with digital peripherals, such as the Address Book application" or "... appropriate for applications that strive to re-create a familiar physical device". I think its the second one that is the most important here, but both uses play a role.

      Take a look at iTunes. Its got one main window, an that window is the main focus of the app. In this case, the window is supposed to mimic the features and feel of, say, a CD player or the equivilant. Same with the calculator. Each of these one main windows contains all the controls you need, in one place where they can be easily accessed. In this context, the brushed window is approriate, because you only need one simple window for your interface.

      Now, if this is the case, then why is it used in the Address book app or Safari? Well, its pretty simple. While you are not trying to mimic an actual peripheral, you ARE focusing soley on one particular type of data. Be it addresses, or a web page, each single window has a specific single focus.

      Basically, each metallic window needs only focus on one thing. That one thing could be a web page, an address card, or a playlist. Putting tabs in safari would break that metaphor, which is something that apple would most likely not do.
      • > Basically, each metallic window needs only focus
        > on one thing.

        I think this is correct. Additionally I think the metallic interface is used when the application isn't document-centric. So Word, Excel, and PowerPoint are document-centric and should use the regular pin stripes. Dantz Retrospect and Virex are not document-centric, and should therefore use the metallic appearance.

        The only problem I have is I like the pin stripe look better than the metallic interface. So I'd hate to see too many applications using the metallic look.
    • reading through their HIG to see if they warn against it.

      I found information in Chapter 5 Section 14 [apple.com] (Windows With Changeable Panes), which leads to the exactly relevant Chapter 7 Section 13 [apple.com] (Tab Controls):

      " The tab control provides a convenient way to present information in a multipage format. Tabs can display centered horizontally across the top or bottom edge, or centered vertically along the left or right side. "
      • Also note that use of the Brushed Metal look for Safari is explicitly discouraged in Chapter 5 Section 4 [apple.com] (Textured Windows):
        " This window style has been designed specifically for use by--and is therefore best suited to--applications that provide an interface for a digital peripheral, such as a camera, or an interface for managing data shared with digital peripherals, such as the Address Book application. This appearance may also be appropriate for applications that strive to re-create a familiar physical device--the Calculator application, for example.
        Avoid using the textured window appearance in applications or utilities that are unrelated to digital peripherals or to the data associated with these devices. "
        From these examples (not to mention QuickTime 5 Movie Player and many many others) we can see how much Steve Jobs cares about Apple's guidelines. Dogfood? What's that?

  • Tabs, Maybe. (Score:3, Informative)

    by Cokelee ( 585232 ) on Wednesday February 12, 2003 @05:21PM (#5291125)

    Some applications are not document-based. Such applications typically still have at least one main window, which can use the standard Aqua document window appearance and features.

    Apple HIG [apple.com]

    • Re:Tabs, Maybe. (Score:2, Interesting)

      by NaugaHunter ( 639364 )
      It isn't spelled out directly there, but from previous times I worked on MacOS apps the guideline summaries have pretty much said "One document, one window". It is consistent with their original desktop theme - each window was a document and sort of appeared as a sheet of paper.

      And before someone else points them out, iTunes is more like an appliance - i.e. your CD player. iPhoto is an electronic photo album. iDVD and iMovie are film editors. Essentially the distinction is they don't work with single documents. Safari, however, deals with would could be called active newspapers or magazines. If you want to read a different article, it's in a different magazine, and either replaces your current document or is another document altogether.

      I'm not trying to over-defend their choices. I just wanted to point out they are fairly consistent. Sometimes the distinctions are vague (e.g. what would Mail be?), but in the case of Safari I thinking they are going to stick with the document line of thought, and in this case it makes sense to me.
    • > Apple HIG

      What did you call me?! :)

  • Shortcuts (Score:5, Informative)

    by slenver ( 644088 ) on Wednesday February 12, 2003 @05:21PM (#5291130)
    Apple+arrows now work for back and forward pages..... I just hate having to reach for the mouse when browsing 'with one hand'.....

  • whoops...banking gone for me (Score:3, Informative)

    by djupedal ( 584558 ) on Wednesday February 12, 2003 @05:22PM (#5291134)
    My online banking worked via Safari until this new version.

    For online access to secure sessions within wellsfargo.com, you must use an approved operating system and browser.

    Time to enlighten WFB's tech dept. once again. I don't feel like forcing a spoof.
    • When I upgraded to beta60 my online banking also turned off. I was able to update the .plist manually on this machine and everything went back to normal. - Just send me your info (bank name, account number, etc...oh dont forget SS#) and I can fix it for you!
    • Change the user agent to IE, it will work fine.
    • Use one of the various available utilities or tricks to enable the Debug menu-- I think you can do it with defaults, but I forget exactly how; google it-- and you can change your browser ID string. Wells Fargo's site works just fine if you pretend to be running IE 5 for Mac, for example.
      • As I said before, I'm not anxious enough to do any spoofing right now. I'll wait for it to get out of beta, and if it is still an issue, and if still WF hasn't come on board (I used to work with the network division, so if I do anything, it will be to prod the team to recognize Safari), etc. and...if I have time I'll trik it. Seems for now it may come and go and I've got other goblins to chase...like how to get my Linux box to do Firewire networking :)
    • I've had problems with Safari since a few days after it was released when I tried to access Wells Fargo. For some reason they see Safari as a "secuity risk" but right now I'm logged into WF online through Phoenix 0.5

      Saying NO BETA SOFTWARE is just silly. Just makes me mad when I have to either use Chimera (which is still beta itself) or enable the debug menu and tell the server i'm on MSIE6.0 WinXP =[

  • Gel (Score:3, Informative)

    by Graymalkin ( 13732 ) on Wednesday February 12, 2003 @05:43PM (#5291276)
    What the hell is up with Safari and UBB? I can't seem to log onto many UBB powered sites using Safari, are there any special tricks to get this to work? I was hoping with this release I might be able to not use OW or IE to post to UBB boards but I guess I'll just have to wait a bit longer. This is pretty much the only real downside I've personally come across with Safari, everything else I've wanted to do it has worked fine and fast. Is there a actuallyWorkWithUBB flag in the plist I need to set or something?

    I've tried everything available through Safari's interface including enabling popup windows, allowing cookies from everyone, and allowing every form of script and plug-in to run. So far I've had big fat zero luck. And yes I've submitted bug reports, including the page's source and any pertinent details of my particular setup.
    • I am an admin at a UBB, and am able to post with Safari. I am unable to logout though with the previous version. :( Had to delete the UBB cookies to logout.

      I don't whats up with Safari and UBB, but maybe this new version will fix it.

      *downloading*..

      Sweet! Ok, I can log in, logout, and post with the new beta.

      Click the logout link in UBB, then delete your cookies from that site. You should be able to log in and out as you please then.

  • I turned off software update (Score:5, Funny)

    by skinfitz ( 564041 ) on Wednesday February 12, 2003 @06:09PM (#5291483) Journal
    Who needs it when /. announces all Apple updates?

    Incidentally the apple /. gfx appear to be broken in safari now.

  • Tabbed Windows solution (Score:5, Interesting)

    by Anonymous Coward on Wednesday February 12, 2003 @06:26PM (#5291601)
    Here you can see screenshot mock-ups of my idea for tabs:

    http://home.quicknet.nl/mw/prive/dennis.scp/s/safa ri [quicknet.nl]

    The idea is NOT to add tabs inside a window. But to place a new window at the exact same place as your previous window and let any obscured windows pop up a tab.

    So instead of indenting that new window to the lower right to reveal a clickable border as used today, I say let the windows behind the current window pop up a tab to show their name and icon. The windows stay independent and the screen has less clutter than with today's jumpy stacking system. Power-users can cycle the windows in a tab-like fashion using the [option] key.

    • Exellent work, Mr Anonymous Coward. Certainly good enough for me. I'm sticking your url in a safari bug report right now.
    • Fine suggestion and very nice page, too. Let us hope that Apple sees the light: tabs are, well, insanely great.
    • Nice work. Must say, I've always been an advocate not for tabs, but for tray items instead. You know, like the sidebar that Mail uses? That would be muchly Apple and muchly tabby!
      • The GUI control you are thinking about is called a "drawer" by Apple.

        For an example of how Safari might use a drawer, check out Apple's Preview application. If you open up multiple images in Preview at the same time, you get the first image displayed with the other images shown as thumbnails in a drawer.

        In Preview's preferences a user can decide whether the thumbnails should show just the image, just the name of the file, or an image/name combination. A theoretical Safari implementation could have similar preferences, i.e. show URL/page name, show preview image of page (like you'd get by minimizing the page to the dock), or both.

        Other OS X web browsers such as Chimera and OmniWeb use drawers for bookmark management, but as Safari has a different way of doing that, a drawer could be useful for window management.
    • The idea is NOT to add tabs inside a window. But to place a new window at the exact same place as your previous window and let any obscured windows pop up a tab.

      I appreciate the effort and thought you have put into this idea, but I see at least two problems with it:

      1. Windows are identified by their title bar text which can be very long; horizontal tabs always face a challenge with this.
      2. I don't really see how you can easily deal with (say) 20 open windows effectively with this idea. Again, I think the insight I have on tabs is that you're primarily trying to gain the functionality of the "window list" given in the Window menu while solving its issues and allowing keyboard navigation.
      Power-users can cycle the windows in a tab-like fashion using the [option] key.

      I am not sure how this is any improvement over cycling through windows using cmd-~. Am I missing something?

  • Rendering engine changes in detail (Score:5, Informative)

    by ollie_ob ( 580756 ) on Wednesday February 12, 2003 @06:27PM (#5291609) Journal
    Mark Pilgrim's excellent blog Dive Into Mark [diveintomark.org] has a very comprehensive list of changes to the Webcore rendering engine. The permanent link is here [diveintomark.org]. I'm impressed with how quickly he's managed to list these changes seeing as it only came out today!

    One change I've noticed is Safari no longer freezes for a minute when loading certain webpages. Another nice change is that stylesheet change on Dave Hyatt's weblog [mozillazine.org] actually works now. Dave is ironically one of the Safari developers, so it's just as well!!!

  • drag & drop and improved <OBJECT> suppor (Score:3, Interesting)

    by tim1724 ( 28482 ) on Wednesday February 12, 2003 @07:18PM (#5291896) Homepage Journal

    You can now drag & drop text from browser windows. (It previously only allowed dragging links and images.) Unfortunately it uses the silly Cocoa-style delay before allowing you to drag text. (When will Apple finally fix text dragging in Cocoa?!)

    It also now supports embedding HTML with the <OBJECT> tag, although it will stop drawing the embedded content if you use the Back/Forward buttons. Also, if you click in the <OBJECT> and scroll it with the keyboard, then clicking on links outside of the <OBJECT> sometimes doesn't work unless you first click outside of the <OBJECT> area and scroll the main page with they keyboard. (weird, but it happens .. check out the W3 CSS1 test suite pages)

  • Still no command-option-w support (Score:3, Interesting)

    by mattkime ( 8466 ) on Wednesday February 12, 2003 @07:24PM (#5291926)
    As any long time mac user knows, command-option-w closes allthe windows in almost ANY mac app made in the past 12 years.

    yet safari does not do this.
    • As any Mac OS X user knows, command-option-w no longer closes all open windows. Option-clicking the close button does, however.

      Try it with TextEdit; that's the canonical Mac OS X document-based application. All other document-based application should behave like TextEdit does.
    • Well, I haven't been able to use command-option-w consistently since I switched to the Dvorak keyboard layout, so I hadn't even noticed that missing feature in Safari. Mac OS X's lack of support for Dvorak is pathetic when it comes to dealing with keyboard shortcuts. Some applications insist on treating all keystrokes as if I had a QWERTY keyboard, some treat the keys differently depending on the circumstances. HotApp, for instance, is a neat little preference pane for making lots of keyboard shortcuts, but it reads Dvorak keys when assigning the shortcuts and QWERTY keys when using them, which is extremely confusing (think about it for a minute or two till your head hurts).

      All this means that, for instance, in the Finder, closing a window is command-, (comma is where w would be in qwerty, I have it set to use qwerty command keys to make certain apps happier), but closing all windows is command-option-w (w being, ironically, where , is in qwerty!).

      If only Apple would support different keyboard layouts at a lower level in the OS, changing the characters before other applications could read them, I wouldn't have all this trouble...
      • Aside from X11, I have never experienced this issue while using the Dvorak layout, and their latest update to that is supposed to correct that. command-w works correctly in finder and all my apps. Dvorak has worked just fine and the keyboard layout facilities of OSX have been a lot more consistant than MS's model. In fact, MS operating systems have the single, most crappy keyboard layout implementation in my experience.

  • Saving RAM: An argument for tabbed browsing (Score:4, Interesting)

    by elliotj ( 519297 ) <slashdot.elliotjohnson@com> on Wednesday February 12, 2003 @07:50PM (#5292090) Homepage
    According to an off-the-cuff test I just performed, tabbed browsing can cut your RAM requirements in half and greatly speed up your system.

    On my Mac I opened Chimera and filled up the window with as many tabs as it would allow (16 in a single window). All windows displayed the Slashdot mainpage. My Slashdot prefs are set to show all stories from all sections.

    I checked the system usage in the Process Viewer app:

    Navigator %CPU 9.00 %Memory 11.20


    I then closed all the windows and did the same thing, this time opening 16 SEPARATE windows. Again with Slashdot's mainpage loaded in each.

    Process Viewer showed:

    Navigator %CPU 9.20 %Memory 22.40


    So, according to this unscientific off-the-cuff test, you cut your RAM requirements in half by using tabs. YMMV.

    I noticed this the other day when I opened over 50 different images in different windows. My Mac almost ground to a halt. I then opened the same images in tabs (in only a few windows ... again Chimera limits you to 16 tabs per window), and my performance was great.

    So, to all those who think tabbed browsing is purely a matter of personal preference, I suggest that there is at least a reasonable performance based argument for it.

    (the productivity arguments are even more compelling IMHO, but I won't get into those)
    • Interesting. I'll often see CPU percentages running between 30 to 50% (on a 700mhz iBook). Which build of Chimera are you using, and do you have its cache enabled?
      • I'm using out-of-the-box Chimera 0.6 Build ID: 2002122004. (By this I mean it's not a nightly, I downloaded the 0.6 binary straight from their website).

        It's running the default config: no special settings on my part, so whatever caching settings that might be I guess.
  • Safari still doesn't allow me to check my issues and change my settings in my NationState [nationstates.net]. Come on, Apple, how am I supposed to keep the people of my country happy when I have to tend to them using an inferior browser?
  • Three sites I regularly visit still don't play well with safari;

    my dating site [fuckedcompany.com]
    my mail reporting site [reportez.com]
    my domian registration site [aitdomains.com]
  • The cookie code generates the incorrect default PATH if the server does not supply a path. The RFC (and w3 spec) states that the path should be the url from the end of the hostname up to (and including) the last / (before a ? if one is present). Safari just grabs the whole url up to the ?.

  • Safari already has SLOW tabs (Score:3, Interesting)

    by localman ( 111171 ) on Thursday February 13, 2003 @09:58AM (#5294284) Homepage
    Well, sort of. There are such a large group of people who don't want anyone in the world to have tabs that you'd think that tabs or anything like them were abhorrent.


    But as far as I can tell any criticism that can be aimed at tabs can also be aimed at Safari's bookmark bar. Across the top of the brower there are a bunch of horizontal text buttons that let me select different documents to view in the same window. Or in other words, tabs.


    The big differences are that the bookmark bar doesn't have the "tab look", it doesn't keep the page in memory, and to add one from a link you have to option-click, select "add bookmark" then click "OK". So they are basically a slow and inconvenient tab system. Although they are persistent across browser sessions, which is kinda cool.


    Yes, I understand that they can't really be used efficiently that way, but that's not the point. The point is that as a UI concept Safari's current bookmark bar and the proposed (and much maligned) tabs are cousins anyways. So anyone spouting that tabs are an inconceivably bad UI design is just reacting to surface characteristics and religion


    Cheers

  • I had some very bizarre and frustrating printing problems that appeared sometime after I installed either safari or the 10.2.3 update. But right after I installed the new safari, they magically disappeared! Cool!

Slashdot Top Deals

"The following is not for the weak of heart or Fundamentalists." -- Dave Barry

Close