(meta) resolve javascript, html and css packaging

[einars]

Someone expressed a need and wish to port the beautify-html and beautify-css to python, so do we declare "yes, yes, we do support basic html and css formatting" now and consolidate the apis?

[bitwiseman]

I've filed separate issues for the porting. What did you mean by "consolidate the apis"?

[einars]

We have the initial js_beautify, and style_html and css_beautify added later, powered by magic and unburdened by tests, each taking different-ish options — seems chaotic.

[evocateur]

I feel like the HTML and CSS beautifiers should be a separate project. They are certainly reminiscent of a particular version of the JS API they were copied/adapted from, but they are not in my mind "spiritual equals" under the rubric of a JS beautifier. They were contributed, accepted graciously, but as noted, unburdened by tests and scarcely updated since addition.

I made an effort to at least document the random options whilst developing the node CLI. They are indeed very chaotic, which lends weight in my mind to splitting them out into a separate project. Perhaps, if there is interest, a "meta-project" could be created that provides all three at once (front-end-beautifier or somesuch).

[bitwiseman]

Yeah, it is a bit confusing to have them packaged into the same project.

It doesn't even have to be a meta-project, it could just be html-beautify, which includes handling of inline css and depends on js-beautify for handling inline javascript.

At the same time, jsbeautifier.org, which is contained in the gh-pages branch, depends on the html beautifier while beautify.js does not. If we were to split html and css out, it would make sense to also break out the jsbeautifier.org code into a separate repository to avoid a confusing dependency graph.

[bitwiseman]

@einars - Any opinion here?