Allow top-level text nodes in whitespace braces

[thumphries]

It's pretty annoying to need to do {{ "foo" }} to produce a text node from a string literal, and likewise it can be hard to tell when exactly you're writing HTML vs an expression. Might make sense to allow {|foo|}, with {||} always implying HTML mode.

Suggestion from Russ

[russmaxdesign]

Adding HTML inside expression blocks is slightly problematic. From what I can tell, there are only two options:

Option 1: Force wrapping an HTML around the content:

{
  bikeshed/modules/layout/container
    <span>Lorem ipsum dolor sit amet, consectetur</span>
}

Option 2: Using an HTML string

{
  bikeshed/modules/general/lozenge Lozenge0
    {{ "0%" }}
}

The problem with option 1 is that it forces authors to wrap the content inside a new element.

This can lead to potential issues such as:

1. Adding an unnecessary element to the markup
2. Adding an incorrect element to the markup. It is possible for authors to wrap a <div> element around content that is then placed inside an inline element. And projector does not currently flag this as an error.

One solution would be to use the new wraping symbols to define ANY HTML content - regardless of whether it is a block or a string.

{
  bikeshed/modules/layout/container
    {|
      Lorem ipsum dolor sit amet, consectetur
    |}
}

{
  bikeshed/modules/general/lozenge Lozenge0
    {| 0% |}
}

{
  bikeshed/modules/layout/container
    {|
      <div>Lorem ipsum dolor sit amet, consectetur</div>
      <p>Lorem ipsum dolor sit amet, consectetur</p>
    |}
}

[thumphries]

Agree.

Although it was my idea, I am concerned about reusing {| |} for this, since it implies significant whitespace where there may be none. Ideally we'd come up with another set of brackets...

[damncabbage]

I'm... not sure.

I definitely agree that adding the extraneous tags is the wrong option (eg. https://github.com/ambiata/bikeshed/blob/d195f2942cfe1614e5598883e2c8219d9908345a/modules/general/tooltip/template.prj#L11), and that we should at least be using {{ "0%" }}, or ({{ "Hello, " }} <i>World</i>) for the side-by-side text + html case. This knocks out both 1 and 2 from Russ' example.

Our weird projector language rules are:

1. You can start (and end) an Html expression by using an HTML element, eg. <div>
2. You cannot create an Html expression with regular text, eg. hello; you need to use text ... or the text shortcut {{ ... }}.
3. 1 and 2 means you can't have foo <i>bar</i> baz as a line in projector, as a top-level expression.
4. You can use regular text inside an Html expression. This is a shortcut, eg.
   <p>Hello, </b>World</b></p> instead of
   <p>{ text "Hello, " }<b>{ text "World" }</b></p>.

I think it's number 4 that's causing the weird "where am I?" / "what can I type here?" disjoint feeling. You have regular text which is fine in some spots, and wrong in others. BUT, it's incredibly convenient.

I'm not sure what the fix is, but this {| ... |} feels like a bandaid. :S

[damncabbage]

Agreed about not re-using {| |} as well.

And either way, this would leave us with five special brackets:

• { ... } for Projector Expression.
• {{ ... }} for String -> Html
• {{ ... }} for String -> Attribute String
• {| ... |} for Whitespace-Sensitive String -> Html
• ??? for Html -> Html

[thumphries]

I'm not sure what the fix is, but this {| ... |} feels like a bandaid. :S

There's no other fix short of mandatory HTML brackets around all HTML blocks, which we almost certainly don't want.

{{ "foo" }} is a little verbose but is serviceable, if you find yourself doing it all the time it may be worth restructuring to pass strings around instead.

[damncabbage]

IRL chat result: we're deferring this for a week while we convert templates, to figure out common annoying patterns.