JS-based feature detection we can use server-side

[nacin]

In #20923 we added initial support for browser-based uploads in iOS 6, by detecting the user agent. This is a good stopgap, but we can do better.

We should implement a simple API that allows for us to do JS-based detection for mobile devices. We can use this for touch support, general upload ability, drag-drop upload ability, customizer support, and anything else that we can best detect in JS but that we need in order to make decisions in PHP.

We could probably model parts of it on how the user settings API works — leveraging cookies, but without the DB backend. A function could then return a value from the cookie if set, and otherwise, it'd use the default value passed to it.

[tomauger]

Would love to understand more about why JS-based detection is preferable to UA detection. I do appreciate that capabilities detection plays a huge role in JS, but if you're looking at the complete landscape, that includes CSS, JavaScript AND potentially switching up program logic (ie: PHP), you want to have as much info as possible. If you want to do good progressive enhancement, you'll need the UA info as much as the JS capabilities info. Would love to hear more about your thinking on this.

[markjaquith]

tomauger — Well, UA detection means that we have to wait for a new release to add support for new UAs. With feature detection, we can automatically support new UAs just as soon as they add support for the feature we want to detect. Plus, we spend less time massaging UA regexes.

[tomauger]

@markjaquith - totally get that, but in #20923 I provided a totally robust solution, but never heard any comments back on it: ​http://core.trac.wordpress.org/ticket/20923#comment:18

File: ​http://core.trac.wordpress.org/attachment/ticket/20923/WP_Browser_Detection.7z

I'm all for feature detection, when it's about JavaScript compatibility etc. But when certain UAs are known to, for example, render CSS differently, or have different implementations of CSS3 standards etc, UA detection might be the only solution.

In the example that I posted, all the maintenance issues you mention are addressed. The regexes and UA detection is dealt with, and gets regular (ie: daily) independent updates.

Take a look. Could be another angle on this issue. I'd definitely be happy to move this forward if it appears viable. I mean it's basically ready to go now, just needs to be either pluginized or patched.

[helenyhou]

No traction for 3.5, and we're in betas now.

[nacin]

Two reasons for no traction:

• There isn't not a pressing need for this

• No one worked on it (besides tomauger's proposed UA detection)

[chriscct7]

Based on comment:5 3 years later, closing as wontfix