Requirements for html-layout

1. Layout, outsourcing and technical tasks

Layout is a relatively independent stage of web development and, for example, in small web studios it is often the first candidate for outsourcing in conditions of limited labor resources.
It so happened that I often had to give this work to subcontractors and, despite the expected uniqueness of the result, sometimes the layout designers surprised me a lot. And more often - in a negative sense.

To save manpower staff designers, it is not enough to shift this work on the shoulders of the first vending freelancer. Everything is much simpler if you constantly outsource work to the same performers - in the process of long-term cooperation, some kind of unwritten set of standards and requirements are always formed, the fulfillment of which is a habit. But if you are working with a person for the first time - the very good portfolio and recommendations do not guarantee getting the desired result and moreover - they do not even assume that the performer will understand you correctly. Therefore, we need detailed technical tasks on layout.

And this moment is ignored. Often this is due to the assumption that the labor costs of writing a detailed TK in the amount of the cost of outsourcing does not pay off with the saved time of a full-time layout designer. In the end, the layout - it's not so difficult - thinks an ordinary project manager. And, as a rule, it really rolls, * praise to the human intellect *, professional layout designers for the most part limit the riot of experimenter's spirit and know in advance what technical solutions in the layout can cause the customer to not hell hemorrhoids to ban the layout designer, but still excluding joy and admiration for a beautiful html-layout.
')
However, the probability of fakapov, as practice shows, is not so small that it can be neglected.

And the main misconception here is that the detailed TZ is difficult and time consuming. In any case, some specific requirements for the layout have to be described, but as a rule, the general requirements and recommendations are scored.

2. Oh, great is my sorrow!

I recently received a layout that managers gave to outsource and just did not know whether to laugh or cry. If it were not for me to integrate this layout into the CMS template system, I would probably still laugh.

Table layout and styles not rendered in the CSS file and the standard Dreamweaver script for highlighting the buttons are not even perceived as flaws after the hell I saw. All input fields were inserted inside the label tags, stuck in separate forms, and when trying to somehow bring it into a human form, the whole layout was falling apart. CSS classes had Cyrillic names, and not meaningful, but of the form ".style1, .style2". Most of the form elements were stylized by some little known and terribly crooked jQuery script, some elements had the same ID and between them was JS code that operates on these elements and receives them by ID, and the top of the insanity is the application at the end of the document jQuery.css to set styles, which, well, nothing really prevented just register in the CSS file. And the site header, along with a bunch of links (with Tahoma font and without smoothing) was made with one picture, which has MAP and AREA elements superimposed. I will not injure your psyche anymore with the description of the files in this wonderful layout, since there were countless of them there.

In general, believe me, comrades, it was PPC, which also sneaked up almost before the deadline.

Incidents of such a character prompted me to publish a list of requirements and recommendations that will be useful both to people giving layouts on the html layout and to the layout designers themselves.

You can recycle these recommendations and add your typical TK to them for layout. Many of the things listed are quite obvious, but you can extract profit from the fact that they are all collected in one place. Some items (for example, requirements for support by browsers or used scripts) are specific for different offices, but I will not continue to write vague phrases so that this list can be easily copied and sharpened for their specific work .

3. Requirements and recommendations

1 . Cross-browser compatibility
The site should work fine in IE7 +, FF3 +, Opera9 +, Safari4 +, Chrome latest major version (or depending on the terms of the contract with the client and the year in which you read this article).

2 Always describe the background color for the body, even if it is white.

3 If you use CSS hacks, comment on what it is and for which browser, but rather use css_browser_selector.js . Take care of coders who will have to work with this layout after you.

4 Class names and id must be meaningful for use.
eg header, menu, footer, news

5 Please separate the main html blocks by comments. Like that:
<! --— BEGIN FOOTER ->
<! --— END FOOTER ->

This is necessary to create a template for the CMS from the html template that was laid out, after which the comments will be deleted.

6 Do not neglect the possibility of using GIF / PNG with 8-bit alpha channel instead of PNG-24, where possible.

