From: Robert Ramey (ramey_at_[hidden])
Date: 2004-07-28 11:31:59
>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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk