|
I've Been Framed
It's been my experience over these years to get so many site FAILures blamed on framesets. If a site FAILs and it uses frames, then the checker must be too stupid to figure out frames. Common sense dictates that if framesets are common all over the web, why wouldn't the checker be able to read them? 90% of site FAILures attributed or assumed to be a result of the frameset, in actuality, are something else. So why the bad rap for frames?
I think WebRing brings it on themselves to a degree. Their own phrasing on some pages suggests that framed sites are going to be a problem. I offer the following as evidence:
Both of these suggest that the checker is 100% inflexible with frames. However, phrasing it differently just to appease the framed world would intensify confusion with the frameless crowd. That is where this page comes in.
There are really only two instances where frames are troublesome.
- When the frames are created by a JavaScript. This is because the checker cannot look within the JavaScript for the WebRing coding. Any "nesting" of JavaScript codes will FAIL the WebRing code checker.
- When the frames are i-frames. The checker is unable to work with those. Originally it was because i-frames were not widely-compatible with other browsers. It is unknown at this time if the checker could be tweaked to work around i-frames, so for now, there remains a conflict.
Otherwise, frames are not difficult to work with. It's a simple case of registering the URL for the frameset, but installing the WebRing coding on one of the files that comprises the frameset. Such is the case with http://home.dejazzd.com/androb/mlb/. The URL "http://home.dejazzd.com/androb/mlb/" is registered. The code was installed on "http://home.dejazzd.com/androb/mlb/main.html". But since "main.html" is one of the files that comprises the frameset which loads when calling up "http://home.dejazzd.com/androb/mlb" this membership PASSes and the navigation is accessible.
Please note that by installing the coding on the frameset URL will return a PASS test result, but the coding will not create a VISIBLE Navigation Bar. Many RingMasters will notice this and suspend the membership. This is best demonstrated by having you view http://great-phototips.com/ then asking you to access the page source (which is available by clicking the "view" tab on most browsers, the selecting "source" or "page source"). You'll see the SSNB is properly installed, but in the wrong place. However, this site PASSes the checker for two memberships because the checker can see the coding in the source of the registered URL. Unfortunately, the checker cannot reason out that the location of the coding will not result in a visible, accessible Navigation Bar.
I have a few simple rules about using frames with WebRing, which will help keep frames from being troublesome:
- Register the assigned URL for the frameset. I recommend this in all situations, actually. Reserve domains, short URLs, and redirects for search engines, letterheads, business cards, email, and friends. Register the actual URL of any site with WebRing. When the checker must go through any type of redirecting to get to the proper page, there is an increased chance of problems.
- Don't place the coding on the frameset URL. Yes, the system says unequivocably that the code must go on the registered URL. But almost any rule has its exceptions, and this is it. You have no content on that page, so the coding doesn't go there either. Getting a PASS result is really only half the job. There must be a visible, usable NavBar present, too.
- Use the main content page to display the coding. Whatever file you have designated to hold the main content of that frameset is where the Navigation should be. If you would extract the main content from the frameset and view just that one page, the Navigation should be visible. Don't hide it in a tiny side frame.
|
