The Cold Hard Code name has always evoked feelings of metal. I've generally opted for stark expanses livened up by small dashes of bright color. This has worked well but I decided that CHC needed a change. This design used a bright, eye-catching background with a dark header, creamy body and dark text.

The Page

The first step was to fire up a grid. One of the fundamentals of using any template or one-size-fits-all methodology is realizing that it's a guide, not a law. I began by using a 60px column width to frame up the page. The first layer of the orange (which I call the wrapper) is 60 pixels wide. The second layer (the liner) is also 60px. This two-tone look breaks up the large, boring field of orange that would be there otherwise and frames the text. My original had an outer size of 60 and inner of 120. This looked great at high resolution but cramped the text unnecessarily when shrunk down to 1024x760.

The header gives me a place to show one of my signature design memes: organic patterns. I love to add swirls, paisleys and other curves into squares. Subtly peeking from our header is a complex pattern. It doesn't overpower the header but adds an underpinning of style. The inset type is set in Hoefler & Frere-Jones new Tungsten family. Recently released, I knew at first glance it was a great fit for the CHC brand. The inset effect — which is very trendy at the moment — gives it that stamped feel that anchors most CHC designs. A bit of a spotlight is added to the left to draw some attention to our logo.

The Body

The color was chosen to contrast well with the orange background but will also be discussed in the text section. The sides discussed earlier are fixed, so our center is fluid. Since I didn't expect there to be any grid needed for our body, this is a reasonable choice. Were we mixing in a lot of images or other content I would probably reverse my grid and let the sidebars be fluid.

Text

Since the state of web fonts is currently in flux, I chose to use our signature font (the aforementioned Tungsten) only in the header. The titling and body fonts are chosen from the palette of standard fonts that users should have installed. The titling sans-serif progresses as: Helvetica Neue, Arial, Helvetica, sans-serif. The body serif progresses as: Palatino, Palatino Linotype, Georgia, Times, Times New Roman, serif. We move from least-to-most in terms of expected availability. Most modern users should have these fonts and if they don't then we gracefully degrade to other fonts with comparable qualities.

The base font size is 14px with an 18px line-height (14/18). Since the content is expected to be somewhat technical, I chose to keep the text open with plenty of room to breath. If it were going to be less tech-heavy I would probably drop down to 13px for the font height.

The sizes of the various header tags are arranged using the golden ratio: 34, 26, 21 and 16. The line-height of each is adjusted to be a multiple of 18 to retain vertical rhythm. All block text elements are padded 18px at the bottom, again, to keep vertical rhythm.

Not happy with boring ol' black for text, I chose a very dark brown that works well with the header. Choosing a background and foreground color for your page is very important. It's vital that there is adequate contrast between the colors so that people with various forms of color-blindedness (or people with shitty monitors) will have a good experience. You can use Jonathan Snook's Color Contrast Check to verify that you are meeting established guidelines for contrast. In our case the foreground (#312A24) and background (#EFEDC9) have a brightness difference of 190 and a color difference of 550. Well beyond recommendations. This gives us excellent contrast and a nice feel, as the brown-on-brown looks high end.

Code

The markup is all HTML 5 with some features from CSS3. Since our market is people that aren't running old IE browsers we can leverage these modern features without alienating potential users or customers. The overall weight of the page is light, with only 5 images making up the base design. The YUI reset stylesheets are used to give us a clean slate to work from. There are some major problems with IE8 at the moment, but we're O.K. with that for now.

Summary

I'm quite happy with the overall design. The bold earth tones and the solid underlying principles yield a look and feel that is both modern and stable. A header swap will allow us to some simple updates in the future. The fluid center is causing some problems when scaled up to large widths, but that's par for the course. I'm also very excited about the recent support that WebOTF is getting. I assure you that I'll be closely following it's developments and constantly tuning this site over the coming weeks.

I really like YUI, and the YUI RTE.  I think that for most typical editing scenarios, it works far better than other options.  It's easily extensible, and has a great default feature set.  The one thing that was really frustrating is that it kept eating my embedded gist tags.

The gist embed tags are very simple, and look simply like this:,

<script type="text/javascript" src="http://gist.github.com/1234.js"></script>

Outside of the very real risks of allowing XSS and other dangerous things, this is useful to be able to do.  However, the RTE doesn't allow it, and if the editor slurps in a textarea with a script tag, the editor silently eats all the script tags. Nom nom nom.

The only way to enable this behavior is extending the editor class, and doing some very hacky changes. Please note that this widget interpolates script tags even when they are escaped (meaning if you type in <script> in the editor, it turns into a live script tag). This is, for the most part, behavior that I want. Leave comments if this is oppositional to your uses, and I'll figure out a better API.

You can see my trusting editor in action, allowing script tags to preserve, and the complete code, displayed here:

The “official” version I will maintain will be at http://gist.github.com/200773. If it gets to be frequent, I'll setup a project for it.

In conclusion, I'd like to talk about my personal view of this solution. I don't want this to go on my permanent record without defending myself and this code. I think this solution is bad. Relying on a non-contractual API, and an internal method of the Editor (_cleanIncomingHTML), is generally asking for trouble. I don't have faith that this behavior won't change, and as such, this change cannot be guaranteed for future versions of YUI.

I would, very much so, like to see this change go into YUI Core, as it provides an option that trusts the programmer. It won't be included because of security concerns. Requiring the above type of extending to get non-destructive behavior really scares me, though. It just reeks of codesmell, and I'm sad that there isn't an option to trust the engineer.

I will maintain the gist to make sure it works with the latest released version of YUI (currently 2.8.0). If you notice a bug, please leave a comment and I will get it fixed up. I will also submit a patch to the Movable Type plugin that allows <script> tag embedding.

A common problem i was encountering is the mess of applications knowing where they exist, their root path, etc.  Catalyst solves this relatively well with the Catalyst::Plugin::ConfigLoader plugin.  You get the $c->path_to("some/file") method that makes everything very convenient.

It also doesn't exist outside of Catalyst, and that makes me sad.  I started working in a role that incrementally grew and grew and now is fairly full featured.  I don't really want to release it to the CPAN, because things like Bread::Board are much better.  This is also a really half-baked solution, and I don't want to pollute the elegant world of MooseX:: with my sub-par contributions.

I can, however, blog about them.

It's a rather long read for the full code, but the general idea is that it gets you the familiar MyApp->new_with_config construction, with an configurable configuration file.  You get the configuration substitutes (giving you $instance->path_to and MyApp->path_to both, but this is ultra hacky).  The usage, with coercion, is pretty simple: