The problem I've found with this combination is that the datepicker doesn't generally trigger validation when you change the date. This can be a problem if a user accidentally types an invalid date in a date field, and then they use the datepicker to correct it. Validation messages and styling will still show the date as invalid. No good – confused user.

Recently, I've been using either Ryan Seddon's well done H5F Library or the jQuery Validate plugin from Bassistance to handle form validation. Below are my solutions to handling the issue with the datepicker using these two validation libraries:

H5F

See working example {exp:gist:fetch id='2628275' file='js'}

jQuery Validate plugin

See working example {exp:gist:fetch id='2628089' file='js'}

If you would like to see solutions for other validation libraries let me know, I'll see what I can do. Or, let me know what your solution looks like. If you have suggestions, definitely let me know in the comments or on twitter.

While our first workshop in Cincinnati was a one-day event, we've extended the workshop to include more RWD goodness that just couldn't be fit into a single day. We will continue to cover the basics, planning, design, and responsive HTML/CSS. However, in Columbus, we'll be adding some emerging responsive patterns, responsive JavaScript, and the issue of responsive retrofits. More details.

Tickets go on sale May 21. Due to the one-on-one nature of the workshop, we're keeping it small at 80 seats, and we expect them to go fast. Mark your calendars today, kids.

We still have a few open sponsorship slots available as well. If you're interested, check out our sponsorship packet and hit us up.

Paul Hayes came up with a lovely solution, but it needs to check for a specific media query. In this case, your media queries need to be maintained in two places. If you decide to change a media query in your CSS, then you need to also change it in your JavaScript.

In a perfect world, CSS and JavaScript separation (even in the case of media query detection) should be maintained.

Rob Tarr and I worked to develop our own solution. First off, which CSS property could be used to test this theory? The property needs to accept any value thrown at it. The content property seemed like a great fit. Why not test the value of content from inside a throwaway :before or :after pseudo-element?

Things are going well so far, but we still needed this to fire on an event of some kind. Paul Hayes’ previously mentioned solution had the answer: transition events! 

We created a mashup of these two ideas by checking for content on transition instead of media query size. We used “small,” “medium,” and “large” as the content string to give us a loose coupling between the triggered media query and our goal in JavaScript. With this solution, we can claim that multiple media query breakpoints should still be considered “medium,” which is something that could come in very handy. We also found that we needed to attach the transition to the parent of the pseudo element because the transitionend event never fired when transitioning in elements with a content property defined.

Here’s the gist, so you can see it for yourself. Also, play around on this jsFiddle with your console open. The irony of this solution is that it actually has better browser support than matchMedia! The only caveat is that IE 9 falls between the cracks. IE 9 supports media queries, but it does not support the transitionend event, which this solution depends on. So, IE 9 will need a fallback.

Wrapup

Is this hacky? Yes.

Keep in mind, it's just a proof of concept, but we think it has some legs. We also made a simple demo for you here. Enjoy.

The gist in its entirety:

{exp:gist:fetch id='2482049'}

In my opinion, Karen McGrane stole the show. Don’t get me wrong – Jason killed it talking about the smart TV, and Ethan was as eloquent as I’ve ever seen him. Josh is always engaging, and Stephanie blows my mind anytime she speaks. Somehow, though, Karen managed to stand out in this amazing line-up of presenters.

We love to think responsively. That doesn’t mean we always follow the definition of #rwd in the purest sense of the term, but we embrace the intent of responsive web design. We strive to create excellent content experiences no matter the device on which they are viewed. What Karen so beautifully described carried this concept beyond design and development into content strategy and content management system integration. While this certainly wasn’t completely new to me, Karen was able to present the topic in a way that made it feel more tangible – more within reach – than I’ve heard it before. The basic premise is that we must consider a more modular approach to content which will allow it to span channels, devices, and contexts. Thinking of our content management systems as APIs opens up a wealth of possibility for the portability of content. After all, content is where real value lies. 

