-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am not really sure if the site really needs JavaScript anyway. Besides the audio player or like Ken said, the progress bar, what would the need be?
If the HTML part of the site was laid out well enough then the ability to change the CSS would be a good administrative feature I'm sure. The only issue would be is if the site used a lot of CSS3 or some specific tags that did not render in other browsers correctly. If JavaScript was used (JQuery or whatever) then that does become an administrative nightmare. Once implemented and IE decides to do one more stupid thing, the entire thing falls down and you spend weeks rewriting you 1000 lines of JS. I say go for it. If you need assistance in testing or help with the layout / CSS I would be glad to help. How flexible is the layout of the html? I mean is it set in stone and now the CSS is what is being worked on? Or are you still working on the html part of the site as well? - -Curtis On 12/20/2013 06:29 AM, Ken Fallon wrote: > Hi All, > > Forgive the cutting and pasting of the comments but I want to group them > for a FAQ page. !! > > 0) HPR is open to *all*, not some, not most, simply all. > Jonathan Nadeau, listens to HPR. > http://accessiblecomputingfoundation.org/jonathan-nadeau > While you are there contribute < ${time of year guilt trip.} > > > 1) People using text mode browsers > > 2) People using screen readers or other accessibility aids > > Please read > http://accessites.org/site/art-texts/0702-olsson_gracef-degrad-progres-enhanc.txt, > which is an excellent article on the correct approach. Rarely are > Graceful degradation or progressive enhancement done. Even > by people that know better, and that have the resources to do it > correctly. Please see attached files G+js.png and G-js.png. > > > 3) People who are unjustifiably paranoid about allowing remote sites > > to run client side code > Our site is called *Hacker* Public Radio. It's hard enough to get some > people over the stigma surrounding the word *Hacker* to get them to the > site in the first place. The use of JavaScript on the site would add an > additional layer of paranoia. > > 4) People on slow or expensive connections > It (usually) increases the amount of data that needs to be downloaded > increasing bandwidth costs on people with slow, expensive, connections > or with bandwidth caps. These costs will still be incurred if people > choose to use a JavaScript blocker or not. > > Example http://www.blogspot.nl/ > -rw-rw-r--. 1 ken ken 43795 Dec 19 14:43 withjs.txt > -rw-rw-r--. 1 ken ken 199 Dec 20 08:32 textonly.txt > > 5) People using slow hardware. > I'm not just talking about people using old dedicated screen readers, or > people with low income using old computers, but also people connecting > via hackable hardware. We need to be fast for people using Arduinos or > RasberryPi's. > > Even those of you lucky enough to fall into the category of "most > people", who among us has not at one time or another decided to upgrade > all our computers at the same time, only to forget one minor step on > page 40 of the readme file. Now you know HPR has a show about that > problem and a wokaround. but the only device you have is an old laptop > running a version of Windows 95. > > 6) JavaScript encourages bad design > People are using JavaScript just because they can rather than when they > need to. This is nothing new, and was true with Marquee text/animated > gifs on GeoCities, then the use of JavaApplets, then the use of Active > X/"designed for Internet Explorer", then the use of Flash, and now > JavaScript. If we come across a area where we absolutely need JavaScript > then we can signal that to the visitor so they can choose to use it or > not. See sites that have "Follow Us" buttons follow you as you scroll > down the page. > > 7) It removes control from the Visitor > Imposing one and only one way of displaying the data on a page is rude. > Not having a "View - Page Style - No style." is a bug. > > 8) JavaScript is associated with tracking, been intrusive and annoying. > Just like Flash advertisements before it, JavaScript has the reputation > of been used to solicit user intervention, monitor, track and report our > use on the Internet. While this would not be true on HPR, the technology > itself has a bad reputation and therefore would tarnish us with the same > brush. > > > Designing a site with no JavaScript limits its capabilities. > I see no reason why this should be the case for HPR as the site is > entirely driven by php, or perl, and changes once a day. The only two > areas where I can see that JavaScript would be useful would be to record > audio, or as a upload progress bar. The upload progress bar is > something that can be added to FireFox as a plugin, or we could point to > a "click here for a javascript progress bar". Although a "keep this > window open until you get our confirmation email" would also work. > > The audio recorder functionality is something that will probably require > the use of a Flash or Java Plugin anyway. > > > I suppose that writing a website that degrades gracefully basically > > means double the normal amount of testing. > Yes and we do not have the resources to develop or test it. If someone > wishes to take this on they are more than welcome. As with all software > submitted to HPR, we expect the submitter to offer a minimum of two > years of support. And again be aware that we are called *Hacker* Public > Radio, which draws the attention of people that will ensure your code > merits the label. > > If someone wishes to develop a JavaScript site for us then you have our > full support but the choice to use the site or not should be given to > the visitor. Either by using a sub-domain or a additional parameter in > the url. > > ---------------------------------------------------------------- > Please keep your comments coming in about the proposed web design (and > JavaScript discussion) and also bug fixes for the css and html. > > Now to steer us back on track a little. I hope you agree that whither we > use JavaScript or not should not take away from the decision to move to > this design. > > Does anyone have any objections to us moving to this design ? > > Thanks, > > Ken. > > > > _______________________________________________ > Hpr mailing list > [email protected] > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJStDQWAAoJEK1k9cfJhUDT+PwP/1SJrxmDT5+Wvm2kaAIA1QAR S10lzXG1Yy9X/3oqJkuhg7I/Y/WcXr2d0mBLKvfBkkCOyTHCGYi+r2iqyUB9lXxS 0FTjF2HEtMUVJ/M2JByWUdauQXOxd4qJds0T6liNyzKr6xbGjWPoFQg/OcmRgSgB mKxcy4jlKJNvnH3R/upmL981unPFW78Z0BncfagtKvDFY6KPPt6Zlr7Auy9yd768 qCX5pv+30MQwuHTekAyu7LuSDjdVHSdsB1LGwNfLadrds330yL2CaHyG8GqEXQfd Uq3xbuvYuAN44TKzjWtUmAfd1Y7phf1cQFmdbQRljbUQtl/rBylhZHckJKL7LSkL UZXi0CbOI8bEMRs8WQeOBrHjQtaErCzmE1HariEPTIH2pkp8fip5SfgRGNhuV5d5 KOerxV1EuUwVTqvz9e1rXhNRJaHAUx0PY5hPy6bw9xszAfkRiOpa7r2g8WLUjzOu 7fOunMMrPrekTpw6jr6WAptKsBetzVoyhJWd+eLbnhLxdICrn6E8UnbQuMbCvIBx HkpZGdHH+kUm7zkqOLNB1dleuPNaXzeLYpAtDiUX7ovzJGmKZL4h0LP/JGkS2vwd Y+yEL2kLWynQLo+MAPoHzqSV7mUrIj5bbQtRbbdhxjm+ME8LeO2S4aFb33Wzgo+/ HE/7NAtX1atVLjaUtQuD =7A1p -----END PGP SIGNATURE-----
_______________________________________________ Hpr mailing list [email protected] http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
