Haboversion of the rules of good tone for the web technologist
Good day to all.
I read yesterday at Habré an interview with Olga Aleksashenko , in which she, among other things, divides the maker-ups into two classes - those who "figs" (the majority of employees of small studios with a certain experience), and "creators" - perfectionists who are looking for everyone case is the perfect solution. I immediately had a question - how to form common requirements for typesetting within one studio? Indeed, in the first case, these should be the most formal requirements, the fulfillment of which will not complicate the lives of programmers and optimizers, and the second type technologists become full-fledged architects - the quality of their decisions depends on the quality of the future project.
I invite all interested participants of Habr to take part in the creation of Habraravil good tone for layout designers. I understand perfectly well that there are a huge number of translated articles (mainly describing the CSS whales of the world's leading technologists), as well as many examples of solving specific problems. But I still didn’t find an accessible and understandable ideology, and Habr is a good choice as a platform for such a manifesto.
I propose to compose this way: in every comment there is one rule. Top-rated comments are added to the topic and participate in the discussion already as part of the rulebook.
')
To start:
When layout, the Habs community recommends:
1. Use the Reset-block together with the definition of key formatting tags (headings, paragraphs), if there is a possibility (perhaps not provided by the design) of their use on the site;
2. Separate, where possible, style sheets for browsers that support standards differently (i.e., reject css hacks of any kind in the main style sheets).
I ask you to take the topic seriously if possible - a lot of important things were invented on April 1.
Added by first day results:
3. Hard to set the rendering mode (! DOCTYPE);
4. Consider the possibility of scaling fonts;
5. Use clear class names, or accompany the draft with comments made;
6. In general, observe the semantics of markup tags - tables by tables, lists by lists.
I read yesterday at Habré an interview with Olga Aleksashenko , in which she, among other things, divides the maker-ups into two classes - those who "figs" (the majority of employees of small studios with a certain experience), and "creators" - perfectionists who are looking for everyone case is the perfect solution. I immediately had a question - how to form common requirements for typesetting within one studio? Indeed, in the first case, these should be the most formal requirements, the fulfillment of which will not complicate the lives of programmers and optimizers, and the second type technologists become full-fledged architects - the quality of their decisions depends on the quality of the future project.
I invite all interested participants of Habr to take part in the creation of Habraravil good tone for layout designers. I understand perfectly well that there are a huge number of translated articles (mainly describing the CSS whales of the world's leading technologists), as well as many examples of solving specific problems. But I still didn’t find an accessible and understandable ideology, and Habr is a good choice as a platform for such a manifesto.
I propose to compose this way: in every comment there is one rule. Top-rated comments are added to the topic and participate in the discussion already as part of the rulebook.
')
To start:
When layout, the Habs community recommends:
1. Use the Reset-block together with the definition of key formatting tags (headings, paragraphs), if there is a possibility (perhaps not provided by the design) of their use on the site;
2. Separate, where possible, style sheets for browsers that support standards differently (i.e., reject css hacks of any kind in the main style sheets).
I ask you to take the topic seriously if possible - a lot of important things were invented on April 1.
Added by first day results:
3. Hard to set the rendering mode (! DOCTYPE);
4. Consider the possibility of scaling fonts;
5. Use clear class names, or accompany the draft with comments made;
6. In general, observe the semantics of markup tags - tables by tables, lists by lists.
Source: https://habr.com/ru/post/22673/
All Articles