Re: [w3ctag/design-reviews] Delegated Ink Trail (#473)

Resurrecting a bit of an old issue at this point, so please let me know if this should be in a new issue. Thought I would start here for the context though.

I'm working on a draft version of the spec to launch this feature in Chromium soon, and one topic that has come up again is the string `type` param on requestPresenter. Given that it is only there for future extensibility, it is essentially a no-op parameter right now. Therefore, there has been some talk of potentially dropping both parameters in its current form and using a dictionary as the only param instead, which would only optionally contain a `presentationArea`. That way we could freely expand it to include a `type` in the future.

An updated IDL for this would then be something along the lines of:

 ```
dictionary PresenterParam {
    Element presentationArea;
  }

  Promise<InkPresenter> requestPresenter(optional PresenterParam param = {});
```

The concern that I have is that it seems like it could be a confusing or unexpected experience for developers in the future when the `type` param is added. Then they could get the delegated ink experience via either specifying `type: delegated-ink-trail` or leaving `type` out completely. This isn't a blocker, of course, but two different ways of achieving the same result seems like something we'd prefer to avoid.

Does TAG have any preferred pattern to follow in situations like this, or a stronger opinion on the `type` param?

Here's the link to the issue on the draft spec, for a bit more discussion: https://github.com/WICG/ink-enhancement/issues/20

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/473#issuecomment-876612377