Enforce beautify standards and validate code to catch mistakes

[ZoeBijl]

From @MichielBijl on January 13, 2016 0:8

As noted by Karl Groves: we should enforce beautify standards and require that all PR's pass the validity checks.

As this only affects the practices, I propose we add a separate README.md in there (as to not litter the main README).

@jnurthen noted that because we need to write stuff that is ARIA 1.1/2.0 it might not validate. Still, validating the code to catch other error should be mandatory.

Copied from original issue: w3c/aria#202

[ZoeBijl]

Related issues: w3c/aria#88, w3c/aria#95, and w3c/aria#131

[ZoeBijl]

From @jnurthen on January 13, 2016 1:29

What do you mean by validate? We have requirements to use aria 1.1 features which may not be implemented in any validator.

[ZoeBijl]

Good point. Still, if you go through the code in w3c/aria#174 you'll see a lot of errors not related to aria (1.1). All current examples now actually validate in the nu validator.

But we should allow for errors and warnings related to ARIA 1.1/2.0.

[ZoeBijl]

@jnurthen I started on a README and EditorConfig file. I've included an exception for warnings/errors related to future ARIA stuff. Does this seem fair to you?

[ZoeBijl]

I have added research on the use of js-beautify.

[ZoeBijl]

Part of this was an EditorConfig file, that is now provided.

[ZoeBijl]

From @handcoding on April 7, 2016 16:47

For @MichielBijl and others—

On the subject of the EditorConfig file, can I make a request for an indent_size that’s larger than 2?

For those of us with spatial-acuity issues (like me), an indent size of only 2 can make it hard to tell which lines of code share the same indention level. Would anyone be open to an indent size of, like, 4-ish?

[ZoeBijl]

@handcoding sorry, I wasn't aware of that. I don't mind the 4 spaces indent. I prefer 2 spaces, but if 4 spaces is easier to read for more people; I'm fine with it.

[ZoeBijl]

@handcoding: I have set indent_size to 4 in 20cfaa5

I still need to indent the entire document to this new format, but haven't come around to that.

[mcking65]

Closing this issue based on discussion in August 15, 2016 meeting and the work that is happening in issue #12.