Overt Pretension

Site refresh + new open source project

2017-07-16T23:46:00-07:00

I’ve just gotten done giving the site a much-needed visual refresh. Also, I’ve recently put together a new open-source project, bootstrapped by create-react-app, that includes:

Integration with React Router and Redux
Styles in Sass (scss format)
Stylelint and ESLint configs based on my preferred coding standards
.editorconfig
A basic set of styles based on css3-foundation
Testing with Mocha, Chai, and Enzyme

Give ‘em both a spin! (And let me know about issues you find please.)

Organizing your CSS

2016-01-30T17:57:00-08:00

The larger your website or application gets, the harder it is to keep your CSS sane and easy to maintain. The trouble, of course, is that there is no One True Way. Lots of people have made recommendations on how to do this over the years. Here’s mine.

Let me say this first: I subscribe to neither the SMACSS nor BEM schools of thought, though I agree more with the latter than the former.

My philosophy is that if you have a reasonable file organization, a structured commenting strategy, and strive always to use semantic names, you’re in pretty good shape. No complicated naming conventions necessary.

Use a CSS pre-processor

Nowadays, even on small projects, I use a CSS pre-processor—Sass is my favorite. They’re way more powerful than CSS, are conducive to organizing your code in smaller, topical, maintainable chunks, and just all around make your life easier. If you aren’t using a pre-processor and you build websites on a regular basis, consider switching.

File hierarchy

Here is how I organize the styles in all my web projects:

styles
├── basics
│   ├── _colors.scss
│   ├── _grid.scss
│   └── _typography.scss
├── shared
│   ├── _alerts.scss
│   ├── _footer.scss
│   ├── _forms.scss
│   ├── _foundation.scss
│   ├── _header.scss
│   ├── _mixins.scss
│   ├── _page.scss
│   └── _pagination.scss
├── _feature-1.scss
├── feature-2
│   ├── _feature-2-component-1.scss
│   └── _feature-2-component-2.scss
├── _component-1.scss
├── application.scss
├── ie.scss
└── print.scss

basics/ contains the building blocks of the styles: the colors (more on this in just a bit), the typography, the grid.
shared/ contains application-wide styles like header, footer and form styles. Default styles for the basic HTML tags should also be included here.

The rest of the styles should be organized by feature or component, with more complex features getting their own subfolders.

Make sure that every component or feature/page in your application gets its own root-level class—sometimes this goes on the body tag. Then in your style definitions, make sure to namespace the sub-feature or component styles inside the root-level class for better cleanliness and easier overriding of global styles:

1
2
3
4
5
6
7
8
9
<!DOCTYPE html>
<html lang="en">
<head>
  <!-- … -->
</head>
<body class="feature-1">
  <!-- … -->
</body>
</html>

1
2
3
4
// In _feature-1.scss
.feature-1 {
  // …
}

As is the convention in Sass, all partials should have their names preceded by an _ (underscore) so that the Sass compiler knows not to compile them as individual files in the output directory.
application.scss, ie.scss and print.scss are manifests including some combination of the partials. Because they lack the _ prefix, they will be compiled into the output directory.

Colors in Less and Sass

One of the most irritating and error-prone things to have to do in CSS is change colors. When I put together my _colors.scss color manifest, I do a few things to minimize the pain of changing colors, which can happen often in the early days of a web project.

Never use raw hex or RGB values outside the color manifest.
Every hex value should be assigned a human-readable color name: $tangerine-yellow is much more understandable than #ffcc00.
Further, assign those colors to a semantic variable name based on usage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// Main palette
$raw-steel       : #3f3c3a;
$sand            : #dfd2c9;
$aqua            : #cbf1e3;
$orange          : #ff7f00;
$saddle-brown    : #844421;

// Secondary colors
// …

// Greys
$warm-grey       : #c5bdb8;
$light-grey      : #d0d0d0;
$ash             : #e1dbd7;
$white           : #ffffff;

// Backgrounds
$page-bg         : $sand;
$content-bg      : white;
$accent-bg       : lighten($ash, 10);

// Text
$body-text-color      : $raw-steel;
$secondary-text-color : $saddle-brown;

Then elsewhere, you can do:

1
2
3
4
body {
  background-color: $page-bg;
  color: $body-text-color;
}

If later on I want to change the page background or body text color, I only need to change it in the color manifest, and it’ll get propagated everywhere with no fuss.

Commenting

