Adam Merrifield { the collective } » css

How the Time Goes By

Adam Merrifield — Tue, 16 Jun 2009 18:05:26 +0000

How the Time Goes By, originally uploaded by seyDoggy.

My second born child shown here on the day she was born (nearly 6 years ago). It’s looking back on images like these that make you realize just how much changes in such a short amount of time. When I think to back to this moment, I was working as a quality technician at a tool and die shop, programming a CMM, I was shooting weddings on weekends, my son still lived in town, I still lived in the first house I ever bought, I was hand coding websites using tables and some css, I was still using film…

I could write a whole book on the stuff my family has been through in just the last half decade. I dare not think of all that’s changed since my son was born 12.5 years ago.

TextMate Tip: Use Color Picker in All Bundles

Adam Merrifield — Fri, 12 Jun 2009 14:15:48 +0000

After reading this TextMate tip this morning about using the color picker in TextMates CSS bundle, it reminded me of an article I thought I wrote once about extending this same color picker functionality to the other bundles I commonly use in TextMate (namely Property List). After a quick search here and on other blogs of mine, I was unable to find it. So I Googled it and as it turns out, I blogged about it on Flickr of all places. Knowing the information wasn’t of much use there, I thought I had better revisit this tip for the benefit of other geeks.

Use Color Picker in Other Bundles

So here is the gist of it; in the CSS bundle in TextMate you can quickly pick colors for your CSS properties. This is great, but I do a lot with hex colors in other bundles too, like the Property List, Javascript and jQuery bundles. So here is what I did…

I opened the Bundle Editor (⌃⌥⌘B), went into the CSS Bundle, found the “Insert Color…” command and made a copy of it (it’s the ++ icon at the bottom of the panel). I selected and renamed the command and changed it’s Scope Selector from “source.css” to “text, source”. This will enable color picker for just about everything. “text” will cover all of the plain text based languages like HTML, XML, Property List, Markdown, BB Code, LaTeX, etc… While “source” will cover all the programatic languages like CSS, Javascript, PHP, Ruby, etc…

