You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I love what you've done here. The HTML-based API is simple and elegant, and I don't need to think about Javascript or JSON nearly at all in order to implement it. I took a very brief look at the implementation, but am recognizing that I'm not familiar enough with several of the technologies involved to have answers to some of my questions, and figured you might be willing to answer or discuss them with me.
Particularly, I'm wondering if this or a similar custom element could be used a button. Buttons have some really neat properties that I think could be very helpful in this context. Two specific features come to mind immediately that could be useful.
First, buttons can override or declare certain form attributes, like enctype and action. This could make it possible for a different backend page to process the login form if the Passkeys button is the one used to submit. This would run afoul of the limitations you've noted with Safari, but assuming that bug gets cleared up, that could be useful.
Second, buttons are able to submit to forms that are located elsewhere in the DOM: they do not need to be a direct descendant. This is also possible with inputs, so it's not unique to buttons, but could be helpful as a form-related control, to maintain as much parity with existing inputs as possible.
Thanks again for your work, and if you don't have the time to answer, I understand: we're all busy.
The text was updated successfully, but these errors were encountered:
I got stuck on this too when experimenting. I agree a button seems to be ideal when you don't care about the autocomplete stuff. Especially when you do not care about the input[type=text] field for the username and just want a "Log in with Passkey" button. And also create-public-key-credential most likely can only be a button.
Problem that I got stuck on is that custom elements can currently not act as submit buttons:
You can partially work around this by calling requestSubmit() in an onClick handler. But it has limitations like not being part of the implicit submit and also no support for :default focus
I love what you've done here. The HTML-based API is simple and elegant, and I don't need to think about Javascript or JSON nearly at all in order to implement it. I took a very brief look at the implementation, but am recognizing that I'm not familiar enough with several of the technologies involved to have answers to some of my questions, and figured you might be willing to answer or discuss them with me.
Particularly, I'm wondering if this or a similar custom element could be used a button. Buttons have some really neat properties that I think could be very helpful in this context. Two specific features come to mind immediately that could be useful.
First, buttons can override or declare certain form attributes, like
enctype
andaction
. This could make it possible for a different backend page to process the login form if the Passkeys button is the one used to submit. This would run afoul of the limitations you've noted with Safari, but assuming that bug gets cleared up, that could be useful.Second, buttons are able to submit to forms that are located elsewhere in the DOM: they do not need to be a direct descendant. This is also possible with inputs, so it's not unique to buttons, but could be helpful as a form-related control, to maintain as much parity with existing inputs as possible.
Thanks again for your work, and if you don't have the time to answer, I understand: we're all busy.
The text was updated successfully, but these errors were encountered: