tooltips make source code unreadable for text-only browsers (lynx)

[jwaldmann]

Tooltips for type classes in "deriving (Show, Eq)" make it impossible to read source code in text-based browsers (lynx, w3m).

See this thread https://mail.haskell.org/pipermail/haskell-cafe/2020-November/132933.html

The example given in the message is (similar to)
https://hackage.haskell.org/package/isbn-1.1.0.2/docs/src/Data.ISBN.Types.html#line-19

Related: #715

[sjcjoosten]

In case you're looking to see what does and doesn't work in Lynx:
https://sjcjoosten.nl/tmp/test.html

Most of what should work (according to standards) does not, only JavaScript seems like a reliable way of hiding things from Lynx. Showing things to Lynx that don't show up in a regular browser is much easier.

I see two ways to solve the issue:

1. generate two different pages, one for Lynx users and one for non-lynx users
2. use JavaScript to render non-lynx content. Create a per-user setting on whether such content should be rendered on hover (default), click, or never, and store it in a cookie that can be set by screen reader users that have JavaScript enabled (this option would possibly be hidden to users without screen readers).

Option 1 means generating an extra set of files (for ransom-note colored source-code that allows links to the definition but does not have fancy tooltips).
Option 2 means giving up tooltips for people who have JavaScript.This might, on the other hand, help reduce file size of the generated file-with-tooltips (still an issue here).

Hiding stuff from Lynx in ways other than JavaScript is, afaik, not possible. Lynx doesn't follow the standards and decides to show everything instead, for a (good?) reason: most pages don't test for Lynx, so Lynx will render as much as possible just to increase the chance of the user being able to see what it was looking for, at the expense of displaying stuff that the user didn't wish to see (an example: if the page has a form in which fields are hidden until an event elsewhere unhides it later, lynx users would want to see those hidden fields to they can fill them in; lynx does not do dynamic unhiding so the fields have to be there from the start).

Following option 2 and using JavaScript might also help with an issue mentioned here: #1197 namely that the file size can become very large and have rendering issues. An example is that this page http://78.47.113.11/docs/html/libraries/ghc-prim/src/GHC.Classes.html does not fully load for me in Safari or Chrome, and it loads incorrectly (I think) in FireFox.

If losing tooltips for no-JavaScript users is considered a sacrifice worth making by haddock's project owner(s) (btw, who is that?), then I'd be happy to help out.

[harpocrates]

Although it would very much be desirable to for Haddock to work well with Lynx, we should focus on solutions that

• do not introduce more options (or significantly more code) to Haddock
• don't compromise the feature set or experience for graphical web browsers

Option 1 seems like it would end up being a significant maintenance and runtime burden for a relatively small payoff. Also, it is already possible to swap out hyperlinked sources for highlighted sources generated in some other way, see the various --source-* options. HsColour can help generate sources which I think would be Lynx friendly.

  --source-base=URL
  --source-module=URL
  --source-entity=URL
  --source-entity-line=URL

As for option 2, switching from CSS to JavaScript seems like a step backwards. As you say, this would means that no-JavaScript users (who I suspect form a larger share of users than Lynx) would no longer be able to use the tooltips. If a JavaScript rewrite was to fix some other significant performance issues, the change would be a lot more palatable. Note that the PR you linked was WIP - the equivalent page on Hackage loads quite nicely on Safari, Chrome, and Firefox (and has tooltips too). I struggle to keep up with web best practices, but my understanding is that CSS-driven solutions are preferred whenever possible to JavaScript since their declarative nature enables more efficient and parallelized processing by the browser.

Is there really no way to teach Lynx to hide elements with display: none? Or some other Lynx-specific hiding functionality?

[sjcjoosten]

I agree that there will be more no-Javascript user than Lynx users (in part because all lynx users are no-javascript users). I recognize that I linked to WIP, and you are correct that the consensus is that CSS driven solutions are more preferable to JavaScript based ones. Lynx ignores CSS display:none, but I'll keep looking

[sjcjoosten]

Found a way!

https://sjcjoosten.nl/tmp/test3.html

Displays in lynx as:

Trying to use the COMMENT tag for a tooltip

Source of that page:

<html lang="en" class=""><head>
  <meta charset="UTF-8">
  <title>Testing ways of hiding text</title>
<style>
  comment{display:none;position:absolute;}
  .hasTooltip:hover>comment{display:block;position:absolute;background-color: yellow;}
</style>
</head>

<body>
<P>Trying to use the <SPAN class="hasTooltip">COMMENT<COMMENT>Tooltip!</COMMENT></SPAN> tag for a tooltip</P>
</body></html>