WebDev:FrontendCodeStandards

Browser Requirements

Support Levels

• A grade:
  • Full functionality and layout support
  • Minor inconsistencies between browsers is tolerable
• B grade:
  • Larger rendering issues allowed
  • Fallback to basic html from dhtml/ajax where necessary
• C grade
  • Send down just HTML
  • Degrade to base interactions

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.4	OS 10.5
Fx 3.5	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 3	B-Grade	B-Grade	B-Grade	B-Grade	B-Grade

Full Support

(primary goal of website is to drive Firefox downloads and/or offer technical support)

	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
IE 6			A-Grade
Fx 3.5	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 3	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 2	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Safari 4		A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Safari 3		A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Opera 10	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Opera 9	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

Latest Support

(primary audience of website is Firefox users)

	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 3.5	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 3	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Fx 2	B-Grade	B-Grade	B-Grade	B-Grade	B-Grade	B-Grade
Safari 4		A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Safari 3		A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Opera 10		A-Grade	A-Grade	A-Grade	A-Grade	A-Grade
Opera 9	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

(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)
• HTML:
  • HTML5 doctype. Safe to use for all browsers.
  • 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.
• 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
• 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/

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/)
• 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

(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?