WebDev:FrontendCodeStandards: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Replaced content with "This page has been deprecated. For current coding standards and guidelines check out: > [http://mozweb.readthedocs.org/ '''Mozilla Webdev Bootcamp'''] (it's on [https://g...")
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== Browser Requirements ===
This page has been deprecated. For current coding standards and guidelines check out:
===== Support Levels  =====


*A grade:  
> [http://mozweb.readthedocs.org/ '''Mozilla Webdev Bootcamp'''] (it's on [https://github.com/mozilla/webdev-bootcamp github], contributions welcome!)
** 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.
(For the previous version of this page, check out the [https://wiki.mozilla.org/index.php?title=WebDev:FrontendCodeStandards&oldid=735044 wiki history]).
 
===== Mobile Devices =====
{|
|
! Support Level
|-
! Mobile Firefox (Android)
| bgcolor="#CCFFCC" | A-Grade
|-
! Mobile IE
| bgcolor="#CCFFCC" | A-Grade
|-
! Fennec
| bgcolor="#CCFFCC" | A-Grade
|-
! Opera Mobile
| bgcolor="#CCFFCC" | A-Grade
|}
 
===== Internal Tools  =====
 
{|
|-
|
! Linux
! Win XP
! Vista
! OS 10.5
! OS 10.6
|-
! Fx 4.0-Latest
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
|-
! Fx 3.6
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
|-
! Fx 3.5
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade
|}
 
===== Minimum Browser Support  =====
 
Support of other browsers is left to each product team.
 
{|
|-
| <br>
! Linux
! Win7<br>
! Win XP
! Vista
! OS 10.5
! OS 10.6<br>
|-
! IE 9
| <br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| <br>
| <br>
|-
! IE 8
| <br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| <br>
| <br>
|-
! IE 7
| <br>
| <br> | <br>
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| <br>
| <br>
|-
! Fx 4<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
|-
! Fx 3.5/3.6
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade<br>
|-
! Safari 4
| <br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade<br>
|-
! Opera 10<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade<br>
|-
! Chrome
| <br>
| bgcolor="#ccffcc" | A-Grade<br>
| bgcolor="#ccffcc" | A-Grade
| bgcolor="#ccffcc" | A-Grade
| <br>
| <br>
| <br>
|-
! Gecko based
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade<br>
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade
| bgcolor="#ffe303" | B-Grade<br>
|}
 
===== 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 [[Webdev:WAI-ARIA#Basic_ARIA_Support|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 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 [https://github.com/mozilla/playdoh 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 [https://github.com/jbalogh/zamboni/blob/master/manage.py Zamboni's code] and ask questions in #flux.
 
Applications must scale to estimated traffic.
 
see [http://mozilla.github.com/playdoh/ 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
* DRAFT: App code should be optimized to handle a high amount of concurrent traffic (i.e. X hits per second). Talk to product owner or Mozilla lead developer to determine minimum limit and estimated traffic.
 
==== 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...
** &lt;video&gt;, obviously the first choice
*** Supported by FF 3.5+, Safari 3+, Chrome
** Quicktime
*** IE w/ quicktime installed, iPhone
** Flash
*** Check out open source [http://www.longtailvideo.com/players/jw-flv-player/ 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
** [http://camendesign.com/code/video_for_everybody Video For Everybody] - excellent page detailing complete setup, from codecs to HTML
** [http://www.longtailvideo.com/players/jw-flv-player/ 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)

Latest revision as of 23:33, 22 October 2013

This page has been deprecated. For current coding standards and guidelines check out:

> Mozilla Webdev Bootcamp (it's on github, contributions welcome!)

(For the previous version of this page, check out the wiki history).

Retrieved from "https://wiki.allizom.org/index.php?title=WebDev:FrontendCodeStandards&oldid=735048"