Make WordPress Core

Opened 12 years ago

Closed 9 years ago

#21083 closed enhancement (wontfix)

JS-based feature detection we can use server-side

Reported by: nacin's profile nacin Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Upload Keywords:
Focuses: Cc:


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.

Change History (6)

#1 @tomauger
12 years ago

  • Cc tomaugerdotcom@… added

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.

#2 @markjaquith
12 years ago

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.

#3 @tomauger
12 years ago

@markjaquith - totally get that, but in #20923 I provided a totally robust solution, but never heard any comments back on it:


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.

#4 @helenyhou
11 years ago

  • Milestone changed from 3.5 to Future Release

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

#5 @nacin
11 years ago

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)

#6 @chriscct7
9 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.