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.
> On Fri, Nov 27, 2009 at 3:58 PM, Steve Howell <showel...@yahoo.com> wrote:
> > 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?
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Haml" group.
> > To post to this group, send email to h...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > haml+unsubscr...@googlegroups.com <haml%2bunsubscr...@googlegroups.com>.
> > For more options, visit this group at
> >http://groups.google.com/group/haml?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Haml" group.
To post to this group, send email to h...@googlegroups.com.
To unsubscribe from this group, send email to haml+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haml?hl=en.
