A genuinely interesting (and droll) deep dive into derp learning …for typography!
Six years old. Still very astute. Still very true.
This is handy—an up-to-date list of tests run on form fields with different combinations of screen readers and browsers.
Standardizing `select` And Beyond: The Past, Present And Future Of Native HTML Form Controls — Smashing Magazine
While a handful of form controls can be easily styled by CSS, like the button element, most form controls fall into a bucket of either requiring hacky CSS or are still unable to be styled at all by CSS.
Despite form controls no longer taking a style or technical dependency on the operating system and using modern rendering technology from the browser, developers are still unable to style some of the most used form control elements such as
select. The root of this problem lies in the way the specification was originally written for form controls back in 1995.
Stephanie goes back in time to tell the history of form controls on the web, and how that history has led to our current frustrations:
The current state of working with controls on the modern web is that countless developer hours are being lost to rewriting controls from scratch, as custom elements due to a lack of flexibility in customizability and extensibility of native form controls. This is a massive gap in the web platform and has been for years. Finally, something is being done about it.
I can see how this would be good to have fixed at the browser level.
Another five pieces of sweet, sweet low-hanging fruit:
- Always label your inputs.
- Highlight input element on focus.
- Break long forms into smaller sections.
- Provide error messages.
- Avoid horizontal layout forms unless necessary.
Five pieces of low-hanging fruit:
- Unlabelled links and buttons
- No image descriptions
- Poor use of headings
- Inaccessible web forms
- Auto-playing audio and video
This is a terrific collection of guidelines for form design.
I guess, because browser-makers tend to be engineers so they do engineering-type things like making the browser an app-delivery platform able to run compiled code. Or fight meaningless user experience battles like hiding the URL, or hiding View Source – both acts that don’t really help early users that much, but definitely impede the user path from being a consumer to being a fully-fledged participant/maker.
Own. Your. Nook. There’s power in owning your nook of the ‘net — your domain name, your design, your archives — and it’s easier than ever to do so, and run a crowdfunding campaign at the same time.
Some good blogging advice.
Building a blog for the long run? Avoid Medium.
This is great! Ideas for allowing more styling of form controls. I agree with the goals 100% and I like the look of the proposed solutions too.
The team behind this are looking for feedback so be sure to share your thoughts (I’ll probably formulate mine into a blog post).
I never thought of combining the
datalist element with
input type="color"—it’s pretty cool that it just works!
Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct
autocompleteattributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.
This is an excellent deep dive with great advice:
You may think that you are familiar with the basic
autocompleteoptions, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!
Chromium browsers—Chrome, Edge, et al.—are getting a much-needed update to some interface elements like the
progess element, the
meter element, and the
color input types.
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
Some solid research here. Turns out that using
input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using
Chris takes two side-by-side deep dives; one into the
a element, the other into the
Even if you think you already know those elements well, I bet there’ll be something new here for you. Like, did you know that the
button element can have form over-riding attributes like
It’s now easier than ever to style form controls without sacrificing semantics and accessibility:
The reason is that we can finally style the ::before and ::after pseudo-elements on the
<input>tag itself. This means we can keep and style an
<input>and won’t need any extra elements. Before, we had to rely on the likes of an extra
<span>, to pull off a custom design.
The demo is really nice. And best of all, you can wrap all of these CSS enhancements in a feaure query:
Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to
The many ways of improving a single form field in HTML.
I love these kinds of deep dives into markup!