Html5-boilerplate: Рассмотрите возможность использования HTMLLinter?

Как будут выбираться используемые правила? Некоторые стандартные правила являются личными предпочтениями. Например:

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-double-quotes оба являются совершенно допустимым HTML5, и я не думаю, что этот шаблон должен выбирать, какой стиль должен быть по умолчанию.

https://github.com/yaniswang/HTMLHint/wiki/Tag-self-close оба являются действительными HTML5, и последний на самом деле является более современным способом сделать это, поскольку предыдущий для XHTML и разрешен в HTML5 для обратной совместимости. при переходе с XHTML на HTML5, насколько мне известно.

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-not-empty оба действительны, и последнее - то, что использует большинство людей, но это считается плохим способом.

Многие из этих правил сомнительны и могут привести к тому, что части шаблона будут отмечены как ошибки или предупреждения. В связи с этим я против добавления этого и предпочитаю оставить такие настройки на усмотрение разработчика и не связывать их с этим проектом. Может быть, добавить в документы раздел HTML-линтера и дать ссылки на разные линтеры?

@quantumpacket Как вы упомянули tag-self-close всегда есть хоть какое-то оправдание для выбора одного перед другим, и не здесь ли сообщество может взвесить так же, как они могут над содержимым шаблона? Там, где нет оправдания, мы просто не добавляем это правило. Для справки, если мы посмотрим на все стили кода для JS https://github.com/rcorp/standard-project-structure/issues/6, особенно на AirBNB, мы увидим, что существует множество правил, но каждое из них имеет рассуждения, которые разработчик оценит.

Я полностью понимаю вашу точку зрения, но это всего лишь правила. Те, которые мы не выбираем, не применяются. Так что это может быть очень снисходительный подход. и шаблон для разработчиков для добавления / удаления правил из .htmlhintrc

@ gaurav21r Извините, что позволил этому задержаться. Думаю, это была бы хорошая идея. (Вы хотели предложить такую ​​помощь с PR? Я пока отмечу, что эта помощь нужна.)

Что касается того, какие значения выбрать, отправная точка будет видна из самого проекта. В случае с примерами @quantumpacket shared - мы используем двойные кавычки, используем пустые атрибуты и не закрываем сами себя. Оттуда, я уверен, у людей будет свое мнение.

@roblarsen Мы хотели бы внести свой вклад в PR. Мы уже выбрали хорошую стартовую базу для набора правил. https://github.com/rcorp/standard-project-structure/issues/13

Его используют несколько больших организаций. Я посмотрю, соответствует ли он шаблону и не слишком ли он самоуверен. Остальное мы можем обсудить в самом PR!

Есть ли прогресс по этому вопросу?

@ gaurav21r Есть обновления? Если нет, то кто-нибудь еще хочет нанести удар по этому поводу?

@roblarsen Если случится так, что @ gaurav21r не сможет продолжить, я буду счастлив это сделать.

@AlexxNica звучит хорошо. Мы всегда любим помощь.

Извините за очень поздний ответ! @roblarsen @AlexxNica Постараюсь сделать это до 15 числа. Если нет, буду рад помочь кому угодно!

без проблем!

15-е пришло и прошло! Это открыто для всех, кто хочет попробовать!

Мы уверены, что HTMLHint - лучший вариант?

@AlexxNica У меня нет опыта в этом

Нам нужно хорошенько рассмотреть это, прежде чем добавлять код в проект. Прежде чем предпринимать какие-либо действия, необходимо убедиться:

· Достаточно ли это полезно, чтобы оправдать необходимость внедрения?
· Легко ли отправлять и обслуживать?
· Проверялось ли это кем-то / нами?
· Видим ли мы реальные улучшения по сравнению с реальной моделью?
· Провели ли мы тесты для нашего кода, чтобы увидеть, не нужно ли нам ничего менять, чтобы соответствовать требованиям анализатора? (чтобы пользователи не сталкивались с большим количеством ошибок на экране, чем может отобразить их монитор)
· Будет ли у него долгосрочное присутствие? (Я не думаю, что это хорошая идея реализовать что-то, что не будет существовать в течение длительного времени)
· В чем простота использования?

@roblarsen Можете ли вы изменить надписи на этом? Я думаю, что " awaiting feedback " и (возможно) " HTML " были бы более подходящими.

Я добавил те. Это все еще требует помощи и остается новой функцией. Я не собираюсь касаться этого лично, так что сообществу определенно придется работать над этим.

Думаю, здесь есть два вопроса:

• Должны ли мы включать .htmlhintrc в папки src / dist для пользователей?
  HTMLHint на самом деле предназначен только для использования для линтинга полных, скомпилированных HTML-страниц (например, по умолчанию он проверяет, что каждый файл имеет тег <title> поэтому он не подходит для большинства языков на стороне сервера или языков шаблонов. Поэтому Я думаю, что это имеет ограниченную ценность, так как многие пользователи используют Angular, React, PHP, ASP или языки шаблонов, такие как Liquid, где он либо выдаст много ошибок, либо не будет работать вообще. Пользователь может редактировать все правила, чтобы он не отображал ошибки но тогда такого рода поражение цели его включения. И всем пользователям потребуется установить плагин для своей IDE, чтобы иметь возможность использовать его. Я просто не думаю, что достаточное количество пользователей кодируют веб-страницы в чистом HTML без включения, чтобы гарантировать его включение (я лично использую HTMLHint только при кодировании электронных писем HTML - он отлично подходит для поиска ошибок) - и мы не включаем никаких файлов конфигурации JS или CSS linters / hinter.

• Должны ли мы включать HTMLHint в систему сборки для проверки ошибок?
  Да, я думаю, это может быть хорошей идеей. Наша система сборки в настоящее время использует Gulp, и для ее интеграции есть пакет NPM: https://www.npmjs.com/package/gulp-htmlhint. Я займусь этим в ближайшие несколько дней. Это позволит проверить наличие ошибок HTML при компиляции и может быть полезно для поиска проблем до развертывания сайта.

Неспособность использовать html-линтеры с языками шаблонов всегда мешала нам его использовать. React - это немного другая история, поскольку jsx можно эффективно использовать с ESLint.

Построение Linting кажется полезным для проекта, но не для конечного пользователя. Но это лучше, чем ничего, по крайней мере, это предотвратит случайные ошибки в исходном коде шаблона.

Кстати, не вижу причин использовать Gulp для таких тривиальных задач. Всегда проще и надежнее избегать дополнительных слоев для линтеров и вызывать их напрямую из npm test (см. Пример ).

ИМО, стоит держаться подальше от нестандартных инструментов.

Это похоже на то, что вы вообще не используете валидатор, и я говорю по опыту, поскольку на Bootstrap v4-dev они перешли на htmlhint, который в основном не обнаруживал никаких реальных ошибок.

Я предлагаю использовать официальный валидатор vnu.jar, даже если для этого требуется Java. У вас может быть сценарий-оболочка, который будет запускать его, если Java доступна.

Недавно я сделал аналогичное изменение в Bootstrap (см. Https://github.com/twbs/bootstrap/pull/24149), потому что меня раздражал тот факт, что у нас практически не было никакой проверки с помощью htmlhint.

К сожалению, HTMLHint больше не поддерживается активно (https://github.com/yaniswang/HTMLHint), и, как говорит @XhmikosR, есть проблемы, поэтому я голосую за закрытие этой проблемы.

Сверчки + вышеперечисленное