Some days you can tell that @font-face embedding is still trying to find its feet in becoming a stable and viable solution. Chrome 4 and 5 beta currently have a bug that creates some weird behaviour.

In the following screenshot, you'll notice that everything looks a little off. Okay, that's an understatement.

Image courtesy of Pete Lambert

Every character is replaced by an A in a box. The problem is the local() declaration in the @font-face declaration. If you have the font installed on your machine and visit a page that uses the local() declaration then you'll see these boxes instead of your beautiful font.

The only solution I've seen so far is to remove the local() declaration.

Hat tip to Anton Peck for actually discovering the connection.

I've commented on this before but I have a protocol that I usually use when emailing someone. I like to finish my emails in a way that acknowledges that you have reached the end of the message.

My first email tends to be on the more formal side.

[Cheers | Best regards | All the best | Best of luck to you],

Jonathan

Once the formality is out of the way, I keep it short. The verbosity is unnecessary since you should already know my name and the goodbye greeting sounds odd in the middle of an ongoing conversation.

In which case, I like to use my initial prefaced by a hyphen.

-j

And yet, I've played with other options...

.js

Consider that I do a fair amount of JavaScript development and my initials are JS, I thought there was a subtle humour in ending my emails with the file extension.

However, recently, I've started something new.

=j

The hyphen seemed negative. Whereas the equal sign creates a smirk-like emoticon—a sense of levity to go with my brevity. And really, aren't we all just equals?

Okay, maybe I think too much.

Have you heard of Hundred Pushups? It's a simple six-week program to build up your strength by slowly increasing the number of pushups you can complete. By the end of six weeks, you should be able to complete 100 and along the way you've gotten a short workout working multiple muscle groups.

Since I'm still trying to lose weight, I figured I'd get started on the program (yesterday was my first day and managed to do 12 pushups at the end of my first set). However, being the geek that I am, I thought, "I should track my progress with a cool iPhone app." There is one available for $1.99 from the Hundred Pushups web site. There is a free web site that can be used to log your progress, too.

I checked out the web application and realized that all it did was track the results of your final set over the course of the six week plan, with the ability to add a comment. Very straightforward. But I want an iPhone app and suddenly inspiration struck...

Drop and give me two hours

Last night, I took the challenge to try and put together this application within two hours. Mission accomplished. Almost.

Check out http://pushups.snook.ca/ on your trusty iPhone or iPod Touch.

At 11pm last night, I grabbed a copy of jQTouch and started working out the interface. The documentation needs a little work (need some help, David?) but I managed to figure it out. I used localStorage to store the results. You can save the site to your home page where it'll run as a fullscreen application.

Improvements?

Of course, there's always room for improvement. Safari, Firefox, Internet Explorer 8 and Opera 10.50 has support for localStorage, too, so there's no reason why this can't be adjusted slightly to allow the application to work in desktop browsers, too. I also haven't tested this yet in WebOS or Android and I'd be intrigued to know how well it works.

Some of the interface needs refining, too. I'm using JavaScript-based confirm statements to prevent accidental deletion (like swiping over an entry) but a more iPhone-like experience would be preferred.

If you haven't already, what are you waiting for? Head over to http://pushups.snook.ca/.

HTML forms have been, to date, quite simplistic. We've had limited options: the text field, the checkbox, the radio button, the textarea and finally the select drop down. Any complex data like phone numbers, email addresses or dates had to be checked by JavaScript. (And you should always and I mean always do server-side validation of the data.)

The input element works overtime by being rendered completely differently based on the type it's given—be that a text field, password, checkbox, radio button, and others. Considering my readership, this is all terribly old and boring to you now. I understand.

New Types

Under the HTML5 umbrella, however, forms are getting a makeover. The new input types are:

• search
• tel
• url
• email
• datetime, date, month, week, time, and datetime-local
• number
• range
• color

In the example of an email field, validation could be performed by the browser, without JavaScript, to ensure that an email address was correctly entered. Even more powerful, it could allow autocomplete based on your local address book.

New Attributes

There are also plenty of new attributes, many designed to aid in constraining the limits of a field. Here is a small subset of new attributes:

• list — points to a datalist element containing value suggestions
• max and min — constrains valid date/time and number values
• pattern — allows a regular expression as a constraint
• placeholder — displays a text hint for the field

Fallback

If you try to use these new type now, browsers that don't recognize the type will fall back to the text type. Unrecognized attributes will similarly be ignored. That means that you could start using it now and when browsers begin to recognize them, you'll be ready. Client-side validation via JavaScript could be layered on in the meantime.

Where things are unclear is how you can tell whether the browser already supports these features. For example, inspecting the type in Firefox returns "text" but Safari and Chrome return "email".

Browser Support

What's most interesting is that we're starting to see some of these features get implemented into browsers.

Mobile Safari (on the iPhone) was quick out of the gate by adding support for number, email and url. No validation is performed but special keyboards for each input type are presented to aid in entering a value.

Most recently, Chrome 5 beta has support for the placeholder attribute.

<label for="email">Email address</label> <input id="email" type="email" placeholder="jonathan@example.com"> What next?

I have qualms about how browsers will handle the complex input types like date and time and so I appreciate the slow and considered implementations to date. Yes, this isn't very much just yet but it's encouraging.

Every now and then I look at using background-position-x and background-position-y but can never seem to find a definitive and up-to-date resource. To save myself the trouble in the future, I'm documenting it here.

Positioning via separate X and Y values is a feature that Internet Explorer introduced but never made it into a W3C specification. Any recommendations to add it to the spec have been denied.

Why have separate X and Y values?

I believe that there are several reasons why you may wish to have separate values.

Animation

The last time I was frustrated by the lack of consistent cross-browser support for X/Y was when I wrote my article on animating background images using jQuery. Having to take a string value, split it into its separate X and Y values, parse the units, and then rebuilding the X/Y value into a single string is a cumbersome experience. Being able to animate just the X or Y value would have been much simpler and would have worked with jQuery "out of the box", since jQuery already knows how to animate pixel or percentage-based values.

Sprites

CSS Sprites have become a popular way to optimize the performance of a page. It's an interesting technique in which you compile numerous background images into a single image and then use background-position to only show the desired part of the image on an element.

#a { background: url(sprite.png) 0 0 no-repeat; } #b { background: url(sprite.png) 0 -30px no-repeat } #c { background: url(sprite.png) 0 -60px no-repeat }

Of course, we could optimize this like so:

.icon { background: url(sprite.png) 0 0 no-repeat; } #a { background-position: 0 0; } #b { background-position: 0 -30px; } #c { background-position: 0 -60px; }

However, given access to separate X and Y values, we could optimize it like so:

.icon { background: url(sprite.png) 0 0 no-repeat; } #a { background-position-y: 0; } #b { background-position-y: -30px; } #c { background-position-y: -60px; }

Admittedly, that didn't save us any bytes and for this reason alone, I can see why the W3C denied the inclusion of this into the specification.

Internationalization

However, let's take a look at internationalization. Specifically, in having to deal with right-to-left (RTL) environments like Arabic. In these scenarios, where an icon is positioned on the left of some text in a left-to-right environment (LTR), the icon should now be positioned on the right.

Wouldn't it be great to just add in an extra line in bidi environments where we tell the background of all sprites to be positioned on the right instead of the left?

html[dir=ltr] .icon { background-position-x: 100%; }

That's it. One line. (And this actually works in IE7+, S3+ and Chrome.)

Instead, without the ability to separate X and Y values, all sprites need to be redeclared for RTL environments.

Support Table

Finally, here's the support table for which browsers support background-position-x and background-position-y.

Browser Version Opera No Support Firefox No Support Safari 3+ Internet Explorer 4+ Chrome Yes

Opera is the only hold-out at this point and hopefully we'll see it get introduced at this point. It has become a de facto standard and it's exclusion from the W3C specification doesn't diminish it's usefulness.

I'm embarrassed. I could've sworn I had it working in the latest version of Firefox but I've re-run my test case and I can't get it working in Firefox at all. My apologies for poor testing. But I'd still like it in all browsers, pretty please!

Logo Design Love is a book written by David Airey that covers the whys and hows of brand identity development.

