We made requirements for the typesetter, didn't we go too far?

Question

1C-Bitrix

We work with remote layout designers and constantly go through the rake when we transfer the layout to programming.
We made a guide what we want from a layout designer tailored for us: html.jarency.ru
Tell me, how adequate is it to demand from a layout designer?

Answer 1

I do not see any excessive requirements, on the contrary, they can still be supplemented. If you read this "document", it may seem that you are unnecessarily demanding, but in fact, for a normal layout designer, everything that you described is the norm. I don't understand about bam either.

Answer 2

1.1. Directory structure

mkdir -p  html/{css/fonts,scss/util,js/vendor,i/icons}
tree html

spoiler

html
├── css
│   └── fonts
├── i
│   └── icons
├── js
│   └── vendor
└── scss
    └── util

.

1.2.1. Breakpoints

Suffice it to say that we store all variables in a separate file

20 For ID - camelCase. ID we need for JS

Not right. You need to use classes. If you want to separate classes for styling and for zhs - do a prefix

23 We use Autoprefixer, it will arrange prefixes for us. We use automation - we put it as a package and connect it to the style processing process. We do not use automation - there is an online option

Do layout with flex = do not use old browsers = no prefixes required = no autoprefixer required
Do not automate - there can be no such item even in theory

2. Solutions used

Mixing a general guide and a style guide is not necessary
A style guide generally needs to be prepared separately for each project
Everyone has already said about the bem

Answer 3

I advise you to write documentation like this:
1. Create a "clean" empty ("white sheet") template (without third-party libraries and with the ability to download it in the archive) and briefly describe the structure of the template (including grid layout and its default behavior for various permissions).
2. Describe the format of the section(s) for connecting third-party libraries and themselves: what they are for and in what cases they should be used. (you can add connection of all and comment out in a "clean" template-blank and put it in an additional archive)
3. Create a catalog of all elements of the template: on the left - the object itself, on the right - the source code.
4. Separately describe the main, most frequently used styles and their additional modifiers.

Answer 4

norms, well done,
if it’s not enough, add later, or the layout designer, applying some rules, can add directly there,
well, for general cases, you can stick this https://google.github.io/styleguide/htmlcssguide.html

Answer 5

BEM for sure!

Answer 6

It should be more compact.
Nobody can read that much.
Less sections.

Answer 7

Kindergarten.
Sorry.
You definitely didn't overdo it. Rather, they didn’t bend =)
Although some points are controversial, but this is already a personal preference))

Answer 8

For starters, it's pretty good. There is room to tighten
up You shouldn't use BEM in vain.

Answer 9

Normal requirements, not at all rigid even. But some points are controversial.

Answer 10

I didn’t bend the stick at all)
This will be a lafa workbench)