find_and_preserve is what ~ originally did. It finds whitespace sensitive elements <pre>, <textarea>, and a few others... when it finds one... it takes the contents of the area and then converts \n into the HTML entity for endline. That way... basically multi-line things *look* like single lines that be browser treats as having endlines. It used be be called "find_and_flatten".
%textarea I'm here becomes <textarea>I'm&ENTITYICANTREMEMBERhere</textarea> That way when later Haml templates get the area, they can indent freely, since there aren't any \ns.... The browser treats them the same. Its basically a hack that allows us to have whitespace sensitive areas on the page and still have it look pretty when we indent it properly. -hampton. On 2/11/07, weepy <[EMAIL PROTECTED]> wrote: > > it's a shame that we have to get funky with pre and textarea. isn't > the main problem with pre and textarea to do with the way in which > Haml chooses to show display it's html ? i.e. indented ? would the > problem be fixed if we chose Haml to display unindented? or am i > missing the point ? > > on a side note, can someone explain the logic behind the name > find_and_preserve ? --- what are we finding ? > > > On Feb 11, 10:22 pm, "Jeff" <[EMAIL PROTECTED]> wrote: > > Nathan, > > > > IMHO, textarea is not a "case that doesn't come up at all for most > > people". It comes up for everyone who creates a form. > > > > Ross argues for maintaining the integrity of haml the template > > langauge. When I suggested special behavior for textarea and pre, I > > was arguing for maintaining the integrity of the markup that haml > > produces. > > > > I love haml and I can live with the deprecation, but I don't buy the > > arguments. ~ is no more obscure than %, - or find_and_preserve. > > > > -- Jeff > > > > On Feb 11, 1:45 am, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote: > > > > > I agree with Steve. We want the Haml commands, especially those used > > > most commonly (%, -, and =) to behave as intuitively as possible, not > > > have special behaviors for various special cases that probably don't > > > come up at all for most people. Special cases have special handlers; in > > > this case, the find_and_preserve helper function. > > > > > As to readability, I think having an obscure command, such as "~", or > > > worse yet no command at all, is much less readable than a clearly-named > > > helper method. > > > > > - Nathan > > > > > Jeff wrote: > > > > I needed ~ to make my textareas work. Why would one ever want the > > > > unfiltered behavior for textarea and pre tags? Why doesn't haml > > > > filter those tags automatically? IMHO haml breaks those tags and I > > > > shouldn't have to use a filter to get the behavior I would expect. > > > > > > I think I should be able to say: > > > > = textarea :user, :profile > > > > > > and get the same result as is currently returned by > > > > ~ textarea :user, :profile > > > > > > The new methods may improve the haml source code, but from my > > > > perspective as a user, they don't improve ease of use or readiblity of > > > > my code. > > > > > > Thanks, > > > > -- Jeff > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
