| 02:01 | <Hixie> | zewt: actually scripts _can_ detect the conditions you mention for when the network comes back -- they just need to listen for the 'online' event |
| 02:26 | <zewt> | Hixie: assuming transient issues (eg. ip changes) ever make it consider itself "offline" |
| 02:26 | <zewt> | i really don't understand the notion that pages should have to deal with this individually, when so many other web APIs go to efforts to eliminate uncommon error states and make things just work |
| 02:33 | <Hixie> | zewt: it's possible we need to change the design. so far people have just been saying "we should slightly change this api for this one case", not "we need to rethink the basic design of the api" |
| 02:38 | <zewt> | simply saying that reconnection behavior, at least for most users, will be done much better if the UA handles it, and that we'll have a lot of buggy and badly-behaved apps if not |
| 02:38 | <zewt> | certainly doesn't seem like a huge change, no |
| 02:39 | <Hixie> | i don't know how big a change it would be since i haven't examined the implications of a fundamental design change |
| 02:40 | <Hixie> | sometimes one can change the basic idea of the feature without actually changing the API at all |
| 02:40 | <Hixie> | other times, it simply makes no sense to even have a similar API with a change of design philosophy |
| 02:43 | <zewt> | i havn't looked at it in depth either, but roughly i'd expect it to look equivalent to if it still only retried once, but it just took a long time (eg. it'd sit in CONNECTING for a long time) |
| 02:43 | <zewt> | (don't really know if it'd need to expose more than that) |
| 02:46 | <zewt> | (i should have said I don't expect it to be a big script-visible change) |
| 03:00 | <Hixie> | zewt: i don't know, but e.g. maybe the protocol needs other features, maybe there needs to be attributes exposing or controlling it, i dunno |
| 03:02 | <zewt> | yep |
| 09:09 | <annevk> | matjas: the intention is to allow it |
| 09:09 | <annevk> | matjas: not sure anything defines it as being same-origin though |
| 09:09 | <annevk> | matjas: but UAs are starting to implement it that way |
| 10:12 | <annevk> | matjas: hmm yeah so we need to make that more explicit somehow |
| 10:13 | <matjas> | yes please. if it wasn’t for the non-normative “note” i wouldn’t have even mentioned it |
| 10:14 | <matjas> | annevk: want me to file a CORS spec bug? |
| 10:14 | <annevk> | it's not a bug in CORS |
| 10:14 | <annevk> | it's an XHR bug |
| 10:15 | <matjas> | it doesn’t just apply to XHR though |
| 10:15 | <matjas> | data URL images should be same-origin too |
| 10:15 | <matjas> | or is that case already covered elsewhere? |
| 10:15 | <annevk> | "If the XMLHttpRequest origin and the request URL are same origin" needs to expand to also include request URLs whose scheme is data: |
| 10:15 | <annevk> | matjas: that is covered elsewhere at the moment |
| 10:16 | <annevk> | matjas: maybe we can flip things around and only special case data URLs where allowing them to be same-origin would be harmful, but that would require working through all the same-origin checks in the platform |
| 10:17 | <annevk> | matjas: it's not okay for instance for shared workers |
| 10:18 | <annevk> | somehow blob URLs are defined to be same origin with the script that created them |
| 10:18 | <annevk> | that prolly works |
| 10:19 | <annevk> | but that cannot work for data URLs |
| 10:22 | <annevk> | matjas: I can fix the XHR bug easily enough sometime later, but maybe we should look at data URLs again in various contexts to see if updating the same-origin definition and special casing shared workers would be enough |
| 10:30 | <annevk> | hmm so XHR -> cross-origin -> data URL would still need to be cross-origin |
| 10:31 | <annevk> | so yeah, it would kind of depend on where we special case it how such scenarios would work |
| 10:32 | <annevk> | e.g. with my proposal XHR -> same-origin -> data URL would fail |
| 10:43 | <cheron> | What is the intention of the "challenge" attribute of the HTML 5 keygen element? Are there any use cases/examples? |
| 10:46 | <annevk> | cheron: it influences the generated signature |
| 10:46 | <annevk> | cheron: the use case is mainly supporting some legacy sites that use <keygen> |
| 10:47 | <annevk> | cheron: so maybe we should move the element to the "obsolete" section |
| 10:50 | <cheron> | annevk: ty, this helps me much with my bachelor's thesis |
| 10:51 | <annevk> | what's the subject of the thesis? |
| 10:51 | <cheron> | Security in HTML5 |
| 10:51 | <smaug____> | uh, we should definitely move keygen to obsolete |
| 10:52 | <annevk> | cheron: cool |
| 10:52 | <annevk> | smaug____: file a bug ;) |
| 10:53 | <smaug____> | whaat, keygen has got some new properties in HTML spec |
| 10:59 | <cheron> | smaug__: if you file a bug can you send me the link, pls |
| 11:01 | <cheron> | annevk: yeah, pretty interesting |
| 11:48 | zcorpan | sends an email to site-comments about robots.txt |
| 11:51 | <MikeSmith> | zcorpan: what's up with robots.txt? |
| 11:52 | <zcorpan> | MikeSmith: http://lists.w3.org/Archives/Public/site-comments/2012Jul/0007.html |
| 11:52 | <MikeSmith> | I can fix the dvcs.w3.org one myself |
| 11:53 | <MikeSmith> | what should it have? |
| 11:53 | <MikeSmith> | the www.w3.org one I'll leave up to others |
| 11:54 | <zcorpan> | MikeSmith: is don't see any reason to not use `User-agent: *\nAllow: *` but maybe there is |
| 11:55 | <MikeSmith> | zcorpan: I know they have had serious problems in the past with bots crawling dev.w3.org |
| 11:55 | <MikeSmith> | creating massive load |
| 11:56 | <zcorpan> | bratell just had issues finding the HTML Editing APIs spec because of this, and i found out yesterday that the quirks mode spec isn't visible in google |
| 11:56 | <MikeSmith> | yeah that's not good |
| 11:56 | <MikeSmith> | I will talk to the systems team about it |
| 11:57 | <zcorpan> | thanks! |
| 11:57 | <zcorpan> | the /Bugs/ thing was someone complaining here in #whatwg the other day |
| 11:59 | <MikeSmith> | OK |
| 15:59 | <zcorpan_> | http://simon.html5.org/sandbox/bookmarklets/w3c-cg-spec-checker.js |
| 16:17 | <ashemedai> | Yay, I get to annoy the Opera guys again |
| 16:19 | <zcorpan> | matjas: i have filed a spec bug about CORS-enabled fetch to consider data: to be same-origin |
| 16:20 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17461 |
| 18:29 | <smaug____> | rniwa: values from dictionaries are read when the object is passed to some native method |
| 18:29 | <smaug____> | so I don't quite understand your email about the problem |
| 18:30 | <rniwa> | smaug____: well, you can then modify those properties |
| 18:30 | <smaug____> | so? |
| 18:30 | <rniwa> | smaug____: so you can do undoManager.transact({execute: function () { this.undo = ~; }}) |
| 18:30 | <rniwa> | smaug____: so my point is that it's not a problem specific to having DOMTransaction interface |
| 18:30 | <smaug____> | this.undo = wouldn't do anything sane |
| 18:31 | <rniwa> | smaug____: what do you mean? |
| 18:31 | <rniwa> | smaug____: it'll do something extremely sane |
| 18:31 | <smaug____> | I mean, it would put .undo property to 'this' |
| 18:31 | <smaug____> | this wouldn't be the dictionary object |
| 18:31 | <rniwa> | smaug____: yeah but "this" is the dictionary object! |
| 18:32 | <rniwa> | smaug____: since execute is supposed to be called on the dictionary object passed into. |
| 18:32 | <smaug____> | no |
| 18:32 | <rniwa> | transact |
| 18:32 | <rniwa> | smaug____: why no? |
| 18:32 | <smaug____> | execute is a property of the dictionary |
| 18:32 | <smaug____> | and stored separately |
| 18:32 | <rniwa> | smaug____: yes. |
| 18:32 | <rniwa> | smaug____: no. |
| 18:32 | <smaug____> | when passed to native |
| 18:32 | <rniwa> | smaug____: that's not how it works |
| 18:33 | <rniwa> | maybe my spec isn't clear. |
| 18:33 | <rniwa> | smaug____: but the intent is for the dictionary to be kept alive |
| 18:33 | <rniwa> | smaug____: and execute, undo, redo, & executeAutomatic to be called upon on the dictionary object |
| 18:33 | <smaug____> | then you should use some nointerfacecobject interface |
| 18:33 | <smaug____> | not dictionary |
| 18:33 | <rniwa> | smaug____: I'm using that. |
| 18:33 | <rniwa> | smaug____: it's DOMTransaction |
| 18:34 | <rniwa> | smaug____: with [NoInterface] |
| 18:34 | <smaug____> | ok, let's not talk about dictionaries then :) |
| 18:34 | <Ms2ger> | Eh, NoInterfaceObject, you shouldn't use that |
| 18:34 | <rniwa> | smaug____: yeah, that's the confusing part. |
| 18:34 | <smaug____> | ojan_away was talking about dictionaries in his email |
| 18:35 | <smaug____> | so you're probably talking about different things... and I'm not sure what exactly :) |
| 18:35 | <rniwa> | smaug____, Ms2ger: http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html#dom-domtransaction |
| 18:35 | <rniwa> | well... it works like Dictionary to some extent |
| 18:35 | <rniwa> | at least in ES5, you can create one like Dictionary |
| 18:35 | <rniwa> | but yeah... it's not really the same thing |
| 18:36 | <rniwa> | the fact we're talking about this in ES5 is making everything super confusing |
| 18:36 | <smaug____> | Dictionary is pretty well-defined in WebIDL |
| 18:36 | <rniwa> | smaug____: yes, but i don't think ojan_away was talking about that. |
| 18:36 | <smaug____> | I thought he was talking about dictionaries |
| 18:36 | <rniwa> | smaug____: he and everyone else are referring to dictionary was in ordinary programming language term. |
| 18:37 | <rniwa> | s/ was/ as/ |
| 18:37 | <smaug____> | huh |
| 18:37 | <Ms2ger> | Interfaces aren't implemented by content scripts |
| 18:37 | <rniwa> | Ms2ger: they could be. |
| 18:37 | <Ms2ger> | No |
| 18:37 | <rniwa> | Ms2ger: but this is EXACTLY why I want to change the interface |
| 18:37 | <rniwa> | because it's so damn foreign to the Web |
| 18:38 | <smaug____> | when talking about WebIDL interfaces 'dictionary' certainly refers to the concept in WebIDL |
| 18:38 | <Ms2ger> | So, what is this DOMTransaction thing? |
| 18:38 | <rniwa> | Ms2ger: http://www.w3.org/TR/WebIDL/#es-user-objects |
| 18:39 | <rniwa> | Ms2ger: it's a user object implementing a callback interface |
| 18:39 | <rniwa> | but we had never used this semantics in any other API |
| 18:39 | <Ms2ger> | What do you use it for? |
| 18:39 | <rniwa> | Ms2ger: you use it to represent an undo "step" |
| 18:39 | <rniwa> | Ms2ger: a unit of work that can be done, undone, or redone via undo manager |
| 18:40 | <rniwa> | Ms2ger: it represents a "command" in the command design pattern |
| 18:42 | <smaug____> | I don't buy the "foreign to the Web". { handleEvent: function(evt) {} } isn't foreign to the Web |
| 18:42 | <smaug____> | the fact the the object may have some more properties does change anything |
| 18:42 | <smaug____> | s/does/doesn't/ |
| 18:44 | <rniwa> | smaug____: i don't think most authors are aware of the fact an event handler is an object though |
| 18:44 | <Ms2ger> | So, you pass it to transact()? |
| 18:44 | <rniwa> | smaug____: i literally had never seen anyone using that explicit object form |
| 18:44 | <rniwa> | Ms2ger: right. |
| 18:45 | <Ms2ger> | Why doesn't the IDL for transact say that? |
| 18:46 | <Ms2ger> | Looks like a dictionary would work |
| 18:46 | <rniwa> | Ms2ger: yeah... i should update the spec :\ |
| 18:47 | <smaug____> | dictionary doesn't work if rniwa wants the 'this' handling he mentioned above |
| 18:47 | <Ms2ger> | Well, no |
| 18:48 | <rniwa> | smaug____, Ms2ger: that "this" handling is pretty important. |
| 18:48 | <rniwa> | otherwise the benefit of using dictionary degrades significantly |
| 18:50 | <smaug____> | so don't use dictionary but callback interface :) |
| 18:50 | <rniwa> | smaug____, Ms2ger: so are you guys opposed to yuval's proposal? |
| 18:50 | <Ms2ger> | Link? |
| 18:51 | <smaug____> | I'm not sure I understand what is the "final" proposal |
| 18:51 | <matjas> | zcorpan: thanks for the link |
| 18:52 | <Ms2ger> | Anyway, write it up, and we'll complain then :) |
| 18:52 | <rniwa> | http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0058.html |
| 18:52 | <smaug____> | that hybrid form is really odd |
| 18:54 | <smaug____> | rniwa: just curious, did this all start from the memory management problems, or were you thinking about changing the API even before someone started to implement the API ? |
| 18:55 | <rniwa> | smaug____: i had never liked the API because it seemed very different from other APIs |
| 18:55 | <rniwa> | smaug____: and my intern had been wokring on this patch |
| 18:56 | <rniwa> | and memory management thing motivated me enough to start the thread |
| 18:56 | smaug____ | can't wait to see cycle collector to be implemented for webkit ;) |
| 18:58 | <Ms2ger> | Let's try workers first |
| 18:58 | <rniwa> | smaug____: that oddness solves one important weridness |
| 18:58 | <rniwa> | smaug____: which comes with "native" DOMTransactions |
| 18:58 | <rniwa> | smaug____: editing commands add |
| 18:59 | <Ms2ger> | (Hah, XSLT3) |
| 19:00 | <rniwa> | Ms2ger: how about some sane NodeList & HTMLCollection |
| 19:00 | <smaug____> | rniwa: well, it is odd to have some sorts of callbacks and event listeners |
| 19:00 | <Ms2ger> | rniwa, what about NodeList? |
| 19:00 | <rniwa> | smaug____: no... there will be no callbacks |
| 19:01 | <rniwa> | Ms2ger: WebKit has namedItem or whatever on NodeList |
| 19:01 | <smaug____> | new DOMTransaction(function () { ~ }) |
| 19:01 | <Ms2ger> | Kill it |
| 19:01 | <smaug____> | what is that function if not a callback? |
| 19:01 | <rniwa> | smaug____: on but that won't be added as a property |
| 19:01 | <rniwa> | smaug____: it'll be hidden within the object. |
| 19:01 | <smaug____> | so? |
| 19:01 | <smaug____> | it is still a callback |
| 19:01 | <rniwa> | smaug____: yeah... :\ |
| 19:02 | <rniwa> | smaug____: so should we just do |
| 19:02 | <rniwa> | t = new DOMTransaction |
| 19:02 | <rniwa> | t.onexecute = function () {~} |
| 19:02 | <rniwa> | t.onundo = function () {~} |
| 19:02 | <rniwa> | t.onredo = function () {~} |
| 19:02 | <rniwa> | ? |
| 19:02 | <smaug____> | that one looks better |
| 19:06 | <smaug____> | (but I'm sure the jQuery fans will complain ;) ) |
| 19:08 | <rniwa> | smaug____: well, people who like jQuery can wait for jQuery to support it |
| 19:08 | <Ms2ger> | t.onexecute = function () { ~; return this; } |
| 21:00 | <Ms2ger> | https://twitter.com/dastels/status/223059799699501056 |
| 21:05 | <jsbell> | Not sure if praise or damning praise. |
| 22:24 | <ojan> | a bit late to the party...but, for the record, I was talking about WebIDL dictionaries |
| 22:29 | <Hixie> | so what's the browser interest on the http+aes stuff? |
| 22:33 | <espadrine_> | isn't that what https is supposed to do? What's http+aes? |
| 22:34 | <Yuhong> | <Hixie> looks like netscape was on the path of blame |
| 22:34 | <Yuhong> | I think IE1 was the first browser to support named colors. |
| 22:35 | <Hixie> | espadrine_: a way to have content served to a client from an untrusted CDN |
| 22:37 | <espadrine_> | some kind of CORS with a brand new protocol then? |
| 22:38 | <Hixie> | no, new scheme that includes a key to decrypt the payload of an HTTP resource |
| 22:38 | <Hixie> | it's in the spec currently |
| 22:38 | <Hixie> | but i'm wondering if we should drop it |
| 22:38 | <Hixie> | since it doesn't seem anyone really cares |
| 22:38 | <Hixie> | we added it because people said there was a use case for it, but i'm starting to think the use case was a fiction intended to help push a DRM scheme |
| 22:41 | <espadrine_> | oh, I see |
| 22:41 | <smaug____> | rniwa: it still sounds like ojan is talking about WebIDL dictionaries and you're talking about callback objects :) |
| 22:42 | <ojan> | what are callback objects? |
| 22:43 | <smaug____> | { handleEvent: function() {} } |
| 22:43 | <smaug____> | and you store reference to that object |
| 22:43 | <rniwa> | smaug____: yeah so it seems. |
| 22:43 | <ojan> | callback objects seem like a bad idea |
| 22:44 | <smaug____> | callback objects are a nice idea :) |
| 22:44 | <smaug____> | but in this particular case dictionary should work well too |
| 22:44 | <ojan> | it simplifies many things in this case |
| 22:45 | <ojan> | e.g. what happens when you reuse the object for two transact calls |
| 22:46 | <ojan> | i'm about at the end of my standards arguing rope on this discussion though...and i don't think there's much more to say...so, unless some new information comes to light...i don't have more to add to that thread |
| 22:47 | <smaug____> | I don't care too much, except that the proposal to use callbacks in some cases and event listeners in some other cases looked really really odd. |
| 22:47 | <smaug____> | either event listeners, or dictionary or callback object |
| 22:47 | <zewt> | smaug____: that seems like a pointless idea, heh |
| 22:48 | <zewt> | very Java-ish (or more generally, any language that doesn't have first-class function objects-ish) |
| 22:48 | <smaug____> | from implementation point of view callback object is easiest in Gecko, but other options are easy too |
| 22:48 | <zewt> | it's just completely alien to JS as a callback paradigm |
| 22:49 | <zewt> | i mean, i don't know why a *user* would ever want to use that method |
| 22:50 | <smaug____> | (yet { handleEvent: function() {}} is commonly used, but let's not start this discussion again. It is getting late here :) ) |
| 22:50 | <zewt> | never once seen it in real-world code :) |
| 22:51 | <smaug____> | I'm fine with dictionary or event listener based approaches |
| 22:51 | <smaug____> | zewt: you haven't looked at Firefox UI code ;) |
| 22:51 | <zewt> | i have a bit; i try to avoid it at any cost :) |
| 22:51 | <smaug____> | or, IIRC, OSX Dashboard |
| 22:52 | <rniwa> | ojan: i replied on the thread but there were use cases for being able to keep the original object |
| 22:52 | <rniwa> | ojan: in particular properties on the original object. |
| 22:53 | <smaug____> | ( that is the use case for { handleEvent: function() {}} too. One can store state in the object easily. ) |
| 22:54 | <zewt> | (not really a use case for that, since you can easily pass in a bound function or a closure) |
| 22:54 | <zewt> | (not specific to that, I mean) |
| 22:54 | <smaug____> | "you can easily" doesn't mean the other approach is bad |
| 22:55 | <zewt> | it is if the object is meant to be a simple callback (as opposed to, say, a *set* of callbacks, in which case it's fine) |
| 22:55 | <smaug____> | zewt: in this case, UndoManager, we're talking about a set of callbacks |
| 22:55 | <rniwa> | zewt: in undo manager's case it'll be 1-3 callbacks so it'll be odd. |
| 22:56 | <rniwa> | zewt: in fact, you can't just pass in an object |
| 22:56 | <rniwa> | ugh.. i mean pass in a function |
| 22:56 | <zewt> | then OK (that's very different from the weird handleEvent thing on event listeners) |
| 22:56 | <rniwa> | you need to explicitly pass in an object |
| 22:56 | <rniwa> | zewt: yeah. |
| 22:56 | <rniwa> | I DO like the syntax of pure Dictionary or user object implementing DOMTransaction |
| 22:57 | <rniwa> | the fact we can't have any readonly property, etc... |
| 22:57 | <rniwa> | make things too hary |
| 22:57 | <rniwa> | hairly* |
| 22:57 | <smaug____> | zewt: it is not at all different from event listeners. you can pass { handleEvent: function() {}, undo: function() {}, redo: function() {}} to UndoManager and to addEventListener |
| 22:58 | <zewt> | it's very different from event listeners, because event listeners are a single simple callback which can (just for compatibility reasons) also be passed in as an object |
| 22:58 | <zewt> | event listeners aren't a set of functions, they're just a function |
| 22:59 | <smaug____> | eh, but you can pass the *same* object implementing several callbacks |
| 22:59 | <smaug____> | that is the point |
| 22:59 | <smaug____> | no need to play with bind() or anything |
| 23:01 | <zewt> | i don't know what you're saying; I can think of nothing you can do with addEventListener by passing in an object that you can't do easily with a function |
| 23:01 | <zewt> | (not sure what you mean by "several callbacks"; event handlers have only one callback, handleEvent) |
| 23:01 | <smaug____> | { handleEvent: function() {}, undo: function() {}, redo: function() {}} |
| 23:02 | <smaug____> | you pass the same object to addEventListener, and also to UndoManager |
| 23:02 | <zewt> | that's pointless and unnecessary |
| 23:02 | <smaug____> | you can keep some state in the object |
| 23:02 | <smaug____> | this isn't useful discussion :) |
| 23:03 | <zewt> | if you say so :) |
| 23:03 | <smaug____> | if the argument is all the time something like "that's pointless and unnecessary" :p |
| 23:04 | <zewt> | it lets you do nothing that you can't do easily and cleanly without it; that's how I describe that |
| 23:05 | <rniwa> | anyways, i'm inclined to take the flame and use the event listener approach |
| 23:05 | <zewt> | anyway, we're stuck with it for event handlers, but I hope I won't be the only one to object if someone suggests supporting it for other simple callbacks :) |
| 23:05 | <rniwa> | i'm sad about the verbosity but it seems better than the user object approach. |
| 23:06 | <rniwa> | zewt: object to what? |
| 23:07 | <zewt> | rniwa: that a function taking a single, simple callback should accept either a function or an object with some method, like event handlers |
| 23:07 | <zewt> | (not what you're doing) |
| 23:07 | <rniwa> | zewt: oh yeah... that's a very odd design indeed. |
| 23:08 | <zewt> | rniwa: as long as you expose event attributes, it's not *too* much more verbose (compared to having to addEventListener each of them) |
| 23:09 | <rniwa> | zewt: oh yeah, definitely not addEventListener |
| 23:09 | <smaug____> | well, there will be also addEventListener |
| 23:09 | <rniwa> | zewt, smaug____: or maybe I should just give up and stick with the original design. |
| 23:09 | <zewt> | yeah, if you're an EventTarget then you get addEventListener automatically |
| 23:10 | <smaug____> | rniwa: original was callback object, right? |
| 23:10 | <smaug____> | I'm fine with that, and I'm fine with dictionary, and with event listeners |
| 23:11 | <smaug____> | but just don't mix them :) |
| 23:11 | <smaug____> | I kind of like the callback object approach |
| 23:11 | <rniwa> | smaug____: yeah. |
| 23:11 | <rniwa> | smaug____: sicking really liked the callback object approach. |
| 23:12 | <zewt> | hmm |
| 23:13 | <zewt> | we don't have any way to feature detect dictionary-based APIs, do we |
| 23:13 | <zewt> | akin to func.length for simple functions |
| 23:14 | <zewt> | (in cases where you can't just call it and see what happens, which isn't always workable) |
| 23:14 | <zewt> | thinking of createObjectURL(blob, {autoRevoke...}) |
| 23:16 | <zewt> | aside from https://www.w3.org/Bugs/Public/show_bug.cgi?id=16953#c4, which is a bit insane |
| 23:16 | <rniwa> | zewt: no :( |
| 23:17 | <zewt> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746 heh people copying and pasting a mail from me into a bug is ... confusing |
| 23:17 | <rniwa> | zewt: another thing about user object is that you can't do expandos |
| 23:17 | <zewt> | "havn't I read this before?" |
| 23:17 | <zewt> | rniwa: i think the dictionary-feature-detection thing should be solved generically (don't know how though) |
| 23:17 | <rniwa> | zewt: how do you do that? |
| 23:17 | <zewt> | i said i don't know :P |
| 23:17 | <rniwa> | zewt: also, what is there to feature-detect? |
| 23:18 | <zewt> | whether an argument supports a particular options argument |
| 23:18 | <zewt> | eg. whether createObjectURL supports autoRevoke |
| 23:18 | <zewt> | rniwa: which case can't you do expandos? |
| 23:18 | <zewt> | if it's a dictionary then the API doesn't really store the object itself anyway, as I understand it |
| 23:19 | <zewt> | (WebIDL basically makes a shallow copy) |
| 23:20 | <rniwa> | zewt: dictionary. |
| 23:21 | <rniwa> | zewt: i guess i meant the user object case then. |
| 23:21 | <rniwa> | zewt: in either case, you can't really add new functionality to dom transactions. |
| 23:21 | <rniwa> | unless you manually modify each object. |
| 23:22 | <zewt> | yeah, you don't get a reference back to the original object (since the API never even sees it) |
| 23:22 | <zewt> | it's not quite like passing around handler objects like JS libraries like to do |
| 23:23 | <zewt> | it doesn't really lose you anything compared to event handlers, either, though |
| 23:24 | <rniwa> | zewt: well in the event handler case, the object uses DOMTransaction interface |
| 23:24 | <zewt> | i don't have any strong opinion on "return an EventTarget and the user attaches listeners to it" vs. "pass in an object with a set of callbacks"; there's really very little difference |
| 23:24 | <rniwa> | zewt: so you can feature detect on DOMTransaction interface if any |
| 23:25 | <rniwa> | zewt: one big difference is that you can add event listeners to the former after the fact |
| 23:25 | <rniwa> | zewt: and observe undo/redo per dom transaction |
| 23:25 | <rniwa> | zewt: wheres for the latter, we need to do that at element/document level |