WebDev:FrontendCodeStandards

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Browser Requirements

• Follow Yahoo! GBS? http://developer.yahoo.com/yui/articles/gbs/
  • Do we want to Grade A IE6? (Do we want property-specific GBS?)
    • Potential users vs. existing users
    • Support Linux on our matrix
    • Support last major release (2) and revisit support for FF2 in 6 months.
    • Some IE6 stats:
      • sfx: 11.7%
      • gfx: 14%
      • moco: 3.9%
      • sumo: 2.1%
      • amo: 1.1%
• Except we should support a degraded experience in all Mozilla/Firefox versions?
• More?

Proposed schema

Mobile Devices

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

Internal Tools

	Linux	Win XP	Vista	OS 10.4	OS 10.5
IE 8		C-Grade	C-Grade
IE 7		C-Grade	C-Grade
IE 6		C-Grade
Fx 3	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 2	C-Grade	C-Grade	C-Grade	C-Grade	C-Grade
Safari 4		C-Grade	C-Grade	C-Grade	C-Grade
Safari 3		C-Grade	C-Grade	C-Grade	C-Grade
Safari 2				C-Grade	C-Grade
Opera 9	C-Grade	C-Grade	C-Grade	C-Grade	C-Grade

Full Support

(primary goal of website is to drive Firefox downloads)

	Linux	Win XP	Vista	OS 10.4	OS 10.5
IE 8		A-Grade	A-Grade
IE 7		A-Grade	A-Grade
IE 6		A-Grade*
Fx 3	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 2	A-Grade**	A-Grade**	A-Grade**	A-Grade**	A-Grade**
Safari 4		A-Grade	A-Grade	A-Grade	A-Grade
Safari 3		A-Grade	A-Grade	A-Grade	A-Grade
Safari 2				A-Grade	A-Grade
Opera 9	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Chrome
Gecko based	B-Grade	B-Grade	B-Grade	B-Grade	B-Grade

*  - reevaluate End of Year 2008
     (branch off and declare continued support only for acquisition sites?)
** - reevaluate End of August 2008

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

(Copied from Y! GBS)

Representative testing of the core experience is critical. If you choose to adopt a Graded Browser support regime for your own web applications, be sure your site’s core content and functionality is accessible without images, CSS, and JS. Ensure that the keyboard is adequate for task completion and that when your site is accessed by a C-grade browser all advanced functionality prompts are hidden.

Accessibility Requirements

• Hard to define what 'accessible' is
• Read Accessibility accommodations
• Read up on: ARIA
• WAI Priority 1

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)
  • More?
• HTML:
  • XHTML 1.0 strict doctype (we might want to move to HTML 4.01 strict if we are serving XHTML as html/text)
  • Pages must 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.
  • More?
• CSS:
  • No separate stylesheets for any browser and no conditional statements.
    • This might be necessary for some layouts. Reserved for worst case scenarios.
  • 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
  • More?
• 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
  • Standardize on jQuery?
    • jQuery++, but remember Cake uses Prototype and the namespaces can conflict
  • Make JS reusable as best as possible.
  • var your variables
  • Use JSlint : http://www.jslint.com/
  • More?

Performance Standards

• 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/) (possibly at build time?)
• No more images in the DB!
• Min 1.5s load time for all pages (broadband)?
• Min Xs for dialup?
• Min Xms for page to execute?
• Use ySlow to see where pages can be improved
• 250k max page size overall
• More?

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

Security Standards

To be branched off into separate document

Also IT's responsibility, we should work with them together on this

• Protect against cross-site request forgeries with crumbs (http://developer.yahoo.com/security/)
• Filter all input (SQL, HTML, JS, CSS)
• Verify user has permissions on content they are editing/deleting
• Don't include JS from 3rd party domains
• Read http://phpsec.org/projects/guide/
• More?