103204 - link toolbar does not work with frames

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect)

Description

[basic]

currently the link toolbar does not work with frames. I'll attach a testcase.

I think that the link toolbar should work with the relevant links in the frames.
However the frameset document might have links too. I'm not sure how this need
to be handled but without handling links in frames would make the link toolbar
much less useful.

Comment 1

[basic]

Attachment: testcase (bugzilla search)

Comment 2

[sairuh (rarely reading bugmail)]

to gerv for triage.

Comment 3

[Gervase Markham [:gerv]]

This is a difficult question that it's not possible to answer immediately. When
the initial hubbub around the links toolbar dies down, we can think about this
issue. Bug 102990 is relevant - that will happen eventually, and will be a good
start. If we can do tabs right, then we can think about frames.

Gerv

Comment 4

[Jeffrey Baker]

back button doesn't support frames either.  frames are a navigational hazard. 
may the guy who invented them have a dry, itchy scalp for all eternity.

Comment 5

[Tim 'Tool-Man' Taylor]

Put LINK elements in your frameset document and the toolbar should work fine ;-)

I'm only half joking.  Frames are deprecated.  How far must we go to support
them?  This bug could easily be renamed to "Frames make it hard to build
consistent, easy to use navigation UIs".  I vote for INVALID (per above frameset
comment) or WONTFIX (per deprecation).

Actually, I kind of lied that adding to the frameset would be enough, since I
don't think we ever got the toolbar using the TARGET attribute of the LINK element.

Comment 6

[Gervase Markham [:gerv]]

WONTFIX. I probably won't fix this specifically. If it falls out of the tab
work, so be it. Frames suck.

Gerv

Comment 7

[Ashley Bischoff (blog at handcoding.com)]

*** Bug 105920 has been marked as a duplicate of this bug. ***

Comment 8

[Niko Pavlicek]

ok, I disagree with WONTFIX for the following reasons:

Often frames are
  a. just redirections (like the one in the duped bug 105920) and the
<link>-definition is in the content frame (the one with the "real" page) and if
you follow a link on this site, the <link>-elements also change and they can't
be defined in the frameset
  b. there is one navigation-frame in which the <link>-definition is done. This
frame can change too, e.g. for different sections of the website and so the
<link>-elements can change, too and they can't be defined in the frameset.

And if there are <link>-Tags in the frameset AND one or more frames of the
frameset, it's still easy to decide which should appear in the site navigation bar:
  1. you use the ones defined in the frameset
  2. then you start searching for them in frame[1], frame[2], .., frame[n] and
mozilla adds new <link>s respectively overwrites existing ones of the frameset
or previous frames.

Any objections?

Comment 9

[Gervase Markham [:gerv]]

WONTFIX === extraordinarily low priority compared to other links toolbar stuff.
So low, in fact, that anyone who has the skill to work on it should be working
on more important stuff for 1.0. If you want to reopen it, assign it to
[e-mail], and target it at Mozilla 1.2, feel free. :-)

Gerv

Comment 10

[basic]

ok here goes

Comment 11

[Niko Pavlicek]

I would understand your comment, if it had been on a feature request, but this
bug is just the full functionality of a yet-implemented feature!
Many pages use frames and additionaly there are thousands of redirections
managed with frames, especially on personal websites. It's not a bug which
affects one or two pages and if you want people to use <link>-Tags they have to
be able to use them in frames, too, since it is an additional way to navigate
through pages and not an alternative to a frame-based navigation!

Comment 12

[basic]

and so that Gerv wouldn't hear about this bug again

Comment 13

[Niko Pavlicek]

sorry for the spam:

your == Gervase's

Comment 14

[Gervase Markham [:gerv]]

I repeat: I would implore anyone who has the skill and knowledge to be working
on this to work on e.g. XBLifying the toolbar, or moving it into the content
area, or fixings its performance problems, all of which are higher priority than
this. Some of them are prerequisites, as well.

Gerv

Comment 15

[basic]

Niko: I think more thought is needed before attempting to fix this. We should
see how other browsers handle this (if at all).

I originally thought that this could be fixed by having the link toolbar
correspond to the currently focused frame, but I realized that it is not always
ideal. Maybe something like having the link toolbar correspond to the currently
focused frame and if it does not have (some of the) links, display the links in
the parent and so on and so forth...

This is just an idea, why don't you bring this discussion to a mozilla newsgroup
like netscape.public.mozilla.browser and maybe some web developers mailing
list/newsgroup or even the W3C HTML mailing list and see what they say about how
links and frames should be handled (note that frames include both framesets and
iframes)

Comment 16

[Alex Bishop]

When/if bug 102990 is fixed then I assume it would be possible to put a Site
Navigation Bar (or whatever we're calling it nowadays) in each frame. I have no
idea what to do about the case where you have both a frameset and frames with
<link> tags though. And don't even begin to confuse my little mind with the
possibilites of nested framesets...

So how do browsers like iCab do this?

Comment 17

[Niko Pavlicek]

ok, I thought about the problem, again. Here's my new solution proposal:

After the toolbar is placed above the content area with bug #102990, the toolbar
should show the <link>s of the currently selected (focused) frame. It is not a
good idea to place a toolbar in each frame, which has <link>s specified, since
frames are 
1. often used as an layout element and the layout would look like **** with a
toolbar in it.
2. often very small (100 - 200px), especially navigation frames, which probably
have the <link>s specified in the most cases.

Comment 18

[Alex Bishop]

Good idea, but it doesn't solve the problem of if the frameset document has
<link> elements though.

Comment 19

[Michael Nahrath]

This thread gives another proove of the general weakness of the frames concept.

One of the main weaknesses of frames in user experience is that viewable content
is no more directly connected to the URL in the URL bar.

At least the link navigation toolbar needs to keep this connection. The values
of <link ...> can only be displayed for the topmost frameset. Everything else
would give a user experience desaster.

Having an own link toolbar for each frame is no solution for several reasons:

* Most sites use frames mainly for decorative reasons. Webmasters do weired
things to make frame borders invisable to their users. I think that this is a
bad idea, but _they_ would hate us for setting tolbars in the middle of what
they call "their layout"

* There is still the option for displaying the toolbar always. Imagine what this
would do to sites that use 4 frames only to create a margin around the content!

* The basic idea in navigation by the link element is standardisation. 
It has to be consistent for all sites. Thus there can be only one link toolbar
at a time and it has to keep its place inside the crome. 
(Please reread <http://www.euronet.nl/~tekelenb/WWW/LINK/> for the basic idea!)

BTW.: The toolbar's place should be either as near as possible to the site
content or it should be connected with the page title and the URL bar.

* Compare! Where is the content of title element of framed pages displayed?

* Try to think a frameset document to be a normal page that references external
data (like Images and iframes), only with the difference that the external data
takes 100% of the viewport! Would you as well like a toolbar and a title for
each iframe?

More about frames (sorry, only in German):
<http://www.subotnik.net/html/frames.html>
More about the link element (sorry, some weeks outdated concerning browsers):
<http://www.subotnik.net/html/link.html>

IMO Mozilla already behaves correctly concerning <link ...> in framed situations. 
It uses those in the topmost frameset (Example: <http://www.buhev.de/aktuell.html>)

Ergo: --> invalid

Comment 20

[Hixie (not reading bugmail)]

I'd like to add my vote that we WONTFIX this. Let's not encourage authors to use
frames any more than they need to.

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420