Update documentation of eslint plugin rules

Author: utarwyn

eslint-plugin/docs/rules/avoid-css-animations.md

@@ -4,28 +4,38 @@
 
 <!-- end auto-generated rule header -->
 
-## Rule Details
+## Why is this an issue?
 
-This rule aims to limit the usage of all types of CSS animations which can be very costly in terms of CPU and memory.
-They must only be used when they are indispensable and should be limited to the CSS properties `opacity` and `transform`
-with it's associated functions : `translate`, `rotate` and `scale`. You can also inform the navigator of upcoming
-changes with the `will-change` instruction for more optimization.
+CSS animations, especially complex or continuous animations, can impact the performance of a web page.
+They may consume significant browser resources, leading to slower page rendering and decreased user experience,
+particularly on devices with limited processing power.
 
-## Examples
+On mobile devices, constant animations can contribute to increased power consumption, affecting the device's battery
+life.
+Limiting the usage of CSS animations helps in creating a more energy-efficient and mobile-friendly user experience.
 
-Examples of **non compliant** code for this rule:
+```jsx
+<div style={{ border: "1px solid black", transition: "border 2s ease" }} /> // Non-compliant
+```
 
-```js
-<div style={{ border: "1px solid black", transition: "border 2s ease" }}/>
+```jsx
+<div style={{ border: "1px solid black" }} /> // Compliant
 ```
 
-Examples of **compliant** code for this rule:
+It's important to note that while limiting animations is generally advisable for certain scenarios, there are cases
+where animations contribute positively to the user experience and overall design.
+In this case they should be limited to the CSS properties `opacity` and `transform` with it's associated
+functions : `translate`, `rotate` and `scale`.
+You can also inform the navigator of upcoming changes with the `will-change` instruction for more optimization.
 
-```js
-<div style={{ border: "1px solid black" }}/>
-```
+## Resources
+
+### Documentation
+
+- [CNUMR best practices](https://github.com/cnumr/best-practices/blob/main/chapters/BP_039_en.md) - Avoid JavaScript /
+  CSS animations
 
-## Further details
+### Articles & blog posts
 
-This recommendation is made by the
-CNUMR: [Avoid JavaScript / CSS animations](https://github.com/cnumr/best-practices/blob/main/chapters/BP_039_en.md)
+- [web.dev - Animations and performance](https://web.dev/articles/animations-and-performance)
+- [web.dev - How to create high-performance CSS animations](https://web.dev/articles/animations-guide)

eslint-plugin/docs/rules/avoid-high-accuracy-geolocation.md

@@ -4,46 +4,45 @@
 
 <!-- end auto-generated rule header -->
 
-## Rule details
+## Why is this an issue?
 
-This rule aims at reducing CPU consumption by telling the device to use a less accurate yet more eco friendly geolocation, when geolocation API is used.
+High-precision geolocation typically requires more power from the device's GPS hardware.
+By requesting less accurate geolocation, you can reduce the power consumption, leading to extended battery life, which
+is crucial for mobile devices.
 
-## Examples
-
-Examples of **non compliant** code for this rule:
+Obtaining highly accurate geolocation often involves more complex calculations and processing, which can increase CPU
+usage.
+If the application or service does not critically require pinpoint accuracy, opting for a less accurate geolocation can
+help minimize the strain on the device's CPU.
 
 ```js
-var options = { enableHighAccuracy: true, timeout: 5000, maximumAge: 0 };
-function success(pos) {
-  console.log(pos.coords);
-}
-
-function error(err) {
-  console.warn(err);
-}
-
-navigator.geolocation.getCurrentPosition(success, error, options);
+var options = { enableHighAccuracy: true, timeout: 5000, maximumAge: 0 }; // Non-compliant
+navigator.geolocation.getCurrentPosition(
+  (pos) => console.log(pos),
+  (err) => console.warn(err),
+  options
+);
 ```
 
-Examples of **compliant** code for this rule:
+In these examples, the enableHighAccuracy option is set to false (the default), indicating that the application prefers
+lower-accuracy geolocation to conserve resources:
 
 ```js
-// enableHighAccuracy is false by default, so not declaring it is correct
-function success(pos) {
-  console.log(pos);
-}
-navigator.geolocation.getCurrentPosition(success);
+navigator.geolocation.getCurrentPosition((pos) => console.log(pos)); // Compliant by default
 ```
 
 ```js