Establish and consistently follow a commenting strategy. Even if you’ve broken up your styles into files, each file will likely have subsections. Do your future self and your team a favor by delineating sections of code with comments.

Here’s how I like to do it. You can see that the names for subsections are indented further than the top-level styles, and that if comments are necessary, they’re included under the header.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/*-----[ foundation ]-----------------------------------------------------------
| Reusable content styles. Define your application-wide styles, like links,
| headers, body text, clearfix, etc. here. See the readme for information on
| recommended rule order.
*/

/*----------[ table of contents ]-----------------------------------------------
| tags
| non-semantic styles
*/

/*----------[ tags ]------------------------------------------------------------
*/
// …

/*----------[ non-semantic styles ]---------------------------------------------
| Purely presentational styles with non-semantic names.
*/
// …

Semantics. Semantics. Semantics.

Years ago I hopped on the semantic markup bandwagon and never got off. I’ve developed a bone-deep loathing of purely presentational identifiers in markup and do everything short of twisting myself into a pretzel to avoid using anything besides clearfix in my HTML classes.

“But,” I hear you saying, “what if I need to define a common set of styles that I want to reuse? Wouldn’t I just create a class and use it everywhere?” My answer to that is: only if you’re using vanilla CSS.

If you’re using a pre-processor, as most projects of significant size do, I recommend you put those reusable styles in a mixin. To me, this:

1
2
3
4
<form id="sign-up-form" action="…">
  <!-- … -->
  <input class="sign-up" type="submit" value="Sign up">
</form>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@mixin cta-primary {
  // …
}

@mixin cta-large {
  // …
}

#sign-up-form {
  // Assuming a Susy grid of 12 columns
  @include span(6);
  margin-left: span(3);

  .sign-up {
    @include cta-primary();
    @include cta-large();
  }
}

is infinitely preferable to markup littered with purely-presentational names like:

1
2
3
4
<form id="sign-up-form" class="col-md-6 col-md-offset-3" action="…">
  <!-- … -->
  <input class="btn btn-primary btn-large" type="submit" value="Sign up">
</form>

The former example achieves a much clearer separation of content and presentation, and makes the markup much, much easier to read and understand.

Order CSS rules consistently

Follow a consistent order when writing CSS rules. What the order is is largely immaterial, as long as you and your team agree on and consistently follow that order. Here’s the order I prefer. To make doing this easier, I use CSScomb to automatically reformat my CSS according to a config file.

Coding standards

Generalizing from the last section: establish coding standards for your team and enforce them in code reviews and automated testing, to keep your code base clean and maintainable. Here are the standards I use with my team.

Wrapping up

To summarize:

Use a CSS pre-processor.
Break up your styles into files by common purpose: basic styles, shared styles, then individual features or components.
Structure your color manifest for maximum reuse and minimal cost of change.
Establish and follow a commenting strategy to make your files easier to scan.
Make the names in your markup meaningful. Minimize—strive to eliminate—purely presentational identifiers in your markup.
Order your CSS rules consistently. Consider using a code formatter to help with this.
Establish and enforce coding standards.

Building a color palette

2016-01-29T21:56:00-08:00

I should start out by saying that I’m operating in near total ignorance of color theory or formal education in design. So you may think what I do here is unscientific and unrefined, at best. That said, over the years I’ve felt my way into a process I like for creating color palettes for new web and design projects.

Think about color like a UX designer

The first thing to remember is that choosing color is not just about making your site/application/whatever look pretty. Usually, that’s not even the main concern. Color is an important weapon in your arsenal to convey information, and as such it should be used with intent and forethought.

The requirements

When I start a new web project, I know I’m going to need colors for a number of different kinds of information:

Body text
Headings
Blockquotes or other emphasized areas of text (I call this secondary text)
Links, including hover and active states
Stroke colors for borders of page elements, tables and form inputs, including focus and disabled states
Highlighted or inverse text
Buttons: normal, destructive, secondary, each with hover, active and disabled states
Alerts of all severities: information, success, warning, failure

Realistically not all these things would require individual colors. I might decide, for example, that headings and body text are the same color, or that focus, hover and active states all get the same styling. Even so, all told I need 10 to 20 colors for a fully-functional web palette.

That’s a lot of colors. If I used 20 different hues, it’d look like a rainbow went on a bender and threw up its excess all over my website. So here’s what I do: I choose 5-10 hues, then all the rest of the palette is comprised of shades, tints or tones of the main hues.

Terminology

