Add a way to customize CSSLint rules

[obenland]

Maybe this should be part of a bigger discussion about finding a way to customize certain parts of CodeMirror. I was going back and forth between individual customization files like I'm proposing in this PR, and one combined file, something like wp-codemirror.js or something.

We should also go through the rules CSSLint comes with and see which ones we want to keep or not. /cc @melchoyce

Fixes #26.

[melchoyce]

Thanks @obenland. Do you think I should start a new issue to discuss which rules we want to include?

[obenland]

I think we can do that here and then add those in

[melchoyce]

Cool. Thinking we should actually be pretty conservative about which rules we're including. I'm thinking...

• ✅ Parsing errors should be fixed
• ✅ Possible Errors
• ❌ Compatibility
• ❌ Performance
• ❌ Maintainability & Duplication
• ✅ Accessibility
• ❌ OOCSS

[obenland]

@westonruter Given how many rules we remove here, I wonder if it would be better to create a custom build of csslint than to have the default script add all the rules and us the overwriting them later on? I'd have one ready to go.

[westonruter]

@obenland My only concern there would be if someone would like to enable those rules via filtering, but if they aren't part of the build then they wouldn't be able to do it. How is a custom build made?

[obenland]

How is a custom build made?

I followed the instructions here, removed the unwanted rule files from src/rules, and ran grunt concat. The resulting file can then be found in dist.

[westonruter]

I'm trying an alternate approach to defining the rules in af724cc. This could allow us to use PHP to filter the rules that the user wants. It's a bit hacky in how it CSSLint doesn't have a removeRule method, so it has to clear all of them and then re-add the ones that we want.

Thoughts?

There are still a few warnings shown in the style.css for Twenty Seventeen, but there are far fewer than before.

[westonruter]

Maybe we could pass the list of rules in the options object that gets passed to CodeMirror, but we could have a wp-code-editor wrapper script, with a wp.codeEditor.initialize( id, options ) wrapper that emulates wp.editor.initialize() for TinyMCE. The wp.codeEditor.initialize function could grab additional properties in options, like csslint-rules, and then configure CSSLint before initializing CodeMirror since the CodeMirror options doesn't allow for the list of rules to be defined.

[westonruter]

if we had a wp.codeEditor as well, this could provide an abstraction which would de-couple us from having to specifically support CodeMirror directly, and we could in the future switch to a different editor if we need to.

[westonruter]

And back to the note about being filterable, this could be part of the $options array which then later gets filtered theme_editor_codemirror_opts or plugin_editor_codemirror_opts, both of which could be simply a wp_code_editor_settings filter for parity with TinyMCE's wp_editor_settings filter.

[westonruter]

I'm working on the refactor to add the wp.codeEditor abstraction.