Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Consider allowing UAs to omit navigator.bluetooth on platforms that don't support it. #305

Open
jyasskin opened this issue Oct 6, 2016 · 3 comments

Comments

@jyasskin
Copy link
Member

jyasskin commented Oct 6, 2016

Some platforms don't support Bluetooth LE at all. Others support it conditionally depending on whether a radio is attached. getAvailability() covers the second group of platforms, and can be used to cover the first, but it might be simpler for developers to be able to treat no-Bluetooth platforms they same as they treat no-Bluetooth browsers.

w3c/web-share#8 and whatwg/notifications#81 propose this strategy for two other specs.

@slightlyoff @PaulKinlan @RByers

@RByers
Copy link

RByers commented Oct 7, 2016

Agreed that it's more predictable for developers if the API doesn't show up at all in the cases we know the feature is never available on the platform.

@beaufortfrancois
Copy link
Member

Just to be clear, Bluetooth may seem to be unavailable on the platform.
However it could work with cheap Bluetooth USB dongles such as https://www.amazon.com/Medialink-Bluetooth-Adapter-Energy-Technology/dp/B004LNXO28 .

@jyasskin
Copy link
Member Author

I'm thinking about removing navigator.bluetooth on platforms like Windows 7 or MacOX 10.9, where even if the user plugged in a cheap dongle, we still wouldn't be able to give them Web Bluetooth. On platforms that support Bluetooth but machines where they'd have to plug in a dongle, the site would need to use getAvailability().

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants