Package: lynx-ssl Version: 2.8.4.1b-3 Recently, debiandoc-sgml in woody started generating <link href="..."> tags at the start of pages. This was quite annoynig for the user of links and lynx-ssl, but OK for the uses of w3m, galeon, and evil-IE. After a chat with Ardo van Rangelrooij <ardo@debian.org>, we came to the conclusion that these tags are becoming standard thing and links and lynx must handle them reasonabbly. I personally think these shell be the optional content to be displayed by specifying some command line option. You may differ with me on above strong comment but at least these shall be some way of turning on/off these links. To see the effect, please see page like: http://qref.sf.net/quick Though I report on ssl enabled packages, I think this is general issues with these program. I see the same problem with cygwin lynx :) Thanks Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii links-ssl 0.96.20011222- Character mode WWW browser with SSL ii lynx-ssl 2.8.4.1b-3 Text-mode WWW Browser supporting SSL
Package: debiandoc-sgml
Version: 1.1.59
Severity: wishlist
Please make the generation of <link href="..."> tags in <head> ...
</head> section of html files to be selectable by a command-line option
because of the following reasoning. Also cyclic page pointer at the top
of html should also be selectable. (CCed to the affected package
maintainers.)
---
Recent improvement in debiandoc-sgml started generating new tags at the
<head> ... </head> section of html file. This causes annoying effect
when these pages created from a large sgml source is viewed by browsers
such as "lynx" and "links", i.e., first few pages of each page are just
"href" links.
Good example web page is: http://qref.sf.net/quick/index.en.html
("links" starts at page 13 so pressing the "HOME" key is nightmare)
Though this is a problem with the browsers (bug report #138240 and #138241)
and not a problem with mozilla/galeon/w3m, I think debiandoc-sgml shall
offer some kind of remedy considering woody is in practical freeze mode
and these browsers will be released in this state.
For cyclic tag, since we have [1] ... links at the top of pages seen by
"galeon" and "w3m", I do not know how useful it is.
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii debiandoc-sgml 1.1.59 DebianDoc SGML DTD and formatting tools
[...] links or lynx, because text mode browsers take teh approach to visualise everything could be visualised, then providing non-visual data to the user in a form they feel appropriate. Both browsers approach the question as "we won't hide information possibly useful to the user", and I believe this is what happens: the information is showed, because browser cannot decide whether user needs it or not. Graphical browsers usually handle these differently, some may even use this info to visualise the links/references, create a toolbar or whatever goodies they come up with. I don't think hiding this would be easy, because there are plenty way to embed informations into html and the browsers cannot guess which one does the user need and which one doesn't. Hiding useful info is usually not an option here, graphical browsers aren't for the ignorant average Joe. :-) Uh, what't the goal of those anyway? Does any browser use it? Peter
Peter, I understand you are "links" guy :) I thank you a lot for maintaining nice package. I feel some gap with you. "appropriate" is good guide line, though. Please read on and reconsider the situation. First, updates on the situation. 1. After discussion with Ardo (debiandoc-sgml upstream and package maintainer), Ardo agreed to make generation of <link ...> tag as optional feature since woody release is near and it is very unlikely to get popular browsers to be friendly to these tags before the release. Currently, creations of <link ...> tags are optional and enabled only by the command line option "-L". So those bug reports (#138240 and #138241), we do not expect any actions from their maintainers before the woody release. We both agreed, generation of these tags are GOOD things since it can be used by browser effectively as index etc. 2. What is really happening with "links" and "lynx" In case of "Debian reference" created by debiandoc-sgml with -L option, you get followings: Link: start Link: prev Link: next Link: contents Link: copyright Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: chapter Link: appendix Link: appendix Link: appendix Link: appendix Link: section then there are 17 page long repeats of just Link: section before seeing any real contents. This is the effects of <link..> tag. Besides, those links was not so useful without proper display of "title". "lynx" does print "title" but 11 pages of them without any formatting was pain. My request should be understood as a request of data presentation format and choice given to the user. At this moment, "links" and "lynx" force users to see long practically useless representation of <link ...> tags on certain web pages whose authors expect them to be shown in separate window or such. User has no choice to turn it off. That is the issue. Yes. Same can be said for console browsers. Turning their display by command line option (or key command) is a practical feature to have. "Useful" if only they are presented in a reasonable manner. You do not display information in <!-- ... --> unless you display sources in these browsers. Discussion of displaying these hidden links shall be something similar to how we should handle comments and chose not to show them in normal display but display them in the source display. Good point. I do not know. :( I think having index side-bar is natural use of them.
-- _An official winning notification has been sent to you Google Cooperation INC, Kindly download attachment for more information:_ _Sincerely,_ _ _ _Monica Marchese Swinerd_ _Director Google Senior Fellow/Artificial Intelligence_