I’ve got a couple of clients I’m going to be building websites for and I figure I’m behind on what’s still acceptable.
I know iframes were the hot thing ten years ago. Are they still good from a usability and standards standpoint?
I think the best alternatives are either server-side includes or php includes, right? I’m hesitant to use ssi because they require a .shtml suffix which I’ve had trouble with (did I mention that I am not a web expert). I don’t think php does?
GQ Answer: Support for iframes isn’t any worse than it was ten years ago, so from a standards point of view, they’re “still good” if you’re willing to accept that they were good then.
IMHO Answer: They were horrible from a usability standpoint then, they are horrible from a usability standpoint now. They make navigation non-intuitive and design overly complex and bug-prone.
As for the third paragraph, server-side includes (which includes PHP) are a completely different animal. They greatly simplify design and increase consistency across the site, but they don’t have any of the user-interface implications of iframes. If you’re looking for a modern equivalent from the behavioral point of view, study up on CSS. With the help of a bit of Javascript, you can replicate the good parts of a frame-based design with few of the disadvantages.
iFrames, man. Slightly better than normal frames. (I did have a client about five years ago who insisted I use frames. sigh). At very least they were prettier.
Wombat, I’m pretty good with CSS. I’ve never been able to figure out writing Javascript, or anything else that involves actual coding, but I’ve had fairly good luck with finding scripts.
Doing a bit more research, it looks like I’ll be learning enough php to do includes.
Iframes are used more and more now actually because there are so many dynamic content opportunities. For example, YouTube’s embed code is an iframe now instead of a Flash object. Google’s map code is an iframe too. I’m sure Twitter modules are iframes as well.
They’re not bad at all for third-party content framed within your site.
However, they are bad for putting your own site content on your own site. That’s just the wrong way to use them. They are very bad for SEO (just like frames) and they can pose design and usability problems.
You cannot be a Web design professional if you do not know how to use includes in some capacity. Period. Writing out the same code on every page is what you do on Day 1 of your “Hello world!” design. By lunch time of day one you need to learn how to use includes or you need to stop trying to be a Web design professional.
Adding to the Wombat’s advice section: I’m aware of at least three websites run by people I know and trust that ended up with embedded Trojans hosted on the sites, with code slipped in due to having legacy iFrame coding present. If ***that ***doesn’t provide a good reason for avoiding their use, I’m not sure what would.
I completely agree with this. I’ve been using includes on my sites for a long time now. But I’m self-taught in bits and pieces and wanted to make sure I was headed in the right direction. I wouldn’t call myself a web professional, but I get asked to do stuff. shrug
What are you actually trying to do with an iframe that would be better done in php? I’m having trouble following how one is an alternative for the other. Would you use cURL and libcurl?
I’m just guessing here, but when iframes were first introduced, a bunch of developers put their site navigation in a different frame from the actual content. Sometimes other elements that were consistent from page to page (e.g., footers) were in yet another frame.
When someone finds a page on your site through Google instead of coming in from the front page, do you have JavaScript code to recreate the frameset, or do they see that page without the menu?
Does bookmarking pages other than the main page work?
Does the page title in the menu bar of the browser accurately reflect where they are in the site?
Is there a visual indicator in the menu of which section of the site they’re in? Did you have to do that in JavaScript, too?
I haven’t done “real” web coding since the last millennium, so take what I say with a grain of salt.
I would say there’s nothing fundamentally wrong with frames. All of the criticisms launched against them (broken bookmarks, unintuitive navigation, and so on) can be as easily applied against more modern approaches such as AJAX. Although many sites have improved since then, early Web 2.0 sites did in fact have all these problems. Heck, even today try navigating to a place in Google maps and bookmark the page. You won’t get back to the same place unless you bookmark a special link field that they provide.
The only real problem is that frames tend to *encourage *a kind of bad design. If you start with the idea that you have frames, and design your site around using them as much as possible, then you will probably end up with a bad design. However, if you *start *with a good design, then there is nothing (necessarily) wrong with using frames. It is just an implementation detail, and like programming languages (or human languages) it hardly matters in the end which one you use (even if some are better suited to certain tasks than others).
I recently got roped into some intranet web coding due to my past experience, and guess what: I used frames. I needed a bit of external content to show up in a page, and while I could have used JavaScript or PHP or some other method, frames were the simplest approach, and worked perfectly.
The menu is not really important. It’s just there to let people see what’s there if they are not regular visitors.
Any page can be bookmarked separately and I can imagine that people have bookmarked one specific page with information that is updated regularly while the rest of the site is quite unimportant.
The title in the menu bar is taken from the index file, but it’s the same in all pages anyway. And there’s really no need to indicate exactly where in the site you are as there are only a handfull of pages of which one or two are of interest to regular users.
All in all, I just happen to like simplicity and a pure HTML page (with some javascript) works perfectly well for me. There are so many overelaborated web pages with features that are there only because it’s possible to have them.
What kind of site is this? I am having trouble picturing a site where the menu is never used for navigation by regulars, where the bookmarked pages all have the same title, and there’s no need to know where you are in the site.
PHP includes do require a .php extension, and .shtm/.shtml extensions are generally the standard for SSI, but you can check with your webhost to have .html and .htm pages parsed to enable SSI. There are a couple of different methods of going about this.
If your server is an Apache-based server, the easier (but somewhat outdated) version involves adding a couple of lines to your .htaccess file, which is basically a plain text file placed in your top level directory – usually hidden because it has no extension (like .txt). The lines will direct your server so that every .htm or .html page is parsed for SSI. For example, one of my older sites uses:
Options +Includes
AddType text/html .htm
AddType text/html .html
AddOutputFilter INCLUDES .htm
AddOutputFilter INCLUDES .html
The reason this isn’t always recommended is that there’s a slight overhead as a result, since your server has to parse each page whether it contains SSI or not. But if your site is small and you’re not expecting huge traffic, it won’t be noticeable.
If traffic / server overhead are issues, then you or your host can use the XBitHack method, which means editing your .htaccess file and making the pages where you use SSI user-executable via chmod (usually an easy step if you use an FTP program such as CuteFTP or Filezilla). While it’s a bit more work, it does ensure that only those files that are set to be user-executable are parsed.
For a smaller, simpler site, the first method is easier – and is also a nice easy introduction to editing your .htaccess file.
Hopefully this is correct… I’m a bit loopy 'cause I’m posting on Benadryl right now.
