Automatically hide informative audits with score=1

[patrickhulce]

Summary
Informative audits have been in this unusual state for the past few years where "passing" must be notApplicable and any result in informative is considered "failing". I just made this mistake in a PR https://github.com/GoogleChrome/lighthouse/pull/13049/files#r707762173 and I know I'm not the first, having caught several in review as it's a very easy mistake to make.

We did this because informative audits do not pass a score to the LHR/report renderer so there's no signal on that end to move them into passed, but I see a few options to handle this better on the core side before an LHR is generated.

1. Force informative audits to explicitly return a notApplicable property. At the very least, this forces the developer to remember the importance of this boolean in audit impl and do the right thing more often. Also, require score: null.
2. Automatically consider score=1 for informative audits to be notApplicable
3. Add some new property/readd score to informative audit results to signal "passing" state.

Thoughts?

[connorjclark]

We're all leaning towards 1). @paulirish to add more thoughts (re: to renaming some things in renderer)

[paulirish]

1. first up, just declaring what these displayModes actually do… n/a: color gray + keep behind collapsed clump. informative: color gray + show to user along with displayed items. (non-passing and non-n/a audits)
   • our docs should clarify these, since you can't do both on the same audit.
2. showAsPassed is a bad name. The "rating" determines if the audit is GREEN which === 'passed'. showAsPassed should be includeInCollapsedPassingClump basically. (or keepBehindCollapsedClump). these names arent great, but.. dunno another way out.
3. calculateRating doesn't handle informative, but does handle N/A. _setRatingClass has to do a special thing for informative. Seems weird how these classes get set.
4. we call the "displayed" clump "failed" but informative is in there which is dumb. maybe... "problematic"? "displayed"?
5. hypothetically all n/a products could require a score:1 and all informative products require a score:0. perhaps that makes the association more clear?

---

1. Force informative audits to explicitly return a notApplicable property.

given the above, this proposal doesnt make sense to me.

1. Also, require score: null.

We could do my item 5 instead. Making the score real helps the developer rationalize things a bit more, but.. the null scores are useful to protect programmatic users from summarizing scores without looking at display modes... and we'd lose that.

6. Another idea.. rename 'informative' to 'applicable'. Clarifies the two are mutually exclusive.