An aside here on color terminology. All of the terminology I know I’ve learned from monkeying around with Photoshop. Well, that and a recent purchase that I’ll talk about a bit later. For the purposes of this article, let me define the terms I’m using, the way I understand them (i.e. they may not be technically correct):

Hue: Essentially, one of ROYGBIV. Is it reddish or bluish? Is it closer to green instead?
Saturation: How intense is the color? Is it a brilliant cherry red, or closer to mauve (a greyish pink)?
Brightness: How bright is the color? Is it dark (close to black), or bright (close to white)?
Shade: Hue + black
Tint: Hue + white
Tone: Hue + black + white

From this you’d surmise, accurately, that my favorite color space is HSB (hue, saturation, brightness); it suits well how I like to think about color. First I pick the hue I want, then adjust its saturation and brightness to taste.

Refining the requirements

Back to the problem at hand: choosing hues. Even though we have a bunch to choose, there are constraints we have to operate within if we want people to be able to read our sites or use our applications for more than three seconds without getting a headache. In practical terms that means:

The page background is white or a very pale tint of some hue.
Body text is black, dark grey, or a very dark shade of some hue.
Success messaging is usually in the green family, while warnings are yellow or orange and errors red.
Links and buttons are almost always in the green or blue family.

Given these constraints, it’s likely you might find two similar hues in your palette. In that case, make sure that they’re different enough in hue, saturation or brightness from one another so as to be distinguishable at a glance.

Okay, I hear you saying, but where do I start?

The inspiration

Find something whose colors you find appealing. It can be a photograph, a fabric swatch, a picture in a catalog, anything. I would often browse color scheme sites like Adobe Color or COLOURlovers, or look for illustrations or designs on Dribbble.

From one of those sources, I’d get a starting palette of around 5 colors—this particular one is inspired by a photo of my dining room:

The palette template

Now that I’ve got my starting point, I need to build out the rest of the palette. But how do I make sure that all the colors are harmonious? That they are complementary parts of a whole? This is something I struggled with for quite a while. The answer, of course, is to put a bunch of color swatches close together and see if they look nice.

But how can you arrange the swatches so that it’s easy to see if nearly every combination in your palette is harmonious? Here’s the swatch arrangement I came to after some trial and error: a bunch of triangular swatches, arranged in a circle like pieces of a pie:

Look near the center, and you’ll be able to see all the colors and how they play together. Download this file as a Sketch template.

Building methodically

Okay, now I’ve got my inspiration and my palette template, and I’m ready to build out the full palette. But how do I get from here to there? Here’s how I like to do it:

Remember that we want each of the primary hues from the inspiration palette, accompanied by at least one shade, tint or tone, so we don’t end up with a total hodgepodge of colors. So pick one of the colors from your inspiration palette and set the fill of one of the wedges.
Now move one wedge clockwise (or counterclockwise if that’s your preference), and set that wedge to the same color as the first.
Adjust the saturation and brightness settings so you get a shade, tint or tone of the first hue.
Do this as many times as you want variations on the same hue.
Now move to the next empty wedge and pick another color from your inspiration palette. The rule is, it has to look nice next to the wedge you colored previously; every pair of adjacent wedges should look harmonious together.
Lather, rinse, repeat, working your way around the pie until all the wedges are colored. Check along the way that every pair of wedges looks nice. Also keep in mind the constraints we came up with previously. You want a shade of green for success messaging, yellow or orange for warnings, a dark grey or black for text, etc.
When all the wedges are filled, do a last check of the center of the fully-colored pie. Do all the colors look nice? Do they go well together? Yes? Then you’re done.

Common problems

While I’m generally happy with this process, there are some problems I run into on a regular basis:

Sometimes I have an idea for a palette in my head, but I have a hard time translating it to colors on the screen; it just doesn’t look right. At those times I wish I just had a bunch of paint swatches or something I could hold in my hands and move around to try things out before I move to creating the palette on screen.

Until very recently, I had no way to deal with that problem other than trial and error, and usually dissatisfaction that I couldn’t realize my vision easily. But that’s all going to change now. Late last year, I backed a Kickstarter project called BreakThroughColour, intended to be a system of hold-in-your-hand cards that would teach you about colors and basic color theory.

They arrived last week—this is how I learned what shade, tint and tone mean—and I couldn’t be happier with them. Though they’re physical cards printed with ink—of necessity defined in the CMYK color space—each card contains a hex code that’s a reasonable facsimile and which gives a good starting point for the color on-screen.
Once I have a palette built, there’s the tedious but unavoidable step of getting the hex codes for the colors into my CSS. I have to go into Sketch, grab the hex code for the wedge from the color picker, then paste it into my code. This is incredibly annoying.

But! I recently installed a few Sketch plugins that individually and together make this much, much, much easier:
1. Sketch → Colorpeek
2. Sketch palettes
3. Sketch-mate
4. And the jewel in the crown: the Zeplin plugin. This one lets you import sketch drawings into Zeplin, which makes it super easy to extract, name and export colors into CSS, Sass, Less, or Stylus. BOOM.

Other useful resources

Here, in no particular order, are some useful websites I’ve come across while trying to refine my color choosing process:

Share colors online with colorpeek.
0 to 255 makes it dead easy to find variations on any color.
Colblindor has some great resources on color blindness, which is an important concern when designing with color. It also has a nice tool to help you put names to colors—especially useful for your Sass or Less color manifests (more on this in another post).
Don’t like those names? Try Name that Color instead.
Use rgb.to to convert from RGB to almost any other color space. Especially useful for getting Pantone numbers.
Design color schemes based on color harmonies with Paletton.

Happy new year!

2016-01-04T23:12:00-08:00

Working around the Yosemite/El Capitan Mail.app memory leak

2015-11-27T20:59:00-08:00

Twice in the same week, on two different computers, I fell victim to the same egregious Mail.app memory leak. Within seconds or minutes of launching Mail, it would eat up all the available system memory, and bring the system to a grinding halt; only a hard restart would work after that. The good news, though, is that there’s a relatively straightforward workaround.

TL;DR: An Apple support forum post has the right solution, which is to force the computer to rebuild Mail’s container. Practically, this will mean deleting all the saved mail and settings, then redownloading or reimporting all messages.

In my experience, though, you don’t have to delete and re-add all your mail accounts (Step 3 in the solution); removing the saved messages and settings did the trick for me.

Fixing your zsh path after upgrading to El Capitan.

2015-10-08T21:06:00-07:00

I upgraded to El Capitan last week and noticed shortly thereafter that my path was messed up; when opening up new terminal windows, the active version of ruby was the system version instead of my RVM default. On investigating, I saw that for some reason the default paths in /etc/paths (/usr/local/bin:/usr/bin:…) were first in my path instead of last, as they would have been if my .zshenv and .zshrc were being sourced properly. Here’s how I fixed it.

So the problem is that El Capitan creates an /etc/zprofile that contains the following:

1
2
3
4
# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
   eval `/usr/libexec/path_helper -s`
fi

path_helper is a utility that adds those default paths to your path. Problem is that /etc/zprofile gets sourced after ~/.zshenv (background), and if you construct your path in .zshenv, like I was, this meant that all the hard work I was doing to build my path in the first file was getting screwed up by sourcing the second.

So I had two choices:

Move all my path construction to .zprofile or .zshrc, since they get sourced after /etc/zprofile. This was a no-go since I want my path to work for non-login shells.
Simply comment out the lines in /etc/zprofile. Which is what I did.

And, boom! Back in business.

Making Middleman v3.4.0 work with Pow.

2015-08-21T22:06:00-07:00

I recently upgraded the Middleman gem in my blog installation to the latest version, v3.4.0, and found to my dismay that it no longer worked with Pow. A refactor to Middleman::PreviewServer caused Pow to throw a TypeError – PreviewServer is not a module exception. The good news is that the change was a simple one, and you’ll only need to change a single word in your config.ru file to make it work again.

Various sources from around the internet recommend that your config.ru file look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
require 'rubygems'
require 'middleman-core/load_paths'

Middleman.setup_load_paths

require 'middleman-core'
require 'middleman-core/preview_server'

module Middleman::PreviewServer
  def self.preview_in_rack
    @options = { latency: 0.25 }
    @app = new_app

    start_file_watcher
  end
end

Middleman::PreviewServer.preview_in_rack
run Middleman::PreviewServer.app.class.to_rack_app

And all you have to do to make Pow work again with Middleman is to change the module keyword on line 9 to class: PreviewServer is now a class instead of a module.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
require 'rubygems'
require 'middleman-core/load_paths'

::Middleman.setup_load_paths

require 'middleman-core'
require 'middleman-core/preview_server'

class ::Middleman::PreviewServer
  def self.preview_in_rack
    @options = { latency: 0.25 }
    @app = new_app

    start_file_watcher
  end
