| 00:04 | <Hixie> | yroc: i seem to recall there was some difference, but the real answer is probably just because it was already implemented, so why not |
| 00:16 | <zewt> | annevk: random thought, but i wonder if this could just be element.addEventListener("click", function(e) { }, { options }) when the third argument is a dictionary instead of a boolean, possible options are "selector" and "capture", and have "alwaysBubble" be an option (instead of having a separate function just for that) |
| 00:17 | <zewt> | also i wonder if making addEventListener return an object or a timeout-like id would be web-compatible (can't imagine why not, but it's such a critical API that who knows) |
| 00:36 | <jamesr> | if we do that i'd really like there to be a way to specify some filters on the sorts of events - i.e. say which key events you care about for keyboard-related ones, specifying which modifiers you care about |
| 00:36 | <jamesr> | so the browser can know up-front whether to bother doing all the setup of firing a DOM event or if the listener is just going to toss it |
| 00:43 | <yroc> | Hixie: Interesting though because <wbr> is not in the 4.01 spec as far as I can see, nor in Berners-Lee RFC 1866 or W3C's 3.2 spec. |
| 00:43 | <Hixie> | yeah we didn't pay much attention to the earlier specs when writing the current one |
| 00:44 | <Hixie> | more what browsers implemented |
| 00:44 | <yroc> | Hixie: I have found references to it dating back to the late 90s, so it's obviously been around |
| 00:44 | <yroc> | I see. |
| 00:44 | <yroc> | So that was the driving force then. The fact that it was implemented in the major browsers, so it was just spec'ed |
| 00:45 | <Hixie> | that's why it was specced as required to implement, but the reason it was speced as valid to use (a completely different question) is more likely to be that it provided a valid use case (albeit one that's no more useful than the zwsp character, iirc) |
| 00:48 | <yroc> | But there's really such thing as "required to implement," is there? I mean the vendors can do what they want, no? |
| 00:48 | <Hixie> | well true |
| 00:48 | <Hixie> | in practice what the spec says is required to implement is what they will implement anyway |
| 00:49 | <yroc> | ...or have already implemented! :-) Gotcha. |
| 00:49 | <Hixie> | but it also says what a new browser would have to implement to be compatible with the web |
| 00:51 | <yroc> | "Compatible with the web?" -- what do you mean by "web" here? |
| 00:51 | <Hixie> | deployed web content |
| 00:52 | <yroc> | So compatible with what web authors are producing. |
| 01:03 | <Hixie> | right |
| 01:45 | <Hixie> | ok, i'm reopening all the whatwg later and remind bugs |
| 01:52 | <jamesr> | new year = it's later now? |
| 01:58 | <Hixie> | yeah |
| 03:53 | <Hixie> | annevk: did you fiele a bug for https://www.w3.org/Bugs/Public/show_bug.cgi?id=20535#c3 ? |
| 11:40 | <annevk> | Hixie: will do |
| 11:57 | <annevk> | done |
| 12:02 | <annevk> | jamesr: interesting idea |
| 13:04 | <annevk> | smaug____: I suggest looking at some popular JavaScript libraries if you want to understand "why" |
| 13:23 | <smaug____> | annevk: that isn't why |
| 13:23 | <annevk> | it is though |
| 13:23 | <smaug____> | jQuery has its API just because someone has decided to have such |
| 13:24 | <smaug____> | I'd like to understand why jQuery has the API |
| 13:25 | <smaug____> | I don't have too much against jQuery's APIs, but need to be careful since it tends to slow down things (either it is jQuery implementation or the API design) |
| 13:49 | <annevk> | every developer I talk to wants selector-based filtering |
| 13:49 | <annevk> | you make a good point about when to do said filtering though |
| 13:50 | <annevk> | pretty sure we can do whatever is most performant there |
| 13:51 | <smaug____> | well, it affects to behavior |
| 13:51 | <smaug____> | I wonder what jQuery does |
| 13:55 | <annevk> | oops, it seems it filters based on event.target |
| 13:55 | <smaug____> | oh |
| 13:55 | <smaug____> | that is somewhat odd |
| 13:55 | <annevk> | nah, see e.g. http://icant.co.uk/sandbox/eventdelegation/ |
| 13:57 | <smaug____> | other thing possibly useful would be event target groups, so that one could add and remove listeners from many targets at once |
| 13:57 | <annevk> | that's basically this |
| 13:57 | <smaug____> | it is not |
| 13:58 | <annevk> | you register on a common parent and select the targets with a selector |
| 13:58 | <smaug____> | this requires common parent and all |
| 13:58 | <annevk> | given that events dispatch in a tree, that's a given |
| 13:58 | <annevk> | but maybe the reverse is all we need... |
| 13:59 | <annevk> | listen to events for elements that match these selectors? |
| 13:59 | <annevk> | not sure that quite works given text nodes and such though |
| 14:01 | <smaug____> | "given that events dispatch in a tree"... I was thinking something more generic which can handle several DOM trees at once, and wouldn't actually be restricted to DOM trees, but would work with all the event targets |
| 14:01 | <smaug____> | hmm, selector matching on XHR doesn't quite make sense |
| 14:03 | <smaug____> | is jquery's 'on' node only thing |
| 14:03 | <smaug____> | oh dear, it has all different thing for "Ajax" |
| 14:05 | <annevk> | yeah, selector-based matching only makes sense for Elements |
| 14:05 | <annevk> | well, for RootNode I suppose |
| 14:07 | smaug____ | doesn't understand the word "delegation" with event handling |
| 14:07 | <smaug____> | it is just normal event handling |
| 14:08 | <smaug____> | the fact that listener isn't on the target or that target checking happens within the listner does not mean any kind of "delegation" |
| 14:17 | <annevk> | I think the way it's viewed is that you delegate the work to a listener registered on a parent |
| 14:18 | <annevk> | I'm not sure it's very interesting to debate terminology at this point though. It's called delegation by the developer community... |
| 14:18 | <smaug____> | yeah, and I just don't understand what you actually delegate. You just do stuff in an ancestor's listener :) |
| 14:19 | <smaug____> | well, delegation isn't a good term IMO, so I don't expect it to end up to specs |
| 14:19 | <smaug____> | we need something more exact, if anything |
| 14:19 | <smaug____> | but lunch time |
| 14:28 | <annevk> | the spec will just define the API, no buzzwords... |
| 14:28 | <annevk> | but at this point it's not really clear what requirements the API should meet |
| 15:29 | <smaug____> | yeah, need to know the requirements first |
| 17:31 | <zewt> | smaug____: "delegation" just refers to the approach (handling events for dynamic trees by listening up the tree and filtering), and it's the best term there will ever be merely because it's what everyone uses and understands |
| 17:31 | <zewt> | trying to rename something after a term is widely accepted is never the right thing to do |
| 17:33 | <smaug____> | well, I don't know how accepted that is |
| 17:34 | <smaug____> | anyhow, if it doesn't end up to any spec, as I hope, I don't care :) |
| 17:34 | <zewt> | it is in my experience |
| 17:35 | <smaug____> | Firefox UI is all about event "delegation", but "delegation" isn't really used anywhere |
| 17:36 | <smaug____> | (I know, that is not web development) |
| 17:58 | <zewt> | oops, tried to put a million event listeners on window and chrome is upset at me |
| 18:01 | <smaug____> | :) |
| 18:01 | <smaug____> | zewt: doing performance testing? |
| 18:02 | <smaug____> | (for some reason chrome's event dispatch speed has regressed significantly) |
| 18:03 | <smaug____> | (at least in my tests) |
| 18:07 | <zewt> | smaug____: just sanity checking the "event filtering" thing on https://www.w3.org/Bugs/Public/show_bug.cgi?id=16491 (which as I suspected, seems to not be useful, at least at the dispatch phase) |
| 18:08 | <zewt> | also ... wow, webkit is initKeyboardEvent and gecko is initKeyEvent and there's no overlap? seriously? |
| 18:08 | <smaug____> | Gecko has DOM 0 key events, webkit has some obsolete D3E draft key events, IIRC |
| 18:13 | <annevk> | o_O |
| 20:30 | <Yuhong> | "And we provide the longest support life cycle of any browser, allowing you to upgrade your browser at your own pace." |
| 20:30 | <Yuhong> | From http://blogs.windows.com/ie/b/ie/archive/2012/12/13/ten-reasons-why-internet-explorer-10-is-best-for-business.aspx |
| 21:11 | <zewt> | one might possibly refer to that as "spin" |
| 21:31 | <Yuhong> | <zewt> one might possibly refer to that as "spin" |
| 21:32 | <Yuhong> | Not my point, My point is they are actually touting that they support all IE versions for the 10+ years life of a Windows version. |