On January 7, 2016 7:40:44 AM EST, "Agustín K-ballo Bergé"
Robert Ramey
writes: f) javescript.
I thing the admonitions agains java script should be softened. Most of the concerns existent when the document was originally written don't apply to day. I would like to see our html documentation support
On 1/7/2016 7:53 AM, Louis Dionne wrote: thinks
like syntax coloring, running example code online, and the like. These things are often supported via injected javascript.
+1
I think JavaScript should be allowed, and even encouraged when it makes the documentation much superior. For example, Hana uses JavaScript to integrate performance benchmarks to the documentation in a nice way.
I'm one of those that used to disable javascript by default.
I run NoScript, but I don't mind having to enable JavaScript to view Boost docs. I'd whitelist boost.org if it became common.
I wouldn't mind its use when it results in a superior documentation, as long as it's optional and I can still get at least a mediocre documentation with the basic information, and possibly some hint that I need to enable javascript for this site to see more (not just to navigate differently).
Agreed
What's your take on the remaining ones?
- Makes printing docs pages difficult.
That's probably not common, but the same is probably true for generating PDF docs, too.
- Often results in really bad user interface design.
That's like saying C++ often results in bad code. All tools, including HTML and CSS, can produce bad results.
- "It's just annoying in general."
The only thing annoying about JavaScript is its use in tracking me and trying to exploit my browser.
- Would require Boost to test web pages for ECMAScript/JavaScript compliance.
I suppose that's necessary to ensure we don't release problematic docs.
- Makes docs maintenance by other than the original developer more difficult.
I'm not sure that has much merit. ___ Rob (Sent from my portable computation engine)