|
|
Posted by Neredbojias on 10/27/30 11:21
With neither quill nor qualm, Stewart Gordon quothed
> True. However, some of the benefits of frames are lost:
>
> 1. It becomes necessary to have several versions of the frameset page,
> taking up more space on your server and in the user's cache.
No. Using either javascript or some server-side solution, only 1 is
needed.
> 2. The browser must fetch two html files each time a link is followed,
> which can slow things down a bit.
True, but the frameset is only marginally inhibitive.
> 3. It adds to the duplication of effort involved in creating an unframed
> version as well for those who do browse using Lynx or a mobile phone.
Well, when I did it, it was for a strictly thumbs-'n-graphics page so I
didn't particularly care about the consequences to Lynx, and phones are
for talking on.
> 4. It becomes tricky to link to fragments. Suppose you want to provide
> a navigation frame with links to various parts of various pages. Unless
> you create a frameset for each _fragment_ of a page, changing the whole
> frameset at once won't achieve this. Unless you pass the fragment ID as
> a query string in the frameset URL itself, and rely on either
> JavaScript (which will always shut out and/or annoy some users) or
> server-side scripting (which will add to your server load and prevent
> people from browsing your site offline) to pass it on.
Uh huh, but as always, the page-crafter should be astute enough at his
craft to limit relative complications such as you describe. I could
screw up a non-frames html page just as easily.
> 5. Some kinds of interactive sites can certainly benefit from being able
> to switch some frames without resetting the state of others.
All I'm saying is that frames *can* be used correctly. They are not an
automatic pariah to html but do require some forethought of application
in order to provide a beneficial interface to the web.
--
Neredbojias
Contrary to popular belief, it is believable.
Navigation:
[Reply to this message]
|