Who framed the web: Frames and usability

Back in the nineties, using frames to split a browser window into several independent parts was very popular. Much due to the increased awareness of usability and accessibility over the last few years, frames usage is not quite as widespread as it used to be. However, frames can still be found on many sites, especially those that haven’t had a major overhaul in a while.

If you spend most of your online time reading blogs, you hardly ever come across any sites that use frames. That’s good, considering that blogs are typically very rich on information. I don’t miss frames at all, and it’s been years since I last used frames myself, but recently I asked myself what the problems with frames are, and if there are occasions where the pros of frames outweigh the cons.

The problems with frames

The drawbacks are obvious to some, while others think frames have some things going for them. The problems I see with frames are mostly related to usability and accessibility. You may have heard of the problems before, but let me reiterate:

  • Frames break the unified model of the web. One of the basic principles of the web is that every page is represented by a unique URL – the page is the atomic unit of information. Frames break this fundamental principle.
  • Frames cause problems for search engine robots. While it is possible to provide workarounds that allow search engine robots to crawl a frame based website, those workarounds are still workarounds. There will also be problems for visitors that come to a framed site from a search engine. Those visitors are likely to land on documents that are incomplete when viewed outside of the context of the frameset they belong to. Crucial elements like navigational links may be missing, for example.

    Some frame-dependant websites try to get around these problems by using the file robots.txt to tell search engines not to index sub pages. On other sites, JavaScript is used to prevent visitors from viewing any document outside of its parent frameset. Both of these methods – preventing deep-linking and disallowing search engines from indexing a site – may work, if the goal is to get fewer visitors.

  • Frames make URLs stop working. If a visitor wants to send someone the URL of a document within a frame based site, they can’t just copy the address from the browser’s navigation or location field. That’s the frameset’s URL, not that of the current document. It’s possible to extract the URL to a document within a frameset, but many people don’t know how to do that. Even if you do manage to find the document’s URL, it leads to an incomplete page, creating the same problem as when a search engine indexes a frame based site.
  • Frames break bookmarking. Most web browsers can’t bookmark a page inside a frame based website. When you open the bookmark, you will go to the default state of the frameset, which is usually the website’s homepage, and most probably not the page you intended to bookmark.
  • Frames make printing more difficult. Many visitors will have problems when trying to print documents. It’s common for browsers to require that you activate a frame by clicking in it (or tabbing to it) before you can print it.
  • Frames hurt accessibility. While the leading screen readers can handle frames, a frame based site is more complex, and thus more difficult to navigate in a non-graphical browser. For this reason, accessibility guidelines advise against using frames.
  • Frames increase technical complexity. Besides causing trouble for the site’s visitors, developers using frames make things harder on themselves. A frame based website is technically more complex, and more time consuming to develop and maintain than a site that doesn’t use frames. For example, something as simple as keeping the navigation system in sync with what’s being displayed in the main content area can get really complicated.


What about iframes (inline frames) then? Well, usability-wise they really aren’t all that different from normal frames. They suffer from most of the problems mentioned for normal frames. Iframes are probably slightly less complex to maintain than normal frames since they don’t need special frameset files.

There are also reports of potential accessibility problems with iframes, where under some circumstances an iframe grabs focus when its content has finished loading. This can be very confusing for someone using a screen reader, and can cause unexpected results when printing. I haven’t seen this occur in my (limited) testing, but it’s something to keep an eye on.

CSS based frame imitations

CSS can be used to imitate the look of frames. This will avoid most of the problems with real frames. However, it can also cause usability problems that are different from those caused by frames.

One CSS technique used for this displays a header and a footer in fixed positions, letting the whole browser window scroll when necessary. The main content area will then slide behind the header and footer. I’m not aware of this technique causing any serious problems.

However, when an inline frame is imitated by using the CSS declaration overflow: auto, printing the full contents of the “frame” becomes impossible in the browsers I have tested – only the visible part is printed. This can be circumvented by providing a print style sheet, but it’s something that you should be aware of.

Another problem with the overflow: auto technique is that in many browsers, scroll-wheel mice cannot be used to scroll the contents of a “CSS frame”. While this is not a huge problem for most, and probably something that should be fixed by browser vendors (Apple and the Mozilla Foundation come to mind), it is very annoying.

Frame imitations cause fewer problems than real frames, but you should be aware that there are issues. Those issues can be avoided by providing alternative style sheets, both for viewing and printing.

Frames and frame imitations aren’t always bad