Now keep in mind that this particular command is going to add the hash (#) as a prefix. This may not suite you needs for some languages so you may choose to make another “Insert Color…” command for those languages and modify the appropriate lines, then use “source.actionscript.2″, for example, as your Scope Selector.

Play around with the poosibilities and have fun.

FireFox CSS Hacks

Adam Merrifield — Fri, 13 Mar 2009 16:28:25 +0000

Sometimes it’s not Internet Explorer, and sometimes it’s not FireFox… Sometimes it’s (gasp) Safari. I always develop for Safari and then fix everything else but sometimes, just sometimes you come across a situation where IE7, IE8 and FireFox 3 all render the same way. By law of averages, wouldn’t that mean that Safari has it wrong? Well let’s not jump to nasty conclusions, that doesn’t prove anything right?

Well regardless, I’m not about to start hacking for Safari (on moral grounds), so that leaves CSS hacking for IE7, IE8 and FireFox 3 (IE6 is just a given so were not going there). IE7 and IE8 are dealt with well enough using condition comments, or for example, but CSS hacks for FireFox are a different beast.

Some time ago I stumbled across this guys trick that goes something like this: #yourSelector, x:-moz-any-link {styles for Firefox 2.0 here} #yourSelector, x:-moz-any-link, x:default {restore styles for Firefox 3.0 and newer}

You can read more about it there, but in short, the :-moz-any-link is a private Gecko selector that other browser just ignore. Be warned though, it doesn’t validate so you’ll want to move it out to a javascript file or something if you are concerned about that sort of thing.

I don’t use this that often (only once before in fact), but it sure is handy to have in the toolbox sometimes.

Control your processors in Mac OS X 10.5

Adam Merrifield — Sat, 07 Mar 2009 15:02:53 +0000

Remarkably after nearly one month I am still trying to tweak my system just so. I think this is one of the last things though, my processor preference pane. By default, the CPU controls in Mac OS X 10.5 and not enabled and in fact, can’t be enabled unless you have the developer tools installed.

I like to be able to turn off some of my processors when I am just doing day to day web design and theme development. It’s a good way to save some energy (it’s good to be green) and to be totally honest, coding in HTML, CSS, PHP, Javascript and XML isn’t all that processor intensive. With the developer tool installed you can do this. There two things you can do, you can run the CPUPalette.app and/or you can install processor preference pane.

The CPUPalette.app can be found in /Library/Application Support/HWPrefs/. It’s a simple app that doesn’t allow much other than turning the processors on or off. If you click the little pill button in the top right-hand corner you can see a couple of basic preferences for window type, sampling rates and information display. It’s a quick and easy way to both monitor how your cores are being taxed and whether or not you can afford to shut a few of them down.

Your other option, if you you are already familiar with your processor usage, is to install the processor preference pane. Go to /Developer/Extras/PreferencePanes and find Processor.prefPane. Double click to install it. Once installed I highly suggest you click the “Show control in menu bar” for quick access. You’ll notice by installing the processor preference pane you get access to the CPUPalette.app without having to dig for it.

I Give Apples New Safari 4 Beta a Spin

Adam Merrifield — Tue, 24 Feb 2009 15:34:04 +0000

Apple announced today the launch of their Safari 4 beta program that claims to lead the way with innovation. I had to test this claim so I immediately downloaded it and gave it a spin. Here are my findings:

On initial launch you are presented with the “Top Sites” window in which it appears that Safari scours your history for the most frequently visited sites in your recent cache and then throws up their thumbnails in a Core Animation like black gallery for you to pick from. Selecting the edit button allows you to remove items and make others sticky. I presume you can also add others that might actually be more indicative of your “Top Sites”. Again, in true Apple form, Apple seems to be hinging the success of a product on visual wow factor, but admittedly I could see myself making use of this.
My next reaction was when I created a new tab and found that, a la Google Chrome, the tabs are on top. Why? While I will most certainly get used to it, what is the actual reason for this? I can’t find and difference in their functionality apart from the fact that you can only drag them about from their corner. Aside from that you can still drag them, move them from window to window, create a new window with each tab… there is one option I hadn’t noticed in previous version, “Add bookmark for these X tabs”. Is that new?
Coverflow in Safari… there have been a few plugins to address this in the past. I guess they are history now. Do I need Cover Flow in Safari? I don’t need it iTunes or Finder so I probably won’t use it here either. But that said, it must be a popular enough technology if they keep throwing it in to their software.
History search. Now that I like! I have always found searching the the history in the bookmarks folder to be painful and unproductive. This history search is insanely fast and (in Cover Flow form) even shows you screen shots of the sites that match your search terms.
It claims to be faster, using the Nitro Engine. It could be but browsers and web technology today is getting so fast I would be hard pressed to notice the difference. It does seem to be faster overall but am I reacting to the guts of a finely tuned OS X Cocoa application or the page load? One note I will make about making browsers faster (and Safari 3 is already guilty of this), they cache things… unnaturally so which can make web development a nightmare. Safari 3 already caches it’s javascript and images in ways that cause web developers to have to reset their browsers all too often just to get an accurate response on their new projects. And faster also means pre-load, again which Safari 3 is bad for. Safari 3 will scour your main CSS file in search of things to load (like background images), whether or not that thing is actually needed or even being used. I hope Safari 4 handles this a little better.
The newish developer tools are nice (if your weren’t already playing with them in webkit), but I don’t know… it’s still not FireBug. You still can’t select code in the element window! How good is debuggin if I can’t edit what’s there or even copy and past it to a text editor? Seriously? As far as developer tools, these will give a glimpse into how your page is working, but they’re not much good for anything else.
The full page zoom could be useful (hopefully not for a few years for me yet), but wow does it ever slow things down. Zoom in once and try page scrolling… not so fast now.
I love, love, love the new address bar! If I am going to interface with browser in any way, it’s through the address bar so this improvement is quite welcome. Basically when you start typing in the address bar you are presented with much the same information your were before, but it’s clearly defined in two categories; history and bookmarks. In both cases it presents you with the site title followed by the URL which makes it very easy to get your bearings.
The search field is now really slick too. It’s along the lines of Inquisitor, offering you suggestions and previous search queries. Very nice!
CSS Animation, CSS Effects, CSS 3 Web Fonts… just more things to tease us web developers with. Stuff we won’t be able to use in the real world until all other browsers catch up. We can always dream though…

Overall, I think this is two things combined; a promising look at where web browsers should be and a sobering reminder of how much waiting for other browsers to get there will suck.

To be Strict or not to be

Adam Merrifield — Wed, 05 Nov 2008 14:35:00 +0000

I am about to geek out so bad it will make your eyes roll back and have you snoring before you finish the first paragraph. But to be honest, it’s not for you that I write this stuff, it’s for posterity and so that I can always look it up in the future, if such a thing should ever happen to me again.

I have finally nailed down an obscure little bug in cataLog (and in turn Acumen) that was causing the second level navigation to jump up about 14 or so pixels when the user used the “Tidy” setting in RapidWeaver and when the user used code or content that tripped the “Tidy” setting into converting the document into a Transitional DOCTYPE. The reason the bug remained so illusive is that this set of circumstances was not immediately clear and is not necessarily something the end user is mindful of.

My repeated testing, assuming that there had to be a difference in the content area or navigation area, kept leading me down the wrong path. One assumes, when “Tidy” is at work, that the HTML of the document is somehow being altered or “tidied up” as it were. And this is where I continued to search extensively but came up empty handed every time. Having exhausted nearly all HTML avenues and having run countless DIFF comparisons I finally turned my attention on the one thing in each document that I knew was different; the DOCTYPE. By simply switching the DOCTYPE from Strict to Transitional, regardless of whether the embodied code was in fact one or the other, I could trigger this odd navigational occurrence.

As much as this was a major breakthrough in the tracking of this bug, I now knew that the game had gotten that much more complex. I was no longer dealing with a bug in my code or the theme as a whole. I was now dealing with what was potentially a rendering bug, or interpretational difference in the two DOCTYPE’s, meaning that the bug being presented may very well be an issue in the HTML standard itself. Eeek!

Since I knew that the navigation in question uses inline-block as a value on its display property, and since I am well aware of the lack of widespread support that inline-block has among browsers, I knew that this was probably the place to look. I need to look in the CSS of the second level navigation.

Through considerable trial and error I found that an attempt to display the ancestor, or hidden navigation inline was what was causing the trouble. In DOCTYPE Strict, the combination of ul {display: inline;} and ul ul {dispay:inline-block;} caused the initial ul to have height, despite having tried to suppress it with ul {height:0; margin:0; padding:0;} etc… While in DOCTYPE Transitional, the initial ul rendered correctly (which is to say it didn’t render at all and had no height), so the latter ul would shift up to takes it’s position. The fix was simply this: ul {margin:0; padding:0;} with no attempt at any display value other that what it would naturally inherit (which would be “block”).

So is this in actual fact a bug in the Strict DOCTYPE standard? It’s hard to say really. In the making of RapidWeaver themes, we pour a lot of effort and trickery into making things happen the way we want them too. In the case of split navigation we use the same set of code in multiple locations and simply turn on or off the bits we want shown or hidden. This probably is not a typical practice in web design but a necessity in RapidWeaver theme development. Still, why would one DOCTYPE behave differently from another where such a small property in concerned?

RapidWeaver's %pathto%, TextMate can help

Adam Merrifield — Fri, 10 Oct 2008 17:06:00 +0000

It’s no secret that many RapidWeaver developers are quite close and help each other out quite a bit. It’s also no secret that in order to develop RapidWeaver themes you need to use some pretty powerful tools. Some of use TextMate, the most powerful one in my opinion. There are so many ways to extend TextMate’s features to streamline our workflow, one of the simplest is to edit existing bundles by tweaking their commands or snippets or making a command or snippet of your own.

So back to the RapidWeaver developers… recently, Giuseppe at Bonsai Studio shared a TextMate snippet with the other developers. A snippet that would write a very specific RapidWeaver string that we tend to use quite a bit:

I jumped all over this because as you may know I am a huge TextMate nut. However, the snippet didn’t quite run the way I wanted. So I set about to make it the way that was most useful to me. The main difference being that mine would highlight the file path when activated making it an even faster shortcut for me.

But I didn’t stop there. I wanted one that would handle as well. So the result is to snippets that quickly write a

Adam Merrifield { the collective } » css

How the Time Goes By

Related posts

TextMate Tip: Use Color Picker in All Bundles

Use Color Picker in Other Bundles

Related posts

FireFox CSS Hacks

Related posts

Control your processors in Mac OS X 10.5

Related posts

I Give Apples New Safari 4 Beta a Spin

Related posts

To be Strict or not to be

Related posts

RapidWeaver's %pathto%, TextMate can help