One of the designs I recently had to work on needed a narrow width header in a sidebar with a large number on the left side of it and the header text vertically centered to the right.

If you've worked with CSS for awhile you've probably ran into the same issue as everyone else. Vertical alignment with universally supported css is not easy. There are multiple techniques you can use to make something vertically aligned but there are drawbacks to each.

For my use case I couldn't use any of the normal tricks I'd use. I didn't know the exact height of the number and I needed the header text on the right to wrap properly. So I couldn't use a typical technique involving line-height, absolute positioning, or padding.

You probably already know about HTML5's <input type="number">. Which if supported by a browser displays a form input optimized for inputting numbers. Whether that means an up/down spinner or an optimized keyboard.

However iOS' standard behavior for the number input isn't that ideal. By default iOS will display a standard keyboard slightly modified with a row of numbers at the top. This isn't ideal as you don't need the alphabetic keys and iOS already has a full numeric keypad it could use for the input instead. For reference, other mobile OS such as Android already display their numeric keypad when focusing a number input.

A html5doctor article article went over this, pointed out a trick by Chris Coyier using <input type="text" pattern="[0-9]*"> in which the pattern forces iOS to use it's numeric keypad, and also mentioned HTML5's inputmode.

The state of most uses of css3's border-radius around the web has been bothering me for awhile now. Though now I've found something else to be annoyed at.

The earliest common use of border-radius was -moz-border-radius in Gecko based browsers. Later on the WebKit implementation came into common play. When and where things were actually implemented isn't really important, that's just the order that people started to know about them as common knowledge.

As a result there are plenty of websites around which are still using out of date css that only support Gecko and WebKit based browsers, or in some cases support nothing but Gecko based browsers. This is somewhat irritating considering nearly every browser — at least in their most recent versions — support border-radius, and by using incorrect css they omit support for browsers that actually "DO" have a border-radius implementation. Like Konqueror, Opera, and IE9.

Back on HTML5, section 4.10.7.1.13 defines a number state for inputs. The traditional input for numbers you see inside of OS is a spinbox, a text box containing a number with a set of up and down arrows beside it which allow you to use your mouse to change the input (iirc some OS even let you use the up and down arrow keys).

So far there are two implementations of the number input, in Opera in and WebKit.

Opera gives you a spinner input and lets you use the arrow keys, and in the iPhone OS WebKit optimises the keyboard by placing the numbers at the default top row (why they don't give you one of those nice fancy slot machine style number inputs they worked so hard on is beyond me).

While I was working on version 3 of Kommonwealth I got back to a part of our interface which makes use of live input events (ie: Events that fire as you type into the input) to offer a preview before the onchange event is used to actually change the data by sending an ajax post to the server.

For those who haven't heard of the oninput event, it's part of the html5 spec. You know those older ui parts such as autocomplete features and whatnot. The normal way of making these work is to manually subscribe to keydown and keyup events, and sometimes even use a timer for long inputs. Why? Because onchange only fires after you blur the input (that is what it is speced for and meant to do) and there was no event that would fire while typing was being done, so the only easy way to do it was to subscribe to keyboard events. Of course this method only applied to text inputs. The oninput event is basically an event in html5 which takes care of it. It works similarly to onchange, but instead of firing on blur it fires while you're typing into the input. This has an extra benefit in compliant browsers that like onchange it is only supposed to fire when the data has actually changed (ie: typing asdf then pasting asdf to replace it shouldn't fire).

Well of course this would be like all other html5 features incomplete browser support, the html5 spec doesn't list browser support in any browser. But that's where user code comes into play. We create code to support it manually in browsers that don't support it, and allow browsers that do support it to take over and handle it natively.