You can probably tell by now that I am no fan of frames, iframes, or frame imitations. They do have their uses though. Frames can be useful for intranets as well as for applications like web based e-mail and content management systems, where most of the problems noted here are of little or no concern. On a public website, however, they cause too many problems and should be avoided.

Visual arguments for using frames

But if frames are so bad, why do they even exist? Well, because they were invented back in the nineties, when every new browser feature had to be used just because it was possible. The question should probably be “Why does anyone use frames on public, information based websites?”.

In my experience, most of the web professionals that like to use frames are more visual design oriented than structure oriented. I don’t know if that assumption is true, or if it’s just coincidence. What I do know is that I’ve had plenty of clashes over frames with visually oriented designers wanting to confine a site’s content to a tiny scrollable area. Their reason for wanting to do this is usually a desire to keep the site’s navigation and/or “branding” always visible. Usability, accessibility, and search engine visibility are not on their radar.

I don’t mean that as a knock against all visual designers – I’m just bringing it up as an example of the attitude I’ve run into over and over, especially when working with designers coming from a print background.


To me there is no doubt that frames should be avoided for public websites. They just cause too many problems. For web based applications and intranets however, many of the problems mentioned are of less concern, so there are cases where frames can be useful. Think carefully before using frames though – ask yourself whether you really need them or if there is a better solution available.

As for CSS based frame imitations, my feeling is that those techniques can be useful, but should be used with care. Be aware of the printing problems they can cause, and don’t squeeze your content into a tiny, scrollable area just because you can. Remember that for most sites, people don’t visit just to admire the pretty design – they come looking for content.

