« Announcing a UI control catalog and this week's Control of the Week: Apple-style SlidingPagesWithDots | Main | UI Control of the Week: Microsoft Office combo boxes, still better than anything comparable in HTML »

October 17, 2011

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451fb6769e2015392465516970b

Listed below are links to weblogs that reference Control of the Week: Facebook-style AutoSizeTextBox:

Comments

Ken Geis

A couple of things I don't love about the QuickUI implementation. First, when I start typing the first line, the box changes in height a pixel or two. This is on Chrome on Linux. Second, I'm used to an extra line being added on carriage-return, not on first character on the new line. That feels inconsistent between the first line and subsequent lines.

Jan Miksovsky

Ken: Thanks for the comments!

On the extra pixel in Chrome: This is probably the issue I raised above, where Chrome doesn't seem to give you a way of finding the actual line-height of something. One challenge of building general-purpose web controls is that it's not always possible to finesse little details like this by just hard-coding pixel values for specific elements that are carefully tuned to match the font metrics. Since I'm trying to build a general purpose control that works with a wide range of fonts and font sizes, I'm reluctant to do too much special casing in the base AutoSizeTextBox class: bumping a magic constant in the code one way or the other might make the control behave better with one font, but worse with another -- or better in one browser and worse in another. That said, it'd be quite easy for someone to create a subclass of AutoSizeTextBox that picked up all the base logic, but then forced the text box or hidden pre tag to have the specific font metrics that worked best for their site's font. I'd argue that even with a hack like that, the general solution still gives someone a big leg up compared to having to work out the entire UI behavior on one's own.

Your point about the extra line is well taken. In this implementation, I'd thought it'd be nice to always leave the user with an extra line, so they always know they have more room to type (i.e., they haven't run out of room). That said, what's good enough for Facebook is probably good enough for most sites. When I have a moment, I'll experiment with removing the extra line.

The comments to this entry are closed.