These are chat archives for codexa/firetext

2nd
Jan 2015
Josh Smith
@joshua-s
Jan 02 2015 15:36
@twiss do you think that this section gives us a performance problem: https://github.com/codexa/firetext/blob/develop/scripts/firetext.js#L1038
@jackd1 too ^
I have been thinking that maybe we should move away from this structure
Daniel Huigens
@twiss
Jan 02 2015 16:38
I ran some profiles in Chrome, and I could get it to show up (nothing significant, but I'd believe you if you told me that was different elsewhere). One other drawback of the current thing is that (as https://github.com/codexa/firetext/blob/develop/scripts/firetext.js#L986 hints to) it diminishes some of the benefits of CSP. So :+1: from me for event handlers directly on the elements somehow.
Josh Smith
@joshua-s
Jan 02 2015 16:49
The event handlers will definitely be more difficult and lengthy to implement. I think we should include a separate script for them.
interface.js?
Also, it does indeed diminish the effects of the CSP. The processActions() script is basically a limited form of eval()
Also, it does indeed diminish the effects of the CSP. The processActions() function is basically a limited form of eval()
I'm going to file an issue.
Daniel Huigens
@twiss
Jan 02 2015 16:53
Maybe the easiest thing to do is create a file which does getElementById().addEventListener(..., processActions...)
Josh Smith
@joshua-s
Jan 02 2015 17:31
Hmm would that solve the security issue (the actions are still defined in the markup)
Daniel Huigens
@twiss
Jan 02 2015 22:40
I meant something like document.getElementById('bold').addEventListener('click', processActions.bind(null, 'formatDoc', {action: 'bold'})) OR document.getElementById('bold').addEventListener('click', function() { processActions('formatDoc', this); }) and leave data-click-action in the markup (the latter requires no changes to processActions, but is identical performance-wise). Of course there are numerous other ways to do it.