On Fri, Oct 28, 2011 at 2:47 PM, Ojan Vafai <o...@chromium.org> wrote: > On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor <a...@aryeh.name> wrote: >> It's a few extra characters. I really think the increase in clarity >> is worth it. Boolean parameters are much more confusing, and should >> be avoided wherever possible. > > +1. I'm also OK with the argument if it's a string.
Jonas? > Another use-case: a (possibly collaborative) slide editor (e.g. Google > Presentations). Imagine that each text box in a slide is a contentEditable. > You want adding/removing textboxes and/or slides to be manual transactions, > but actual text editing in the text boxes to be automatic. And you want all > this in the same undo stack. Well, there are two possibilities: 1) When undoing the manual transactions, the author intends to get back to the exact same DOM as before. In this case, it's no problem if the UA enforces this automatically: it's just doing what the author wanted. 2) When undoing the manual transactions, the author does not intend to get back to the exact same DOM as before, maybe because someone else has modified it. In this case, automatic transactions are useless anyway. The UA's best effort will not be what the author wants, particularly if it's undefined. For instance, in a collaborative editor, if someone else has added some text that shouldn't be undone, the UA will fail randomly. Thus the author cannot rely on automatic transactions and will have to do the merge resolution themselves. In other words, even in a collaborative editor, what would be a case where automatic transactions would actually be useful? They'll just fail randomly with undefined behavior. So suppose we have some hypothetical collaborative editor. What's an example sequence of mixed automatic and manual transactions that would occur where the automatic transactions will reliably work, but the manual transactions can't also be automatic?