Declarative API should not be provided natively #144
Description
Per the explainer the goal of the Declarative API is
To make it easier for developers to expose this kind of site functionality while still using the semantic web
Why should this be a native browser primitive rather than a library-level abstraction? Current web applications collect input from users in a variety of ways and are build using a variety of technologies. For WebMCP you need to somehow build a JSON input schema, and depending on the technology the best way and source to build that JSON input schema will differ. The Declarative API is build on the premise that for many forms the <form> node itself could be used as the source for building the input schema (and then quickly realized it's not really enough, so a bunch of custom attributes were thrown on top). But - as noted by the Angular team in #138 - this will often not be the best source for any form that has a more expressive Form-builder driving it.
I hypothesize that the Declarative API will be great during the initial adoption phase, but as needs grow many applications will hit the limit of what can be expressed through the 'too limited' translation provided by the Declarative API. At that point teams will slowly develop and adopt solutions that connect to the more powerful Imperative API and transition the 'simple' tools along. I believe the Declarative API carries a really risk of fading to irrelevance over the course of the next 5 years... and then we will be stuck with it 'forever'.
So: For those applications that would actually benefit from the Declarative API it's trivially easy to imagine a userland library that would provide exactly that syntax. And for those applications that are build using different technologies bespoke user land solutions will be developed to ease adoption.
(And this is more of a personal aside, I actually question the general premise of the Declarative API as well. From experience, traditional MCP servers do not typically blindly expose existing APIs, and instead more bespoke tools are developed that make sense for agentic LLMs. The same applies to the web: You need to design bespoke tools that Agentic LLMs can sensibly interact with. And sure, you could just have a bunch of hidden <form> elements on your page that mirror the user facing forms and controls... but ech?)
(And maybe one more point: The Declarative API didn't use i18n labels for fear that existing labels would decrease in quality when sites would attempt to 'prompt engineer' the labels. By that exact same logic the Declarative API itself creates awkward pressure on developers to structure their HTML for agent consumption rather than purely for users. The more I think about this the less I like this proposal.)