Firefox/Windows 8 Metro Style Guides
- this a spot to jot down guidelines of varying types, largely for front end developers & designers. This includes code style, theming style, and whatever else will help us produce a consistent, shiny produce faster. If you have questions about this page, please ping :ally in #windev.
- Message Dialogs
- Use message dialogs to present blocking questions that require the user's input.
- Use message dialogs for rror messages that apply to the overall app context
- Flyout 
- Show a flyout only in response to a user tap or click, and you should always dismiss the flyout when the user taps outside of it
- Size: The Flyout should be as small as possible given its content. It doesn't need extra padding beyond what is provided by the Flyout itself. If a control isn't absolutely necessary, then don't include it.
- Position: The Flyout should always be positioned near its point of invocation. Flyouts should never be positioned in non-contextual places such as the center of the screen. 
- Context Menu 
- A maximum width that equates to approximately 50 characters.
- Show the fewest number of commands possible, up to the six-command limit
- Use sentence capitalization for each command name
- Use a separator to distinguish groups of related commands
- Order custom commands in the context menu by importance, with the most important commands at the bottom
- App Bar
- Do follow placement conventions.
- Place the New/Add/Create button (+ icon) on the far right.
- Group view switching buttons together and place them on the far left.
- Place Accept, Yes, OK commands to the left of Reject, No, Cancel commands.
- Do set the app bar's dismissal mode to sticky when displaying contextual commands.(Should applied to Firefox Start contextual app bar)
- Do follow placement conventions.
- Help Page 
- Include a link to your support or home page or either embed an online page into your help page
- Do label the entry point in the Settings pane Help to clearly identify it.
- Don't use the Help entry point to link directly to a website. Don't launch a web browser when the user taps Help.
- Generally we use Mozilla Coding Style, with a few exceptions:
- You don't need to wrap lines to 80 characters. Use longer lines (up to around 100 characters; use your judgement) if it improves readability.
- Consistency is king, and supersedes any particular rule.
- Coding Style exceptions/additions:
- Put the opening brace on the same line as the "function" keyword (rather than on a separate line by itself).
- No space before ":" in object literals.
- if you create an attribute and it has only one value, do not set it to true/false. Remove the attribute in the case of false. This produces cleaner, more concise css, without imperiling js readability.
XUL / XML
- One attribute per line, aligning with the first character of the first one
- If there is an id attribute, that should be the first attribute listed
- Children are indented 2 spaces
- Treat strings enclosed as children
- In example below, &clearPrivateData.done is an enclosed string where as &clearPrivateData.button is a label, which is an attribute
- If separate open & closing tags, tags should go on separate lines
- No soft tabs (\t characters)
- Try to keep the 80 character limit
- (and if not, try really hard to keep it below a 100)
- If your oncommand, command, or onclick code is too long, please really consider putting it in a function
<hbox align="center"> <button id="prefs-clear-data" label="&clearPrivateData.button;" command="cmd_sanitize" flex="1" /> <spacer id="clear-notification-empty"/> <cssthrobber id="clearprivacythrobber"> </cssthrobber> <description id="clear-notification-done"> &clearPrivateData.done; </description> </hbox>
- yuan's list of design links: https://kippt.com/yuan/designing-for-windows-8
- general coding guidelines for Mozilla: https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style
- general branding/identity/style/usage guide for Mozilla: https://www.mozilla.org/en-US/styleguide/