The book is broken down into three parts: The importance of brand identity, the process of design and keep the fires burning which looks at how to find motivation and inspiration. It's a light 200 pages with readable type and plenty of examples.

David Airey aims this book at the aspiring designer by not only covering the design process but also covering the process of project scope and client management in the context of logo design.

Logo Design Love hits the mark when it speaks from experience, which it does for most of the book. There's plenty of real world examples with plenty of input from designers other than just Airey himself. The book falters only slightly (and briefly) when Airey makes assumptions or raises open questions as he does with his assessments on the Tropicana or New Coke campaigns.

In the end, Logo Design Love was an enjoyable read with plenty of good information in a well-designed package.

CSS3 features are making their way into the various browsers and while many are holding off on implementing them, there are those who are venturing ahead and likely running into a world of interesting quirks across the various platforms.

Two such features that I have been having the pleasure of enjoying are the use of multiple backgrounds and CSS gradients. I'm covering both features because multiple backgrounds by itself is simple enough, as are CSS gradients, but combining the two is where things get interesting.

Multiple Backgrounds

What are multiple backgrounds when it comes to CSS? I mean the ability to define more than one background image for a single element. That sounds wonderful, doesn't it? It is. No more having to have nested elements with lots of CSS just to create a layered effect. The syntax is very straightforward: just separate each background image with a comma.

background-image: url(…), url(…);

For browsers that don't recognize multiple backgrounds, the entire background declaration will be ignored. (Actually, according to PPK, Explorer Mac will show the last background declared.) Depending on your design, you may need a single image declared and then declare the multiple background on the next line.

background: url(…) 0 0 repeat 10px 100px, url(…) 5px 5px no-repeat 5px 5px #FFF; background-image: url(…), url(…);

You can declare multiple backgrounds using the shorthand syntax, as well.

background: url(…) 0 0 repeat, url(…) 5px 5px no-repeat #FFF;

I threw a bunch of stuff in here to see if you're paying attention. The shorthand syntax for a normal background includes image, position, and repeat. However, the colour is always the last thing declared. (I've traditionally always declared it first.) There can only be one colour applied to an element—although with rgba, if you could declare the colour more than once, it'd theoretically be possible to mix colours.

Background Size

Another interesting property that is being implemented in recent browsers is support for background size. Any browser that supports multiple backgrounds also supports background size.

When declaring background size for multiple backgrounds, the declarations are separated by commas just like with background-image.

background-image: url(…), url(…); background-size: 10px 100px, 5px 5px

In Opera, Mozilla, and Safari, you'll need to declare the vendor prefixes. Chrome and the Opera 10.5 dev builds don't require the vendor prefix. And to further clarify, background-size support is in Opera 10.1 but multiple background support isn't.

-o-background-size: 10px 100px; -moz-background-size: 10px 100px, 5px 5px; -webkit-background-size: 10px 100px, 5px 5px;

(As much as I love the features that browsers are implementing, I'm getting really annoyed at all the vendor prefixes. Seriously. And believe me, by the end of this article you'll see how much worse it can get.)

The background size declares width first and then height. Technically, you should be able to omit the second value, which should use auto for the second value.

background-size: 10px; /* should be the same as '10px auto' */ background-size: 100%; /* should be the same as '100% auto' */

The reality?

Opera 10.5 Works according to the spec Safari 4 ignores the declaration altogether Firefox 3.6 Works according to the spec Chrome 4 Treats the second value as the same as the first. Eg: 10px becomes '10px 10px'

There are two other values that can be used for background-size: contain and cover. Cover will make sure that the background image covers the element. Contain makes sure that the entire background image is visible within the element. Only Safari seems to be the odd man out on this one.

If you declare multiple images using the shorthand syntax, the background size is always declared after the background position (since they could technically be confused with each other) and separated with a slash.

background: url(…) 0 0 / 10px 100px repeat, url(…) 5px 5px / 5px 5px no-repeat #FFF;

The only problem is that no browser supports this and the entire background declaration will be thrown out if you try and use this syntax. Well, except for Opera 10.5 which does a weird thing where it ignores just the parts of the declaration it doesn't understand.

