On Tue, May 3, 2011 at 10:57 AM, Rene <renew...@xs4all.nl> wrote: > Maybe I'm comming on to strong with unacceptable. I think it is a lot > of work to support javascript. There are so many libraries each with good > and bad. Which would you choose (jquary, yul, google). And you create a > dependency. > > And what really is a lot of work to maintain the html pages in c-src. > adding javascript complicates that even more. One src file can contain > C-preprocessor, C language, HTML, TH1 and javascript > > Backward compatability (not breaking any code) is high on the list. > I could see that going wrong with javascript. > > Couldn't agree more: dependencies are bad. Just wanted to get an idea of Fossil "coding philosophy".
> I do think that namming your classes unique is a sensible thing. I have > been mucking around with documentation and have generated documentation with > docbook and lyx. > for an docbook example see > http://chiselapp.com/user/renez/repository/cvs2scm/doc/tip/doc/wiki/index.wiki > You stand a risk that docbook generated class names confilct with fossil > classnames. > So generating a name space by prefixing classnames with fsl_ or fossil_ > seems prudent. > > I also think that generating good class names for every output type > e.g. fsl_wiki fsl_wikiedit fsl_artifact fsl_artifact_content > fsl_artifact_type, > is a good thing. > > I like the idea of prefixing 'documentation' class names with "fsl_" thought I think the current batch of class names is fine (they're all fairly general). Tomek
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
