A plea: a convention for <input name="handle">

Discussion
1

As someone who uses my phone more than maybe advisable, I end up typing in jauntwk.bsky.socialmuch more than I want to to log into neat atproto apps. Every now and then the browser can auto-complete for me, but it feels too rare! This post is a plea for help from the atproto ecosystem, to please try to make this better.

It comes down to what name the input element has: that’s what the browser usually uses for autocomplete. I would love to have a convention/standard for what name to use for the <input> element that takes the username/handle/account, so that autocomplete works on whatever site we land on.

In the title, I went with handle . I am totally fine with bike-shedding this. I went with this for two reasons: because it was the term of the art I saw in one particular README (cited below), and it was what the last app I logged in to used (welcome online https://drerings.app).

But it feels like having some advice we can hand out for what to name this form element would help users a lot. I’m not sure how or where such guidance should go that it’s easy to provide & feels authoritative; a little thread here feels like just a starting place & I want more, but I wanted to raise this usability issue, that I face, with hopes that we can improve the user experience for those trying to use their “internet handle”, as it were.

8 Likes
2

YES PLEASE. I would love to see a demo of this with a web app and a fork of Bitwarden designed to handle the handle text input.

2 Likes
3

You might go mention this request in this thread.

2 Likes
4

What we use in all of the “cookbook” examples (eg, for Go, Python, JavaScript, TypeScript) is <input name=“username” …>.

2 Likes
5

I use this for Smoke Signal, Lexicon Garden, etc.:

<input
    class="input" type="text" id="loginHandleInput" name="handle"
    autocomplete="username" placeholder="alice.bsky.social"
    data-loading-disable="">
5 Likes
6

I’d love to know what (hack) Deviantart is doing to make this already work.

7

Nice, implemented it in Barazo right away: feat(auth): add name="handle" to login input for cross-app autocomplete by gxjansen · Pull Request #149 · barazo-forum/barazo-web · GitHub :flexed_biceps:

1 Like
8

Browsers and password managers can use the name field to determine autofill, but the autocomplete property is the proper way to accomplish this. Here’s what I use for atproto handle inputs on Cartridge:

<input
  autocomplete="username"
  name="handle"
  pattern="(\\w+\\.)+\\w+"
  type="text">
  • name - This just gives the form a key for the input in its FormData. Using it for anything beyond that is outside of the HTML spec. The only reason it works in select cases is because these applications are trying to be helpful for users on websites that don’t properly use the autocomplete attribute.
  • autocomplete - Setting this to username is the appropriate analog for atproto domain handles.
  • type - I use text instead of url because not all browsers properly validate this. Some require a scheme like http://, others validate the TLD against an out-of-date list so handles like mine with newer TLDs (e.g. .codes) don’t validate.
  • pattern - The pattern I’m using is slightly too permissive for full validation but it does allow all valid handles to pass. This only matters if you check the input’s (or form’s) validity before submission using the ValidityState API.
5 Likes
9

These are all valid inputs though:

  • ngerakines.me (handle hostname)
  • @ngerakines.me (@handle syntax)
  • at://ngerakines.me (AT-URI with handle authority)
  • did:plc:cbkjy5n7bk3ax2wplmtjofq2 (plain did)
  • at://did:plc:cbkjy5n7bk3ax2wplmtjofq2 (AT-URI with DID authority)
  • https://pds.cauda.cloud (my pds)
  • https://morel.us-east.host.bsky.network/ (oath-protected-resource)
  • https://bsky.social (oauth-authorization-server)
2 Likes
10

if the input is labeled “Handle,” I wouldn’t expect it to take just any of those (maybe there’s a better way to communicate what’s allowed). The pattern is mostly unimportant in this context, tho. The autocomplete attribute is what matters. I can remove the pattern if it’s distracting from the topic.

11

Sorry, fwiw I’m not harping on pattern. Just trying to say that autocomplete may mean different type of information and should probably reference multiple fields:

<input
  autocomplete="username handle did login-url"
  name="handle"
  type="text">

[autocomplete on MDN]

3 Likes
12

Ahh, sorry, I misunderstood. That’s an awesome addition. :heart:

13

Yeah, autocomplete=”username” might be better than name=”username” :

2 Likes
14

This seems like the best approach to go with. My one concern is that it seems a little unclear to me if those extra detail tokens after username in the autocomplete attribute are allowed / not inaccessible. Reading HTML attribute: autocomplete - HTML | MDN, I’m hoping that browsers and accessibility tools (and password managers alike) parse the details list and ignore the non-standard ones that follow?

Then, if we are providing these autocomplete details/hints, how do we make it useful - is it having password managers start recognizing it? There might be an open question here of how a password manager should even store a handle as an entry, to use in every atproto app.

One parting thought: how much bikeshedding is this worth if we could angle for FedCM with custom identity providers instead?

1 Like
15

Hey folks. Thank you all so much for your contributions. I want to try to append some recommendations in the future but trying to figure out what exactly to say is hard & you all have so many good ideas!

I also want to share this link, which has some more really really good ideas for how to make the input box experience signficiantly better (thanks tyler.fun for posting): @tyler.fun on Bluesky

1 Like