开发者

Legacy iframes, what is a full fledged replacement for them?

开发者 https://www.devze.com 2022-12-13 23:07 出处:网络
A site heavily using a main iframe I inherited a legacy codebase/website, http://ninjawars.net .The iframes were in place before I started coding on the site.

A site heavily using a main iframe

I inherited a legacy codebase/website, http://ninjawars.net . The iframes were in place before I started coding on the site.

I constantly hear about the problems of iframes (security, accessibility, layout issues), and I'm pretty certain that iframes aren't friendly for search engines (a big minus). My personal experience with iframes has mainly seen problems with their load times (heavy http requests, I guess?).

Searching for a replacement for iframes

Unfortunately, no-one who says "get rid of iframes" also gives an effective solution to my situation, generally assuming that a simple include of the content of the frame will make everything rainbows and unicorns (e.g. Converting from iframes). In my case, a static include solution does next to nothing for me.

jQuery load() (dynamically loads content into a div, for example) is a better fit, but doing a conversion to that method will take time, and doesn't benefit accessibility for search engines, or non-javascript-browsing users. jQuery load() fixes the speed issue, but I'm not sure whether it fixes the accessibility issue. Even without javascript, the iframes still work (for manual clicks), though whether the extra support work of keeping the iframes working underneath the javascript is practical, I'm not sure.

Potential Alternatives?

  • jQuery & load()
  • Full rewrite of site to static pages with comm开发者_Go百科on header/footer/sidebar + some minor javascript polling.
  • ??? Something not yet considered by me ???


Iframes are not the spawn of some unnamed demon, as some people would have you believe. They still have a very useful place for web applications.

They definitely are bad for search engine optimization, however! I would never recommend that a "normal" public web site use them unless absolutely necessary, especially if SEO was a big concern.

I would consider jQuery to be a good option for solving the accessibility issue. One of the great things about jQuery is that it is easy to make your site degrade gracefully for those users that don't have javascript - like search engines.

Basically the way I approach a new public web site with jQuery is the following:

  1. Build the site with static navigation. All content blocks that I would normally be getting from some ajax request (in your case, in an iframe), I make accessible in its own page. The "Contact Us" form is a great example - put it in it's own page for non-javascript users, but it'll eventually be loaded with ajax into a modal div for regular users. The static navigation ensures search engines see everything. In your case, replace the iframes with divs that just contain a link to the page that the iframe is currently loading.

  2. Add jQuery. Taking it one page at a time, start replacing all occurrences of static navigation links with the ajax calls to load the content you want.

  3. Refactor the javascript continually until you have minified it into a script that will work across all the navigation on the site.

An example of a simple gracefully degradeable site is the following (taken from a site I worked on):

$(document).ready(function() {

    $("#menu a[href]").each(function() {
        this.href = this.href.replace(/Index/, "Ajax");
    })
    .click(function() {
        $.get(this.href, null, function(data) {
            var $main = $("#main");
            $main.hide();
            $("#main").html(data);
            $main.fadeIn("slow");
        });
        return false;
    });

This script runs in all pages on the site, replacing any occurrence of "/Index/" in the menu navigation target URLs with "/Ajax/", which redirects the URL to resources that return ajax responses, and then adds a click handler that handles adding the content to the page.

Now search engines and non-JS users can follow the static navigation, and JS users get a snappier UI with some effects.


have you considered using jQuery's Ajax capabilities in combination with a history plugin? That way you could preserve the browser's back-button functionality plus ensuring support for bookmarks without having to reload an entire static page while navigating on the website. I don't know if it is search-engine friendly (I like to make myself believe it is, though).


I assume you want to keep your interface basically the same -- left, right, and top sections always stay in the same position, and the center section can scroll down if necessary. If that's true, I'd try the following layout:

  1. Design the page to put the left, right and top sections in their own divs, and the center section in a scrolling div by using "overflow: auto".
  2. Break the left, right and top divs into their own PHP files and include them in every page. So each page would include those files, and then define the unique content in the scrollable div.

Admittedly it's not the most elegant solution (I prefer using a library such as Apache Tiles in Java). But it has worked well for me in the past. A key to making this maintainable is to make each include file start with the <div> tag for that section, and end with the </div> tag for that section. Writing include files that start and end on different levels, or leaving divs open that must be closed in another file, is a cause of major headaches.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号