- From: Domenic Denicola via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Sep 2018 16:10:06 +0000
- To: public-web-nfc@w3.org
You shouldn't modify a foundational method like that of the platform for NFC-specific use cases. So the "Other option" from https://github.com/w3c/web-nfc/issues/152#issuecomment-425045567 makes more sense to me. (Although I'm unsure why you'd need to do `{ capture: false }`, since it's not in a DOM tree anyway.)
Otherwise, I strongly agree that inventing your own event listener-like infrastructure is not good, and following the precedent set by other specs makes more sense. Especially if we already have such a strong parallel with Web Bluetooth.
> or if we want to bind it to the navigator.nfc object, we could have a factory method instead of constructor (like @kenchris suggested).
Constructor is preferable if possible! I wonder why Web Bluetooth went with something else. Does creating it have to be async? Your last IDL block has it as promise-returning, and it's not clear to me why.
--
GitHub Notification of comment by domenic
Please view or discuss this issue at https://github.com/w3c/web-nfc/issues/152#issuecomment-425486170 using your GitHub account
Received on Friday, 28 September 2018 16:10:07 UTC