I hovered over moritz's three links and was a bit surprised to not see "ours truly" included. moritz is so polite. ;)
And, before I go any further, I would like to extend my sincere thanks to jj808 for the hard work (on an important site) and for announcing the changes here. I hope he won't mind the ensuing discussion. I'm unlikely to privately communicate critiques of his work since I have the opportunity to do so with much less effort as part of this discussion.
I don't want to discount the visual changes that I'm sure jj808 worked hard on. As you may have suspected from visiting this clunky-looking site that I hack upon, I don't really notice fonts or colors much (except when they make things hard to read). So I'm genuinely sorry that I don't have much praise to offer about "the look". I go to perldoc because I want to read some text and it is often the most convenient way to get to that text in a format that is easy to read. I am truly thankful that jj808 worked hard on the new look and I hope that it is well appreciated by normal people who notice that stuff. :)
I also would like to offer great praise to jj808 for choosing to leave links underlined so that I can find them (and without learning some alternate visual cue).
The Perl documentation (in the new layout) is quite easy to read. The "syntax coloring" on the code snippets is done subtly enough that it is only slightly distracting (the bright red for sub names is an exception in both that it isn't subtle and actually makes the names hard to read).
The highlighted boxes around in-line code snippets make it easy to scan for keywords and bits of syntax while they also don't seem to disrupt my reading nor make the code hard to read. Good job!
But having such an important feature (search) not work w/o javascript is something I would consider unacceptable. I find it even more galling for a Perl site (but we can to be self-righteous, can't we). I know that many people appreciate many of the interface options that become possible with javascript (I do sometimes but I even more often find that I prefer the consistency of an HTML-only interface) but providing a fall-back is just polite.
In this particular case, I'm not upset except in abstract at this point because I don't use perldoc's search feature anyway. I use PerlMonks' to 'search' perldoc, typing (for example) doc://$; into the PerlMonks 'search' box to jump right to the desired documentation (and this still works w/o need of javascript, thankfully). When doing full-text searching of Perl documentation, I tend to use 'grep' against my local perl/pod/*.pod (or equivalents, usually using vi as my doc reader). And now I know to not try the search box so I'll just use google w/ site:perldoc.perl.org when I want to find documents that mention "all of the following words".
So those who miss a useful search due to lack of javascript (perhaps just by choice) have at least two alternatives for searching perldoc.perl.org (use PerlMonks or use google).
So I would like to gently encourage jj808 to allow non-javascript environments to work more smoothly at such an important site (certainly javascript isn't intrinsically required for any previously-available functionality there, such as searching, since it worked w/o javascript before).
I realize that the new search functionality is more than just interface tweaking. And I noticed and appreciate the "this is the best match but you can look at the list of other matches if you want to" feature (a feature I've long wanted to add to PerlMonks). But the site should at least offer a less-smooth search feature in the absense of javascript (IMO, obviously).
I'm sure some will ask "why would you ever not have javascript enabled"? In this particular case, I would go out of my way to disable javascript just to get rid of the "floating" heading bar. There are lots of annoyances inflicted by javascript so I prefer to opt-in to javascript only for sites where they offer features that really require such functionality and where the site does an excellent job of not annoying me (javascript is often used to make particularly annoying advertisements, for example; but I often find javascripters' interface choices annoying enough as well). I'm sure others have other reasons to browse w/o javascript (corporate security policy, their own security choices, their particular environment, etc.).
I also encourage providing a link to set a cookie that turns off the "you don't have javascript" notice (or at least replace it with something much less conspicuous). I understand the desire (and wisdom) of making it very obvious to new visitors the likely reason why the site is behaving "a bit odd". But I also understand visitors refusing or being unable to enable javascript and getting quite annoyed at the visual noise on every screen.
I also encourage providing a way to set a cookie saying that one doesn't want the floating header so those with javascript enabled can get rid of it (some will surely find it useful but it is unusual enough that I'm sure some will just find it an annoyance), perhaps triggered from an 'x' element on the bar.
Finally, I will once again tilt against the windmill of webpages that don't know how to resize. I'm certain that your new design would be nearly unusable if I visited from my zaurus (or other small-format browsers I've been known to use). I can adjust the width of my browser window as much as I want to and your new layout resolutely refuses to acknowledge my choice (or limitations). If I want to get a larger section of documentation showing on one part of my screen as a reference while I'm doing work based on it in another window, you have greatly limited my choices.
I realize that there is a resolute meme that CSS is king and tables (for layout) are evil and even bow to the strong motivation for "pixel-perfect" web layout in the face of many web advertisement schemes. And I love CSS for much styling. But CSS is fundamentally broken when it comes to doing layout (as can be seen by people spending days trying to do simple things with it and the fact that almost nobody is cabaple of producing a layout with CSS that is capable of resizing well). So I'll just challenge you to prove me wrong (as I always do) and get your CSS-based layout to resize to still be readable when given a quite narrow window and to use more horizontal space when it is offered to it.
Thanks again for your hard work, jj808! I hope you find my critique and criticism useful.
