When viewing a page full of features, include a filter for entering text and/or a regexp to show only matching features.

From #12:

The graph values don't quite add up when there are more complex browser support objects, e.g. it handles { version_added: true } but I'm not 100% sure it handles { version_added: true, prefix: '-webkit'} and it definitely doesn't handle support objects that are arrays of these hashes.

I'm pretty sure it handles the second case properly now (not the third though), but it'd be useful to make sure it stays true as development of the Rails app continues.

Rather than using data from data-test.json, which could cause failures any time the data is modified, I think it'd be a good idea to create the Feature objects when running the test suite using something like factory_bot.

I was initially hesitant to do this because I wouldn't be able to make sure the JSON that gets passed by seeds.rb matches the JSON used in the tests, but I think that the benefits outweigh the potential problems. Hopefully I can come up with some way to make sure the data actually in the database and the data in the tests match up.

tl;dr use fixtures/factories to generate Features and write simpler, more resilient tests.

Dependabot encountered the following error when parsing your .dependabot/config.yml:

The property '#/update_configs/0/allowed_updates/0/match/kind' value "all" did not match one of the following values: security

Please update the config file to conform with Dependabot's specification.

You can mention @dependabot in the comments below to contact the Dependabot team.

This is kind of a hack because there's not really a good way to link to the source file from the webapp.

It'd be nice to be able to easily find the feature in the GitHub repo, e.g. have a link in the api.ANGLE_instanced_arrays feature card that directs the user to https://github.com/mdn/browser-compat-data/search?q=ANGLE_instanced_arrays.

Add pages for each individual feature, e.g. /features/css-font-size.

Subfeatures were introduced in #66, unfortunately the code was written such that the subfeatures didn't require a dot immediately after the feature name.

This leads to problems like api.AnimationEffect being displayed as a subfeature of api.Animation, which it is not.

This could be on a separate About page or just on the home page (we're not doing much with the home page right now anyway).

When filtering by version info, it would be helpful to be able to search for features that are "supported or support unknown" or "unsupported or support unknown".

https://github.com/connorshea/mdn-compat-data-explorer#user-content-deployment refers to https://mdn-compat-data-explorer.herokuapp.com/

Application error

An error occurred in the application and your page could not be served. …

Currently the Graphs page has donut charts with browser support info, it'd be nice to have more graphs.

Ideas:

• Stacked bar chart of releases vs. releases with release notes for each browser
• % of tracked features that are standard, % that are experimental, % that are deprecated

https://travis-ci.org/connorshea/mdn-compat-data-explorer/builds/471442248

Rather than having URLs like /browsers/1, the browser pages should be like /browsers/chrome. The ids aren't deterministic when you generate the DB, so the URLs could differ when deploying a new version.

Dependabot encountered the following error when parsing your .dependabot/config.yml:

The property '#/update_configs/0/automerged_updates/1' of type object did not match one or more of the required schemas```

Please update the config file to conform with Dependabot's specification.

You can mention @dependabot in the comments below to contact the Dependabot team.

Show the hierarchy of features, so you'd see the Array object and then click a widget to show all the stuff underneath Array, like Array.forEach, etc. Would be more browsable and easier to wade through.

Currently in the features_helper.rb file we just send "Yes", "No", "?", or forward the version number, and if there's more than one version hash (e.g. it was prefixed initially and eventually was added without the prefix, or the same thing but with a feature flag) it will only take data from the first hash and ignore everything else.

Similarly, it doesn't care about notes or any of the other possible attributes, it only cares about the version_added attribute.

When returning the HTML, perhaps we should include attributes like data-flags, data-notes, etc. The problem with this is how we should handle a situation where there are multiple hashes, maybe numbering the data attributes depending on the hash's location in the array.

Maybe a better, more "universal" solution would be to just pass the JSON directly as a data attribute and then have some JavaScript parse it on the client-side and modify the table cells from there.

In the KumaScript repo there's a directory of JSON fixtures, e.g. support_variations.json which will probably be useful for filling out the fixtures in this repo.

There's also a fixture with a support array rather than a hash, this'd be useful to add:

https://github.com/mdn/kumascript/blob/3c264ed0bbf2c3da2b4940fad02b669bd1820f58/tests/macros/fixtures/compat/notes.json

Right now there's no organization for the browser columns in compatibility tables:

This should work more like MDN's compatibility tables, where the table head has two levels:

Currently you end up always seeing the same features.

We really want most features to have MDN links, so having a way to quickly find the ones where they're missing here would be handy.

I've been spelling it as "Compatability" throughout the codebase 🤦‍♂️

System tests need to be written to make sure the various search filters work properly:

• Selecting multiple categories, e.g. HTML and CSS.
• Filtering based on presence of description and mdn_url.
• Filtering based on status: experimental, deprecated, and standard_track.

All features with a name matching api.ANGLE_instanced_arrays.* would be a subfeature of api.ANGLE_instanced_arrays, so it should be possible to list all subfeatures for each feature. It may be a better idea to determine this information when seeding, but I'm not entirely sure how to go about doing that.

It'd also require some way to link to a given feature. I'd rather not have a page for every feature, but I guess that wouldn't be the worst thing?

Currently the table renders "Yes" even though the feature was removed from Chrome in v24. This is misleading.

The JSON looks like this:

{
  "version_added": true,
  "version_removed": "24"
}

Browser releases could be updated to list all features added in a given release. It'd probably be a good idea to either load this data on-the-fly with JavaScript or to make a separate page for each browser, so as not to put too much strain on the DB when loading the Browsers page.

Dependabot encountered the following error when parsing your .dependabot/config.yml:

The property '#/update_configs/0/automerged_updates/1' of type object did not match one or more of the required schemas

Please update the config file to conform with Dependabot's specification.

You can mention @dependabot in the comments below to contact the Dependabot team.

The data is static so this should be fairly easy (famous last words).

Add a helper to include a page-specific title to the head of every page.

I already have psuedo-changelogs in the Releases view, but that's only for GitHub. A CHANGELOG.md would be better.