Re: [boost] Help request, boost docs

From: Cédric Venet (cedric.venet_at_[hidden])
Date: 2007-06-20 16:06:52

> > >>
> > >> I didn't see anything at the top-right hand corner of the page.
> > >
> > > Browser?
> >
> > sorry, all I'm seeing is a nice green rectangle above the words
> "Search
> > Boost"
> > and a right pointer arrow that displays the word "Next" when the
> pointer
> > is placed over it.
> 
> Weird, it has been tested in IE7 several times in different machines.

I also have IE7 (7.0.5730.11) under WinXP SP2 and I see the same things
(like the screen shot of IE5) (firefox ok)

> Move the mouse to the upper-right corner of a code block and you will see
what I am talking about :)

and I didn't see anythings in the corner of the code either... even with
firefox.

> 
> > > IMHO working with frames is not the right direction. We can
> > > investigate iframes, a module of XHTML 1.1 but for now is it out of
> > > the scope of the proposal.
> >
> > Well, I certainly don't want to be guilty of promoting scope creep.
> > Though I would menention that frames have been a part of standard
> > html forever and documentation for many boost libraries have them
> > for just this purpose.
> 
> The standard is moving towards an unframed web.

I think the grouped link is good (if it worked on IE). But if you prefer
another menu, there is no frame based alternative:

At the cost of reproducing the menu in each page (the generation is
automatic, but the download is a little longer), there is many
possibilities:

- use a div with fixed or static positioning
- use a css based unroling menu (pure css)
(http://www.alistapart.com/articles/horizdropdowns/
 http://www.alistapart.com/d/horizdropdowns/horizontal2.htm
 http://www.alistapart.com/articles/dropdowns/#resettop
 http://www.htmldog.com/articles/suckerfish/example/ )
- hybrid menu
http://www.alistapart.com/articles/hybrid/
http://www.alistapart.com/d/hybrid/hybrid-4.html 

http://search.atomz.com/search/?sp-q=menu&sp-a=sp1002d27b&sp-f=ISO-8859-1&sp
-p=All&sp-k=All

> 
> > The usage of javascript is a little more problematic in that it
> depends
> > on the particular case.  In the case of J.Turkanis navigator control
> > this was discussed at some length and the final consensus seemed to
> > be that this was an acceptable and useful tool.
> 
> If we use only W3C allowed js, and if we make sure that it degrades
> gracefully when used in an old browser IMHO we should include js in
> our docs. Look at our design, the places where js has been used are
> very discrete. We do not want flashy things flying around, really. We
> only add dynamic support for useful and discrete tools that do not
> interfere with the user.
> 
As long as the navigator (with default options) don't ask you if you want to
enable js each time you goo to the page, I think it is really useful.

-- 
Cédric Venet