Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Produce HTML from S-Expressions

github.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Produce HTML from S-Expressions

#31

Post by tannhaeuser »

FYI in traditional SGML DTD-driven HTML parsing, "disabled" in
represents the attribute value rather than the attribute name. The value has to be declared in an enumeration and must be different from all other enumerated values (of other elements) for the parser to infer the attribute and emit canonical markup such as
In HTML, it just so happens that the attribute name in what the WHATWG HTML spec calls a "Boolean attribute" is always the same as the single allowed value. However, WHATWG managed to break that in the latest spec, allowing "until-found" as additional value for the "hidden" attribute [1].

[1]: https://sgmljs.net/docs/html230116.html

Re: Produce HTML from S-Expressions

#32

Post by vermilingua »

lelanthran wrote: post #13
sph wrote: post #10

Earlier quoted context omitted.

> Using `((class . "alert"))` does not provide any benefits over :class="alert". Of course it does. It is a s-exp, like everything else in this language, so it's just another list you can map, apply or otherwise transform. The keyword approach instead requires a weird incantation of (string-trim (cadr (string-split (keyword->string :class="alert") ?=)) ?") to extract the value from the attribute. For what benefit? If…

> If the goal is using s-exps, why not use s-exps for everything? My goal wasn't "Use s-expressions", it's "More readable and writable HTML trees." This isn't a Lisp interpreter either, TBH. There's plenty of those around and they require the user to use a Lisp implementation, and write Lisp code. map, string-trim, car, cadr etc are not required for s-expressions, they're required for Lisp.

If your goal wasn't "use s-expr" and it isn't a lisp interpreter, the tagline probably shouldn't be "Produce HTML from S-Expressions" and the project shouldn't be named "lisp-to-html"; it should be "Write HTML with parentheses".

Re: Produce HTML from S-Expressions

#33

Post by thom »

pgt wrote: post #29

Hiccup syntax for Clojure uses hash maps (curly braces) for attrs, e.g. `{:style {:background "red" :margin "1em"}}` See Reagent which uses Hiccup syntax: https://reagent-project.github.io/ (defn simple-component [] [:div [:p "I am a component!"] [:p.someclass "I have " [:strong "bold"] [:span {:style {:color "red"}} " and red "] "text."]])

Also just because it’s not shown here, IDs can be declared with tag#id syntax.

Re: Produce HTML from S-Expressions

#34

Post by lelanthran »

vermilingua wrote: post #32
lelanthran wrote: post #13

Earlier quoted context omitted.

> If the goal is using s-exps, why not use s-exps for everything? My goal wasn't "Use s-expressions", it's "More readable and writable HTML trees." This isn't a Lisp interpreter either, TBH. There's plenty of those around and they require the user to use a Lisp implementation, and write Lisp code. map, string-trim, car, cadr etc are not required for s-expressions, they're required for Lisp.

If your goal wasn't "use s-expr" and it isn't a lisp interpreter, the tagline probably shouldn't be "Produce HTML from S-Expressions" and the project shouldn't be named "lisp-to-html"; it should be "Write HTML with parentheses".

> If your goal wasn't "use s-expr" and it isn't a lisp interpreter, the tagline probably shouldn't be "Produce HTML from S-Expressions" and the project shouldn't be named "lisp-to-html"; it should be "Write HTML with parentheses".

You're right maybe it shouldn't be called "Lisp-ish".

But, the sources really are s-expressions with an additional ':' marker for attributes, just not Lisp s-expressions with the ':' marker.

So "Write HTML with parenthesis" would be less accurate than "Emit HTML from S-expressions".

Re: Produce HTML from S-Expressions

#35

Post by bmacho »

pgt wrote: post #29

Hiccup syntax for Clojure uses hash maps (curly braces) for attrs, e.g. `{:style {:background "red" :margin "1em"}}` See Reagent which uses Hiccup syntax: https://reagent-project.github.io/ (defn simple-component [] [:div [:p "I am a component!"] [:p.someclass "I have " [:strong "bold"] [:span {:style {:color "red"}} " and red "] "text."]])

A more interactive (but less examples) showcase : https://escherize.com/works/hiccup.space/

Re: Produce HTML from S-Expressions