end

::Middleman::PreviewServer.preview_in_rack
run ::Middleman::PreviewServer.app.class.to_rack_app

Boom!

Tea and transformation

2014-11-30T11:48:00-08:00

Tea speaks to me of rainy afternoons and crackling fires. Of snow falling on a silent garden. Of a few quiet moments out of time, the ease of familiar movements, of being in yourself completely, at peace. It speaks of hospitality and comfort, companionship and home. Tea is more to me than just a drink.

But that is only peripherally what I’ll talk about today. I decided a little while ago that I wanted to take some of my TV-watching time and devote it to learning, specifically to improving my design sense. So I bought a bunch of design books and decided to do a little project.

The motivation

I’d been spending a lot of time reading Brand New, a designer-written blog reviewing identity and branding redesigns, and I quickly found that I didn’t have the knowledge to even look at the designs critically, let alone assess them. I wanted to gain that knowlege, and given that I learn best by doing, I thought it’d be fun to do a little rebranding project of my own.

The great thing about living in a city is that there are small, mom-and-pop businesses everywhere you look, and it is rare when you find one that has both a good identity design and a functional, usable, mobile-friendly website. I can’t tell you how many times I’ve walked by a menu posted in a restaurant window and wanted to redesign it for usability—or yeah, okay, maybe just do it so I have an excuse to use some of the fonts I collect.

So I picked a business in my neighborhood to rebrand: Dartealing, a tea room (see above) with a logo I could try redesigning, a menu I could typeset, and a website I could make responsive.

And no, before you ask, they don’t have any idea that I’m doing this. I just picked them because tea.

The goals

A logo design book I’d read recommended starting out with an ideation exercise: a free-association mind-map used to collect inspiration and aspiration, a sort of formless manifesto. Out of that came the following goals for the design:

Elegant
Timeless
Appealing to both sexes
Relaxing
Unpretentious

The solution

Using a mix of traditional and modern design elements, I came up with something that I’m rather pleased with, and that more importantly I had fun building. Read on to see what I did and how I did it.

Color

For new web projects I usually start at palette generator sites like Adobe Color (the artist formerly known as Kuler) and grab a five-color palette to start from. I was looking for colors that were vibrant but soothing, sophisticated, and modern. Here’s where I began:

hope springs eternal by hyoung

But five colors aren’t enough for most projects with a web component, so one thing I’ve taken to doing in the last few years is taking that initial palette and expanding it out to 20 colors. I like to do it by building a custom color wheel and following these guidelines:

Ten main hues, each represented by two shades: one intense and one muted.
Arrange the colors like a pie chart. Each color should go well with its immediate neighbors.

Full color palette

Logo

The logo comes in three color treatments and two orientations: full color, monochrome and monochrome inverse (for use on dark backgrounds), each in horizontal and vertical layout.

Logos

Business cards

This is my favorite part of the project, and I think the part that best shows the mix of traditional and modern that I was going for:

Back	Front

Tea packaging

These labels are designed assuming that they will be affixed, front and back, to a vacuum-sealed zip-top bag containing the tea sold. There are five types of labels, one for each category of tea the shop sells.

Front	Back

Finally, the website

This bit is where I had the surest footing, but I definitely learned from the experience. The first order of the day was to make it responsive:

Website at various screen sizes

But I wanted to go a bit further and, well, optimize the hell out of it, based on some tricks I’d learned at An Event Apart the previous week. I ended up doing pretty well, according to webpagetest.org:

Performance score

I actually did put the whole subdomain under a DNS-level CDN, but it seems webpagetest is just looking for certain base URLs for asset fetches…well, I’ll stop yakking and let you see for yourself.

There it is, and there it was

So that’s it. I felt like I got a lot out of it, primarily since it was the first time I’d done a soup-to-nuts identity design and development project—special thanks to the friends who were kind enough to take a look part-way through and give me feedback. I definitely need more practice, but I think it went rather well. Most of all, I had a great time doing it. Thanks for reading.

Link brew MacVim against brew Python

2014-08-26T19:21:00-07:00

I’m constantly tinkering with my environment; I’m on an endless quest to simplify and automate it as much as possible. Between my shell, my editors and my window management solution, I’ve got things running pretty smoothly now…for the most part. Recently, my brew-installed MacVim had been giving me fits—seg faults right and left. Here’s how I solved the problem.

