User story for linting html in yew

[WorldSEnder]

Lint explanation

A macro introduced by our library introduces some new syntax that feels like html, but emits expressions resulting in rust data structures. We want to make uses aware of several bad practices in their "html".

Example code

html! {
   <>
    <a>{ "I don't have a href attribute" }</a>
    <a href="#">{ "I have a malformed href attribute" }</a>
    <a href="javascript:void(0)">{ "I have a malformed href attribute" }</a>
    <img src="img.jpeg"/>
    </>
}

Example output from our current setup:

warning: All `<a>` elements should have a `href` attribute. This makes it possible for assistive technologies to correctly interpret what your links point to. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML#more_on_links
 --> tests/html_lints/fail.rs:5:10
  |
5 |         <a>{ "I don't have a href attribute" }</a>
  |          ^

warning: '#' is not a suitable value for the `href` attribute. Without a meaningful attribute assistive technologies will struggle to understand your webpage. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML#onclick_events
 --> tests/html_lints/fail.rs:8:17
  |
8 |         <a href="#">{ "I have a malformed href attribute" }</a>
  |                 ^^^

warning: 'javascript:void(0)' is not a suitable value for the `href` attribute. Without a meaningful attribute assistive technologies will struggle to understand your webpage. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML#onclick_events
  --> tests/html_lints/fail.rs:11:17
   |
11 |         <a href="javascript:void(0)">{ "I have a malformed href attribute" }</a>
   |                 ^^^^^^^^^^^^^^^^^^^^

warning: All `<img>` tags should have an `alt` attribute which provides a human-readable description
  --> tests/html_lints/fail.rs:14:10
   |
14 |         <img src="img.jpeg"/>
   |          ^^^

Notes

The current setup works only on nightly, and works by using proc_macro_error::emit_warning with a customized message. This serves its part for linting, but not without downsides. For one, it can't easily turned off (see yewstack/yew#2360). That is, a lint should interoperate with #[allow()] and #[deny()], which should work hierarchically, on a block-, function- or module-scope. We would be able to come up with unique names without problem.

Bonus points if the possible lints would show up somewhere in the documentation, so we don't have to keep a section in sync manually - or (easier to implement, probably?) if there's a sort of meta-lint about undocumented lints.