Add FAQ section about the ask-on-use paradigm

explainer.md

@@ -488,6 +488,7 @@ This alternative proposed creating a registry for "well-behaved" origins. Once a
 <!-- TOC --><a name="faq"></a>
 ### FAQ Section
 - **Q: Does the `<permission>` element increase complexity for user agents?** Yes, the security measures, styling constraints, timing, and position mitigations add complexity for user agents. However, this complexity is inherent in the design, which aims to place the permission request within the user's context and control, addressing shortcomings of current permission flows, ultimately shifting the burden from users to the user agents. We believe the user benefits justify these complexities.
+- **Q: Does this break the paradigm of ask-on-use?** Yes, it does. Historically this paradigm has been used with the assumption that this flow helps provide user context for their permission decisions (see the [removal of request()](https://github.com/w3c/permissions/issues/83) thread). However, this in practice is often not the case. In practice the time when a developer wants to use a capability is a very different time then when a user wants to make a capability decision. Consider the metric that 79% of prompts are triggered without a user gesture (in Chrome, May 2025), and that the lack of user gesture is a strong indicator that the user currently has no context nor desire to make a permission decision for these prompts. This is easily explained by the many use cases where a capability will improve the site experience in some way, so naturally the developer will try to use said capability early in the page's lifetime. Making permission prompts a transparent step of using said capability means that even well-intentioned developers will often miss the fact that simply trying to make use of a capability can result in worse UX due to it producing an annoying permission prompt. Example use cases: delivery sites, navigation sites, teleconference sites (where calls can be incoming at random moments), pretty much any site which uses the file system API, calendars sending notifications about upcoming events, gaming sites (to detect if controllers are plugged-in), etc
 - **Q: How does The `<permission>` element handle backwards compatibility?** Backwards compatibility is supported by showing fallback content if the `<permission>` element (or its specified type attribute) is not supported. This allows developers to provide a fallback experience using existing APIs. The element is designed to degrade gracefully and provide a fallback experience.
 - **Q: Does the `<permission>` element encourage websites to ask for permission ahead of access?** No, the `<permission>` element fundamentally shifts control to the user, as websites cannot proactively request permissions via this element; only the user can initiate the flow. The clear string on the button like "use <capability>" signals an immediate action, discouraging premature requests. For real-time capabilities, some proactive setup is often desired by users, and developers are responding to this need, not an encouragement from the `<permission>` element.
 - **Q: Is "priming" or "pre-prompting" a concern with the `<permission>` element?** Preparing users for permission requests is not inherently detrimental, and we want to encourage providing contextual information. The `<permission>` element facilitates a standardized approach to this. Our research indicates that helpful pre-prompting can lead to higher grant rates. Preventing sites from pre-prompting is practically infeasible. The `<permission>` element prioritizes a consistent, user-centric experience, regardless of pre-prompting, empowering users with clarity and control. The `<permission>` element can also reduce the need for sites to display troubleshooting prompts that guide users through browser settings.