7 All that can be done without Javascript, do without it.

8 If there is a lot of Javascript code, you need to put it in a separate file. Event handlers are also better separated and declared in a separate file.

9 If this has not yet been agreed with the customer, preliminarily stipulate which JavaScript libraries you plan to use during layout design, so that later it does not turn out that PrototypeJS was used during layout, for example, the customer plans to implement jQuery on a mandatory basis.

10 For rubber layouts, the minimum and maximum width must be set.

11 If in T.Z. it does not say otherwise, the layout must necessarily be placed without horizontal scrollbars in the browser window that is maximized with a horizontal component of the screen resolution of 1024px, and if the layout size allows, then 800px.

12 In the folder with images there should not be images that are not used in the layout. If something is excluded from the layout or altered - do not forget to delete already unnecessary pictures.

13 For all elements that can contain text of different lengths, which should be written in one line (for example, for buttons or headings, if the design does not provide that they can occupy more than one line), be sure to set the CSS property to white-space: nowrap .

14 The CSS file should be split using lines with block comments by function, for example:

/* ___________one. Reset CSS ____________________ * /
/ * ___________2. Typical elements ____________ * /
/ * _______________ 2.1. Pledges ______________ * /
/ * _______________ 2.2. Links ________________ * /
/ * _______________ 2.3. Form elements _________ * /
/ * ___________ 3. HEADER (Site Cap) __________ * /
/*___________four. FOOTER (Basement) _______________ * /
/*___________five. SIDEBAR (Right) _______________ * /

How exactly to structure styles is a bit holivarny question, but the main thing is to do it somehow.

15 If delivery of the layout is done by more than one step (for example, the layout designer sends the pages one at a time, or if already added pages are sent back for revision) and you do not use a version control system for layout, the performer must attach a file describing changes in the layout approximately such content:

• Added new images to the img folder,
• Pictures btnHome.jpg and btnFeedback.jpg are no longer needed, can be deleted
• Changed html-code in the anketa.html file section
• Added new styles to the end of the main.css file (starting with .form_row and below).

16 To specify in what encoding the html layout should be. CSS and JS files must be in the same encoding as the layout, otherwise the likelihood of a long and tedious hunt for bugs is critically increased.

17 If JS is present in the layout, it modifies the DOM - closely monitor that everything works correctly in Opera, since this wonderful browser does not reload the page when you click on the button, but returns the cached document, and a very important point: the document is not just cached, but also with all the DOM modifications that were made with JS

18 Do not forget to prescribe the cursor: pointer for buttons that are not made using input. If you don’t know if an event handler is hung on this button using JS or it will be a link, it’s better to use the <a> tag anyway.

19 If you do event handling when clicking on links, make sure that event handlers return false, or use href = 'javascript: void (0)' instead of popular href = '#', so that the page does not scroll up.

20 Correct the form correctly: field labels must be in label tags with a properly filled for attribute. When form-making, provide elements for displaying validation errors and styles for incorrectly filled fields. If this is not provided in t.z. and design, be sure to discuss this with the customer.

21 . If non-standard fonts are used in the layout, be sure to specify whether elements with a non-standard font can be made into pictures, if not - discuss with what technology their display will be implemented (sIfr, Cufon, etc.)

22 Unless otherwise noted, for particular cases, all blocks whose height in the design does not interfere with making it dynamic should have exactly dynamic (i.e. content dependent) height, and sometimes, so that nothing could potentially break the design, it is necessary to set and minimum height. If you want to make a block of a fixed height - first ask the customer.

23 . In layouts, where the height of the page depends on the content (and such, as a rule, the majority), provide for the footer to be nailed to the bottom of the browser if there is no / small amount of content, unless otherwise stated.

24 If the layout does not pass 100% html validation, try to at least do so that the use of an invalid code is justified. It’s not worthwhile to validate the validity of the layout just because “I like it so much” or “it turns out shorter”

PS

I hope this list of requirements and recommendations will be useful to you! If there are constructive thoughts, suggest in the comments how it can be supplemented.