HTML attributes to improve your users’ two factor authentication experience

There are plenty of opportunities for friction in the user experience when logging in, particularly while entering a two factor authentication code. As developers we should be building applications that support the need for account security but don’t detract from the user experience. Sometimes it can feel as though these requirements are in a battle against each other.

In this post we will look at the humble <input> element and the HTML attributes that will help speed up our users’ two factor authentication experience.

The final markup to trigger the correct keyboard and have the browser autocomplete the received SMS code is this:

<input
  type="text"
  name="token"
  id="token"
  inputmode="numeric"
  pattern="[0-9]*"
  autocomplete="one-time-code"
/>

HTML attributes to improve your users’ two factor authentication experience →

🚨 Do note that 2FA using SMS is not secure, mainly due to the lacking policies at SIM providers easily allowing SIM port hacks. The recently announced origin-bound OTP addition as proposed by Webkit/Apple won’t make any difference in the case of a SIM hack.

Why <details> is Not an Accordion

Dave Rupert on why that (wonderful) way of Using the <details> element to create modals and menus is not good for semantics.

Because <summary> has role="button", it eats the semantic content of elements inside it.

So that big <h1> inside of your <summary> becomes just another piece of text, sans semantics.

I especially like this part of his post too:

At the risk of being a broken record; HTML really needs <accordion>, <tabs>, <dialog>, <dropdown>, and <tooltip> elements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements. A new set of accessible controls for a modern era…

Why <details> is Not an Accordion →

💁‍♂️ FYI: We already have a <dialog> element, as detailed here. At the time of writing it is supported in Chrome (by default) and in Firefox (behind a flag). A polyfill is available.

Idiosyncrasies of the HTML parser

Highly interesting book (in the making) by Simon Pieters, on how HTML parsers work:

The HTML parser is a piece of software that processes HTML markup and produces an in-memory tree representation (known as the DOM).

The HTML parser has many strange behaviors. This book will highlight the ins and outs of the HTML parser, and contains almost-impossible quizzes.

Not for beginning audiences!

Idiosyncrasies of the HTML parser →

“Can I email…” – Support tables for HTML and CSS in emails

Can I email is like Can I use but specifically for email: which HTML and CSS features are supported by which mail client?

They also provide a scoreboard, ranking mail clients based on their support among the 70 HTML and CSS features listed on Can I email.

Can I email… Support tables for HTML and CSS in emails →
Can I Email – Email Client Support Scoreboard →

😱 Digging back in the archive I noticed that “Can I use…” got mentioned here on bram.us about 10 (!) years ago … wow, has it been that long already?!

Reducing motion with the <picture> element

Great trick by Brad Frost, in which he combines prefers-reduced-motion? with the <picture> element

<picture>
  <source srcset="no-motion.jpg" media="(prefers-reduced-motion: reduce)"></source> 
  <img src="animated.gif alt="brick wall" />
</picture>

Yes, that actually works!

Reducing motion with the <picture> element →

💫 When taking prefers-reduced-motion into account in your CSS code, it becomes really powerful when combined with CSS Custom Properties

Including content from other files in your HTML (“HTML Includes”)

Nice find by Scott Jehl from Filament Group: Instead of fetching files over XHR and then injecting their contents, you can also use an iframe + leverage its onload event to include the contents of any other file directly into the current web page.

<iframe
  src="signal.svg"
  onload="this.before((this.contentDocument.body || this.contentDocument).children[0]);this.remove()"
></iframe>

The example above loads up a .svg, but you can also use it to include other pieces of markup. Above that you can combine it with [loading="lazy"].

This is “Server Side Includes” all over again 😅

HTML Includes That Work Today →

Using the <details> element to create modals and menus

The folks over at GitHub have been leveraging the <details> element to create modals and menus:

<details class=“dropdown”>
  <summary class=“btn” aria-haspopup=“menu”>…</summary>
  <ul class=“dropdown-content”>
    <li><a href="/muan">profile</a></li>
    …
  </ul>
</details>

Very clever, as <details> trumps the <modal> element in many ways:

  • Semantic
  • Accessible
  • No JavaScript

Next to that, they’ve also released a few custom elements that make use of this technique: a <details-menu> and a <details-dialog> custom element.

Details on <details>
Details on <details> (slides)
<details-menu> element →
<details-dialog> element →

Multilingual Sites: Linking to Translations

Good piece by Hidde on the markup one needs to use when linking to a translation of a page.

The other day I worked on some front-end code that takes users to a version of the website in a different language. Two attributes can make such links more accessible: lang and hreflang. What’s the difference?

Linking to Translations →

Styling the select element

Scott Jehl, from Filament Group:

The select element has long been difficult to style consistently across browsers. To avoid its shortcomings in the past, we have used workarounds like styling a parent element, adding pseudo-elements, and even using JavaScript to construct a select-like control out of different elements that are easier to style. But workarounds are hard to maintain and use, not to mention the accessibility challenges that custom elements bring.

Recently, we’d seen some articles suggest that things haven’t changed a great deal with select‘s styling limitations, but I decided to return to the problem and tinker with it myself to be sure. As it turns out, a reasonable set of styles can create a consistent and attractive select across new browsers, while remaining just fine in older ones too.

Thanks to the appearance CSS property they’ve removed the native styling and were able to inject their own, all whilst retaining the behavior and semantics of the select itself (unlike JS implementations and other attempts). The result is quite nice:

Styling a Select Like It’s 2019 →
Styling a Select Like It’s 2019 (Demo) →

Pure CSS Francine – An 18th-Century Oil Painting Recreated with HTML and CSS

Handcrafted recreation of an 18th-century oil painting using just HTML and CSS.

Here’s an analysis of it using the Chrome DevTools, as recorded by Paul Irish:

Chrome only though:

Because of the artistic nature of this project I have not concerned myself with cross-browser-compatibility, so the live preview will most likely look laughable in anything other than chrome.

However, the results in other browsers are quite viewable (and remind me of the ACID tests)

Pure CSS Francine →
Pure CSS Francine Source →