Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UPDATED README WITH ENGLISH LANGUAGE #28

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 76 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -86,3 +86,79 @@
<li>Разумеется картинки должны быть в&nbsp;отдельной папке, css&nbsp;&mdash; в&nbsp;отдельной и&nbsp;js&nbsp;&mdash; в&nbsp;отдельной. Графика, не являющаяся частью дизайна (всякие илююстрации, фото в новостях и т.д.) — нужно положить в отдельную папку, например userfiles.</li>
<li>Изображения должны масштабироваться в зависимости от размера окна <code>(max-width:100%; height:auto;)</code></li>
</ul>

[README IN ENGLISH]

Layout checklist
In order to give the layout to the client, it is enough to comply with the first 5 points. For distribution to production - the first 6.

Details for each item: http://habrahabr.ru/post/114256/

Compliance with the layout
Cross-browser, encoding and DOCTYPE
Validity (including CSSLint and JSHint), accessibility (ARIA, WCAG), microformats (microformats 1 & 2, microdata)
Block independence in CSS: minimizing the cascade, using BEM techniques
The site should look normal in all standard resolutions from 320 and higher, not have horizontal scrolling and fit into the screen of mobile devices
Correct work when driving in real text, layout reliability
CSS should be written using preprocessors (LESS / Sass / Stylus). It is desirable to use build systems (Grunt / Gulp) and builders (PostCSS / Autoprefixer).
Checking and optimizing download speed: https://github.com/ihorzenich/WebPerformanceChecklist
Retina support
Availability of Win / Mac / Linux-like fonts
Availability with disabled (loading) pictures
HTML5 forms, linking, validation
Semantics. No nonsense in html and css, uniformity, neatness (see "Good / bad")
Correct heading structure (H1, H2, ... etc. and TITLE)
Performance with disabled (unloaded) JavaScript
Performance when Flash is off
No bugs with large font
13. "Bad" / "Good"
It is important to understand that semantics can be not only in the elements used, but also in the class names. And the BEM class hierarchy is a new level of semantics.
Bad:

The worst thing, fortunately already rare, is float: leftfor all blocks. Crazy layout designer emulates familiar table cells, placing blocks like bricks one after another. Get out of the profession!
It is checked in the browser extension Web Developer → Outline → Outline Floated Elements, if everything is in red blocks, the layout needs to be thrown into the trash.
Also, such a layout is obtained when creating sites in Adobe Muse .
Examples : one - two - three
Indents between blocks on the site should be due to the margin of the blocks, and not protruding margins of the content of the blocks.
Bad - the lack of titles.
Bad - the lack of alt in images.
Bad - hacks for browsers inside main.css (both without filters and with them). Without filters - this is when when we just write {zoom: 1;}- it's very good. bad because will apply to all IEs, not just the one with the problem. With filters - when they write (* html, *+html и т.д.)- it is bad, because it clogs the code, makes it less readable, and some hacks may be generally invalid and break the CSSLint run. Conditional Comments is also bad, although it was previously considered a good technique, it is bad because this is an increase in the number of css files, and the main thing is the distribution of the code to different places. Now it is recommended to use special classes like html.ie7, html.ie8,…(from HTML5 Boilerplate), Modernizer-detection of features (view classes html.js.flexbox.canvas.no-touch…) and JS-detection of browser and platform (for example, CSS Browser Selector generating view classes html.webkit.chrome.chrome25.win.win8…)
Bad - not checking tabindex on forms.
It's bad to write styles without thinking about the logic of the elements' placement. For example, if an element is always on top, it should have a large z-index, you can't hope that everything looks fine now - the styles should be reinforced concrete. If an element should always be in some place, regardless of the surrounding elements, this is position: absolute; not float, etc. Blocks that are independent of each other should not be inside the same block (for example, company phone number and site search). Blocks that are independent of each other should be position absolute, not floated.
Very bad - presentation classes (right, red).
It is undesirable when the layout contains empty blocks for presentation purposes, for this there are pseudo-elements
It's bad when standard elements do not have basic styles. Those. just h1, h2, ul, table, etc without classes should look nice and organic. Simply put - use Normalize, not Reset CSS.
It's bad when there is no gradual refinement of styles for the text, when the style is written for each element separately, and outside of it - the appearance can be radically different. We are talking about a situation when, for example, text written without paragraphs has a completely different style than all the elements in the block. It is necessary to lead the styles from the bottom up, gradually refining them. It is important not to confuse text styles and block styles here. For text - a cascade is good, for site blocks - you need to use BEM.
Worse, overly detailed global styles. For example a {font: italic 10px Tahoma;}/ * Hate! Hatred! HATE !! 11 * / Then you have to override the link style for each block.
The dimensions and positioning of the element must be specified in the same units of measurement. Those. block height / width in px and margin / padding in em is strange and most likely a bug. Line-height - it is better to set it by a factor (1 / 1.2 / 1.4 ... i.e. without specifying the unit of measurement - this is the number by which the font-size is multiplied and the line spacing will be obtained). If we set the font-size / height in em, then we set the margin / padding in em too. Classic example: list dl-dt-dd, where dt and dd are stacked against each other by pulling dd up with a negative margin. Or - we allocated a padding space under the position: absolute of some text block. For text elements (paragraph, table cells), set padding and height in em (to correctly increase the font size).
It is bad (unacceptable!) To hang styles on the selectors of nested standard tags, without classes. Those. let's say we write something like h2 a span {какая-то крепкая штука, типа картинки с графикой, что закрывает текст в заголовке}, and then the client in the vizig suddenly drives in such a combination! And we get an incredible bug. On just single tags to display text from the database - it is possible, but using the .b-text block (see BEM CSS).
Bad - directly set the visual display elements through js: $('.element').css(color,"#f00"). This should be done through setting / changing classes.
Okay:

