Can I bind to dynamically generated DOM elements?

[Vicary A.]

Thanks for the work, this is beautiful.

I am looking for a light-weight text editor like this to apply in a CMS.

Instead of grande.bind() or grande.init() to the whole document, can I apply this to part of the DOM just when the editable area is generated?

[Yannick Lohse]

Right now this is not possible without altering the code, but I think it would be a good feature. The ability to scope grande.js to only a subset of the DOM seems necessary if it needs to be easily embedded into existing systems.

[Matt DuVall]

@vicary Thanks!

This really has to be done for it to be embedded on other webpages, I have a few questions about this though:

1. The current DOM handlers for the document and window would be have to stay to support resizing and blur at the document level to trigger the toolbar to be off. Is this the best we can do at the moment?
2. Passing in a HTMLElement will be useful for bind although the coupling to having article and section will still exist and seems more semantic than ad-hoc declaration of the editable area. Would the dynamically generated HTMLElements still contain section and article?

[Vicary A.]

@mduvall

1. Retaining the resize handler upon script load wouldn't be hurting, just make sure it iterates through all binded instance.
2. You can force that as your own spec, users could adapt. I personally like any kind of encouragement to HTML5.

For whatever approach of your choice, disposal (manual or automatic) and memory leaks could be overlooked easily, esp. when porting scripts from static to dynamic.

[Yannick Lohse]

1. For the blur, we could listen to the actual blur event on the node level. This requires proper testing but I think it should work. The resize is probably best at document level. There's also the triggerTextParse function which is triggered on document-level keydowns that would need addressing.
2. i don't know about that one. I feel like embedders should decide for themselves what is semantically best for them. IMHO, grande could turn any DOM element passed to bind into a content editable node and work on that and it would be perfectly fine with me.

[Matt DuVall]

@vicary @y-lohse Sounds good I'll look into parameterizing the grande.bind with the DOM elements to bind to!

[Matt DuVall]

Fixed via 9a1b5c4. grande.bind now takes an optional argument NodeList to bind to.

[Zachary Zimbler]

@mduvall so with the NodeList feature/fix is it supposed to solve attaching the editor to specific nodes? Something I've noticed is that if you have other content on the page and then highlight that text it brings up the editor even though it's not editable. Perhaps instead of worrying about changing blur events, etc to the local node, just throw a check in the triggerTextSelection() to see if the node you are currently highlighting is actually one of the editable nodes that you passed in.

I guess my situation also presumes using the editor on more than just article elements.

[Zachary Zimbler]

What about this to check editable nodes?

for(var i = 0; i < editableNodes.length; i++) {
    if(document.activeElement === editableNodes[i]) {
        console.log('we can actually edit this element');
    }
}

or pop it into a separate function like so and then check if true in triggerTextSelection to either show the editor tooltip or not...

function isCurrentNodeEditable() {
    for(var i = 0; i < editableNodes.length; i++) {
        if(document.activeElement === editableNodes[i]) {
            return true;
        }
    }
    return false;
}

[Matt DuVall]

Yeah that sounds good to me, would eventually like to move away from the document-level event bindings as well! 👍