On Saturday 18 September 2010 18:45:30 Ian Clarke wrote: > 2010/9/18 Clément Vollet <[email protected]>: > > Ok, then, should I proceed like that : > > > > - adding a templating system, > > - design a new UI, and implement it in HTML + CSS only, > > - add GWT support (well, use it if it's already implemented) to make it more > > dynamic. > > If we are going to use GWT we should really be using it for the entire > UI, but not for the "proxy" component of fproxy, which displays pages > retrieved from Freenet. Based on my understanding of GWT it is > designed for creating UIs in a browser, which is what we need, but it > is not designed to degrade gracefully if Javascript isn't supported. > > I find the whole argument that we must support people who don't want > to enable javascript to be unpersuasive. We can and do filter out any > javascript from any page retrieved from Freenet so that isn't the > issue. We are talking about people refusing to run Javascript that is > written by us and served up by the Freenet node to their browser. It > is no more dangerous for someone to run Javascript written by us in > their browser, than it is for them to run Java code written by us in > their operating system. > > Given that disabling Javascript with Freenet does nothing to improve a > user's security, can someone remind me why our entire approach to a UI > redesign is predicated on supporting those that irrationally insist on > disabling Javascript in their browsers? Why must we inconvenience 99% > of our users to accomodate the irrational 1%?
Because a significant proportion of our users, both actual and potential, care about privacy. If you care about privacy online then disabling Javascript *for your web browsing* makes a lot of sense. Both for reasons of privacy (see e.g. EFF panopticlick) and security (most browser exploits are javascript based). Most people will not use a separate browser for Freenet: They will do the most convenient, and documented, thing, which is to double click the rabbit icon in the system tray. Therefore it will be using the same browser (admittedly in privacy mode) - and it will tell them that it needs javascript. At which point, they will either enable javascript globally or uninstall. A significant proportion will do the latter. Some of them will have plugins to enable it on a per-site basis, but it will still cause unnecessary headaches. *REQUIRING* javascript will reduce people's options, annoy a large proportion of the existing developers, contributors and users (we should do a poll!), and large proportion of two potentially important demographics - geeks (particularly old-school geeks as opposed to mac using web 2.0 entrepreneurs such as Ian) and vaguely privacy aware users. And there is nothing we can do without a fallback that we can't do with a fallback. At worst we are talking about code quality here, and a probably relatively small amount of developer time. I 100% agree that we should use Javascript where it is available. It can do some really great things, as we can see with the web-pushing branch (which will not make 0.8.0). However making it an absolute requirement is excessive, and IMHO the vast majority of the community agrees with me.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
