Link tags: form



Let a website be a worry stone. — Ethan Marcotte

It was a few years before I realized that worry stones had a name, that they were borrowed from cultures other and older than mine. Heck, it’s been more than a few years since I’ve even held one. But in the last few weeks, before and after launching the redesign, I’ve kept working away at this website, much as I’d distractedly run my fingers over a smooth, flat stone.

BBC - Future Media Standards & Guidelines - Accessibility Guidelines v2.0

A timely reminder:

The minimum dependency for a web site should be an internet connection and the ability to parse HTML.

Maintaining Performance -

In my experience, 99% of the time Web Performance boils down to two problems:

  1. “You wrote too much JavaScript.”
  2. “You have unoptimized images.”

But as Dave points out, the real issue is this:

I find that Web Performance isn’t particularly difficult once you understand the levers you can pull; reduce kilobytes, reduce requests, unblock rendering, defer scripts. But maintaining performance that’s a different story entirely…

Get Static – Eric’s Archived Thoughts

Performance matters …especially when the chips are down:

If you are in charge of a web site that provides even slightly important information, or important services, it’s time to get static. I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.

Inclusive Inputs « Texte | ovl – code & design

This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.

Rise of the Digital Fonts

A history of typesetting from movable type to variable fonts.

Visitors, Developers, or Machines

Garrett’s observation is spot-on here:

I’ve been trying to understand the appeal of these frameworks by giving them an objective chance. I’ve expanded my knowledge of JavaScript and tried to give them the benefit of the doubt. They do have their places, but the only explanation I can come up with is that developers are taking a similar approach as Ruby and focusing on developer convenience and productivity. Only, instead of Ruby’s performance being tied to the CPU level, JavaScript frameworks push the performance burden to the client.

In both cases, the tradeoff happens in the name of developer happiness and productivity, but the strategies have entirely different consequences. With Ruby, the CPU is still (mostly) the responsibility of the development team, and it can be upgraded. With JavaScript, the page weight becomes an externality pushed onto visitors.

Why the GOV.UK Design System team changed the input type for numbers - Technology in government

Some solid research here. Turns out that using input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using input type="number".

Why 543 KB keep me up at night - Manuel Matuzović

How and when did I get to the point where I would consider a page weight of 4 MB on a large page and 500 KB on a small page normal?

This isn’t just a well-earned rant from Manuel. I mean, it *is that, but it’s also packed with practical performance advice.

Reflections on software performance - Made of Bugs

I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived.

This is a fascinating look into how performance has knock-on effects beyond the obvious:

It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.

What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task.

This observation is particularly salient for web developers:

We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.

Web bloat

Pages are often designed so that they’re hard or impossible to read if some dependency fails to load. On a slow connection, it’s quite common for at least one depedency to fail.

Fire up Reader Mode and read this excellent article informed by data from using a typically slow connection in rural USA today. Two findings are:

  1. A large fraction of the web is unusable on a bad connection. Even on a good (0% packetloss, no ping spike) dialup connection, some sites won’t load.
  2. Some sites will use a lot of data!

“Let us Calculate!”: Leibniz, Llull, and the Computational Imagination – The Public Domain Review

The characteristica universalis and the calculus racionator of Leibniz.

Emma Willard’s Maps of Time

The beautiful 19th century data visualisations of Emma Willard unfold in this immersive piece by Susan Schulten.


This is so useful! Get instant results from Google’s Chrome User Experience Report without having to wait (or pay) for BigQuery.

Here’s an example of my site’s metrics over the last few months, complete with nice charts.

A Complete Guide to Links and Buttons | CSS-Tricks

Chris takes two side-by-side deep dives; one into the a element, the other into the button element.

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 formaction, formenctype, formmethod, formnovalidate, and formtarget?

Page Speed Benchmarks | SpeedCurve

This is going to be so useful for client work at Clearleft—instant snapshots of performance metrics across industries and regions!

For example, we’ve been working a lot with the travel sector, and now we can call up these benchmarks without having to generate a whole bunch of Web Page Test results ourselves.

See Tammy’s blog post for me details.

Custom Styling Form Inputs With Modern CSS Features | CSS-Tricks

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 <div> or <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 @supports.

Innovation Can’t Keep the Web Fast | CSS-Tricks

I’ve come to accept that our current approach to remedy poor performance largely consists of engineering techniques that stem from the ill effects of our business, product management, and engineering practices. We’re good at applying tourniquets, but not so good at sewing up deep wounds.

It’s becoming increasingly clear that web performance isn’t solely an engineering problem, but a problem of people.

Google Maps Hacks, Performance and Installation, 2020 By Simon Weckert

I can’t decide if this is industrial sabotage or political protest. Either way, I like it.

99 second hand smartphones are transported in a handcart to generate virtual traffic jam in Google Maps.Through this activity, it is possible to turn a green street red which has an impact in the physical world by navigating cars on another route to avoid being stuck in traffic

HTML attributes to improve your users’ two factor authentication experience - Twilio

The many ways of improving a single form field in HTML.

I love these kinds of deep dives into markup!