Add Severity Levels To Warnings

[openjck]

Upstream issue originally reported in mdn/YouShouldUse#34.

Quoting the first comment:

It's be nice not to moderate the tone of the comments when a user is using good progressive enhancement techniques. For example: a box-radius that isn't supported is probably not going to be a problem but lack of support for display: flex could be pretty catastrophic.

[anandthakker]

@openjck Yeah, this seems like a useful feature.

I'm wondering what the best approach would be here. As @mrmakeit brought up in the original issue, we'd need a mapping from feature to severity. This would be both subjective and possibly tough to maintain.

I guess that means it should be configurable, ideally with some sensible defaults. What do you think?

cc @stephaniehobson

[anandthakker]

Note to self/others: I wonder if there already exist any nice, long lists that could be used to bootstrap the 'sensible defaults' piece...

[openjck]

Good questions. I suppose layout properties (like box-sizing) are usually more important than presentational properties (like box-shadow) but it also depends on the situation. For example, there could be times when box-shadow is used to provide a very important visual cue.

Maybe something as simple as a property blacklist would do the trick. That would have downsides too, though.

[Flimm]

Here's an idea: introduce a special comment that's a hint for doiuse, just like Jshint and other linters use. Imagine code like this:

.callout {
    box-shadow: 3px 3px 5px 6px #ccc; /* ifsupported */
    border: 1px solid black;
}

To human readers, /* ifsupported */ tells us that the author is aware that the rule may get dropped, and that they find that acceptable. It also tells doiuse to not report this line.

I think that this is a better approach than attempting to design general rules that apply to all code and all use-cases.

I haven't put too much thought into whether the syntax /* ifsupported */ is the best. Ideally, it would match conventions used by other linters, it wouldn't be too hard on the eyes, and it would be instantly understandable by someone who is completely unfamiliar with doiuse.

[anandthakker]

@Flimm I like the idea of using comments to mark exceptions to the linting rules being used. However, I also think that the ability to configure rules more globally would still be really useful, since some features are much more likely to cause catastrophic problems than others (e.g. box-radius vs flex, from the initial comment)

[StefanSchwartze]

I'm also looking for such a feature! I would really like to have a severity system with maybe 3 steps, from 1 = Progressive Enhancement to 3 = Layout crashing. We could on the one hand prepare a rating system in this repo that is realized with a property for each feature (a severity property could include the number and a link to a source where a reason for that decision can be found) or on the other hand, this could be also part of the caniuse-db... what do you think could be the next step?

[anandthakker]

Interesting. You know, now that stylelint exists, it seems to me like this might be duplicating functionality that's already being handled much more systematically over there. I wonder if it would make sense to implement this as a stylelint plugin? (Disclaimer: I have done 0 research into styleling plugin authoring)

[StefanSchwartze]

Okay, stylelint seems to be a big thing that does a lot in style improvements, but did not try it out yet. I think I will have a better overview on this after some research also. In my opinion, an integration into caniuse-db seems the easiest way because doiuse anyway includes that data..