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

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

References

[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