15 years. Yep, that’s a long time. In fact, it’s so long that it’s hard to remember “not” working for Adobe. But as of May 4th, I will be leaving the “big red A” to set off on a new adventure. I’ve accepted an offer to join Stremor, a start-up here in Phoenix as their VP of User Experience Engineering. In addition to making coffee, putting Ikea furniture together, and other typical start-up jobs, I will be putting my HTML5/CSS3/JS chops on the line building a real product! Sadly, I can’t tell you “what” it is yet – that’s all still hush, hush – but I can tell you that it’s so amazing, we’ve already got patents pending! Oh, and we’re also looking for great developers!

As I began debating whether to make the move, I got pretty sentimental about the last 15 years – so much so, that I almost chose not to go. Thanks to GoLive/Macromedia/Adobe, I’ve gotten to help build tools that literally have changed the (web) world. I’ve also had the good fortune to travel around the world more times than I can count and accumulated frequent flyer miles and hotel points that will take years to use up. And along the way, I also got to meet and work with some truly amazing people, including my incredible wife, Stephanie Rewis. I want to thank you all – my colleagues, friends, travel buddies, conference attendees, et. al. – for so many great memories. Chili crab in Singapore, tuk-tuk rides in Dehli, climbing the Sydney Harbor Bridge, dinner at Carnivores in Johannesburg, standing naked in a hotel hallway in Seoul (don’t ask), horizontal rain/ice in Helsinki in February(buuurrrr!), far too many beers at the Oktoberfest, sitting in the MacWorld green room with Steve Jobs, getting to fly with Paul McCartney – and so many, many more!

It’s been an amazing ride and I would be lying if I said that I won’t miss parts of it (expense reports excluded). I hope to still be asked to speak at conferences (hint, hint), and I will definitely be writing here and twittering there – it’ll just be less Dreamweaver and Adobe stuff, and more HTML5/CSS3/JS – and you’re all still invited to come hang out on Geeks4Sail. But, I’m also excitedly looking forward to the new challenges that come with change – and even better, I get to carpool to work with Stef (our offices are literally one mile apart)!

So, to my soon-to-be former colleagues at Adobe, I wish you all the best! Keep making great products! And to the rest of my readers, I’m not leaving you, so… um… carry on with what you were doing!

*Hat-tip to Leslie Jensen-Inman for the title of this post

When my wife, Stephanie Rewis, decided to leave the gun-for-hire world and join a start-up, she was immediately faced with a decision on which CSS preprocessor to use – Sass or Less. And compounding the problem, her editor of choice, Dreamweaver, doesn’t provide color coding or hinting for either preprocessor – even though their files are really just CSS. So, being the good husband (and evangelist for Dreamweaver) that I am, I set out to remedy the problem. If you’re wanting to use Sass or Less with Dreamweaver, here’s how to make it work.

As always, here’s the disclaimer – you’re going to be editing files in Dreamweaver’s Configuration folder, so proceed with caution, make a backup of the originals, etc.

The first thing that we need to do is to tell Dreamweaver that it’s okay to open a .scss or .less file – something that Dreamweaver by default doesn’t understand. You’ll first need to take a peak in your personal Dreamweaver configuration folder – on a Mac, that’s located in ~username/Library/Application Support/Adobe/Dreamweaver CS5.5/en_us/Configuration – and locate a file named “Extensions.txt”. If, for some reason, this file doesn’t exist, you can edit the master file located in Adobe Dreamweaver CS5.5/Configuration. Open the file and add SCSS (or SASS if you’re using the older syntax) and LESS to line 8, so that it reads: CSS,SCSS,LESS:Style Sheets. Save the file and restart Dreamweaver. You should now be able to click on a .scss or .less file in your Site panel and have it open in Dreamweaver.

