заголовок на русском, а содержание на английском) это very странно

Frontend Best Practices - HTML
Paragraph 3: Константин Константинопольский
Delete last symbol in link: https://tema.livejournal.com/1322108.html/

Привет всем!
В goodPractice.md имеется пункт про следованию стайлгайду от AirBnB. И хотя там же присутствует оговорка

Все, что перечислено в гайде принять к исполнению, если это не перекрыто нашими правилами ниже

тем не менее, хотелось бы акцентировать внимание на спорных рекомендациях касательно нейминга (квази)приватных методов класса:

В js нет публичных и частных свойств, поэтому частные методы просто делать с префиксами "_" (нижнее подчеркивание)

Как вы считаете, возможно, стоит этот пункт переписать с учетом правил, изложенных в стайлгайде AirBnB, и использовать для имитации приватных полей WeakMap или, как вариант, символы?

На данный момент имеется несколько разногласных issues для нескольких людей, где в одном issue указано, что все кавычки в pug файлах необходимо заменить на двойные, а в issue другого человека, другой ревьювер написал о необходимости использовать двойные кавычки в pug HTML атрибутах, а в местах где используется js код - одинарные. Нужно регламентировать данный момент в best practices, во избежание спорных моментов, и желательно использовать второй вариант, где:

- const anyWord = "word";               // Плохо, т.к это уже js код, хоть и внутри PUG файла, 
                                        // у него должны быть одинарные кавычки
button(type="button")= anyWord          // type="button" - HTML атрибут, 
                                        // он должен быть в двойных кавычках

- const anyWord = 'word';               // Хорошо
button(type="button")= anyWord         

В шаблоне можно сфомрировать структуру, по которой будет требоваться перед открытием PR заводить ишью и там обсуждать сам факт внесения изменений. В шаблоне ишью можно будет формализовать, какие именно части вопросов надо осветить, чтобы начать обсуждение предложенной темы.

Создано после обсуждение в #36

Не знаю можно ли создавать issue по этому поводу, но когда изучаю best practices иногда встречаются такие ошибки

Если нужно, буду сюда заносить неточности

В первом пункте пишем про одно, а затем ниже сами его и нарушаем, надо исправить
https://github.com/fullstack-development/front-end-best-practices/blob/master/JS/jQuery.md

Думаю, следует дополнить стандарт примерами для:

• использования путей с алиасами;
• что делать в случае если импорт используется только для правки порядка импорта ресурсов сборщиком (при использовании bem компонент должен быть импортирован раньше модификаторов, которые лежат глубже).

Ссылка на стандарт

Концепция не удовлетворяет области применения для модификаторов с «ключами»

#27

есть пункт "Прогонять картинки через kraken.io или использовать свои CLI-утилиты для этого;"
https://github.com/fullstack-development/front-end-best-practices/blob/master/HTML/includeFiles.md
наверно нужно пояснить для чего их нужно прогонять

Сделать как с AirBnb, только вот на эту доку: https://github.com/eventbrite/javascript/blob/master/react/testing.md

Здравствуйте!
Надеюсь, обратился в правильное место. Я стажер.
В лучших практиках указано, что нужно придерживаться стайлгайда Airbnb,
и читать его только на оригинальном английском, так как в нем описаны es6 фичи.
Я наткнулся на перевод Леонида Лебедева, где так же хорошо описаны эти фичи.
https://github.com/leonidlebedev/javascript-airbnb#ecmascript-6-es-2015-styles
Прошу обратить на это внимание.

Здравствуйте!
В моем личном представлении глобальные библиотеки - библиотеки, которые установлены в системе, а не в проекте.
Речь, наверное идет о библиотеках, которые попадают в конечную сборку, то есть не только находятся в проекте при разработке, но и на продакшене.
В файле package.json они описаны в Dependencies.
Надеюсь я правильно понял, и лучше изменить "глобальные" на "которые попадут в продакшн"

В конце раздела о CSS:

Подробнее об этом и других багах, возникающих при работе с флексами, можно прочитать на Flexbugs, перевод 
материала на русский здесь.

Ссылка на русскоязычный материал не работает (это просто свободный домен на данный момент). Я погуглил свежие материалы на эту тему, но ничего раньше 2015 года не нашел – ссылка на материал с css-live.

Можно приложить ссылку на вышеупомянутый материал, либо вовсе убрать текст о русскоязычной версии.

В стандартах ничего не говорится о том, какие кавычки используются в CSS, одинарные или двойные, можно было бы добавить это в "Общие требования".

