How much javascript are we allowed in docs these days? It seems that Javascript started to appear here and there. Is there general guidelines on what is allowed? Gennadiy
on Mon May 28 2007, "Gennadiy Rozental" <gennadiy.rozental-AT-thomson.com> wrote:
How much javascript are we allowed in docs these days?
It seems that Javascript started to appear here and there. Is there general guidelines on what is allowed?
I don't think there are. It would be good if someone were to write them. My personal take is that Javascript is okay if: a. functionality degrades gracefully when JS is off b. the particular functionality chosen doesn't annoy me ;-) I would also like library authors to be mindful of the fact that we're trying to move to a (more) consistent look & feel for Boost documentation, so I would prefer if we only used JS that is generally accepted for future adoption (e.g. Jonathan Turkanis' menu control). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
I would also like library authors to be mindful of the fact that we're trying to move to a (more) consistent look & feel for Boost documentation, so I would prefer if we only used JS that is generally accepted for future adoption (e.g. Jonathan Turkanis' menu control).
There's also the consideration of adopting, as in allow use of and include someplace common, an external JS library. There are numerous JS libraries out there that smooth out most of the cross-browser incompatibilities. And that way we would leave the testing and maintenance to JS experts. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
David Abrahams wrote:
I would also like library authors to be mindful of the fact that we're trying to move to a (more) consistent look & feel for Boost documentation, so I would prefer if we only used JS that is generally accepted for future adoption (e.g. Jonathan Turkanis' menu control).
There's also the consideration of adopting, as in allow use of and include someplace common, an external JS library. There are numerous JS libraries out there that smooth out most of the cross-browser incompatibilities. And that way we would leave the testing and maintenance to JS experts.
What, boost.org isn't going to become a js powerhouse ? (Sorry, couldn't resist... ;-) ) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
on Mon May 28 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
I would also like library authors to be mindful of the fact that we're trying to move to a (more) consistent look & feel for Boost documentation, so I would prefer if we only used JS that is generally accepted for future adoption (e.g. Jonathan Turkanis' menu control).
There's also the consideration of adopting, as in allow use of and include someplace common, an external JS library. There are numerous JS libraries out there that smooth out most of the cross-browser incompatibilities. And that way we would leave the testing and maintenance to JS experts.
Yes, hooray for libraries! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Mon May 28 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
I would also like library authors to be mindful of the fact that we're trying to move to a (more) consistent look & feel for Boost documentation, so I would prefer if we only used JS that is generally accepted for future adoption (e.g. Jonathan Turkanis' menu control).
There's also the consideration of adopting, as in allow use of and include someplace common, an external JS library. There are numerous JS libraries out there that smooth out most of the cross-browser incompatibilities. And that way we would leave the testing and maintenance to JS experts.
Yes, hooray for libraries!
As I recall, the whole question was launched by the inclusion of a JS index in the serialization library documentation. This violated boost guidlines but I believe that this objection was overridden by the manifest utility of such a "documentation navigator". This sparked Jonathan's effort to make a better more definitive implementation which I believe was tested on all browsers that we use. Note that if this tree "navigator" were automatically generated and inserted as part of the documentation build, it could be replaced by some other implemenation just by changing the build script. So I don't see this fact that we may find an implementation which is somewhat better as any reason for making an improvement using what we currently have available. Robert Ramey
David Abrahams wrote:
so I would prefer if we only used JS that is generally accepted for future adoption (e.g. Jonathan Turkanis' menu control).
FWIW - I would like to see this menu control automatically used by Boost Book. I believe that this would only need a little effort my some XSLT expert. Robert Ramey
Robert Ramey wrote:
David Abrahams wrote:
so I would prefer if we only used JS that is generally accepted for future adoption (e.g. Jonathan Turkanis' menu control).
FWIW - I would like to see this menu control automatically used by Boost Book. I believe that this would only need a little effort my some XSLT expert.
Even if it takes some XSLT work I wonder as to injecting this particular tree control. The main issue is support. Who will support the JS code? As you know Jonathan is extremely busy now-a-days. As some other recent preferences have shown, it would be best to find more widely supported JS libraries. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
participants (6)
-
David Abrahams -
Gennadiy Rozental -
Matias Capeletto -
Rene Rivera -
Robert Ramey -
Stefan Seefeld