|
|
Posted by Tim Streater on 10/19/07 15:23
In article
<ps3Si.239251$ax1.173353@bgtnsc05-news.ops.worldnet.att.net>,
"Beauregard T. Shagnasty" <a.nony.mous@example.invalid> wrote:
> Tim Streater wrote:
>
> > Neredbojias <monstersquasher@yahoo.com> wrote:
> >> Here's an example of a non-frames page with a stationary header and
> >> footer:
> >>
> >> http://www.neredbojias.com/_a/whelan1.html
> >
> > Again, you don't say why it's better, you merely assert that it is.
>
> 1. There is only one page to deal with, not three or four (frameset,
> heading page, nav page, footer page, and of course, content page).
It may ease the implementer's task, but so what.
> 2. While looking at any of the sub-pages (in this case images), a
> visitor can *bookmark* the sub-page, unlike in frames where only the
> frameset page can be bookmarked.
The main page in my app is reached via a table on another page. The
table contents may change (not very often, but it happens) based on
database contents. So they shouldn't be bookmarking even the main page,
as it may not exist at some future point. And they certainly shouldn't
be bookmarking the sub pages, as they are likely to get rubbish (data is
passed back and forth via JS variables in the top frame).
In fact, if I had my way, I'd prevent any of these going into the
history stack.
> 3. Assuming pages of text rather than images, Google will index the
> content on the sub-page, and when a visitor goes there (direct link sans
> frameset), there is *no* header, footer, and more importantly, no
> navigation.
Google doesn't need to know anything about any of my app's pages -
indeed, shouldn't because the users need to login to reach them.
> That should do it, eh?
Yep, sure does.
Navigation:
[Reply to this message]
|