[web-devel] proposal for hamlet-like syntax that is more compatible with html
Michael Snoyman
michael at snoyman.com
Mon Dec 13 17:16:20 CET 2010
On Sun, Dec 12, 2010 at 9:14 PM, Greg Weber <greg at gregweber.info> wrote:
> what are multi-line tags? does that mean the attributes are on multiple
> lines? If you mean inner text, I don't see anything stopping inner text from
> the second line.
I meant attributes on multiple lines, sorry for the ambiguity.
> All well-thought points. Given the resistance to change I am also warming to
> multiple versions. What I was trying to do was get rid of '!' in any
> version- I really don't like that, especially when there are multiple
> attributes. It is fine when there is one attribute, but otherwise I find it
> hard to read compared to white space.
And frankly, I don't think have a %! version and a <> is horribly
confusing. I personally wouldn't want to use both in the same
template, but I think it could work at well overall.
> For Julius, perhaps '$(' - with an opening bracket could be jQuery.
> Prototype has $$, and $A, but again, any real world use should have an
> opening parens. There is one other use of having it as a function argument,
> but
> that can be decipehred also- function($,a){} - in this case there will be
> only white space and a comma after the dollar.
I don't like it because:
* It violates principle of least surprise
* It doesn't allow things like $.getJSON
Michael
> On Sun, Dec 12, 2010 at 8:54 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
>>
>> On Sun, Dec 12, 2010 at 6:39 PM, Greg Weber <greg at gregweber.info> wrote:
>> > Thanks for the feedback on the proposal. It is good to hear some
>> > criticism-
>> > that means there are people using hamlet! So we have heard from current
>> > users now- can we get feedback from those not using hamlet? Does the new
>> > syntax tempt you into switching? If you were forced into a project with
>> > hamlet, which syntax would you like best? Does anyone think that
>> > designers
>> > would be more comfortable with the new syntax?
>> > I would like to note another possible benefit to the proposal noted by a
>> > commenter on Michael's blog- the removal of the '%' character means that
>> > instead of signifying variable interpolation with '$' it could be done
>> > with
>> > the '%', making the syntax uniform across hamlet, cassius, and julius.
>> > I would like to be clear on the design goal of being closer to html. All
>> > other things being equal, it is simply about avoiding a larger mental
>> > overhead when switching between html and hamlet. The new syntax does not
>> > mean we are "writing html" or have any "constraints" not already present
>> > in
>> > hamlet. It simply means attributes use a space instead of a '!', and
>> > tags
>> > begin with a '<' instead of a '%', and are separated with their inner
>> > text
>> > by a '>' instead of a space. While the proposal discusses the
>> > possibility of
>> > allowing things like closing tags, that would be optional if it were
>> > implemented.
>> > Reducing the mental "context switch" could be useful for existing hamlet
>> > users that also works with html in other projects. But it is largely
>> > about
>> > getting more users of hamlet, particularly when they start a new
>> > project. I
>> > would not expect many projects to switch a project over, and closeness
>> > to
>> > html when switching an existing project over doesn't matter much once
>> > converters are available, and the larger the project, the more practical
>> > it
>> > is to write a converter. I see the real practical use on a smaller
>> > scale- if
>> > you want to copy and paste some html into your file, including html from
>> > a
>> > more traditional templating language where a converter may not
>> > available.
>> > Space-based attributes:
>> > Are there any objection to the *concept* of the change to use a
>> > space with
>> > attributes instead of a '!'?. This would actually make hamlet *more*
>> > similar
>> > to HAML.
>> > The difficulty in implementation is with determining the end of the
>> > attribute portion of the tag. For '%body id=the-body' there would be
>> > ambiguity as to whether the id started an attribute or inner text. Even
>> > worse is an attribute without a value 'input type=checkbox checked'. One
>> > technique is to assume it is an attribute if an '=' sign is present-
>> > requiring escaping the '=' sign, and requiring a (possibly empty) value
>> > for
>> > every attribute. HAML handles attributes by requiring opening and
>> > closing
>> > symbole: '(attribute=name attribute2=name)', which looks nice, but I
>> > would
>> > much rather have white space to begin attributes, and the closing
>> > character
>> > is forced on you when there is no inner text.
>> > Following my original proposal, the attributes could have a closing
>> > character that is optional when there is no text.
>> > %body id=the-body class=the-class>Inner Text
>> > I could appreciate that this might look peculiar to someone when the tag
>> > leads with a '%' instead of a '<' as in the original proposal. I think
>> > '&'
>> > could be a lot more appealing and signifies 'and there is text', also
>> > similar to how it signifies more parameters in a url.
>> > %body id=the-body class=the-class&Inner Text
>> > So I am still proposing the original proposal. If the original is not
>> > accepted, or if we want more time to think about it or otherwise an
>> > intermediate step is desired I would still propose using a space-based
>> > attribute syntax. We could also consider the possibility of allowing
>> > both
>> > the '%&' and the '<>' syntaxes now that they would be very similar.
>> > However,
>> > I would strongly argue for using the html-compatible syntax. Those whose
>> > senses are offended by a lone opening '<' can still add the '>' and
>> > justify
>> > that it prepares them for adding inner text.
>>
>> I'm actually thinking that a good first step on this proposal is
>> simply adding the <> syntax in addition to what we already have. For
>> example:
>>
>> %foo!bar=baz This is something
>>
>> is equivalent to
>>
>> <foo bar=baz> This is something
>>
>> Without introducing any other changes. I originally did not like the
>> idea of "two hamlets", but I'm beginning to warm up to it as an
>> intermediate step. I'd even consider leaving both of them in there
>> indefinitely, though I'm not sure that's the best idea.
>>
>> I very much would *not* like to implement a proposal such as % and
>> whitespace attributes, eg:
>>
>> %foo bar=baz&This is something
>>
>> I don't like this for two reasons:
>>
>> 1) It's almost, but not quite, what we have right now. I'd much rather
>> do a *big* change over to <> so that it's obvious that a change has
>> occurred.
>> 2) I don't want to start gobbling up more symbols.
>>
>> I also am not really interested in using the percent sign for variable
>> interpolation in Hamlet/Cassius: dollar sign is well established for
>> this in many languages, and I only grudgingly used the percent sign in
>> Julius because of jQuery.
>>
>> If I'm not mistaken Greg, this means the part of your proposal which
>> is being excluded by this proposal would be multi-line tags, is that
>> correct?
>>
>> Michael
>>
>> > On Sun, Dec 12, 2010 at 3:00 AM, <web-devel-request at haskell.org> wrote:
>> >>
>> >> Send web-devel mailing list submissions to
>> >> web-devel at haskell.org
>> >>
>> >> To subscribe or unsubscribe via the World Wide Web, visit
>> >> http://www.haskell.org/mailman/listinfo/web-devel
>> >> or, via email, send a message with subject or body 'help' to
>> >> web-devel-request at haskell.org
>> >>
>> >> You can reach the person managing the list at
>> >> web-devel-owner at haskell.org
>> >>
>> >> When replying, please edit your Subject line so it is more specific
>> >> than "Re: Contents of web-devel digest..."
>> >>
>> >>
>> >> Today's Topics:
>> >>
>> >> 1. Re: proposal for hamlet-like syntax that is more compatible
>> >> with html (Michael Snoyman)
>> >> 2. Re: proposal for hamlet-like syntax that is more compatible
>> >> with html (Alexandros Salazar)
>> >> 3. Re: proposal for hamlet-like syntax that is more compatible
>> >> with html (Alexander Dunlap)
>> >>
>> >>
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 1
>> >> Date: Sat, 11 Dec 2010 17:48:48 +0200
>> >> From: Michael Snoyman <michael at snoyman.com>
>> >> Subject: Re: [web-devel] proposal for hamlet-like syntax that is more
>> >> compatible with html
>> >> To: Simon Michael <simon at joyful.com>
>> >> Cc: web-devel at haskell.org
>> >> Message-ID:
>> >> <AANLkTinumxoNV-efehgrVBUnoNUYvRB1ijC01aN6Pv=6 at mail.gmail.com>
>> >> Content-Type: text/plain; charset=ISO-8859-1
>> >>
>> >> Alright, at this point I've only heard positive things about this
>> >> syntax change. Does anyone want to volunteer to try and tackle this,
>> >> or will this need to wait till I can get around to it? Fair warning:
>> >> I'm likely to try to deal with the WAI + enumerator and xml-enumerator
>> >> tasks first. If someone wants to take a crack at the Hamlet changes,
>> >> I'll be happy to review things.
>> >>
>> >> Michael
>> >>
>> >> On Sat, Dec 11, 2010 at 2:38 AM, Simon Michael <simon at joyful.com>
>> >> wrote:
>> >> > I support this proposal's goal, and would be fine with rewriting my
>> >> > templates.
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > web-devel mailing list
>> >> > web-devel at haskell.org
>> >> > http://www.haskell.org/mailman/listinfo/web-devel
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 2
>> >> Date: Sat, 11 Dec 2010 11:17:37 -0500
>> >> From: Alexandros Salazar <nomothetis at gmail.com>
>> >> Subject: Re: [web-devel] proposal for hamlet-like syntax that is more
>> >> compatible with html
>> >> To: web-devel at haskell.org
>> >> Message-ID:
>> >> <AANLkTikxJfPFOnD8Fzo9-bpH9g8Z6S6n8aCwB9+kvbAM at mail.gmail.com>
>> >> Content-Type: text/plain; charset="utf-8"
>> >>
>> >> My belated 2c (sorry, work has been keeping me away from things Yesod
>> >> and
>> >> Haskell):
>> >>
>> >> 1. The key reason I switched to Yesod was Hamlet. I'm very new to
>> >> Haskell,
>> >> and I wanted to try developing a webapp in it; when I looked at the
>> >> various
>> >> frameworks, my main question was "What will require me to learn the
>> >> least
>> >> new stuff, while still giving me a full Haskell-based development
>> >> experience?" Yesod was the answer, because I was already familiar with
>> >> Haml.
>> >> So, it is one less thing a large swath of people need to learn when
>> >> they
>> >> decide to give Yesod a try. And at least in my case, it was a deciding
>> >> factor.
>> >>
>> >> 2. I'm not convinced closeness to HTML is a design goal. My experience
>> >> is
>> >> again limited, but I wouldn't expect many people to switch existing
>> >> projects
>> >> to Yesod (or really, from any framework to any other); therefore, the
>> >> idea
>> >> that someone will have a bunch of HTML to be converted as simply as
>> >> possible
>> >> to whatever templating language we use seems remote.
>> >>
>> >> 3. Along the same lines, the reason for the existence of templating
>> >> frameworks like Haml and Hamlet is precisely that people don't enjoy
>> >> writing
>> >> HTML: why would we constrain ourselves by similarity to something
>> >> people
>> >> have put large (and creative) amounts of effort into avoiding? I think
>> >> it
>> >> is
>> >> unduly limiting.
>> >>
>> >> 4. I do believe there are some issues with Hamlet; in fact, the issues
>> >> raised by Greg are exactly the issues I have. I don't see having a
>> >> Yesod-specific templating language as the solution, unless this new
>> >> syntax
>> >> gives Yesod such a big productivity boost compared to using Hamlet that
>> >> it's
>> >> worth putting in the effort.
>> >>
>> >> In brief, I think Hamlet is 95% of the way there, and that Michael has
>> >> done
>> >> a great job with it. It seems easier to take it another 4% and get it
>> >> to
>> >> 99%
>> >> than it would be to rewrite the syntax from scratch. I don't view HTML
>> >> similarity as a bonus (or a malus, either way). Maintaining (and
>> >> furthering)
>> >> similarity with Haml seems worthier goal, given how many people use it,
>> >> are
>> >> familiar with it, and love it; it will ease adoption.
>> >>
>> >> I hope this all made sense, and that I didn't start an argument about
>> >> bike
>> >> shed colors... ;-)
>> >>
>> >> Alexandros
>> >>
>> >>
>> >>
>> >> On Sat, Dec 11, 2010 at 10:48 AM, Michael Snoyman
>> >> <michael at snoyman.com>wrote:
>> >>
>> >> > Alright, at this point I've only heard positive things about this
>> >> > syntax change. Does anyone want to volunteer to try and tackle this,
>> >> > or will this need to wait till I can get around to it? Fair warning:
>> >> > I'm likely to try to deal with the WAI + enumerator and
>> >> > xml-enumerator
>> >> > tasks first. If someone wants to take a crack at the Hamlet changes,
>> >> > I'll be happy to review things.
>> >> >
>> >> > Michael
>> >> >
>> >> > On Sat, Dec 11, 2010 at 2:38 AM, Simon Michael <simon at joyful.com>
>> >> > wrote:
>> >> > > I support this proposal's goal, and would be fine with rewriting my
>> >> > > templates.
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > 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
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >> URL:
>> >>
>> >> <http://www.haskell.org/pipermail/web-devel/attachments/20101211/1d41e534/attachment-0001.htm>
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 3
>> >> Date: Sat, 11 Dec 2010 18:32:51 -0800
>> >> From: Alexander Dunlap <alexander.dunlap at gmail.com>
>> >> Subject: Re: [web-devel] proposal for hamlet-like syntax that is more
>> >> compatible with html
>> >> To: Michael Snoyman <michael at snoyman.com>
>> >> Cc: Simon Michael <simon at joyful.com>, web-devel at haskell.org
>> >> Message-ID:
>> >> <AANLkTinqnFVeCyOHLudnxpKGXWXFGmsHrFVX=6eBTivr at mail.gmail.com>
>> >> Content-Type: text/plain; charset=UTF-8
>> >>
>> >> I would prefer that the bikeshed stay the color it already is. ;) The
>> >> syntax is easier for me as it is different from HTML. The HTML-like
>> >> syntax looks to me like invalid HTML and is more difficult to read.
>> >>
>> >> Alex
>> >>
>> >> On Sat, Dec 11, 2010 at 7:48 AM, Michael Snoyman <michael at snoyman.com>
>> >> wrote:
>> >> > Alright, at this point I've only heard positive things about this
>> >> > syntax change. Does anyone want to volunteer to try and tackle this,
>> >> > or will this need to wait till I can get around to it? Fair warning:
>> >> > I'm likely to try to deal with the WAI + enumerator and
>> >> > xml-enumerator
>> >> > tasks first. If someone wants to take a crack at the Hamlet changes,
>> >> > I'll be happy to review things.
>> >> >
>> >> > Michael
>> >> >
>> >> > On Sat, Dec 11, 2010 at 2:38 AM, Simon Michael <simon at joyful.com>
>> >> > wrote:
>> >> >> I support this proposal's goal, and would be fine with rewriting my
>> >> >> templates.
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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
>> >>
>> >>
>> >> End of web-devel Digest, Vol 16, Issue 6
>> >> ****************************************
>> >
>> >
>> > _______________________________________________
>> > web-devel mailing list
>> > web-devel at haskell.org
>> > http://www.haskell.org/mailman/listinfo/web-devel
>> >
>> >
>
>
More information about the web-devel
mailing list