#36

Post by junon »

lelanthran wrote: post #22
junon wrote: post #18

I actually really love this. I much prefer this over HTML syntax. Add a way to do custom tags and imports and this becomes a very, very neat static site generation tool.

> Add a way to do custom tags I don't know what that means - it currently uses the first element of the list as the tagname, so you can use whatever tags you want to. > and imports and this becomes a very, very neat static site generation tool. I've toyed with the idea of adding more functionality (like imports, environment variables, conditionals, etc). Not too sure I want to go in that direction.

The ability to create tag templates basically. You'd define tags that you could parameterize using attributes, and then within the custom tag "body" would be more tags definitions.

If the parser comes across a tag it doesn't know, it emits it verbatim. If it comes across a tag that is defined as a custom tag, then it replaces the tag expression with the expanded tag template body ("expanded" here meaning the parameters are substituted).

Similar to JSX, make an implicit parameter called "children" that holds all child elements, and then allow the templates to refer to attributes with a special expression (e.g. `(attr children)` or something, or maybe just `(:children)` if that doesn't break syntax rules).

Re: Produce HTML from S-Expressions

#37

Post by lelanthran »

junon wrote: post #36
lelanthran wrote: post #22

Earlier quoted context omitted.

> Add a way to do custom tags I don't know what that means - it currently uses the first element of the list as the tagname, so you can use whatever tags you want to. > and imports and this becomes a very, very neat static site generation tool. I've toyed with the idea of adding more functionality (like imports, environment variables, conditionals, etc). Not too sure I want to go in that direction.

The ability to create tag templates basically. You'd define tags that you could parameterize using attributes, and then within the custom tag "body" would be more tags definitions. If the parser comes across a tag it doesn't know, it emits it verbatim. If it comes across a tag that is defined as a custom tag, then it replaces the tag expression with the expanded tag template body ("expanded" here meaning the paramete…

> The ability to create tag templates basically. You'd define tags that you could parameterize using attributes, and then within the custom tag "body" would be more tags definitions.

This sounds like a good idea (could call it a `macro` but it might annoy readers who expect Lisp-type macros).

Something to DRY the input a little, maybe. I don't want it veering off too much into LispLand because then it's bound to be annoying to devs who wanted a more Lisp-conformant tool.

Re: Produce HTML from S-Expressions

#38

Post by mschaef »

junon wrote: post #36
lelanthran wrote: post #22

Earlier quoted context omitted.

> Add a way to do custom tags I don't know what that means - it currently uses the first element of the list as the tagname, so you can use whatever tags you want to. > and imports and this becomes a very, very neat static site generation tool. I've toyed with the idea of adding more functionality (like imports, environment variables, conditionals, etc). Not too sure I want to go in that direction.

The ability to create tag templates basically. You'd define tags that you could parameterize using attributes, and then within the custom tag "body" would be more tags definitions. If the parser comes across a tag it doesn't know, it emits it verbatim. If it comes across a tag that is defined as a custom tag, then it replaces the tag expression with the expanded tag template body ("expanded" here meaning the paramete…

> The ability to create tag templates basically. You'd define tags that you could parameterize using attributes, and then within the custom tag "body" would be more tags definitions.

Not sure how it might be supported in this library, but Hiccup (in the Clojure) ecosystem is similar and lets you do this with functions. This is a simple example of a scrollable div with a title block.

    (defelem scroll-column [ id title & contents ]
      [:div.scroll-column
       [:div.fixed title]
       [:div.scrollable { :id id :data-preserve-scroll "true" }
        contents]])
Note this (and Hiccup in general) heavily depends on Clojure array and hash literals. This wouldn't look as clean in a Lisp without those things.

Re: Produce HTML from S-Expressions

#40

Post by mtreis86 »

lelanthran wrote: post #14
sph wrote: post #12

Earlier quoted context omitted.

Bare words are fine until you have a variable with the same name as your bare word, so you need additional syntax to determine if you're referencing a variable, or it is just text.

> Bare words are fine until you have a variable with the same name as your bare word, so you need additional syntax to determine if you're referencing a variable, or it is just text. This doesn't have variables. Or functions.

The space you embed it into might
Post reply on HN