|
|
Posted by Len Philpot on 12/31/05 02:15
In article
<hufbr1hfl857d7ic158a3u3l2qlecolp5s@news.spartanicus.utvinternet.ie>,
invalid@invalid.invalid says...
> You say that you cannot figure out how to replicate the function of
> frames and when you are told you reject it with an argument that amounts
> to "but that's not how frames work". Frames are a fundamentally broken
> concept, hence proper solutions should at best aim only to replace some
> of the functionality of frames, *not* replicate the failures of the
> frames concept.
This is starting to remind me of some of the threads on c.l.c. from time
to time... ;-\
I don't want to replicate the _broken_ behavior of frames. I can easily
replace the broken parts of frames (SE following, etc.) with non-broken
CSS. However, one of the _non-broken_ fuctions is the ability to remain
static while other content scrolls. If that's my opinion (in your
opinion), then so be it. There's nothing inherently "broken" in that
[static/scrolling] concept just because someone arbitrarily decides it
is.
> >Let's see - I can have the same nav code repeated x times for x pages
> >and have to manually update it each change, or I can (functionally)
> >"import" it once for the nav frame and that's it.
>
> The framed nav code is in a separate file: multiple source files.
Yes, *one* separate file. Or should a C programmer maintain multiple
copies of stdio.h for each and every *.c module in which it's #included?
> >Seems simpler to me, aside from any other issues.
>
> For the third time: preprocessor, S&R, building static files locally
> using a database, only the last option is potentially more complicated
> to use than using frames.
And for the xth time, I don't have a database, preprocessor, SSI,
scripting nor anything else available to me *at my ISP* (regardless of
whatever I might install here locally). As I stated before, I'm
(voluntarily) working within the constraints of my ISP account. If this
were a (paid) commercial website, things would be different.
> Btw, it's bad form to link to the active (target) page itself, so a
> navbar should change from page to page by omitting the link to the
> (target) page itself.
Ideally, yes, but not a major infraction. Once again, this would matter
more if the nav panel changed from page to page. If it's static, then
technically /none/ of the links should be there, since they'll all be
redundant at some point in the experience. That would completely nullify
the usabilty for the nav panel at all...
--
-- Len Philpot -> len@philpot.org <--
------ ><> -----> http://philpot.org/ <--
Navigation:
[Reply to this message]
|