As it turned out, the problem was that brew MacVim only links against the system Python, and I had a brew-installed version of Python. When trying to launch MacVim, Bad Things Happened. I spent far longer than I care to remember Googling for a solution, and found a few differing recommendations. By cobbling them together—and a fair amount of trial and error—I was finally able to get it to work. Here’s how you can do it too:

Create a soft link to the python config directory:

1
2
cd /usr/local/lib/python2.7
ln -s /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/Current/lib/python2.7/config config

Edit the brew Macvim formula: brew edit macvim, then add the following configure flags under elsif build.with? "python":

1
2
--enable-pythoninterp
--with-python-config-dir=/usr/local/lib/python2.7/config

Add a soft link to the python include directory to make Python/Python.h accessible:

1
2
cd /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/Current/include/python2.7
ln -s `pwd` Python

Finally, make sure linking and building flags are the same when installing:

1
DYLD_FORCE_FLAT_NAMESPACE=1 vi_cv_path_python_plibs="-L/usr/local/lib/python2.7/config -lpython2.7 -ldl -u _PyMac_Error" brew install --verbose macvim -- python

css3-foundation updates

2014-07-05T08:13:00-07:00

I’ve made quite a few updates to my css3-foundation project of late. If you’re not familiar with it, it’s a Compass-based CSS3/HTML5 framework I built at my last place of work for bootstrapping web development projects.

You might ask: “Why yet another framework? Aren’t Twitter Bootstrap or Zurb Foundation good enough?” I’m going to give the asshole answer: they’re more than I need. It’s not just that, though:

I still believe strongly in separating content from presentation. I don’t like littering my markup with a million presentation-related classes when I’m already using Sass; I prefer to keep my markup clean and readable and use Sass mixins instead. This means I don’t really believe in SMACSS. Yeah, I said it.
Outside of rapid prototyping, I feel the frameworks have limited use. You can spot a Bootstrap site from a mile away, and chances are that your production application, past the initial get-it-working stage, needs its own, unique visual identity, which you won’t achieve on one of these frameworks without significant customization. If you’re already spending so much time customizing the look and feel, why not just start from a lighter baseline and build from there?

So what I’ve done is build that lighter baseline, which has what I need and no more:

A master page layout with JS and style includes structured where and how I want them
Basic styles and a framework of variables that I need to modify to set the baseline: colors, fonts, layout.
Mixins for stuff I use all the time, like retina image backgrounds, common font size/line height combinations, inline lists.
A responsive grid for rapid prototyping when needed; I’ve chosen to go with Susy.

Everything else, I tend to change from project to project, so I leave that alone. This approach works for me; your mileage may vary.

All that said, this project continues to be the front-end baseline of every web project I start, and I’m constantly tweaking it as I find things that work well, and to take advantage of new techniques I learn. Recent updates to the css3-foundation project include:

Adding support for Guard, LiveReload and Pow.
Upgrading the icon font mixins to use Rico Sta. Cruz’s icon-fonts project
Replacing the retired 1140px CSS grid with Susy

Try it out; let me know what you think.

It’s over between me and WordPress.

2013-11-10T02:48:00-08:00

WordPress and I are through. We’d been together a long time, but things had started to go sour: it was needy and high-maintenance, susceptible to the wiles of passing charlatans, and finally I’d had enough. I told it “so long” and went off to find greener pastures.

While I was at it, I decided to start totally fresh. I dumped almost all of the content I’d been building up over the last 8 years, and kept only the articles that people were reading. I’ve also switched to—in true neckbeard fashion—a static site generator that will enable me to use version control on the site’s content, and the Rails Asset Pipeline for its structure. This new site is built on Middleman, because I’ve done the Jekyll thing and was looking for a pasture greener than that.

So far, so good. Look for a more detailed post in the near future about the migration and setup.

The IE7 hover ghost bug

2009-07-14T00:00:00-07:00

Ran into this one today, in somewhat unusual circumstances: I had a hover style where buttons inside a table row only appeared when the mouse was over the row, and if you clicked on one of the buttons but moved the mouse into another row before releasing the mouse button, the previous row would stay highlighted.

The authoritative writeup of the bug, and most others, refer to the problem happening with dynamically-displayed submenus, but make little mention of my particular problem. There was some hope that triggering hasLayout would fix the problem, as it’s the closest thing we have to a magic bullet, but it (shocker!) didn’t work for me.

What did work for me was reverting back to the brute-force method one had to use for older versions of IE: using JavaScript onmouseover/onmouseout events to trigger a hover style¹ rather than the :hover pseudoclass. So much for IE7 implementing :hover on non-anchor elements. Sigh.

