You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea behind superhtml is great, the library part is currently completely unusable without lots of hacks to decouple it from the zine usage.
I was hoping this issue could be a starting point to get a roadmap to a usable independent library.
The text was updated successfully, but these errors were encountered:
Documentation is definitely missing and there's some polish work I still need to do to make it easier to integrate with SuperHTML, but it has absolutely zero dependency on Zine.
The library is designed to have the host application define the semantics of what is available to the user, so yes, in the case of Zine it uses Zine's logic, but you are supposed to create a new evaluation context tailored to your use case.
More specifically, most of the personalization is not directly used by SuperHTML, but it's actually passed down to Scripty, which is the component most directly affected by this design.
As an example, in Zine I have $page that represents the current page being rendered. If a webserver wanted to use SuperHTML as the templating language, it would probably want to have something else, like $request and $user. In that case it's the host application's (ie the webserver) responsibility to define what those things should be and which builtin functions they should expose.
The idea behind superhtml is great, the library part is currently completely unusable without lots of hacks to decouple it from the zine usage.
I was hoping this issue could be a starting point to get a roadmap to a usable independent library.
The text was updated successfully, but these errors were encountered: