Jeremie Patonnier :Jeremie Reporter
	Description • 10 years ago

On of the feature we wish to build on top of our compatibility data is the ability to let a user choose a given browser and version and then highlight all the relevant content or fade out all the irrelevant content.

Such feature have two main UX issues:
* How to let the user choose which browser he want to highlight?
* How relevant or irrelevant content is displayed?

	Will Bamberg [:wbamberg]
	Comment 2 • 10 years ago

We could look at how other documentation platforms expose something like this to users.

For instance, in the Django documentation each page has a little widgety thing that enables you to switch the version of the product you're interested in, and it then shows you the version of the docs for that version of the product.

If the version you've switched to is obsolete it tells you that with a warning at the top.

The version you're on follows you around, so if you follow a link from a page at version 1.3, the target it also the 1.3 version.

See http://imgur.com/vppDd0S.

	Andrew Overholt [:overholt]
	Comment 3 • 10 years ago

2 other ways (besides browsers/versions) to slice feature availability is by what's in Web Workers and FxOS privilege levels.

	Eric Shepherd [:sheppy]
	Comment 4 • 10 years ago

(In reply to Andrew Overholt [:overholt] from comment #3)
> 2 other ways (besides browsers/versions) to slice feature availability is by
> what's in Web Workers and FxOS privilege levels.

Good idea. Jeremie, is that feasible/realistic with the plan as it is?

	Jeremie Patonnier :Jeremie Reporter
	Comment 5 • 10 years ago

(In reply to Eric Shepherd [:sheppy] from comment #4)
> Jeremie, is that feasible/realistic with the plan as it is?

I don't see any trouble to add this in the current plan. The data schema is not yet set in stone and even in it's current state I don't see any blockers to have something like that.The only question is: Do we need to add an extra information to the data schema or can we simply relay on "features set" to do such things.

The technical question will be raised on bug 996570

In this bug we will discuss how to display such information, assuming it's possible (and it will ;)

	Luke Crouch [:groovecoder]
	Comment 6 • 10 years ago

How many different "agent contexts" are there? i.e., will Chrome implement the same limited feature-set for web workers as Firefox does?

I'm wondering if we should create another data model entity - "Contexts" - along with Browsers and Versions. So we would have:

Browser: Firefox|Chrome
Version: 31|37.0.2062.3
Context: DOM|WebWorkers

	Jeremie Patonnier :Jeremie Reporter
	Comment 7 • 10 years ago

(In reply to Luke Crouch [:groovecoder] from comment #6)
> How many different "agent contexts" are there? i.e., will Chrome implement
> the same limited feature-set for web workers as Firefox does?
No, the agent context is highly browser dependent. If WebWorker is a known standard context it not the case for the various privilege available in Firefox OS (there is currently no agreement on the privilege model yet) or the extension world (for example FF add-ons vs Chrome Apps).

For what I saw, we could anticipate at minimum the following context:
WebWorkers
WebWorkers (Service Workers)
Web Content
Web Content (Installed)
Web Content (privileged)
Web Content (Certified)
Chrome Content
Chrome Content (Add-ons)

All those context are not exclusive, it's orthogonal to the browser support.

> I'm wondering if we should create another data model entity - "Contexts" -
> along with Browsers and Versions. So we would have:
> 
> Browser: Firefox|Chrome
> Version: 31|37.0.2062.3
> Context: DOM|WebWorkers
I don't know. I tend to think that using "features set" to build such context could be good enough. However, a deeper exploration of the use cases could help us defining what is the best technical option here. What difficulties could we face if the data model does not record that context?
If we add that context, it adds a level of difficulty to maintain the data which does not make me really enthusiastic.

	Luke Crouch [:groovecoder]
	Comment 8 • 10 years ago

If we don't have a "Context" entity, we could either:

* Put context info in implementation notes fields
* Put context info into tags

	Jeremie Patonnier :Jeremie Reporter
	Comment 9 • 10 years ago

Question is: Do we need to perform some kind of DB request based on that context that could require some optimisation? Currently I can only imagine using it to filter the data but I don't know if we need to do more.

	John Whitlock [:jwhitlock]
	Comment 10 • 7 years ago

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