Forms

This is a fascinating deep dive by the people at Discord on their development of a focus ring component and all the problems they had to overcome:

Browsers implement default focus rings that apply to all elements, but the ability to style these is (currently) very limited. These rings, while they have recently improved greatly in Chrome and Edge, are also not very pleasant when integrated with the rest of Discord’s design, and other browsers like Firefox are almost entirely invisible in most cases due to the thinness and low contrast of their styles.

As such, we want to implement a custom focus ring style. At a glance, this seems relatively simple, but when dealing with the variety of use cases Discord has for these rings, the list of requirements quickly grows, and the options for implementations shrink.

Ideally, we want to match the browser’s focus ring behavior exactly. Within Discord, this means that a comprehensive focus ring implementation needs to:

• Perfectly map to the element that has focus (with exceptions listed below).
• Follow elements as they move when containers scroll.
• Follow elements as they animate and transition within the document.
• Not be clipped off when the focused element is bounded by overflow: hidden or other bounding techniques.
• Respect occlusion of overlapping elements, but not be occluded by an element’s own z-index.

Additionally, to be able to implement pleasant and overall better focus styles for various elements in the app, we have additional requirements to be able to:

• Apply the focus ring on a different element than the actual focused element
• Provide positional offsets to adjust ring placement around the element.
• Adjust ring styles to match the look and feel of the surrounding context (could include changing border radius, color, shape, and more)
• Specify a style for when focus is within an element, for example to indicate the bounds of a widget.

See the source link for the rest.

The term brutalism is often associated with Brutalist Architecture, however it can apply to other forms of construction, such as web design.

[…]

The term brutalism is derived from the French béton brut, meaning “raw concrete”. Although most brutalist buildings are made from concrete, we’re more interested in the term raw. Concrete brutalist buildings often reflect back the forms used to make them, and their overall design tends to adhere to the concept of truth to materials.

A website’s materials aren’t HTML tags, CSS, or JavaScript code. Rather, they are its content and the context in which it’s consumed. A website is for a visitor, using a browser, running on a computer [or mobile device] to read, watch, listen, or perhaps to interact. A website that embraces Brutalist Web Design is raw in its focus on content, and prioritization of the website visitor.

Brutalist Web Design is honest about what a website is and what it isn’t. A website is not a magazine, though it might have magazine-like articles. A website is not an application, although you might use it to purchase products or interact with other people. A website is not a database, although it might be driven by one.

They list the following principles:

• Content is readable on all reasonable screens and devices.
• Only hyperlinks and buttons respond to clicks.
• Hyperlinks are underlined and buttons look like buttons.
• The back button works as expected.
• View content by scrolling.
• Decoration when needed and no unrelated content.
• Performance is a feature.

A repository of styled and “styled” form control patterns, and how they are announced by screen readers.

Why?

Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.

I recently embarked on improving the client-side form validation for a client. There were about 400 lines of form validation code stuffed inside a 1000 line form_helper.js. I looked for lightweight form validation scripts but after some hemming and hawing I decided to try my hand (again) at native HTML5 Form Validation.

If you’ve ever experimented with HTML5 Form Validation, you’ve probably been disappointed. The out-of-box experience isn’t quite what you want. Adding the required attribute to inputs works wonderfully. However the styling portion with input:invalid sorta sucks because empty inputs are trigger the :invalid state, even before the user has interacted with the page.

I finally sat down and spent a couple days trying to make HTML5 Form Validation work the way I want it. I had the following goals:

1. Leverage browser-level feedback, free focus management and accessible labelling
2. Only validate inputs on submit
3. Styling with .error class

With this wishlist in hand, I set off and found a solution that works with only 6 lines of code.

Web forms are complex beasts. There are a lot of field types to remember, each with dozens of attributes. It’s hard to know which is the right way to go, especially when presented with a choice between two seemingly similar options for disallowing a field to be edited: disabled and readonly.

TL;DR: If you really need it, which you probably don’t, readonly is what you want.

[…]

The Key Difference

So why do we have two attributes that do the same thing? Unfortunately this is where developers often get confused: the user experience is the same, but the mechanics are quite different.

Fields marked as readonly are collected along with all of the normal field values in a form submission (“successful controls” in the spec). The only difference between a readonly field and a regular field is the user experience.

Fields marked as disabled are ignored when collecting values from the form. In a traditional form submission, the action page would never receive values for a disabled field, regardless of whether it has a name attribute.

This seems like it could be a useful tool:

Increase your form conversions by fixing common usability issues

Copying text to the clipboard shouldn’t be hard. It shouldn’t require dozens of steps to configure or hundreds of KBs to load. But most of all, it shouldn’t depend on Flash or any bloated framework.

That’s why clipboard.js exists.

The intersection of rushed (or careless) development and unintended consequences:

We’re doing a story about people that have names that websites and computers don’t seem to like - for example, we spoke to a guy named William Test, and a woman named Katie Test, both of whom can’t seem to keep a hotel or airplane booking because the name “test” is flagged by internal systems.

We also spoke to a guy named Christopher Null who had the same problem, and woman named Joan Fread, who can’t use paypal because her last name is the same as a PHP command.

I’m curious if there’s anyone in the dev community that is thinking about this, and how to deal with it. Is it even considered a problem? Is the population that this affects so small that people don’t even think about it?