Showell Markup

[Steve Howell]

Hi everybody, I found about HAML recently and think the concept is
pure genius!

Since I work mostly in Django, I decided to create a markup that is
similar to HAML. I use it as a preprocessor for Django templates.
You can read more here:

http://groups.google.com/group/django-users/browse_thread/thread/7a8fbac4572d5c25#

I have an idea that I think might resonate with the HAML community.

First, let me say that HAML does a great job of providing indentation-
based syntax, and that is 80% of the pain when dealing with non-HAML
solutions. I have made no innovations there; instead, I have just
ported the concept to Django use cases.

Where I differ from HAML is in HTML one-liners.

HAML puts the markup on the left:

%strong{:class => "code", :id => "message"} Hello, World!

Showell Markup puts the markup on the right:

Hello, World! | strong class="code" id="message

The idea is that Content is King! Markup is just an afterthought.

And you can also chain markup as follows

Hello, World | strong | span class="greeting"

Start with the content, and then apply markup from left to right, with
each new element surrounding the previous. You get this result:

<span class="greeting"><strong>Hello, World</strong></span>

I hope this makes sense. Good luck bringing HAML to the masses! It
is important stuff.

[Chris Eppstein]

The haml-spec project is creating a standard test suite for haml implementations. A python implementation of Haml seems like a no-brainer... I'm surprised one doesn't exist yet.

As far as your new syntax ideas go with putting the content before the markup, I'm not a big fan. Content may be king on the internet but it is rarely the most important part for the programmer. I care about what the ID and classes are for my elements and this is the part that haml optimizes so nicely. Haml is awesome for structural markup. When it comes to markup for "content" I often use markdown via the haml markdown filter.

Chris

--

You received this message because you are subscribed to the Google Groups "Haml" group.
To post to this group, send email to ha...@googlegroups.com.
To unsubscribe from this group, send email to haml+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haml?hl=en.

[Steve Howell]

On Nov 27, 10:43 am, Steve Howell <showel...@yahoo.com> wrote:
> Showell Markup puts the markup on the right: [....]

P.S. I think the idea of putting the markup on the right, vs. the
left, is particularly interesting when dealing with list items or
table cells.

About | a href="/about.html" | li
Get Help | a href="/help.html" | li
Tutorial| a href="/tutorial.html" | li
Documentation | a href="/docs.html" | li
Blog | a href="http://nex-3.com/?tag=haml" | li

I am not saying this style is better...just interesting. :)

Here is what gets produced by the above:

<li><a href="/about.html">About</a></li>
<li><a href="/help.html">Get Help</a></li>
<li><a href="/tutorial.html">Tutorial</a></li>
<li><a href="/docs.html">Documentation</a></li>
<li><a href="http://nex-3.com/?tag=haml">Blog</a></li>

[Bradley Grzesiak]

I agree with Chris, but on a separate level. While I agree that content is very important, the corresponding context is also important. By implementing HTML in a semantic way, we – as authors – provide (hopefully) minimal hints at the context just before the content.

Of course, this falls away as we start piling on extra markup like a giant "style" attribute (which, arguably, is poor semantic authoring).

Anyway, I appreciate Steve thinking outside the box, but in the end... it's not for me.

:brad

--
Bradley Grzesiak
list...@gmail.com

* You have received an email from my personal account. Please do not divulge this address to any website (eg: evite, shutterfly, etc). I have another address for such uses; please ask me for it.

[Steve Howell]

On Nov 27, 1:13 pm, Chris Eppstein <ch...@eppsteins.net> wrote:
> The haml-spec project is creating a standard test suite for haml
> implementations. A python implementation of Haml seems like a no-brainer...
> I'm surprised one doesn't exist yet.
>

This was the closest thing I found:

http://lucumr.pocoo.org/2008/2/15/ghrml-haml-for-genshi

Although I admire HAML, I am not striving to produce an exact clone.
Regarding the haml-spec project, it might be a good idea to define a
subset of HAML that only deals with indentation, without some of the
Ruby integration and class/id sugar. It might facilitate cross-
platform support.

Here is the link to my Python code if anybody wants to adapt it more
purely for HAML: http://www.djangosnippets.org/snippets/1819/

The Indenter class is probably the most reusable part. Some of the
other methods are more geared to specific Django use cases.

