Various changes from KA's fork: upstream?

[pamelafox]

We've been using slowparse at KA for the last three years, and have been slowly adding more features to our fork of it. You can see the diff here:
https://www.diffchecker.com/J4JJcWF2

I'm wondering whether this project is still active, and if so, if you'd like any of those changes upstream.

Ours has these new warnings that help guide people to better HTML/CSS:

• NO_DOCTYPE_FOUND (warning)
• HTML_NOT_ROOT_ELEMENT (warning)
• OBSOLETE_HTML_TAG (warning)
• INVALID_URL (warning)
• UNKNOWN_CSS_PROPERTY_NAME (warning, now distinguished from the INVALID error)
• IMPROPER_CSS_VALUE (warning, spacing issue in color properties)

Ours also has a more restrictive environment, with the following as errors:

• ELEMENT_NOT_ALLOWED (error, for forbidden tags)
• EVENT_HANDLER_ATTR_NOT_ALLOWED (error)
• JAVASCRIPT_URL_NOT_ALLOWED (error)

We also parse for JS errors with esprima.

Would it make sense to go through the effort to create a PR for any of these changes? Thanks!

[Pomax]

If you've added more functionality and are actively using it, it might actually make more sense for KA to adopt the project and become the authoritative source for new versions. It would be cool if the "more restrictive than technically required for legal HTML5" options could be turned on/off with a config object if that's not already the case, so that people can keep using your version of slowparse in their own projects.

Does that sound reasonable @flukeout @humphd @jessevondoom?

[humphd]

@pamelafox I really appreciate what Khan Academy has done with slowparse, and that you're taking the additional step to figure out whether upstreaming this work makes sense. I also agree with @Pomax that it probably makes the most sense for you to become the stewards of this project, given your investment and ongoing use of the code.

I don't speak for Mozilla, but I think that it's great to see slowparse finding a stable home in Khan Academy, with its shared vision for the purpose of what we built.

As far as I'm concerned, having your fork become the base repo makes the most sense.