WebDev:FrontendCodeStandards

Browser Requirements

Support Levels

• A grade:
  • Roughly 90% or more of functionality and design is supported and functional
  • Variations between browsers is acceptable
  • 'Advanced' browsers can receive a higher fidelity experience with other browsers receiving a lower fidelity
• B grade:
  • Larger rendering issues allowed
  • Core functionality and content should still be accessible
  • Fallback to basic html from dhtml/ajax where necessary

If it's not on the chart, we don't support it.

Mobile Devices

	Support Level
Mobile IE	A-Grade
Fennec	A-Grade
Opera Mobile	A-Grade

Internal Tools

	Linux	Win XP	Vista	OS 10.5	OS 10.6
Fx 4.0	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 3.6	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 3.5	B-Grade	B-Grade	B-Grade	B-Grade	B-Grade

Minimum Browser Support

Support of other browsers is left to each product team.

	Linux	Win7	Win XP	Vista	OS 10.5	OS 10.6
IE 8		A-Grade	A-Grade	A-Grade
IE 7			A-Grade	A-Grade
Fx 4	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 3.5/3.6	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Safari 4		A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Opera 10	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Chrome		A-Grade	A-Grade	A-Grade
Gecko based	B-Grade	B-Grade	B-Grade	B-Grade	B-Grade	B-Grade

Other Support

• New Sites/Projects: Progressive enhancement for advanced functionality
• Current Sites: make new functionality degrade, don't rewrite current code
• Need to work on accessibility! (ex: AMO Control Panel)

QA Requirements

QA should test and file bugs appropriately for the browser support chart that applies to each site.

Accessibility Requirements

• Add basic ARIA support where appropriate

L10n Requirements

All projects must be localizable. Layouts must be compatible with RTL and LTR text flow.

Designs shouldn't be overly "tight" and should be bullet-proof against text length. Use http://www.felocity.org/files/bookmarklets/fakegerman.html to test your deign.

Don't put text in images. Use gettext. The L10n web team will evenutally help you extract strings into an SVN repo and uploaded into Verbitm.

Source Control

Use source control :) use https://github.com/mozilla for new projects. You may also use Mozilla's hg or svn.

Create teams for agencies or community members as needed and give them read/write access to the new mozilla repo.

L10n strings should be stored in SVN under a new project or https://svn.mozilla.org/projects/l10n-misc/trunk/

Code Standards

• Layered semantic markup
  • Semantic class/id names and appropriate HTML tags for content
  • No inline CSS & JS unless absolutely necessary
  • Progressive enhancement (see bolded QA requirements)
• HTML:
  • HTML5 doctype. Safe to use for all browsers.
  • Pages should validate. Not a strict requirement. Some layouts can't be achieved without a few errors.
  • Use most meaningful tags for content
  • Images/bg images with text in them must have alternate textual representation (alt text or text positioned offscreen for screenreaders). Avoid these due to L10n difficulties anyway.
• CSS:
  • Separate stylesheets for other browsers (IE) are ok
    • If only 1 or 2 properties are changed, keeping them in the original stylesheet is ok
  • For new sites, look into YUI Fonts & Reset, this will reduce browser layout differences
  • Semantic classnames
  • Don't use position: absolute unless absolutely necessary
  • Use least amount of selectors possible to allow for overriding
  • Don't use !important (see above)
  • Specify font sizes in EMs or %
  • Clear floats with zoom:1 & content:after
  • Hide content for screen readers with position:absolute and position offscreen. Display:none hides content from screen readers.
  • Design layouts to stretch according to their contents (good for localization and good for font-resizing)
  • Avoid selectors that are native element names (i.e. don't style on "div" or "p") except when resetting.
  • Specify in comments the scope of generic sounding class names (what does .block mean and where is it applied? one page or multiple pages?)
    • Try avoiding generic class names altogether
• JS
  • Don't pollute the global namespace (put all functions into objects/closures)
  • Use Module pattern for singletons? (http://yuiblog.com/blog/2007/06/12/module-pattern/)
  • Use .prototype for objects
  • Use jQuery
    • Very fast & light
    • If you need another library, please concatenate & use as little as possible
  • Make JS reusable as best as possible.
  • var your variables
  • Use JSlint : http://www.jslint.com/

Performance Standards

Page requirements

• Min score of B on homepage and 1 other 'major' page
• ~400k max page size

Recommendations

• Follow Yahoo!'s 34 rules http://developer.yahoo.com/performance/rules.html
• Follow these best practices: http://developer.yahoo.net/blog/archives/2008/01/the_7_habits_fo.html
• Sprite images
• Concat and minify JS & CSS with
  • YUI Compressor (http://www.julienlecomte.net/blog/2007/08/13/)
  • or Minify (http://code.google.com/p/minify/)
• Max 3s load time for all pages (tracked via Gomez)
• Use ySlow to see where pages can be improved

(see Webtools:Scalability for an overview of tools/infrastructure)

Security Standards

WebAppSec/Secure_Coding_Guidelines

Video Standards

• Players, in order of degradation...
  • <video>, obviously the first choice
    • Supported by FF 3.5+, Safari 3+, Chrome
  • Quicktime
    • IE w/ quicktime installed, iPhone
  • Flash
    • Check out open source JW-FLV player
    • YouTube, DailyMotion, etc are also options
  • Download links
    • If all else fails, at least let the user download easily

• Formats
  • Webm - Firefox
  • OGG
  • MP4 / H.264 - everything else
  • Consider high vs. low vs. audio-only formats?

• Resources
  • Video For Everybody - excellent page detailing complete setup, from codecs to HTML
  • Open source flash player

• Hosting
  • Currently, file a bug with IT (mozilla.org:server ops) and host at videos.mozilla.org
  • https://intranet.mozilla.org/Uploading_Videos
  • Link to videos should use CDN (videos-cdn.mozilla.net)