MozillaWiki

WebDev:FrontendCodeStandards

Revision as of 22:44, 26 April 2011 by Aking (talk | contribs) (→‎Web App Code: Adding notes around vendor)

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

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 design.

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

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/

Analytics

Set goals for your project.

Use the Mozilla Webtrends account to track analytics: https://intranet.mozilla.org/Webanalytics

Web App Code

Code should be written in Django and MySQL. If you want to use any other architecture or anything more interesting (message queues, etc) ask first!

A basic starting point is to use Playdoh.

Setup your app to use the playdoh and playdoh-lib. The playdoh-lib repo will show up in a directory named 'vendor' as it is a git external. Lots of useful libraries are in vendor, but document any extra python libraries in the requirements/prod.txt. Your app must be able to run from mod wsgi using the vendor libraries.

Developers Niceties

You may install into a virtualenv and/or run Django via manage.py's runserver command.

Our Operations group will use the libraries under vendor during deployment. Make sure your code loads and runs under either deployment scenario!!! As always, compare your setup with Zamboni's code and ask questions in #flux.

Applications must scale to estimated traffic.

see Playdoh's Docs for details.

Scaling Tips

  • django-cache-machine - Use memcached
  • django-multidb-router - Your app must be configurable so that reads can go to a separate DB than writes
  • zeus - Your app will run behind Zeus... Set HTTP headers, etc
  • Think about cache coherency, based on all of these factors

Web dev will not support a project made up of multiple random codebases with multiple authentication flows. Example: Wordpress + Tiki-Wiki + Plone. When in doubt, integrate 3rd party services for non-essential features;Do not spin up a new instance of an existing 3rd party product for non-essential features without consulting webdev and operations.

Web dev/Operations will not support arbitrary servers (Couchdb, Cassandra, something you wrote in Fortran 4)... without being consulted first.

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.
    • Use W3 Validator before you commmit to git
  • 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.
    • Write unit tests with qunit
    • var your variables
    • Use JSlint : http://www.jslint.com/
  • Python
    • Use PEP-8
    • Use pylint, pyflakes, and other code analysis tools before commiting to git

Performance Standards

Page requirements

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

Recommendations

(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?
Retrieved from "https://wiki.allizom.org/index.php?title=WebDev:FrontendCodeStandards&oldid=303024"