Posted on November 18, 2004 in Accessibility, Search Engine Optimisation, Usability


  1. As you said, intranet sites suffer less by using frames. During all my web development experience I created only one site that relied on frames, and guess, it was for a corporate intranet CMS. I faced all the problems you outlined and I hope I never need to work with frames anymore.

    If you take Bloglines as an example, you’ll see a good use of frames.

  2. Great post (as usual)!

    a frame based site is more complex, and thus more difficult to navigate in a non-graphical browser.

    This depends. Sometimes a frames based site can actually help a sreen reader user. Many frames-based sites put the navigation menu in a separate frame. This makes it easy for screen reader users to focus on the main content and switch to the navigation frame in a consistent way.

    Of course a site should have skip-to links to help out with finding the menu, but frames actually makes that easy for most screen reader users.

    But, considering the other factors avoiding frames would be the best approach.

    A worst-case example is the Swedish National Board of Fisheries. The site use a lot of javascript to open links in different frames. It is difficult to spider for most search engines as well as impossible for screen reader users to understand.

    Maybe they could become a customer for NetRelations?

  3. One of the few times I have had to use frames is when one of our clients was being provided content by a third party vendor, and the content was just on a plain page with no branding applied. We used frames to “wrap” the content in the site template.

    Of course, in a perfect world, that vendor would have just provided and XML feed for the content that we could have aggregated into the site.

  4. I entirely agree with most of this, but I do have a couple of queries.

    1) Surely search engine spidering is only an issue if you display a page in a frame, and don’t link to that page elsewhere?

    If your site design is such that every page has a link to it anyway (e.g. you’re just using frames to keep navigation and pages separate), then wouldn’t search engines be fine without any workaround?

    2) “A frame based website is technically more complex, and more time consuming to develop and maintain than a site that doesnt use frames.”

    What, always? What if a developer wants to, e.g., separate navigation from page content, to make updating easier, and can’t use/doesn’t want to learn server-side scripting? Here, I think frames would reduce complexity.

    Tiny points though, cos everything else you mention makes the case pretty well that frames aren’t worth bothering with. I’ve had to write JavaScript to make iframes expand to the height of their content, and the whole time I was trying to work out why the content wasn’t just put together with the page on the server.

  5. Small Paul, hopefully I can shed some light on those two problems:

    1) The complexity has to do with the how the frame set links to everything. Search engines do not follow links defined within the frameset tag, only links within the noframes tag. Therefore, you have to ensure that any links that appear in your navigation frame appear on this page in order for search engines to actually make it anywhere past the home page. That being said, once your site is indexed, you still have the other issues with users coming from a search engine being placed into a frameless site that likely has no navigation or branding (because they’re in different frames).

    2) What adds to complexity is setting frame targets correctly. It’s a common mistake where a target is missed on a link and suddenly you’ve got framesets within framesets within framesets.

    If you don’t wish to use server-side languages, then you should look into tools like Dreamweaver that can still build statically driven sites while easing the maintenance of common elements through it’s template system.

  6. November 18, 2004 by Roger Johansson (Author comment)

    Small Paul:

    1. Yes, spidering can be taken care of. The bigger problem is how to make people coming from search engines get the complete frameset with the page they found loaded.

    2. In the case you mention, frames may reduce complexity for the developer. Until they decide they want to highlight the current section in the navigation ;)

  7. What, always? What if a developer wants to, e.g., separate navigation from page content, to make updating easier, and can’t use/doesn’t want to learn server-side scripting? Here, I think frames would reduce complexity.

    Alas, this only replaces complexity of the one kind with complexity of another. And, besides, solving his own problems in this way developer creates problems for site visitors.

  8. I don’t see how frames can reduce complexity for either the developer or the user compared to server-side includes. It seems much easier to insert a single include line in a document than to worry about targeting links and maintaining separate html documents for each frame. Granted, my only include experience is with PHP, but from what I have read about other methods, it doesn’t seem much more complex, if at all.

    To learn frames, you must learn framesets, maintain separate html pages, and worry about targeting.

    To learn includes, you must learn how to include a page in your html, and that’s it.

    Am I missing something?

  9. I would add to consider using Iframes to capsulate embed/object objects such as flash banners, as described in Joe Clark’s excellent “Accessibility for the web”. This actually benefits accessibility as iframes enable content editors and designers to add alternative content in case the content within the iframe can’t be accessed, as well as the title / longdesc attributes to describe iframe content , which is unavailable with uncapsuled object/embed content.

    Which is the only use case that stuck with me :)

  10. I experimented with CSS pseudo-frames a while ago. Works pretty well, but I did come across some browser problems - with IE obviously.

    Some of the feedback I received suggested that my pseudo-frames could be made a little more “cross-browser” if I’d done things a little differently.

    The great thing about the pseudo-frames is that they degrade perfectly.

    See: Fixed Header: Emulating the Frameset

  11. November 18, 2004 by Roger Johansson (Author comment)

    Sander: I recently read about potential problems with banners in iframes. If the content of the iframe finishes loading after the main document, in some browsers the iframe grabs the focus, which can be unexpected for visitors.

    I don’t know exactly under which circumstances this can happen, and I haven’t seen it happen myself. Anyone know more about this?

  12. I think you’ve forgotten one of the most important use of frames. That is that frames can reduce the amount of data sent to the user since the navigation does not get sent back to the user on each page load. I ran into this problem when I web enabled our e-mail system quite a few years ago. Many users at that time had thousands of folders yet did not have broadband at home, they used modems. For that matter our branches used 64k frame relay links shared by all the users in the branch. By using frames for folder navigation, the folders only had to be loaded once. For the “sighted” user navigation was a snap. Accessibility was not thought about by most web developers in those days.

    This is one of the problems I have with the current crop of developers. They have access to high speed Internet connections and don’t think about users with low speed modem connections. Because of this you get things like “post-back” in .NET. and 200k+ home pages. I took a class in .NET development and when I saw it used post-backs for validation, I asked the instructor how this performed for modem users. He smiled, and told me that for his DSL users performance was pretty good, however for modems users, performance “tanked”.

    I no longer use frames because of web standards, it just makes sense to have the whole page as a unit. However in the past for users who had slow speed connections separating large navigational elements from the content made a lot of sense.

  13. November 18, 2004 by Roger Johansson (Author comment)

    Tanny: While the argument about frames reducing the amount of data sent is true, I’d say the savings you can make are all but negligible. If you use semantic markup and move all presentation to external CSS, you’re down to savings of a few hundred bytes to a couple of kilobytes.

    I fully agree that the viewstate thing .Net uses is insane, though.

  14. Roger: I’m not saying that frames should be used now. I am saying that eight years ago I didn’t use semantic markup but created a collapsing/expanding tree using tables and some javascript. It was a big deal back then when we didn’t know any better and still had to support IE 4 to send that huge amount of data to the user. We had one user that had over three thousand folders with up to seven levels of nesting! Sending that much data over a modem line for every page was just not reasonable. Framed pages helped us solve that problem but also introduced a whole lot more problems. Like how do you synchronize the framed folder list with the contents of the folder? What happens when a user chooses a folder then clicks the back button? That sort of thing. Also what happens when you have to include a 60k java applet with the page so the chat feature will work. Putting that in a frame and only loading it once at the time made a whole lot of sense. Yes using semantic markup makes things a whole lot smaller. As soon as I realized that I could get rid of all those font tags and use CSS instead I started to, then when I read Zeldman’s DWS I started to use CSS for layout.

    I’m still not sure how I would deal with 60k to 100k of a folder list on every page load though, what would your approach be?

  15. November 19, 2004 by Roger Johansson (Author comment)

    Tanny: I did the same thing back in the nineties, so I’ve been there ;-)

    My approach to the case you describe would be to take a close look at the implementation to see if it could be done in some other way. If that’s impossible, and you have to have a 60 - 100 KB navigation tree, and modem users are a large part of the audience, well, that’s when you have to start making sacrifices. Either let modem users wait, rework the design, or use frames and introduce usability problems for everyone.

  16. I tried to port SKForum over to a non-frames system, but it included nasty hacks to reload some data (used to be just a http refresh), and the scrolling never behaved like it should’ve. In the end I threw away roughly a weeks work because after all that high tech fiddling I ended up with something vastly inferior to simple frames. Pity really because I truly hate them :/

  17. Whoops, looks like I came across as if I thought frames were a good idea :) I really don’t (despite my own guilty past…) - at least, I’ve no particular love for them. I have no problem with server side scripting, and I’m currently very much enjoying learning PHP.

    Jonathan: many thanks, the spidering thing is now clarified nicely, much appreciated. JavaScript can handle the frameless site thingy, if one was so inclined, though I’m sure you know that. Wonky targets would indeed lead to general nastiness.

    Roger: indeed, I was thinking from the point of view of a developer, probably kinda inexperienced, trying to remove specific complexities from her site management (didn’t really make that clear). Once this developer is advanced enough to be highlighting current pages, she’s clearly ready to learn how to do websites properly :)

    Rimantas: that it does. But the developer in question may find one kind less onerous than another. You’re quite right that this may, however, present irritating obstacles to some/most/all of her users.

    Will: in terms of code to write, you’re spot on. But if said developer doesn’t have any server-side scripting languages working on her machine, or doesn’t have web hosting that provides it, then the work required to get to a stage where she can use includes may be more than the developer wants to do. (Hope she bites the bullet and gets there soon though.)

    By the way, see www.quirksmode.org for a pretty fully-featured frames-based site, and justification for using it. I only put this here as a matter of interest :)

  18. December 19, 2004 by Pontus

    I belive in Frames because issues of navigation within a site is of extreme importance in some sites whereas issues such as being visible to the outside by searchengines, bookmarking…. is of less importance.

  19. February 14, 2005 by Saint Jude

    Perpective, perspective,…

    • Frames break the unified model of the web

    How about the web as a collection of nodes. ‘Single document’ pages link to other documents. Frameset documents just go that step further by including and displaying them. Very unifying !

    • Frames cause problems for search engine robots.

    Search engines can do all that, but they can’t crawl framesets. Why not ? This sounds like a problem with SE’s (and a simple one at that) - not framesets.

    • Frames break bookmarking.

    True of course, although actual browser bookmarks can be more sophisticated.

    Frames are a pain granted. But, as a user, I love them in any site that is intended as a reference. Not being much into fluff myself, that’s nearly all sites.

    The Java API, ZVON.org - great.
    (MSDN partially excepted, since it insists on automatic re-framing)

    I prefer the smooth visual transition, and I do notice the delay involved when a menu and its state are being doled out via a server script.

    Not that I’d know, but the opportunity to have the navigation area readily available, and fully delineated must have some accessibility benefits (?)

    Of course,everybody does not have access to, or suitable training for server scripting either…

  20. February 15, 2005 by Roger Johansson (Author comment)

    Saint Jude: Search engines can crawl framesets, but visitors coming to a framed site from a search engine result will load “orphaned” documents, without the surrounding frameset. How would a search engine store the frameset’s state and list it in its search results?

    I agree that in some cases frames can be useful. Many web applications and certain references qualify for that. However, for most sites frames are a pain for the user and the developer.

  21. April 28, 2005 by Cringle

    and don’t squeeze your content into a tiny, scrollable area just because you can. Remember that for most sites, people don’t visit just to admire the pretty design – they come looking for content

    I happened to take notice to this and my first thought was “what tiny scrollable area”. The window size of the person’s browser doesn’t change, so what if I took up 75px at the top to keep the branding visible. If one wants repeat visitors, this is another way to keep your name in their head. And, if they bookmark the site, that’s not the equivalent. If they aren’t at the browser where they bookmarked the site, then they may be screwed, because they didn’t see the site name quite long enough (or tracked it down from web site to web site until they hit your site).

  22. April 28, 2005 by Roger Johansson (Author comment)

    Cringle: What I was referring to are the sites that use frames to create a 400 by 300 (or thereabouts) pixel box for their site’s content, regardless of the visitor’s window size.

    Setting 75 px aside for “branding” is not what I mean by that, although repeat visitors, IMHO, are created by offering something your visitors want, not from keeping your branding visible.

  23. I have a slight problem, forgive me if I have overlooked this in a previous article. One of the advantages of frames is if you have big graphics on banners and on nav bars this will only load once and you only have to re write the main window section, once you have a target reference. Which means not taking up bandwidth from servers for images loading time and time again and also the ease of writing and not picking your way through code. My question is, is there any way to target a frame and just change the content in this window rather than loading the whole page again?

  24. May 6, 2005 by Jack Norton

    I understand all these problems with frames (only too well), but … I am designing a site with a three level hierarchical menu structure. The items from the first menu are read from the database and displayed (and must remain displayed). The items on the second menu are read from the db based on the first level item selected - there may be many of them, and they must remain displayed. The third level items are read from the db based on the second level item selected. So a user may at any time select from the list of second level items to display the list of third level items. If I don’t use frames I would have to do many database reads to refresh the list of first and second level items each time a new third level item was selected. So it is saving database reads I am interested in - not trafic. I think this justifies the use of frames - yes?

  25. May 6, 2005 by Roger Johansson (Author comment)

    Those images would be cached by the browser and only downloaded once, so not using frames would not increase loading time. There are ways of loading content into part of a page, but doing so may cause accessibility problems.

    I don’t think that justifies the use of frames. That sounds pretty much like the way most navigation systems work, and I have never encountered a case where that generates too much CPU usage from database reads.

  26. May 6, 2005 by Jack Norton

    Thanks for the quick response Roger. My worry is not so much cpu as the increased dbms load - having to refresh everything on a typical user selection could result in say 100 db reads, whereas if I use frames it may be just 2. On these figures, i.e. a 50 fold increase on dbms load, when there are potentialy hundreds of concurrent users, a frames approach, with all its problems, seems a strong contender. However, I am also very interested in the ‘usability’ issues that people normally level against frames. Even as I type this I note that I am scrolling first this web page within the browser window - of which the tools on the top remain static (useful) and the info at the bottom (status bar) is always there. And, I am scrolling within this text box. The bottom line is that when we design for client-server type systems and don’t have the limitations of the web model, we wouldn’t dream of producing big single up and down pages that go away and come back with every tiny thing we do on the screen. If we get back to basics and design purely for the user experience we wouldn’t design single web pages. So if there is a technology that can work around the web model limitations isn’t that a move in the right direction? I realise that it is probably heresy to talk of the web model ‘limitations’ among your audience - but I sometimes think that people are now mesmerised by it and are blind to other approaches. In particular, I really think that when technically aware people think that the ‘up-and-down’ web page is good from a usability perspective they are not being totally objective - they have persuaded themselves based on the underlying technical issues associated with the web model - including search, bookmarking, printing, etc.

  27. May 6, 2005 by Roger Johansson (Author comment)

    Database management is not my thing, so I can’t give you any advice there. However, a quick look around at high traffic sites shows that most are not using frames, so I’d say that it is a problem that can be overcome.

    As for the user experience, well, if you want a more “application” style design, you can, and you don’t have to use frames. It’s possible to achieve that with CSS, which will avoid most (but not all) of the usability problems with frames. My CSS Frames demo shows the concept.

  28. id like to know which problems with frames also exist with AJAX implementation … seems to me the problems about bookmark, copy location, search engine visibility, printing(?) can be found here, too. whereas AJAX is normally considered a big usability improvement.


    Frames work miracles in Yahoo groups where the “public web site” is not my own, so I have only 2000 char of HTML to work with and no server or client script is allowed.

    In that instance, an iframe enables me to refer to a whole external site, sidestepping both the 2000 char and other limitations that Yahoo imposes. For an example, click on my name above while it lasts.

  30. JR Fisher: that’s funny, I mean users really do know what a link is. What’s wrong with just putting a link to some other web space, where you have more control, more space, your own document body, no ads, should I keep going?

    And if you really like the info there but can’t deal with the limitations of yahoo then put a big image up, with the link.

  31. November 9, 2005 by Boril Yonchev

    How can I block moving of Sidebar div ? Only content div can to move

  32. November 9, 2005 by Roger Johansson (Author comment)

    Boril: Use position:fixed.

  33. I think frames have 2 important types of disadvantage:

    • They make it difficult for users to bookmark specific content pages, because the URL remains the same.
    • They may have accessibility disavantages. But this partly depends on the browser / user agent.

    They also offer significant advantages to users:

    • Independently-scrollable navigation and content. It’s no accident that most email clients and many other apps use a framed layout - it’s very usable.
    • Faster loading because large menus are cached. PS if you use server-side scripting, make sure this does not disable the browser’s cache.

    I disagee with most of the other objections.

    In particular “Frames break the unified model of the web” is meaningless to most users. Non-developers don’t have a theory of the web, and are already used to framed layouts (email, other windowed apps, many games). Users I’ve asked like independently-scrollable navigation and content.

    Iframes get the advantages of frames with almost none of the disadvantages - provided the content is in the main page and the menu is in the I frame (other structures are nonsensical).

    The worst disadvantage of putting the menu in an Iframe is that the menu is re-initialised every time the user goes to a new page, so the user may lose his / her place in the menu. But this can be overcome:

    • Javascript which sets a “you are here” marker in the menu and / or scrolls it to make the current page’s menu entry visible. This makes Iframes better than Divs for large menus because the W3C DOM does not include scripted scrolling of anything other than window objects (e.g. Iframes).
    • Per-session cookies to save the state of the menu from page to page. This also requires JS.
    • Breadcrumb trails in content pages.

    Most modern browsers print the content of pages containing Iframed menus OK. As for printing the menu:

    • Should you print it at all?
    • If so, should it have the same position and prominence as in the screen version of the page?
    • And should you print the whole menu or just the main section headings? If you print the main section headings you give the user a reminder about the site’s range of content without wasting a lot of paper and ink.

    So most sites need separate @media print rules, regardless of whether they use Iframes.

  34. February 24, 2006 by Michael Holberton

    Dear Roger and others,

    I’ve been programming Database Applications since 1993 but I’m pretty new to Web Programming. I am trying to determine the best path to take regarding the development of an Application that will be accessed by Web Browsers for a client of mine in Australia.

    My client’s requirement is for people to be able to access a Task Driven Application, rather than a Content-Based WebSite, from anywhere by using the Internet and Browsers. The application has been developed with VS .Net 2003. The people who were previously working on it have not done a very good job, I think, and it’s not User Friendly for such an application. They basically have one aspx Page and “poke” Web Controls into a Table on the fly using VB .Net.

    My intial thoughts have been that such an Application would be more easily facilitated and maintained with the use of Frames loaded with aspx pages.

    There is a lot of discussion that CSS is the way to go with Web Development but the reading I have done, so far, suggests that different hacks are required for different browsers as well as general other fudging required to emulate the use of Frames.

    The data is mostly of a hierachical structure. I think it would be more User Friendly if people do not have to scroll up and down a page. Once they have accessed a top level of the data they should be able to point and click to access (drill down to) related sub-levels of the data within a Frame or Nested Frames on the same page as the top level data in a similar fashion as you would use Nested Forms in an Access Front-End.

    Is it possible to emulate Nested Frames with CSS?

    If so, would it entail a lot more work using CSS to achieve such an interface especially as I envisage this as the best way to present such an application?

    Is it possible to use CSS with .Net and .aspx files in this way or am I on the right track with my proposal of loading frames with .aspx pages?

    Would such an application be better suited to using Citrix Presentation Manager to push an Access Front-End to a User via the Internet?

    Thanks, Michael Holberton

    Hospedaje Macha Wasi & Sacred Valley Mountain Bike Tours
    Cusco Database Development and Cycling Services

  35. one of the best advantages of a frame set is that I can use anchor links in the navigation to anchors in the content in the content frame to jump from place to place … how do I emulate that if I wish in a css based layout?

  36. March 16, 2006 by Steve

    I regularly develop web pages that use a flash-based audioplayer loaded in a frame that gets refreshed and starts playing when the user click a link in the “main frame”.

    I’ve not been able to find any alternative method to frames that would allow the user to continue navigating the web site and still listening to their previous selection as with all CSS methods i’ve tried the “second” frame would always be refreshed, thus stopping the playback.

    Is it possible to have a CSS “frame” that wouldn’t be refreshed along with the rest of the page?

  37. I don’t like framesets either, but if one knows really what s/he is doing, it has its benefits. Philip Chalmer’s points are very valid indeed, and Quirksmode is one prime example of good use of frames. That is the to say, frames can sometimes be good too.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.