Author: Heikki Toivonen
$Date: 2001/03/22 23:51:47 $ $Revision: 1.2 $ $State: Exp $
Link Manager Design Documentation
Link manager is a component that can recognize links and knows where a link can end. For HTML a links, simple XLinks and the like, a link manager is not really needed as a single element will have all the necessary information about the link. For extended XLinks (or other arbitrary links) a link manager is a necessity. Extended XLinks can define a link in different place than the link starting element, the link can be bidirectional, there can be several link ends, there can be restrictions on the traversal and so on. And in fact, the link start and end need not be complete elements - they can be regions of text or just about anything.
Because links can have multiple ending resources, the simple :visited etc. CSS styles will not be completely accurate. Should a starting resource be marked :visited if only some of the ending resources have been visited? Or do we need a new pseudo style, :partly-visited?
Below is an illustration of a situation with extended links. Document C defines one link. The starting and ending resources are in documents A and B. There are two starting resources in document A, and two ending resources in document B. Additionally part of the other ending resource is also a starting resource.
We can have the link define traversal rules as follows:
- Starting resource 1 can lead to ending resource 1 or 2
- Starting resource 2 can lead to ending resource 1
- Starting resource 3 can lead to ending resource 1
Legend:
- Starting resource 1
- Starting resource 2
- Ending resource 1
- Ending resource 2
- Starting resource 3
| Document A | Document C Defines the links, the starting and ending resources in documents A and B |
Document B |
|
<p>Let there be <span>light</span>.<p> <p>Click!<p> |
<p>And <span>night</span> came.<p> <p>Good night!<p> |
The above example makes it clear that we must be able to style and detect click regions other than elements. Range lists can hold that kind of information. Also the CSS pseudo style :link must be expanded to work for arbitrary ranges. The example also illustrates that there must be some visual indication of what exactly is the ending resource. CSS3 offers help here, but even simpler way is to make link traversal select the link target. Finally, when a link can lead to more than one ending resource there must be a way for the user to select the ending resource. One way would be to pop up a menu listing the possible ending resource URLs and/or showing some content from the ending resources.
Link manager can also offer optimizations for simple link handling cases.
Architecture
The link manager is a document observer. This means that it will be notified when a document loads, changes and unloads. The link manager has a link database that contains information about all the links defined in documents that are currently loaded.
Interested parties can register as link observers (on the link manager). They can observe all starting and/or ending resources, or starting and/or ending resources in a document, or a single starting and/or ending resource, or all starting and/or ending resources where an element participates.
Alternatively, the link manager could listen to document load, unload and mutation events in order to keep its link database up to date. It could also send events about link changes to link event listeners.
Finally, interested parties could explicitly ask the link manager about links.
Below is an illustration that combines observer architecture with questions that interested parties can ask from the link manager:
+--------------+ +----------+
| Style System | - - - - - - - - - - - - - - - - - - - - - - - ->| Element |+
+--------------+ +- - -+----------+|
| | +----------+
| |
|[1] [2]| |
| |
| | |
| +---------------------+<- - - - - - -+ +-----+----+
+------------>| Link Manager |-------------------->| Document |+
+---------+-----------+ Observe +----------+|
| +----------+
|
|
/------\
| Link |
| DB |
\------/
Legend:
[1] Observe("all starting resources in all documents")
GetStartingResources(in node, out linkidlist)
GetStartingResourceRangeList(in linkid, out rangelist)
GetEndingResources(in node, out linkidlist)
GetEndingResourceRangeList(in linkid, out rangelist)
[2] Observe("all starting resources where the element participates")
GetStartingResources(in node, out linkidlist)
GetEndingResources(in node, out linkidlist)
GetStartingResourceRangeList(in linkid, out rangelist)
GetEndingResourceRangeList(in linkid, out rangelist)
[3] GetStartingResources(out linkidlist)
GetStartingResourceRangeList(in linkid, out rangelist)
GetEndingResources(in node, out linkidlist)
GetEndingResourceRangeList(in linkid, out rangelist)
--- Required relationship
- - Optional relationship (optimization)
The solid lines show the required relationships. The dotted lines represent a chance of optimization: an element could Observe links that overlap with its area and cache the values so that it can answer quickly when queried about link properties.
The diagram is missing the link handler components, i.e. how do we make link interaction happen. Currently an element knows if it is a starting resource, and will respond to mouseover and click events by calling the link handler (nsILinkHandler).