Separate test runner and other imrovements

[danny0838]

As explained in the commit messages.

[danny0838]

Is there still some problem with these commits? It should be OK to merge this before #54 and #56, which I can rebase them afterwards.

[tabatkins]

Nope, it's purely been a matter of me not having the time to review them.

[danny0838]

Rebased on top of #59.

[danny0838]

@tabatkins I'm wondering if there's still any plan to continue development on this parser. Since it has been halted for over a year.

As a developer, I’m in need of a spec-compliant CSS parser that can safely handle CSS rewriting, especially in edge cases. Ideally, I’d like to use an existing, well-maintained parser rather than building one from scratch.

I've tried several popular parsing libraries like postcss, but unfortunately they don’t meet my requirements. Most of them implement their own tokenization and parsing logic, which can diverge from the CSS spec. Additionally, they often enforce strict error handling, throwing exceptions on invalid CSS. In contrast, I need a parser that can recover gracefully and perform minimal error repair during parsing.

That said, I’ve noticed some limitations in this project that may make it less suitable for my use case:

1. Reproducible parsing: I'm working on a CSS rewriter that needs to preserve as much of the original source text as possible — including whitespace, line breaks, and comments — in order to safely rewrite only specific parts, like URLs.
   However, this parser corrently removes such information according to the spec. Additionally, characters such as linefeeds, control characters, and bad surrogate pairs are also eliminated during the preprocess step.
   I'd have to rewrite the tokenizer/parser to add option(s) to allow them to record the bound source code of each tokens, and add comment tokens to preserve such information when desired. Some of my recent PRs are for this.

2. ES6 module support: These days, ES6 modules are widely preferred for JavaScript projects. They’re easier to analyze, test, and bundle into other formats like IIFE, UMD, minified, or polyfilled builds. It's also fairly easy to use directly in a modern browser (Chromium >= 61, Firefox >= 60).

I'd really appreciate your thoughts on both points. The second one seems fairly easy to implement if you're in agreement. The first may require more discussion and design considerations. If this project isn’t intended to support such extended use cases, I may need to fork it or build something custom. That said, I hope the spec can evolve in a way that accommodates these types of real-world usage scenarios (e.g., by allowing comment tokens or preserving source information). Otherwise, developers may be forced to rely on non-spec-compliant parsers, which undermines the goal of having a shared, universal standard.