A blog dedicated to documenting the letterforms on display in Berlin.
This is an excellent proposal from Emil. If we can apply
display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
This is a really great screencast on getting started with React. I think it works well for a few reasons:
- Sarah and Chris aren’t necessarily experts yet in React—that’s good; it means they know from experience what “gotchas” people will encounter.
- They use a practical use-case (a comment form) that’s suited to the technology.
- By doing it all in CodePen, they avoid the disheartening slog of installation and build tools—compare it to this introduction to React.
- They make mistakes. There’s so much to be learned from people sharing “Oh, I thought it would work like that, but it actually works like this.”
There’s a little bit of “here’s one I prepared earlier” but, on the whole, it’s a great step-by-step approach, and one I’ll be returning to if and when I dip my toes into React.
A look at the feedback needed for a slider control that feels “right”.
You can get most of the behavioural (though not styling) suggestions in HTML by doing this:
<form> <input type="range" min="0" max="100" value="50" onchange="amount.value=this.value" onmousemove="amount.value=this.value"> <output name="amount">50</output> </form>
Stylish and accessible checkboxes and radio buttons accompanied by an explanation of the CSS involved.
No images were harmed in the making of these form controls.
The ‘Credit Card Number’ Field Must Allow and Auto-Format Spaces (80% Don’t) - Articles - Baymard Institute
A deep dive into formatting credit card numbers with spaces in online forms.
Some interesting insights from usability and accessibility testing at the Co-op.
We used ‘nesting’ to reduce the amount of information on the page when the user first reaches it. When the user chooses an option, we ask for any other details at that point rather than having all the questions on the page at once.
Ever been on one of those websites that doesn’t allow you to paste into the password field? Frustrating, isn’t it? (Especially if you use a password manager.)
It turns out that nobody knows how this ever started. It’s like a cargo cult without any cargo.
There’s a whole category of native apps that could just as easily be described as “artisanal web browsers” (and if someone wants to write a browser extension that replaces every mention of “native app” with “artisanal web browser” that would be just peachy).
Here’s some more thoughts along the same lines:
We’re spending increasing amounts of time inside messaging apps and social networks, themselves wrappers for the mobile web. They’re actually browsers.
There’s an important take-away to this:
The web is and will always be the most popular mobile operating system in the world – not iOS or Android. It’s important that the next generation of software companies don’t focus exclusively on building native iOS or Android versions of existing web apps.
Just make sure those web apps render and work well in the new wave of mobile browsers – messengers. Don’t build for iOS or Android just for an imaginary distribution opportunity. Distribution exists where people spend most of their time today – social and messaging apps, the new mobile browser for a bot-enabled world.
I always loved the way that Gov.uk styled their radio buttns and checkboxes with nice big visible labels, but it turns out that users never used the label area. And because it’s still so frickin’ hard to style native form elements, custom controls with generated content is the only way to go if you want nice big hit areas.
A little tool for testing common form issues.
- Did we remember to give every input a label? (No, placeholders are not an adequate replacement)?
- Do our labels’ for attributes match our inputs’ ids?
- Did we take advantage of the url, email, and password input types, or did we forget and just use text?
- Are our required fields marked as such?
Usability Testing of Inline Form Validation: 40% Don’t Have It, 20% Get It Wrong - Articles - Baymard Institute
I saw Christian speak on this topic at Smashing Conference in Barcelona. Here, he takes a long hard look at some of the little things that sites get wrong when doing validating forms on the fly. It’s all good sensible stuff, although it sounds a bit medical when he takes about “Premature Inline Validation.”
Mandy is fighting the good fight for the open web from within Vox Media. Her publishing tools have been built with a secret weapon…
This practice — which I refer to unoriginally as progressively enhanced storytelling — also has the added benefit of helping us make our content more accessible to more kinds of users, especially those with disabilities.
Equal parts clever and scary. By using
autocomplete in HTML and some offscreen positioning in CSS, it’s possible to extract some unexpected personal information.
I expect browsers will be closing these holes pretty quickly.
This is a truly fantastic example of progressive enhancement applied to a form.
What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
Choosing the right input type for your form field.