Forum Moderators: phranque
Also what would be the best substitute for it instead of tables or regular frames?
Thanks guys!
I would highly recommend using server-side technology such as SSI, or a scripting language such as PHP or ASP to manage your content, as it will help avoid such problems. If you want to continue with iframes, you can follow isitreal's suggestions in the above thread.
Of course, even without the problems with search engines, iframes have significant accessibility issues (similar to regular frames), which makes them unadvisable in many other circumstances.
Assuming you have correctly coded the iframe to let the spiders into the content, you have to then lift the user back up to the iframe container page. I've experimented with several different methods over the last year to see if I could resolve these issues, but it's extremely complicated.
If you use a javascript solution, you have to check if the content page is in its container, if not, you have to set a cookie with the url of the content page (I tried setting a get query string, but that leads to extremely serious issues in certain circumstances), reload the container, read the cookie, load the correct content page (I currently am doing that with php reading the cookie and writing in the correct content src url in the iframe, with a default option on), then delete the cookie, set another cookie that says this happened.
The last step is for if a user comes to the content page through a search engine, you have to let them use the back button to get back to the search engine or else they get stuck in an endless loop, you also have to use javascript at that point to jump them two steps back on one mouseclick if the search engine cookie is set. This works, but if the user has either javascript or cookies turned off, you're out of luck.
Before giving up on iframes I'm going to see if I can use another technique, all server side, to do the same thing. You can always check to see if the content page referrer is the website or not the website, if it isn't, write the cookie, or possibly do a get query string, lift them up (I think session variables would do the trick here), then lift them back to the container, load the correct page. I haven't tested this method yet to see if there are issues in terms of returning to the search engine page.
While theoretically this seems like it might work, I'm not optimistic that it will.
As near as I can tell, if you do this operation on the content page when the headers are sent but before the page is sent, there may not be any problem in terms of the user being able to return to the search engine from the reloaded container page.
If anything could replace iframe functionity decently I'd give up on this immediately, but the lack of support for overflow:auto, and the huge tweaks and instablity I've gotten using the iframe emulation methods I've found here make that a fairly unattractive option for anything but experimental sites (severe problems with jerky scrolling in IE in some cases).
Hopefully these kinds of problems would convince most people not to use iframes on a commercial site if they need the iframe contents spidered.
The accessibility issues, which are definitely a real issue, can only be resolved as far as I can see by using dynamic building of the pages, where you write in the iframe through scripting for iframe supporting technologies, and otherwise just write in the iframe content, I might use that I think if I can't come up with a better solution this year. A quick view of a framed or iframed page in Opera 7's small screen emulator shows that it doesn't even tell you that there is an iframe, unlike browsers that don't support the tag.
thanks again!
