Choosing the right input type for your form field.
There’s this really common use-case I’ve seen at Codebar and Homebrew Website Club, where someone is making a static site, but they just want a contact form that sends data via email. This looks like a handy third-party service to do just that. No registration required: it’s all done via the value of the
action attribute in the opening
A great series of short videos from Marcy on web accessibility.
A handy tool for testing the legibility of different typefaces under all sorts of conditions.
You’re supposed to be able to create two-handled sliders with
input type="range" but the browser support isn’t there yet. In the meantime, Lea has created a nice lightweight polyfill.
Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.
Did I mention that it’s free?
The greatest form ever made.
A step-by-step walkthrough of how GitHub has tweaked its Content Security Policy over time. There are some valuable insights here, and I’m really, really happy to see companies share this kind of information.
When I’ve been helping Codebar students on their personal projects, everything goes great until some kind of server-side processing is needed. Nine times out of ten, that server-side processing simply doing something with the contents of a contact form. This looks like it could be a useful service to plug into little projects like that.
Use the right element for the job.
- Does the Control Take Me to Another Page? Use an Anchor.
- Does the Control Change Something on the Current Page? Use a Button.
- Does the Control Submit Form Fields? Use a Submit.
The ability to follow links down and around and through an idea, landing hours later on some random Wikipedia page about fungi you cannot recall how you discovered, is one of the great modes of the web. It is, I’ll go so far to propose, one of the great modes of human thinking.
A clever technique by Emil to implement the “float label” pattern using CSS. It all hinges on browsers supporting the
:placeholder-shown pseudo-class which, alas, is not universal.
I was hoping that maybe
@supports could come to the rescue (so that a better fallback could be crafted), but that tests for properties and values, not selectors. Damn!
Well, this is timely! Just today I was having a really good natter with Charlotte about using checkboxes, specifically sending multiple values to the server:
You’ll notice that the
namegiven to each of these checkbox
inputelements is the same: “reservation-requested-device”. The square brackets (“”) at the end of the
nameare the magic bit that allows the values of each chosen “reservation-requested-device” checkbox to be submitted as the value of “reservation-requested-device”.
See, I wasn’t sure whether that was just a PHP thing (the only server-side input-handling I’ve had much experience of) or whether it was a more general way of sending multiple values.
Update: It seems that the square brackets are indeed a PHP thing. Multiple values will be sent in any case. See this test case.
A useful primer on which combinations of attributes and values work best for which form fields:
Marco gives a run-down of the basics of getting accessibility right on the web. Nothing here is particularly onerous but you’d surprised how often developers get this wrong (or simply aren’t aware of it).
He finishes with a plea to avoid unnecessary complexity:
The sad history of
I wish I could share in the closing optimism:
Now imagine the future where Web Components are supported natively, and someone else is allowed to write a <better-input>, an element that is a real, encapsulated DOM element, and not just a div soup. Imagine using this <better-input> that isn’t implemented differently in each browser, that looks the same everywhere, and that probably also knows how to bake you a cherry pie.
But I all I can think is:
Now imagine the future where Web Components are supported natively, and everyone is allowed to write a million variations of <my-idea-of-a-better-input>, an element that is an inaccessible div soup under the hood.
Paul compares publishing on the web to publish on proprietary platforms, and concludes that things aren’t looking great right now.
Performance is the number one selling point for each of these new content platforms.
I completely understand Peter’s fears here, and to a certain extent, I share them. But I think there’s a danger in only looking to what native platforms can do that the web doesn’t (yet). Perhaps instead we should be looking to strengthen what only the web can offer: ubiquity, access, and oh yeah, URLs.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Beautiful use of CSS transitions and transforms.
Also: CSS is officially the new Flash—”skip intro” is back.
A great investigation into the usability benefits of allowing users to fill in their passwords in plain text.
Major caveat: make sure you still offer the ability to mask passwords too.
Lea wasn’t happy with the lack of styling and extensibility of the datalist element, so she rolled her own lightweight autocomplete/type-ahead widget, and she’s sharing it with the world.
Simon St. Laurent on uncertainty as a feature, not a bug.
Luke continues to tilt against the windmills of the security theatre inertia that still has us hiding passwords by default. As ever, he’s got the data to back up his findings.
Yesterday, Aaron gave a great talk at BD Conf about forms. In one example, he was using
aria-describedby. I was a bit confused by the differences between
aria-labelledby, so Aaron has very helpfully clarified the distinction.
A great technique from Heydon for styling radio buttons however you want.
Léonie gives a great, clear description of how screen readers switch modes as they traverse the DOM snapshot.
A fantastic collection of short videos from Luke on interaction design for devices of all shapes and sizes.
Make yourself a nice cup of tea, hit “Play all”, sit back, relax and learn from the master.
I really like this interface idea from Brad that provides the utility of input masks but without the accessibility problems.
This looks like a nifty take on the ol’ using-labels-like-placeholders pattern for forms. I still prefer to have a label visible at all times, but this seems like a nice compromise.
Here’s a clever use of flexbox: have a form field stretch to fill up most of the space and a button fill up what’s left.
A look at how Huffduffer-style forms might improve “conversion”.
Whatever. Let’s face it: it’s just quite nice when a form isn’t just your typical form (which this article makes a good point of mentioning):
Where the traditional sign up form is a regular, everyday brown cow, the mad lib form is a purple cow - a shiny object. We’re naturally easily distracted by, and drawn to, what’s new or out of the ordinary! Take advantage of that.
Want to style those new HTML5 input types? I hope you like vendor prefixes.
This is wonderful stuff! I’m a big fan of the
datalist element but I hadn’t realised how it could be combined with
input types like
Here are some nice patterns that Paul uses for starting points in his own projects.
Bruce takes a look at the tricky issue of styling native form controls. Help us, Shadow DOM, you’re our only hope!
Andrea looks at support for HTML5 input types in IE10 Mobile.
I concur completely with Luke’s assessment here. Most password-masking on the web is just security theatre. Displaying password inputs by default (but with an option to hide) should be the norm.
This looks like a handy way of enhancing forms to have input masks (Luke W. would approve). Right now it’s a jQuery plug-in but I’m sure someone as smart as you would be able to create a standalone version, right?
Here’s a handy little tip for CSS animations: instead of changing position properties, use translate instead.
A look at the new pseudo-classes in CSS3 that go hand-in-hand with the form enhancements introduced in HTML5.
impress.js | presentation tool based on the power of CSS3 transforms and transitions in modern browsers | by Bartek Szopka @bartaz
This looks like a nice progressive enhancement pattern: convert a select element into an auto-completing input element (a country selector in this case).
This abuse of the !important declaration in Firefox’s user-agent stylesheet was driving me crazy recently. Roger proposes a CSS patch, but this is really something that needs to be fixed in the browser.
A terrific overview by Richard of the variations in names around the world:
How do people’s names differ around the world, and what are the implications of those differences on the design of forms, ontologies, etc. for the Web?
A fascinating examination by Hixie of web technologies that may have technically been “better” than HTML, but still found themselves subsumed into the simpler, more straightforward, good ol’ hypertext markup language.
The follow-on comments are definitely worth a read too.
A handy list of regular expressions that you can use in the new pattern attribute on the input element in HTML5.
New Mobile Safari stuff in iOS5: position:fixed, overflow:scroll, new input type support, web workers, ECMAScript 5 | David B. Calhoun – Developer Blog
Eric is making some genuinely beautiful art by applying CSS transforms to some well-known sites.
More brilliant and useful code from Glenn: copy and paste contact details from one URL into a form on another URL.
Andy just debuted this at An Event Apart—lovely stuff.
A cute’n’nifty demonstration of transforms and animations in CSS that works a treat in Webkit.
A nice succinct description of the placeholder attribute, with an emphasis on accessibility.
A quick run-through of some of the new HTML5 form features coming in Firefox 4.
A very handy page for showing HTML5 form element support in your browser.
A very handy looking API that turns file uploading (and conversion) into a service.
An interesting proposal for a Huffduffer-style mad-libs ad-posting form for Craigslist.
Leah has some great ideas on combing "log in" and "sign up" forms into one.
Steven Pemberton, one of my favourite long-term thinkers, talks about programming, markup and XForms.
Experimenting with CSS3 and HTML5 features implemented in Webkit.
The 26 step process required to add +1 to a feature request in IE. Franz Kafka is alive and well and living in Redmond.
A nice stab at a markup (and CSS) pattern for forms.
Demo for a neat piece of code that will auto-populate form fields from an hCard-carrying URL.
Interface elements as fridge magnets. Make prototyping fun!
Screenshots of various log in screens on the iPhone. I think Cindy has been hanging out with Luke W.
Tom Hume demos Octobastard: a robot arm controlled from a mobile phone.
A nice piece of UI design. I think Kathy Sierra would like this.
WebKit continues to steam ahead. Now with CSS transforms; you can scale and rotate your elements.
A nice bit of unobtrusive DOM scripting for validating just about any form.