Re: Frames spec & the NOFRAMES tag

> I think you've misunderstood what I proposed completely.

Actually, rereading my message, I have to agree.. sorry about that.

Actually, I hadn't misunderstood you that much, I think, I just got
something turned around somehow in my response and ended up talking
about the wrong issue instead of the one I intended to.. :)

> This issue has been rehashed again and again, and proposals from new
> elements to extensions like yours to new URL schemes have been proposed on
> the list, all of them with basic problems. How would you express a
> four-frame frameset in which 3 of the four (or all four) of the frames have
> been changed to new contents?

Actually, in that respect, your proposal is just as flawed as mine. 
There is no provision in your proposal (as far as I can see) for
referencing "changed" frames either, only the one original configuration
presented when the page/frameset first comes up.

Really, none of these schemes adequately address the issue of
"bookmarking" someplace you browsed to, and probably never will.  In my
opinion this can only really be handled by browsers which record
bookmarks properly (noting the content of each frame in a multi-frame
bookmark, etc), which none of them currently do.  I don't think it's
really feasable to attack bad browser design with language changes,
however.

> Problems with DevEdge Online, which is a typical example of frame use:
> 
> It reloads the frameset ALL the time. Otherwise it would be impossible to
> bookmark/link to anything but the root document, and the TITLE of what
> you're viewing would always be "DevEdge Online"

Well, but think about it, isn't this exactly what you're proposing too? 
The only difference is that your scheme only uses one HTML file while
theirs uses 3 or 4.  I will admit that it's slightly more cumbersome,
but I don't see anything that really warrants a completely new (and not
easily compatible) language construct.

> It's impossible to link to a specific section, let alone use a fragment
> identifier to link to a tail link somewhere within a document that's
> displayed in one of the frames.

My proposed solution would work just as effectively for this as yours
would, unless I'm missing a major part of your proposal.

> While you're viewing the site, there's ALWAYS a "main" frame and the rest of
> the frames are just "supporting" frames. The "main" frame contains the
> actual document you're viewing, while the "supporting" frames contain
> information about navigation, document titles, etc. This is VERY bad,
> because it means that neither the documents in the "supporting" frames nor
> the document in the "main" frame CAN STAND ON THEIR OWN. They are, in an
> abstract way - not the strict SGML view of the thing, invalid. 
I will grant you that conceptually, frames are a little awkward, clumsy,
and yes, even a bad design.  Personally, I would have done frames
significantly differently if I were designing them, but there is an
important point here and that is that the current implementation of
frames already exists, is being used, and will continue to be used for a
long time to come, to the extent that it's even included in the latest
HTML standard.  Frames are here to stay.  With that in mind, I'm loathe
to support essentially duplicating the same functionality in a
completely different system unless there's a significant benefit which
can't be achieved via enhancements to the existing system, and I don't
see anything your proposal will do which the existing LINK system and
the existing frames system can't.

> What you propose would have to be A LOT more complicated in order to work as
> you propose. And a lot of problems would still exist.

I think you're trying to attribute a lot more to my proposal than I was
attempting to propose.  I never claimed it would fix all the problems
there are with frames, just the ones your proposal would fix, and then I
went on to point out that it could have additional UI benefits as well,
which it could.

-alex

Received on Saturday, 7 March 1998 04:35:15 UTC