Re: Collective term for Screen Capture CG APIs in MDN docs?

>
> I think it would be a better user experience to invent a collective term
> for these kinds of API and have one landing page for that, which they (and
> future similar APIs) can live under.


This approach makes the most sense to me.
I would expect the following API surfaces to match that category:

   - The API surfaces in the canonical Screen Capture
   <https://www.w3.org/TR/screen-capture/> spec.
   - API surfaces from specs that extend CaptureController
   <https://www.w3.org/TR/screen-capture/#capturecontroller> (example-1
   <https://screen-share.github.io/captured-mouse-events/>, example-2
   <https://w3c.github.io/mediacapture-surface-control/>).
   - API surfaces that extend anything either accepted by getDisplayMedia()
   or returned by it. Region Capture
   <https://w3c.github.io/mediacapture-region/> and Element Capture
   <https://screen-share.github.io/element-capture/> extend the returned
   MediaStreamTrack, as does Capture Handle
   <https://w3c.github.io/mediacapture-handle/identity/index.html>.
   - API surfaces that seek to provide a gentle spin on getDisplayMedia,
   such as getViewportMedia <https://w3c.github.io/mediacapture-viewport/>.

IMHO, there are enough specs and API surfaces to merit this approach. Wdyt?

On Fri, Nov 22, 2024 at 2:48 PM Chris Mills <chris@millsdocs.com> wrote:

> Hi Screen Capture CG!
>
> I’m Chris Mills, formerly of Opera and Mozilla; these days I run a
> technical writing consultancy, mainly documenting web technologies on MDN
> for Google and Mozilla.
>
> One of my latest tasks for Google is documenting the Region and Element
> Capture APIs, and I’m thinking about how best to structure the reference
> docs. It makes sense for them to live next to the existing Screen Capture
> API docs. The trouble with MDN is that we tend to split API ref docs up by
> API spec, rather than by functionality. Putting Region and Element Capture inside
> Screen Capture wouldn’t work on MDN; the natural way to do it would be a
> separate docs tree for each API.
>
> However, I don’t really want to do that, as both of them use nearly the
> same API surfaces, they are very closely related, and each tree would be
> tiny. I think it would be a better user experience to invent a collective
> term for these kinds of API and have one landing page for that, which they
> (and future similar APIs) can live under.
>
> François and I have been discussing “Screen Capture extensions” as a
> collective term that they could live under. I think its suitability depends
> on what future APIs you have got in the pipeline, and how many. We also
> don’t want this collective docs tree to end up as a dumping ground for
> loads of stuff.
>
> What do you folks think?
>
> Best regards,
>
> Chris Mills
> Director and Lead Technical Writer
> Mills Docs Limited <https://millsdocs.com/>
> chris@millsdocs.com
> LinkedIn <https://www.linkedin.com/in/chris-mills-4471711/> / Twitter
> <https://twitter.com/chrisdavidmills>
>
>