Now, in order for Dreamweaver to understand that this, in fact, is a CSS file, you’ll need to edit MMDocumentTypes.xml located in the DocumentTypes folder in the Configuration folder. Open this file and scroll down to line 142. You’ll notice two properties on that line: winfileextension=”css” macfileextension=”css”. Add scss and less (comma seperated) to the appropriate property for your platform. Save the file and restart Dreamweaver. Open your .scss or .less file and you should see your familiar CSS code coloring and hinting!

If you’re serious about your Sass and/or Less, you should be using CodeKit, IMHO. CodeKit, in addition to other things, monitors your scss (or less) file for changes and then compiles it into CSS. I’m using CodeKit and Sass on every project – and loving it! To optimize my workflow, I actually link to the .scss file in my HTML (just remember to remove it before pushing the page live). That way, I can use Dreamweaver’s split view to edit the .scss file while looking at the page with Live View turned on. When I save the .scss file, CodeKit compiles the file into a CSS file that is also linked in my page. Sadly, Dreamweaver doesn’t know when the CSS file is changed, but simply hitting F5 (or the refresh button at the top of the document window) causes Dreamweaver’s Live View to refresh and I can see my changes.

As anyone who has worked in the front-end dev world knows, keeping up with the “new” stuff is challenging. Thankfully, the browser makers have provided vendor prefixes which allow us to use a lot of the new CSS3 properties before they are finalized. But thanks to a reader of my blog, I was made aware that Chrome (version 16), as they removed the need for a prefix on border-image, has also changed the way the property is rendered. This morning, I awoke to find my site broken in the latest version of Chrome.

When I updated this blog to “HTML5″, I took the leap and used CSS3 everywhere that I could. This post area was a prime candidate for border-image. For the uninitiated, border-image allows you to use a single image as both a border and fill for an element. All you need to do is specify how much of the top, left, bottom, right of the image will be the borders, and how those pieces should fill each area (stretching or repeating).

Diagram illustrating the cuts corresponding to the value ‘25% 30% 12% 20%’ from the W3C specification

If you’ve ever used Fireworks, Illustrator or Flash, they all have a feature known as 9-slice scaling. Border-image is basically the same thing, but done on the fly via CSS. The rule for all posts here looked like this:

.post {
margin: 0 0 40px 0;
-webkit-border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
-moz-border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
border-image: url(images/article-background-stretch.png) 29 50 55 32 round round;
border-width: 29px 50px 55px 32px;
}

In keeping with best practices, you can see that I have listed the official property (without the vendor prefix) last, so that as browsers drop the need for the vendor prefix, they will simply read the last property – and the change will be seamless. Except in the case where all browser vendors are rendering a property different than the spec—thus lulling us into believing their rendering is correct when it is not.

Don’t adjust your screen! This is what every post looked like!

There is actually an additional value in the spec called “fill”. The “fill” keyword instructs the browser to render the middle of the image as the background of the element. Without the keyword, the middle remains transparent (ie, the background-image or color is rendered instead). If there is no background-image or color defined for the element, it is simply transparent. Till now, all browsers have ignored the lack of the “fill” attribute and rendered the middle regardless. The code above worked perfectly—but it was based on improper rendering.

Chrome (actually, the change was made in Webkit) has recently changed their implementation of the border-image “fill” value as described in the spec. This is good, but it will ultimately break a lot of sites since many of us left the fill attribute off since vendors were ignoring it. Sloppy, sure. But it worked… until today.

So, dive back into your code and add the “fill” keyword if your site suddenly looks like swiss cheese. But you’ll want to (for now) only add the fill value to the non-prefixed version, as the addition of the value currently breaks Firefox if added to the -moz version of your rule (hat tip to @chriseppstein for that little nugget). My post class now looks like this:

border-image: url(images/article-background-stretch.png) 29 50 55 32 fill round round;

“fill” tells Chrome (and eventually other browsers) to render the center of your image as the background of the element. The two “round” values instruct the browser to tile the images on the x- and y-axis.