docs(rules): usage argumentation
See original GitHub issue1. Summary
It would be nice, if HTMLHint documentation will contain arguments, why HTMLHint users must use specific rules.
2. Argumentation
“Must” in The script tag can not be used in head.
, Id and class value must meet some rules: underline, dash, hump.
is not argument. The documentation does not show the reasons. Users should know “Why must”?
3. Example of expected behavior
As for CSSLint wiki. Examples:
adjoining-classes
rule use, because Internet Explorer 6 doesn’t support adjoining classesfallback-colors
, because Internet Explorer 8 doesn’t supportrgba()
hsl()
orhsla()
HTMLHint wiki doesn’t contain similar argumentation.
4. Specific rules
At first, I want to know argumentation for these rules.
4.1. head-script-disabled
Most popular Stack Overflow answer with 1608 stars at March 2019:
The current state-of-the-art is to put scripts in the
<head>
tag and use theasync
ordefer
attributes. This allows your scripts to be downloaded asap without blocking your browser.
Script tag must be used in head.
4.2. id-class-value
BEM — the most popular CSS methodology use underlines and dashes both. Example from BEM quick-start:
<!-- `search-form` block -->
<form class="search-form">
<!-- `input` element in the `search-form` block -->
<input class="search-form__input">
<!-- `button` element in the `search-form` block -->
<button class="search-form__button">Search</button>
</form>
Users don’t need use underlines or dashes.
5. Do not offer
Yes, I know, that I can enable/disable/modify specific HTMLHint rules. My question not about it.
Thanks.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (2 by maintainers)
Top GitHub Comments
@Kristinita Also some parts has maybe changed since your initial post 🙂
https://github.com/htmlhint/HTMLHint/blob/beta/src/core/rules/id-class-value.ts#L12
e.g. we can define a regex to support
bem
notation@Kristinita Thank you very much and please be patient with us We are currently working intensively on the release of version 1.0.0 When we publish it, we also have new documentation
Would be great if you could watch the new documentation and contribute after the 1.0.0 release