[jdjb]

And yet the whole thing doesn't load if you block javascript. No content at all.

[cbd1984]

So goodbye to accessibility.

[wirrbel]

how does this reduce accessibility? javascript interpreters are not hard to find nowadays.

[easytiger]

There are in fact a huge number of both usability and accesability issues with this that do not exist with the original:

http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html

[wirrbel]

does javascript reduce "accessibility" as in: does it keep average users and handicapped users from accessing the pages?

The usual texinfo output is probably more accessible from a technical standpoint, but from a usage perspective it is not.

Markup formats like ReST/Sphinx are much more semantic and improve accessibility for the impaired as well. Simple JS is not the problem here.

[easytiger]

> The usual texinfo output is probably more accessible from a technical standpoint, but from a usage perspective it is not.

Can't possibly agree with that. Slap a fancy clean font on it and it prob solves half the issues people have with it.

From a usage perspective this page is crippled compared with the original.

> does it keep average users and handicapped users from accessing the pages?

If the third part tools they need to navigate and consume the content stop working, then yes, yes it does.

[_ak]

Bullshit. Modern screenreaders in browsers directly look at the visible parts of the DOM.

Wilfully turning off Javascript in the browser is not an accessibility issue.

[easytiger]

Well the content is loaded dynamically so that is going to screw a lot of utilities up.

[elmerland]

That's right, this was intentional. The content is loaded dynamically. I thought this would help with mobile users, to reduce the amount of data used.

[xorcist]

I am actually on mobile, and the biggest problem on mobile is spotty coverage. I click stuff and there is a slight animation but no more data shows.

I have no idea if that was because a TCP connection broke, or if this is just a design concept and the actual data is missing. I have to reload the whole page, then click down to the sub-heading I just opened and try again to know.

I haven't looked, but I get the impression you don't have any error handlers (or maybe there are crazy high timeouts?). You should always, especially if your users are on mobile networks, to put up some sort of spinner when loading data and make a serious effort of handling the errors that inevitably happens.

[e12e]

I applaud your effort to apply some styling to the manual, but this is, frankly, ridiculous.

To whit:

    # Debian Jessie
    $ du -hs /usr/share/doc/glibc-doc-reference/html/
    9.0M    /usr/share/doc/glibc-doc-reference/html/
    $ cat /usr/share/doc/glibc-doc-reference/html/* > all.html
    $ wget https://www.gnu.org/software/libc/manual/html_mono/libc.html
    $ gzip -9 -k *.html
    $ du -hs *
    7.5M    all.html     # Local html
    1.1M    all.html.gz  # -"- gzip'ed
    4.9M    libc.html    # single-file version, from wget above
    900K    libc.html.gz # -"- gzip'ed
  

So, under a mb of data, for the whole thing -- and that's not even working with the various sections. It might have made sense on dial-up, but not really for mobile clients. The fact that you've completely broken the whole thing (eg: no mirroring with wget) doesn't make up for the savings. Also, if you'd kept the/a single html-file -- that file would've been cached, so doing some js-magic with hide/show should be instant, after the thing is downloaded. That's the old Dreamweaver way of pre-loading content (set sections/div/whatever as display:none, and toggle on mouseover link/clicks etc).

So this is not degrading css, this is just broken html for no good reason. If you want to load "partials", keep the traditional structure, and do your magic "upgrading" in js -- load the content asynchronously into a div or what-not -- and leave the links working for browsers without javascript/wget/etc.

All that said, the work you've done with the CSS is very nice. I'd probably add a media-query to collapse the sidebar -- it takes up quite a lot of space on mobile (especially in portrait mode). I'm also no fan of typekit -- if possible I'd prefer to use locally hosted (freely licensed, of course!) fonts.

As for search, maybe have a look at http://lunrjs.com/ .

And just as a reminder, on the off-chance that there might be some readers that are unaware: CSS Zen garden is still a good example of how html and css can go together in creative and gracefully degrading manner: http://www.mezzoblue.com/zengarden/

A final note on links/urls. With eg. vimperator, "gu" (go up) works for going from example.com/some/where to example.com/some/ -- so while most browsers have gotten rid of "forward" and "up" navigation arrows, they still do work.

[spc476]

But you broke the back button. Perhaps using frames might be better?

[cbd1984]

People who rely on screen readers probably don't like this.

[elmerland]

Ahhh, thats a good point. I will fix that! I tried using iframes at first. But they are a pain to deal with. I think I can solve the back button problem without them though. Thanks for pointing that out!