When should there be a declarative version of a JavaScript API?

I feel like it’s high time I revived some interest in my proposal for button type="share". Last I left it, I was gathering use cases and they seem to suggest that the most common use case for the Web Share API is sharing the URL of the current page.

If you want to catch up on the history of this proposal, here’s what I’ve previously written:

Remember, my proposal isn’t to replace the JavaScript API, it’s to complement it with a declarative option. The declarative option doesn’t need to be as fully featured as the JavaScript API, but it should be able to cover the majority use case. I think this should hold true of most APIs.

A good example is the Constraint Validation API. For the most common use cases, the required attribute and input types like “email”, “url”, and “number” have you covered. If you need more power, reach for the JavaScript API.

A bad example is the Geolocation API. The most common use case is getting the user’s current location. But there’s no input type="geolocation" (or button type="geolocation"). Your only choice is to use JavaScript. It feels heavy-handed.

I recently got an email from Taylor Hunt who has come up with a good litmus test for JavaScript APIs that should have a complementary declarative option:

I’ve been thinking about how a lot of recently-proposed APIs end up having to deal with what Chrome devrel’s been calling the “user gesture/activation budget”, and wondering if that’s a good indicator of when something should have been HTML in the first place.

I think he’s onto something here!

Think about any API that requires a user gesture. Often the documentation or demo literally shows you how to generate a button in JavaScript in order to add an event handler to it in order to use the API. Surely that’s an indication that a new button type could be minted?

The Web Share API is a classic example. You can’t invoke the API after an event like the page loading. You have to invoke the API after a user-initiated event like, oh, I don’t know …clicking on a button!

The Fullscreen API has the same restriction. You can’t make the browser go fullscreen unless you’re responding to user gesture, like a click. So why not have button type="fullscreen" in HTML to encapsulate that? And again, the fallback in non-supporting browsers is predictable—it behaves like a regular button—so this is trivial to polyfill. I should probably whip up a polyfill to demonstrate this.

I can’t find a list of all the JavaScript APIs that require a user gesture, but I know there’s more that I’m just not thinking of. I’d love to see if they’d all fit this pattern of being candidates for a new button type value.

The only potential flaw in this thinking is that some APIs that require a user gesture might also require a secure context (either being served over HTTPS or localhost). But as far as I know, HTML has never had the concept of features being restricted by context. An element is either supported or it isn’t.

That said, there is some prior art here. If you use input type="password" in a non-secure context—like a page being served over HTTP—the browser updates the interface to provide scary warnings. Perhaps browsers could do something similar for any new button types that complement secure-context JavaScript APIs.

Have you published a response to this? :


Guilherme Simões

Agreed! Another example: btn.addEventListener(‘click’, () => window.print()); Why not have a <button type=”print”> ?

1 Share

# Shared by Zachary Dunn on Thursday, March 10th, 2022 at 3:09pm


# Liked by Viorel Mocanu on Wednesday, March 9th, 2022 at 8:36pm

# Liked by Chris Taylor on Thursday, March 10th, 2022 at 7:48am

Previously on this day

1 year ago I wrote March

Out of the ordinary.

1 year ago I wrote Content buddy

Moving words around.

2 years ago I wrote 41 hours in Galway

A weekend of food and music to celebrate my birthday.

3 years ago I wrote Handing back control

An emergent theme at An Event Apart Seattle 2019.

3 years ago I wrote Updating email addresses with Mailchimp’s API

A change in version 3 of Mailchimp’s API.

4 years ago I wrote A workshop on building for resilience

The progressive web: a day-long workshop.

7 years ago I wrote Huffduffing video

Now you can grab the audio from YouTube and Vimeo videos for your huffduffing pleasure.

13 years ago I wrote Crawlbar

Say it with me.

17 years ago I wrote Perfect timing

Just in time for South by SouthWest, the Washington post has published an article called “Texas Eat ‘Em” about barbecue in the Lone Star State:

18 years ago I wrote We'll always have Paris

I’m back from my weekend in Paris.

20 years ago I wrote Trout Thursday

Only 327 days to go.