A new release of CoLT is now available. Changes include:

• Changed the minimum supported Firefox version to 17.0, since the 10.x line is no longer supported
• Bumped the maxVersion to 30.*
• Various locale updates

Earlier this month, my girlfriend and I set out for yet another visit to a North Carolina state park. This time, we checked out Stone Mountain state park, near the town of Traphill. Stone Mountain is easily one of North Carolina’s most scenic parks, and offers fantastic hiking trails. Several waterfalls can also be enjoyed in the park, along with the site of an historic homestead from the mid-19th century. I’ve posted some photos from our trip, showcasing some of the sights from the park.

By default, Firefox ships with the Use hardware acceleration when enabled option turned on. Unfortunately, Firefox has a number of font rendering bugs under the hardware acceleration umbrella (the following are a select few):

• Line spacing problem with D2D enabled(use hardware acceleration when available)
• Text using hardware acceleration looks inferior to and considerably different from text with acceleration disabled and on other browsers
• Increased line heights with DirectWrite (unlike in IE9)

As a result of these bugs, I’ve run with hardware acceleration disabled on my personal systems for quite some time. This, however, has resulted in an unforeseen consequence with my web development. The apps and pages I’ve developed look great in every browser, except stock Firefox! I only recently ran into this issue when I re-enabled hardware acceleration on my work laptop (in the process of creating a new profile). To my horror, several sites I had developed looked pretty terrible, my photo site being one among them.

I have since rolled out an updated stylesheet to my photo site, fixing the problems that showed up in stock Firefox. It should (hopefully) still look alright in all other browser variants (if you spot a bug, let me know). It’s worth knowing, however, that enabling hardware acceleration in Firefox is a worthwhile thing to do if you develop things for the web. The underlying bugs in the rendering engine may bring out underlying flaws in your design.

I have just pushed out the responsive version of this site’s theme, so you should see it immediately. Though the various tweaks may not be immediately apparent, the experience of this site on a mobile device or tablet (or a smaller screen in general) should be much better than before. Resize your browser window in the horizontal direction to see the style changes in real time!

There are still a few pain points to work through:

1. I’m still a little unsure how to handle the syntax-highlighted code snippets in the various posts around the site. Snippets that don’t use syntax highlighting will word-wrap, but the syntax-highlighted blocks currently just offer a horizontal scroll bar.
2. Various images in older posts need to have their hard-coded sizes removed from the img tags, so that they’ll scale appropriately. This is just a matter of going through and making those changes.

There could be other issues that I have yet to stumble across. From my limited testing, the site looks alright in Firefox, Chrome, and IE-9. I’m sure I’ll be tweaking stuff here and there over the next few days. If you spot problems, please let me know by leaving a comment.

I’m currently working on converting this site’s layout to a fluid, responsive-design variant, which will make the site much more usable on mobile devices (as of this writing, the mobile experience is pretty bad). In my efforts to improve the design, I noted that the browser on my Android phone didn’t respond to my changes at all. The Responsive Design View in Firefox yielded acceptable results, as did the developer tools available in Chrome (which, by the way, are pretty terrible). So why did my phone look so different?

The answer has to do with the concept of the viewport. I found a terrific pair of articles detailing the ideas behind viewports on both the desktop and mobile devices (be sure to read the desktop article first; it sets the stage for the second). It turns out that my page’s header was missing a key meta element, whose very existence we can thank Apple (of all people) for. The tag looks like this:

<meta name="viewport"
      content="width=device-width, initial-scale=1, maximum-scale=8" />

Using this meta entry allows devices to scale their layout viewport appropriately. Adding this one element fixed my phone, causing the site to render as expected. There are other articles that discuss this element better than I could, so give them a look. And don’t forget this one line if you’re designing responsively; it’ll save you a lot of potential headache!

A brand new version of CoLT has been released, implementing a couple of new features and fixing a bug or two:

• Added support for conditional expressions using the %?[] variable
• Added support for importing and exporting custom formats (useful for moving them between systems)
• Improved the way custom format events are handled
• Removed the embedded JAR file from within the extension’s XPI file
• Made a few minor improvements to the installer manifest
• Changed the minimum supported Firefox version to 10.0
• Bug Fix: Newly added separators now properly extend across the custom format dialog

The import and export functionality will make it a lot easier to migrate formats between different Firefox installs. Similarly, the new conditional expression support makes it very easy to include text in your custom formats that only appear if a particular variable has a value. I have updated the custom format documentation to discuss how to use the new conditional variable option. If you spot any problems with this release, leave a comment and I’ll address them as quickly as possible.

I have decided to start using the SyntaxHighlighter package here at this website, to make various code snippets a little easier to read. This package really appeals to me since it supports a number of languages, has a graceful fallback mechanism, and looks nice. Rolling out these changes will be slow, however, since I have to go through and apply some styling to all the appropriate code blocks. As always, let me know if you spot a problem with this new feature.

I just realized that a number of posts that were imported to this site from my old blog are missing backslash characters. After doing some investigation, I found out that there’s an associated WordPress bug (Ticket #21007) against the importer utility. Apparently, backslashes aren’t preserved as they should be.

I’m working to fix all of the relevant posts and comments. When I’ve completed this task, I’ll update this post.

Update: I believe I have fixed all of the relevant posts. If you spot a problem somewhere, let me know!

Version 4.9.7 of Googlebar Lite has just been posted, fixing the following issues:

• Various internal code improvements
• Bug Fix: Disabling the “Remember last combined-menu search type” option will now reset the combined search button properly
• Bug Fix: Doing a news search when no search terms are present will now take you to the Google News homepage as intended

To me, the single most helpful feature in CoLT is the custom format. Being able to copy link text and URLs as either HTML, Markdown, or whatever else is a real time saver. That said, I think there’s still some room for improvement in what CoLT can do. Let’s take a look at an example.

Among others, I have the following two custom formats in my current Firefox profile:

• Markdown – [%T](%U)
• Markdown (Selected) – [%S](%U)

The first format copies the link text along with the link URL, while the second uses any selected text in place of the link text. Both of these options are handy to have, but I’m forced to have two custom formats for something that one ought to be able to do. I also have to remember when to use each one.

Problem 1: Conditional Formatting

I would love to be able to combine the two formats above into one rule, resulting in something like the following: [%?S|T](%U). In this theoretical example, selected text would be my first option, but if no text was selected, the link text would be used as a fallback.

Problem 2: Optional Text

One CoLT user suggested a similar scenario for including optional text in the copied value. Consider this example using a differing conditional syntax: [%T](%U)%[I (%I) ]%

Here, everything between the %[I and ]% would be optional, assuming the nested %I had no value. This would allow users to insert conditional text in formats for values that may not always appear (such as the %I option, which maps to a link’s title text). However, the suggested syntax somehow seems more ugly and error prone.

Food for Thought

As a result of these usage scenarios, here are some questions for you:

1. Is there an elegant, concise syntax that could be used for these two scenarios? I prefer the question mark-style syntax in problem 1 to indicate conditional formatting (it’s concise), but it doesn’t seem to solve problem 2.
2. Given this kind of capability, would you actually use it? I can think of a number of scenarios where it would help me, but do others see the same kind of thing?

Any and all comments on this topic would be appreciated. And if you see ways to improve what’s already present in the extension, let me know!