Again, I'm merely replying to the initial comment which was needlessly negative and frankly a tiring trope on HN (rudely criticising something unimportant about the site regardless of its intended use).
If you don't like sub-threads I suggest you get an HN-reader than can collapse comments.
I took that image from a non-laptop desktop machine, by the way.
You ignored the half of the sentence following the 'or'. To me, that's unfair.
> if the excuse is [...]
It's not an excuse, it's context.
The performance is a low priority compared to the content, when the site is a developer resource.
In many places, perf is still important, and one of the reasons, I believe, that GNU offers its manuals in various formats: [0]
I know of a few devs that work for web, but due to their nations economics, work:
* On a smartphone
* Via a satellite connection
Despite being in a first world country, I've had to do both at various times whilst working from remote areas.
The GNU manuals have a huge wealth of information, but they load fast by following simple-first policies.
caniuse.com is a SPA, but they load damn fast.
I'm not saying that this page is insanely slow, but that it is slow at all is still a surprise.
And not every dev in the world gets to have broadband.
Do all GNU projects keep there documentation i one big file? I wanted to contribute some recently but got lost in a complex help file.
* HTML - entirely on one web page.
* HTML - one web page per node.
* HTML compressed (gzipped tar file) - with one web page per node.
* Info document (gzipped tar file).
* ASCII text compressed (gzipped).
* TeX dvi file (gzipped).
* PDF file.
* Texinfo source (gzipped tar file).
If the one big file (great for grepping) was too confusing, you probably want to opt for HTML, with one file per node. For example, the Sockets/Local Namespace page for glibc: [0]
[0] http://www.gnu.org/software/libc/manual/html_node/Local-Name...
Edit:
And it appears the help files are seperate inside the source code as well. [1]
[1] https://sourceware.org/git/?p=glibc.git;a=tree;f=manual;h=71...
Thanks. It appears that this wasn't the case for make.
That really sucks.
And why should it render all examples on one page?
They could have a static page for every property so one could link to http://cssreference.io/align-content instead of http://cssreference.io/#align-content and get just that static page. That should be pretty quick, especially with long caching of all other resources than the actual page content.
There's lots of different ways to have done it without having to do it all at once.
Or, would have complained that it was stupid to actually use an anchor tag to link to god forbid another complete page load.
Or, if they used a javascript framework to make deep links someone would have complained that they used a javascript framework for a static page, or even maybe they used the wrong JavaScript framework.
No it shouldn't. Split up large chunks if it impacts performance.
I'd probably do a full load for the text, with specifying the height for the examples inline, and then lazy-render the examples once they're visible.
The problem with this site is not that it has too much context. Just too much new and crazy styles.
Very lazy on the part of the developer to code it that way.
Thanks for the report. Hopefully the author will almost fix it.
It would require setting section heights to fixed values so you can know which section is visible and enable and disable styles for them without changing the sites height.