Use RapidWeaver's %pathto()% syntax in javascript files

It may take me a while sometimes, but there is one simple truth about my workflow, I always strive to have the most efficient way of getting things done. This is especially true in RapidWeaver theme development. Developing themes for RapidWeaver is not like standard web design. You have no way of knowing how each user will structure their site, what plugins they'll use, what they'll add to their pages... All of these uncertanties leave us as developers scratching our heads sometimes, trying to sort out ways of dynamically including things and stuff without the end user being able to break it.

PHP would be the obvious choice here, but we don't have the luxury of knowing what the end users hosting environment will be and whether they could, or even would be willing to support a host of PHP functions. So the next best thing is javascript; yes it's a little slower and it does depending on the end user having javascript enabled, but the ubiquity of javascript has never been as great as it is today.

One thing that has plagued RapidWeaver developers for some time is how to utilize RapidWeaver's %pathto()% syntax, the bit of code that allows RapidWeaver to imprint the end users chosen common file path, in any other file other than the index.html template file. For any javascript file that has required the inclusion of another file, we've previously had to fill our html with scripted variables for each file, each using the %pathto()% syntax and so forth until we have built a separate path to each file from outside our javascript that actually requires it. Since RapidWeaver will only write the path to files it can actually find, you need to do this for each and every file.

Today I had an AH-HA moment while in need of multiple paths to be defined for use in various javascript files. I decide to write a small bit of code that grabs RapidWeaver's %pathto()% syntax while it chases a real file. Then I strip out the actual file name, and KABLOW! you have a common file path in the the form of a javascript variable, ready to be used in any javascript file you like.

Download the bit'o code here.

Realmac Software release LittleSnapper/QuickSnapper one-two punch!

Realmac Software has just made LittleSnapper official, bringing this very powerful screen and web snapping app out of beta and into the general public. I've been fortunate to be playing with this app for a week or so, putting it and it's integrated web service, QuickSnapper through their paces. This isn't just you normal screen snapping app. It's a lot more than Skitch (which has never left it's apparent state of perpetual beta) and has many advantages over it (with one or two slight disadvantages). And the web service, not unlike ScrnShots is a robust and attractive place to be and get inspiration.

LittleSnapper allows you to treat a collection of screen and web snaps more like a library, and iPhoto Library if you will, allowing you to tag them, rate them, make notes and annotations, view the source code for web snaps. This gives you not just a library of images, but a tool box of thumbnails complete with source code for studying, origins, ways to note what you liked about it, etc... There really isn't many things to compare it to. It is one of those trend setting apps that has more or less made it's own niche. Certainly a web designers must-have app.

And then there is QuickSnapper... While at first glance, it's not all together different from what other similar scree/web shot sites are doing and on it's own it wouldn't be particularly exciting (except that it looks damn sexy). What set's it apart though is that it was built to support the LittleSnapper app, and not built the other way around. That's where these other screen/web snap sharing site have gone wrong in my books. They've built the site and now in order for you to get your stuff up there, they've made a half baked "utility" that will, if you are lucky, let you upload something... sometimes.

QuickSnapper, on the other hand was built with LittleSnapper integration in mind... exclusively. With the click of a button, LittleSnapper loads up a snap to your account. In turn, with the click of a button on QuickSnapper, you can pull down a shared snap into your own LittleSnapper library... click... that's it! A complete, happy snapping, bio circle of screen and web snapping goodness. Does it get any better than this? Me thinks not!

Oh, and BTW, the screen grab of LittleSnapper? Yeah that was taken with LittleSnapper and is hosted on QuickSnapper...

From pixels to paper, we're getting noticed

There is no greater flattery than to be made an example of so when we were asked some time ago if we would consent to being published in DesignMeltdown's, The Web Designer's Idea Book, I was truly honored.

Today, I received my copy in the mail and was thrilled to find these kind words on page 102 along side a screen shot on page 103:

"A great example of a unified design is the seyDesign site. It has an office theme, and everything flows together perfectly. The corkboard background creates a terrific foundation to tie the site together. It essentially gives the office supplies a place to exist."

Of course this isn't how the site looks today, but for this 2007 iteration of seyDesign.com to be forever immortalized in print is a true sense of accomplishment. All in all, RapidWeaver developers as a whole had a good showing in this book with various sites. Adam from Elixir Graphics has already written about his contributions. and I've heard there are more, I just haven't had time to look through each page yet.

To get yourself a copy of this most excellent web design resource, go to Amazon.com.

To be Strict or not to be

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?

seyDoggy is back in the office.

We are back from or little vacay, and back on the horse, if you will, working through a pile of emails and such. On our agenda this week is to address a few bug issues in some of our RapidWeaver themes, namely a footer issue in wideNas, and a couple of mystery bugs that occasionally rear their head in cataLog and Acumen. We should have all of these addressed this week with their respective update installers ready for download.

And as always we are ever moving forward and onward with the theme developments and ideas. We have quite a list of them to get through over the next year or so so you can be sure to see one or two new themes from us every month. Yes that is an ambitious plan, but this is what we do after all, we might very well be the only full time RapidWeaver theme developers now who do nothing else.

And speaking of RapidWeaver, did you notice that RapidWeaver 4.2 has been released? Yes indeed. I have not yet tried it myself, but I have downloaded it and will be getting into it shortly. Learn more about it's release here.

We're off to London!

I'm off to the UK for a bit of a holiday. We take flight at 9:40 pm October 23 (that's today) and will be gone for about 10 days. We'll be back to answer your support questions on the week of November 1st. Remember that if you have any major concerns between now and then you can always try posting them the the Realmac Software forum and I am sure one of the kind and knowledgeable folks there will help straighten you out enough until I get back.

We'll try to keep you posted on our daily outings. That's likely to occur on Twitter so if your inclined to keep tabs on the leisure time of a theme developer geek like myself then you can come follow me.

Anyhow, stay safe and we'll catch in a few days time.

RapidWeaver's %pathto%, TextMate can help

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:

<script rel="stylesheet" type="text/css | text/javascript" src="%pathto(script/filename.file)"%></script>

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 <link> as well. So the result is to snippets that quickly write a <script> string and <link> string that include the %pathto% syntax.

So if you are a heavy TextMate user and happen to develop RapidWeaver themes then you might be interested in these two snippets.