- From: John T. Whelan <whelan@physics.utah.edu>
- Date: Wed, 22 Jul 1998 09:46:54 -0600
- To: www-html@w3.org
- Cc: dagan@upf.es, gwalla@hotmail.com, tpscan0@sac.uky.edu
>> 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 11:46:37 UTC