3 ms·

It's unreasonable if you feature detect on every load. why not store feature detected capabilities within a cookie that's passed on additional requests?

• mattnewton 7y ago
  If you think about it, that’s kinda what is happening, except instead of a punishing first load that appears broken and slow every time the user loses the cookie or we change our feature detection code, we do that ahead of time and the “cookie” is in a map where the key is the UA
  • spaceribs 7y ago
    Interesting, so to be clear, the sequence looks like this: 1. User goes to website, UA communicates previously known features for this browser. 2. Browser does feature detection after load 3. Browser communicates any new browser features up to a backend service, crowd analysis determines if new features have been implemented for this UA. If that's the case, that's a pretty awesome way of keying features, but I'd have to think about the implications in practice.
    • mattnewton 7y ago
      No, I haven’t seen anything that fancy. The “user” in step 1 is internal QA testing the site on the browser, maybe after seeing it a lot in logs. Exposing users to novel UA strings to a bunch of feature detection JavaScript is an interesting idea but it’s probably better to log them and then do this in a QA setting.
    • finchisko 7y ago
      like this proposal