It is unclear what 'type' argument for requestPresenter method is used for.
Closed this issue · 7 comments
'type' seems to be non-optional argument, yet it isn't used at all in the spec.
Its described a bit better here in the explainer than in the spec, so we can definitely expand on it more there. The idea is that the user can specify the type of presenter that they want with the DOMString type param. While not particularly important now (given that there is only one presenter type), the idea is that it allows requestPresenter to be extensible for other types of presenters in the future.
If no type or an invalid type is specified, an error is thrown.
That feels odd. DOM APIs don't in general have such extra parameters just-in-case.
In fact we've tried to get rid of such APIs (there used to be such around 10-15 years ago)
We do have ideas of how this API will be extended - one such example would be a future ink presenter that enables authors to render a trail with shaders for more complex ink strokes.
Its possible that we're overthinking it or going about the extensibility the wrong way though if you think it should be kept simpler until we have firm proposals for extending it.
This is not the way web APIs are designed usually. There should be no useless parameters.
If you want easier way to extend the API later, you may want to consider to use a dictionary as the parameter type.
Something like
dictionary PresenterParam {
Element presentationArea;
}
Promise<InkPresenter> requestPresenter(optional PresenterParams param = {});
Its a little unclear to me how that is nicely extended in the future. We couldn't make a type entry in the dictionary required, since that would break current usage that doesn't include the entry. I guess we would just make no type entry default to today's experience, and type: shader-ink-trail (or whatever) would get the new experience? It feels a little strange to me to choose between two different experiences by specifying something or nothing at all.
Another option would be to make no type entry and type: delegated-ink-trail both get today's experience. It also seems a little unexpected to have two different ways of getting the same experience, but maybe that isn't unusual?
Are there other APIs that do something like this? I'm admittedly not very experienced with creating new Web APIs, if this is a common pattern then I can definitely fall in line with the norm.
If "type" doesn't really mean anything today, it shouldn't be there at all. And yes, if in the future it could start to mean something, one could have DOMString type = "delegated-ink-trail" (or whatever the default value should be). Then passing no type and "delegated-ink-trail" would be the same thing.