Closed
Bug 2800
Opened 26 years ago
Closed 23 years ago
No UI for HTML2 "LINK" element
Categories
(SeaMonkey :: General, defect, P3)
SeaMonkey
General
Tracking
(Not tracked)
mozilla1.0
People
(Reporter: ian, Assigned: drbrain-bugzilla)
References
(Blocks 1 open bug, )
Details
(Keywords: helpwanted, Whiteboard: [Hixie-P2] PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt)
Attachments
(13 files)
(deleted),
text/plain
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/x-java-archive
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
application/x-java-archive
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
application/x-xpinstall
|
Details |
Test URIs:
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link1.html
http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/link2.html
Expected Behaviour:
http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3
For this bug to be completely fixed, the UI must be up and running. However,
as a start, NGLayout could actually understand and parse the LINK
information, and then when it comes to implementing it in the UI, it'll be
just a matter of making links and titles available on a menu.
Reporter | ||
Updated•26 years ago
|
QA Contact: 4110
Summary: HTML2 "LINK" element not supported → No UI for HTML2 "LINK" element
Reporter | ||
Comment 3•26 years ago
|
||
From 3173:
>
> "I'd suggest either a dockable pane containing a list of the available
> navigation elements, or an icon (as on the menu bar) or small glyph (as
> sometimes appear on the status bar i.e. the security icon) to indicate
> that there is additional navigational options. This can be clicked on to
> give further options. The two could of course be combined... so that
> clicking on the glyph brings up the navigational box which can be
> minimised to become just a glyph again"
>
> The bug report is suggesting something very reasonable, but it's more of a
> feature request than a bug because the HTML4 spec suggests how this
> information could be used, but doesn't really mandate I'm changing the
> severity to "enhancement" and marking it REMIND so I don't
> forget about it, but we probably won't implement it for version 1.0
>
[ Changing summary, transfering QA contact from 3173 ]
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 4•26 years ago
|
||
Verified RESOLVED-REMIND
Reporter | ||
Comment 5•25 years ago
|
||
Reporter | ||
Comment 6•25 years ago
|
||
I have attached some additional information which may be useful when this
feature is implemented. It is also available on the world wide web at:
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
Reporter | ||
Updated•25 years ago
|
Status: VERIFIED → REOPENED
Reporter | ||
Comment 7•25 years ago
|
||
Since bug 1995 is now under consideration, and it is very similar, I am
reopening this bug.
Reporter | ||
Updated•25 years ago
|
Resolution: REMIND → ---
Reporter | ||
Comment 8•25 years ago
|
||
Troy, you may wish to reassign this bug to german/don/shuang in UE, as this
will probably require a spec before it can be implemented.
Note that I have already written a preliminary spec which is available at:
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
Note further that this feature has already been partly implemented in the Lynx
browser for some time.
Reporter | ||
Comment 10•25 years ago
|
||
Note to rick/kipp/peter: Any generated content attached to the <link> element
should act as a link. See bug 6306.
Comment 11•25 years ago
|
||
latering to m10 and downgrading setting priority to p3. Likely candidate for
exposing this functionality will be the what's related panel inside the sidebar.
Comment 12•25 years ago
|
||
*** Bug 10747 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Target Milestone: M10 → M16
Comment 13•25 years ago
|
||
Later.
Updated•25 years ago
|
QA Contact: chrisd → claudius
Comment 14•25 years ago
|
||
Reassigning QA contact to claudius@netscape.com. This seems to be a UI issue.
Comment 15•25 years ago
|
||
this will be past beta 1. If we for some reason do not get it into 5.0 we will
have to move it to 5.1
Comment 16•25 years ago
|
||
The following internet-draft specified a proposed set of link relations. You
might find it interesting, even though it expired ages ago.
<A
HREF="http://www.groveware.com/~lee/papers/draft-ietf-html-relrev-00.txt">http://www.groveware.com/~lee/papers/draft-ietf-html-relrev-00.txt</A>
Comment 17•25 years ago
|
||
My two cents: using a sidebar panel for this would be a bad idea.
Ideally, the LINK attribute should be a way of implementing consistent
navigation, without including global navigation links on every page (and
stuffing up search engine indexes in the process). And some of these links are
pretty important (author, next document, previous document, etc). A majority of
people are going to have their sidebar hidden, so if LINK uses a sidebar panel,
they'll seldom be noticed.
I'd suggest a pane which pops up at the bottom of the window for a document
with LINKs; with icons for the semi-standard RELs, and a generic icon for any
others.
OS: Windows 98 → All
Hardware: Other → All
Comment 18•25 years ago
|
||
Ack.
But wait, what if I want the links to appear at the top of the content window?
Pref, pref!
Comment 19•25 years ago
|
||
Then you drag the link bar to the top of the window, of course! (Once we have
toolbars which can do that, that is.)
Comment 20•25 years ago
|
||
I think the browser should make a toolbar across the top of the page where I
could give links to sections of my site. It would be nice if I could provide a
graphic for each link also, an icon or gif.
This tag is also used for external stylesheets. It might work to have
everything with a rel= of "stylesheet" or "alternate" in a menu where it is
more out of sight, and everything else in the toolbar.
NCSA Mosaic uses this tag to make a toolbar. Go to
http://www.nemontel.net/~2ezfarm/cursor/index.html to see an example of using
this tag.
Comment 21•25 years ago
|
||
Moving all libPref component bugs to new Preferences: Backend component.
libPref component will be deleted.
Component: libPref → Preferences: Backend
Comment 22•25 years ago
|
||
Perhaps this would be better implemented as a collapsible frame, rather than a
toolbar. It's a subtle distinction, but a frame would work better for a frameset
and its frames, all of which had their own sets of LINK elements. With a toolbar,
the toolbar elements would change every time you switched focus from one frame to
another. You'd also have difficulty in getting at the LINKs for the frameset
itself (since you can't give the frameset focus).
BTW, what is this doing in Preferences: Backend? Shouldn't it be in one of the
HTML/DOM/Layout categories?
Comment 23•24 years ago
|
||
It occurs to me that these items should be added to the bottom of the 'Go' menu,
if Netscape 6/Mozilla has one (don't have a working build on this machine to
check).
I'm not saying that they shouldn't also be some other more obvious UI as is
being discussed above, just that these would make a lot of sense on the go menu.
(Go site home, go next etc)
Please see also bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=33684
which discuses an 'UP' button. I think an Up button is a great idea, but rather
than simply chopping off the end of the URL as suggested on 33684 it should
interact with the <link> tag to do something smarter.
One would simply grey it out for pages without the right <link rel=" " > tag
defined - web sie authors would swiftly start thinking "hey that's cool, how do
I get it to work on my sites"
This has the potential for *hugely* increasing the usability of the web. No more
guessing where the next/previous/contents/index/search/site hompage links are
hidden. (Though these could still exist, naturally).
Not to mention this would make life easier for the makers of speech & other
accessibility technology browers. (I know I've written one).
But it needs to be supported in a major browser like Mozilla to give the site
authors out there incentive to support it. Otherwise you have a vicious circle
that no one will use the tags, because none of the browsers have a UI for it,
and none of the browsers have a UI because no one uses the tags :-(
Comment 24•24 years ago
|
||
based on the last comment, I thought you might like to see this, radha.
Comment 25•24 years ago
|
||
Aside from "Go" menu, I think there should be smaller navigation buttons
(only textual?) below the location bar for this purpose:
^[________________________________________________]Go
<Up> <Previous> <Next> <Contents> <Index> <...>
If we get rid of funny gray strip, there is just enough room for these buttons
below the location bar.
(Be sure not to increase the height of toolbar as it is already big enough (too
big?)
Comment 26•24 years ago
|
||
For a good example of a browser using LINKs well, here's an article about LINK
types with many iCab screenshots:
http://www.euronet.nl/~tekelenb/WWW/LINK/index.html
Comment 27•24 years ago
|
||
In the screenshots at http://www.euronet.nl/~tekelenb/WWW/LINK/index.html
the LINK element toolbar is way too prominent, IMHO.
If both the browser's main toolbar and the LINK toolbar are rendered
graphically, how to make eg. the browser's generic "Back" clearly distinct from
the "Prev/Previous" LINK button? Or the browser "Home" from the LINK
"Home/Start/Top"?
The drop-down menu - see the last screenshot on the mentioned page - feels like
a better solution to me.
See also Jakob Nielsen's review of (and some improvement suggestions to) the
iCab LINK interface: http://www.useit.com/papers/icab.html
Comment 28•24 years ago
|
||
> the LINK element toolbar is way too prominent
That's because it's shown all the time, when it should only be shown when there
are LINK elements in the page.
> how to make eg. the browser's generic "Back" clearly distinct from the
> "Prev/Previous" LINK button? Or the browser "Home" from the LINK
> "Home/Start/Top"?
By using different icons. And possibly by not allowing page authors to change the
icons, either (though they might be able to change the colors).
> The drop-down menu - see the last screenshot on the mentioned page - feels like
> a better solution to me.
I don't think so -- just like putting it in a sidebar panel, that implementation
would suffer from the problem that much of the time it would not be visible. LINK
navigation should be shown *whenever* it is present -- it shouldn't require extra
clicks.
Comment 29•24 years ago
|
||
I think those iCab screenshots are pretty nice.
Jakob Nielsen's setup where the link toolbar is small and *out of the way of*
the other navigation buttons is interesting. Being all the way "over there on
the right" seems, to my mind to be enough to differentiate it from the back and
forward buttons.
I think the best way to do this would be to recognise a few of the "standard"
rel="foo" names and use icons for those, but also use labels (the first 2 words
of the rel ?). Buttons for which there is no icon would simply use the rel text
label.
Home is the real problem - its confusing to have 2 home buttons, one for the
site and one for the user's home page. What we'd probably want to do is make
the label for the button 'Site Homepage' and try to think of a different icon.
Ideally we'd want to work out the site name "NBC Homepage" but there's not
really a good way to work this out, unless we were to specify some meta tags
that authors could use to enrich the information presented in the <link
rel="foo"> tags.
Can anyone think of a better term than Site Homepage? I was messing around with
ideas like 'Front Door' but nothing quite seems to click (plus you need
something you can localise).
Also - as the iCab toolbar shows, there's no reason not to have the icons *and*
a more self explanatory drop down menu too. Its not like the drop down wastes a
lot of space...
So what do we need to do to get something built for this so we can play with
ideas and gather feedback from the community? I'd like to see this happen in
time for commerical Netscape 6. I can build on Linux and I'm willing to throw
something together but I'm not exactly familiar with the codebase....
What do the netscape people think? Anyone got time to work on this, or to help
me out a little? Is this the sort of thing that we'd be able to try out without
writing C++ or is it going to take a little code to get it going?
Comment 30•24 years ago
|
||
The iCab toolbar seems nice.
As I suggested above, it should be put under the url bar on the navigation
toolbar . In this way we have large back,forward, ... buttons on the left and
small icons below the url bar for LINK element UI.
Comment 31•24 years ago
|
||
We probably will not be able to make this one into this verison at all. Move to
later milestone for future consideration.
Target Milestone: M16 → M30
Comment 32•24 years ago
|
||
Based on the discussion here, I created and attached a couple of imaginary
screenshots of a proposed LINK GUI. As you can see, it's kind of a compromise
between the full button bar and the drop-down menu.
Some open issues:
- Is the current set (Home, Prev, Up, Next) the optimal "most common" LINK
navigation set?
- Should "Previous" be abbreviated to "Prev"?
- Is "Site navigation" an appropriate term to start with?
- The UI still appears a bit cluttered to me when Personal toolbar and the
"Site navigation" toolbar are both visible. How could we improve this?
Opinions? Comments? Volunteers for an implementation? (We do want this before
Netscape 9, don't we?-)
Comment 33•24 years ago
|
||
Comment 34•24 years ago
|
||
| - Is the current set (Home, Prev, Up, Next) the optimal "most common" LINK
| navigation set?
I think author/e-mail should be included too (rel="made"). This is supported in Lynx (just hit c to write an e-mail to the author of the page), and is a *very* useful feature.
| - Should "Previous" be abbreviated to "Prev"?
If 'author' is included, it probably should be.
| - Is "Site navigation" an appropriate term to start with?
'Site links'?
Reporter | ||
Comment 35•24 years ago
|
||
I like all this discussion, but can I please ask that you all read
my "Suggestions for implementation of UI for LINK element" document which I
wrote around a year ago? The latest copy is available here:
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
Important things to note from that document are the "rel" and "rev" attributes,
the "hreflang", "type" and "media" attributes, and the "alternate" keyword, as
well as a host of other issues.
Any implementation which does not take all of these issues into account are
not complete solutions.
Component: Preferences: Backend → User Interface: Design Feedback
Comment 36•24 years ago
|
||
Great discussion. As usual, whenever I think of an enhancement for Moz, other
people are already working on it :) The screenshot attached here is a great
start, IMHO. The other thing I am worried about is how to work the glossary
in. I think it might be nice to add a "Lookup term in glossary" button for each
term that appears in the glossary, but really I haven't done enough
investigation to see if there are standard formats for glossaries. My gut says
"no", therefore Moz would have to be pretty smart about linking.
Perhaps Moz could extract every anchor from the glossary and use the resulting
anchor names as terms to highlight in the document.
Suggestions?
Comment 37•24 years ago
|
||
adding self to CC:
Comment 38•24 years ago
|
||
I am currently attempting to implement this using just XUL, JavaScript, and
DOM. (I'm learning as I go, but it's easier than I thought) I posted a
document that describes some of the issues and problems with the design that I
have encountered while reading the specifications and discussions. In
addition, I've described some of the options for implementation. Hopefully I
can get some feedback on these issues so we can finally add this HTML 2.0
feature to Netscape.
http://www.prismelite.com/linktag.txt
Comment 39•24 years ago
|
||
| ------- Additional Comments From Tim Hill 2000-05-18 19:30 -------
|
| [ ... ] so we can finally add this HTML 2.0 feature to Netscape.
Great!
Comment 40•24 years ago
|
||
Pragmatically, in order to get page authors think that using LINK is a good idea,
we really need the following. I'm proposing a couple of non-standard HTML
extensions here; this isn't something I do lightly, but I really think it's
necessary if LINK is ever going to have widespread use.
* LINK elements, when present, must always be visible. They must not be hidden in
a menu, and they must not be hidden if the document happens to have been
subsumed into a frameset (my LINK-reliant site must not lose all navigation if
it happens to have been chosen as an AskJeeves answer, for example). That's why
I say that LINKs should be a floating frame at the top of the document/frame --
I think the W3C's statement, quoted by Tim, that LINKs `are NOT rendered with
the document's contents' can be interpreted as meaning that LINKs should not
scroll with the document's contents (just like toolbars don't).
* An (optional) LINKS element needs to be introduced which contains the LINK
elements, and which is stylable in the same way as lists are -- it can be given
background color, background image, etc. This is necessary in order for authors
to have *some* degree of visual control over the navigation, without losing
the general consistency in navigation that was the whole point of LINK in the
first place.
* A NOLINKS element, akin to the NOFRAMES element, needs to be introduced to
surround traditional navigation elements in HTML documents. This is necessary
in order for pages containing LINKs to remain backward-compatible with browsers
which don't support LINK, without having two sets of navigation on those
browsers which do.
Reporter | ||
Comment 41•24 years ago
|
||
I agree with your first point.
Concerning your second and third points: There's no reason to have a LINKS
element not a NOLINKS element, everything that you have described can already
be done using CSS as is stands.
However, I'm not sure we want to allow the author to style the UI at all... I
mean, you're the one who keeps saying we want consistency in the UI and all
that. Skinnable, yes, but if the look and feel of the links buttons/bar/
whatever change each time a user changes site, usability must suffer, no?
Tim: I'm working on answering your questions.
Comment 42•24 years ago
|
||
I don't think the LINK UI should be skinnable by a web page. Consistency is very important, and of the points of having the LINK element, is being able to have consistent (and therefore easy to use) navigation across web sites.
Comment 43•24 years ago
|
||
* Any implementation of LINK at all will be far, far more consistent than what we
have now (which is a bunch of A HREF links in arbitrary places).
* We need to make LINK stylable to some extent, if a decent proportion of page
authors are to consider it good enough (read: cool enough) to use instead of
their traditional navigation (a bunch of A HREF links in arbitrary places).
* All that really needs to be stylable is the color (of the LINK label text), the
background color/image (of the links bar), and the image used for the Home link
(e.g. the site's logo -- consistency here is provided by the fact that the Home
link is always the first link in the links bar).
Comment 44•24 years ago
|
||
| We need to make LINK stylable to some extent,
| if a decent proportion of page
| authors are to consider it good enough (read:
| cool enough) to use instead of
| their traditional navigation (a bunch of A HREF
| links in arbitrary places).
*Instead* of? They shouldn't use LINK instead of their traditional navigation, but in addition too. One reason is that only Lynx, iCab and Mozilla support LINK, but there are other reasons. Navigation is extremely important to a web site. Using only LINK will not be satisfactory. Often, the navigation is organized in a tree structure, which makes it much more easy to use than just LINK elements. A site can't (and shouldn't) rely on just LINK elements, but should use them in addition to its normal navigation bars.
| All that really needs to be stylable is the color (of the
| LINK label text), the background color/image (of the links
| bar), and the image used for the Home link
| (e.g. the site's logo -- consistency here is provided by
| the fact that the Home link is always the first link in
| the links bar).
What will be gained by this? The real advantage of a LINK navigation bar is that it'll look exactly the same on all web pages, therefore greatly improving the usability and making navigation both easier and faster (you don't have to "learn" a new way of navigating for each web site you visit).
Comment 45•24 years ago
|
||
LINK is part of HEAD, not of the BODY, and should not be styleable by the page
just like the TITLE isn't.
Comment 46•24 years ago
|
||
Ian and I are hammering out a spec for doing this. We're in agreement on about
75 % of it so far. I'll attach it when we've finished.
Comment 47•24 years ago
|
||
Hi all,
Though this bug is assigned to me, I have not looked in to it, because I have
other higher priority features/bugs assigned to me. Some of you have actively
discussed specs and possible implementations. If anybody is interested in taking
over this bug and implementing it, please go ahead. I think it will be a while
before myself or somebody else will implement it.
Thanks,
Radha
Reporter | ||
Comment 48•24 years ago
|
||
Tim, since you are working on this I'm reassigning it to you. Feel free to
assign it to me if you don't want it, I can find someone else to deal with it...
;-)
Assignee: german → tim
Status: ASSIGNED → NEW
Comment 49•24 years ago
|
||
Accepting. Moving target milestone from M30 to M18 (I can hope :) ). I'm
waiting for the spec from Matthew and Ian, but working on the basic
XUL/JavaScript implementation in the meantime.
Comment 50•24 years ago
|
||
At 2000-05-04 02:56, Antti Näyhä said:
> In the screenshots at http://www.euronet.nl/~tekelenb/WWW/LINK/index.html
> the LINK element toolbar is way too prominent, IMHO
Please notice that the primary nav buttons have been set to text-only rather
than graphical.
Great discussion here. I'd love to see LINK support by Netscape beta/PR2.
There is also the possibility of multiple LINKs with the same REL value. I
could set REL="next" HREF="my-next-doc.html" and also a REL="next"
HREF="webring.cgi?nextsite" for example. The toolbar widgets would need to
expand into menus in this case. The TITLE attribute could be used as the text
here, with HREFLANG info appended (if applicable). If the user has tooltips on,
these could pop up when the user mouses over the button, too.
At 2000-05-04 04:35, Matthew Thomas said:
>> the LINK element toolbar is way too prominent
> That's because it's shown all the time, when it should only be
> shown when there are LINK elements in the page.
I disagree. It should always be visible, so that authors and users will know
the feature is there for use. The number of authors making use of LINK is small
now, but it will grow if its a known feature.
Comment 51•24 years ago
|
||
| I disagree. It should always be visible, so that
| authors and users will know
| the feature is there for use. The number of
| authors making use of LINK is small
| now, but it will grow if its a known feature.
I agree with this comment. If the LINK toolbar is always visible, "all" web sites will begin using the LINK element. This is a Good Thing!
Reporter | ||
Comment 52•24 years ago
|
||
We now have a more detailed spec for this:
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
Comments welcome. Sooner rather than later though, please, since Tim is already
working on this and we don't want him to have to redo it five times... ;-)
Comment 53•24 years ago
|
||
Its all gone a bit quiet! Great spec guys, now all we have to do is get the damn
thing built :-)
To that end - I'm really a Java coder, C++ is not my strong point, and I'm no
expert on the Mozilla source base, however I am willing to help.
I'm assuming adding the links toolbar to the xul has been easy enough - its just
a matter of adding a new <toolbar> to the appropriate xul file, right?
So now it needs wiring up so the buttons actually *do* something. I assume this
is gonna involve C++ whether we like it or not. (Javascript might be OK for a
demo, but you're gonna have to catch documentLoad events and act on them).
This file shows a patch for nsWebShell.cpp that the Java DOM guys have for
getting document load events on Solaris:
http://lxr.mozilla.org/mozilla/source/java/dom/nsWebShell.cpp.patch
I doubt this is necessary in this case - presumably we can just add to code that
already gets called on the document load event. Has anyone figured out where this
might be?
Once we're notified that the page is loading we need to:
i) get a reference to the document
ii) walk the dom to find the links: something like
document.getElementsByTagName("LINK") though one could walk down into the HEAD
element first.
iii) Process the LINK tags in accordance with the spec
Next get a reference to our XUL toolbar and somehow:
iv) enable/disable each button
v) build the popup menu
vi) wire each button and menu item so it opens the appropriate URL
To be honest, if we knew where this code needs to go and how to go about getting
references to the objects we need, a spit and duct tape version could probably be
hacked up in a day or 2. Error handling would take longer ;-)
Anyone know the guts of Mozilla well enough to be able to add any pointers to
this bug? (sure wish there was some "getting started with these 10000 c++ files
document :-| )
I'd be willing to do some the of typing, but my time for exploration is
distinctly limited. I'm a fair C coder, but Mozilla seems to need some fairly
funky C++ and it'd be a learning curve.
(this comment was also to be made available in
x-minbari-warrior-caste-windswords-clan but transmission time at sublight speeds
was deemed to be excessive ;-)
Comment 54•24 years ago
|
||
Been doing some heavy digging:
This file looks interesting - certainly there's a lot of logic for dealing with
LINK tags in here - its seperating out the rel=stylesheet ones from the others:
http://lxr.mozilla.org/mozilla/source/layout/html/document/src/nsHTMLContentSink.cpp
Still, I'm in two minds as to how we would implement the fix for this bug - and
the problem is that I fundamentally don't understand the Moz architecture.
e.g.
maybe we want to be way down at this level in the Content Sink or maybe we want
to be several layers up in the code watching for document load events and
searching the DOM for the links. I dunno.
Someone needs to hit the newsgroups and start asking impertinent questions ;-)
Comment 55•24 years ago
|
||
Don't Panic (TM). Tim is working on this, but (as I understand it) it's a slow
job, and a proper implementation is dependent on a number of unfixed bugs (Tim,
does the dependency list need updating?). If you want to help out, e-mailing
Tim is probably the best thing to do.
Comment 56•24 years ago
|
||
I did hack up a quick version of this in a few days. Now I'm working on the
non-hack version :) I put up a web site at http://www.prismelite.com/linktag/
if you'd like to track my progress. I might put up the source soon so people
can test it.
You can find out when a document has finished loading by using:
contentArea.addEventListener("load", onloadfunc, true);
Ideally, I'd prefer to be notified whenever a LINK tag is created or destroyed,
rather than using getElementsByTagName. But notification doesn't appear to be
possible through JavaScript/DOM (DOM2 supports node mutation events but Mozilla
doesn't support it yet)...
Since LINK tag support is kind of Layout (as well as kind of Front End), the
implementation might be a bit nicer if done from C++... but unless someone is
willing and able to do that (not me!), I'm going ahead with my JS
implementation. The main area where JavaScript is deficient is in getting
notifications of new LINKs.
Whiteboard: http://www.prismelite.com/linktag/
Comment 57•24 years ago
|
||
http://www.w3.org/TR/REC-html40/types.html#type-links has a list of standard
link types and this note:
"Authors may wish to define additional link types not described in this
specification. If they do so, they should use a profile to cite the conventions
used to define the link types. Please see the profile attribute of the HEAD
element for more details."
(The profile attribute is defined at
http://www.w3.org/TR/REC-html40/struct/global.html#adef-profile)
Do you guys think this is something we should care about? Or should we just
carelessly show all link types except those with the word 'stylesheet' -
recognized or not - in the UI?
Comment 58•24 years ago
|
||
I sent an email to Ian regarding the link spec. Hope you got it.
Antti brings up a good concern. There should be some sort of general LINK
handling feature in Moz, perhaps similar to iCab's "all LINKs" menu. If the
author put it there, it must be something important, and ought to be accessible
in some way. Also, browsers can outlive specs...more standard REL types may be
added and this should be allowed for.
I don't quite follow why we wouldn't want stylesheet types to be available
though. Perhaps web developers would like to see the text of the stylesheets; I
know I would. I think I mentioned this in the email to Ian, too.
Reporter | ||
Comment 59•24 years ago
|
||
Our current spec does say to show all links, except stylesheet:
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
I guess we could decide to show stylesheets as well. Matthew: Is there any
particular reason to avoid those?
Tim: One thing though is that "stylesheet alternate" does not mean that the link
is an alternate version of this document. So we need to take that into account
even if we _do_ show stylesheets.
I still think we need a decent LINK API. See my comments in bug 7515.
BTW, Tim: You rock. ;-)
Depends on: 7515
Whiteboard: http://www.prismelite.com/linktag/ → PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
Comment 60•24 years ago
|
||
REL type "alternate" should always indicate a secondary option of the other
indicated REL type. If "alternate" is the _only_ REL type, then it indicates an
alternate web page (different language maybe, or whatever).
For instance, you could have "next" and "next alternate" LINKs. The former
indicates the next page in the 'typical' sequence, the latter the next page in
an 'alternate' sequence. I alluded to this in my comment on 2000-06-08 12:06.
The Next button would have a default action, but could also open a menu since
there is more than one option available.
Similarly you can have "stylesheet" and "alternate stylesheet" LINKs that the
user could switch between. This might be messy when multiple stylesheets are
meant to be used concurrently. I might want one stylesheet the always applies,
and additional ones that the user can switch between, one of which may be
applied by default by not specifying "alternate". If I switch to the alternate
one, will it...
1. Be applied in addition to the other two
2. Replace the other current secondary style
3. Replace both current style sheets
This bit is outside the scope of this bug (2800) but it's a valid concern. I
don't know how Moz currently applies (multiple) styles.
Reporter | ||
Comment 61•24 years ago
|
||
Tim Larson wrote:
> REL type "alternate" should always indicate a secondary option of the other
> indicated REL type.
Woh -- hang on, what makes you think this? References, please! What you say is
the OPPOSITE of what the HTML4 spec says.
http://www.w3.org/TR/html4/types.html#type-links
> Similarly you can have "stylesheet" and "alternate stylesheet" LINKs that the
> user could switch between. This might be messy when multiple [...]
HTML4 is *VERY* precise about this issue. Mozilla implements it correctly, as is
shown by my ImportTest suite (you can only see this from Viewer at the moment).
Comment 62•24 years ago
|
||
Unfortunately, the HTML specification remains somewhat vague on what multiple
link types in the same "rel" attribute mean. It just says "rel" is defined as:
<!ENTITY % LinkTypes "CDATA" -- space-separated list of link types -->
"alternate" used by itself refers to an alternate form of the current
document. "alternate stylesheet" uses "alternate" to modify the meaning
of "stylesheet". What exactly the following values would mean is debatable...
Does it apply to all other rel values? Some? The ones before? The ones after?
rel="alternate next copyright"
rel="next alternate copyright"
rel="next copyright alternate"
Even though HTML uses "alternate" to modify the semantics of "stylesheet" (I
think it SHOULD have used "alternate-stylesheet"), I hesitate to introduce rel
values (such as "alternate") that modify others, yet look syntactically the
same as normal values.
The way it's designed now, you can already generate a menu for the "next"
button by including more than one LINK with rel="next".
The primary reason to hide stylesheets in the Link Navigation menu is that most
users don't care about viewing the source code for stylesheets. In addition,
the list of stylesheets will eventually be accessible from View > Use
Stylesheet. For web developers though, stylesheet source should be accessible
from the "View Source" window.
Comment 63•24 years ago
|
||
Ian Hickson wrote:
> http://www.w3.org/TR/html4/types.html#type-links
Hmm, I have been totally misreading that part for some time, then. I stand
corrected. By some mental lapse I thought that alternate referred to the object
of the LINK, and thus extended to all REL types. (Made sense to me at the
time.) Tim Hill's comment sums it up I suppose.
> HTML4 is *VERY* precise about this issue. Mozilla implements it correctly
As I haven't seen a mechanism for switching style sheets anywhere in Moz yet, I
guess I'll have to take your word for it.
Comment 64•24 years ago
|
||
I doubt there's much point in putting stylesheets in the menu.
Mozilla's View->Use Stylesheet menu will (when it works!) allow you to switch
between stylesheets quite nicely, actually reading the things is only of
interest to developers, and they know how to find the names and download them
with "View Source".
This is a new feature that could be of great benefit to end users, and we need
to avoid cluttering the interface with "geek friendly" features so that it
remains easy to understand and use. (Especially those geek features where the
geeks know there's already a way to do it.)
As for C++ vs. Javascript I have no vested interest in doing it either way.
I'm surprised it can be done in JS at all though! (New respect for Mozilla).
Where on earth do you put the script s.t. it's called for every page loaded?
Its not in a web page obviously...
I guess whether a C++ implementation is necessary depends on
i) are there anyu issues that simply aren't solvable from JS. Tim seems to
think there might be
ii) Is this the only component in Mozilla that works this way? If everything
else like this is implemented in C++ following some standard pattern we would
want the implementation we have to use the same pattern, so as to simplify
maintainence.
iii) Is the JavaScript version too slow?
In any case I applaud Tim for getting this done... We should certainly work out
all the issues we need to solve with the JS version then present this to the
relevent module owners to see if we can get it included, or whether they feels
it needs to be implemented in C++.
I have real hope this will get into NS6 now. Beta 3 anyone?
Reporter | ||
Comment 65•24 years ago
|
||
lordpixel wrote:
> Is this the only component in Mozilla that works this way?
Well... most of the interface is written in JavaScript, actually. JavaScript for
the work and XML and CSS for the interface. Scary huh. ;-) Look in the "chrome"
directory for proof...
Tim Larson wrote:
> As I haven't seen a mechanism for switching style sheets anywhere in Moz yet,
> I guess I'll have to take your word for it.
Run "viewer" and look in the menus.
RE: the stylesheet thing -- on thinking about it, I think it is best to leave
the stylesheets out of the menu, and leave the showing them business up to
View Source or Page Info. It's too geeky to be part of the standard UI.
Comment 66•24 years ago
|
||
I think we should maintain a list of recognized "navigational" rel/rev values,
and _only_ show a LINK element in the Navigation menu if the rel/rev value is
found on the list.
Some examples of LINKs that make absolutely no sense in the Navigation menu:
- style sheets
- P3P Profiles: the draft uses <link rel="P3Pv1" href="URI">
- TrueDoc fonts: <link rel="fontdef" src="URI">
(note, though, that this is using a non-standard 'src' attribute and
such things should be done with CSS anyway)
- RDF sitemaps
- a lot more to come in a few years, probably.
It wouldn't be reliable to solve the problem another way around (by having a
list of "non-navigational" rel/rev's) since new link types are being born all
the time.
Of course, "non-navigational" LINKs might be shown in another place, such as
View -> Page Info.
PS. I just noticed that the 'href' attribute is not required in HTML 4. Thus,
it should be added to the spec that all LINKs with no href attribute should be
ignored while constructing the Navigation menu.
Comment 67•24 years ago
|
||
I agree, the problem is LINK can serve two purposes -- presenting a human-
understandable User Interface and being a machine-readable link to other
files. And so far, it's been used mostly by software
("stylesheet", "fontdef", "P3Pv1", "schema.dc", "shortcut icon").
Possible solution... Only display items in the Navigation menu that specify
a "title" attribute. Exception: stylesheets would not be shown in the
Navigation menu, title or no title. Exception: the "title" attribute for the
standard navigational items (top, up, previous, next, possibly others) could be
left unspecified or blank and still appear (i.e. as "Next" instead of "Next:
Chapter 3"). Advantages:
1. Good backwards-compatibility. Most LINK tags intended for machines don't
have title attributes, as far as I know, so they'd automatically be hidden.
2. Extensibility. New REL values could still appear in the UI. Specifying a
title probably means that you wanted it to be read by a human.
3. Consistency. This is similar to the way persistent stylesheets vs.
preferred/alternate stylesheets are treated in the HTML spec.
Comment 68•24 years ago
|
||
A test version of the LINK tag interface is now available...
http://www.prismelite.com/linktag/
Comment 69•24 years ago
|
||
First off, I'd just like to saw congratulations and WOW!
Great job. Now what we need to do is push this to final quality and get it landed
with the help of the module owner.
However, the first stage of that is for me to tell you all the bugs I found.
We should also decide whether to keep using this bug or whether to open new bugs
to cover any issues.
I'm testing on Mac OS and I can also test on Linux, though less frequently, so if
any other Linux users want to get involved that would be great:
Here are some problems:
****We need to confirm whether these are Mac specfic, so people get reproducing!
****This issue alone will probably force us to open new bugs. If issues are
****plaform specific we should use Bugzilla to track this accurately
* Crash with mailto: links. This html, which Lynx browser users will recognise
is commonly used to specify the author of a page:
<link rev="made" href="mailto:whoever@foo.com">
When linktag 0.5 hits this it generates a button calle Author, and add it to the
Site menu.
a) bizarrely, the Author button seems to have a drop down menu. Why?
b) When I select the mailto: link the browser crashes. Messily.
This could be a general bug in mailto: support but I could not find any such
bug. Are other people seeing this problem.
Note: I may not have any mail accounts set up in Mozilla, so it could be trying
to launch the new account wizzard. Please also try to check this possibility.
Comment 70•24 years ago
|
||
I decided to split each bug out into a seperate comment, at least.
Apologies for all the spam!
* Tooltips: These should behave like other Mozilla toolips, appending the title=
"" atribute to the URL when possible. (i.e. when both exist) and using
"Location: URL" if we decide to display any links that do not have titles set.
Comment 71•24 years ago
|
||
Regarding the crash with mailto: links...
...cannot reproduce this on Windows NT 4 Workstation running SP 6a. The mail composer came and launched the account wizard successfully. No crash.
See http://www.brookers.co.nz/catalogue/ for the page I used to test this.
Comment 72•24 years ago
|
||
* The icons on the Link toolbar highlight on Mouse over even when the button is
disabled
Comment 73•24 years ago
|
||
* icons look *really cheesy* on the classic skin :-)
* Site menu doesn't look like a menu on Modern skin. No down arrow
* Why is this menu called site? I don't think a new user would understand this.
How about "Site Links"
* Is there a reason the Site menu comes first? For some reason I always though it
would be the last element in the toolbar, as it seems more obscure than the
Top and Up buttons, which is what I expected to be first
Comment 74•24 years ago
|
||
* Why doesn't the toolbar load until I go to a page that has <link> tags?
Once I've visited one page it stays up. Is this by design or is this a bug?
* Why is the icon for the site menu a circle? No icon may be better
* Position of the toolbar. One of the things I liked about the iCab
implementation (links to screenshots are elsewhere in this bug) is that it was
right aligned. This kept it completely seperate from the other controls (no way
to confuse Top with Home or Next/Previous with Back/Forward) because several
inches of space seperate them.
For the sake of simplicity, I'll describe using the modern skin.
Could we:
i) right align the toobar within the blue stripy area such that its right hand
edge aligns with the right hand edge of the address box (i.e. its under the
search button
ii) Can we move it into the grey area, so it sits under the throbber, right up
against the right hand edge of the window? That way it doesn't (imediately) get
in the way of the personal toolbar.
Trouble is I'm not sure how flexible Moz's toolbars will eventually be. If
they're as good as the ones in MS Office and IE then the links bar should be a
seperate bar that the user can drag around and put where they please. I'd still
prefer under the throbber for the default though. Thoughts?
Final note:
Apologies for all the spam. I think this bug is going to have to spawn children
very soon.
Also, I'm not trying to be mean to Tim here. I think the work he's done is
wonderful. I'm trying to play devil's advocate and question everything.
Comment 75•24 years ago
|
||
Ok, I know I said the last comment would be the last for tonight, but this is
important.
It seems linktag 0.5 is not playing nicely on the Mac with build 2000071810 at
all. I tried clicking the same mailto: link in Mozilla 2000071810 with linktag
0.5 added, and without and in the one with linktag it crashes, in the one without
it works perfectly.
n.b. this was not a mailto: link in the links toolbar. It was an "ordinary"
mailto: link in an <a> in the page.
This does not look good. Someething is obviously getting screwed up.
Can someone delete all their mail profiles from Mozilla so that when they go into
Moz Mail&News the account creation wizard pops up autmoatically?
I want to see if that will trigger a crash on Win32 and Linux.
That said - LinkTag should not be causing unrelated parts of the browser, like
<a href="mailto:foo@bar.com"> foo</a> to crash under any circumstances.
I can give you stack crawls if need be, but I figured they'd be little use as its
written in JavaScript.
Comment 76•24 years ago
|
||
I really think we need to have a discussion/debate in the
netscape.public.mozilla.ui newsgroup (this bug is getting rather long) about
what the "default" LINK items should be. There's plenty of disagreement about
that right now :) Another big issue is where the toolbar should be positioned,
how big it should be, when it should appear (only when there are link tags is
the designed behavior), icons/text, etc.
I think I've had a crash before with mailto and no account configured, but I
doubt it's due to me (though crazier things have been known to happen). I
can't reproduce it anymore. If you can repeat it consistently, with the EXACT
same conditions for no linktag / linktag (i.e. registry and profiles deleted),
let me know.
The Author button is actually a menu, so if you included multiple authors it
would display them all. There are many skin-related issues remaining including
the ones you mentioned. The site icon is a circle, and the icons are cheesy
because I'm not an artist :) The icons and text wording can easily be changed
though, since it was designed to be skinned and localized.
Comment 77•24 years ago
|
||
OK, I did a full regression test on the mailto: links, deleting all the
registries and profiles between attempts and it does indeed look like a false
alarm. Sometimes Mozilla does crash when trying to invoke a mailto: link but it
has nothing to do with Link Tag per se.
A couple of other notes: I'm up for a discussion in the UI newsgroup. Should I
just start it anytime or should we arange a time for a few of us to get together
an begin, to gets things kicked off in a lively fashion?
I truly believe the Links toolbar should be on all the time.
Two things about the author menu -
i) the menu always appears blank to me. It works, in that it tries to start the
Mail and News compoent when I select the first item, but there is no text
ii) I thought the plan was that when a menu button on the links bar only had one
entry it would act as a button, without the menu appearing? Is there some bug
which blocks this?
Oh, and Mathew T - are you going to put this into Aphrodite when its done?
Comment 78•24 years ago
|
||
Things seem to have stalled againand doing a diff against a recent navigator.css
is also making me worry this is bitrotting.
One thing I forgot to mention before:
I don't seem framesets as a big problem.
I figure do one of two things:
i) Ignore <links> in the <frames> and just go with what's in the <frameset>
or
ii) Start by adding everything in the frameset, then add/overwrite with any links
from the sub frames.
Why not? There's no signifcant existing implementation to be incompatible with,
and since, like so many things about framesets, the semantics are undefined, why
not just do what feels best?
Chances are most people won't add <links> to both the frameset, their main frame
and their navigation frame, but if they do we should either just use the frameset
(to a user its the main document no?) or try to include everything and simply
clobber links from the frameset if they're repeated in the body.
The first approach assumes the frameset is the master document and overrides
everything else the second assumes that "deeper" documents are better. Actually
I'm leaning towards the second option because rel="previous" and rel="next are
likely to be set for the documents in the frameset.
Comment 79•24 years ago
|
||
I've just tried the test version, and I think it's great. This is one of these
features which will make Mozilla "cool".
Ordinary users don't notice better standard supports, small bug fixes or
similiar new features, but they'll notice LINK support, search panel in sidebar
and themes support. This is what'll make Mozilla feel like a much better
browser.
I've always used the LINK elements on all my web pages (well, Lynx supports
them), and they feel so much easier to navigate using the Mozilla LINK support.
This *needs* to be implemented in the nightlies soon ...
Also, should there be a separate button for rel="Bookmark" links? These can be
used to create a table of contents for a (single) web page, or just for links
to sentral parts of a page (not site). For an example, see the W3C home page
<URL:http://www.w3.org/>. Very useful!
Comment 80•24 years ago
|
||
Be aware that since the 17th of July build that linktag is known to be compatible
with, there have been some changes (nothing major) to navigator.css.
Since linktag replaces this file, you're actually "damaging" any more recent
build in the sense that you're undoing those changes while applying the linktag
changes.
This is bitrotting as we watch :-(
There seems to be a phenomenal lack of interest from anyone at Netscape in
getting this in for 6.0, given it blocks full HTML 4.0 compliance, this is
surprising. Lets face it, I think by this stage we can forget about this being in
6.0. Beta 2 was supposed to be feature complete, so the only stuff getting in now
is work thats being champione by someone at Netscape, which definatey rules this
out.
:-(
Comment 81•24 years ago
|
||
I wouldn't complain that there's a total lack of interest from Netscape when all
the people from Netscape cc:ed on this bug have absolutely nothing to do with
the UI. cc:ing ben.
Comment 82•24 years ago
|
||
Comment 83•24 years ago
|
||
Comment 84•24 years ago
|
||
>I wouldn't complain that there's a total lack of interest from Netscape when all
>the people from Netscape cc:ed on this bug have absolutely nothing to do with
>the UI.
Agreed. Mea culpa.
We should definately start a thread about this in xpfe and ui newsgroups (any
others?). I'll do it if no one else feels they can, but I think people other than
me may have a better grasp of the issues. Let me know...
Comment 85•24 years ago
|
||
fwiw Hixie is @nscp. cc'ing blaker (also nscp). for reference versioned diff's
are much preferable to replacement files.
Hixie does this get a cssX keyword?
Comment 86•24 years ago
|
||
I am working on a source patch against current CVS right now. Let me know if I
am duplicating effort.
FYI, my patch will implement the link widgets as their own toolbar. There
simply isn't enough room to jam them underneath the Location input on the
navigation toolbar. IMHO.
Comment 87•24 years ago
|
||
I've got it working on the new Modern skin. For some reason, the icons aren't
being styled in, but I'm working on it.
Give me some feedback on this screenshot:
http://atari.saturn5.com/~jwb/linktag-modern.gif
Comment 88•24 years ago
|
||
Excellent work, Jeffrey. It's own toolbar is exactly what LINK needs. The most
obvious problems from the screenshot:
(1) the toolbar should appear below the Bookmarks Toolbar, not above it. (This is
because it should only appear when there are navigation links to show,
otherwise users won't notice when the links are active. And we don't want the
Bookmarks Toolbar to be jumping around, depending on whether the Links
Toolbar is visible or not for a given page.)
(2) `Site' should be `Site home'.
(3) It looks as though all the items are menus. If so: that's wrong -- they
should only be menus if there is more than one link with the same rel/rev
value. If not: then get rid of those triangles.
Comment 89•24 years ago
|
||
Sorry for the non-CVSed "patch", I only recently got a proper tree and C++
compiler setup. I've also been busy working on a few other things...
I did try to bring the subject up in another bug about having a LINK tag
toolbar, but didn't get much response there. I agree that the navigation
toolbar is over-crowded, especially with all of the other buttons being added
to it. But should the content area really shift up and down every time you
enter and exit a LINKs page? I found this annoying. We already have enough
chrome. The second issue to decide is what the default buttons should be.
i.e. "Top", "Up", "Previous", "Next", etc. The third issue to address is what
the link tag buttons should look like on each of the skins. Should we re-use
an existing button style class that will look good on both Classic and Modern,
or do Link Tag buttons need their own unique button style class? Both Modern
and Classic are in a continual state of flux. It's nice to re-use existing
style rules as much as possible, but Link Tag buttons have special requirements
over plain buttons... in addition to a graphic on the left side of the button,
a drop-down arrow on the right side of the button should be visible if the
button is a button-menu, but otherwise it should leave a blank space. Finally
I have a few more bugs to squash in the code itself. If someone wants to work
on the skinning portion of this, I'd appreciate the help.
Comment 90•24 years ago
|
||
Tim: Using your javascript, I don't ever get the icons I see in your screenshot.
Each button has the little diamond next to it (see my screenshot). Is this one
of your known problems, or something messed up in the style system?
I'm > 75% done with the conversion to a CVS patch, and I am also converting the
GIFs to PNGs.
Comment 91•24 years ago
|
||
One other thought: The amount of content here almost makes it more useful as
part of page info in a sidebar.
I don't remember which bugs discuss sidebar features maybe mpt can mention
them.
I also need to see if we have support for autohiding the sidebar, because if we
did, this sort of stuff would me much more useful.
Ben any thoughts or comments?
Comment 92•24 years ago
|
||
Re: the shifting content area, I don't really think that's a problem. At least,
it's as much of a problem as any other issue with content moving around during
progressive display of a page. We *want* something obvious to change between when
a page uses these links and when it doesn't, otherwise users just aren't going to
notice.
Re: the sidebar idea, see my comments in this bug on 2000-02-01. (And
auto-showing the sidebar would make the content shift around even *more* than
with a toolbar.)
Re: the page info idea, LINK elements (and their HTTP equivalent) are what I
refer to as `intrinsic' links in the `Links' tab of <http://critique.net.nz/
project/mozilla/general/component/info/>. But if we restrict the UI for LINK to
that, we're only really being useful to Web developers, not Web surfers.
Comment 93•24 years ago
|
||
I've rolled the patch forward to current CVS. See my patch at
http://atari.saturn5.com/~jwb/linktag/
What you get from this patch is a functional linktag toolbar in the modern skin
only, with the wrong icons. Actually, you don't even get the icons because I
didn't include them in the diff.
Anyway the port forward was pretty easy. I'm going to wait for the dust to
settle around the Modern 2 skin before I pick up this work again. Once the
skins settle down, we need to:
1) Maintain the patch against current CVS
2) Change the icons to PNG
3) Find out why the icons aren't being switched properly in linktag.js
4) Make the drop down menus look like other Mozilla drop down menus
5) Get checkin approval
6) Checkin
When is our best shot for getting this in the product? My gut feeling is either
right now, or just after we branch for the next milestone release.
Comment 94•24 years ago
|
||
Regarding comments by Matthew Thomas (2000-08-27 17:06), I think the LINK
toolbar needs to be present at _all_ times. (Others have said this before.)
LINK is an incredibly useful feature that's been ignored since HTML2. Awareness
needs to be raised. Right now so few sites implement it that it's very likely
no one will ever notice that Mozilla supports it. If, OTOH, an iCab-like
approach of "graying out" inactive buttons were used, people would say, "Hey,
what is this? How can I make it work for me?" Heck, this is exactly what
people are doing with the completely non-standard MSIE favicon.ico thing.
Please don't hide LINKs in the sidebar, either. I minimize the sidebar all the
time, because it grabs _way_ too much content area. If the space the extra
toolbar chrome will use is a concern, make it possible to toggle it off in a
preference panel, or minimize it like you can the other toolbars.
Comment 95•24 years ago
|
||
> If, OTOH, an iCab-like approach of "graying out" inactive buttons were used,
> people would say, "Hey, what is this? How can I make it work for me?"
Web developers would say that. But end users would just see a bunch of links that
(99 percent of the time they looked) were disabled. So they'd turn the toolbar
off, because it apparently didn't do anything.
And I think Web developers are going to work out the coolness of LINK by
themselves, without us taking screen real estate away from users in the meantime.
Comment 96•24 years ago
|
||
> We *want* something obvious to change between
> when a page uses these links and when it
> doesn't, otherwise users just aren't going to
> notice.
Exactly! I actually like the way it's currently implemented (with the LINK bar
appearing below the location bar). It would be nice if it were a separate
toolbar too, as long as it appears/disappears on web pages using the 'link'
element. It should IMO *not* be just grayed out. This will cause people to
disable the toolbar, and those that wouldn't probably wouldn't notice that it's
not grayed out on page using the 'link' element.
One other suggestions related to the rel="bookmark" attribute. There could be a
button for an automatically generated table of contents. This should be a
simple drop-down menu (like the other buttons) showing all the headings
('h1', 'h2', 'h3' &c.) in the document (with 'h1' centered, 'h2' left-
aligned, 'h3' left-aligned and indented, 'h4' left-aligned with more indention
&c.). This will greatly encourage web page authors to use real heading elements
instead of <font size="5">Headings</font>. Should I open a separate bug for
this?
Comment 97•24 years ago
|
||
> Web developers would say that. But end users would just see a
> bunch of links that (99 percent of the time they looked) were
> disabled. So they'd turn the toolbar off, because it apparently
> didn't do anything.
A good chunk of the early Mozilla adopters _are going to be_ web developers.
Even if they're not, seeing the feature work even _once_ is going to get some
exec's brain clicking, and he'll tell the web team to make it work. That's how
the IE favicon thing is growing. So if Mozilla is going to implement the LINK
UI anyway, make it customizable. (Note IE doesn't let you turn off the
favicon.) Make it a three-way option [always on, only when LINKs present,
always off] if you want. I'll just set mine to "always on". Does this meet the
requirements of not stealing real estate now, yet allowing for coolness when
developers catch on? I hope so.
Regardless of the initial state of the toolbar, when it _is_ visible the
standard LINKs (whichever they end up being) that are not available on the page
should be grayed out.
Comment 98•24 years ago
|
||
Might want to use "Main" instead of "Site Home"--keeps it distinct from the
user's Home page.
Comment 99•24 years ago
|
||
The LINKs can be in the sidebar, as long as it's available from a toolbar too.
The perfect place for it in the sidebar is of course the What's Related panel.
Comment 100•24 years ago
|
||
Reading the discussion of using frames vs using toolbars, I can see the
arguments for both, so it seems that we need a pref. I think the available
options should be (the wording is bad, but you get the idea...):
* As a frame above every frame that provides LINKs
This would add the 'toolbar' in the form of a small frame above every frame that
provides LINKs (other than stylesheets).
* As a toolbar (always on)
This would put the toolbar immediately below all other toolbars. It would
display at all times, and the frame that applies would be chosen by the
following algorithm:
- If no visible frames have links, display only the standard buttons and disable
them all.
- If only one visible frame has links, use that frame always.
- If more than one visible frame has links, then choose one arbitrarily when the
page first loads
- When a frame with links gains focus, take the links from that frame
- When a frame loses focus, *do not* change the links unless the focus was
transferred to another frame with links.
* As a toolbar (appearing when needed)
This should be the default. The same algorithm as above should apply, except
that if no visible frame has links, the toolbar should be hidden. In addition,
if possible, a "lazy" algorithm should be used to determine when to display this
toolbar - create only when it is known for *certain* that (at least one of) the
currently displayed frames has links, and take it away only when it is known for
certain that no frames do. Thus, when navigating between pages that all have
links, the toolbar would not disappear and reappear between page views.
I think the coloring should match the page canvas if a "frame" is used, but
match the rest of the toolbars if a "toolbar" choice is used.
Thoughts? Any comments on ease of implementing this with the current toolbar
implementation?
Comment 101•24 years ago
|
||
Changing the icons can be done later. Fine-tuning the wording of the links can be
done later. But now can we just check in this baby? (Please?)
I'd suggest ignoring link rel="icon" in the same way as we ignore
link="stylesheet", for forwards-compatibility with bug 32087. But that's not a
blocker for this to be checked in, really.
Comment 102•24 years ago
|
||
I understand your frustration. Since it seems that new modern skin has landed,
I am proceeding on my work to port the patch forward on both modern and classic
skins. I expect to have this work complete by September 11. If I don't post my
patch here by then, ping me again.
Comment 103•24 years ago
|
||
Just a warning. I've picked up from the newsgroups that September 14th seems to
be the last possible day to get anything checked in to make beta 3. Don't know
this for certain but a couple of comments have suggested this.
Comment 104•24 years ago
|
||
> I expect to have this work complete by September 11.
Well, it's September 12 now. Is is finished?
Comment 105•24 years ago
|
||
Okay kids, the patch is ready. I have implemented the linktag toolbar in
classic and new modern. The link widgets are in their own toolbar, which can be
toggled with view->link toolbar. The toolbar disappears when there are no LINK
elements. I also ditched the icons because they looked goofy on both skins.
Anyway, lets leave the details for later. When need to get this checked in
today, in the next few hours. I volunteer to own this thing from now until we
ship. All I need is a quick review, and checkin approval from brendan or
waterson. Who should review this patch?
Comment 106•24 years ago
|
||
Attaching the patch to the bug would be a good start. Perhaps
ben@netscape.com should review?
Comment 107•24 years ago
|
||
Reassigning to Jeffrey. I'll try to help out since linktag.js is mostly mine,
but I'm a bit too busy right now to work on this. Should this go in right
before nsbeta3; how long a period before the final release? Is there really a
UI feature freeze?
Assignee: tim → jwbaker
Status: ASSIGNED → NEW
Comment 109•24 years ago
|
||
Comment 110•24 years ago
|
||
> Is there really a UI feature freeze?
YES! See 'UI Freeze' in n.p.m.seamonkey.
Comment 111•24 years ago
|
||
Patch looks pretty good to me. One question (maybe I'm just missing some of the
code). Why do you tear down the tooltip's text element and recreate it each
time? Can't you just set the <text> element's value without having to destroy
and recreate it?
Comment 112•24 years ago
|
||
This might be a useful resource for designing the menu organization specifics:
http://fantasai.tripod.com/qref/Appendix/LinkTypes/
"ltdef.html" is a list of definitions quoted directly from the sources; makes it
easier to look things up. "alphindex.html" is an alphabetical index for it.
Comment 113•24 years ago
|
||
Has this been checked in? (with the UI freeze and all?) Look at the number of
votes for this bug...
Comment 114•24 years ago
|
||
I solicited review from ben and hewitt, but I'm still waiting.
Comment 115•24 years ago
|
||
Let's vote ;-) 19->20
Is the question concerning the tooltips' text David Hyatt asked solved?
Comment 116•24 years ago
|
||
This looks like a completely new feature, and the feature cutoff deadline is
long past. Marking nsbeta3-.
Whiteboard: PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt → [feature][nsbeta3-]PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
Comment 117•24 years ago
|
||
That's pretty cute. Ignore the bug report for 20 months, ignore the existant
patch for two months, let review for the latest patch slide past the feature
deadline, then claim that the deadline is gone.
This is the only thing I hate about working on Mozilla: Netscape management.
Meanwhile hewitt, nbhatla, and company have a blank check nsbeta3+ approval to
completely overhaul (read: destroy) the modern skin, right before and continuing
through the "feature freeze". Very nice.
Get back to me when the Open Source product and the bad management product are
on two different branches.
Comment 118•24 years ago
|
||
Its also required for Netscape's stated goal of HTML 4.0 compliance.
No scratch that, its required for HTML 2.0 compliance. Sheesh!
Sad. Very sad.
Comment 119•24 years ago
|
||
Sorry, but this isn't Netscape's fault this time. This branch has been a long
time coming. As the patch was created by a Mozilla contributor, it didn't have
to be nsbeta3+ to get it checked in. Had you finished it and checked it in
before today, it would be in Netscape 6.
And, for what it's worth, the blank check theme bugs have been minused or
marked fixed today.
On a brighter note, per your request Jeffrey, it's time to get back to you --
as of today, Mozilla and Netscape 6.0 are in separate branches, and will
continue to be until Netscape 6 rtm.
Comment 120•24 years ago
|
||
That's BS. Even as a m.o contributor I still need review and approval for the
checkin, otherwise the process would go all to hell. I didn't get review from
anybody, so I couldn't exacly just check it in.
There is an inherent conflict between the open source side of this project and
the AOL side. The open source people are going to want to ship it when it meets
its stated goals. The AOL people want to ship it by date X. Luckily now that
it is branched we can perhaps both get what we want.
That is, *if* I can get a module owner to review the damn thing.
Comment 121•24 years ago
|
||
[Last comment before this moves to other communication methods...]
It is not BS. Hyatt said the patch looked good on 9/15 (meaning you were
probably inches from an r=hyatt) and just asked a simple question. You never
answered it, so there went that potential reviewer. All you had to do to get
approval was email brendan or waterson (the checkin rules have changed slightly
now); both of them are very good about email, and respond quickly.
There is no conflict between AOL and Mozilla. The whole purpose of the branch
is so that Netscape can go off and pursue its goal for a stable build to ship
soon, and Mozilla can continue on the long, winding road to 1.0. You can still
check this patch into the Mozilla branch.
Comment 122•24 years ago
|
||
So hopes of an HTML 2 compliant Netscape 6 are shot all to heck because of 2
days and a missed email?
Great. Wonderful. I'm thrilled. *sigh*
Comment 123•24 years ago
|
||
Additionally, there are only 14 bugs with 23 votes (which this bug currently
has) or more. Of these, 3 seem to be basic compliance issues: this one, bug
22529 (25 votes), and bug 33032 (32 votes). Of those three, this is the only
one that has had a working patch ready to go for over a month.
Excluding a perfectly good patch because an arbitrary deadline was missed on
account of one email seems awfully small-minded to me. People want this
feature. The specs demand this feature. It's sitting here on a silver platter.
Get it in!
Comment 124•24 years ago
|
||
I have to agree with hyatt that recreating the content nodes for the tooltip
every time seems a bit strange. If they're already there, why not just reuse
them? It's faster, and it doesn't rely on JS garbage collection to get rid of
all the elements you're creating (and in the future things could change so that
such elements don't go away until the document does -- see my proposal in bug
52732).
If you want to be completely paranoid, you could change that bit of code to
something like the following totally untested code written in the bugzilla bug
entry form...:
function linktagToolTip(ttnode) {
if (ttnode.getAttribute("class").indexOf(LINKTAG_BTN_CLASS) == -1) return
false;
var tt = document.getElementById('linktagtooltip');
var ttbox;
var txt;
if (tt.childNodes.length != 1 || tt.firstChild.tagName != "box") {
while ( tt.childNodes.length > 0 )
tt.removeChild( tt.firstChild );
}
if (tt.firstChild) {
ttbox = tt.firstChild;
} else {
ttbox = document.createElement("box");
}
ttbox.setAttribute("orient", "horizontal");
if (ttbox.childNodes.length != 1 || ttbox.firstChild.tagName != "text") {
while ( ttbox.childNodes.length > 0 )
ttbox.removeChild( ttbox.firstChild );
}
if (ttbox.firstChild) {
txt = ttbox.firstChild;
} else {
txt = document.createElement("text");
ttbox.appendChild(txt);
}
txt.setAttribute("value", linktagGetLocalTitle(ttnode.link,
ttnode.getAttribute("data"), false, false));
if (!tt.firstChild)
tt.appendChild(ttbox);
return (true);
}
But if these are the only things the tooltip is used for, couldn't you just put
them in the XUL and do a GetElementById for the innermost one, and just change
that?
Comment 125•24 years ago
|
||
The tooltip creation code can probably be replaced -- not sure why that was
there. Although I seem to remember some problem I had where the tooltip
wouldn't resize correctly if I just set its text property, but that might have
been fixed.
Comment 126•24 years ago
|
||
So are we going to try to land this on the trunk for Mozilla0.9?
Reporter | ||
Comment 127•24 years ago
|
||
Taking QA per managerial policy.
QA Contact: claudius → py8ieh=bugzilla
Comment 128•24 years ago
|
||
I agree with jce2@po.cwru.edu - let's do something here. What needs to happen,
and who needs to do it? How can we bring it to the attention of that person?
Let's get it in so it can be in the next Milestone builds.
FWIW this is now in the top 7 bugs.
Updated•24 years ago
|
Keywords: mozilla0.9.1
Comment 129•24 years ago
|
||
According to http://www.mozilla.org/roadmap.html, what needs to happen first is
that the bug owner submit the patch to reviewers@mozilla.org. I'm not clear on
what happens next or whether the patch on this bug is in a state that's ready to
be submitted...
I could be misunderstanding the roadmap, of course. Anyone have any other ideas
on what is necessary to get this into the trunk (and by extension, into M18?).
Comment 130•24 years ago
|
||
Well, the first problem is that whoever wrote the patch is now (apparently) very
pissed off and isn't responding to any of the bug replies.
Jeffrey, are you willing to submit your patch for super-review?
Second of all, Ben Goodger supposedly had problems with the patch (9/14/00), but
he hasn't commented on his problems in this bug. Ben, if you're listening, could
you please add your comments to this bug?
Comment 131•24 years ago
|
||
First we need peer reviews. We've had some of those, and I think that some of the
suggestions need to be incorporated. This is actual work that needs doing.
Then we need a module owner review:
http://www.mozilla.org/hacking/reviewers.html
Doesn't make it clear who would own this as its both XUL, CSS and "Skins" in some
sense. i.e. its general UI.
However Hyatt says its Ben Goodger, and I concur.
We also need a super review. That would probably be Ben G again, so no doubt we
can collapse the two into one.
So - we need someone who's Javascript is good enough to handle this to take
onboard the tooltip adjustments, then when that is done we need to get some og
BenG's valuable time.
If Jeffrey's too busy, any other volunteers?
Comment 132•24 years ago
|
||
Okay kids I'm working on this bug again and I intend to get it on the tip. I
have to update the patch again because of torrential committing in the modern
skin, and then take a good look at the javascript that runs this thing.
Comment 133•24 years ago
|
||
Apologies for the delays in my commentary. I applied a version of this patch on
my W2K machine about two weeks ago and found the following problems (some are
serious, some are nitpicks):
- it did not work 'out of the box' (and I was unable to get it to work)
(I applied the patch, loaded one of Hixie's tests, the toolbar dropped down
but contained nothing)
- the code was difficult to follow.
(Few comments and no high level overview as to how the feature works,
numerous global variables that were mostly indistinguishable, convention is
to label global variables with 'gVarName' - I know a lot of the existing
code doesn't do this, but we should be fixing that ;)
- there were js warnings
- UI issues
(the toolbar should appear directly above the content area since it relates
directly to the webpage, not between the navbar and the personal toolbar.
the toolbar should also be disabled by default. Starting the browser for
the first time, the toolbar appeared, blank, and after my homepage
(mozilla.org) finished loading, the toolbar went away. This is broken. It
should be /shown/ when a page with link is loaded.)
I await a newer version of the patch that addresses these issues. This is a
great feature. Keep up the good work!
Thanks,
Ben
Comment 134•24 years ago
|
||
adding Don Melton to the CC list as he is the module owner for Navigator.
Comment 135•24 years ago
|
||
Thanks for the comments, Ben. The original patch was put together to try to get
it in before the 2000-09-15 UI freeze. Since we no longer have pressing time
constraints, I am going to pretty well rip out Tim's javascript (sorry) and
replace it with something readable and in the accepted style. The attached
patch won't currently work because of skin and event changes since it was
submitted.
Comment 136•24 years ago
|
||
Comment 137•24 years ago
|
||
I have attached my latest version of the LINK UI to this bug. Changes since the
last version:
1) Patch applies cleanly to 2000-10-16 trunk
2) Updated to understand jar packaging
3) Cleaned up linktag.js, while reducing its size by %15 and removing warnings
4) Merged the "Top" widget into the "Up" widget
5) Made all widgets menu-capable
6) Moved to standard tooltip handling (no more tearing down the tooltip box)
7) Made the View->Toolbars->Link Toolbar preference sticky
8) Made sure that the toolbar doesn't appear and disappear at startup
Issues which still remain:
1) The menubutton arrows point the wrong direction. This is really a problem
with the menubutton XUL widget itself
2) I don't know if the build works on windows. I updated jar.mn, MANIFEST, and
makefile.win, but I don't have a windows box + compiler to test it with.
3) I think I might want to move strings from linktag.properties to a DTD
somewhere.
So, please apply this patch to your tree and report the results. On windows,
please contribute and build system hackery which I have overlooked.
Target Milestone: M18 → mozilla1.0
Comment 138•24 years ago
|
||
I forget to mention that the actual loading of the URLs is wanky. First, we are
using appCore and we should transition to using the proper XPConnect stuff, but
I don't know what that is. Second, loading mailto: URLs doesn't work properly.
Reporter | ||
Comment 139•24 years ago
|
||
Jeffrey: FYI, there were some specs written for this a few months back,
which are mentioned in the above comments... Just want to make sure you've
read them to see if there is anything interesting in them:
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkelement.txt
Comment 140•24 years ago
|
||
Yes I've read those fine documents. We're baby-stepping to that goal.
Currently we do everything in that spec except distinguish between rel and rev
links, and paint a useful status line.
Is there a canonical way to make a menu item change the status line, or should I
simply use an event listener to set the status manually?
Reporter | ||
Comment 141•24 years ago
|
||
Jeffrey: Excellent!
Ben: Do we still have to do status bar stuff manually? I know it used to be that
way, but I was kinda hoping some attribute would be added at some point...
Comment 142•24 years ago
|
||
I'll try this out tonight.
Comment 143•24 years ago
|
||
Ian, yes, currently (unfortunately). Convention on windows is to display a
statusbar message when navigating around in menus. We do not support this
automatically at present, and as a result we do not do it at all.
Comment 144•24 years ago
|
||
I'm still seeing results similar to what Ben saw in his earlier comment: the
toolbar drops down appropriately at Ian's link pages, but there's nothing on it.
Any ideas?
Comment 145•24 years ago
|
||
Blake: when you say that there is nothing on the toolbar, are you saying that
there is absolutely nothing there, or that all the buttons are disabled? Also
please tell us what platform you tested on.
I installed VMWare so I can test on Windows, but I fear it may take quit a while
to compile mozilla inside windows inside a virtual machine :(
Comment 146•24 years ago
|
||
There's absolutely nothing there. Just a toolbar and a grippy. win98, new
trunk build.
Comment 147•24 years ago
|
||
Okay I know what the problem is. linktag.properties was left out of the build
process, and that's where all the strings live. The buttons are probably
*there*, but I bet they are only a few pixels wide and you can't see them. I
plan to merge linktag.properties into navigator.dtd in the next revision. In
the meantime please apply this patch in
mozilla/xpfe/browser/resources/locale/en-US/ and rebuild xpfe:
Index: makefile.win
===================================================================
RCS file: /cvsroot/mozilla/xpfe/browser/resources/locale/en-US/makefile.win,v
retrieving revision 1.14
diff -u -r1.14 makefile.win
--- makefile.win 2000/09/15 06:59:30 1.14
+++ makefile.win 2000/10/18 03:50:20
@@ -33,6 +33,7 @@
.\NetSupportConfirmCheckYN.dtd \
.\navigator.properties \
.\askViewZoom.dtd \
+ .\linktag.properties \
$(NULL)
Comment 148•24 years ago
|
||
Anything happening here? Will this get fixed/checked in for 0.9.1?
Comment 149•24 years ago
|
||
OK, with jwb's latest change, this works. But it breaks many things for me,
like mousewheel scrolling and typing in textfields (!), because the toolbar
appears to take focus. Try some -moz-user-focus rules.
And people argued when this got minused for rtm...?
Comment 150•24 years ago
|
||
Here are some problems I spot at a glance:
* The toolbar doesn't dropdown/work at http://www.bath.ac.uk/%
7Epy8ieh/internet/eviltests/link1.html, but it does at http://www.bath.ac.uk/%
7Epy8ieh/internet/eviltests/link2.html -- is it supposed to work at the former?
* The toolbar buttons should look be in the normal state again if you mousedown
and then drag the mouse away (e.g. they should only be pressed
in :hover:active, not just :active)
* You can check and uncheck Link Toolbar in View > Toolbars, but if you're not
on a page that it can be used on, that won't do anything.
* The toolbar seems to steal focus, so key and mousewheel events to webpages
are broken (!) Toolbar buttons should never take focus.
* You get the standard page context menu when right-clicking on the toolbar.
* If you go to View > Toolbars > Link Toolbar even when the toolbar is shown,
checking and unchecking the item does nothing (except print "toggling toolbar
LinkTagToolbar" in the console, which probably isn't necessary once we have all
the kinks in this patch worked out)
* `Link Toolbar' should have an access key in the menu
* You're able to drop links on the link toolbar, but not on normal chrome
toolbars. (Good luck with this one :-)
* Whatever happened to the original design, which had this toolbar more like a
toolbar and less like an integrated part of the page? I agree that, since this
is page navigation, it should probably be visually related to the page (then
again so is Back/Forward and those are on toolbars), but using standard
toolbars has benefits (like easily providing grippies, and fixing the link-drag
ability and context menu popup, along with the focus). And if you use the
standard toolbars, it'll pick up the same color as the rest of the chrome (and
the system) in at least some skins (e.g. Classic).
More comments later, I haven't even looked at the code yet.
Comment 151•24 years ago
|
||
The Linktag toolbar is just a regular <toolbar chromeclass="toolbar">, the very
same as the personal toolbar. If it has all sorts of odd behavior, then bugs
need to be filed against XP Toolkit/Widgets. I think I did a pretty damn good
job, given that the XUL reference for toolbars hasn't been updated in over 6
months, and is incomplete and wrong.
I don't have any of the problems you have when I use the Linux build. The menu
works fine, turning the bar on and off as expected. Of course, it doesn't make
the bar appear on a page with no links. That's the design intent. I don't have
any event binding problems with the toolbar. I don't get any context menu when
I right-click on it.
Is there really this giant divide between unix and windows XPT/W? Are you sure
that patch applied without any rejections?
Comment 152•24 years ago
|
||
Blake, addressing all of your comments, as tested on Linux debug build pulled
2000-11-01-22
* The toolbar work fine for me at Hixie's link1 and link2 pages.
* If you poke the button and then drag off the toolbar, the button returns to
normal state
* By design
* Key events and mousewheel both work fine
* I get no context menu on the link toolbar
* The menu entry for the Link Toolbar toggles the toolbar, as expected
* Will fix
* The toolbar does not respond to drag & drop, as expected.
* This is the original design, mostly.
Since our observations are so different, I can only assume that my patch doesn't
work properly in the Windows build environment. Most likely, one or more files
is missing from your jars.
Comment 153•24 years ago
|
||
Jeffrey Baker sez:
> The menu works fine, turning the bar on and off as expected. Of
> course, it doesn't make the bar appear on a page with no links. That's
> the design intent.
Does this mean there's no way for developers to make the LINK bar always on? I
was really hoping that this pref would be a 3-way. (See discussion circa Aug
28.) How much extra work would that be?
Comment 154•24 years ago
|
||
Considering that this three-way preference
(always-on/always-off/on-only-when-relevant) behavior is almost certainly
confusing for new users *anyway*, how about the following as a behavior to
minimize confusion:
When View->Toolbars->Link Toolbar is selected:
IF page has links:
IF toolbar is visible (ie pref is always-on OR on-when-relevant):
Change pref to always-off.
ELSE (toolbar is not visible; pref is always-off):
Change pref to on-when-relevant.
END IF
ELSE (page has no links):
IF toolbar is visible (pref is always-on):
Change pref to on-when-relevant.
ELSE (toolbar is invisible; pref is always-off or on-when-relevant)
Change pref to always-on.
END IF
END IF
(I think there should be something in a preferences panel that makes these three
choices explicit, though, otherwise it's confusing).
The benefits of this scheme are:
- Selecting the View menu item always visibly toggles the presence of the toolbar.
- If the user has the toolbar on without realizing what it does, sees the
buttons are always disabled, thinks it's useless, and toggles it off, it will
still reappear when it actually *becomes* useful.
- If the user then turns it off even though the buttons are now active, it will
stay off for good.
- The same "two-step process" can always be used to make the toolbar always
visible, even if it is originally turned on on a page that does have links.
I think that that if a "checkbox"-like menu item is really needed for this (and
it probably is, for consistency with the other toolbars), something like this
algorithm is the only way to make all possible choices available through that
menu (and of course, most users wouldn't think to look in Prefs for this,
especially since no other toolbars are in prefs).
Thoughts?
Comment 155•24 years ago
|
||
Stuart,
This makes a lot of sense to me. Actually, the only thought I have in order to
make this menu item as clear as possible, is to make a sub-menu:
View->Toolbars->Link Toolbar->Always on
Always off
On when relevant
Where the currently selected item has a check mark in front. This way you don't
even have to check the algorithm you mentioned.
Comment 156•24 years ago
|
||
I really think that making the same menu item do two different things,
depending on what the current page happens to include, is asking for trouble.
The Link Bar is not a toolbar, it is content which is specified in the page.
(E.g. in the unlikely event that two frames in a frameset have independent sets
of LINKs, each frame should have its own Links Bar at the top of it.) Offering
an explicit option to hide the Links Bar when LINKs are present, makes as much
sense as offering an explicit option to hide A HREF links when *they* are
present.
Comment 157•24 years ago
|
||
If Mr. Baker has truely quit mozilla development (per his comments in bug
40828), then we need to assign this bug to someone else to get traction.
Comment 160•24 years ago
|
||
The functionality for this toolbar needs to also go in the "go" menu. I know not
many people use this menu, but it is the logical place to put Page navigation
functions. I don't know whether this has been discussed, but it could be easily
implemented as a section in the menu with the necessary choices. The choices
could be greyed out if not available. This would make it easy for those people
who don't want a toolbar (Always Off) to be able to still access those features.
Comment 161•24 years ago
|
||
> I know not many people use this menu
Then it should be removed.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: mozilla1.0 → mozilla0.9
Comment 162•24 years ago
|
||
I use the "Go" menu all the time. It's extremely useful for navigating the
history more than one page at a time. I also think this would be another good
place for LINK nav to go in addition to the toolbar.
Updated•24 years ago
|
Priority: P2 → P3
Target Milestone: mozilla0.9 → mozilla1.0
Comment 163•24 years ago
|
||
Just if someone is interested:
I dedicated a web page to the topic 'HTML LINK-element':
http://www.subotnik.net/html/link.html
It is written in German language, but beeing mainly a list of links to English
sites it might be usefull for you even if you don't understand my words.
Updated•24 years ago
|
Keywords: helpwanted,
mozilla0.9.1,
nsbeta3,
patch,
review
Whiteboard: [feature][nsbeta3-]PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt → PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
Updated•24 years ago
|
Keywords: mozilla0.9.1
Comment 164•24 years ago
|
||
after reading comments from mpt & alecf in 23095 and remembering the ever-present
competetion, I thought that this might be done like the IE5 Auction Assistant,
sliding down over the content area, rather than a toolbar extending over the
sidebar, which it is not relevant to.
Comment 165•24 years ago
|
||
*** Bug 67850 has been marked as a duplicate of this bug. ***
Comment 166•24 years ago
|
||
From bug: 67850
In the HTML spec, I think, the link tag can provide help for a particular page
by specifying a help page url through the href attribute
e.g. <link rel="help" href="help.htm" />
For various reasons, this could prove useful if implemented by the browser.
Perhaps under help in the top menu bar, the option 'help for this page' could
appear if this tag was present in the document head.
Would seem an easy enough thing to implement (sorry, middle of college stuff or
I'd do it myself!).As far as I remember, there are a whole load of things that
<link> can refer to (rel='contents' for a sitemap, rel='glossary',
etc.).Seperate bug reports for those, I suppose, if this one seems sensible.But
they seem like useful tags to support in some fashion.
Comment 167•24 years ago
|
||
Do we have a plan for this bug? We should get at least a bare-bones UI (even if
just a list in PageInfo) for .9 so we can make sure it works for 1.0
should someone nominate for .9 so it gets on people's radar? (0.9.1 seems like
some people might miss it.) Also, nsbeta1 and top100 might be good bets.
And another thing, this is not an enhancement. This is a legitimate bug in
Mozilla's handling of HTML2.0. severity should be upped.
I wish I had the power to make these changes... Oh well...
Thanks.
Comment 168•24 years ago
|
||
I agree with moving it to 0.9 even if it's just for the purpose of getting it on
more peoples radar, top100 - no because I doubt it affects any top 100 site
(because we've got the situation that no top browser supports it so sites don't
bother), nsbeta1 - no because I don't consider myself in a position to tell
Netscape what to do, but upping severity as this is a HTML compliance issue.
Severity: enhancement → normal
Keywords: mozilla0.9
Comment 169•24 years ago
|
||
Chaning the qa contact on these bugs to me. MPT will be moving to the
owner of this component shortly. I would like to thank him for all his hard
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: ian → zach
Updated•24 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9
Updated•24 years ago
|
Target Milestone: mozilla0.9 → mozilla1.0
Comment 170•24 years ago
|
||
> (E.g. in the unlikely event that two frames in a frameset have independent
> sets of LINKs, each frame should have its own Links Bar at the top of it.)
I think that's more trouble than it's worth.
One, it's not as usable as having a consistent UI in a standard place. Two,
it's going to interact poorly with page authors that designed their framesets
and frame contents with specific dimensions in mind. Three, framesets are being
phased out of (X)HTML. Four, as you pointed out the occurance of multiple frame
contents with navigation LINKs is an edge case.
Comment 171•24 years ago
|
||
adding self to cc:, shoulda done it when I posted my comment, sorry for the spam
Assignee | ||
Comment 172•23 years ago
|
||
I have created an add-on toolbar that is in its first incarnation, it is posted at:
http://segment7.net/mozilla/linktoolbar/
I don't have much time to work on it, but at least it is a start. Patches and
suggestions are appreciated.
Comment 173•23 years ago
|
||
Unfortunately, this is not something I have time to do in the near future.
Does anyone who's been more active on this issue (Eric?) want to take this and
shepherd it along?
Comment 174•23 years ago
|
||
I'm attaching a .jar file containing Eric's toolbar with some of my revisions.
Still to do:
HTTP headers still don't work.
Needs a dtd for l10n.
Doesn't work with Modern theme.
Need to make "rel" value appear before title of "misc" links.
Reporter | ||
Updated•23 years ago
|
Whiteboard: PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt → [Hixie-P2] PROGRESS: http://www.prismelite.com/linktag/ SPEC: http://www.bath.ac.uk/%7Epy8ieh/internet/discussion/linkspec.txt
Comment 175•23 years ago
|
||
Christopher Hoess: Are you actively working on this? Also, you said you were
going to attach a .jar, but didn't...
Gerv
Comment 176•23 years ago
|
||
I suppose so, for low values of active. One of my changes managed to break the
.jar just as I was about to post it, and I had to leave the computer for the
weekend...anyway, it's working now.
Eric: I've had a change of heart, I'm just going to throw the .jar up here-it
would look kinda weird posting a diff to a patch that isn't Bugzilla-available.
I have some ideas on putting link-type + title in for "misc" links, but I'm not
sure when I'll have time to work on this again-I will definitely have some time
after the 11th, though.
Comment 177•23 years ago
|
||
Sigh...OK, Bugzilla keeps timing out whenever I try to upload an attachment, so
the .jar is now at <http://www.stwing.upenn.edu/~choess/linktoolbar.jar>. If
anyone can get it attached to this bug, feel free to do so-and Eric, feel free
to roll it into your .xpi, too.
Comment 178•23 years ago
|
||
Reassigning to Eric, who's working on this way more actively than I am.
Assignee: blakeross → drbrain-bugzilla
Status: ASSIGNED → NEW
Comment 179•23 years ago
|
||
I have updated the Link Toolbar again: it's still at the previously posted link
(on my personal homepage), but I'll try to get it sent as an attachment ASAP
(I'm behind a proxy). It now has a proper DTD for L10N, and
I've changed a little more of the parsing that assigns titles to the popup
menus.
Still to do: HTTP headers, goofs up chrome in modern theme. I'm also looking
for suggestions here on condensing the buttons: of the various HTML4 defined
link types, only chapter, section, and subsection have been placed under "Misc".
The toolbar is kind of wide (I'm sure it breaks on some people's screens), and
I'd like to know which ones people think I should condense. (If I condense,
say, "appendix" and "glossary" into "misc" as well, then those links would
appear as "appendix: title of link", "glossary: title of link", etc. in the
popup. Of course, the grouping of appendix, glossary, chapter, section, and
subsection might get a new button called "document" or something.) Please let
me know of any suggestions for reducing the number of buttons in a user-friendly
way.
In the next round of improvements, I think I'll also test a (partial?) fix for
bug 57399, by simply adding all anchor elements to the array of links. Once the
bugs with HTTP headers and modern breakage are worked out, I'll try to rearrange
the file packaging so this is an integral part of the browser chrome and not an
add-on.
Comment 180•23 years ago
|
||
> Please let me know of any suggestions for reducing the number
> of buttons in a user-friendly way.
Here's a process of elimination I think will help determine which link types
should have buttons.
First group the link types by utility:
Home # high utility
Up
Previous, Next
First, Last
Contents, Index, Glossary, Appendix
Copyright, Chapter, Section, Subsection
Help, Bookmark # low utility
Then decide which group to stop adding buttons for. Everything below the bar
goes into "misc":
Home # high utility
Up
Previous, Next
First, Last
----------------
Contents, Index, Glossary, Appendix
Copyright, Chapter, Section, Subsection
Help, Bookmark # low utility
You can place the bar whereever you like. I selected the placement above
because it represents a good compromise between utility and screen space.
In ranking utility, think about what navigation is commonly employed by websites
today or what navigation is recommended. For instance:
Home is both a highly recommended and a commonly used navigation link.
Up is recommended, but not as common. However, with increased appearances of
"breadcrumb trail" navigation, Up is becoming more common.
Next and Previous are common and probably recommended when appropriate. If I
had to choose between them and Up, I would rather have Up. A single Up button
has greater "utility density" than Next and Previous buttons.
I'm not a big fan of First and Last buttons, but I think people are accustomed
to having them when Next/Previous navigation is present. However, I wouldn't
complaining if they ended up in "misc".
The remainder are either uncommon, not recommended, or both. Furthermore, were
Contents to have a button, so should Index, Glossary, and Appendix. That alone
makes them belong in "misc".
Another way to think about it is to imagine that providing a button will spawn a
Web revolution with page authors adding LINK elements corresponding to the
available buttons. Assuming that, which buttons would provide the most benefit
for most users. Thinking this way I come up with the same results as above.
Comment 181•23 years ago
|
||
> First group the link types by utility:
>
> Home # high utility
> Up
> Previous, Next
> First, Last
> Contents, Index, Glossary, Appendix
> Copyright, Chapter, Section, Subsection
> Help, Bookmark # low utility
While agreeing with your methodology, I disagree with a bit of your your
ordering. There are several important points.
How common a <LINK> is is not something which should affect its utility. If we
decide it's less common and give it less prominent UI, then this will be a
self-fulfilling prophecy.
I haven't seen the current Link Toolbar yet, and can't remember all the
arguments about whether buttons should disappear (shorter toolbar) or get greyed
out (muscle memory) when there are no links of that type. However, Help, for
example, seems to me to be an ideal candidate for a disappearing button which is
always on the right hand end of the line of buttons (right hand end of the
toolbar for Mac).
What do Bookmark links do? If all they do is provide the URL that should be
bookmarked for this resource, then they do not need links toolbar UI at all.
Using them is the responsibility of the File Bookmark command.
I'll have a look at the current design and comment further :-)
Gerv
Comment 182•23 years ago
|
||
> What do Bookmark links do?
They're internal bookmarks. See <URL: http://www.w3.org/ >. They're especially
useful for speech browsers (and Lynx), since you can skip directly to the part
of the page that interests you, bypassing navigation bars, TOCs &c.
Comment 183•23 years ago
|
||
> How common a <LINK> is is not something which should affect its utility.
I wasn't clear. I wasn't referring to the commonality of LINK element links.
was referring to the use of A element links. For example, most sites have
markup like this somewhere on the page:
<a href="http://foo.com/">Home</a>
That's what I was referring to as a common occurance of a Home link.
Look at how authors are linking today. Figure out what the most common
relationships they're making between documents. Pretend that they've been using
LINK elements to do this. Create an interface that helps users navigate the
most common and useful of these LINK elements. Then hope that authors actually
/do/ start using LINK elements to specify the associations they've been making
all along.
Following that formula I just don't see how other associations are more
prevalent, useful, or important than Home, Up, and Next/Previous. Perhaps
Copyright is, but that can just prominent placement in the Misc or Other menu.
Afterall, it might be prevalent, but most users have no need for the copyright
info (i.e. it has low utility).
Comment 184•23 years ago
|
||
I realize this is probably quite a bit more work. But what I'd like to see is a
dynamically-sizing toolbar. Put all the "standard" buttons on it, go ahead.
Any nonstandard LINKs can go under "Misc". If the user shrinks the viewport so
that the rightmost end of it is cut off, replace those buttons with entries at
the top of the "Misc" menu. If you order the buttons from most useful (left) to
least useful (right) this would work great.
I'd second Gerv's suggestion that the "Help" button be anchored to the right end
of the bar, regardless how big the window is and what other buttons are showing.
If a window is as small as possible, the two buttons I'd want to see are "Home"
and "Help".
The option to iconify the toolbar would be great. I like to retain full
functionality while maximizing screen real estate. I like iCab's toolbar.
I like the idea of button the LINK relationship in the "Misc" menu along with
its title. Note that iCab uses ">" or "<" to indicate whether it's a REL or REV
relationship. I don't know if we'd need to go that far.
Whatever order is decided for the buttons will become a self-fulfilling prophecy
for how authors will implement LINK in their pages. ("Ditto Gerv.") Therefore
it's very important that we pick the right ones. Modifying tim@tool-man's list,
I'd suggest the following order.
Home, Help # anchored to the left and right, respectively
Up
Previous, Next
First, Last
Author
Contents, Index, Glossary, Appendix
Chapter, Section, Subsection
Copyright
Bookmark
Non-standard-ones
The first four groups (aside from Help) comprise your basic "directional" nav.
The others are more "conceptual" nav. While copyright links are common, the
average user probably won't have much use for it.
If Mozilla gets the ability to customize it's toolbars, this would be one that
users might use that alot on. Some users may read sequential articles often,
and want to use the First/Prev/Next/Last buttons the most. Other users'
navigation style may be to always refer to the Home/Chapter/Section page and
start drilling down again. Maybe a user likes to contact the authors of pages
he reads, and places the Author button prominently.
Comment 185•23 years ago
|
||
This is an RFE and MUCH lower in my list of priorities than just getting this
feature into mozilla's default installation in *any* form, but long-term, I'd
like to see this work in conjunction with bug 22056 so that the link-bar could
be used in icons-only mode. We'd need a set of icons that are somehow visually
distinguishable from the normal back/forward progression - perhaps "next" and
"previous" could borrow from the visual look of the "Next" button in mailnews,
for example.
But being able to use this toolbar in icons-only mode would allow a
significantly larger number of links to appear on it without filling the width
of the screen...
Comment 186•23 years ago
|
||
> [...] so that the link-bar could
> be used in icons-only mode. We'd need a set of icons that are somehow visually
> distinguishable from the normal back/forward progression [...]
And it would be nice if the User would be able to set his own icons for the
link-bar, independent of the current Theme.
Comment 187•23 years ago
|
||
OK, here's my current thinking:
Seven buttons.
1) |< Start
This is what people have been referring to as the "Home" button. (One of the
specs/draft specs at fantasai's page reserves the "home" keyword.) Recognizes
keywords start, begin, top, origin, and first.
2) < Prev
Recognizes keywords prev and previous.
3) ^ Up
Recognizes keywords parent and up.
4) > Next
Recognizes keywords next and child.
5) [icon of page with writing on it, arrows coming from each side] Document
Catch-all for conceptual links about this document. Recognizes (in order):
search, help, navigator, contents|toc, index, glossary, bibliography, chapter,
section, subsection, appendix, copyright, disclaimer, trademark, footnote,
biblioentry. Labels each of them in an appropriate manner.
6) [perhaps a pencil, or a "stick figure"?] Author
Recognizes keywords author, made, editor, and publisher. Labels them
appropriately.
7) Other
Alternates with no other rel keyword or an unrecognized rel keyword, properly
labeled. Links with unrecognized rel attribute, labeled with the value of the
attribute and their title.
Tim (L.), I think you have some interesting ideas here but I'm a bit wary of some
of them. I'm not sure "Help" is worth having its own button, because I think
very few sites have a resource appropriate to be linked in with rel="help".
However, in my proposal, "Search", "Help", and "Navigator" (navigational aids)
will always be at the top of the "Document" menu if they exist, so they'll still
be relatively easy to find.
There seems to be considerable enthusiasm about an all-iconic, iCab type toolbar.
Personally, I'm kind of cool to the idea (the iCab toolbar screams "mystery meat"
to me), but it seems reasonable, once but 22056 is fixed. If someone in the
viewing audience would like to supply icons as described above, it would be Much
Appreciated; my drawing abilities aren't up to it.
The "dynamic toolbar" is cool, and I think implementable, but again I'd want to
run it past mpt; I'm worried about the usability consequences.
I also want to add two menu items to the "Go" menu, as in Hixie's proposal, to
store the "rel" and "rev" values. (The toolbar doesn't do "rev" right now,
although I will probably have to ad-hack in support for rev="made", since I
understand that's used by other browsers to indicated authorship.)
Comment 188•23 years ago
|
||
Christopher,
You're right, we should be calling it "Start" instead. "Home" is reserved.
I definitely think "Help" is worth a button of its own. My personal site has
virtually no content (though I have big plans!) but already two help pages: one
for help using the site ("Hi, I use valid HTML/CSS and LINK tags to enhance your
user experience. Get a browser that supports this.") and an "about" page
describing the purpose of the site ("Hi, this site is for Stuff I Like[tm] but
all I have now is a resume.") If I only had two additional navigational aids
available, they'd be "Start" to get back to a fixed location from which I can
(theoretically) get anywhere else, and "Help" to give me some pointers for when
I am totally confused and don't even know where I'm trying to go. "Help" would
be especially useful for web applications. This would reduce the need for
hyperlinks spawning JavaScript popup windows (and whatever else), which I see
more of all the time. Just click the page's "Help". Implement the standard
HTML, and you reduce the need for scripting and improve the accessibility.
OK, I didn't know 22056 existed. That part is a RFE that can wait.
I don't know how the "dynamic toolbar" as I described it would be a usability
problem. I think _not_ having something like this would be a usability problem.
If you can't access the buttons because your window is too narrow, how do you
use these features? Maybe you slide them into the "Misc" menu, maybe you put
all LINKs in the "Go" menu for redundant secondary access. Sliding them into
the "Misc" menu keeps them in the toolbar, which I like.
I forgot all about "Search" and "Alternate". They should exist too, in the same
group as "Contents, Index, Glossary, Appendix" in my last post. I like your
idea of putting the more "conceptual" LINKs under a "Document" menu. This might
be less cluttered than throwing all LINKs into a "Misc" menu. A couple basic
"directional" buttons, document (most other standard types) stuff, author, help,
and misc (non-standard types) stuff. This is a total of about 8 buttons, your
list plus "Help". Not bad. Better than the ~20 my list is up to now! With 20
standard LINKs, maybe your idea is better than the "dynamic toolbar" from a
usability perspective - a small set of button-menus with logically grouped LINKs.
Comment 189•23 years ago
|
||
Latest changes: <URL:http://www.stwing.upenn.edu/~choess/linktoolbar.jar> has
been updated again. (If someone would like to attach this to the bug [I'm
behind a proxy], please feel free to do so.) The toolbar now has Start, Prev,
Up, Next, Document, Author, Other, and Help buttons, implemented as described in
my last comment with the exception that the Document menu isn't sorted yet. (I
should be able to do this relatively trivially, but I'm getting tired of hacking
this; I'll throw that in with the next set of changes.) The document menus also
recognizes "sibling", "child", "next", "end," and "last". Various
non-human-readable link types are filtered out. Adding links to the "Go" menu
will occur when I repackage this for inclusion in the mainstream chrome.
For those in the viewing audience who want to know how to install, just pop the
.jar into your chrome directory.
On to HTTP headers!
Comment 190•23 years ago
|
||
> Latest changes: <URL:http://www.stwing.upenn.edu/~choess/linktoolbar.jar>
> has been updated again.
I downloaded and installed that JAR, but it doesn't contain the changes you
described. HTTP HEAD shows that linktoolbar.jar was updated Wed, 20 Jun, but a
diff shows it identical to the linktoolbar.jar I grabbed on Tue, Jun 19.
FYI, I've been modifying linkToolbarOverlay.xul and linkToolbarOverlay.js
myself. Not sure what I'll do with it when I'm done, since I've already broken
several "hacker" rules by changing the line terminator, indentation, and braces.
I'm currently doing some refactorings to "Replace Switch with Polymorphism" and
"Replace Conditional with Polymorphism" since I'm an OO-head. I guess I could
just release it as a competing JAR...
Comment 191•23 years ago
|
||
Has adding the stylesheet selector been talked about and discarded? (Bug 6782
deals with this.) I think that putting it with the rest of the <LINK> tags would
be a good idea. I actually want a full menu thing in the toolbar, but that's not
going to happen.
Comment 192•23 years ago
|
||
There is already an alternate stylesheet UI, under the View menu.
Comment 193•23 years ago
|
||
Tim T.: it should be good now. I uploaded the new jar to my home directory
rather than my web page by mistake. I'm afraid your hacking may be for naught,
as I've gutted a lot of the parsing code and replaced it. It's pretty ugly code
right now, but I'll clean it up as I keep working.
Peter: I was planning to leave the stylesheet selector in the menus; you don't
really browse to a stylesheet like these other links, you load it.
Tim L.: My UI concerns WRT the dynamic toolbar were because I know one of mpt's
pet peeves is UI where items appear and disappear. It may confuse users when
they resize their screen and some buttons disappear. I think with the current
scheme, that's less of a problem, anyway.
One other thing I thought of, once this bug gets done, is to file a bug against
Evangelism to promote it. I.e., see if they can arrange some
developer.netscape.com articles or material elsewhere so people know how and why
to use <link>.
Comment 194•23 years ago
|
||
Christopher: OK, I completely understand the concern of UI element disappearing
or moving without reason. But if you shrink your window enough that the
buttons fall off the right hand side, they "disappear" anyway. Putting those
options in a menu keeps them accessible, at least.
But I'm starting to believe that the 20 (or so) LINK types we'd want accessible
is just far too many to fit individually on a toolbar. We should probably make
the couple most useful individual buttons, and group the rest as logically as
possible in menus, as you suggested.
In addition to displaying the rel type and title in the menus, the lang
attribute would also be useful for rel=alternate. Maybe instead of
saying "Alternate: TheTitle (Spanish)" it could say "Spanish: TheTitle".
The evangelism idea is great. There are several resources already online, like
Tekelenberg's. I'd bet he'd add Mozilla screenshots when this is ready.
Comment 195•23 years ago
|
||
Comment 196•23 years ago
|
||
I've added Christopher's latest linktoolbar.jar as an attachment. To try it
out, download the attachment to <your-mozilla-dir>/chrome/linktoolbar.jar. Be
sure to specify the filename or you'll end up with a file named
"showattachment.cgi".
Comment 197•23 years ago
|
||
Shouldn't this work on MacOS (9.1 D and Build ID: 2001061308) as well?
I tried with each 'chrome' directory sherlock finds on my disks, even created a
new user to get fresh prefs and put it in this user's chrome directory. No extra
toolbar arises :-(
BTW which _should_ be the right directory? There is at least one active chrome
in the programm's folder and in the documents folder:
Mac-HD:Mozilla:Profiles:Michi 3:wozyjwbl.slt:US:chrome:linktoolbar.jar
Mac-HD:Internet:Internet Programme:Mozilla:Mozilla Folder:chrome:linktoolbar.jar
Assignee | ||
Comment 198•23 years ago
|
||
Wow, you people have been busy, I'm merging the changes of Christopher Hoess'
version into my own that has a few UI functionality improvements.
Just to weigh in here I am returning the "contents" and "index" links. I feel
it is very important to have a direct link back to both the contents and the
index of the current document you are in for quick lookup of information. In a
reference book I find myself often switching between the content of the book and
the index when searching for information, especially when there is no useful
search feature (W3C specs for example...)
This really is turning into a UI debate that should be carried out in the
newsgroups, we should probably move it there. Our primary focus here is to get
a working, commitable toolbar, not to debate about what links should and should
not be on it. Lets get this bug fixed _/*THEN*/_ file bugs against it to get
the set of links we want on it.
Comment 199•23 years ago
|
||
Comment 200•23 years ago
|
||
Eric: I'm afraid I've created some more changes to sort the "document" and
"author" menu and implement Tim L.'s suggestion for alternate/translation.
Sorry to spring this on you, but I was halfway through the fix when I saw your
update.
I agree that the discussion of exactly which buttons we should have should go to
the newsgroups: if someone sees mpt on IRC, could they solicit his opinion as well?
Do "UI functionality improvements" include "fixing that hidous breakage w/
Modern"? I don't know enough about XUL to know how to fix that. Also, was the
HTTP header code ever hooked up? I've had some trouble figuring that out...
(just wait till we get to Evil Link Tests 5 & 6).
The DTD for L10N isn't actually working right now, you have to put the DTD in
en-US.jar, so I figured I'd leave localization to the final packaging.
Glad to have you back, Eric.
Comment 201•23 years ago
|
||
Comment 202•23 years ago
|
||
Comment 203•23 years ago
|
||
Comment 204•23 years ago
|
||
Comment 205•23 years ago
|
||
I attached two versions of the GNU make manual. The first attachment is the
same as the manual published on GNU's website:
<http://www.gnu.org/manual/make/html_mono/make.html>
The second attachment is a modification to add REL attributes to the anchors in
the Table of Contents. There are 4 link elements and 131 anchor elements with
REL attributes, mostly divided into Chapter, Section, and Subsection. I used
both versions to test performance on documents with thousands of links and also
as a sanity check for the various linktoolbar UIs.
Lastly, I've attached my own rendition of a Link Toolbar along with a screenshot
for people who don't want to install the chrome. Here's a rundown of the
changes off the top of my head:
* rewrote most everything to use OO code that can easily accomodate
rearrangements of the toolbar, including changing items between buttons,
menubuttons, menus, or menuitems.
* UI improvements. Borrowed XUL and CSS from the Personal Toolbar, reused icons
from existing chrome.
* removed code that wasn't used (yet), like the HTTP header parsing.
* lazy initialization of the language dictionary. Not created until an HREFLANG
attribute turns up on a link element.
* added profiling code for time consuming methods.
Things that need improvement:
* The button icons I found are an improvement, but not good enough. It
shouldn't use the Home or Bookmarks icons. All icons should have variants for
hover, active, and especially disabled. It's difficult to tell when a button is
disabled if its icon doesn't change.
* It takes 2.2 and 1.6 seconds on a 750 MHz Athlon to process the GNU make
manual with and without REL attributes respectively. During that time the
browser is completely unresponsive. Ideally, the code to handle links would run
in a seperate thread. I have no idea if this is possible with just XUL and
JavaScript.
* The toolbar doesn't even start to get built until after the page has loaded
completely. On a slow connection it'd be faster to navigate by links in the
page instead of waiting for the toolbar to populate. Ideally the toolbar would
update incrementally as the document is loaded. No idea of the feasability of this.
* Removal of some kludged CSS selectors to get the styling to work. Need better
XUL-fu to do it right.
* Of course, support for LINK HTTP Headers :)
* automatically initialize the JavaScript link handling objects from the XUL.
Currently you have to mirror changes to the XUL in the JavaScript code. It's
only in one place, but it would be nice if you could just change the XUL for
things like:
+ move something into or out of the More menu
+ change a button to a menubutton or vice-versa
+ change a menu to a menuitem or vice-versa
and just have it work. Time spent building the menu handling objects is small
compared to handling a document with lots of links. A little more automation
probably won't impact performance noticeably.
Comment 206•23 years ago
|
||
Tim T.: Wow, what a change! I think you can fix the auto-generation from XUL
problem by doing a document.getElementsByAttribute("class", "button-toolbar
bookmark-item") to create a nodeList. Loop through the nodeList, trim the
preceding "link-" from the id of each element, and that value can
replace "top", "up", "first", etc.
Comment 207•23 years ago
|
||
[...]
> doing a document.getElementsByAttribute("class", "button-toolbar
> bookmark-item") to create a nodeList. Loop through the
> nodeList, trim the preceding "link-" from the id of each element,
> and that value can replace "top", "up", "first", etc.
Excellent! Oh how I wish that function existed in the DOM, then this would work:
function getChapterLinks() {
return window._content.document.getElementsByAttribute(
"REL", "Chapter");
}
FYI, I'm going to be away from my computer all weekend, so you won't be seeing
any activity from me on this bug until Sunday or Monday. First on my list is
making disabled variants of the icons and getting tooltips to work. Also adding
code to disable the More menubutton when all its children are also disabled.
That way an enabled More menu is an indicator that links are available. I'm not
sure of the usability implications of disabling a top-level menubutton. Right
now you have to open the menu just to determine if links are present. That's
gotta be poor usability as well.
Assignee | ||
Comment 208•23 years ago
|
||
Ok, I've incorporated all of Tim's changes into the link toolbar package (
http://segment7.net/mozilla/linktoolbar/index.html ). This URL will work for
those of you who have never installed the link toolbar before.
I've updated the logic for anchors which have no title. It now grabs all the
#text nodes in side the anchor and sets it as the label, see
http://www.w3.org/TR/1999/REC-html401-19991224/ for an example (chapters menuitem)
I've also attempted to get localization to work but I've had no luck. If
somebody wants to take a crack at it go ahead, I'll try again when people are awake.
You can turn the toolbar on and off via the View | Toolbars menu.
Assignee | ||
Comment 209•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 210•23 years ago
|
||
OK, here we go:
1st point: the toolbar should not be visible unless page has <LINK> elements.
I would guess that there is no way you are going to get this UI into Mozilla,
using up valuable vertical screen space, unless it's only visible when it's
necessary :-)
The underlining on the menu is wrong in Classic - it goes all the way to the
right.
The look and feel of this menu should be as close to the Personal
Toolbar's Bookmarks menu as possible.
We shouldn't be using the Home icon for Top - it's conceptually wrong.
I think you want double-headed arrows for First, Last and Top and single headed
for Up, Previous and Next. I think this is a common VCR-like idiom.
Disabling:
The icons should have greyed-out versions.
Those toolbar items which are greyed out should not underline on mouseover.
"More" should be greyed out if it's empty.
The arrows on Next and last should be to right of text, and you should have a
vertical bar in the centre, like on the Personal Toolbar to the right of Home.
Rough ASCII art:
H Top ^ Up | <- First < Previous | Next > Last -> | X More (X Bookmarks ? Help)
There needs to be at least one pixel less spacing between the icon and its text
than between adjacent buttons. Otherwise associating an icon with its text is
hard, because the buttons do not have raised edges.
"More" menu:
Things which are not present should be hidden, not greyed out.
Remember to hide the separator if you hide all the items in a section.
You should, in general, avoid separators with single items in each division.
"Appendices", "Glossaries", "Indices" should all change to the singular
(Appendix, etc.) and become standard menu items (rather than cascading
sub-menus) if the sub menu has a single item.
Similarly, if the Miscellaneous Menu has only one or two items, they should move
to the main menu. That might be a bit harder.
"Help" should disappear (see below) and the Authors/Copyright section should
move to the bottom.
I don't know what "Alternates" is - do you mean translations and stuff? If so,
how about "Other Versions"?
SubSections should be Subsections. There are no StudlyCaps in English ;-)
What about hotkeys? It would be cool to do Ctrl-Alt-Left Arrow to move to the
next logical page. Is that part of this bug?
I realise that we have to cater for those on 640x480 but I have a 1024x768
screen and there's a lot of wasted grey screen space. The default Personal
Toolbar is almost twice as wide. Can we not have this current layout for small
and a different layout for larger screens?
As discussed before, a Help button which appears if there's help, at the right
hand end, would be good. Also a Bookmarks menu like the Personal Toolbar one,
called "Page Bookmarks" for rel="bookmark".
Are there any W3C guidelines on how Chapter and Section rel links are to be
used? For example, in the testcase, you get a Chapter link and then Section
links inside it. It would be good to reflect this in the UI - as in, the Chapter
menu had submenus for each chapter listing the Sections (top element being
"Beginning of Chapter") and the Sections were submenus for subsections (if they
existed), top element being "Beginning of Section". See what I mean?
...
Chapters -> Chapter 1 -> Beginning of Chapter
... --------------------
Section A
Section B
...
Chapter 2 -> Beginning of Chapter
--------------------
Section Q -> Beginning of Section
--------------------
Subsection Q.A
Subsection Q.B
That'll do to be going on with :-)
Gerv
Comment 211•23 years ago
|
||
> "More" menu:
> Things which are not present should be hidden, not greyed out.
I *think* I disagree. I like that all items are visible. This is the way menus
work in the rest of Mozilla (and other applications). (Though I realize this
isn't a very good argument. :) )
Some comments:
If 'title's are available for a link, they should be displayed as a tooltip.
Unknown link types should IMNSHO not be recognized. See Antti Näyhä's comments
from 2000-07-0 for an explanation why. I have this problem at my Web site, e.g.
<URL: http://www.gratis-kvalitetsdataspel.org/omtalar/blocks-plus.html
>, 'schema.DC' and 'schema.AC' are displayed.
We need a new bug for this. It takes ages to load the page to see the latest
comments. We can call it 'Better UI for HTML2 "LINK" element' or something like
that. Or we can have a newsgroup discussion.
Comment 212•23 years ago
|
||
He's right. This bug is horrible. Resolving as dupe (to maintain dup chain) of
new clean bug 87428. Eric - hope this isn't a problem for you :-)
Everyone - if this bug is bugging you, feel free to remove yourselves from the
CC list of the new bug. Please do not add a comment when you do so, so that
people can filter the spam. Thanks.
Gerv
*** This bug has been marked as a duplicate of 87428 ***
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 23 years ago
Resolution: --- → DUPLICATE
Comment 213•23 years ago
|
||
Gervase Markham wrote:
> 1st point: the toolbar should not be visible unless page has <LINK> elements.
There are several comments posted above on this topic. Both sides
claim usability improvements. At this point, it would take a usability study
to prove who is correct. In lieu of such a study, working code trumps
comments :)
FYI, I agree with Tim Larson and favor the "always on" link toolbar.
> We shouldn't be using the Home icon for Top - it's conceptually wrong.
...
> The icons should have greyed-out versions.
Agreed. All the icons need several improvements. It would help out greatly
if someone would attach an archive containing improved icons. Things to
include:
* normal, hover, active (mouse button depressed), and disable icons for
all buttons and the More menu
* versions for Classic and Modern themes
Microsoft PowerPoint is the most common application I can think of that uses
first, previous, next, last style navigation.
> Those toolbar items which are greyed out should not underline on mouseover.
It works that way already. At least, it should.
> The arrows on Next and last should be to right of text
Currently, the buttons are using the personal toolbar styles. LINKs are
essentially predefined bookmarks, so it's appropriate to use the same
styling. I'll check if the personal toolbar styles include a button with an
icon on the right and see how it works.
> "More" menu:
> Things which are not present should be hidden, not greyed out.
Karl Ove Hufthammer wrote:
> I *think* I disagree. I like that all items are visible. This is the
> way menus work in the rest of Mozilla (and other applications).
> (Though I realize this isn't a very good argument. :) )
Adaptive menus have poor usability. Karl's argument /is/ a good argument.
UI consistency == good.
> "Appendices", "Glossaries", "Indices" should all change to the
> singular (Appendix, etc.) and become standard menu items (rather than
> cascading sub-menus) if the sub menu has a single item.
I considered doing this, but decided against it for the same reason that
adaptive menus are bad.
When UI elements move around or disappear the user gets confused. It also
prevents the user from becoming habituated to the interface. For instance,
they would have to perform a different gesture to get to the first chapter
depending on whether there was one or more than one chapter LINK.
This is the general argument against moving items into or out of the "More"
menu, or removing something instead of disabling it.
If your curious where these notions of consistency, adaptive menus == bad, and
habituation come from, do a search for "Jef Raskin".
> What about hotkeys? It would be cool to do Ctrl-Alt-Left Arrow to move to
> the next logical page. Is that part of this bug?
Good idea, create a bug for it :)
> I realise that we have to cater for those on 640x480 but I have a
> 1024x768 screen and there's a lot of wasted grey screen space. The
> default Personal Toolbar is almost twice as wide. Can we not have
> this current layout for small and a different layout for larger screens?
More != better. Sometimes more is worse. I tried putting Help on the toolbar
itself. I didn't like it for several reasons, one of which was clutter.
My goal was to use up no more horizontal space than the top menubar (excluding
the Debug and QA menus).
The problem of power users with high resolution monitors would be solved if
Mozilla toolbars worked like Internet Explorer toolbars instead of Netscape 4.x
toolbars. In other words, you could place two short toolbars side-by-side and
save vertical space. Someone's probably already created a bug for that enhancement.
> As discussed before, a Help button which appears if there's help, at the
> right hand end, would be good.
Like I said, I tried it out because enough people wanted it. Here's why I
decided against it:
0. clutter
1. no other menu, not even the top Help menu, works that way
2. putting Help on the toolbar will cause confusion between it and the
top help menu. I'm not convinced that putting it in a submenu is much
better. I'd rather call it something else, but nothing has come to mind
> Also a Bookmarks menu like the Personal
> Toolbar one, called "Page Bookmarks" for rel="bookmark".
0. clutter
1. "Page Bookmarks" is alot of horizontal real estate. I debated between
"Prev" instead of "Previous" to save space (I settled on avoiding
abbreviations), but "Page Bookmarks" is too long.
2. Bookmarks is on the "low utility" end of the scale, hence its position
deep inside the More menu
> Are there any W3C guidelines on how Chapter and Section rel links
> are to be used?
Not that I found. However, I didn't look hard. If someone turns up
something official please share.
> Chapters -> Chapter 1 -> Beginning of Chapter
> --------------------
> Section A
> Section B
> ...
[snip]
I agree that would be a better organization. Unfortunately, there is
nothing in the HTML spec to indicate those relationships. We could guess, but
we'd guess wrong alot of the time and display incorrect relationships. I
encourage someone to prove me wrong :)
Comment 214•23 years ago
|
||
Yeah, I realize it has moved to bug 87428, and I realize I'm supposed to discuss
in n.p.m.ui.. It annoys me each time people divert discussion to the
newsgroups, and, for what it's worth, I disagree with moving to a new bug, too.
I'd rather make progress than debate, so I'll be a good citizen and post to bug
87428 from now on. But not without saying good-bye first.
Twenty-eight hundred
Taken from us in your prime
Ian still loves you
Comment 215•23 years ago
|
||
Verifying, not the normal use for a duplicate but this page takes a while for to
load even over a cable connection so it'll be a pain for modem users.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 216•19 years ago
|
||
Good news boys: in the span of less than 3 months, Hixie managed to conceive of the <a ping>, slap it into a WHATWG draft, and land the patch with hardly any discussion. We've departed our long Ice Age and entered the brave new world of instant checkin. So if anyone wants to work on this <link> UI again, this time it might take slightly less than seven years.
Comment 217•19 years ago
|
||
Alternatively, you could help clav update the current extension so it works with Firefox 1.5...
http://extensionroom.mozdev.org/more-info/linktoolbar
If anyone is thinking of taking this up again, with a view to getting some UI permanently into Firefox, I would counsel that less is more. Don't think "how can I provide UI for all the possible uses of <link>", but "What simple UI would get the most bang for the buck and be useful to the average user"?
Gerv
You need to log in
before you can comment on or make changes to this bug.
Description
•