Thanks for the feedback. We need more developer feedbacks on this spec. On Jul 5, 2012 1:50 PM, "Yuval Sadan" <sadan.yu...@gmail.com> wrote: >> >> >> Passing in objects containing one or more non-callback properties is also an increaingly common pattern, and we are trying to replace legacy APIs that took lots of positional arguments with options-object based replacements (e.g. init*Event). From the point of view of a javascript author there is no difference between something like {foo:true} and {foo:function(){}}. Insisting that there should be a difference in DOM APIs because of low-level implementation concerns is doing a disservice to web authors by increasing the impedence mismatch between the DOM and javascript. >> > I read the conversation but still feel I'm stepping into other people's business; I'll still pitch in my author point-of-view: > > A. Are there any other APIs where a JS object representing an atomic piece of data is passed as an interface-less object to a DOM function? I don't think this includes options-objects, which are meant to, imo, alleviate the pain of optional arguments. > > It seems helper functions with position-based arguments are more common: addEventListener, createElement, createObjectURL, and more notably pushState/replaceState (in history, which also have to do with saving atomic records, and historical ones to that). > > B. On the other hand, are there APIs where objects with interfaces are created explicitly using the interface name? > > Sifting through the webapps docs, I found several sporadic examples of DOM-defined objects which are explicitly instantiated: > - Image, Audio, Option, > - MediaController, TextTrackCue, > - DrawingStyle, Path, > - Worker, SharedWorker, MessageChannel, XMLHttpRequest, EventSource, WebSocket. > > Of these, the closest semantic relative is TextTrackCue, and it uses positional syntax similar to what was suggested. > > Also worth mentioning is IndexedDB which is loaded with new interfaces, but not one is instantiated by authors (might be very well be wrong, just afaik). > > To sum up, as an author I vote for-- > var t = undoManager.transact("foo"); > t.onundo = function() { ... }; > OR t.setUndo(function() { .... });
How do you envision it should work with an automatic transaction? We need some mechanism to tell the UA "record DOM mutations while I'm calling this function". - Ryosuke