- From: =JeffH via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 01:01:40 +0000
- To: public-webauthn@w3.org
Here's an overall comment on "browser capability detection': I asked [Tab Atkins](https://github.com/tabatkins) (CSS spec editor) about this (back in April), and he said that the ``` if (foo.bar()) /* do something */ else /* not there, go figure */ ``` approach, colloquially known as "feature detection", often is the best one can do from JS within a user agent. There are feature detection JS libraries — e.g., modernizr, yepnope — but results with them can be mixed. Tab says that SVG tried specifying feature label strings (i suppose one asked the svg impl 'what is supported?' and got a list of strings in return), and that sorta worked for a very short time and then implementations would lie about what they supported, then the number of features outgrew the set of strings, etc. Tab asserts similar efforts occurred in various portions of the web platform with lousy results overall. In CSS, they have a `@support <css stuff to test here>` rule, which nominally works because CSS is a language, they have a parser, and the assumption is: if the @support rule can successfully parse the `<css stuff to test here>`, then it's supported. WebAuthn/FIDO2 is an especially tough problem because we have a browser->protocols->authnr stack and the answer to "is foo feature supported" question may involve component answers from several layers in the stack. -- GitHub Notification of comment by equalsJeffH Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1219#issuecomment-499309788 using your GitHub account
Received on Thursday, 6 June 2019 01:01:42 UTC