¹ See the first comment. And shame on you, Webmaster World, for not having permalinks to the comments. Get a load of their generated source, too: they’re still using font tags. Seriously?! And this is a resource for webmasters? Come on.

Speed up Mail.app

2009-07-06T00:00:00-07:00

In these times of effectively unlimited quotas, there’s no need to ever delete email. And I don’t—all my various accounts’ inboxes combined add up to somewhere around 20,000 emails. Having all your emails is great, but accessing them quickly is at least as important as having them on hand. However, of late, I’d been experiencing some severe performance problems in Mail.app—it was taking literally on the order of minutes for Mail to start up and shut down for me. Just brutal.

Today, in an effort to alleviate some of that pain, I stumbled across a solution that worked magnificently for me: cleaning up Mail.app’s SQLite database.

Here’s how you do it:

Quit Mail.app.
Launch Terminal, then type cd ~/Library/Mail/.
Back up Envelope Index in whatever fashion you prefer. I did cp Envelope\ Index EnvelopeIndexBackup.
Open Envelope Index with SQLite: sqlite3 Envelope\ Index. At the sqlite> prompt, type: vacuum subjects;. Once the prompt returns, type Ctrl-D or .exit to quit SQLite.

This reduces the size of Mail.app’s database and cleans it up, usually to dramatic effect. I reduced my database from ~34 MB to ~22 MB, and Mail now starts up in seconds, not minutes. Boom!

References: procedure and information about the vacuum statement.

IE7 lessons learned: the z-index bug

2008-01-11T00:00:00-08:00

The IE z-index bug had been around since IE4 or 5, and was finally fixed in IE8. It’s still an issue in IE7, however, and chances are that you, the web developer, still have to support it. You should read Aleksandar Vacić‘s in-depth characterization of the problem to really understand what’s happening, but what it boils down to is this: the CSS 2.1 spec says that a positioned element with any integer z-index value (i.e. not auto) should create its own zero-based stacking context, and use the integer value specified to decide its place in its parent stacking context. In other words, if the positioned element has a z-index of auto, its stacking context is inherited from its parent. Internet Explorer, however, creates a new stacking context for elements with any z-index value, including auto, which wreaks all kinds of havoc and generally causes mayhem in your previously neat and orderly layouts.

So what does this mean for you? Well, if you, like many people, use any variation of ALA’s Suckerfish dropdown menus on your site, you’ll notice that any positioned element, with any z-index, that is located lower down in the code than the menus will appear above the menus—no matter what z-index the menu is given—exactly the opposite of what you want to happen. If you use IE6 or below, you’ll also see form elements like the infamous IE select box appear above the menu.

Now you know what the problem is, let’s talk about how to work around it. If the problem you’re having is with form elements bleeding through, one of the solutions described here, specifically Hedger Wang’s solution (placing your menu above an iframe with a z-index of -1), should fix you right up. Unless, of course, you have subsequent positioned and z-indexed elements in your code. Then it becomes a lot harder.

And, surprise!, that’s exactly the problem I had. I had a bunch of relatively positioned UI widgets with absolutely positioned children, each with its own flyout menu of actions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
a
{
  color: black;
  text-decoration: none;
}

#main
{
  margin: 50px auto;
  padding: 10px;
  width: 350px;
}

.block
{
  position: relative;
  margin: 0px 0px 10px 0px;
  width: 100%;
  height: 25px;
  background-color: #e0d0d0;
}

.badge
{
  position: absolute;
  top: 0px;
  left: 0px;
  width: 21px;
  height: 21px;
  background-color: white;
  border: 2px solid #c0b0b0;
  color: #c0b0b0;
  line-height: 21px;
  text-align: center;
  font-size: 13px;
  font-weight: bold;
}

.info
{
  position: absolute;
  top: 0px;
  right: 0px;
  left: 25px;
  bottom: 5px;
  padding: 0px 5px;
  background-color: #f0e0e0;
  border: 1px solid #f0d0d0;
  line-height: 18px;
}

a.menu-activator-arrow
{
  display: block;
  position: absolute;
  top: 0px;
  right: 0px;
  width: 20px;
  height: 18px;
  background-color: white;
  border-left: 1px solid #e0c0c0;
  line-height: 18px;
  text-align: center;
  color: #c0a0a0;
  font-weight: bold;
  text-decoration: none;
}

