Your Thoughts, Please: Implicit Tags
Nex3
When Haml was originally created, Hampton decided to make it even
easier to create divs than it was to create other sorts of tags by
making divs the default.
Mislav Marohnić had an interesting idea for extending this. In some
cases, divs are invalid - within a p tag, for example, or an ol. What
if instead of producing a div, an implicit tag would create whatever
makes sense? A span, an li, maybe a tr or td.
There are a few potential issues with this. It makes Haml's output
more dependent on the document context than it usually is, and might
break a few templates. On the other hand, you should be thinking about
the context in which you use divs anyway, and any templates it breaks
are invalid anyway.
So I wanted to get the community's opinion on this. Is this something
you'd like? Something you'd dislike? Or does it not really matter to
you?
If you want to try it out, grab Mislav's Haml fork at git://github.com/mislav/haml.git.
- Nathan
Mislav Marohnić
Mislav Marohnić had an interesting idea for extending this. In some
cases, divs are invalid - within a p tag, for example, or an ol. What
if instead of producing a div, an implicit tag would create whatever
makes sense? A span, an li, maybe a tr or td.
.foo
It would become <div class="foo">. But when we are in a UL element, for example, DIV doesn't make sense (it's not allowed). The only allowed child for UL is LI (list item). So:
%ul
.foo Item
This would become:
<ul><li class="foo">Item</li></ul>
I call it "smart implicit tag". Smart, because implicit tag can not always be a DIV. In TABLEs, it's a TR. In a lot of elements that don't allow children of type block (like DIV), it's a SPAN. For instance, a paragraph doesn't allow DIV as child element, so the smart implicit tag inside a P would be a SPAN.
Here is a test template from my branch where I implemented it:
http://github.com/mislav/haml/tree/html/test/haml/templates/implicit_tags.haml
You can see how this can save typing.
Lawrence Pit
+1 love it!
pimpmaster
Bryce
When I first started using Haml my brain associated `#foo` and `.foo`
as 'a <div> tag with [id/class] of `foo`'. This change would make the
#/. syntax stand for 'the most appropriate element with the [id/class]
of `foo`'. The switch from being explicitly-implicit to
implicitly-implicit is the source of my uneasiness. One 'implicit' is
pretty magical already.
But! My brain can make this switch in the majority of cases (like the
ones you gave, Mislav) but there are two problem-cases that come to
mind (there might be more or these might be wrong).
Tables:
%table
#foo
thead, tbody and tfoot can go here, right? You might not expect a user
to expect to put an implicit tag here but it's still a syntactical
possibility.
Forms:
%form
#foo
What is supposed to be placed there? There are a number of valid tags
(not span, though, p works) that could be plopped there. Again, this
doesn't make a lot of sense for someone to be doing but it would still
be possible.
Are these really problem-cases or am I missing something? If they are,
would Haml error out or just use the next-best-substitute?
-- Bryce
Mislav Marohnić
But! My brain can make this switch in the majority of cases (like the
ones you gave, Mislav) but there are two problem-cases that come to
mind (there might be more or these might be wrong).
Tables:
%table
#foo
thead, tbody and tfoot can go here, right?
Yeah. But TR is chosen as implicit tag because it's most common.
Forms:
%form
#foo
What is supposed to be placed there?
DIV. When block elements are allowed in an element, DIV is always the implicit tag.
Are these really problem-cases or am I missing something? If they are,
would Haml error out or just use the next-best-substitute?
Haml would never error out. DIV is fallback for everything. But, where DIV is not allowed I hand-picked an element among the allowed that is most common: like TR in TABLE although tbody, thead and tfoot are allowed, and like TD in TR although TH is also allowed. In SELECT, OPTION and OPTGROUP are allowed, but the implicit tag is OPTION.
Does it make sense now? It's not really that magical, I think it's actually very straightforward. Look at the mappings:
http://github.com/mislav/haml/tree/html/lib/haml/precompiler.rb#L90
They read out like "implicit_child => parent_tags" pairs. For instance, SPAN is implicit child element for any of these:
That is because they only allow inline elements as children, and DIV is block.
Nathan Weizenbaum
When Haml was originally created, Hampton decided to make it even easier
to create divs than it was to create other sorts of tags by making divs
the default.
Mislav Marohnić had an interesting idea for extending this. In some
cases, divs are invalid - within a p tag, for example, or an ol. What if
instead of producing a div, an implicit tag would create whatever makes
sense? A span, an li, maybe a tr or td.
There are a few potential issues with this. It makes Haml's output more
dependent on the document context than it usually is, and might break a
few templates. On the other hand, you should be thinking about the
context in which you use divs anyway, and any templates it breaks are
invalid anyway.
So I wanted to get the community's opinion on this. Is this something
you'd like? Something you'd dislike? Or does it not really matter to you?
If you want to try it out, grab Mislav's Haml fork at
git://github.com/mislav/haml.git.
- Nathan
Nathan Weizenbaum
Geffy
Mislav.
Nate Vack
Does bringing the extra context along hurt much?
-Nate
Nathan Weizenbaum
being cached it shouldn't affect performance at all. Even if it's not,
it's not using any extra context - just the same data that's used to
remember which tags to close.
ratbeard
just to be sure:
%ul
.a yo
.b sup
would compile to:
<ul>
<li class='a'>yo</li>
<div class='b'>sup</div>
</ul>
That is, the implicit tag inside of a 'li' would be a 'div'? This
kind of nested implicit tag might take a little longer for your brain
to process while reading the code, but who knows, maybe it will become
second nature and you'll start to think about the document structure
more instead of relying on explicit tags. And of course, you can
always be explicit if you want to :)
I think it looks very cool and look forward to trying it out.
Mike
Jeff Casimir
I would think...
%ul
.a yo
.b sup
Would translate to...
<ul>
<li class='a'>
yo
<span class='b'>
sup
</span>
</li>
</ul>
Since I don't think a DIV can just be inside a UL.
- Jeff
Sean Cribbs
> Mike,
>
> I would think...
>
> %ul
> .a yo
> .b sup
>
>
spaces suggest, it should be:
%ul
.a
yo
.b sup
As far as whether it should have implicit tags, I think it could be a
good thing (time saver), but you should also be able to turn it off.
Sean
Mislav Marohnić
On Wed, Mar 5, 2008 at 8:55 PM, Sean Cribbs <seanc...@gmail.com> wrote:
As far as whether it should have implicit tags, I think it could be a
good thing (time saver), but you should also be able to turn it off.
Hampton
Ok, so first off. Fucking A+++++ on unique thoughts. This is probably
the most interesting idea I've heard in a long time. And its a really
interesting extension of what Haml is meant to do and the ways it
makes you think about the documents you are creating. So +100 points
to Mislav for being super-smart.
However, I am pretty solidly against this being default behaviour in
Haml. I shall list the reasons!
* Remembering and figuring out context takes too much brain power.
Having to look up and figure out why something is happening takes too
much time. The programmer should have more power.
* If you are debugging, your first step will have to be View Source
since you will be unaware of what is being created. Your first
instinct is "holy crap it must not be doing the right thing". This
slows you down.
* Nesting partials gets trick, trick, tricky. I can think of many
complex examples where tracking this would be a fucking pain.
* Muddles your assumptions
* Behaviour changing without notice is unnerving.
* Too much "magic" is frightening to programmers.
The only thing I'd consider for "official" syntax is a "GUESS" command.
%table
?
?.name
Data
?.value
Data
I'm just not sure how useful it is. I feel like I want to say "Yeah, I
KNOW what I want there... duh"
Another possibility is building this as an optional pre-parsing.
Install the magic-haml plugin and all templates get put the the ringer
of this magic. That way, core-haml can just focus on what-is-seen....
and the magic can be contained in its own project.
Just my two shits.
-hampton.
PS: I like the line of thought though. I'm still up for convincing.
Lawrence Pit
A DIV can't be inside a UL, but it can be inside an LI.
Seems to me this (and the other examples given) show that people don't know what to expect, indicating these smart implicit tags aren't perhaps advisable. You'd have to think about your future developers who will read your haml code too.
Lawrence
Eric Anderson
> This
> kind of nested implicit tag might take a little longer for your brain
> to process while reading the code, but who knows, maybe it will become
> second nature and you'll start to think about the document structure
> more instead of relying on explicit tags.
with "a" and "b" as the class name it does need the explicit tags
because there is no relevant context for the brain other than what the
missing %li would have provided. But if the markup has other context
info (as most do):
%ul#videos
- for video in @videos
.video= output video
In this case I like the fact that the %li is gone. It just adds noise
and the fact that I now have so much context info (videos, video,
etc.) my brain can scan this without thinking twice. Combined with the
fact that the only people who would be negatively impacted by this
feature is people who already have invalid markup my vote is enabled
by default but then have some option for turning it off so people with
existing (invalid) markup are not forced to fix their files until they
are ready.
Sean Cribbs
For paranoia's sake, mostly. I suspect (although it may be unfounded) that it might be valuable when generating XML and not HTML.
Sean
Eric Anderson
> Seems to me this (and the other examples given) show that people don't
> know what to expect, indicating these smart implicit tags aren't perhaps
> advisable. You'd have to think about your future developers who will
> read your haml code too.
obvious to developers that their assumption about markup is invalid.
If they type:
%ol
.item Foo
.item Bar
Then look at their generated source and wonder why they see <li> tags
instead of <div> tags they will now be educated to the fact that the
source they were about to send out is invalid.
Just my two cents.
Chris Boone
>
> So I wanted to get the community's opinion on this. Is this something
> you'd like?
Yes. +1.
--
Chris Boone, Hypsometry
http://hypsometry.com/
Chris Boone
>
> * Remembering and figuring out context takes too much brain power.
Isn't that a reason to support this idea? Context will be remembered
and figured out for you.
Surprisingly often I find myself wondering "Am I allowed to use a div
here? Or do I need to use a span?" (You'd think I'd have that down by
now.) This enhancement would remove the need to do that.
> * Nesting partials gets trick, trick, tricky. I can think of many
> complex examples where tracking this would be a fucking pain.
I can see that, for sure. But I can also think of cases -- ones I'm
working on right now -- where this smart tag generation would be
helpful, not harmful.
For instance, I'm working on a site with these chunks of content.
(Doesn't really matter what they are.) I've got a standard way of
generating them, using a partial, and I use that partial all over the
place. Sometimes I want the chunks of content to appear in a list,
sometimes just on their own. As it is now, I'm using partial layouts
to wrap the chunks in the appropriate surrounding HTML (li or div, as
needed). It's not difficult or complicated, but it is one extra thing
that I need to keep track of. With these smart tags I wouldn't need to
do that, since Haml would determine the needed tag for me.
> * Too much "magic" is frightening to programmers.
This seems less like magic to me, and more like enforcing best
practices. IMO, it fits in naturally.
pimpmaster
> practices. IMO, it fits in naturally.
Haml is supposed to enforce valid HTML.. this just takes things a bit
further.
I said it before and I'll say it again:
+1 !!!
Mislav Marohnić
* If you are debugging, your first step will have to be View Source
since you will be unaware of what is being created. Your first
instinct is "holy crap it must not be doing the right thing". This
slows you down.
I agree with this 100%.
* Nesting partials gets trick, trick, tricky. I can think of many
complex examples where tracking this would be a fucking pain.
Well, I never even thought of tracking it across nested templates. It would be hard to implement, I guess.
The only thing I'd consider for "official" syntax is a "GUESS" command.
%table
?
?.name
Data
?.value
Data
I like having the "guess" character since it would allow me to build nodes without specifying a classname or ID. I never thought of this. I dislike using the "?" character, however. I would much rather use asterisk or dollar.
%table
*
*.name Mislav
*.age 24
What do you think? Is there a character more appropriate?
Regarding other people disliking this because of "magic": I agree. Giving people this behavior is not necessarily giving them power; it can also take away power (as Hampton said) and lead to some debugging sessions. Jeff Casimir demonstrated this: he thought that SPAN will be generated inside the LI, but in fact DIV is generated. While this can educate people on HTML (as Eric noted), it can also be frustrating.
Explicitness in programming is not always bad; quite the opposite. In Haml templates it leads to readability, which is good. I came up with this idea because I wanted to sacrifice explicitness for ease of typing, but maybe the trade-off isn't fair. But, because I learned HTML directly from the spec and its DTD, I know all the nesting rules by heart and therefore I benefit from this "magic". Other developers who never read the DTD may not benefit in the same way and will feel uneasy about using the syntax because they will not be sure what's being generated.
I don't want to kill off my baby, however. Neither does Hampton or Nathan, as they expressed it openly. I'll keep my "html" branch alive and try to actually use it, see if I hit some negative consequences with this. Maybe I'll also release this as an evil twin plugin for Haml, it is very easy to monkeypatch in core Haml.
You are free to pull my branch and play with it. Thanks for all the comments and praises.
So how does the community feel about the "guess" syntax (middle of this email)? It has more chance of becoming core.
pimpmaster
+1 vote for *
$ gives me bad php flashbacks :p
Bryce
hadn't considered.
I don't like the idea enough to want to make it the default but I like
it enough to want it as an option.
+1 for 'Guess' Syntax
Chris Boone
<mislav....@gmail.com> wrote:
>
> So how does the community feel about the "guess" syntax (middle of this
> email)? It has more chance of becoming core.
Fine by me.
Irfan Adilovic
of a simple reason: one can always force a div by saying
%div#id.class, so writing #id or .class feels natural enough to be the
way of the guessing syntax. In other words - since we'd use implicit
tag guessing most of the time - there is no reason to reserve the #id
or .class syntax for divs any more. If special guessing syntax is
introduced, my preference would be
? > * > $
I like the concept by itself too, but I'd probably like to either see
it off by default in core or as a separate magic-haml plugin (that
would modify the existing Haml behavior when installed) as Hampton
suggested (I hope he meant that).
The partials... Does the haml in partials normally get compiled and
cached before inclusion into other templates? If that is so, this
magic wouldn't help in generating the correct contextual tag as the
context is non-existent.
If the compilation happens after inclusion, then the magic would
rather aid the programmer, as Chris Boone pointed out.
-- Irfy
2008/3/7, Chris Boone <hypso...@gmail.com>:
Hampton
If I KNOW what is supposed to go there,
then I'm only saving 2 characters on a %tr and I'm losing
explicitness. I'm just having trouble coming up
with a use-case that makes any sense.
* does look nice, but what are we really ~gaining~.
Can someone come up with some examples when the utility of * (or even
the original idea). Like,
"in this situation ____ is easier because _____." But, only examples
that improve both _clarity_ and _efficiency_.
I need these to be compelling problems we run into right now.
-hampton.
scott stewart
it, the less I like it. One of the things that attracted me to HAML is
that it is a pretty clean abstraction on top of html/xmhml. Its not so
much about introducing new abstractions like creating a "grid" tag or
a special labeled text tag, but just taking plain ole html/xhtml and
beautifying it. I realize this suggestion isn't quite like creating a
new special tag, but it does seem like it leads down the path of
creating special abstractions. I realize we already have the special
case of "." and "#" and their relationship with div. But, if you had
to pick one tag to make the default, it does makes sense. Making the
default tag be context specific changes this thought from just being
the "default" tag to being a haml abstraction that I'm not sure will
be good in the long run.
HAML, isn't so much about introducing "new" abstractions, but making
what you are doing already more beautiful, terse and easier to read.
For the most part, you use the exact same html/xhtml tags, but hamlize
them. This makes haml 1) very easy to learn, 2) extremely productive
to work with, and 3) always a pleasure to read. I think this
suggestion, might help #2 in some cases and make you slightly more
productive for the microsecond that you are typing that tag inside a
ul, tr, etc., but in the long run hurt 1 and 3.
On Mar 6, 5:48 pm, "Mislav Marohnić" <mislav.maroh...@gmail.com>
wrote:
Nathan Weizenbaum
it wouldn't be possible to guess tags across them.
s.ross
>
> Hey folks,
>
> When Haml was originally created, Hampton decided to make it even
> easier to create divs than it was to create other sorts of tags by
> making divs the default.
>
> Mislav Marohnić had an interesting idea for extending this. In some
> cases, divs are invalid - within a p tag, for example, or an ol. What
> if instead of producing a div, an implicit tag would create whatever
> makes sense? A span, an li, maybe a tr or td.
>
> There are a few potential issues with this. It makes Haml's output
> more dependent on the document context than it usually is, and might
> break a few templates. On the other hand, you should be thinking about
> the context in which you use divs anyway, and any templates it breaks
> are invalid anyway.
>
> So I wanted to get the community's opinion on this. Is this something
> you'd like? Something you'd dislike? Or does it not really matter to
> you?
>
> If you want to try it out, grab Mislav's Haml fork at git://
> github.com/mislav/haml.git.
>
> - Nathan
So, to summarize thus far:
- It seems like a good idea, because invalid markup is harder to
create (would it really know the DTDs?)
- It might save typing (or not)
- Surprising things might happen so programmers should be able to
control it
- Maybe an explicit way to invoke it using a "guess" syntax would be
good (or not)
- Partials present a problem because they are compiled first and don't
know about their context
Question: Is Haml likely to succeed at enforcing standards-compliant
(X)HTML or might it just give the illusion of that? If the latter,
then I think this might better be handled in (X)HTML validators that
send you back to your source with your tail tucked between your legs.
Validators can also handle your CSS. Granted, that has to happen on a
per-page basis, but it's pretty darn reliable.
Fair?
Wincent Colaiuta
It's probably useless to protest, seeing as there is such overwhelming
enthusiasm for this idea, but I'm actually opposed to it.
I don't like the way it takes a piece of syntax and changes what it
means depending on its context. In a markup language, I think any
given token should always mean the same thing, as it makes it easier
to teach, easier to write (because you don't have to think ask
yourself, "What will this syntax produce in this context?") and easier
to read (for exactly the same reason). It just doesn't seem worth it
for the benefit (a few saved keystrokes).
Cheers,
Wincent
Mikel Lindsaar
> enthusiasm for this idea, but I'm actually opposed to it.
-1
Which is a good example of what it would mean to have a guessing
syntax. Is my -1 by you just glancing at it, -1 to not having it or
-1 to having it?
Programming languages and DSLs and markup should provide consistent
behaviour. I don't want to be two partials deep thinking "will this
break something somewhere else?"
besides %li and ? are actually only two keystrokes apart... the time
you would save in typing the two keystrokes you loose overwhelmingly
in having to work out the context you are typing those ? in when you
are looking at it later trying to debug it.
So in this context, my -1 means "no, I do not think this would be an
improvement on HAML"
Mikel
Nate Vack
> Partials are compiled before being included in their super-template, so
> it wouldn't be possible to guess tags across them.
unworkable, even if you could send context to them. For example, you
could do:
(foo.haml):
%ul
= render :partial => "bar"
= render :partial => "bar"
(bar.haml)
.bar
What kind of element am I?
What should happen here? It looks like maybe the code should generate
<li class="bar"> and <div class="bar"> -- that would be...
surprising... to me, as a developer. Right now with haml, I *know*
what's gonna happen when I write '.bar'.
-Nate
Tom Stuart
> What should happen here? It looks like maybe the code should generate
> <li class="bar"> and <div class="bar"> -- that would be...
> surprising... to me, as a developer. Right now with haml, I *know*
> what's gonna happen when I write '.bar'.
As Irfan Adilovic already pointed out, if you want a <div>, you can
write %div. In some circumstances it would be monumentally useful to
have a context-aware partial that generated the appropriate tag at the
top level -- for rendering a representation of a particular model, for
example, regardless of whether the partial was rendered directly into
the <body>, into a <p>, or into a <ul>.
This behaviour shouldn't be "surprising" if you haven't specified
which tag to output. In many ways it's the least surprising behaviour:
"I haven't given a tag name here, so do whatever is best". Only
familiarity with the meaning of Haml's current syntax would lead you
to expect a <div> where none was specified; if the syntax changed,
future developers wouldn't have the same expectation.
Cheers,
-Tom
Geffy
it most closely mirrors CSS.
Also think Magic HAML would be best suited to being an additional
plugin to the main core.
The idea of context sensitive implicit tags does have a good use case
for core though. That case is DIV and SPAN, these are both in the same
"family" of elements in HTML, with one being block and the other being
inline. In the case where HAML sees
%li
%a
Hello
.greeting Bob
it will currently generate
<div class="greeting">Bob</div>
for the implicit tag, though DIV is not valid within the context of an
anchor tag. In this case I believe HAML should instead generate a
<span class="greeting">Bob</span>
as this valid and SPAN holds a similar purpose to DIV. At the moment
it is not surprising that you'd need to change it to
%span.greeting Bob
but I think it would help if HAML was at least context sensitive to
the degree of knowing when it should generate a DIV and when to
generate a SPAN.
Do those ramblings make sense to anyone?
Geoff
Daniel Manrique
Technology can provide reliability; however, the general public is no longer even aware that it's possible.
pangel
want to turn haml into a validator.
Nathan Weizenbaum
Irfan Adilovic
Templates are included in a layout, and there we have the same
situation - no context for the outermost tags (right?), but we assume
that div is okay - since that is most common. Should we need anything
else - we'd simply put an explicit tag.
Since we have clarified that we cannot know the context of the partial
while compiling the partial, we could simply make Haml either:
a) fail loudly whenever it encounters a magical tag without context, or
b) generate a div silently, which is simpler, and consistent with
non-partial magic-tag-selection.
If you need a specific tag, you can override it, just as in any other
circumstance.
I'm not sure about this, but it seems the context problem would exist
only for the outermost element(s) in a template/partial (making the
problem that much smaller), correct?
-- Irfan Adilovic
2008/3/11, pangel <pange...@gmail.com>: