luisivan
commented
10 years ago +1, this way Ractive would be CSP compliant
Closed nwmcsween closed 10 years ago
Rich-Harris
commented
10 years ago I'll be honest, I'm not sure I see the value here. I respect what the Polymer project is aiming to do, and in general I approve of the W3C 'paving the cowpaths' trod by JS library and framework authors, but I've been following a lot of the development around these new specs and I can't get excited about them.
The <template> element in particular seems like a step backwards - even with Polymer's data-binding extensions it's pretty inflexible (you can't nest templates inside other templates without activating them all separately... wha?), and the style of programming it encourages is the kind of crufty old ad-hoc DOM traversal and manipulation that led people to use string-based templating engines in the first place.
The draft specs seem to be changing pretty rapidly (especially around data-binding AKA model-driven-views), and they may look much better in a few months' time, but in the meantime I think it would be a mistake to try and use something that is in a state of flux, especially given that it isn't backwards compatible.
There's a separate issue which is around Ractive's philosophy specifically. Unlike templating engines that interpolate strings (like Handlebars) for innerHTMLing, or data-binding libraries like Knockout that automatically manipulate pre-existing DOM, Ractive works by parsing the template string and creating a parallel DOM. That way, it's able to make smart decisions about how to manipulate the real DOM, including triggering transitions and animations, and efficiently binding event handlers. For it to work with templates that lived inside the <template> element, it would have to stringify them first, which defeats the object of <template>. So even though support for languages other than mustache is on the roadmap (albeit not for a while), <template> wouldn't be among them as it's solving a fundamentally different problem.
@luisivan I don't know much about CSP - can you elaborate please? I'd be interested to know why Ractive isn't CSP compliant and what it would have to do differently to become so.
Closing this as wontfix but happy to continue the discussion.
luisivan
commented
10 years ago @Rich-Harris The CSP (Content Security Police) is a layer added to mitigate some very common attacks as XSS and arbitrary injection, it works not allowing the load of inline scripts, eval and other stuff that you can read at http://people.mozilla.org/~bsterne/content-security-policy/details.html
I found out that probably the unique reason of RactiveJS not being CSP compliant is the use of inline scripts to define templates, so using any other tag would fix that.
Apps that use native resources on Firefox OS must be CSP compliant, and as a Firefox OS developer I would love to use RactiveJS in my apps without having to patch it before.
Rich-Harris
commented
10 years ago Ah, I see, thanks. You can use any string source - the use of script tags is totally optional, it's included as a convenience because it saves having to load stuff via AJAX if you're just doing something small.
When you do...
ractive = new Ractive({
el: 'body',
template: '#tpl'
});...Ractive determines (from the '#' character) that it should look for an element on the page with the 'tpl' ID, rather than treating '#tpl' as a template in its own right. That element doesn't have to be a script tag - it can be anything. But script tags are nearly unique in that their contents are not turned into DOM. That's important, because all other elements (including <template>) must contain valid HTML.
For example, this...
<table>
<thead>
<tr><th>#</th><th>Player</th><th>Score</th></tr>
</thead>
<tbody>
{{#players:i}}
<tr><td>{{i+1}}</td><td>{{name}}</td><td>{{score}}</td></th>
{{/players}}
</tbody>
</table>...is not valid HTML because the only thing that can be an immediate child of a <tbody> element is a <tr> element - no text nodes. So if you had that inside a <template> instead of a <script>, the browser would break it before Ractive got a chance to parse it.
So in summary
Unfortunately, reading that document, there's another reason Ractive won't be CSP compliant - the Function constructor is banned because it's a form of eval. It's used internally to create functions to evaluate expressions (e.g. the {{i+1}} mustache in the example above) - it's totally safe, since it's just rehydrating JavaScript that was previously parsed and determined safe, but there's no way for FirefoxOS to know that. Not sure how to deal with this problem.
luisivan
commented
10 years ago Oh right, thank you.
Yeah, I reviewed Ractive's source code and couldn't think of a workaround... Anyway, Ractive is a piece of awesomeness, keep up the good work!
kristianmandrup
commented
9 years ago I wonder why it has become so fashionable that every framework has to have their own template parser to build their own custom virtual DOM. Looking at the parser code... here the comment converter
comment = {
t: types.COMMENT,
c: content
};
if ( parser.includeLinePositions ) {
comment.p = parser.getLinePos( start );
}
return commentWhy not open up this API for other parsers to be created or even allow for the render to use some javascript API similar to Mithril or React.js which can generate such Virtual DOM nodes without having to go through a template parser?
Cheers ;)
nwmcsween
commented
9 years ago You may want to look at mercury, it simply uses virtual-dom, you can create whatever parser you want. On 15 Nov 2014 04:17, "Kristian Mandrup" notifications@github.com wrote:
I wonder why it has become so fashionable that every framework has to have their own template parser to build their own custom virtual DOM. Looking at the parser code... here the comment converter
comment = { t: types.COMMENT, c: content }; if ( parser.includeLinePositions ) { comment.p = parser.getLinePos( start ); } return comment
Why not open up this API for other parsers to be created or even allow for the render to use some javascript API similar to Mithril or React.js which can generate such Virtual DOM nodes without having to go through a template parser?
Cheers ;)
— Reply to this email directly or view it on GitHub https://github.com/ractivejs/ractive/issues/285#issuecomment-63170361.
zlamma
commented
9 years ago Hi,
One advantage of allowing to consume mustaches from <template> would be that they could finally have <script type='text/javascript'> nested in them. This is not possible in <script type='text/ractive'> due to how browsers interpret the first </script> tag as the end of the main script.
I found that Angular also noticed the problem and they seem to be looking at the template tag as a solution.
I am currently using your single-file-components, which I'm in love with because of how they give me choice of maintaining super high code cohesion where I need it. However, this little nuisance hinders it a bit.
A nice step would be to make Ractive support taking its templates from both of these element types.
Madgvox
commented
9 years ago Perhaps I'm just thinking too narrowly, but what applications would embedding script tags inside templates have? I can't think of anything you can do that you couldn't do with the existing code space.
zlamma
commented
9 years ago In the spirit of keeping related things together, like in the single-file-components:
When developing templates with rich HTML controls that achieve their logic solely by decorating HTML (think jQuery plugins like datepickers, dropdowns, autocompletes) it is useful to keep the implementation details in the template only (especially which of the hip .js libraries were chosen to fill in the gaps in the ever-changing HTML featureset), so that the Ractive component contains just the lean data model, completely unaware of its HTML structure.
Putting the HTML initialization in the <script> inside the template allows you to achieve just that.
Note that this is not a limitation of whole Ractive. As long as you use separate files for your templates/partials/components, Ractive does allow your to have </script>. It's just when you choose to put your ractive code inside a <script type="text/ractive">.
There are good reasons for the inlining into such a script tag (performance, making page self contained - another one in the spirit of 'keeping related things together'!) so, whenever you feel it would be useful to you, this limitation comes as an annoying surprise.
Polymer provides a pollyfill for the tag with extensions that allow mustache style interpolation http://www.polymer-project.org/platform/template.html http://www.html5rocks.com/en/tutorials/webcomponents/template