- Search for existing issues. Please check to see if someone else has reported the same issue.
- Share as much information as possible. Include operating system and version, browser and version. Also, include steps to reproduce the bug. This is a good boilerplate to use.
Refer to the documentation.
JS files must pass JSCS and JSHint using the provided .jshintrc and .jscsrc rules.
Run gulp lint before pushing a commit. It will validate that your JS passes our formatting rules.
lowerCamelCaseGeneral variablesUpperCamelCaseConstructor functions- Use semantic and descriptive variables names (e.g.
colorsnotclrsorc). Avoid abbreviations except in cases of industry wide usage (e.g.AJAXandJSON).
- 4 space indentation
- Class names use hypenated case (e.g.
my-class-name)
- 4 space indentation
- Always a space after a property's colon (e.g.
display: block;notdisplay:block;) - End all lines with a semi-colon
- For multiple, comma-separated selectors, place each selector on it's own line
Note: There is an .editorconfig that will help you maintain settings consistent with our guidelines. Most editors support this format. See editorconfig.org. There's also a wma.sublime-project that can be opened in Sublime Text.
If possible, test your patch on a Firefox OS and Android device (4.2 is our baseline for support). If you don't have access to these devices, please test in Firefox and Chrome.
- Try not to pollute your pull request with unintended changes – keep them simple and small. If possible, squash your commits.
- Try to share which browsers and devices your code has been tested in before submitting a pull request.
- If your PR resolves an issue, include closes #ISSUE_NUMBER in your commit message (or a synonym).