a.menu-activator-arrow:hover
{
  background-color: #a07070;
  color: white;
}

.menu
{
  position: absolute;
  top: 19px;
  right: 0px;
  z-index: 10;
  background-color: #f0f0f0;
  border: 1px solid #a0a0a0;
}

.menu ul
{
  margin: 0px;
  padding: 0px;
  list-style: none;
}

.menu a
{
  display: block;
  padding: 2px 5px;
}

.menu a:hover
{
  background-color: #808080;
  color: white;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
<div id="main">
  <div class="block">
    <div class="badge">Ad</div>
    <div class="info">
      some info
      <a class="menu-activator-arrow" href="javascript://">v</a>
      <div class="menu" style="display: none;">
        <ul>
          <li><a href="javascript://">choice one</a></li>
          <li><a href="javascript://">choice two</a></li>
          <li><a href="javascript://">choice three</a></li>
        </ul>
      </div> <!-- /menu -->
    </div> <!-- /info -->
  </div> <!-- /block -->

  <div class="block">
    <div class="badge">Ad</div>
    <div class="info">
      some info
      <a class="menu-activator-arrow" href="javascript://">v</a>
      <div class="menu" style="display: none;">
        <ul>
          <li><a href="javascript://">choice one</a></li>
          <li><a href="javascript://">choice two</a></li>
          <li><a href="javascript://">choice three</a></li>
        </ul>
      </div> <!-- /menu -->
    </div> <!-- /info -->
  </div> <!-- /block -->

  <div class="block">
    <div class="badge">Ad</div>
    <div class="info">
      some info
      <a class="menu-activator-arrow" href="javascript://">v</a>
      <div class="menu" style="display: none;">
        <ul>
          <li><a href="javascript://">choice one</a></li>
          <li><a href="javascript://">choice two</a></li>
          <li><a href="javascript://">choice three</a></li>
        </ul>
      </div> <!-- /menu -->
    </div> <!-- /info -->
  </div> <!-- /block -->
</div> <!-- /main -->

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// When the DOM is ready,
$(function() {
  /*
  ** For each link with class "menu-activator-arrow" inside
  ** an element with class "block",
  */
  $(".block a.menu-activator-arrow").each(function() {
    // When that link is clicked,
    var $link = $(this);
    $link.click(function() {
      // Show or hide the element with class menu that follows it.
      $link.next(".menu").toggle();
    });
  });
});

And it looked like this in IE7:

The upshot of Vacić’s article is that the relatively positioned parent of your absolutely positioned menu should be given a specific integer z-index that is higher than those of subsequent positioned elements on the page in order to ensure that your popup menu appears above all other elements. However, that requires you to know precisely how many relatively positioned elements are in the page, and to manually assign a z-index to each. But in the context of my application, these widgets were dynamically generated and I didn’t know how many I would have. So how did I deal with it? The brute force way. After all the widgets had been loaded, I searched for all divs with class block, and iterated through the list, assigning subsequently smaller z-indexes to each, thereby enabling the menu belonging to the topmost widget to appear above all subsequent widgets:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
function isIE()
{
  if(navigator.userAgent.match(/MSIE \d\.\d+/))
  {
    return true;
  }
  return false;
}

function zIndexWorkaround()
{
  if(isIE())
  {
    var zi = 1000;
    $(".block").each(
      function() {
        $(this).css("z-index", zi--);
      }
    );
  }
}

But that’s a bit ugly. Vacić himself suggested a more elegant solution: just dynamically increase the z-index of any positioned ancestor element when your mouse is over it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
function zIndexWorkaround()
{
  // If the browser is IE,
  if(isIE())
  {
    /*
    ** For each div with class menu (i.e.,
    ** the thing we want to be on top),
    */
    $("div.menu").each(function() {
      // For each of its ancestors,
      $(this).parents().each(function() {
        var $ancestor = $(this);
        var pos = $ancestor.css("position");

        // If it's positioned,
        if(pos == "relative" ||
           pos == "absolute" ||
           pos == "fixed")
        {
          /*
          ** Add the "on-top" class name when the
          ** mouse is hovering over it,
          */
          $ancestor.hover(function() {
            $ancestor.toggleClass("on-top");
          });
        }
      }
    }
  }
}

Where on-top is defined thusly:

1
2
3
4
.on-top
{
  z-index: 10000;
}

And then you’d just call zIndexWorkaround() from inside your domready call.

Hope this is of some help.