Мне кажется не совсем точно указано п.8 определение для элемента. Footer может использоваться не только как подвал страницы, а также как нижний колонтитул section, article и aside. Думаю стоит дополнить, т.к. это достаточно важно для придания семантики документу

CSS/generalRequirements.md

12.Имена:

использовать lower-case-hyphenated (то есть не mySuperAwesomeElement и не my_super_awesome_element);
имена должны отображать смысл, а не описание стилей ("loading" а не "big-yellow-spinny-thing");

Здесь еще можно добавить, что нельзя именовать классы с нумерацией: .icon-1, icon-2, icon-3... Мне кажется, такое часто встречается.

https://github.com/fullstack-development/front-end-best-practices/blob/master/CSS/README.md#4.4

Предлагаю:

1. Удалить явно лишнее быть.
2. Удалить тавтологию с должен.
3. Изменить окончание в слове самодостаточен на ным (быть каким?).

Как итог: "Каждый компонент должен иметь только явные зависимости, быть самодостаточным."

Если в библиотеке есть бага/нерешенный вопрос из-за которого в проекте приходится писать костыль, то обязательно нужно оставить ссылку на ишью в репозитории либы

Например, кейс который ща у Лехи Жмайлика случился с тем что нативные focus/blur не всплывают, а у реакта какого-то фига всплывают (и эта штука висит с 2016 года) facebook/react#6410 (comment)

Я читала, что хорошей практикой считается вложенность селекторов не больше двух уровней, т.к. большая вложенность усложняет читабельность и поддержку кода.

Неправильно. Вложенность больше двух уровней

.block {
  display: block;

  .description {
    font-size: 14px;

    .title {
      font-size: 16px;
    }
  }
}

Правильно. Псевдоэлменты, псевдоселекторы, родственные и соседние селекторы не влияют на вложенность.

.checkbox__input:checked ~ .checkbox__label::before {   
  border-color: #3D4975;
}

Мне кажется будет удобнее прикладывать ссылку в ишью стражеров на конкретный пункт.

Проблемы

1. Изображения установленные через background не индексируются.
2. Теряем семантику.
3. CSS cвойство object-fit которое может дать изображению img поведение как при background-size: cover нуждается в установке ширины и высоты, что противоречит требованию.

Варианты решения

1. Требование мы можем:
   1.1. Расширить, добавив информацию о том как быть в тех или иных ситуациях.
   1.2. Сократить, на пример - Избегайте действий нарушающие пропорции изображений.
   1.3. Убрать требование вовсе.

2. Вне зависимости от того что было выбрано в пункте 1, предлагаю:

   • Добавить в карту развития jun1/css: Что делает свойство object-fit?
   • Перенести с карты развития jun3/css вопрос Когда стоит использовать тег img, а когда background-image? в jun1/html или css, так как без знания когда и как подключать изображения знания про object-fit и прочие рекомендации будут менее эффективны. Учитывая то, как часто перед нами стоит выбор img или background-image это надо знать уже на позиции jun1.

Результаты Can I use. Поддержка большинством передовых браузеров началась с 2013-14 годов.

front-end-best-practices/CSS/bem.md

Нарушается инкапсулияци

CSS/generalRequirements.md

4. Все правила должны быть разбиты на разные файлы по страницам и блокам, каждый файл не должен быть длинее чем 1000 строк;

Здесь можно было бы еще дополнить, что каждый блок должен лежать в своей папке, и папки блоков нельзя вкладывать друг в друга.

Почему бы не добавить стандарт, добавляющий регламентацию css свойства z-index?

Схема, которую нашел:

• 0-9 - в пределах компонента;
• 10-19 - для всплывающих менюшек, подсказок и т.д.;
• 20-25 - для выезжающих меню, модалок и т.д.;
• для сторонних плагинов добавлять обертки с меньшим z-index.

Что думаете?

Предлагаю вынести некоторые пункты HTML стандартов в один: "Прогонять страницы через валидатор".

Решаемые проблемы:

• уплотнится структура стандартов, что упростит запоминание;
• процесс поиска многих ошибок будет частично автоматизирован;
• валидатор также сообщает и о ошибках, не отображенных в текущих стандартах: <input> внутри <button> или <a>.

Пункты стандартов, которые проверяет валидатор:

• не вставлять блочные элементы внутрь инлайновых;
• начинаем новый .html файл с <!DOCTYPE html>;
• самозакрывающиеся теги;
• изображения должны содержать alt;
• не допускать вложенные формы <form>.

P.S.: расширение позволяет прогонять страницы локально.