946413 - Create a mechanism for feature compatibility detection

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: BrowserCompat, defect)

Description

[Daniel Buchner [:dbuc]]

What problems would this solve?
===============================
It will auto-populate the API compatibility tables present on MDN

Who would use this?
===================
Everyone who reads MDN docs would view it, writers and contributors would realize a huge efficiency boost and time savings.

What would users see?
=====================
Fully populated compatibility tables - no more "?" blanks!

What would users do? What would happen as a result?
===================================================
They would rejoice - velvet ropes would part, champagne would fall from the heavens.

Is there anything else we should know?
======================================
Naw, just build that shizzle!

Comment 1

[Luke Crouch [:groovecoder]]

Paul Irish and I discussed this a while back complete with an etherpad that I completely lost. :/

I agree with Janet - this bug should be about Mozilla getting involved with http://testthewebforward.org/.

Comment 2

[Daniel Buchner [:dbuc]]

(In reply to Luke Crouch [:groovecoder] from comment #1)
> Paul Irish and I discussed this a while back complete with an etherpad that
> I completely lost. :/
> 
> I agree with Janet - this bug should be about Mozilla getting involved with
> http://testthewebforward.org/.

So testthewebforward is a great, standardized feature detection harness, but where's the part about collecting the data into a usable form that is meant for displaying in docs UI to advance compatibility awareness? Surely we still need to run the tests and record the results across browsers, then enhance MDN to display that data, right?

My point is: testthewebforward is a rudimentary, stateless testing tool, but we still need to use that  tool to create the compatibility recording/display mechanism on MDN, which is what this bug is about - know what I mean?

Comment 3

[John Karahalis [:openjck]]

(In reply to Luke Crouch [:groovecoder] from comment #1)
> Paul Irish and I discussed this a while back complete with an etherpad that
> I completely lost. :/

Shame. Maybe we could open an IT bug to track it down given the date of creation or some textual content.

Comment 4

[Luke Crouch [:groovecoder]]

(In reply to Daniel Buchner [:dbuc] from comment #2)
Got it. browserscope.org does exactly that (when the server's up[1]), so I suggest we add the w3c/web-platforms-tests into browserscope.org.

Do we know anyone involved with browserscope.org who can tell us it's history and plans for the future? Maybe we should fold it in as an MDN service?

[1] http://www.downforeveryoneorjustme.com/browserscope.org

Comment 5

[Daniel Buchner [:dbuc]]

(In reply to Luke Crouch [:groovecoder] from comment #4)
> (In reply to Daniel Buchner [:dbuc] from comment #2)
> Got it. browserscope.org does exactly that (when the server's up[1]), so I
> suggest we add the w3c/web-platforms-tests into browserscope.org.
> 
> Do we know anyone involved with browserscope.org who can tell us it's
> history and plans for the future? Maybe we should fold it in as an MDN
> service?
> 
> [1] http://www.downforeveryoneorjustme.com/browserscope.org

I'll talk to Mathias about use of browserscope (or running a reliable instance). We should be able to (rather) cleanly utilize the TTWF tests in browserscope. I'll ping back here when I have more info on browserscope options.

Comment 6

[Daniel Buchner [:dbuc]]

(In reply to Luke Crouch [:groovecoder] from comment #4)
> (In reply to Daniel Buchner [:dbuc] from comment #2)
> Got it. browserscope.org does exactly that (when the server's up[1]), so I
> suggest we add the w3c/web-platforms-tests into browserscope.org.
> 
> Do we know anyone involved with browserscope.org who can tell us it's
> history and plans for the future? Maybe we should fold it in as an MDN
> service?
> 
> [1] http://www.downforeveryoneorjustme.com/browserscope.org

After talking with Mathias, he sent me these links:

This is how we utilize browserscope to collect feature detection data: http://browserscope2.org/user/tests/howto

Here's how he's used it to detect support for various API features: http://mathiasbynens.be/demo/xhr-responsetype

Basically, we need to hand browserscope a test that outputs a 0 (unsupported) or 1 (supported), then we can pull that data in using their API. After that, it would take some backend code to link it to the appropriate feature tables and cache output for display.

Comment 7

[Luke Crouch [:groovecoder]]

Okay, so the way I see this playing out on MDN:

1. Add a code sample in the "Browser compatibility" section of a web api interface article:

"Improve this table" button executes the browserscope test code in the sample and beacons the results back to browserscope

2. Change the https://developer.mozilla.org/en-US/docs/Template:CompatibilityTable code to get the CSV results for the interface test from browserscope and render an appropriate table

Now that bug 765642 has landed, this is all possible to try in the wiki content, right :sheppy?

Comment 8

[Eric Shepherd [:sheppy]]

Yes, this is theoretically possible. I think we can do something along these lines, although making the user experience right will take some time.

Adding Florian to cc list because this might be a project he'd find interesting to experiment with at some point.

Comment 9

[Hallvord R. M. Steen [:hallvors]]

I'd love to see "live" info on every page: "The browser you're *currently* using supports .." / "doesn't support ..." with that data being generated on the fly by JavaScript feature detection. Then, if it's a not-previously-seen browser/version, we could have a small "share this result.." button?

Comment 10

[Chris Mills [:cmills]]

Could we even do this automatically? User visits guide/reference page, MDN automatically runs a test to see whether your browser supports that feature, lets you know, then collects that data so it can be displayed on the page in future. This might be a lot of overhead, but it would be really helpful data to collect, for our efforts, W3C/webplatform, etc.

But it does have performance and privacy concerns.

Comment 11

[Luke Crouch [:groovecoder]]

:cmills - right, I proposed a "Improve this table" button so the user decides if they want to give us data about their device.

Comment 12

[Stephanie Hobson [:shobson]]

See also Bug #1006030

Comment 13

[Sara Luizet]

(In reply to Daniel Buchner [:dbuc] from comment #5)
> (In reply to Luke Crouch [:groovecoder] from comment #4)
> > (In reply to Daniel Buchner [:dbuc] from comment #2)
> > Got it. browserscope.org does exactly that (when the server's up[1]), so I
> > suggest we add the w3c/web-platforms-tests into browserscope.org.
> > 
> > Do we know anyone involved with browserscope.org who can tell us it's
> > history and plans for the future? Maybe we should fold it in as an MDN
> > service?
> > 
> > [1] http://www.downforeveryoneorjustme.com/browserscope.org
> 
> I'll talk to Mathias about use of browserscope (or running a reliable
> instance). We should be able to (rather) cleanly utilize the TTWF tests in
> browserscope. I'll ping back here when I have more info on browserscope
> options.

Yes even on http://upornot.online/browserscope.org is not loading

Comment 15

[John Whitlock [:jwhitlock]]

The BrowserCompat project is canceled.  See https://github.com/mdn/browsercompat for current effort. Bulk status change includes the random word TEMPOTHRONE.