Skip to content
This repository has been archived by the owner on Jun 21, 2022. It is now read-only.

Compat table macros should order subfeatures #193

Closed
wbamberg opened this issue Jun 6, 2017 · 3 comments
Closed

Compat table macros should order subfeatures #193

wbamberg opened this issue Jun 6, 2017 · 3 comments
Labels

Comments

@wbamberg
Copy link

wbamberg commented Jun 6, 2017

The current aggregated compat tables order the features they contain:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest#Browser_compatibility

But subfeatures are not ordered:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions#Browser_compatibility

The reason for this was a vague idea that subfeatures follow some kind of progression, as browsers add support for the feature, from more basic to more advanced. For some features this is probably true, but for some it isn't. For the sake of consistency, it would probably be better to always order subfeatures.

@snoack
Copy link

snoack commented Jun 21, 2017

As I explained in mdn/browser-compat-data#265, I think a chronological order in which the features were implemented makes sense. FWIW, this also seems to be consistent with the old compatibility tables on MDN, used by the JavaScript and DOM documentation, like here for example.

However, for the "aggregated compat tables" I think it makes sense to have following order:

  1. Constants (uppercase)
  2. Types (capitalized camel-case)
  3. Functions (lowercase)

And within these categories we could sort again by implementation order.

But either way, I'm not sure whether this should be implemented here, or whether we should rather implement validation to make sure that the raw data use a consistent order in the first place.

@jpmedley
Copy link
Contributor

jpmedley commented Jun 21, 2017 via email

@Elchi3 Elchi3 added the bcd label Nov 2, 2017
@a2sheppy
Copy link
Contributor

In the compatibility tables, I could see value to both the chronological and the alphabetical sort of the lists of features. But we need to do something to ensure a predictable order, and we don't have a way to reliably sort on chronological order (especially since things arrive in different orders on different browsers). So alphabetical it is.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

6 participants