
Lisp-like html as a replacement to bbcode/markup/textile - JimmyRuska
http://94.249.190.129/
======
buro9
This would never replace bbcode.

The best thing to replace that is markdown.

People don't really grok tags very well at all.

BBCode only works because of WYSIWYG editors that do the work for the user.
That and the wide acceptance meaning that sites like Flickr produce BBCode
embed statements.

Markdown works well for people just typing in plain text but still getting
something formatted without trying to tag things.

If you have a WYSIWYG editor then who cares whether this is used... and as the
embed stuff isn't compatible why pick this over BBCode?

If you don't have a WYSIWYG editor, and assuming you're in a web page and a
textfield, then markdown works superbly well (ignoring the ugly image syntax).

I struggle to see, given the title and mention of BBCode, how the linked
article overcomes any of the issues of the existing methods or offers any
benefit.

Not to say that there isn't a place for this... but BBCode isn't it.

~~~
nakkiel
> BBCode only works because [...]

Any board out there is full of posts with broken quotes and markup. I don't
think BBCode works. It's widespread but it doesn't mean it works.

I otherwise agree with your points.

~~~
monsto
his underlying point, and he as much as said it, is that bbcode IS successful
because it WAS successful.

when it was born, it was convenient because it looked and acted like html
while limiting the users ability fuck things up. at the same time it didn't go
confusing the machine that was going to process it. it was clearly never
designed for anything but bridging that gap... some 15+ years ago.

Flickr produces bbcode embeds, but imgur produces like 8 different embeds.
existing adoption is not the sole mark of success for anything digital.
facebook anyone?

the wysiwyg editors make it easier to generate "human usable code that limits
fucking up". It matters because users can still fuck things up but for some
reason they need to be able to read it.

THAT is why this type of thing should be used (on the developer level) as a
replacement. It's easy to read, it's easy to grasp, it's consistent and it's
no more difficult to parse (for erlang or haskell or php) at the server level
than bbcode.

------
zachallaun
I think that this is an interesting experiment, and reminds me of Clojure's
hiccup[1] library.

In hiccup, you model html to be rendered as nested vectors and maps, such that

    
    
        <span class="foo">bar</span>
    

becomes

    
    
        (html [:span {:class "foo"} "bar"])
    

Where this is a real win is when you realize that it's just data:

    
    
        (html [:ol
                (for [x (range 1 4)]
                  [:li x])])
    

Lisps are well suited to model html.

[1] <https://github.com/weavejester/hiccup>

