[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev What the heck is up with this?
|
From: |
Klaus Weide |
|
Subject: |
Re: lynx-dev What the heck is up with this? |
|
Date: |
Sat, 1 May 1999 09:38:18 -0500 (CDT) |
[Cc'd because I'm sorting out mail problems.
If anyone sent me mail directly in the last few days, you may want
to re-send it to <address@hidden>, it may have gotten lost.]
On Fri, 30 Apr 1999, John Bley wrote:
> Here's an html file:
> <html>
> <head>
> <link rel="bookmark" type="text/html" href="s.html">
> <link rel="start" type="text/html" href="s.html">
> <title>Hi</title>
> </head>
> <body>
> hi
> <a href="foo.html" title="foo">foo</a>
> <a href="foo.html" title="bar">bar</a>
> </body>
> </html>
>
> Load it up in lynx. Displays nicely, doesn't it? Hit the 'l' (lowercase
> L) key, or your LYK_LIST binding. Try repeating this with the hrefs of
> each set pointing to two different destinations.
>
> Why does this happen?
Because the place where an A's title, or a LINK's title or rel value,
is recorded in the destination's HTParentAnchor object and nowhere
else[*]. Essentially the title is handled as a property of the link
destination, not of the link itself (for A as well as LINK - with
non-copitalized 'link' I mean the more general sense that includes
both).
Also a title, set in one of these ways from an attribute, competes
with the TITLE *element* in the target (if it is text/html) when
that is loaded.
Normally in most cases this is ok since you don't have multiple links
of different kinds pointing to the same destination. It's just those
test cases...
It seems to me the decisive but straightforward way to resolve these
ambiguities is to treat title attributes (and equivalents) as properties
of the link, i.e. record them in the HTLink struct (see HTAnchor.h).
Add a title string, i.e.
typedef struct {
HTAnchor * dest; /* The anchor to which this leads */
HTLinkType * type; /* Semantics of this link */
char * title; /* title attribute from LINK or A */
} HTLink;
The only reason I can see against this is that there may be a great number
of HTLink's in memory (and scattered all over it), increasing the size
by 4 or 8 bytes that are mostly unused may have some run-time impact.
You can see in the code my recent attempt to do this more half-heartedly
(conservatively) for *some* link types, by adding title info to the
(mostly unused) HTLinkType. If you tested with say "chapter" and "up"
instead of "bookmark" and "start", you should see something different.
> In showlist(), there's a loop over the child anchors of the current doc,
> which means that essentially we're doing this:
> foreach ("bookmark link" "start link" "foo link "bar link")
> OK, so then we figure out the destination of the current child, "dest",
> and now, we need to figure out the title of this child anchor, so what do
> we do?
> parent = HTAnhor_parent(dest);
> title = HTAnchor_title(parent);
>
> Why isn't the destination's parent's title the same as the child's title?
> Is this an assumption that the destination only has one parent (whatever
> it means for a destination to have a parent)?
> Why doesn't the child anchor have a title?
Because 'title' is not an element of a 'HTChildAnchor' struct.
> This code:
> title = HTAnchor_title(child);
> segfaults.
>
> I'm really at a loss to understand this.
I don't blame you... To really understand the HTAnchor / HTParentAnchor /
HTChildAnchor stuff, you have to spend some time in HTAnchor.c.
But essentially a HTChildAnchor is only a minimal version of HTAnchor,
for use as link source and destination points (and not much else).
All the interesting info about a link dest is in the HTChildAnchor's
'parent', which stands for the full document/resource.
A HTParentAnchor represents (more or less) a full URL:
http://localhost/something.html
A HTChildAnchor represents a location in a resource, which may or may
not have a name:
- if there is an associated name
http://localhost/something.html#name
- if there is no name (a link source without ID= or NAME=), you can
view it as treated the same as
http://localhost/something.html#
A HTAnchor is just a less-specific 'superclass' that is never used
directly, (HTAnchor *) pointers always point to either a HTParentAnchor
or a HTChildAnchor. (And which case you're dealing with can be seen
by looking at the 'parent' element, which always points to a
HTParentAnchor.)
> My first guess at a solution
> would be to add "title" to HTChildAnchor, and then figure out where/how
I don't agree. It may actually appear to solve the problem, but not
in all situations. I think what you logically want is make the title
a property of the link itself.
> to set it (it's displaying the right thing initially, so the data's in
> there somewhere). But this would be an awful hack if there is a deeper
> mystery to the HTAnchor code that I just don't get. Any
> ideas from anybody who does understand this code?
HTH,
Klaus