July 2006


Optimizing CSS definitions

The problem: a number of people are working on the same (set of) CSS file(s) for a web site, and strict class and id naming standards have not been created and enforced. This has led to a proliferation of somewhat meaningful but overall ambiguous labels for CSS ids and classes and selectors. Some of the selectors conflict with each other, and these overlapping declarations are causing unexpected results in the page rendering. Your task is two fold:

  • create a list of the selectors of all CSS rules from every CSS file
  • find out which declarations possibly conflict with each other so they can be examined manually to see if the conflict can be resolved and/or the CSS file can be optimized by consolidating declarations


Continue Reading »

undistracted writing with writeroom

Now, here’s an interesting product: writeroom. What strikes me is how similar writeroom’s screenshot looks like a green screen vt-dumb-terminal. I’ve long since written things like term papers and large documentation projects in vi (well, really vim, or whatever passed for a vi substitute on CX/UX back in the day at DePaul), originally on vt52 and vt100 terminals, writeroom's main screen mainly because the interface of things one would actually call “word processors” lend themselves to constant tweaking with the document’s look rather than making you focus on the content. It’s amazing how the speed, quality and content of my writing improves when written in vi. Once the content is written, the act of importing it into some kind of markup program (read “Microsoft Word” in the computer labs the hour before it was due) to do final formatting and print it out was a breeze. These days, I prefer a little more semantic control over the document than that which plain paragraphs of text afford, so give me a wiki syntax (I’m used to twiki, but mediawiki is starting to grow on me, since it handles nested structure pretty well) and a way to convert it into a renderable mark up. Using XHTML temps one to constantly load the document into a browser to see how it “looks”. It is defintely much easier to concentrate on the content, structure, and meaning without a bunch of GUI doodads and reload buttons begging to be clicked. I notice that in WordPress, every time after I hit “save and continue editing”, I scroll down and check out the preview. This has caught the odd mistake or two while I’m writing, but it definitely gets me out of the writing state and into the reviewing state more often than not, and this can be an expensive context switch.

writeroom apparently takes that to the next level, removing all other computer-based distractions — distractions that most likely had marketing literature claiming they would make you more efficient and productive (oh, the irony).

Interestingly enough, I find myself switching between full-screen terminal windows (or a series of tiled terminals) and GUI tools like gedit these days, because it’s hard to cut and paste a large document from vi in an xterm into an HTML textarea. And I’m not sure I want to take the plunge into a GUI based vi, since that seems to taint the purity of text editing. But vi-style keybindings in every application would be a most welcome experiment.