> As far as your new syntax ideas go with putting the content before the
> markup, I'm not a big fan. Content may be king on the internet but it is
> rarely the most important part for the programmer. I care about what the

> and classes are for my elements and this is the part that haml optimizes so
> nicely. Haml is awesome for structural markup. When it comes to markup for
> "content" I often use markdown via the haml markdown filter.
>

Fair enough. Most of the structural stuff in Showell Markup does
happen at the block level, where the markup does precede the content.
If you keep the structural stuff mostly at the block level, the
content will stand out via indentation, except when you get to more
granular markup. It might make sense for me to more purely separate
the three different filters, since some folks might not like the one-
liner syntax or the Django-specific stuff, but they'll want to keep
the HTML-block-tag indentation goodness.

[Steve Howell]

On Nov 27, 1:29 pm, Bradley Grzesiak <listro...@gmail.com> wrote:
> I agree with Chris, but on a separate level. While I agree that content is
> very important, the corresponding context is also important. By implementing
> HTML in a semantic way, we – as authors – provide (hopefully) minimal hints
> at the context just before the content.
>

Thanks, that is useful feedback!

> Of course, this falls away as we start piling on extra markup like a giant
> "style" attribute (which, arguably, is poor semantic authoring).
>

LOL...yep, in a way, creating a mechanism to push the markup aside
just deodorizes the smell of poor semantic authoring.

> Anyway, I appreciate Steve thinking outside the box, but in the end... it's
> not for me.
>

Cool...not all is lost. There are two orthogonal goals that I had--
one was to keep the markup DRY even for one-liners, and the other was
to put content before markup. I think I might abandon the latter goal
while keeping the former, which will get me closer to HAML.

[Nathan Weizenbaum]

If I were redesigning Haml from scratch, I'd actually try to make it easier to write tags and harder to write content. That is, I'd have the tag be the default and the content require an extra character. Something like this:

    html
      head
        title foo
      body
        p
          > This is text.
          > I like text!

Haml has always been focused on the structure of the document. That's why it has indentation, which makes inline tags harder to use, and why we recommend the Markdown filter rather than providing better inline formatting options. And this works well: when you're using Haml, what you're mostly trying to do is create the structure of the document. An indentation-based tool is simply not well-suited for dealing with documents that are all about the content.

[Steve Howell]

On Nov 27, 3:03 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> If I were redesigning Haml from scratch, I'd actually try to make it *easier
> * to write tags and *harder* to write content. That is, I'd have the tag be

> the default and the content require an extra character. Something like this:
>
>     html
>       head
>         title foo
>       body
>         p
>           > This is text.
>           > I like text!
>
> Haml has always been focused on the structure of the document. That's why it
> has indentation, which makes inline tags harder to use, and why we recommend
> the Markdown filter rather than providing better inline formatting options.
> And this works well: when you're using Haml, what you're mostly trying to do
> is create the structure of the document. An indentation-based tool is simply
> not well-suited for dealing with documents that are all about the content.
>

Nice! I really like the idea of making head/html/body/etc. work
without syntax.

But I am not sure you even need special syntax for the content. Can't
you just infer when you are at a leaf from the indentation, and then
infer that a leaf is most likely content?

It seems like you the only thing you REALLY want to escape is when a
branch is not markup, or a leaf is not content.

I can't fathom a situation in HTML where a branch is not markup.

I can think of scenarios where leafs are markup, not content.

But first a quick philosophical digression. I don't think there is a
pure dichotomy between content and markup. Really there are more like
four or five categories. You have pure content, which is easy to
understand, and the only complications with content is that it often
is not static, but instead needs to get generated by variable
interpolation. Then you have pure semantic markup (think table tags,
lists, divs, paragraphs, etc.), which is highly structural in nature,
and which almost never needs to be re-rendered (although it does
occasionally happen that structure changes on the fly). You also have
markup that is really inline styling, and whether you indicate it
stylistically or semantically (b vs. strong), you are really just
formatting some text, and this type of markup is to be shunned, so
need to optimize for it, just support it via ugly old HTML. Finally,
you have markup that is pure content, which just happens to usually be
expressed as HTML singleton tags (<br>, <hr>, <input type="submit">).

