The original official jQuery Templates plugin. This project was maintained by the jQuery team as an official jQuery plugin. It is no longer in active development, and has been superseded by JsRender.
3.23k
stars
1.01k
forks
source link
Newlines are not preserved in Internet Explorer (v8 -- others not tested) #85
Now suppose element #container has a styling of white-space: pre (like the pre tag by default). Obviously this is a matter for the style sheet, and should be none of the template renderer's business. All he wants to be doing is make sure he generates the correct tree of DOM nodes.
This bug messes up this separation of concerns. All of a sudden the templating solution must be aware of the white-space styling of any piece of the DOM tree, as it will have to make sure that it avoids executing lines of code like the one above, and instead replace them with a work-around.
These work-arounds are heavily context-specific, making them a big burden for me (the developer). F.e. in our scenario we could end up with horror like:
Note how all of a sudden our JavaScript code has to make a lot of assumptions about the semantics of the template. Red flag!
I hope I managed to illustrate this issue some more, and why it is important (to me for sure, but I believe in general).
timmolendijk November 25, 2010
Oh just one thing I'd like to add. I think the solution to this problem can be as simple as stop using $.fn.html() to create and insert DOM nodes, and instead use $.fn.append(). Background discussion can be found in the jQuery ticket.
Thanks for taking the time to submit this issue. Just wanted to let you know this plugin is no longer being actively developed or maintained by the jQuery team. See README for more info.
Copied from https://github.com/nje/jquery-tmpl/issues#issue/30:
Created 5 months ago by timmolendijk WebKit:
IE8:
This issue most probably originates from a bug in jQuery's .html() -- see http://dev.jquery.com/ticket/7138
Comments timmolendijk November 25, 2010 The relevance of this issue has not faded. Real-life use case:
Now suppose element #container has a styling of white-space: pre (like the pre tag by default). Obviously this is a matter for the style sheet, and should be none of the template renderer's business. All he wants to be doing is make sure he generates the correct tree of DOM nodes.
This bug messes up this separation of concerns. All of a sudden the templating solution must be aware of the white-space styling of any piece of the DOM tree, as it will have to make sure that it avoids executing lines of code like the one above, and instead replace them with a work-around.
These work-arounds are heavily context-specific, making them a big burden for me (the developer). F.e. in our scenario we could end up with horror like:
Note how all of a sudden our JavaScript code has to make a lot of assumptions about the semantics of the template. Red flag!
I hope I managed to illustrate this issue some more, and why it is important (to me for sure, but I believe in general).
timmolendijk November 25, 2010 Oh just one thing I'd like to add. I think the solution to this problem can be as simple as stop using $.fn.html() to create and insert DOM nodes, and instead use $.fn.append(). Background discussion can be found in the jQuery ticket.