The guidelines for browser support may live separately from your coding standards. All these guidelines should link to each other and live on a wiki. Some items may be repeated from other documents so that the guide can stand alone as a single entity.
Introduction and conventions
General rules
Avoiding common bugs
Hacks and filters
Devices
These Browser Support Guidelines are applicable to all websites created and managed by Igloo Refrigerator Parts Inc. and under the igloorefrigeratorparts.com domain.
The keywords used in this guide have the following significance:
MUST: This rule must be followed at all times with no exceptions.
MUST NOT: This rule means an absolute prohibition with no exceptions.
SHOULD: This rule should be followed at all times unless there is an acceptable reason not to that has been justified.
SHOULD NOT: This should be avoided at all times unless there is an acceptable reason to that has been justified.
MAY: This rule gives permission to implement a particular measure under certain circumstances.
For coding standards and accessibility considerations, please read the CSS Standards Guide and Accessibility Guidelines, respectively.
You can access the necessary templates and files to start a new project from the "Templates and Assets" section.
2.1 You MUST test the website against the Graded Browser Support chart available on the Graded Browser Support page.[106]
2.2 You MUST test the website with the following setting combinations: CSS on/images on, CSS on/images off, and CSS off/images off because they cover most realistic scenarios.
2.3 The site MUST be legible and functional on each and every device.
3.1 You SHOULD NOT set both width/height and padding on the same element because this may cause layouts to break if a browser renders the page in quirks mode.
3.2 Absolutely positioned elements SHOULD have both horizontal and vertical positioning defined to avoid inheritance issues.
3.3 Floated elements SHOULD have a set width because some browsers will behave unpredictably otherwise.
3.4 You SHOULD set a value for height in IE 6 where min-height is set for other browsers because this browser does not understand min-height.
3.5 When positioning an element relatively, you SHOULD ensure that you trigger hasLayout; position:relative does not trigger hasLayout (see 4.7).
4.1 You MUST NOT use conditional comments that could potentially target future browsers. For example, you MUST NOT target IE, but you MAY target IE 6 or lower.
4.2 Hacks and filters SHOULD be avoided. When they cannot be avoided, they MUST be properly documented; you SHOULD provide a link to the documented solution, as well as the common name for the bug, as follows:
/** HACK_IE_LTE_6: "display: inline" fixes the Double Float Margin bug on IE5/6. More on thisbug/solution: http://www.positioniseverything.net/explorer/doubled-margin.html */
4.3 When using hacks and filters for Internet Explorer, they MUST be prefixed with a comment following the syntax shown here:
HACK_IE_LTE_7:
This comment means a hack for IE versions previous to or equal to 7:
HACK_IE_7:
This comment means a hack for IE version 7. This methodology makes it easy to search for these hacks in the future.
4.4 You MUST NOT use hacks to target browsers other than those in this list:
The underscore hack
To target IE 6 and below, prefix the property name with an underscore.
Example:
_property: value;
The star hack
To target IE 7 and below, prefix the property name with an asterisk.
Example:
*property: value;
To target IE 8 and below, suffix the value with backslash 9.
Example:
property: value9;
4.5 To target multiple versions of IE, you MAY combine the hacks described in 4.4. For example:
property: value9; /* HACK_IE_8: Comment... */ *property: value; /* HACK_IE_7: Comment... */ _property: value; /* HACK_IE_LTE_6: Comment... */
4.6 In cases where the hack you need to use is not mentioned in 4.4, you MUST have it agreed and added to this document before you may use it.
4.7 You SHOULD NOT use zoom:1 for normal purposes, but only to fix hasLayout in IE that cannot be fixed with a cleaner solution.
4.8 You SHOULD use CSS validation as the first step to fixing possible bugs.
5.1 You MUST test the website against the Mobile Graded Browser Support chart available in the Mobile Graded Browser Support page.[107]
5.2 Background images SHOULD be applied to elements with a class that is unique to that device, not elements with no class applied, because those images may be downloaded unnecessarily.
5.3 You SHOULD support print style sheets. The main style sheet SHOULD be aimed at "all" so no devices are left out.
5.4 In print style sheets, lists that use background images for bullets SHOULD have the default bullets reinstated, as most browsers won't print background images by default.
5.5 Navigation elements aren't usually necessary for printed media and SHOULD therefore be hidden via CSS.
5.6 Wherever possible, floated containers SHOULD be unfloated for print style sheets.
5.7 In print style sheets, font sizes SHOULD be set in pt.
5.8 There SHOULD be an indication of the link's href attribute on external links. Visit A List Apart for a good technique on how to do this: "CSS Design: Going to Print" (http://www.alistapart.com/articles/goingtoprint/).
5.9 You SHOULD make sure that tables and images are not cropped on page breaks.
[106] We do not include this document here because we typically recommend using the Yahoo! Graded Browser Support as a start. You should modify it based upon your reporting tools and the browsers your users use.
[107] We do not include this document here because we typically recommend using jQuery Mobile's Mobile Graded Browser Support (http://jquerymobile.com/gbs/) as a starting point. You should modify it based upon your reporting tools and the browsers your users use.