These are handy uses I had not considered, Craig. Thanks for those tips. It's important to be careful what you pass in HTML code, when money is involved though. I read last year or so in 2600, that a shopping cart that did something similar was getting hacked all the time by people who simply saved the page, changed the product price to what they wanted, and then completed the transaction.
I HATE frames, but there is one case in which they seem to be the lesser evil for design, IMO:
3. When you have many scrolling columns of things on the page and you need to make the column headings visible all the time. Sometimes you have to put the whole table or whatever on one page for some reason, and the trick of repeating the headings in a frame by themselves is very handy.
I've seen this done for persistent navigation on really long pages as well, and it works very nicely at the bottom of the window in a horizontal strip if handled correctly. On a non-application page, it is bad practice to make the fixed frame the one that owns the bookmarkable URL. Also, many database-driven catalog sites have the same page title for every page ( "catalog item" is all too common) which also defeats the purpose of bookmarking or using history lists. So pages need both unique main URLs and unique title tags.
Preventing deep linking on a public informational website (or an e-commerce site's product page) is a silly and annoying practice that I hope is fading into obscurity. I never link to sites or email references to sites if I have to give driving directions to the resource in question. (Instead, I use Icab http://www.icab.de/ to pop the frame into a new window, and link to that URL.) Unfortunately most people who make framed websites don't include at least rudimentary navigation links in content frames so that people who visit a deframed page can get to the home page from there. Sometimes you can't even tell which website owns a content frame once it's isolated from the frameset.
At 12:22 PM -0700 5/4/04, Craig Oshima wrote:
> >1. You need to keep substantial or complex data persistent across >multiple pages. You could embed this data in the URL (ugly) or store it >in a cookie (not guaranteed to be enabled), but a hidden frame is >another option. It has more flexibility, fewer limitations, and avoids >having to pass the data back and forth repeatedly across the wire. If >you have server-side functionality (ASP, PHP, JSP, etc.), then this is a >better way to > >2. You need to communicate back to the server, but for whatever reason, >you don't want to reload the entire page. Amazon did this some time >back with their "Earn a nickel" thing where you answered questions about >their site and get nickels that get applied as discounts to your >purchases. By using a hidden frame, you can submit form posts (and >examine the response) without having the whole page reload. >