Late thought: think of operate as the ETL pipeline of CableReady.

I like where this is going, and want to float an idea to see if we can push the concept further. What if we introduce a promise to facilitate the delay and move the before & after hooks into operate? Not sure if it will work but it might look something like this.

const operate = (element, operation, callee, callback) => {
  before(element, callee, operation)
  if (!operation.cancel) {
    if (operation.delay) {
      new Promise((resolve, reject) => {
        setTimeout(() => resolve(callback()), operation.delay)
      }).then(() => after(element, callee, operation))
    } else {
      callback()
      after(element, callee, operation)
    }
  }
}

The operations could then further simplify to something along these lines.

append: (operation, callee) => {
  processElements(operation, element => {
    operate(element, operation, callee, () => {
      const { html, focusSelector } = operation
      element.insertAdjacentHTML('beforeend', html || '')
      assignFocus(focusSelector)
    })
  })
}

I also wonder if passing callee around is necessary. Isn't that data already in the operation payload? At the very least we could pass it explicitly from within the operation's method itself. Perhaps something like,

append: (operation) => {
  processElements(operation, element => {
    operate('append', element, operation, () => { ...

Hey, my head hasn't been in this for a few months but:

• I had a really frustrating night proving to myself that modern browsers have made it impossible to interrogate callee and caller from inside or outside (respectively) for "security" reasons, effectively hamstringing metaprogramming. If it's possible to do this without passing in the callee, that'd be great! I just don't actually have a way worked out. If you do, please jump in!
• Not every operation has events, so moving them into operate creates some edge cases which would make things messy
• If I'm misunderstanding, don't be shy

Not every operation has events, so moving them into operate creates some edge cases which would make things messy

That's a very good reason to keep before and after out of operate; though, I think using a promise in operate may have some merit.

I think we may be able to avoid passing callee around everywhere. Will try to take a stab at that tomorrow if possible.

I'm excited to make this even cleaner. Passing in the callee is a total PITA, I (clearly) just wasn't able to find a more ninja path.

Just to think for a moment about your proposal to move before and after into operate:

I'm also in the process of moving play_sound out of the core, and it is - by far - the ugliest complication wrt after events. So, depending on how that goes, it could be that my hesitation to standardize ends up disappearing.

That would mean that we'd add events to operations that really don't make sense to have events, most specifically dispatch_event. Do we need a before-dispatch-event event? Probably not. Is it terrible if there is one? Probably not.