So back to the question of when leafs are markup, not content. I
think the most obvious cases are <br>, <hr>, and <input
type="submit">. If you have an HTML-aware language, I do not think
you should have any special syntax for them, not even angle brackets.
You just know that those guys do not have children, and so you do the
right thing. It is easy to handle <br> and <hr>, but "input" is a
little more problematic. For some reason HTML thinks that buttons and
text fields both qualify as "input," but textboxes don't. And for
inputs, where you have a value, for some reason it is a treated as an
attribute. Whatever. "Input" is a little painful, but you can
construct a minimal syntax that makes the correct assumptions.

Am I missing anything in terms of where HAML/Showell leafs could be
HTML markup and not content?

Things get interesting when you add a templating engine to the mix.
Pardon me for using Django as an example, but it is what I understand
the best right now.

Django injects itself into the problem at two levels.

First of all, Django has structural elements, with things like for/
endfor, with/endwith, if/endif, etc. I am extremely tempted to allow
those elements to have the same lack of syntax as table, div, ul, ol,
and friends. My engine would just figure out when you are dealing
with a Django tag. If you want to be explicit, I'll let you, but
otherwise, why force the typing? There aren't any naming collisions.
Instead of the {% if ... %}...{% endif %} nonsense, just say "if,"
indent your block, and be done with it!

Second of all, Django has content elements, which are either variable
interpolations ({{ book.title }} or tags {% url whatever %}. Django
has its own escaping mechanism, which so far I have just chosen to
leave alone.

So here are my conclusions:

1) Require no syntax for structural elements, and just let the
preprocessor distinguish Django keywords from HTML keywords.
2) Require no syntax for pure text content.
3) Pass through Django syntax for {{ }} and non-block {% %} tags.
4) DWIM on br, hr, and input.
5) Consider a special syntax for leafs that are semantic in nature,
but I am not sure such a concept is really valid in the first place.

Thoughts?

[Steve Howell]

On Nov 27, 3:03 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> If I were redesigning Haml from scratch, I'd actually try to make it *easier

> * to write tags and *harder* to write content. That is, I'd have the tag be

> the default and the content require an extra character. Something like this:
>
>     html
>       head
>         title foo
>       body
>         p
>           > This is text.
>           > I like text!
>

It seems to me you could support that in a way that does not break old
HAML code.

Every node that is followed by an indented block could be implicitly
treated a tag.

Instead of this:

%one
%two
%three Hey there
%br
%hr

I could write this:

one
two
three<
Hey there
%br
%hr

Instead of this:

#content
.left.column
%h2 Welcome to our site!
%p= print_information

I could write this:

#content
.left.column
h2<
Welcome to our site!
p<
= print_information

The percent signs do seem awfully crufty, and I am not sure what
purpose they really serve, except to call out which lines have
indentation blocks following them. You would still need the percent
signs for hr, br, and friends, although you could special-case them.

[Nathan Weizenbaum]

The problem with making these distinctions between leaf nodes and branch nodes is that, to a user who doesn't understand all the internal workings of Haml/Showell, the distinction between when one needs to explicitly specify text or tag or what-have-you become completely incomprehensible. People already have trouble understanding the rules for indentation; making the syntax for an individual line differ depending on the indentation of that line and other lines around it is going to result in far too much confusion.

[Steve Howell]

On Nov 27, 7:05 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> The problem with making these distinctions between leaf nodes and branch
> nodes is that, to a user who doesn't understand all the internal workings of
> Haml/Showell, the distinction between when one needs to explicitly specify
> text or tag or what-have-you become completely incomprehensible. People
> already have trouble understanding the rules for indentation; making the
> syntax for an individual line differ depending on the indentation of that
> line and other lines around it is going to result in far too much confusion.
>

I understand your concern about confusing users. Part of the problem
is that you cannot reasonably require the user to indent every little
snippet of text, so the user does not "feel" a purely based
indentation model of how their HTML is structured.

It does feel *strange*, though, to have tell HAML that html, head, and
body, in particular, are block tags. But if you gave me sugar for
those (i.e. no need to type '%'), it is a slippery slope toward either
featuritis or confusion.

I doubt it would create any practical problems for big-block tags like
html, head, body, table, div [1], ol, ul, etc.; it would be more in
one-liner tags like h1, td, li, br, etc. that chaos could ensue, or if
not chaos, at least annoying confusion. And figuring out exactly
where to draw the line would be tough.