You can read her writing on the same topic in this article. It's a must read.

Beyond this, I had the opportunity to talk shop with some of the individuals I look up to most in our industry. I had a chance to witness the real community that we’re a part of. It’s a community that truly cares about users, and it is idealistic almost to a fault (which I love). It’s a community that carefully considers new ideas and relentlessly challenges old ones. @bdconf is not your average conference. Somehow, the organizers are able to bring the brightest minds on mobile web together to foster incredible conversation. It was inspiring; but more importantly, it was encouraging.

There, in Orlando, I sat around a fire among smart, smart people until the early hours of the morning, and we discussed a whole new breed of challenges. There is no denying, we are entering uncharted territory, but it is good to know that we're not alone. I’m even more grateful for the hours with my peers over dinner and drinks each evening than for the amazing presentations. 

Thanks to the Breaking Development team for another fantastic conference. You guys rock.

As we learned more about Stry and Dan, we found that the uncoventionally free design direction was in line with the uncoventional organization as a whole. As they like to say of themselves,

We're Stry, a new type of news organization. We don't care much about big headlines or news of the day, and we're not easily distracted. We're just a band of storytellers in pursuit of great storytelling. We tell stories about the issues that affect our lives.

Stop by Stry.us for a look around. Be sure to set aside some time, however, because even if the beautiful, responsive design eventually loses your attention, the rich longform articles will keep you there for hours.

Visit the Stry.us Website

What Font

This handy little bookmarklet allows you to quickly identify fonts used on a webpage without having to go through the Webkit Inspector or Firebug. Simply roll over a section of type on a webpage, and it displays the font name. Click on the section of type, and it displays the font families listed, type size, line height, color, a specimen, and Twitter link.

The Elements of Typographic Style Applied to the Web

Robert Bringhurst’s The Elements of Typographic Style is known as the de facto standard for typography use. The book is a great resource for designers (I pretty much keep one within 3 feet of me at all times), and most design courses use this book to teach general to advanced typographic principles. This site, created by Richard Rutter, takes some of the principles outlined in Bringhurst’s book and applies them to a web context, outlining how they are carried out in CSS. This is a great way for designers and developers alike to brush up on the “rules” of typography and see how they’re carried out on the web. Note: It seems this site has not been updated for several years, but it is still a great resource.

Lettering.js

This is a handy jQuery plugin that allows for “complete down-to-the-letter control”. This is especially handy when the kerning on that huge headline is out of whack. You can easily adjust and be on your way!

FontShop Photoshop Plugin

One of the newest tools out there (in Beta as I write this) is a plugin for Photoshop created by FontShop. It allows the user to preview FontShop fonts in their PSD file. The beauty of this? Now you can show a client a layout without having to purchase the fonts until the layout is approved. Now, if only Typekit would come out with something like this…

Cross-Browser Kerning Pairs and Ligatures

Another interesting tool that has come across the wire is this nifty CSS declaration that “improves handling of kerning pairs and ligatures in modern browsers.”

{ text-rendering: optimizeLegibility; }

Currently this is supported by Safari 5, Webkit, and Chrome. Interestingly, Firefox uses the declaration by default for text sizes over 20 pixels. As usual, there are a few bugs to keep in mind.

Check out some more handy type tools at www.nicewebtype.com.

Andy loans his silky smooth voice to Method & Craft for his second feature, a screencast, on the design-oriented site. He explains how you can use Photoshop’s “Layer Comps” feature to mimic Fireworks’ helpful “States” functionality. If you use Photoshop often and are not familiar with this feature, you won't want to miss this really helpful tutorial.

Check Out Andy On Method & Craft

As of December 2011, 48.1% of all US mobile subscribers own a smartphone according to ComScore's annual mobile report. Apple is on pace to sell 100 million iPads by year's end; and according to Forrester, one billion people across the planet will have smartphones by 2016. One billion. We have not seen this particular type of technology adoption and growth for any other consumer product. 