All this to say that you must always declare background size using the long form. In my opinion, this will almost likely always be the case... changing background implementations risk backwards compatibility and that's a hell I'd like to avoid.

CSS Gradients

One of the many cool CSS additions to come out of Webkit is the ability to specify gradients. Whereever you would normally specify an image using a url() syntax, you can specify -webkit-gradient instead. Probably the most likely scenario will be for background images but you could use it for border-image or list-style-image, too.

background-image: -webkit-gradient(linear, 0 top, 0 bottom, from(#496178), to(#2E4960));

The syntax takes a gradient type as the first parameter: linear or radial. The next two values indicate the start and stop points of the gradient. Each parameter after that is a color-stop(x, y) function where x is a percentage or a value between 0 and 1 and y is the colour value. from and to are shortcuts for color-stop(0, y) and color-stop(1, y) respectively. This implementation mirrors the functionality within the canvas specification.

CSS gradients have made their way into the W3C as a draft spec, although the syntax is different from how Webkit has implemented it. Firefox 3.6 has just been released and now includes CSS gradients using this newer syntax which separates the two types of gradients into their own syntax: -moz-linear-gradient and -moz-radial-gradient.

background-image: -moz-linear-gradient(90deg, #496178, #2E4960);

The first parameter is the position or angle. There are a number of ways that the shorthand can be calculated and degrees are likely the easiest to use. If you're doing a gradient from top to bottom, the angle can be ignored altogether and the colour stops are all that need to be specified.

background-image: -moz-linear-gradient(#496178, #2E4960);

There's no need to specify the color-stop, from or to functions like with the webkit gradients. You can specify multiple colour stops and it'll create a gradient between each one. If you wish to adjust the position of where the gradient transitions, you can specify it as a second value with the color stop.

background-image: -moz-linear-gradient(#496178, #323232 20%, #2E4960);

You can also use rgba values, too, if you wanted to create semi-opaque gradients.

Mixing the Ingredients

Now that you know how the two things work, let's look at putting it all together. If you want to do multiple backgrounds and use CSS gradients, you'll need to do something like the following:

background-image: url(…); background-image: url(…), -webkit-gradient(linear, 0 0, 0 100%, from(#FFF), to(#000)); background-image: url(…), -moz-linear-gradient(#FFF, #000); background-size: 10px 100px, 5px 5px; -o-background-size: 10px 100px; -moz-background-size: 10px 100px, 5px, 5px; -webkit-background-size: 10px 100px, 5px 5px;

Remember when I said the other browsers ignore the entire declaration? That's right, if Firefox doesn't like -webkit-gradient (because it has no clue what it is), it'll pretend that the entire background shorthand was never declared. Opera 10.5 alpha will still recognize any url() declarations and just ignore the -webkit-gradient and -moz-linear-gradient statements. I've put in a bug report with Opera to change their behaviour to match what the other browsers do in this situation.

I'm also going to take a moment right now and rant about vendor prefixes. Yes, I know I mentioned it before but this is getting absurd. Honestly, my plea to Microsoft is to avoid jumping on this CSS3 bandwagon until specifications settle. Where they have, nail it to a tee and make sure it matches how other browsers do it. Don't be innovative.

Wrapping it up

Having been working with CSS gradients as of late, I really wanted to document the current state of things. As you can see, some features can offer up a bumpy ride when you want cross-browser compatibility (even if we are still ignoring the elephant in the room: Internet Explorer).

Check out the Demo Page

I had noticed this little bug on my own site. In the footer, there's a 5px border with the colour set using rgba. In Safari, it's as if the semi-transparent borders overlap each other in the corners and the values are compounded. This creates little squares in the corner of my squares.

Not quite what you'd expect. Firefox and Opera (10.5; I didn't test in 10.10) render this as you'd expect, with a consistent colour surrounding the block.

In testing some other border handling, I noticed that the overlapping only seemed to happen when the border colour was the same on all sides. If the border colour is the same but the border width is different, you'd still get the overlapping values in the corner.

Now, how far apart do the colour values need to be before it reverts to a different way of rendering the borders: generally 3/1000th of a difference.

With the following CSS, the borders render closer to expected in Safari:

border-color:rgba(0,0,0,.201) rgba(0,0,0,.204);

You can still notice a slight line at each edge as I suspect some anti-aliasing is at play. This is consistent between both Safari and Chrome, since they're both based on Webkit.

It's so easy to wallow in self-pity when things don't go right. As much as 2009 sucked on all levels, it wasn't all bad. As much as I want to sulk, the fact remains that I live a charmed life. Through some karmic luck of the draw, I've got a lot to be thankful for.

Personal Projects

This past year was a year of simplication and basically had me letting go of all my personal projects—at least for the time being. I shut down SidebarAds, I never worked on Snitter, and I never finished Haylia, FontSmack or any number of other personal projects that I wanted to work on.

I have mixed feelings about this.

I gained more spare time but I'm not sure that I filled that spare time with anything truly useful. By the end of the year, I still feel that no Twitter client could do what I had envisioned with Snitter. No CMS could do what I had envisioned with GainCMS (a project that I've dreamt of since before going freelance).

2010 may be the year of the comeback and we'll see if I can harness my energies into any of these projects or possibly something new.

Blogging

It was a quiet year on the blogging front. Long periods of silence were shattered with bursts of posts as I felt a rush of inspiration and then back to silence. With that said, a couple posts that were slated to be written for my own blog ended up being written for other sites, namely PHPAdvent and 24ways.

I have many more posts in the wings but need to get off my ass and just write. Many have signed up for Project52 but I've yet to commit to something so rigid. We'll just have to wait and see when inspiration strikes

I had ventured into screencasting and did a number of posts in 2009, which I'm pretty happy with. I would like to continue doing the same in 2010.

And yes, podcasting is still something I've been thinking about. But if I can't keep a regular blogging cycle, can I stay committed to a regular podcasting schedule? We'll see.

Writing

At the end of 2008, I made mention of possibly writing another book or even an e-book. As it turns out, I have begun work on another book but it has been a slow start and I hope to pick up the pace to finish writing by March. Half the problem is just getting the ball rolling. Let's hope things don't get sidetracked and this book gets finished.

Others have done reasonably well with the e-book model but I've yet to feel completely inspired with e-books unless they're short reads. Writing an e-book isn't high on my list for 2010 but as many other things, inspiration may strike and it may happen. I wouldn't hold out hopes for this one!

Freelancing

For over three years, I was a freelancer. I ran my own business. It was a freeing experience but one that was fraught with hassle and disappointment. In previous retrospectives, I flirted with the idea of getting out of freelancing. By the end of 2008, I had already come to the conclusion that growing my business wasn't something I wanted. I cemented my fate in 2009 by giving up freelancing for Squarespace and finally Yahoo!.

I've got the best of both worlds right now. I still live like a freelancer, working from home with my own office and computer, but enjoy the benefits of full-time employment working with people for a company doing some great stuff. I'm excited for the year ahead—a feeling I haven't felt in awhile.

Conferences and Speaking

Speaking engagements early in the year had to be cancelled, including having to turn down an opportunity to speak in New Zealand. I even missed SXSW. The first half of the year was definitely disappointing. However, the year ended on a high note. I got asked to step in at the last minute at Fronteers and had, in my opinion, probably one of my strongest sessions I've ever presented—all despite fighting a cold that had claimed my voice. I followed that up with the jQuery Summit which also felt good and very relaxed. I capped off the year by getting to speak at An Event Apart.

I don't have anything currently slated for 2010. I haven't actively gone after speaking engagements but may take a more proactive approach to get back in the game. Likewise, I'll be working with the other folks in Sidebar Creative to possibly see a resurgence of Sidebar Workshops.

Renewal

Sometimes we have to tear it all down to build it back up again and, for me, 2010 represents a year of renewal. I have a renewed interest in web design and development and a renewed energy to share what I learn along the way.

Come along for the ride...

It has been a year marked with a series of failures and while I feel some urge to explain it all, I think it will be better off left unsaid. This post is a stick in the sand to remind me of what has happened. Onward we go, for time gives us no other choice.