Feature Request: Nesting Syntax #936

jpillora opened this Issue Mar 22, 2013 · 36 comments


None yet

9 participants


So instead of having to do:

      | some text
      code some code
      | and some text

maybe we could do:

   div some text [ code some code ] and some text

so it would treat everything inside the [ ] as it's own line then continue with the text node

not sure if this is a silly idea, thought id throw it out there


-1 that'd mean I couldnt write text with brackets in in it


Indeed, we already have some basic interpolation syntax so you can write:

div some text #{code some code} and some text

If you need JavaScript interpolation of a value. If you need to interpolate jade, you'll have to just use multiple lines, it's a nightmare to read any other way anyway.


Don't think JavaScript interpolation, is what I need...

I agree its good practise to split out long text nodes over multiple lines, so maybe it's a bad idea to allow something like the proposed. Though I've got lots of text nodes like:

      | See 
      a(data-link='topic') A Topic 
      | for more information.

@Nami-Doc yes, [ ] is a bad choice, though it's just arbitrary, though if were allowing CoffeeScript type interpolation, then maybe it could be #( ), #[ ], the syntax isn't so important, it's more about the feature.

  .tip See #[a(data-link='topic') A Topic] for more information

Also, the first example, the space after 'See' is important yet theres no way to tell whether it's there or not, whereas you can in the second.

Anyway, just food for thought.


I'd say the best bet is to just use markdown when you need it:

  See [A topic](#topic) for more information

Alrighty, I'll do that for now (though no custom attributes 😞 ). If I were to add it (with the optimal syntax), do you think the PR be considered ?


.tip See #[a(data-link='topic') A Topic] for more information

Actually, I find that quite cool.




The PR would be considered, my concern is that jade is already becoming very complex. I'm inclined to say it mostly needs fewer features not more. I'm happy to discuss a pull request though and I'd probably leave it to @visionmedia to have the final say 😄


This would fix the "jade|haml sucks for content" and isn't markdown rendered at runtime? That's slow :(
Otherwise I'd agree to get jade a bit lighter


To prevent people from shooting themselves in the foot, it could restrict usage to one node and to one level of nesting, so people won't try to do: #[a(href="..") #[button text #[anotherNode text ] ] ]

Maybe if we can get TJ's input on this before any work is done, it will save time...

shesek commented Mar 23, 2013

I'm +1 on this. Having to split the code over multiple lines just to get some HTML in there is the only thing that really bothers about jade's syntax.

Also, the first example, the space after 'See' is important yet theres no way to tell whether it's there or not, whereas you can in the second.

That's also a good point. I have those invisible spaces at the end of line all over the place. Its not clear that they're there, or why they're there for. When I started using jade, I instinctively removed those end of line spaces because I forgot they're actually needed... even tho I put them there to begin with. And programmers that I work with also occasionally remove them. I ended up adding a big bold note about those end-of-line spaces in our style guide to avoid that.


I instinctively removed those end of line spaces because I forgot they're actually needed... even tho I put them there to begin with. And programmers that I work with also occasionally remove them.

I usually do = 'text ' to be clear :p

It keeps coming up, and I don't think it is a valid concern, that if you make the language allow nesting, that people will start writing bad code. Although it would be possible to write some pretty confusing stuff with nesting, it is better to simply explain to people how to do it better, rather than trying to restrict the possibilities of the language.

Just look at javascript for example, it is pretty easy to write bad code in such a versatile language, but I would hate to have features stripped to attempt to make it conform to one standard.

There are many examples, where inline jade snippets would make the code more readable and maintainable.

I would like to see inline snippets implemented, and explain that it is bad practice to use nesting if it can be avoided, and preferred for use with inline over block elements.


Fine with me, we just need an implementation of #[jade code here] If I see a decent pull request, I'll merge it.

For consistency with #{ code } I think ${ jade } is better than #[ jade ]. Any opinions?


#[] because there's no JS in it. ${} looks like es6 syntax


Where could that appear in ES6? I'm not aware of anything that could make ${} valid JS outside of a string or comment?


I still think I prefer #[] personally.


${} valid JS outside of a string or comment?

Can't remember the actual name, but I'm talking about Some string ${value}


Ah, yes. That is inside a string, but since it has special meaning I think we should make sure we preserve its normal meaning.

This should wait until #962 is merged, then it can use character-parser to parse the bracketed expression so we don't get in a mess when people put arrays inside it.


👍 for #[ jade ] It'd be easier to confuse #{ } with ${ } than #[ ]. I think it's better to be clear that you're inside a jade block as opposed to a js block.

Re: Silly nesting: Maybe just disallow nested inline jade (not sure how hard that'd be to implement though)

@ForbesLindesay Looks like you've merged #962, that should make this feature relatively easy to implement right ? I can have a look at doing this if no one else wants to


That would be awesome. I'm inclined not to worry too much about people abusing this feature with lots of nesting.

wmayner commented May 3, 2013

+1 for this, it's only thing I don't like about Jade so far.

jpillora commented May 4, 2013

Sorry guys, haven't had the time start on this yet, does anyone else have the time ?

itzaks commented Jun 4, 2013


jpillora commented Jun 4, 2013

Yeah this would be handy indeed. Looking through the source now though, I'm assuming it'll be sort of a combination of the : feature and the #{ } feature, though it'd be quite a while before I get anywhere. @ForbesLindesay, any tips for me ? Is this a big change ?

Any progress on this?


Sorry, been swamped, haven't had a chance to dive into the source

On Mon, Jul 29, 2013 at 11:04 AM, Billy Moon notifications@github.comwrote:

Any progress on this?

Reply to this email directly or view it on GitHubhttps://github.com/visionmedia/jade/issues/936#issuecomment-21694955

wiz commented Sep 11, 2013

#[] is somewhat error-prone to type because you have to untap shift before proceeding to type []. #{} however is typed in one stroke. And this is even more rage-inducing whan most of other systems are using curly braces for everything. I remeber using perl's TT2 with its [% %] - such a PITA...


That's with qwerty keyboards tho, I have to use alt gre for { and [ :(.


I've just gotten used to using raw mode . with vanilla html:

  some text <a href="link">link text</a> some more text

I write #[happy days] without touching caps at all on my standard qwerty UK keyboard, and I have to press and release shift for #{mondays}.


@billymoon I have the same, and have never felt that the shift is a significant enough problem to warrant fixing.

@ForbesLindesay ForbesLindesay referenced this issue Oct 17, 2013

Roadmap #1254

0 of 10 tasks complete
lydell commented Nov 28, 2013

If this comes true, I wouldn't use vanilla html inline tags anymore. Actually, I'd expect

  some text <a href="link">link text</a> some more text

to be escaped:

<p>some text &lt;a href="link"&gt;link text&lt;/a&gt; some more text</p>

but that would break backwards compatibility big time. Just sayin'. (Thinking about Python's "there's only one way to do it" and doing what people expect ...)

@ForbesLindesay ForbesLindesay pushed a commit that referenced this issue Dec 10, 2013
Forbes Lindesay Support inline tags
[closes #936]

Implemented, and pull request submitted. This will be released in v1.0.0

@lydell at the moment we support inline HTML all over the place. I kind of like that: it makes the transition easier.


Nice work @ForbesLindesay

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment