marko-body attribute not documented in the language guide

[cdhowie]

The language guide makes no reference to the marko-body attribute. This attribute is necessary to keep Marko from interpreting inline scripts or inline CSS, but without being documented it's difficult to find this mechanism at all.

[patrick-steele-idem]

Thanks for opening the issue @cdhowie. You are right that it is missing from the language guide. We did document this feature in the "What's New in Marko v3", but we did not move over those docs into the language guide: http://markojs.com/docs/marko/what-is-new-marko-v3/#tag-body-content-parsing

On a related note, marko uses htmljs-parser and that parser automatically switches into parsed-text mode when parsing both <script> and <style> tags (see: philidem/htmljs-parser/Parser.js. This means that the parser won't recognize HTML tags inside <script> and <style> tags since those tags do not contain HTML. Therefore, you should very rarely need to know about the marko-body attribute. You should only need to know about marko-body text if maybe you are creating a custom tag that allows non-HTML content to be nested. When creating a custom tag you can specify the body parse mode as shown below:

src/components/my-script-wrapper/marko-tag.json:

{
    "body": "static-text",
    "preserve-whitespace": true
}

Hope that helps!

I'm keeping the issue open so that we update the docs. We are currently extremely busy with all the work associated with the upcoming Marko v4 release so if you would be interested in fixing the docs, please feel free to submit a PR to the following docs file: https://github.com/marko-js/marko/blob/master/docs/language-guide.md

[cdhowie]

This means that the parser won't recognize HTML tags inside <script> and <style> tags since those tags do not contain HTML. Therefore, you should very rarely need to know about the marko-body attribute.

In our case we had ${ without a matching } (code that didn't intend to invoke Marko at all) and this caused an error. I'd shudder to think what would've happened if it silently transformed something causing weird changes in behavior without any warning. I mean it makes sense that maybe you want to ${JSON.stringify(foo)} in the middle of a script tag, though it seems a bit dangerous to me that expressions are enabled in script tags by default. I do understand the logic of keeping it consistent with other tags, however, and obviously it would be a breaking change, so I'm not suggesting that... just kind of musing.

Anyway, documenting marko-body would've at least made it easier to correct the problem when we figured out what it was.

I suppose the correct approach is just not to have inline JavaScript at all -- but sometimes that's nice for testing a quick template mock-up.

[patrick-steele-idem]

To be honest, I could probably be swayed towards making the default static-text (instead of parsed-text) for <script> and <style> tags in Marko v4. Allowing expressions in <script> blocks was kept around because a lot of earlier developer were doing something similar to the following:

<script>
window.foo = ${JSON.stringify(bar)};
</script>

On a related note, marko has special escaping rules for expressions inside the <script> tag to make sure </script> does not get rendered inside a string.

Marko v4 will integrate Marko Widgets and make it much easier to serialize extra data/state down to the browser that then gets passed to the widget constructor.

Anyway, documenting marko-body would've at least made it easier to correct the problem when we figured out what it was.

Agreed. Keeping this issue open so that we at least fix the docs with Marko v4.

/cc @mlrawlings @philidem Thoughts?

[DylanPiercey]

Looks like the documentation was added https://markojs.com/docs/core-tags/#codemarko-bodycode