Compat table macros should order subfeatures

[wbamberg]

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]

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]

Speaking as someone who's created many pages over the last three years, I don't know that many with constants and types. If you're going to order along those lines, seems like it should be page order: constructor, properties, events, methods. Joe Medley | Technical Writer, Chrome DevRel | jmedley@google.com | 816-678-7195 *If an API's not documented it doesn't exist.*

…

On Wed, Jun 21, 2017 at 7:56 AM, Sebastian Noack ***@***.***> wrote: As I explained in mdn/browser-compat-data#265 <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 in the JavaScript and DOM documentation, like here <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#Browser_compatibility> 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#193 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0vi1AG01oj0UFrmNd7jOnj2h0pCyyaks5sGS8igaJpZM4Nxx3I> .

[a2sheppy]

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.