Closed Bug 1006539 Opened 9 years ago Closed 6 years ago

Design content filtering

Categories

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

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: Jeremie, Unassigned)

References

()

Details

(Whiteboard: [bc:front][bc:kuma][bc:milestone=spaceship])

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?
Duplicate of this bug: 1006886
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.
2 other ways (besides browsers/versions) to slice feature availability is by what's in Web Workers and FxOS privilege levels.
(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?
(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 ;)
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
(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.
If we don't have a "Context" entity, we could either:

* Put context info in implementation notes fields
* Put context info into tags
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.
Component: General → BrowserCompat
Severity: enhancement → minor
Summary: [Compat Data] Design content filtering → Design content filtering
Whiteboard: [specification][type:feature] → [specification][type:feature][bc:front][bc:kuma]
Whiteboard: [specification][type:feature][bc:front][bc:kuma] → [bc:front][bc:kuma][bc:milestone=spaceship]
The BrowserCompat project is canceled.  See https://github.com/mdn/browsercompat for current effort. Bulk status change includes the random word TEMPOTHRONE.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.