1. Configuration options can’t be passed to HAML
2. The locals hash isn’t passed to partials

The solution for partials has been given by Randy Parker.

The solution for HAML options has been given by Jason Tennier.

Either of these issues would have been a dealbreaker for me, so I was glad to see they both had relatively easy fixes. Although coming from the Perl world, I do get pissed off whenever I have to hand-edit the source of a gem

And as a newbie to StaticMatic, I do wonder how well the gem is being maintained now. Both of these patches have been around for a while, yet they haven’t made it into the distribution, and I wonder why?

Updated: So the maintainer says he’s been busy, fair enough. With the bug fixes above in place, Staticmatic is nice enough. Having an application server obviates the need to “build,” and if you know me you know how much I hate the build process ^.~ So that to me already sets staticmatic apart from other template engines. I’m really looking forward to 2.0

For some reason someone thought I knew something about nerds, and it led, very rapidly to this.

So here we go.

I’ve been subscribed these groups and lists for a while. Each one has been a regular source of useful or interesting information.

Sign up to mailing lists in digest mode

A lot of these can be read over the Web at Google groups, or you can sign up to receive them as email lists. Where you sign up for emails, I’d recommend subscribing to any of these in “digest” mode. Digest mode means you recieve only 1 email a day, with all the threads for that day summarized. This makes it easy to keep track of whats going on across several different groups.

Before signing up for any of these, you might want to review ESR’s excellent (and amusing) guide to development mailing lists.

Recommended email lists and discussion groups

Selenium discussion, bugs and new features.

JSLint discussion, including new features which are being added weekly. Douglas Crockford runs this list and responds to most questions.

Firebug discussion, including announcements of new Beta features, which are being added weekly. Run by the Firebug team.

For CSS the definitive discussion group is Eric Meyer’s CSS-discuss mailing list (be sure to choose to receive “digest” format, as this is a high-volume list).

comp.infosystems.www.authoring.stylesheets is another excellent source of discussion about real-world issues with cascading style sheets in XHTML.

comp.lang.javascript is the oldest JavaScript discussion group, where you can find intelligent, informed discussion about interesting topics such as recursion in JavaScript. While you can read this one through Google Groups, a news reader with a kill file is highly recommended.

There is a large and erudite JavaScript developer community at the Evolt JavaScript list. The volume on this list is low but the level of discourse is great. Every discussion is imo interesting.

The EcmaScript 4 Discussion list is headed by Brendan Eich, the creator of JavaScript. This is the list to read if you are interested in the development of JavaScript 2. Again, you want to choose “digest” format when subscribing here.

Another deeply technical but informative list is the WHATWG’s discussion list for HTML 5.

See also

User Experience

I’ll also point a few more great browser-related resources, though not actually mailing lists:
http://planet.mozilla.org
http://planet.webkit.org
http://ajaxian.com

Policy and Law

If you like to remain aware of online law, the Electronic Privacy and Information Center’s announcement list is worth joining, and Slashdot also has a category devoted to online legal issues.
http://epic.org/alert
http://slashdot.org/yro

Think of a document being viewed in a Web browser as an MVC application (I found this idea in Ajax in Action),

HTML is the Model: HTML contains only structured data (content and markup).

JavaScript is the Controller: JavaScript is used to change the structure of HTML model, based on user decisions.

CSS is the View: CSS is used to filter and style data from the model so that it is displayed in a way the user understands.

In order to maintain separation between these ‘application tiers,’ there should be no JavaScript or CSS at all in the HTML.

Therefore, the ‘inline event handler’ attributes ONCLICK, ONMOUSEOVER, and their ilk are not needed and should never be used. And the STYLE attribute is never needed either.

An immediate benefit is that it then becomes trivial to lint and validate all of the HTML, JavaScript and CSS contained in a project just by filtering for file extensions. Of course there are many other benefits which are described at some length in articles such as those I have listed here on delicious.com.

Not directly related, but speaking of standards, this is the College Board’s beautiful HTML page which I use as a reference and style guide when designing templates.

And finally, for amusement, I found in my notes that, according to PPK, the term ‘unobtrusive JS’ was coined here.

This idea was first expressed in 2007 by Ric Hayman, who also wrote a very nice post about the original via: tag bookmarklet. And a year later, Nicola D’Agostino picked up the meme and sparked another interesting conversation about attribution meta-data in Delicious.

I hope that 2 people will also use and enjoy the new the del.cio.us whuffie bookmarklet.