On 12/1/12, Branko Čibej <[email protected]> wrote: > On 01.12.2012 07:41, Olemis Lang wrote: >> -1 Reasons mentioned in previous messages. BH has to work even if JS >> is not available , not 100% of the functionalities will be available >> though . > [...] > > Can anyone point to even one BH deployment (OK, potential deployment) > where working without Javascript would be important in the time frame > of, say, a year? I don't think so. >
public ? => I don't know private e.g. in an intranet ? => yes , some ... in some sense I'm one of the users often on non-JS mode since I have to disable JS from time to time to make web sites load faster ... considering the fact that sometimes my internet connection becomes a PITA , btw . > Getting bogged down on technicalities that aren't likely to affect even > 1% of the potential user base is going to kill the project before it > even properly gets off the ground. The perfect is the enemy of the good, > etc., etc. > IMO the effort required to support non-JS clients is tiny as compared to other major features like those developed and scheduled so far : - dashboard & widgets - multi-product (BEP 3) - advanced search (BEP 4) - advanced upload form (#195) - ... if we compare all those side-by-side , support for non-JS clients should be more simple by far . For instance, what a big deal is to insert href="/newticket" in create ticket shortcut button ? Instead of «supporting non-JS clients» maybe it's more accurate to say «not to turn non-JS clients unusable» since the idea is not to spend time developing a marvelous non-JS experience . The idea consists in providing quick navigation paths so that such users will be able to perform basic tasks . A naïve approach is to design templates and , before anything else, check they work with nothing else on top . Let's add the rest later. There's another reason , and it is that if for any reason JS code fails at some point under certain circumstances , non-JS behavior will be handy as a last recourse option . If we don't design with that goal in mind since the beginning then it will always be a loose end . IMO there are other major obstacles when it comes to analyze what might jeopardize the existence of the project . Of course , under certain circumstances if non-JS compatibility effort turns out to be long to achieve , a low priority (starter?) ticket should be enough and we move forward with something else . ;) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
