A list of inline tags

Hello there.

I love haml, but it has its quirks, and most of them are
with inline
tags. I'd be happy if there was an option to specify inline
tags so
using them wont shift the whitespace, like:

Usual behaviour:

%div
  %p
    %strong
       %span
          Hello world
    %img

<div>
  <p>
    <strong>
      <span>
        Hello world
      </span>
    </strong>
    <img />
  </p>
</div>


New behaviour (inline_tags set to %w(span strong)):

<div>
  <p>
    <strong><span>Hello
world</span></strong>
    <img />
  </p>
</div>

The great thing of this is that nesting block tags (p div h2
and such)
in inline tags is invalid. So you cant put div inside span,
so HAML
shouldnt care about it.

This also solves all %a whitespace problems when %a with
content on
another line definition adds one space at the end of a link
in
browser.

Is there a chance for such option to be introduced?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---

Hrrrm, that's actually a really good idea.

Once you just said it, it seems pretty obvious. Inline tags
are a
subset of tags that are pretty easy to define.

+1 for how obvious of a solution this is.

Double bonus points for anyone who can dream up a reasonable
time when
flattening these would go *wrong*.

Also, anyone for a patch with tests?

-hampton.

PS: This isn't a commitment to the idea. I think about
everything a
lot before anything is added to the spec-in-my-head. But,
its a
positive first reactions on a beautiful Saturday morning.

On 10/20/07, Inviz <invizkogmail.com> wrote:
>
> Hello there.
>
> I love haml, but it has its quirks, and most of them
are with inline
> tags. I'd be happy if there was an option to specify
inline tags so
> using them wont shift the whitespace, like:
>
> Usual behaviour:
>
> %div
>   %p
>     %strong
>        %span
>           Hello world
>     %img
>
> <div>
>   <p>
>     <strong>
>       <span>
>         Hello world
>       </span>
>     </strong>
>     <img />
>   </p>
> </div>
>
>
> New behaviour (inline_tags set to %w(span strong)):
>
> <div>
>   <p>
>     <strong><span>Hello
world</span></strong>
>     <img />
>   </p>
> </div>
>
> The great thing of this is that nesting block tags (p
div h2 and such)
> in inline tags is invalid. So you cant put div inside
span, so HAML
> shouldnt care about it.
>
> This also solves all %a whitespace problems when %a
with content on
> another line definition adds one space at the end of a
link in
> browser.
>
> Is there a chance for such option to be introduced?
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---

Hampton:
> Hrrrm, that's actually a really good idea.
>
> Once you just said it, it seems pretty obvious. Inline
tags are a
> subset of tags that are pretty easy to define.
>
> +1 for how obvious of a solution this is.
>
> Double bonus points for anyone who can dream up a
reasonable time when
> flattening these would go *wrong*.
>
> Also, anyone for a patch with tests?
>
> -hampton.
>
> PS: This isn't a commitment to the idea. I think about
everything a
> lot before anything is added to the spec-in-my-head.
But, its a
> positive first reactions on a beautiful Saturday
morning.

Thanks hampton. I'd surely make a patch if i were more
experienced
with ruby. Hope to see this in HAML. Then it'll be really
most
beautiful output as i see it 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---

+1 vote for this excellent feature.

I remember writing Hampton a while ago asking for something
similar,
but it wasn't as clean or simple as this.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---

On 20 Oct 2007, at 22:59, Evgeny wrote:
> What if I want to do
<a><div>...</div></a> -- I just
expect it to  
> work, not to have HAML scream
> about it just because inline_tags includes <a>.
Question is -- how  
> will it work?

If you want to do that, you've got bigger problems, because
it's not  
valid HTML. I guess it's arguable that Haml should silently
support  
generating invalid HTML if that's really what you want, but
it's  
equally arguable that you shouldn't expect everything to
work just  
dandy (on the server or in the client) if you decide to
break the rules.