[1] Of course, div already has sugar, but its sugar saves way more
than one character.

> > haml+uns...@googlegroups.com <haml%2Bunsu...@googlegroups.com>.

[Widi Harsojo]

I want to share my implementation of Haml in W2tags,
(you can try at "w2tags.heroku.com")


The concept just like showell and textmate did, "preprocessor " and
"bundle", but I call it "HOT-tags", and I have presentation
when we had gathering ID-Ruby (indonesian ruby society)
http://www.slideshare.net/wharsojo/w2-tags-is-haml-in-erb-presentation
(even my project that day using c#), now we(at skyeight) using it in
develoment on Japanese company (who build Excavator · Bulldozer · Dump
Truck etc).

first
Haml style is include (% # .) plus (: for attribute name), curly
bracket for custom attribute

second
we have a next tag (^) mean that after ul tag it follows li, after
table tag it follows tr, after tr it follows th and so on ... and
you can put an attribute tag of (:) name, (#) id (.) class after the
command, my point is that it has pattern to follow

%ul
^.mnu one
^.mnu two
^.mnu three
(try it by copy and paste this command to "w2tags.heroku.com")

and it can redefine the-next-tag

%ul
~^%el_i $0
^.mnu one
^.mnu two
^.mnu three

third
you can redefine tag by using command of hot ( !H! ) like example
below (br tags will become breakline tag)

!H!br
%breakline/

%br

!H!br
%breakline $0

%br boowe;owe

%br
boowe

but I recommend to define a special tag by using under score

!H!_br
%breakline $0

-br boowe;owe

fourth
inside Hot ( !H! ) have special variable:
>> $$ for all attribute (: # . { custom }) so you can pass name, id, class to tag inside HOT

!H!_br
%breakline$$ $0

-br#main.item boowe;owe

>> $: $# $. you can specific attribute of name, id, class to tag inside HOT

!H!_br
%breakline$#
-lol$. $*

!H!_lol
$. $0

-br#main.item boowe;owe

>> and some other variable ( *all* *name* *id* *class* @: @# @. )

>> as example above parameters represent of $* (all params), and $0 (individual params and it repeatable), you can
add an equal sign before individual params, ( =$0 ) and it will
translate to <%= %>

!H!_br
%breakline$#
-lol$. $*

!H!_lol
$. =$0

-br#main.item boowe;owe

>> individual params can be interpolate as a String instant object follow tilda (~)

!H!_br
%breakline$#
-lol$. $*

!H!_lol
$. $0.upcase~

-br#main.item boowe;owe

and many more... but the point I create this implementation because I need
1.) erubish but I want in development code like Haml
2.) I want DRY code in view and Haml... I think different goal
3.) if I see repeated tag I save it in a "bundle/hot" and write only
one line of command (reference in bundle/hot)
4.) I have a pattern in development but in production it just plain
old erb / erubis.

thanks.

> To unsubscribe from this group, send email to haml+uns...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/haml?hl=en.
>
>
>

--
/wh

e=mc2inhologram

[Steve Howell]

On Nov 28, 4:41 am, Widi Harsojo <whars...@gmail.com> wrote:
> I want to share my implementation of Haml in W2tags,
> (you can try at "w2tags.heroku.com")
>

Pretty cool!

> second
> we have a next tag (^) mean that after ul tag it follows li, after
> table tag it follows tr, after tr it follows th and so on ... and
> you can put an attribute tag of  (:) name, (#) id (.) class after the
> command, my point is that it has pattern to follow
>
> %ul
>    ^.mnu one
>    ^.mnu two
>    ^.mnu three

Interesting...I considered a syntax like that, but I decided that most
of the subtags are so small to begin with (li, th, td, etc.), you are
not really saving any keystrokes once you have to hit "shift" to get
the caret. I do like how the "^" visually calls out the parent-child
relationship.

>
> and it can redefine the-next-tag
>
> %ul
>    ~^%el_i $0
>    ^.mnu one
>    ^.mnu two
>    ^.mnu three
>

I can see how the macro functionality can DRY up your HTML, although
often the need for macros indicates that your CSS is not robust
enough, correct?

[Steve Howell]

On Nov 27, 3:03 pm, Nathan Weizenbaum <nex...@gmail.com> wrote:
> If I were redesigning Haml from scratch, I'd actually try to make it *easier

> * to write tags and *harder* to write content. That is, I'd have the tag be

> the default and the content require an extra character. Something like this:
>
>     html
>       head
>         title foo
>       body
>         p
>           > This is text.
>           > I like text!
>

Just to follow up on Nathan's suggestion from 10 days back, my
colleague and I are now using a very similar approach to the above
snippet in our Python-implemented HAML-like markup below:

div id="create_referral"
div class="cues"
br
h5 | Start a discussion with friends:
ul
li | Tell a story
li | Share some knowledge
li | Ask for advice
li | Plan a gathering
p
| This is a
| sentence.
i > b | This is italization of boldification of this text.

Everything to the left of the pipes is structural; everything to the
right of the pipes is content. So far it has worked out well. Any tag
like "br" above that is not followed by a pipe, inner tag (see ">"),
or an indentation block just auto-closes, so we do not have to special-
case any HTML knowledge within the parser itself.

Below is a more real-world example of us integrating with Django's
templating language, as well as incorporating some shortcut syntax
like "LINK." The "PASS" syntax is stolen from Python, where you want
to have an empty block and need something to indicate indentation
level.


head
link rel="stylesheet" type="text/css" href="{{ MEDIA_URL }}css/
base.css"
script src="{{ MEDIA_URL }}js/jquery-1.3.2.js"
script src="{{ MEDIA_URL }}js/swap.js"
body
p
LINK fake_login_entry | Signout
if user
| Currently logged in as <b>{{ user.username }}</b>,
| {{ user.points }} points.
hr
div id="menu"
span id="action_links"
LINK home | Home
LINK friends | Friends
LINK create_referral | Create a card
LINK recent_changes | Recent changes
LINK my_archive | Archive
span id="information_links"
LINK about | About Grapevyn
hr

block body
PASS

[Nathan Weizenbaum]

I agree that the percent sign is somewhat crufty. As I said before, were I to design Haml from scratch, I might well decide to get rid of it and use a special character for denoting text instead. However, that ship has sailed.

Of course, it would be possible to add an option or an alternate syntax in which the percent sign is gone. However that takes effort, not so much in terms of implementation but in terms of supporting an additional option and migrating people over and educating people and so forth. It requires of the users effort to choose between two syntaxes, to learn the differences and so forth. I don't think the percent sign is crufty enough to warrant that.

On Mon, Dec 7, 2009 at 9:41 PM, Steve Howell <show...@yahoo.com> wrote:

On Dec 7, 9:17 pm, Steve Howell <showel...@yahoo.com> wrote:
sers from

>  The percent sign is crufty.

And it case it goes without saying my few critiques of HAML are only
given in light of me wanting it desperately to succeed, since it
solves such an important problem.

[Hampton]

I haven't had time to read all of this. But, see... starting off with the "Content is king"

bit is a nearly opposite philosophy to Haml. Haml is that structure and markup are

king. The content is just filler.

Haml is about symantics when building web applications. Content is usually

dynamic and is only important in how clearly its specified.

However, I am always interested in people coming up with new languages!

I might not want to use them, but I love the creativity.

-hampton.

[Steve Howell]

On Dec 17, 1:51 am, Hampton <hcat...@gmail.com> wrote:
> I haven't had time to read all of this. But, see... starting off with the
> "Content is king"
> bit is a nearly opposite philosophy to Haml. Haml is that structure and
> markup are
> king. The content is just filler.
>

> Haml is about semantics when building web applications. Content is usually

> dynamic and is only important in how clearly its specified.
>

Yep, I got the same feedback from a couple of folks on this thread, so
I
decided to put the structural stuff first, more in line with Haml.

> However, I am always interested in people coming up with new languages!
>
> I might not want to use them, but I love the creativity.
>

Thanks! By the way I renamed the project to shpaml, and you can try
it here:

http://shpaml.webfactional.com/try_it

Shpaml is not an exact clone of Haml, but it borrows lots of ideas, of
course.
I have only just started on Haml-like div sugar, so only simple
examples will work there,
but the overall indentation scheme is in place.

There is no syntax required for tags at the block level.

You do need special syntax for tags like br, hr, etc. (either "> br"
or "<br />" works).

There is no special syntax required for content unless you have a line
with "|" or ">" in it, in which case you prefix the line with "| ".