~~~
judofyr
Ruby has had these type of libraries for years. The original is probably
Markaby, but today there are alternatives that are both faster
(<https://github.com/camping/mab/>) and has more features
(<http://erector.rubyforge.org/>).

It's an interesting concept, but I find that (1) it's hard to work on it
together with designers and (2) for larger templates I don't find it that
elegant.

~~~
autodidakto
The theme between these efforts seems to me: Instead of a separate language in
a separate world, our views are normal objects/data (in all their glory and
power) that happen to know how to print themselves as html.

~~~
slurgfest
I'm certainly no cultist of MVC, but I would tend to agree with them that
tightly coupling presentation details to the basic model is usually unwise.

~~~
judofyr
You're not supposed to put these into your models. You should create a
different class/method that accepts models and returns HTML:

    
    
        class TweetWidget
          def initialize(tweet)
            @tweet = tweet
          end
          
          def content; … end
        end

------
pjin
Looks a lot like TeX, which is a good thing. In fact this might even be
better. I'm tired so I might be missing an obvious weakness but to take the
analogy a bit further here are some comparisons between this suggestion and a
more TeX-like version.

The author's suggestion:

    
    
      {b {i This is in italics and bold.}}
      {Henny+Penny We can use google fonts anywhere if we just import them first with the google-font code}
      {macro foobar {u {b %s}}}
    

TeX-like (yes I'm making up the keywords):

    
    
      {\b {\i This is in italics and bold.}}
      {\font {Henny+Penny} We can use google fonts anywhere if we just import them first with the google-font code}
      {\macro {foobar} {\u {\b #1}}}
    

I would definitely prefer the first alternative over the TeX-like. The analogy
also suggests though that instead of HTML "<br />" you could have a TeX-like
atom "\br" instead of "{br}"; saves only one character, but easy to see inside
a block of text.

~~~
printer
Why don't browsers support TeX anyway? Maybe it could even be embedded in a
HTML page, like SVG.

    
    
       <!doctype html>
       <tex>
       Hello, World
       \bye
       </tex>

~~~
cpach
There is actually an XML version of TeX: <http://getfo.org/texml/>

------
ash
Nice experiment.

There's an issue with curly braces { }. When typing in Russian (and in other
Cyrillic languages) you need to switch keyboard layout before and after each
curly brace. It quickly becomes tiresome to do: type-in-russian, switch-
layout, type-{, switch-layout, type-in-russian etc.

This problem also exist in Markdown too: square brackets [ ] and curly braces
{ } both live on the same keys as Russian 'Х' and 'Ъ'. Typing Russian Markdown
with links is tiresome. Curiously, the only easy to type characters in
Cyrillic layout are parens ( ).

 _Update._ I wrote about JCUKEN layout above:
<http://en.wikipedia.org/wiki/JCUKEN>. But on some keyboards the layout is
extended. E.g. Mac keyboard allows you to enter square brackets [ ] with `~
key in default Russian layout [1, 2]

[1]: [http://store.storeimages.cdn-apple.com/2544/as-
images.apple....](http://store.storeimages.cdn-apple.com/2544/as-
images.apple.com/is/image/AppleInc/MC184RS?wid=800&hei=800)

[2]: [http://store.apple.com/ie-
business/product/MC184RS/B/apple-w...](http://store.apple.com/ie-
business/product/MC184RS/B/apple-wireless-keyboard)

~~~
danielbarla
Out of curiosity, do Russian developers permanently use an English layout, or
just map these keys elsewhere?

~~~
ash
Switching layout is not an issue when typing code. You just type in English
because keywords and API are obviously in English. The problem exist only for
markup languages where you type prose.

Still (in addition to English letters) these are hard to type in Russian
layout: { } ' @ # $ ` (and more - depends on a keyboard and operating system).

 _Update._ I've just noticed square brackets [ ] on my (Cyrillic) Mac
keyboard. They are on a key with tilde ~ and backtick `. Before this very
comment I didn't know I could type square brackets in Cyrillic layout... This
should make Markdown much easier!

~~~
batista
Actually on Mac with a combination of alt/option key and the letter you should
be able to right {} in cyrillic without switching layout. Search a little, and
openthe "keyboard viewer" tool.

------
frr149
You just reinvented the RTF spec. It quickly gets out of hand, trust me.

~~~
JimmyRuska
I can say html is better than RTF, and I like this syntax more than html. It
accepts _style attributes on any tag so I do not encourage command stacking.

------
lispm
If you look at the old Scribe, it used a markup like in this example:

    
    
        @hemlock runs in the editor process and interacts with other Lisp processes
        called @i[eval servers].  A user's Lisp program normally runs in an eval
        server process.  The separation between editor and eval server has several
        advantages:
        @begin[itemize]
        The editor is protected from any bad things which may happen while debugging a
        Lisp program.
    
        Editing may occur while running a Lisp program.
    
        The eval server may be on a different machine, removing the load from the
        editing machine.
    
        Multiple eval servers allow the use of several distinct Lisp environments.
        @end[itemize]
    

To make things italic, you would write @i[some text here]. Longer commands
would be like in the itemize example. Each paragraph would be an item in this
simple version.

------
ANTSANTS
Xarn came up with a very similar implementation of an s-expression-based
markup language a few years ago:

[http://cairnarvon.rotahall.org/2010/05/25/towards-a-
better-b...](http://cairnarvon.rotahall.org/2010/05/25/towards-a-better-
bbcode/)

It's fun to play around with for a minute, but unless you really like /prog/,
you're rarely going to want that kind of flexibility in basic text formatting.
Still, a sexpcode parser would make for a decent board gimmick, so I'm kind of
surprised that no one (that I can remember, anyways) used it for that.

------
yorhel
Minor downside: You have to ensure that the contents of a {code ..} block have
all their open-brackets matched with close-brackets. This can be quite tricky
with larger code examples. The bbcode [/code] equivalent is slightly less
problematic.

Other than that it looks like a good alternative.

~~~
eterps
In my opinion all tags should have an optional short/long form i.e.: {code ..}
and {code}..{/code}.

------
franze
you mean like CURL? <http://en.wikipedia.org/wiki/Curl_(programming_language)>
\- used it years ago and it did not make my life easier.

~~~
JimmyRuska
but curl is a programming language itself. This is intended to be safe and
primarily for markup. I did change from parens to angle brackets because of
curl. It made much more sense because brackets are much less used in everyday
chat, on non programmer sites. I made this after I made an html parser, so
it's parsed in very much the same way. Curl is very very different.

------
cientifico
Years trying to move the style to the css and be semantic in the html.

I like it, but comes a little bit late. 8 years ago probably was nicer.

~~~
blacksqr
Cgi.tcl (<http://expect.sourceforge.net/cgi.tcl/>) has been around since the
mid-nineties. Also, htmlgen
(<http://tclxml.sourceforge.net/xmlgen/htmlgen.html>).

------
bithive123
I've found HAML (<http://haml.info/>) to be my ideal reduced HTML syntax,
strange not to see it mentioned here.

~~~
majormajor
HAML is fantastic overall, but there are two ways in which I don't think it's
addressing the same problem as something like this:

* Whitespace-sensitive means I don't want to use it in a text-field in a browser -- in an editor I can have guide lines to show me the indentation levels and what lines up with what, and keyboard shortcuts for indenting/unindenting blocks quickly.

* Nesting and inline stuff just doesn't work well since you'd end up with stuff like a %b on one line and then an %i on the next line unless you just went plain-HTML for the line. HAML is much more suited for page structure, and not so great for inline content.

Something like the following line is really cool with a quasi-TeX feel: "Using
multiple tags: {b {i This is italics and bold.}}"

------
fosap
That look nice, but four things:

divs. How to write something like <div class="text" id="lore">Test lore
ipsum</div> ? Does this have a chicken scheme style named parameters?

Inline HTML, especially useful for macros. {html <i>i</i>} should become
<i>i</i>

A unification <script> <img> <video> <audio> and <iframe>. It's not that easy
to translate to html, but i felt there should be one mechanism, since they all
just embed a another medium. The sematics would make more sense IMO.

The macro expression takes a argument (the macro name). Can my macro aswell do
this aswell? Any why doesn't the colour use it?

~~~
JimmyRuska
I set it to parse attributes with this syntax {b_class="text"_id="foo"
content}. It only supports the style attribute at the moment, because I was
worried about people using stuff like onclick or inheriting a class with a
huge width. I structured it like this mostly because it was easy to parse. I
also support tags like p, span, cite, section, article, aside, sub, sup, hr
and pre. I don't know what you mean in the last part about the macros.

------
akurilin
I believe Clojure has something similar to what the OP is talking about thanks
to Hiccup's macros: <https://github.com/weavejester/hiccup>

~~~
draegtun
Also there's Hiccups older Common Lisp relative CL-WHO - <http://weitz.de/cl-
who/>

Other languages also have _similar_ solutions -
[http://stackoverflow.com/questions/671572/cl-who-like-
html-t...](http://stackoverflow.com/questions/671572/cl-who-like-html-
templating-for-other-languages)

------
mhd
Hmm, an awful lot of <br>s in the generated code. Never mind that I'm not a
big fan of explicit <p>'s, either, as s-expression like formatting isn't that
helpful once your actual content pushes the starting tag beyond the screen.
SGML is actually not a bad idea if your markup content is pretty low (< 5%).

It's still a bit line-noisy compared against markdown and, well, I've yet to
see a forum using bbcode properly.

~~~
JimmyRuska
A new BR for every enter I press. The goal was to make the text in the
textarea readable. Maybe that's why markdown uses 2 line breaks for every
<br/> but I'm not sure I want to do that.

~~~
mhd
I still don't see a reason for manual linebreaks here, which would mostly be
useful for things like poems etc, where you explicitely need to mandate a
certain structure. For everything else paragraphs seem a better solution,
especially compared to pervasive use for <br /><br /> to simulate post-
paragraph spacing.

~~~
JimmyRuska
For developers that's right but when normal people are chatting hit enter they
expect a new line. I can't assume they mean the new text to be a paragraph
unless they specify it. I supposed I could add escaping for newlines but I'm
not going to auto <p> either.

~~~
mhd
If you're aiming for the bbcode sector, sure. Bloggers etc. (i.e. the
textile/markdown crowd) would usually expect more well-formed results.

Not sure whether that's a good demographic to aim at. Basically everything is
better than bbcode, yet it's quite firmly entrenched after all these years
(with a bit of tag-limited HTML and WYSIWYG as alternatives).

------
blue1
Once again see Erik Naggum's "Enamel"

~~~
draven
That's the first thing that came to mind as I read the article. More info:

<http://genius.cat-v.org/erik-naggum/xml-sgml-nml-lisp>

~~~
blue1
Is there actually a public Lisp library to do that? Erik is no longer among us
and brought his code with him; Tim Bradshaw had his version called TML/DTML
that AFAIK was never released.

------
pwg
Something similar from the Tcl world: xmlgen / htmlgen
<http://wiki.tcl.tk/5976>

------
jon_smark
This is almost identical to the syntax used by OCamldoc, a tool for generating
API documentation from OCaml sources:

[http://caml.inria.fr/pub/docs/manual-
ocaml-4.00/manual029.ht...](http://caml.inria.fr/pub/docs/manual-
ocaml-4.00/manual029.html)

------
klibertp
I'm a little bit late to the party and haven't had time to read all the
comments yet, but I like the idea and the fact that it's written in Erlang.

So I just wanted to ask: is it intended to be open-source? I couldn't find the
link to the source on the site and as mentioned I didn't read through comments
yet.

EDIT: I skimmed all the comments but still haven't found any mention about
source code. Also, I remembered YAJET[1] as something at least equally
interesting.

[1]: Home page is here: <http://www.yajet.net/> and docs here:
<http://www.yajet.net/yajet/doc/yajet.html>

~~~
JimmyRuska
I'm not quite done with it yet. I may post source after I've used it for
awhile and worked out any kinks. Honestly doing it in Erlang was not a great
idea. I had to do a lot of micro optimization to make it run at reasonable
speeds. I hope to rewrite it in D one day and maybe make a NIF plugin.

~~~
klibertp
> Honestly doing it in Erlang was not a great idea.

I was suspecting this and it's one of the main reasons I'd like to see the
source :-) Please don't hesitate to post it when you think it's ready!

------
droob
This loses markdown's biggest draw: a normal, readable document outside the
interpreter.

------
regularfry
Could be fun:

    
    
        {defmacro foo [bar] {li {i {bar}}}}

------
regularfry
The missing instruction: a literal '{' is written '\\{'.

------
stonefroot
No domain name! I love it! How often do we see this on HN? Fantastic.

As for the idea in the title, isn't this more or less what Viaweb did?

Create a DSL for generating HTML elements and structure that can itself be
embedded in an HTML page. Then let users POST commands along with their data
to your custom interpeter (that you built from Lisp/Scheme).

------
buster
No.

How does it replace markup?! It's still writing html but (more or less) using
{} instead of <>. That's just silly, imo.

Markup (and restructured text) are so much more concise because you don't need
to know what's <i> or <h3> or whatever.

Also, the page itself uses markup in HTML (not CSS)... wow.. back in 1995
again, are we?

~~~
JimmyRuska
Line by line parsers are extremely limited and markdown makes use of everyday
characters we use in text for their formatting. The page itself uses style
tags at the top so not sure what you mean. This is just showing off my
progress so far of something I plan to use. Not an announcement telling you
this is the future.

~~~
buster
Ah well, not saying you shouldn't use that. Just saying i wouldn't ;)

------
ams6110
Like all other html "improvements" this just trades one set of obscure
conventions for another. A bit more consistent perhaps, and the macros are
cool. How is this better than any other templating library though?

Is the source available?

~~~
JimmyRuska
The difference is normal users are able to use this more easily when used as a
markup language. People use parenthesis all the time as a delimiter for their
ideas (they do this sometimes). So telling them to {i do this sometimes},
isn't much of a stretch when they want to change tones or context of what they
say. If you know html, this is pretty much the same thing but with {tag
content} instead of {tag}content{/tag}. Not a lot of memorization involved and
if I allow any tag then it's the same set of html tags plus the syntax
transformations I've added. There is no source. It's not quite finished, and
even so, the source is in erlang. Not the most common of languages.

------
Lindemann
Thanks for sharing this. Looks very cool!

I would prefer the element name in front of the brackets. Like this:

h3{We can use google fonts easily}

This separates the element name more from the content.

------
darkstalker
I don't get how people likes Lisp syntax so much, for me it looks horrible. I
would prefer markdown as a replacement for BBCode

~~~
JimmyRuska
Line by line parsers are much much more limited. This can support syntax
transformations and html attributes. This is more of an html-alternative in
terms of capability. Markdown links are ugly and you need double space instead
of single space for every space you input. I could do something like replace
things nested in __as italics but I'd rather have normal characters not turned
into formatting. Lisp might look ugly in comparison to python, but not html
and bbcode.

~~~
taylorfausak
What's wrong with Markdown links [1]? I'd have a hard time coming up with a
better syntax than this:

    
    
        [Google][]
          [google]: http://www.google.com/
        [Google][1]
          [1]: http://www.google.com/
        [Google](http://www.google.com)
    

I'm not sure what you mean about double-spacing either. Line breaks (<br />)
are made by adding two spaces to the end of a line. If you don't like that,
try GitHub-flavored Markdown [2].

[1]: <http://daringfireball.net/projects/markdown/syntax#links> [2]:
<http://github.github.com/github-flavored-markdown/>

~~~
JimmyRuska
I was only aware of the last one. This has the capability to be used as a
replacement to html, not just a limited subset. It can also do syntax
transformations like the table, which also accepts other syntax transforms and
tags. Markdown can't take html attributes either.

------
raphinou
Looks interesting. I would have prefered the use of () in place of {} though.

~~~
heyitsnick
That would require a lot more escaping when you aren't writing markup (as
using parenthesis in regular writing is so common).

------
mvasilkov
Great idea, and so very obvious in hindsight.

