Blog

Sometimes, it is useful to differentiate between physical and virtual keyboards in a web application. In my case, I had built a new messaging system for Yanteres with a responsive design which could be used on any device. While responsive design is a given on today’s web, the behavior of certain actions – which can’t be controlled via CSS – is different on mobile vs desktop. In the case of the aforementioned messaging system, hitting Return on physical keyboards is expected to send a message, while hitting Return on a phone’s or tablet’s virtual keyboard is expected to insert a newline.

For about a year, I’ve slowly been migrating to HTML 5. First of course was the DOCTYPE. Next I started using new structure elements such as <section>, <article>, <header>, etc. and in some applications - Web Forms 2.0 input types.

A larger portfolio of my work can be found at Hypernova Design Studio. This is an archive/portfolio of the work I have done outside of Hypernova.

I had to return to PHP for a small application I had to write for which Rails would have been too big. Being used to Rails RESTful methods and MVC, I didn’t want to make another messy 200 line PHP app that I would not be able to read later, so I coded a very small and simple CRUD “router” (as in Rails’ routes) and I decided to share it with the world. So far it only works with a “controller” that manages plural resources. The CRUD pattern here is modeled after the way Rails controllers work. It’s really simple, but it sure makes coding tiny apps a lot cleaner. (Helpers, clean URLs, MVC, etc. are up to the reader to implement)

I haven’t written here in a long time, so as many of you might not know yet, I’ve been learning Ruby on Rails the past 4 or 5 months. I’ll have to say I’ve run into some pretty big challenges, but overall Ruby on Rails is one awesome framework. My latest challenge has been getting DHH’s auto_complete plugin to work with Ryan Bates’ complex forms. It might not be the best way to do it, but the solution was to monkey patch ActionView::FormHelper and FormBuilder which I put in a seperate file in the /lib folder of my project. So without further ado, here’s the code:

I recently had to make an auto expanding textarea for a web application and when it came to Opera, I couldn’t find a working solution. The most common way of making the textarea to auto expand is to compare the offsetHeight or clientHeight of the textarea with the scrollHeight. This works fine in IE, Firefox, and Safari (and even allows auto shrinking in IE) but not in Opera or Konqueror. Some solutions I found divided the number of characters by the number of rows and and cols in the textarea. The problem with this is that many people don’t type everything on one line, so it won’t accurately measure how many lines there are.