The masses are subsequently adopting mobile as their main channel to interact with companies, leaving businesses scrambling to "go mobile." Forrester reports that business marketing budgets for mobile will grow 100% by 2015.

Bringing a company's true brand experience to mobile devices is more important than ever, and you have got to get it right the first time. A survey from Harris Interactive reports, "63 percent of all online adults would be less likely to buy from the same company via other purchase channels if they experienced a problem when conducting a mobile transaction." 

Here's a great quote about mobile sales potential from Kenichiro Nakajima, Chief Mobile Officer at Rakuten, Japan's top retail website: 

Mobile sales are beginning to make a serious impact on the market. We're already seeing that consumers will buy more on their mobile phones than they will on their PCs.... Consumers take their mobile devices everywhere, so brands that really embrace multichannel sales and understand the differences between shopping platforms have the potential to literally travel with their customers.

At Sparkbox, we believe there is no better multichannel platform than the web, so we continue to encourage well-designed mobile web applications over mobile native apps for most purposes. We anticipate that companies which embrace a web design strategy which allows their brand to be harmoniously presented across all channels will win out over competitors that don't. It's just a matter of time. (This previous article from Ben elaborates on our views of mobile web strategy.)

Just like the first years of the internet, consumers will allow a small grace period. Soon, however, consumers will demand an equal and congruent experience from their brands as they continue to integrate mobile devices into their lives.

Source: 1to1media.com - Top Mobile Trends to Watch

We build responsive, standards-compliant, content-focused, well-crafted, accessible, valuable, beautiful websites, and we're looking for some web geeks that do the same. If you want to go home with HTML, CSS, and CMS under your finger nails each day, you'll fit in just fine. You'll be heavy into ExpressionEngine and WordPress daily, and you may get a little dirty with some Ruby, PHP, and JavaScript as well.

Passion, character, and a killer portfolio are a requirement. A long resumé is not.

We also love Macs, food, and our families. Not necessarily in that order.

Send a link to your blog, GitHub account, online portfolio, and/or responsive resumé to info(at)heysparkbox.com, and you could find yourself working on some awesome projects with some equally awesome people.

We're ready to roll, so get on it.

If you haven’t read Ethan’s article, stop now, read it, and then come back here.

Now, let's talk about some responsive web design. For over a year now, we've been developing responsive websites almost exclusively at Sparkbox, and I’ve found something missing in our responsive tool belt – a good way to handle JavaScript.

Example

Recently, I was working on a secondary navigation with two sections. At media queries for smaller sized screens, the navigation had links to show and hide each section using jQuery animations. This posed a problem, however. After they were hidden, jQuery left style="display: none" on the elements. After resizing the browser and jumping to a media query for a larger sized screen, these elements should have been shown without the need for the additional links, but they were hidden because of the inline style. 

Now, I know that everyone likes to say that only developers change their browser sizes to see how things respond. There are real problems with this type of thinking. What if the user maximizes their window or makes it smaller based on the content? This might switch media queries, triggering a break in the secondary navigation. Here's another example that is pretty relevant – what if the controlling media query is somewhere around 900px? A simple orientation change of an iPad would cause these navigation elements to disappear. Oops. Do you care now?

Solution

The solution to this problem lies in the elusive matchMedia method; it provides events triggered by media queries.

In order to run code based on media queries, I'm using mediaCheck (a wrapper I've written around matchMedia to fire events when entering or leaving a designated media query) to trigger the cleanup code when entering larger media queries.

Now when the 600px media query is fired, it will remove the style attributes and all is well with the secondary nav.

mediaCheck provides a nice wrapper to easily turn code on and off based on media queries. Switching behaviors and cleaning up code between media queries is now made simple. JavaScript mischief managed.

Take it out for a test drive, kick the tires, and look under the hood. Feel free to ask questions and contribute, and let's move the web forward together.