W3C home > Mailing lists > Public > www-html@w3.org > July 1998

Re: visiting named anchors (was Re: Ah! Another HTML query!)

From: Brian Kelly <lisbk@ukoln.ac.uk>
Date: Wed, 22 Jul 1998 17:05:52 +0100
Message-ID: <02b901bdb58a$9a629c30$3c92268a@ulpc-bk-fire.bath.ac.uk>
To: "John T. Whelan" <whelan@physics.utah.edu>, www-html@w3.org
Cc: dagan@upf.es, gwalla@hotmail.com, tpscan0@sac.uky.edu
Sounds to me like this discussion on the preferred user agent behaviour for
visiting named anchor should be generalised into user agent behaviour for
processing XML document using XLink [1] and XPointer [2].  Behaviours for
user agents processing HTML would then be a subset of this.

So, for example, how should the user agent process a link to a portion of an
XML document (give me only section 2 to section 4)?  How should a user agent
indicate that a link is only to a portion of a document?  How should a user
agent indicate that a document has been visited  / an internal anchor in a
document has been visited / a portion of a document has been visited?  How
should a user agent indicate that the document will be displayed inline / as
new window / replace current document?

Are there are discussions on these topics, or will this be left to the
software vendors to decide?

Brian Kelly


[1] http://www.w3.org/TR/1998/WD-xlink-19980303

[2] http://www.w3.org/TR/1998/WD-xptr-19980303
Brian Kelly, UK Web Focus
UKOLN, University of Bath, BATH, England, BA2 7AY
Email:  b.kelly@ukoln.ac.uk     URL:    http://www.ukoln.ac.uk/
Homepage: http://www.ukoln.ac.uk/ukoln/staff/b.kelly.html
Phone:  01225 323943            FAX:   01225 826838
-----Original Message-----
From: John T. Whelan <whelan@physics.utah.edu>
To: www-html@w3.org <www-html@w3.org>
Cc: dagan@upf.es <dagan@upf.es>; gwalla@hotmail.com <gwalla@hotmail.com>;
tpscan0@sac.uky.edu <tpscan0@sac.uky.edu>
Date: Wednesday, July 22, 1998 5:48 PM
Subject: visiting named anchors (was Re: Ah! Another HTML query!)

>>> In MSIE and Opera, user's history has to do with "pages visited"
>>> not with "anchors read". Their implementaion is consistent and
>>> not confusing.
>>Again, "not confusing" is very subjective.  I am not confused by NS's or
>>IE's implementation of the named anchors, although I agree that most new
>>users could be.  It would seem that perhaps these named anchors would make
>>more sense if they were marked as read only when they are directly linked
>>to, or when they are in the viewable "window" for more that a certain
>>amount of time (to eliminate the scroll by problem mentioned above).  I am
>>beginning to believe that the "basic unit" of HTML is not the page, but
>>the smallest single unit of content and therefor the entire page should
>>not be marked as visited if I only visit a named area in the middle.
> Of course, any of these proposals have got to be much harder
>to implement than either of the existing conventions.  Either NS's or
>IE's method can tell whether you've visited a link by examining the
>URLs in your browsing history (NS by checking for the exact URL and IE
>by checking for the URL, give or take a name anchor).  Making
>visited-ness of a link dependent on what parts of a page the user has
>scrolled through has got to involve a whole other type of overhead.
>Do we really think it's worth the extra overhead to add this
>specialized feature?
> (Disclaimer: the preceding was based only on intuitive logic
>and not any knowledge of how these features are actually coded into
>the browsers.)
>>That could be fixed though.... speaking of which, why should the
>>whole page load if you are only linking to that named part?  I didn't want
>>to read the other stuff, so why should I wait for it to load?
> This is an unfortunate feature, especially for those of us in
>14.4-land, but I think it's unavoidable.  The browser doesn't know
>where the named part of the page is until it gets to the appropriate
>anchor tag, so it has to download the document until it finds it.  To
>start downloading it in the middle, a browser would have to know where
>to start, and that would require some sort of information in the HTTP
>header about how far into the file the anchor is.  For that matter,
>the server would have to cooperate even further by not transmitting
>the beginning of the file (or transmitting it at the end), so it's
>really a feature that would have to be built into servers as well as
>browswers.  Then there's the whole problem of whether you've missed a
><TABLE> or <DIV> earlier in the document that will affect how the text
>you've linked to is rendered.  So the only way anything like this
>could come about is if the page originated on a server that did some
>serious SGML parsing before it transmitted any document linked to with
>a name anchor.  I suppose Netscape would be able to design the
>browser-server partnership to do this, but building incremental
>rendering of tables into their browser would seem a better use of time
>and effort.
> John T. Whelan
> whelan@iname.com
> http://www.slack.net/~whelan/
Received on Wednesday, 22 July 1998 12:07:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:48 UTC