-var options = { enableHighAccuracy: false, timeout: 5000, maximumAge: 0 };
-function success(pos) {
-  console.log(pos.coords);
-}
+var options = { enableHighAccuracy: false, timeout: 5000, maximumAge: 0 }; // Compliant
+navigator.geolocation.getCurrentPosition(
+  (pos) => console.log(pos),
+  (err) => console.warn(err),
+  options
+);
+```
 
-function error(err) {
-  console.warn(err);
-}
+## Resources
 
-navigator.geolocation.getCurrentPosition(success, error, options);
-```
+### Documentation
+
+- [Mozilla Web Technology for Developers](https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/getCurrentPosition) -
+  getCurrentPosition() method

eslint-plugin/docs/rules/limit-db-query-results.md

@@ -4,20 +4,37 @@
 
 <!-- end auto-generated rule header -->
 
-## Rule Details
+## Why is this an issue?
 
-This rule aims at reducing CPU consumption by limiting the number of returns for a single SQL query.
+SQL queries often involve processing large amounts of data, and fetching a large number of rows can consume significant
+CPU resources.
+By limiting the number of rows returned, you reduce the amount of processing that needs to be done by the database
+engine, which in turn lowers CPU consumption.
 
-## Examples
+Transmitting a large number of rows over a network can be resource-intensive.
+By restricting the result set size, you reduce the amount of data that needs to be transferred between the database and
+the application, improving network efficiency.
 
-Examples of **non compliant** code for this rule:
+If you store data about customers, you certainly don’t need to retrieve information of all at once, because the larger
+the table will be, the more elements the query will return.
 
 ```js
-const query = "SELECT * FROM clients";
+const query = "SELECT * FROM customers"; // Non-compliant
 ```
 
-Examples of **compliant** code for this rule:
+It may therefore be a good idea to limit the results and use pagination, for example.
 
 ```js
-const query = "SELECT columns FROM table_name FETCH FIRST number ROWS ONLY";
+const query = "SELECT id,name,email FROM customers FETCH FIRST 10 ROWS ONLY"; // Compliant
 ```
