Re: XFrames - Resurrected Zombies? (was: Comments on HLink)

Let me put forth my opinion on XFrames by using an
example web application.  The screen is laid out as
following.

+-------------------+
|        A          |
+---+---------------+
| B |               |
|   |       D       |
+---+               |
| C |               |
|   |               |
+---+---------------+

Frame A is a banner that stays consistent throught the
application.  Frame B contains multiple search fields.
 Frame C contains the list of results acquired from
submitting the search from Frame B.  Frame D lists the
details of the item selected from the list of Frame C.

The file in Frame A is banner.html and the frame ID is
banner.
The file in Frame B is search.jsp and the frame ID is
search.
The file in Frame C is results.jsp and the frame ID is
results.
The file in Frame D is details.jsp?file_no=12345 and
the frame ID is details.

With the way frames work now, users of the application
are shielding from seeing all the mess that comprises
the URL's of the frames (query strings and such).  The
browser's address bar would read
http://www.mysite.com/app/

With XFrames, it would read something like
http://www.mysite.com/app/interface.frm#frames(
banner=banner.html,search=search.jsp,
results=results.jsp,
details=details.jsp?file_no=12345)

Now, add in any other query strings that may be
attached to these pages, and perhaps longer URLs to
access these pages, and what we've got is one giant
mess of a URL.  Where the user currently sees what
looks like a nice clean application, XFrames would
have the user exposed to a mess of things they have no
reason to see, and would contribute to an overall
feeling of sloppiness in their mind.

But then you say, "But wait, at least the page can be
easily bookmarked now."  But that is not the case. 
The post data submitted when the search form was
activated is still missing, so the results screen in
Frame C would remain empty, yet the details of a file
would be showing in Frame D, clearly not the desired
behavior.  Using IE 6.0, I can already bookmark framed
pages pretty decently.  I'd say that bookmarking of
framed pages is already probably as good as it's going
to get.  Perhaps all that is needed is merely a note
on best practice user agents should follow when
bookmarking framed pages.

Now, back on the topic of those hideously long URLs,
they could also lead to some serious problems.  Let's
say www.topsecretstuff.com is using XFrames.  Evil
User X could then create a link of the form
http://www.topsecretstuff.com/interface.frm#frames(
frame1=banner.html,frame2=menu.html,
frame3=disclaimer.html,
frame4=http://www.eviluserx.com/phonyinfo)

Now that is what I'd call a serious security problem.

As of now, I see no reason for XFrames to even exist. 
It doesn't seem to provide any benefits over the
current implementation of frames, and has what I see
as many significant drawbacks.  In my opinion, it's
change for the sake of change.

Bill Daly

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Received on Friday, 27 September 2002 14:57:59 UTC