Facebook-Style Expanding Textboxes With jQuery

I was recently asked to create a textbox that would vertically expand depending on how much was written in it. This style of text box can be seen in the Facebook news feed for writing comments under peoples feed items. When I receive this type of request, I usually begin by researching what existing systems and plug-ins are out there, investigate the different approaches people take and then write my own based on which way I think best.

Firstly, a textbox (input type=text) is the wrong element to be using. It cannot be any larger than a single line, so a text area element needs to be used. As a text area element will not automatically expand by itself, the general approach to this problem is to use a hidden ‘staging’ element placed way off the viewable screen. The text entered into the text area is copied across to the staging element, which expands as needed and the resulting height used to resize the text area. It is not a difficult thing to achieve with jQuery and the basic structure of the plug-in can be made in relatively few lines of code.

There are a few things to watch out for however. Firstly, because we are taking the contents of a text area and placing it in a div, we need to watch out for special characters that need encoding before they will render correctly. Primarily the newline character but we also have to watch out for the other special characters that can cause issues. Nothing that cannot be fixed with regular expressions. The other thing that we need to be careful of is the CSS styles that have been applied to the text area. We require that the hidden element perfectly mimic the text area and that the text wraps at the same point. If it does not, we will incorrectly predict when the text area needs to grow. The font size and family, line height and padding need to be copied.

This would normally be the point that I post the code, but after I started writing the plug-in, I stumbled across an existing one that I could just not improve upon and decided to use it in it’s entirety. Its by a guy called Jason Frame and his plug-in can be found on github. For my particular implementation, I added the facility to have watermark text in it by utilising the great plugin over on digital bush and I also added some text parsing requirements that were required for the particular project.

Now for a word of warning. There are some problems with this approach, which I have not managed to solve (and incidentally, nor have Facebook). The text area element renders it’s content slightly differently in every browser. In the hidden element, the text will sit up directly against the edge of the div but in a text area it may not. I suspect this gap also varies from operating system to operating system but as far as I can tell, you cannot eliminate it with styles. The consequence of this is that predicting precisely when the text area needs resizing becomes very difficult. The only thing to do is to accommodate this margin of error. This can be done by making the text area display slightly taller than a single line and to always have an extra line available. That way, if things go slightly off, it is still usable. You can see this problem if you put a significant amount of dummy text into the text area and watch when it expands as you type. Instead of expanding when you reach a new line it happens at a different place. If any one manages to figure out how to completely eliminate this problem I am eager to hear how.

Thanks for Breaking Things ASP.NET 3.5 Team

I have just spent an intense few hours crawling all the JavaScript files in our application (and there are a quite a few) fixing an issue introduced with our upgrade to the .NET framework 3.5. The entire afternoon in fact was spent fixing a single issue: our AJAX calls had stopped working.

The first hurdle was due to a slightly off-the-norm setup we have for our website. In order to save replicating code across the various websites that make up our solution, we opted for a common virtual directory that serves common assets like JavaScript, images and so on. With a little jiggery pokery, it also allows us to use shared .ascx controls. When we upgraded to the 3.5 framework, the upgrade wizard scans the projects and changes any references that should be pointing the new 3.5 versions. Not all references were changed, as the latest framework sits on top of the 2.0 framework, rather than replaces it. Unfortunately, the upgrade wizard could not figure out that our virtual directory project was not an application at all, so it created an unneeded web.config for it . However, removing that made little difference and it took me quite a while until I found that there were additional script handler settings added for framework 3.5 that were causing the errors. We chose jQuery as the backbone of our JavaScript development and only need to have the .ascx web service handler.

As soon as I removed the unwanted handlers, our AJAX calls sprung into life but still none of our AJAX powered controls worked. A quick look with Firebug revealed the reason. All our JSON responses where wrapped in a {d: } object. A little searching on the interweb and the reason was revealed. As a security measure, wrapping the response in that way can stop cross-site scripting attacks.

So why am I annoyed? Well, I cannot fault the reason behind the change, it stops a potentially nasty attack. However, we had no choice in the matter. It broke every one of our AJAX powered controls. Just because Microsoft had handled this change in their own AJAX controls, they decided that nobody else would be using the JSON serializer for anything else. As such, they seem to have no configuration setting to turn it off. We had been running the 2.0 AJAX extension with that vulnerability in it for a while, so I think we should at least be allowed to choose whether we continue that way. Instead, I have to spend hours checking all the JavaScript file for AJAX calls and making them look for their data inside the d object.

Do You Speak HTML?

Ever since I have been living away from my home country of England, I have noticed myself picking up on what I would consider misuses of the English language. On the most part, they are Americanisms, for which I take great pleasure and amusement in refusing to understand, until the person uses the English pronunciation. However, I also seem to hear an awful lot of completely made-up words or incorrect grammar. One may argue that this does not matter, as long as you can communicate the message but I guess being from the country that shares it’s name with the language, I have a built-in pride for it’s correct usage.

In development, things are usually not so forgiving when it comes to language. If you don’t get the spelling or grammar correct, it just will not compile or operate as expected. That is, except for HTML. Browser rendering engines are not fussy at all when it comes to HTML and will render pages happily, even when the code is all over the place. There is historical reason for this but unfortunately it seems to have lead to complete complacency in developers.

HTML is not a difficult language, it is simple to understand, there are not that many grammar rules and the vocabulary is tiny. So why then is there such a massive quantity of web developers who are just not that fluent in the language? I am not talking about just being able to get a page to look like the design. I am talking about expressing the content of the page using correct elements and combinations there of. There is a reason behind every html element, they were created because of a need, and each should be used where it is appropriate to do so.

If you are from the school of thought that does not worry about this, as long as it renders as the designer imagined, then there are good reasons why you should be thinking otherwise. Every day, web bots will be viewing your pages and trying to understand them. Screen readers do the same thing and a badly constructed page can be totally confusing to a blind person. You could be losing out on valuable traffic because of this. You could also find yourself with more work down the line. A site like Css Zen Garden shows just how much can be done with design without touching the html. That is not so easy when you have to work with a badly created page.

So what if that is not a big enough reason for you? Well, look at it this way. People who can speak correctly and have an extensive grammar, find themselves in a much better position than those who don’t. It can give a great first impression. The same thing is true for development. You may consider yourself pretty good in your chosen programming language but if you are sloppy in such a simple language like html, it could be the deal clincher in a job interview. It would certainly change my impressions of a potential candidate if they don’t have a decent grip on something that they should be able to in their sleep.

So how is yours? Time to brush up perhaps? Are you really that fluent? Be honest with yourself. How well do you speak html?

Edit: To all those that have taken this opportunity to pick holes in my use of language in this article: I do not consider myself an expert in English, by any means. I make as many mistakes as the next person. I now live away from England and on a daily basis I hear non-English people use phrases and pronunciations I was taught are incorrect. I don’t try to preach the way I was taught or consider that way the only way it should be done. My point was that something like Html should not have such variance. There is a worldwide standard we are all supposed to adhere to and were it not such a forgiving markup language, things would be much better.