Jonathan Turkanis
There was a discussion a couple weeks ago about the javascript menu in Robert Ramey's serialization docs. I suggested making a menu component available Boost-wide and testing it on a large number of browsers to address portability issues. I've written a preliminary version, documented here:
I've verified that it works -- with varying levels of functionality -- on 26 browsersincluding some antiques such as IE3.02.
I'm still looking at this but I have some preliminary questions observations a) Visually as displayed in the demo it looks very nice. b) I think that testing on 26 browsers and asserting it works on 95% of those in use is the wrong way to look at it. I believe it should be a requirement. "Works on all browsers" - has "more" functionality on browsers that support it. In the case of my implementation - it displays fully expanded unless its one of the three browsers known to work properly. c) The boost "rule" no javascript. This should be re-formulated to be "all documentation should be usable on any browser that supports frames". This can be implemented using the approach b) above. d) The control presented is a very nice job - but I was hoping this might take a slightly different direction. What I would like to see is: "Boost Documentation Navigator" 1) a two frame page. Left frame containing a expandable/collapsible index implemented by a control such as yours. The right page would be the current boost documentation pages. 2) This "Navigator" would be automatically generated from the Boost.Book xml files using XSLT or some other appropriate tool. This would have the following advantages. 1) Usage of this "Navigator" would be optional. Lots of times its interesting to send a page without the frame. Searching through pages without the "Navigator" would be the same as it now - tedious but relieable. 2) it would be "free". The contents/index would be automatically generated without my having to go through another layer of documentation and preparing an index by hand. Those using boost book would get a complete index while old documentation would have just an entry into the top level. 3) it would provide much incentive for boost authors to move their documentation over to boost.book Boost.book might have to add a little bit to support this. While I'm on the subject of Boost.book. I would hope that the formatting is in a .css so that I might replace it with my preferred look and feel. (I prefer the "classic" one). I believe this would resolve the essentially irresolvable about esthetics. Robert Ramey