1. Cross browser testing
Site should work fine in IE6-8, FF3+, Opera9+, Safari4+, Chrome4+
2. Always define background colour for body even if it’s white.
3. If you use css hacks comment them, or better use css_browser_selector.js. Remember about layout designers, that will work with this layout afterwards.
4. Class names and id should correspond to application, for example header, menu, footer, news.
5. Divide html blocks by comments, for example this way:
It’s needed for creating templates for CMS from html model, after that comments would be deleted.
6. Use GIF/PNG with 8-bites alpha channel instead of PNG-24, when it’s possible.
7. Everything that can be done without JS should be done without it .
8. If there is lot of JS code - it should be placed to separate file. Event handlers should also be separated to another file.
9. You should agree with client on which JS libraries you are planning to use for layout, to prevent situations when you used PrototypeJS for layout, and client wants to implement jQuery for his site.
10. For breadboard model should be set min and max width.
11. If there are no conditions, model should fit maximized browser window without horizontal scrollbars with horizontal screen resolution of 1024px, and if model size permits - 800px.
12. In images folder there shouldn’t be images that weren’t used in layout. If something was removed from layout or was made over - don’t forget to delete useless images.
13. For all elements, that could contain text of different length that should be displayed in one line (for example, for buttons or titles, if design doesn’t provide them to display in more than one line) set CSS feature
white-space:nowrap.
14. CSS file should be broken down to blocks by function with the lines with comments, for example
/* ___________1. CSS reset ____________________*/
/* ___________2. Type elements____________*/
/* _______________2.1. Headings______________*/
/* _______________2.2. Links________________*/
/* _______________2.3. Form elements_________*/
/*___________3. HEADER__________*/
/*___________4. FOOTER_______________*/
/*___________5. SIDEBAR_______________*/
15. If layout is carried out by several phases (for example, layout designer send pages one by one, or some pages are returned to him for improvement) and you don’t use system for versions control, layout designer should attach file with description of changes in model that should look like
* new images were added to folder img
* images btnHome.jpg and btnFeedback.jpg are needless from now, they can be deleted
* html-code was changed in file section anketa.html
* new styles were appended to file main.css (from .form_row and till the end)
16. Coding of html-model should be discussed, CSS and JS files should have same coding as the model, otherwise there could be lots of bugs.
17. If model includes JS that is changing DOM - check carefully site to work in Opera, because this browser doesn’t reload page after clicking ‘back’ button, but displays cashed document taking into account all DOM modifications, that were done with JS.
18. Don’t forget to set cursor:pointer for buttons that weren’t done with using input.In situation when you don’t know if JavaScript event handler will be used for this button events or it will be link, it would be better to use tag.
19. If you’re using JavaScript event handler for links, you should watch over event handler to return ‘false’, or use href='javascript:void(0)' instead of popular href='#', so to prevent page from scrolling up.
20. As for layout - field marks should be in label tags, that have correct for attribute. In layout support elements for validation mistakes output and styles for inaccurate filled in fields. If it isn’t supported in design discuss it with the client.
21. If nonstandard fonts are used in your model, find out if elements with nonstandard font can be implemented as images, if no - discuss technology which will implement their displaying (sIfr, Cufon, etc.)
22.If the opposite isn’t required, all blocks should have dynamic high (so it should change against the content) and sometimes you should set minimal high to prevent design breaking. If you are going to use blocks with fixed high you should first discuss it with client.
23. In models where high of the page depends on content make footer fixed on the bottom of browser window when there are no content, if the opposite isn’t required.
24. If model doesn’t pass 100% html-validation, try to use unvalid code only when it’s necessary, don’t use it for shortness ect.