[web-devel] [hamlet] implicit spaces with newlines?
Mark Bradley
barkmadley at gmail.com
Tue May 24 08:22:31 CEST 2011
On Tue, May 24, 2011 at 4:13 PM, Michael Snoyman <michael at snoyman.com> wrote:
> On Tue, May 24, 2011 at 7:00 AM, Greg Weber <greg at gregweber.info> wrote:
>>
>> The Yesod homepage looks like this:
>> <p>
>> If you are new to Yesod, you should start off with #
>> <a href=@{FiveMinutesR}>the five minute start instructions
>> . The #
>> <a href=@{ScreencastsR}>screencasts
>> \ give a nice introduction to some of the advanced concepts, and
>> #
>> <a href=@{BookR}>the book
>> \ is the recommended approach to learning Yesod. Ask the #
>> <a href=@{CommunityR}>commnunity
>> \ for help.
>> Allowing one-line tags in positions other than the very beginning allows for
>> the removal of the '#' character:
>> <p>
>> If you are new to Yesod, you should start off with
>> \ <a href=@{FiveMinutesR}>the five minute start instructions
>> . The <a href=@{ScreencastsR}>screencasts
>> \ give a nice introduction to some of the advanced concepts, and
>> \ <a href=@{BookR}>the book
>> \ is the recommended approach to learning Yesod. Ask the
>> \ <a href=@{CommunityR}>commnunity
>> \ for help.
>> Having implicit spaces is actually a huge win here:
>> <p>
>> If you are new to Yesod, you should start off with
>> <a href=@{FiveMinutesR}>the five minute start instructions
>> The
>> <a href=@{ScreencastsR}>screencasts
>> give a nice introduction to some of the advanced concepts, and
>> <a href=@{BookR}>the book
>> is the recommended approach to learning Yesod. Ask the
>> <a href=@{CommunityR}>commnunity
>> for help.
>> But I am wondering if it is best to keep things the way they are but just
>> indicate when there should be implicit spaces. My thought is to somehow use
>> angle brackets. Changing <p> to <p>> would indicate implicit spaces.
>
> What's the advantage of adding a new syntax for "implicit" space
> versus just explicitly adding the space?
I think he means that the child nodes of <p>> would be affected by
some implicit spacing rules.
Personally I prefer one consistent behaviour (explicit spacing every
time). Trying to get too smart will get confusing and inaccurate
quickly.
>
> Michael
>
>> Greg Weber
>> On Fri, May 20, 2011 at 8:22 AM, Patrick Brisbin <pbrisbin at gmail.com> wrote:
>>>
>>> On 05/20/11 at 11:12am, Daniel Patterson wrote:
>>> > I think what the original author was saying was that when you make a new
>>> > line with html, whitespace is inserted, not whether hamlet should
>>> > automatically insert space after every tag.
>>> >
>>> > So yes, writing <p>hello<strong>there</strong></p> should not put white
>>> > spacing.
>>> >
>>> > But when you write, in html:
>>> > <p>hello
>>> > <strong>there</strong></p>
>>> >
>>> > It is equivalent to <p>hello <strong>there</strong></p> (note the
>>> > space).
>>>
>>> Isn't that simply due to the fact that HTML compresses whitespace across
>>> the board? (turning that "\n\t" or "\n " into just " ")
>>>
>>> Leading spaces in hamlet are used to define nesting, so also compressing
>>> this whitespace (rather than stripping it) would produce odd effects:
>>>
>>> <div>
>>> <p>Hey
>>> <strong>there
>>>
>>> Would turn into
>>>
>>> <div> <p>Hey <strong>there</strong></p></div>
>>>
>>> Which has an unneeded space after the parent <div>
>>>
>>> Right?
>>>
>>> >
>>> >
>>> > On May 19, 2011, at 11:57 PM, Michael Snoyman wrote:
>>> >
>>> > > On Thu, May 19, 2011 at 11:49 PM, Patrick Palka <patrick at parcs.ath.cx>
>>> > > wrote:
>>> > >> I find it a bit unintuitive that the hamlet code
>>> > >>
>>> > >> <p>hello
>>> > >> <strong>there
>>> > >>
>>> > >> or
>>> > >>
>>> > >> <p>
>>> > >> hello
>>> > >> <strong>there
>>> > >>
>>> > >> generates the html
>>> > >>
>>> > >> <p>hello<strong>there</strong></p>
>>> > >>
>>> > >> I expected there to be a space between "hello" and "there" similar to
>>> > >> what
>>> > >> the html specifications dictate. Is this behavior intentional or an
>>> > >> oversight? If it's the former, then what is the recommended way to
>>> > >> simulate
>>> > >> my expected behavior? Appending a space to the end of a line is
>>> > >> mentally ugly and syntactically obscure.
>>> > >
>>> > > I'm not sure what you mean by "what the html specifications dictate."
>>> > > HTML is whitespace-sensitive, meaning that:
>>> > >
>>> > > <i>foo</i> <b>bar</b>
>>> > >
>>> > > and
>>> > >
>>> > > <i>foo</i><b>bar</b>
>>> > >
>>> > > Are different. Now, in all likelihood in the above example, you will
>>> > > want to have the whitespace surrounding tags. But consider the
>>> > > following HTML:
>>> > >
>>> > > <p>You are logged in as <i>Michael Snoyman</i>, <a
>>> > > href="/logout">logout</a>.</p><p>Another paragraph.</p>
>>> > >
>>> > > In the case of the <i> and <a> tags, we definitely do *not* want to
>>> > > add whitespace after the tag (though we do want it before the tag). In
>>> > > the case of <p>, we don't care one way or another, but adding the
>>> > > whitespace everywhere will take up (a trivial amount of) extra
>>> > > bandwidth. tl;dr: Sometimes you don't want the whitespace.
>>> > >
>>> > > So when designing Hamlet, I thought up a few possibilities:
>>> > >
>>> > > 1) What we do now: all whitespace must be explicit.
>>> > > 2) Implicitly add whitespace before/after every tag.
>>> > > 3) Do something "smart", adding whitespace where it's desired.
>>> > >
>>> > > (2) isn't really an option because it makes having a tag as the last
>>> > > word in a sentence impossible. (3) gives me the creeps: I like smart
>>> > > libraries, but I will *never* trust a library to do this kind of stuff
>>> > > correctly all the time, even if I'm the one making up the rules for it
>>> > > to follow! And I have no doubt that it will quickly devolve into 500
>>> > > lines of hairy code to try and cover millions of corner cases. Oh, and
>>> > > don't forget that there are other languages than English that might
>>> > > approach it differently.
>>> > >
>>> > > I suppose another possibility is (2) along with some special way of
>>> > > forcing the removal of extra whitespace, but this seemed much less
>>> > > intuitive than the current approach.
>>> > >
>>> > > Anyway, that's the reasoning behind this stuff, if people have better
>>> > > ideas, I'd like to hear them.
>>> > >
>>> > > Michael
>>> > >
>>> > > _______________________________________________
>>> > > web-devel mailing list
>>> > > web-devel at haskell.org
>>> > > http://www.haskell.org/mailman/listinfo/web-devel
>>> >
>>> >
>>> > _______________________________________________
>>> > web-devel mailing list
>>> > web-devel at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/web-devel
>>>
>>> --
>>> patrick brisbin
>>>
>>> _______________________________________________
>>> web-devel mailing list
>>> web-devel at haskell.org
>>> http://www.haskell.org/mailman/listinfo/web-devel
>>
>>
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>>
>>
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
--
-barkmadley
sent from an internet enabled device
More information about the web-devel
mailing list