WebDev:FrontendCodeStandards: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 15: Line 15:


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.
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 up on: [http://www.w3.org/TR/2008/WD-wai-aria-20080204/ ARIA]


=== Code Standards ===
=== Code Standards ===

Revision as of 20:33, 1 April 2008

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
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


QA Requirements

(Copied from Y! GBS)

Grading the browser ecosystem enables meaningful, targeted, and cost-effective QA testing. As noted, representative C-grade testing and systematic A-grade testing ensures a usable and verified experience for approximately 99% of our audience. A-grade testing must be thorough and complete, while C-grade testing can be accomplished with one or two representative browsers (e.g., Netscape 4.x and Lynx).

It’s worth reiterating that testing resources do not examine X-grade browsers.

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 up on: ARIA


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
    • 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.
    • 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)
    • More?
  • JS

Performance Standards

Security Standards

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