[geeklog-devel] JavaScript, again

Tony Bibbs tony at tonybibbs.com
Tue Nov 10 15:50:52 EST 2009

Hang in there, it's not as bad as it all sounds

On Tue, Nov 10, 2009 at 2:23 PM, Dirk Haun <dirk at haun-online.de> wrote:

> - Believe it or not, but I still use Lynx[1] on a regular basis. It
> comes in handy that even then I can still change my account settings.
> It's sad, though, that I can't change the site settings, as the
> Configuration panel requires JavaScript. Btw, yes, I do have JavaScript
> enabled in Firefox.

You really need to establish a policy for GL developers (on the wiki?).  At
play here is the concept of Progressive Enchancement vs. Graceful
Degredation.  Please take the time to read the section on that here:


After reading that you have two choices:
1) Agree to use Progressive Enhancement which means make it work without JS
and then tweak the user experience using JS for those that have it enabled.
Downside is this often means coding a task twice (once for JS support, once
without).  Upside is it is the best of both worlds.

2) Agree to Gracefully Degrade which means if the browser doesn't support
JS, give them a nice message letting them know the feature isn't available
on that browser.

Now that all said, I still have to give you shit for using Lynx so much
still ;-)

- Accessibility. This is an issue for government sites (508[2] or
> similar local laws) but also affects private and company sites (e.g. the
> CEO of the company I work for recently "discovered" that as an issue).

This is again, the issue I noted above.

- Security. Frankly, I don't know a lot about JavaScript security and,
> as a result, wouldn't feel comfortable telling people that we're "the
> secure CMS" if there's code of which I don't really know whether it's
> secure or not.

Not sure how much there is really to discuss here.  The only real issue I'm
aware of is the now infamous MySpace/Facebook cross site domain XML
debacle.  As for true AJAX requests, you have the benefit of session and
cookie variables so you can treat them as you would normal web requests.
Aside from the same origin policy what else related to JS security should we
be discussing?

> So, I'm trying a different approach and go ahead and suggest we use
> jQuery. Reasons: Nothing particular, other than that it seems to be
> popular and that I like what little I have seen from it.

Coke vs Pepsi.  AptitudeCMS only uses jQuery for it's vibrant community and
documentation.  The most important note, however, is it is completely up to
each plugin in AptitudeCMS to decide which JS library they want.  Choice
there is good but as it pertains to the GL core, yes, you have to pick and I
don't think you'll get much complaining.

That said, only additional tidbit to mention is I'd be sure that all JS
includes occur after the <body> tag instead of the head.  Also, there are
tools you can pump the JS libraries through to shrink them to reduce their
footprint which would be a good thing for production releases.

Tony Bibbs
Phone: (515) 259-0003
Twitter, Skype, Facebook: tonybibbs
Web: http://www.tonybibbs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20091110/4b05f805/attachment.html>

More information about the geeklog-devel mailing list