+
+## Resources
+
+### Documentation
+
+- [MySQL Reference Manual](https://dev.mysql.com/doc/refman/8.0/en/limit-optimization.html) - LIMIT Query Optimization
+- [PostgreSQL: Documentation](https://www.postgresql.org/docs/current/queries-limit.html) - LIMIT and OFFSET
+
+### Articles & blog posts
+
+- [Query Performance Optimization](https://www.oreilly.com/library/view/high-performance-mysql/9780596101718/ch04.html)

eslint-plugin/docs/rules/no-empty-image-src-attribute.md

@@ -4,23 +4,50 @@
 
 <!-- end auto-generated rule header -->
 
-## Rule Details
-
-This rule aims to prohibit the usage of <img/> without specifying its source attribute because it causes extra and unnecessary http requests. This rule is build for the [react library](https://react.dev/) and JSX.
+## Why is this an issue?
+
+When the src attribute is missing, some browsers may still attempt to make a request to the current URL (the base URL of
+the document) in an attempt to fetch the image.
+This can lead to unnecessary server requests, impacting performance and potentially causing errors.
+
+Proper use of the src attribute is essential for web accessibility.
+Screen readers and other assistive technologies rely on valid image sources to provide meaningful information to users
+with disabilities.
+A missing src attribute can result in confusion and hinder accessibility.
+
+```jsx
+return (
+  <>
+    <img src="" /> // Non-compliant
+    <img /> // Non-compliant
+  </>
+)
+```
 
-## Examples
+The HTML specification requires the src attribute for the <img> element, and not including it may lead to non-compliance
+with standards.
 
-Examples of **non compliant** code for this rule:
+```jsx
+import myLogo from "./logo.svg"
 
-```js
-<img src='' />
-<img/>
+return (
+  <>
+    <img src="./logo.svg" /> // Compliant
+    <img src={myLogo} /> // Compliant
+  </>
+)
 ```
 
-Examples of **compliant** code for this rule:
+This rule is build for [React](https://react.dev/) and JSX.
+
+## Resources
+
+### Documentation
+
+- [Mozilla Web Technology for Developers](https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Images_in_HTML) -
+  Images in HTML
+
+### Articles & blog posts
+
+- [Empty image src can destroy your site](https://humanwhocodes.com/blog/2009/11/30/empty-image-src-can-destroy-your-site/)
 
-```js
-import imgSvg from './img.svg'
-<img src='./img.svg' />
-<img src={imgSvg} />
-```

eslint-plugin/docs/rules/no-import-all-from-library.md

@@ -4,11 +4,16 @@
 
 <!-- end auto-generated rule header -->
 
-## Rule details
+## Why is this an issue?
 
-This rule aims to reduce weight of programs by using only needed modules. Many libraries export only one module by
-default, but some of them are exporting ES modules or submodules. We should use them to select more precisly needed
-modules and avoid unnecessarily overloading files weight.
+Including only the required modules decreases the overall size of the program.
+This, in turn, reduces the amount of memory and storage space needed to run and store the application.
+This is especially critical in environments with limited resources, such as on mobile devices or in web applications
+where bandwidth and download times matter.
+
+Smaller programs generally have better runtime performance.
+Reducing the number of unnecessary modules minimizes the amount of code that needs to be interpreted or compiled,
+leading to faster execution and improved overall performance.
 
 ## Options
 
@@ -32,7 +37,8 @@ module.exports = {
 
 ## Examples
 
-Examples of **non-compliant** code for this rule:
+**Example with the well-known [lodash](https://lodash.com/) library, if you only need
+`isEmpty` method.**
 
 ```js
 // Example with lodash
@@ -73,3 +79,14 @@ Size of your bundle, if you use only the "isEmpty" method:
         * isArrayLike.js - 830 B
         * ...
     * index.js - 110 B
+
+## Resources
+
+### Documentation
+
+- [Mozilla Web Technology for Developers](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) -
+  import
+
+### Articles & blog posts
+
+- [Importing modules in JavaScript, are we doing it right?](https://dev.to/dianjuar/importing-modules-in-javascript-are-we-doing-it-right-nc)

eslint-plugin/docs/rules/no-multiple-access-dom-element.md

@@ -4,23 +4,40 @@
 
 <!-- end auto-generated rule header -->
 
-## Rule details
+## Why is this an issue?
 
-This rule aims to reduce DOM access assigning its object to variable when access multiple time. It saves CPU cycles.
+Accessing the Document Object Model (DOM) is a relatively expensive operation in terms of performance.
+Each time you access the DOM, the browser needs to traverse the document tree to find the requested element.
+By assigning the DOM object to a variable when accessed multiple times, you avoid redundant traversals, leading to
+improved performance.
 
-## Examples
+Assigning the DOM object to a variable not only improves performance but also enhances code readability.
+It makes the code more concise and self-explanatory.
+Developers reading the code can understand that the variable holds a reference to a specific DOM element, and its
+subsequent use is likely for multiple operations.
 
-Examples of **incorrect** code for this rule:
+Here's an example in JavaScript to illustrate this rule:
 
 ```js
-var el1 = document.getElementById("block1").test1;
-var el2 = document.getElementById("block1").test2;
+const width = document.getElementById('block').clientWidth;
+const height = document.getElementById('block').clientHeight; // Non-compliant
 ```
 
-Examples of **correct** code for this rule:
-
 ```js
-var blockElement = document.getElementById("block1");
-var el1 = blockElement.test1;
-var el2 = blockElement.test2;
+const blockElement = document.getElementById('block'); // Compliant
+const width = blockElement.clientWidth;
+const height = blockElement.clientHeight;
 ```
+
+In the first example, getElementById is called twice, potentially resulting in two separate traversals of the DOM tree.
+In the second example, the DOM element reference is cached in the `blockElement` variable, and subsequent property
+accesses use this cached reference.
+
+## Resources
+
+### Documentation
+
+- [CNUMR best practices](https://github.com/cnumr/best-practices/blob/main/chapters/BP_054_en.md) - Reduce DOM access
+  via JavaScript
+- [Mozilla Web Technology for Developers](https://developer.mozilla.org/en-US/docs/Learn/Performance/JavaScript#tips_for_writing_more_efficient_code) -
+  Tips for writing more efficient code