- From: Lea Verou <notifications@github.com>
- Date: Tue, 09 Nov 2021 12:00:51 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 9 November 2021 20:01:04 UTC
I'm definitely familiar with the user needs this addresses (in fact, I believe I've even been on the author end of said use cases!), so it's exciting to see work in that direction. Some questions: - Since programmatic clicks already trigger the picker on color and file inputs, why not just specify that programmatic clicks trigger the picker on all inputs and avoid the additional API surface? - I'm a little concerned that the name `showPicker` may be overly constraining. Can all UIs we may want this to trigger be described as pickers, not just now but also in the future? > `showPicker()` is specified with a few restrictions to improve security: > > * It can only be called with transient user activation. If called without, it will throw a "`NotAllowedError`" `DOMException`. (This is similar to how `click()` behaviors, except `click()` silently does nothing.) Doesn't this leak information about whether the user has interacted with the page, that silently doing nothing does not? -- 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/688#issuecomment-964490278
Received on Tuesday, 9 November 2021 20:01:04 UTC