Always Show Arrows for Number Input
While I enjoy small details that make user interfaces more elegant, I also believe that less is more, especially when it comes to native behavior. One native behavior I dislike is that <input type="number" /> elements only show the increment and decrement arrows when the input is focused. It's a needless focus change -- just show those controls all the time.
So how do we show those controls when the input isn't focused? An easy bit of CSS:
/* ensures the increment/decrement arrows always display */
input[type=number]::-webkit-inner-spin-button,
input[type=number]::-webkit-outer-spin-button {
opacity: 1;
}
I appreciate that the browser's native stylesheet doesn't use hidden tricks or privileged code -- it's all just CSS that we can override.
I'm always suspect when it comes to hover effects, as I feel hiding UI elements decreases accessibility no matter what the reason is.
![Detect DOM Node Insertions with JavaScript and CSS Animations]()
I work with an awesome cast of developers at Mozilla, and one of them in Daniel Buchner. Daniel's shared with me an awesome strategy for detecting when nodes have been injected into a parent node without using the deprecated DOM Events API.
![Create a CSS Flipping Animation]()
CSS animations are a lot of fun; the beauty of them is that through many simple properties, you can create anything from an elegant fade in to a WTF-Pixar-would-be-proud effect. One CSS effect somewhere in between is the CSS flip effect, whereby there's...
![CSS Counters]()
Counters. They were a staple of the Geocities / early web scene that many of us "older" developers grew up with; a feature then, the butt of web jokes now. CSS has implemented its own type of counter, one more sane and straight-forward than the ole...
![9 Incredible CodePen Demos]()
CodePen is a treasure trove of incredible demos harnessing the power of client side languages. The client side is always limited by what browsers provide us but the creativity and cleverness of developers always pushes the boundaries of what we think the front end can do. Thanks to CSS...
It’s worth mentioning that these styles only apply on desktop. The buttons are not shown in Chrome on Android which is probably better that way since the buttons are so small.
We can improve it by not showing the arrows for elements with step=”any”, in which case the input arrows don’t do anything.
/* ensures the increment/decrement arrows always display as long as step is not 'any' */ input[type="number"]:not([step="any"])::-webkit-inner-spin-button, input[type="number"]:not([step="any"])::-webkit-outer-spin-button { opacity: 1; }