However, to address the question directly, I guess that
option 2  
(i.e. format the <a> as if it's a block-level element,
even though it  
isn't) is the prettiest, although it'd be hard to implement
because  
when you're rendering the <a> you don't yet know
whether it's going  
to contain any erroneous block-level content, so I reckon
option 1  
(i.e. render the <a> inline-style, with the subsequent
block-level  
element formatted oddly) is probably the right way to go if
such  
behaviour is to be supported at all, because it's easier to
implement  
and if you're not interested in your markup being valid you
probably  
not interested in source formatting either. (But then why
would you  
be interested in Haml?)

For what it's worth, I'd like to see Haml not support
warningless  
generation of invalid HTML by default, with a vinegary
option  
(:i_dont_care_about_web_standards => true) to enable it.

Cheers,
-Tom



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---

The problem with Haml throwing any errors for invalid HTML
is that it 
creates the expectation that Haml will detect other errors.
I don't want 
to build an HTML validator into Haml, nor do I want to have
people 
expect one to be there when it really isn't.

- Nathan

Tom Stuart wrote:
> On 20 Oct 2007, at 22:59, Evgeny wrote:
>   
>> What if I want to do
<a><div>...</div></a> -- I just
expect it to  
>> work, not to have HAML scream
>> about it just because inline_tags includes
<a>. Question is -- how  
>> will it work?
>>     
>
> If you want to do that, you've got bigger problems,
because it's not  
> valid HTML. I guess it's arguable that Haml should
silently support  
> generating invalid HTML if that's really what you want,
but it's  
> equally arguable that you shouldn't expect everything
to work just  
> dandy (on the server or in the client) if you decide to
break the rules.
>
> However, to address the question directly, I guess that
option 2  
> (i.e. format the <a> as if it's a block-level
element, even though it  
> isn't) is the prettiest, although it'd be hard to
implement because  
> when you're rendering the <a> you don't yet know
whether it's going  
> to contain any erroneous block-level content, so I
reckon option 1  
> (i.e. render the <a> inline-style, with the
subsequent block-level  
> element formatted oddly) is probably the right way to
go if such  
> behaviour is to be supported at all, because it's
easier to implement  
> and if you're not interested in your markup being valid
you probably  
> not interested in source formatting either. (But then
why would you  
> be interested in Haml?)
>
> For what it's worth, I'd like to see Haml not support
warningless  
> generation of invalid HTML by default, with a vinegary
option  
> (:i_dont_care_about_web_standards => true) to enable
it.
>
> Cheers,
> -Tom
>
>
>
> >
>
>   


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---

On 21 Oct 2007, at 10:23, Nathan Weizenbaum wrote:
> The problem with Haml throwing any errors for invalid
HTML is that it
> creates the expectation that Haml will detect other
errors. I don't  
> want
> to build an HTML validator into Haml, nor do I want to
have people
> expect one to be there when it really isn't.

Point taken. Of course HTML validity is a larger and hairier
issue  
than just whether inline-level elements contain block-level
ones (and  
even the DTD can't express all of the syntactic HTML
validity  
constraints) so clearly this isn't an area you want to get
into.  
However, if you're deciding to pay attention to a specific
part of  
HTML's semantics (inline vs block) it's not an inherently
bad idea to  
do so correctly, with the caveat that you're not making any
claims  
about any other aspect of HTML.

It seems like this is the stance that Haml is already taking
with tag  
generation, attribute quoting etc (i.e. you've made it
impossible to  
generate badly-nested or unclosed tags, or attributes with
unescaped  
quotes), so this would just be another incremental
chipping-away at  
the problem; Haml already looks after your tag nesting and
attribute  
quoting, and now it knows about inline/block tags too, so it
won't  
let you do fundamentally broken things with them either.

Cheers,
-Tom

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---

On 21 Oct 2007, at 11:44, Evgeny wrote:
> My point was that sometimes the same element can be
both block and  
> inline, depending on where you use it.
> For example I would like my <li> to be inline
everywhere - except  
> the place where I make them display:block.

True enough -- some elements (div, object, ins, del, dd, li,
 
fieldset, button, th, td) can contain both inline- and
block-level  
content, so this is an interesting problem. Again I guess
the most  
magical solution is to render them inline-style if they
don't contain  
any block-level elements, and block-style if they do, but I
don't  
know how much effort it'd be to get the Haml parser to
support that!

Cheers,
-Tom



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Haml" group.
To post to this group, send email to hamlgooglegroups.com
To unsubscribe from this group, send email to
haml-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/haml?hl=en
-~----------~----~----~----~------~----~------~--~---