|
|
Posted by Beauregard T. Shagnasty on 10/19/07 15:35
Tim Streater wrote:
> "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> wrote:
>> Tim Streater wrote:
>>> 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.
Ok, some people like to make things more complicated.
>> 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).
Do you have full control of your 50 users' browsers? If JavaScript is
disabled, that will certainly fail. <g>
> In fact, if I had my way, I'd prevent any of these going into the
> history stack.
JavaScript should be able do that, for those who have it enabled.
>> 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.
You didn't say that before...
--
-bts
-Motorcycles defy gravity; cars just suck
Navigation:
[Reply to this message]
|