Re: [Haskell-cafe] Reading Haddock sources on hackage no longer possible with simple browsers?

I recently noticed that it is no longer possible to read the source of a module, because extra type information (which is likely hidden in a modern browser) is inline with the actual sources.
I confirmed your example, reading with lynx and w3m. It seems the extra text is the methods of the type classes (mentioned after "deriving") and it gets shown on on mouse-over in a graphical browser. (Re: "nobody writes code like this" - the compiler does? Some methods here seem auto-generated.) Looks like a bug in haddock, then? (Or in lynx' handling of CSS?) The actual HTML source looks legit, at least partially (see example below) This seems related: https://github.com/haskell/haddock/pull/1197 I will open an issue on accessibility. - J.W. <span class="hs-keyword">deriving</span><span> </span><span class="hs-special">(</span><span id="local-6989586621679046279"><span id="local-6989586621679046281"><span id="local-6989586621679046283"><span class="annot"><span class="annottext">Int -> ISBN -> ShowS [ISBN] -> ShowS ISBN -> String (Int -> ISBN -> ShowS) -> (ISBN -> String) -> ([ISBN] -> ShowS) -> Show ISBN forall a. (Int -> a -> ShowS) -> (a -> String) -> ([a] -> ShowS) -> Show a showList :: [ISBN] -> ShowS $cshowList :: [ISBN] -> ShowS show :: ISBN -> String $cshow :: ISBN -> String showsPrec :: Int -> ISBN -> ShowS $cshowsPrec :: Int -> ISBN -> ShowS </span><span class="hs-identifier hs-var hs-var hs-var hs-var hs-var hs-var hs-var hs-var">Show</span>

Hello, This is indeed by design - it is a relatively new Haddock feature (here’s the original issue https://github.com/haskell/haddock/issues/715) where types of identifiers and identifiers bound are shown on mouse-over. Here is what this looks like in a graphical browser: As for the the weird declarations like $cshowList and company, this seems to be a bug - Haddock should not display those identifiers. Although I’m sympathetic to the accessibility, in this case wouldn’t just directly opening the sources (in a text editor) be simpler? Is there a (simple) way to preserve the experience when browsing using Lynx without also holding back features aimed at a regular browsing experience? Alec
On Nov 14, 2020, at 1:01 PM, Johannes Waldmann
wrote: I recently noticed that it is no longer possible to read the source of a module, because extra type information (which is likely hidden in a modern browser) is inline with the actual sources.
I confirmed your example, reading with lynx and w3m.
It seems the extra text is the methods of the type classes (mentioned after "deriving") and it gets shown on on mouse-over in a graphical browser.
(Re: "nobody writes code like this" - the compiler does? Some methods here seem auto-generated.)
Looks like a bug in haddock, then? (Or in lynx' handling of CSS?) The actual HTML source looks legit, at least partially (see example below)
This seems related: https://github.com/haskell/haddock/pull/1197
I will open an issue on accessibility.
- J.W.
<span class="hs-keyword">deriving</span><span> </span><span class="hs-special">(</span><span id="local-6989586621679046279"><span id="local-6989586621679046281"><span id="local-6989586621679046283"><span class="annot"><span class="annottext">Int -> ISBN -> ShowS [ISBN] -> ShowS ISBN -> String (Int -> ISBN -> ShowS) -> (ISBN -> String) -> ([ISBN] -> ShowS) -> Show ISBN forall a. (Int -> a -> ShowS) -> (a -> String) -> ([a] -> ShowS) -> Show a showList :: [ISBN] -> ShowS $cshowList :: [ISBN] -> ShowS show :: ISBN -> String $cshow :: ISBN -> String showsPrec :: Int -> ISBN -> ShowS $cshowsPrec :: Int -> ISBN -> ShowS </span><span class="hs-identifier hs-var hs-var hs-var hs-var hs-var hs-var hs-var hs-var">Show</span>
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Alec Theriault
Although I’m sympathetic to the accessibility, in this case wouldn’t just directly opening the sources (in a text editor) be simpler?
Following a link to a definition is convenient because there is an anchor. Of course I can just open the original sources in a text editor. But then I am no longer reading documentation, I am reading sources!
Is there a (simple) way to preserve the experience when browsing using Lynx without also holding back features aimed at a regular browsing experience?
I was expecting this sort of killer argument. I have to admit I am too exhausted with this topic to try and give a meaningful answer. There used to be a time when compatibility to existing technology was a goal by itself. This is going away even in circles which usually have tried to achieve some sort of technical excellence. I am sad. But I can not do anything against the tides except for sometimes pointing at ships while they are sinking, hoping to get someone to see reason and rescue at least some of them. Practically speaking, the problem is the visibility style attribute. As far as I know, none of the text browsers (lynx, w3m, elinks, eww) have CSS support. Barring any other HTML construct which would allow to hide things by default for text browsers, all I can think of a plain version in addition to a hip version. That should be easy to autogenerate, but it has all the problems attached to a alternative version. -- CYa, ⡍⠁⠗⠊⠕

(Neglected to CC haskell-cafe, sorry Mario for the duplicate.)
The only plain-HTML solutions I’m aware of are the ‘title’ attribute and
the HTML5 ‘<details>’ element. The latter may contain a ‘<summary>’ element
for the content displayed by default, plus other content that the user can
expand or collapse. Unfortunately, as far as I know Lynx doesn’t support
either of these; not sure about other text browsers. In Lynx you could
maybe get some nice UX for this with the ‘<fn>’ footnote element from HTML
3.0, but that’s deprecated and probably not supported in other browsers.
It doesn’t help with Lynx support, but I guess the right thing to do here
for screenreader support in other browsers is to add the ‘tooltip’ role to
the tooltip element, toggle its ‘hidden’ attribute with JavaScript to show
and hide it, and use ‘aria-describedby’ / ‘aria-expanded’ on the anchor
element to handle relating the two and announcing the tooltip correctly
when it’s shown.
On Sat, Nov 14, 2020 at 4:20 PM Mario Lang
Alec Theriault
writes: Although I’m sympathetic to the accessibility, in this case wouldn’t just directly opening the sources (in a text editor) be simpler?
Following a link to a definition is convenient because there is an anchor. Of course I can just open the original sources in a text editor. But then I am no longer reading documentation, I am reading sources!
Is there a (simple) way to preserve the experience when browsing using Lynx without also holding back features aimed at a regular browsing experience?
I was expecting this sort of killer argument. I have to admit I am too exhausted with this topic to try and give a meaningful answer. There used to be a time when compatibility to existing technology was a goal by itself. This is going away even in circles which usually have tried to achieve some sort of technical excellence. I am sad. But I can not do anything against the tides except for sometimes pointing at ships while they are sinking, hoping to get someone to see reason and rescue at least some of them.
Practically speaking, the problem is the visibility style attribute. As far as I know, none of the text browsers (lynx, w3m, elinks, eww) have CSS support. Barring any other HTML construct which would allow to hide things by default for text browsers, all I can think of a plain version in addition to a hip version. That should be easy to autogenerate, but it has all the problems attached to a alternative version.
-- CYa, ⡍⠁⠗⠊⠕ _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
participants (4)
-
Alec Theriault
-
Johannes Waldmann
-
Jon Purdy
-
Mario Lang