I’ll be brief. A few years ago, a trend started popping up whereby the label next to a text input (at the time most commonly search fields) would be removed, and instead the default value of the field would be its label. On focus, the input value would be blanked. The result was a cleaner look and really no loss in usability (as well as no loss in accessibility so long as the developer takes care to put the label element in the DOM, but hide it).
The behaviour is common practice now, not only for single-field forms like search inputs, but entire ten-plus field information gathering forms. This is where the problem arrises. If you’re like me and tab between inputs (‘fill in field, hit tab, fill in next field, hit tab, etc), it’s very easy to forget that you need to read the value (acting as a label) in the next field before tabbing into it – as soon as it has focus, you can no longer tell what you’re supposed to be inputting.
The placeholder attribute should not be used as an alternative to a label. –HTML5 Draft Spec
Even more recently, the HTML5 spec introduced the placeholder element for inputs. Though the HTML5 spec advises against using a placeholder in place of a label element, it seems common practice to do so, and it tempting even for myself. This would be fine and dandy if it weren’t for the specific implementation of placeholder‘s behaviour in all major browsers: Exactly the same as we saw above, clear on focus. It leads to precisely the same problem as before, but this time natively instead of using a bit of JavaScript.
I’ve created what I believe is the ideal alternate behaviour multiple times in the past with a tiny bit of JavaScript and CSS:
- Position the label for an input directly below it with the same borders/padding so that the text lines up perfectly with what is typed in the input
- Using JavaScript, bind a function on change for the input that checks to see what the value of the input is (after each keystroke), and if it’s anything other than blank, hide the label. If the label is hidden and the input is blank on change (you’ve deleted the contents of the input), show the label.
I’m not completely sure whether the necessary change here is in the behaviour/intended use case of the placeholder attribute or in the code developers are writing in conjunction with their forms. Since it’s highly unlikely the HTML5 spec will dictate such a change at this point, I think the onus is on developers to be more careful with the aesthetics/usability line. If you implement the above properly and with care, you’ll have an accessible form that saves clutter and uses no additional markup.
I think the little game or feel-around that one must play in order to plug a pair of headphones into their iMac is Apple’s cruel little joke on its loving customers.
Well, not really, but every time I need to plug something into that 3.5mm jack on the back of my iMac at the office, I can’t help but think about why it’s so difficult. I’ve pondered putting that port on the side, on the bottom, anything that helps access – but really, repositioning offers no ideal or substantially improved alternative.
While the same issue is present with the USB ports in the same area, they’re much more defined and can be felt out with relative ease. the issue with the 3.5mm port is that it’s so small, so challenging to accurately locate with your index finger, blindly. So I propose a simple solution (the best kind!). Recess it in a small (approx 1cm in diameter) dimple . Around the size of the tip of an average finger. This does two things: Makes the port easier to find blindly, and provides a very small targeting assist – the plug would slide in with relative ease even if aimed a little bit off.
How’s that, Steve?
Every time I create a custom post type that requires a thumbnail of some sort, it only make sense to use WordPress’s built in Featured Image functionality. Problem being, the default ‘Featured Image’ meta box isn’t totally self-explanatory to your clients (and if you’re mildly OCD like me, it bothers you even for your own site). Let’s change that copy on a per-post-type basis. More »
I find as I learn more and more on WordPress as a CMS, the requirement to keep users out of the WordPress dashboard altogether becomes increasingly common. The issue with prohibiting such access is, a user’s settings are normally handled through a dashboard view. In search of a solution, I found two routes:
- Theme My Login, a plugin, handles this among many other things Its placement in the permalink structure of the page is not ideal, however, but it’s worth a shot.
- On the WordPress.org forums, I eventually encountered this post by jimzqui. Using a custom template and a lot of additional CSS, this code is the shit to get a front-end settings page going. You’ll probably encounter an error – make sure you remove the ‘Resume’ field in his code, as chances are you don’t have one.
I’ve needed to, on multiple occasions, output post thumbnails for different content types at different sizes.
This is the code you probably have:
add_theme_support( 'post-thumbnails' );
set_post_thumbnail_size( 94, 144, true );
At this point, all instances of the_post_thumbnail will output the image at 94×144. There are two main ways to output a different size: using predefined image sizes, or by specifying your own. Using the_post_thumbnail('thumbnail'), for instance, will display the thumbnail using your install’s thumbnail settings, in Settings > Media. This too, however, can only be set globally, and isn’t ideal since the thumbnail size is likely used elsewhere on your site. More »
