Iframes have a checkered history in Web Development because their target property has been used in the past as a vector for security attacks. But improvements in browser security plus vigilance on the part of developers[appropriately locking away web assets] has reduced the the vulnerability of iframes such that Google is now using iframes as their embed code for its You Tube videos[Google’s Chrome browser helps out, if an iframe target is not from the same domain as the originating page – Google asks the browser user to confirm that the external iframe should be loaded]. In short, iframes are being used more often in Web Development, see here for details.
And there are advantages to iframes. Developed web code does not have to be retro-fitted into a website or CMS system. Many iframe pages are like apps or widgets – they are stand alone and do not need to interact or sync with the containing Web page or system. However, if syncing is required then developers have a range of means from clipboard through cookies to local web storage [Google Gears or HTML5’s stumblings toward local storage]. Finally, there are pluses to keeping two web systems separate beyond the lower development costs. The two separate systems can be developed by indiviual teams and the debugging chore of fitting the two systems together is reduced considerably. In fact that is the attraction of using iframes in WordPress which we explore immediately below.
An Example of an Iframe used in WordPress
S5 Slider Script by Eric Meyers[iframe: src=”http://theOpenSourcery.com/slides5/s5-demo.html” width=”100%” height=”300″] This demonstrates the use of an <iframe> within a WordPress page. This use of an iframe has the advantage that the code and its scripting and CSS styling files can be kept outside of WordPress for updating, testing and debugging. This also reduces the amount of code that has to be loaded except when needed when the page or post is loaded. This is important because it can greatly simplify the operation of WordPress and debugging when potentially multiple scripts and stylesheets are operative[Trust me – this can and does happen and becomes very hard to sniff out the problem even with powerful debuggers like Firebug in Firefox or the Chrome Debugger in Chrome etc.].
Problems and Some Workarounds
There is another problem with iframes in WordPress. You cannot add an <iframe> tag in the Visual half of the editor – but you can in the HTML editor. However, if you switch to the Visual editor, the iframe tag will be erased by the Visual editor[really, thanks WP]. There is a plugin, insereIframe, which providea workaround. It uses the WP shortcode syntax and allows all the iframe parameters to be included in the statement except the text for “No iframe support in your browser”. Be sure to place the “[” with no blank next to the “iframe:” or the plugin will not work. With this plugin and its WP shortcode, users will be able to use either the Visual or HTML editor in pages or posts containing iframes with no problems.
Iframes have returned to Web development – they are frequently used in dashboards and portal software. They can make perfect standalone widgets. Iframes can even be used in WordPress as long users do careful testing and design to eliminate conflicts with other widgets and plugins. But occasionally users will have to bite the bullet and incorporate iframe capabilities by acquiring or developing their own equivalent widgets or plugins.