BEM ! It is important to understand that this is a methodology, not tools. For ordinary sites, layout using BEM CSS is enough , without using a block library and bem-tools. For a long time I thought that “BEM is a great idea, but this is too much, so categorically it is not necessary, it is necessary a little differently, for yourself ...” , and so - this is not true! It is imperative to leave the cascade, and BEM is one of the great solutions.
It's good to structure the code into blocks that describe the logic of the document. Those. create a div even where it is not needed for presentation purposes. And vice versa - try not to put an extra div where the structure does not require it, and this is necessary only for visual effects.
HTML5 Boilerplate is a great starter template from the fathers. Use and join development, add your bikes there! Previously, we had our own self-written framework-starting html, now we use Boilerplate as a basis, and we are already adding old developments to it.
Use well-established solutions, other people's modules, jQuery plugins, don't reinvent the wheel, but if you do, support them, maintain the code library (add code there after each new project, update the old one).
For text blocks that are edited in the admin panel, the atomicity of text styles must be ensured. Those. we have a page with some kind of text block, something like this: `` '' css .content-text h1 .content-text .entry .content-text .entry .somenamedblock `` Then .somenamedblock must receive text styles directly - .somenamedblock {font: …; color: …;}since otherwise, we will not be able to freeze them in the admin panel visig.
the same html-code for the blocks on the face and inside, with identical content, but different visual presentation of data. It is implemented through block and element modifiers, but not through the modification from the parent (cascade from body.pagename for example!)
Important little things
The logo on the inner liners should lead to the title. On the title, logo = h1, on the inner liners, H1 = content title, and Logo = div
Each page must have its own unique TITLE format About Us — %CompanyName%
All pages must be linked and checked for broken links .
All links should somehow react to: hover,: active and: focus - by showing / removing the underline, changing the color, whatever. All links except menu items must have a reaction to: visited
Check that all interactive elements of the page that should work - work.
"Content at the beginning of the page" - the content of the page should go at the beginning of the code, before any sidebars and other things.
All created pages should initially be cut into templates to make it easier for the programmer to integrate them.
The copyright must be correct .
There should be a favicon.ico (preferably with 32 × 32, 48 × 48 and 64 × 64 variations included inside it) and an apple-touch-icon
The layout should not contain pieces of code commented out "just in case", unnecessary unused files, old versions of files, etc. All backups can be pulled from the version control system (for example, Git or SVN), and on a live project, "garbage" then prevents you from figuring out how what works.
Sizes for boxes whose sizes depend on the text they contain should be specified in em, not px.
If the url of the link is unknown, then it must be equal to its anchor, written in Latin, with spaces / special characters replaced with dashes.
Skype plugin shouldn't break the layout
Resize textarea should not break the layout
When checking the frontend as a whole, a 404 page should be returned with a 404 code, not 200.
You need to be on the safe side by fixing the sizes of images displayed programmatically in css.
Check spelling by Word or Spelling , preferably - to print the content.
Links to other people's sites should be with target="_blank", it is desirable to highlight them with an "external link" icon.
Of course, pictures should be in a separate folder, css - in a separate one and js - in a separate one. Graphics that are not part of the design (all sorts of illustrations, photos in the news, etc.) - must be placed in a separate folder, for example userfiles.
Images should be scaled based on window size (max-width:100%; height:auto;)