Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pre- and post-processing plugins (could solve lots of issues) #118

Open
spacegangster opened this issue Oct 10, 2015 · 3 comments
Open

Pre- and post-processing plugins (could solve lots of issues) #118

spacegangster opened this issue Oct 10, 2015 · 3 comments

Comments

@spacegangster
Copy link

Hi! At first I'd like to say thanks for such a great library, this is definitely my greatest HTML building experience ever, far beyond PHP, Jade and Handlebars.

The context

There is a trend in the front end world to make pluggable CSS and HTML processing programs like PostCSS and PostHTML. Their handiness lies in their pluggability: the maintainer defines an API, while the user can easily write their own plugins that use that API. E.g. one great plugin for PostCSS is Autoprefixer, which automatically adds needed prefixes to the developer version of CSS making it suitable for a wide range of old browsers. There is also a great plugin for PostHTML -- posthtml-bem which eases the use of the BEM naming convention.

A humble idea (or question)

Maybe it is a stupid idea, but I think that pre-processing and post-processing plugins are doable in Hiccup, and they can solve at least two open issues: the one about unminified output (#65) and another one about safe HTML (#114). It will also make Hiccup much more extensible (and I'd say hail to BEM).
As far as I understand Hiccup, I think it can be organised in such way so that the user can register his own pre-processing and post-processing functions right now, there is no need to rewrite from scratch. Pre-processing is doable just by adding a new layer of root macros which can use passed pre-processing functions. These pre-functions will process the raw Clojure data structures, maybe there can be bindings for just-attributes-processors and just-body-processors. Post-processing can be done through a register of string transforming functions.

P.S. Of course, this is just an idea, and surely not a request. I'm very grateful for the amazing job you've done already.

@weavejester
Copy link
Owner

Pretty printing HTML certainly can be solved by post processing, though at the performance cost of re-parsing the HTML. There's no need for a special API to deal with that - you just wrap the final generated string of HTML in a function that formats it.

Escaping strings cannot be solved by pre or post processing, because there's no way of determining whether a string of HTML is deliberate or an injection.

@spacegangster
Copy link
Author

Escaping strings could be easier, if a user could define his own sugar, like "let's use the bang sign for denoting the need for escape":

[:!div.my-code-display "<script>alert('very injected script')</script"]
; -> [:div.my-code-display (escape "<script>alert('very injected script')</script")]

Pretty printing can be done through pre-processing at least to some degree. The user can start from injecting "\n", and progress to indentation with depth tracking.
Costlier post-processing can be useful for dev workflows.


The thing is that such approach will enable users to author their own plugins for Hiccup.

On the other hand -- escape, pretty-print and BEM are the only three applications that I can imagine for now.

@weavejester
Copy link
Owner

I don't think there's much difference between:

[:!span "<script></script>"]

And:

[:span (h "<script></script>")]

In general, functions are preferable to inventing special syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants