frames html

HTML Frames – they still have some life in them

I'm not sure if I'll get slack for this post. Frames, at one time, carried the popularity that AJAX does today. But they've since been frowned upon because they:

  • Make it difficult for search engines to index the site
  • Cause difficulty with bookmarking
  • Confuse back/forward browser navigation

Because of these usability and indexing issues, the <frame> and <frameset> elements have been completely remove from the HTML 5 specification. In my opinion though, I think they could have stuck around. They're extremely useful for certain types of interfaces, such as control panels, extranets and website administration backends.

So useful, in fact, that I recently adopted them in a recent administrative tool I created. Thankfully, browsers still support them.

Being able to wrap sections of your application in a frame brings a few advantages:

  • Load it and forget it. You can put things like site headers, left-side navigation and footers inside frames. Then, you can create a "content" frame, which will be the only frame that actually performs HTTP requests to get new information from the server. This means that your web server only needs to serve the actual content portion of a page throughout an entire visitor session. The header, footer and navigation remain fixed and neither need to be requested from the server or rendered by the browser after the first page load.

    You may be thinking, "this is easily accomplished with AJAX nowadays". No argument, but turning of JavaScript, or having an error in the JavaScript cripple a JS-dependent site is also just as easily accomplished!
     

  • It provides a really simple way to make content static.  Nearly every piece of desktop software on the market today uses a frame-like system of keeping certain areas of the application static, while other areas will scroll as needed. The browser I'm using right now has a fixed title bar, address bar and bookmarks bar. It would be extremely awkward if these areas were not fixed in place.

    This is exactly what <frame> and <frameset> accomplished for us. Why remove such a common user interface element from the spec!
     

  • They're more structured than iframes. Can you imagine littering iframes throughout your HTML doc to attempt to replicate the <frame> and <frameset> elements? Framesets provided us with a handy layout option, one that was very easily understood, i.e.
<frameset rows="64,*" border="0" frameborder="no" framespacing="0">
    <frame src="/top-navigation.cfm" border="0" frameborder="no" scrolling="no">
    <frameset cols="256,*">
        <frame name="leftnav" src="/left-navigation.cfm">
        <frame name="content" src="/page1.cfm">
    </frameset>
</frameset>

The above code makes a good deal of sense. Frames are a natural way to lay out a web document, and provide great speed and usability enhancements as well.

Why follow me on Twitter?

  • I tweet about new technologies, services or libraries I find interesting
  • Yeah, sometimes I'll post a pet-peeve or rant about something trivial
  • If I discover something that made my web development life easier, I share it
  • I'll shout out any handy tip that I think might be useful to other devs


Tagged , .

Updated: 2013-09-29

Phil LaNasa follow us in feedly