Lea: adding a showpicker method... only for inputs.. so people can programmatically trigger pickers. It's subject to user activation - addresses privacy concerns. This spec changes mandates that the current behaviour change - right now users open the file picker on synthetic clicks... this changes .. my main rservation is that it seems weird to have synthetic clicks only open some pickers.. also though I can see the future possibility some authors may want to make more complex UI... if in the future these needs arise then we can add a separate API call.. this proposed change makes things inconsistent and adds a seperate method... I'm gonna post this from my PoV...

Peter: modal?

Lea: some modal some not... file p

Peter: [ for a synthetic click ] show file picker would not fire event listeners

Lea: correct.

Peter: what does this API surface buy ... over calling the click method or dispatching a click event.

Lea: there's value in the predictability - of triggering it with a click event... have seen comments on StackOverflow asking about this.

Peter: for me the biggest problem with date pickers that they're inconsistently implemented...

Lea: this doesn't help with that.

Peter: it's hard to feature detect.

Lea: if you have a colour input ..... it's weird if you use showpicker and it shows the data list instead of the picker. It's more natural that a synthetic click just does what a click would have done, it's easier to have a mental model about this. [will comment]

Tess: cool idea.. definitely some questions, need to read it to see if they're answered. What happens if you call showPicker on input type text?

Rossen: you might get suggestions...

Peter: input type password might activate your password managers. The hardest thing historically with datetime inptus was detecting whether the browser supports it properly

Tess: at least it's easy to feature detect if showPicker is there. Does it do something useful...

Peter: I can see browsers implementing it for certain types of inputs but not with a good widget

Ken: depends on platform as well, what is applicable

Tess: show if picker is applicable... reading spec text ... has a fallback... any relevent user interface.. if no UI applies, does nothing.

Peter: my concern is I need to know whether it showed something or not. Maybe I have my own UI, but want to defer to the browser if the browser has one. Fair to give me a result that says I can't do this vs user hit escape

Ken: you don't want to show a button if it doesn't do anything

Tess: I don't think there's a way to detect that

Peter: feels problematic

Rossen: behaviour discoverability is important. If you're going to trigger a UI, successful or not, you need to know what actions to take, whether before you call the API or as a result of it. This is missing.

Peter: will leave comment

Rossen: alternatively they can start by restricting this to file picker. They will throw an exception if it's not supported.

Peter: isn't there a situation where it may silently do nothing?

Tess: that's correct

Rossen: if the elements relevant global object does not have transient activation it will throw a not allowed error... but to the point of input type text.. can be used to suggest stuff to the user

Peter: I can't see picker cases for text.. there are other flavours of text input. I'll leave a comment.

Rossen: otherwise direction and general intent is good. This is needed. a step in the right direction.

Concers about feature detection don't seem to be answered, propose closing with concerns at plenary to give Lea/Tess a change to have input.

Peter: my real concern is that it's not detectable... I think this needs to be detectable.

Dan: that's the guidance in the design guidelines.

Peter: yes...

Rossen: there was one suggestion from Francois but didn't go anywhere...

Rossen: The only thing remaining before we can close this is detectability. Everyone agrees the feature is needed and good.

Peter: Domenic's last comment "wait and gather more data"... implement now and wait and see and get data? would like to see a plan for how that data is gathered and loop back. Or we have consensus that it really needs to be detectable to cover all use cases, then just do it, and we can say that.

Rossen: this is only for pickers that are browser native? or any picker? some browsers invoke a platform native picker... font picker, etc... is intent for showpicker to work with those cases as well?

discussion on types of pickers

Tess: missed that distinction but now I get it.. UI provided by browser which may be OS or browser UI, vs picker supplied by a custom component.

Rossen: already talking about component vs browser

Peter: that's what I've been talking about. I want date input, if browser has a decent one I'll use it, if not I want to fall back to mine, which may have issues but is better than them typing text

Tess: you want to know is the one you have crap so I can use my own

Peter: or do you even have one. Whether it's OS or browser, in theory should be detectable. Is there another factor?

Rossen: if showpicker .. if the only way to detect it right now is to call showpicker and look at promise result you're potentially going to invoke something unexpected .. it's very clunky.

Peter: totally fine with a hasPicker method. Also okay with showpicker throwing new methods.. not going to complain if a picker shows up

Rossen: maybe I like the colour picker in firefox native browser UI but I prefer to see the native fontpicker from Windows.. if they tell me they have their own font picker I want to show my library font picker because I don't have a way to invoke the OS native picker which I like.. it's three choices I'm trying to make.. I can detect between the first two (browser or OS native UI) and the third. But you're not allowing me to make the further distinction down the path. Which I'm pretty sure is important for some platforms and some browsers

Peter: similar case historically.. on one OS the date picker is really nice and on the same browser but a different OS the browser has one but it's shit. The only way to detect that is UA string... browser is going to just say yeah I've got a date picker. No feedback of if it's a good one or not. Not sure it's fair to ask for how good is your picker.

Rossen: detectibility further fine grained is needed..

Peter: has picker gives back an enum, native, OS, none.. Leave that feedback?

Rossen: [leaves feedback]

Peter: do we have consensus that we really want detectability?

Rossen: I don't see the reason why this is not needed. If you don't care about detectability just call showPicker and deal with what is there

Peter: Dominic's feedback is he thinks if showpicker throws an exception that will break code. Makes the argument we should implement it and get data. My argument is if you implement it without throwing an exception you're going to have a whole lot of code out there that will never expect an exception and we can never change it

Tess: self-fulfilling prophecy...

Peter: we can always make it not throw later without breaking any code

Rossen: on top of it you're not allowing... nicer ... [behaviour]

Peter: if we have consensus that it should throw if you don't have one we should leave that feedback

Rossen: yep [leaves comment]

Peter: needs to be feature detectable

Dan: close based on feedback from Dominic? Satisfied with concerns? Or unsatisfied?

Peter: somewhere in between.. I want the feature but I think this is a huge mistake and really needs to be detectable in a way that will be backward compatible. The path Dominic is going down we cannot add detectability in a reasonable way. Unsatisfied.

Lea: agree with Peter

Dan: to plenary..

Rossen: closing as unsatisfied.

closed