<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Yoval,&nbsp;<br><div><div>Le 7 mars 2013 à 17:48, yoval p. a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family:Verdana"><span style="font-size:12px">Hi,<br><br>I've been giving matthias's comment some thought re nbviewer support<br>for javascript views, and also considered the intention of disabling javascript<br>due to security-concerns.<br><br>Here is a solution to both issues that I'd like to suggest:<br><br>There's a need to separate static HTML from HTML bearing<br>javascript which might only be renderabe dynamically, call it dynamic HTML.<br><br>My suggestion is that the display protocol be modified&nbsp; so that the semantics of<br>`_repr_html_` would mean static HTML only, and a new `_repr_jshtml_` (however named)<br>magic method would be supported, under which objects would implement<br>dynamic views.<br><br>This provides the following benefits:<br>- Objects can provide HTML representation of themselves suiting<br>the environment they are in. It's the front end that chooses the<br>representation it supports. So there will be no further need to sniff<br>qtconsole vs. IPNB via `get_ipython().config`.<br>In particular, nbviewer could leverage this to allow even dynamic views<br>to gracefully degrading in order to cooperate.<br>- For security reasons, the use of '_repr_jshtml_' view by IPYthon would be <span id="misspelled-optin" name="misspelled-optin">behind<br>an opt-in mechanism</span>, and the static&nbsp; `_repr_html_` would be sanitized/sandboxed.<br><br>The IPython.core.display functions could be extended accordingly to<br>obey the currently active security policy.<br><br>Thoughts?<br></span></span></blockquote><div><br></div><div>What you describe look IMHO to much to the current _repr_html_/_repr_javascript_, we had quite some time to think about it,&nbsp;</div><div>and something in those line was my first idea,&nbsp;but dealing with displaying javascript is both much more complicated than it looks.</div><div>We are also &nbsp;certain that we can have a more general approach.</div><div><br></div><div>(Keep in mind that, thinking of the display protocol as only html/js notebook/qtconsole is also much too restrictive)</div><div><br></div><div>In short, we believe using _display_json_ is the right way and is enough.&nbsp;</div><div><br></div><div>Most of the time, when you display js, the only thing you want to send are data that need to be interpreted.</div><div>Javascript plugin should be js files loaded as extension, you shouldn't need to display generated code.&nbsp;</div><div>This allow also to depend on other installed plugin without having to embed lib like jQuery etc at every call.</div><div><br></div><div>In framework like chromium embeded, you cannot in any way execute code that are in script tag. The js</div><div>**have to** be part of the application at launch time.</div><div><br></div><div>With the architecture we planed, rewriting _display_javascript_ should be totally possible as simple small plugin</div><div>it will just not be supported.</div><div><br></div><div>As for nbviewer, if there is a _repr_json_ , nothing prevent it from using it in html to have dynamic represent,&nbsp;</div><div>but the same json could be use to make a Tikz representation in latex, or even multiple plugin could be able to interpret the same json.</div><div><br></div><div>So after long repletion, I am convince that json-repr is the way to go.</div><div><br></div><div>We'll still consider the suggestion of course, and discussion are welcomed.&nbsp;</div><div><br></div><div>--&nbsp;</div><div>Matthias</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><span style="font-family:Verdana"><span style="font-size:12px"><br>Yoval<br><br>Matthias BUSSONNIER write:<pre>&gt; Hi y-p ! 
&gt; 
&gt; Look really nice ! 
&gt; 
&gt; Did not have time to look into the source right now, but I'll definitively will. 
&gt; Do you think  the data exchanged with the kernel in some cases could be store either in the metadata of cells, 
&gt; or in the Json representation of displayed object ? 
&gt; 
&gt; If we do this and by carefully crafting the "js plugin"  they could be loaded by nbviewer and read sone data in the dom injected. 
&gt; Which would allow a limited interactivity on nbviewer. 
&gt; 
&gt; Do you rely on display_javascript for the initial loading of javascript ? or inject &lt;script&gt; tag in a display HTML 
&gt; If you do , this can be problematic in the future. 
&gt; 
&gt; -- 
&gt; Matthias</pre></span></span>
_______________________________________________<br>IPython-dev mailing list<br><a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>http://mail.scipy.org/mailman/listinfo/ipython-dev<br></blockquote></div><br></body></html>