Inconsistant naming of members

[marcoscaceres]

Why are some properties with underscore and some not?
relNotes vs required_features?

[AMorgaut]

JS APIs usually prefer camelCase syntax.
Few JS Conventions Examples:

• http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Method_and_property_definitions#Method_and_property_definitions
• http://docs.typo3.org/flow/TYPO3FlowDocumentation/TheDefinitiveGuide/PartV/CodingGuideLines/JavaScript.html
• http://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript
• https://github.com/airbnb/javascript#naming-conventions

W3C APIs only use underscore for constants.

JSON documents may vary as they can be provided by different languages with different conventions.
This manifest file looks very much to me as the CommonJS/Node.JS Package format.
The Node.JS one have some "multi-word" property names for which the camelCase notation has been choosen:

• https://npmjs.org/doc/json.html#devDependencies

As this manifest file target web apps written in JavaScript, camelCase looks more natural.

[marcoscaceres]

Thanks for doing this research. Very helpful!

[mounirlamouri]

I think it would be great to have a note about that in the specification.

[marcoscaceres]

@mounirlamouri I can add that, but is it ok to fix the manifest to use camelCase?

[hollobit]

@AMorgaut 👍 Good comment

[mounirlamouri]

I'm fine with changing the manifest. However, you have to keep in mind that you might need to revert that later because Google [1] and Mozilla [2] both use underscores in their manifest format.

[1] http://developer.chrome.com/extensions/manifest.html
[2] the spec is based on that one...

[marcoscaceres]

@mounirlamouri true that. I think at this point, we should just fix the relNotes -> rel_notes.

[marcoscaceres]

So, I'm going to ignore Google compat because we are currently fairly incompatible with them anyway. I'm still not sure what's worst/best here:

1. follow mozilla blindly (keep realNotes and other quirky things).
2. break compat with Mozilla (change all "foo_bars" to "fooBar").
3. break compat with Mozilla only a little (change just "relNotes" to "rel_notes")

Thoughts?

[mounirlamouri]

If the specification changes everything from "foo_bar" to "fooBar", I can do my best to have Mozilla implementing those changes and updating the documentations. However, we might end up with compat issues. If we do it early enough, those compat' issues might be small enough. I do not know if it is worth trying though.

[marcoscaceres]

The only solution I see is that Moz continues to support its own + the new W3C ones (and eventually mark the Moz one as deprecated in the docs). If the W3C changes the behavior of an existing Moz field, then the W3C should rename that field so not to cause compat issues for Moz.

[mounirlamouri]

As I said, I will push our App team to update the manifest handling as soon as possible if you update the document and the mailing list agrees with the naming convention. From there, we will see how to make sure the spec is compatible with the Web.

[marcoscaceres]

Can someone please review: #36 and give it an OK (or not) to merge.

[mounirlamouri]

Just FTR, every time I see properties using the "foo_bar" format, my eyes bleed ;)

[AMorgaut]

I agree with Mounir the "underscore" notation irritates me each time I see it
I raised another issue mentioning it: #50