getInitialBody allow HTML

[sandro-pasquali]

Great library.

I'm using the following in my widget constructor to inject some HTML into the <span w-body></span> injection point of the widget body/template:

    getInitialBody: function(input, out) {
        return 'foo<p>bar</p>';
    },

However, the HTML is rendered escaped (foo<p>bar</p> is displayed, rather than being rendered as HTML)

In templates I can use the $!{data.name}! sequence to avoid escaping HTML. Is there something similar here? Or maybe a better way to dynamically inject content into the widget body?

[maberer]

you can prevent HTML escaping with $! http://markojs.com/docs/marko/language-guide/#text-replacement but be aware of XSS attacks.

Does this help?

[sandro-pasquali]

I can use that via a template instruction, but here I don't see a way of triggering that "flag" via the getInitialBody method.

I could also just pass the html along in the state and then use the $! construct in the template, but that isn't ideal for my case. I'd much rather just use the w-body injection mechanism.

[patrick-steele-idem]

Hey @sandro-pasquali, thanks for the feedback!

I just double checked the code and it looks like we are automatically escaping the string as a precaution: https://github.com/marko-js/marko-widgets/blob/022a181961369cfaf59880b34aa0c53880c1905f/taglib/helpers/widgetBody.js#L35-L37

That may have not been the most intuitive decision, but maybe the following workaround would work for you?:

getInitialBody: function(input, out) {
    return function(out) {
        out.write('foo<p>bar</p>');
    }
}

We wouldn't be able to change the existing behavior without risking breaking existing code, but it may be worth considering introducing a new getInitialBodyHtml(input, out) function as a more clear alternative and that would alternative would not escape strings.

Please let me know what you think.

[sandro-pasquali]

@patrick-steele-idem The workaround you've provided works great. Thanks.

Default escaping is fine (and you're probably right to escape first and ask questions later). As long as it's documented the given workaround is probably enough -- it's reasonable and easy to understand.

Thanks again.