| 01:59 | <GPHemsley> | Hixie: I'm just now going through the backlog of wiki admin stuff... the non-account request e-mails can be quite entertaining |
| 02:00 | <GPHemsley> | (Subject: "I'm going to sue you") "I'm tired of you controlling everything I do. I'm going to sue you for all your open source, ifc, developer, xmtl bullshit. It is a total invasion of privacy." |
| 02:00 | <GPHemsley> | Oh, wait, I left off the kicker |
| 02:00 | <GPHemsley> | "Sent from my iPhone" |
| 02:01 | <GPHemsley> | I also love the numerous spam product catalogs for traffic cones |
| 02:02 | <GPHemsley> | oh, and apparently html5banners.com will soon be available for auction |
| 02:50 | <aretecode> | What books do you recommend reading about specifications/standards/schemas? |
| 02:58 | <Hixie> | GPHemsley: sounds like i have better spam filtering than you, i hadn't seen any of those :-) |
| 02:59 | <Hixie> | aretecode: i haven't seen any especially brilliant ones, i'd mostly recommend reading the specs and joining the mailing lists |
| 03:05 | <aretecode> | Hixie, thanks for your input. Can I buy the specs on paper? |
| 03:06 | <Hixie> | you can buy paper and i think some companies still make printers :-) |
| 03:06 | <SamB> | aretecode: most of them are living nowadays, it seems |
| 03:06 | <Hixie> | yeah most of the good specs these days are maintained, meaning they get bug fixes regularly |
| 03:06 | <Hixie> | like, daily or weekly |
| 03:06 | <SamB> | it's not like buying a TeX manual that you could use for >1/4 century |
| 03:07 | <SamB> | (depending on how interested you are in having all the errata fixed by other than literal copy&paste) |
| 03:08 | <aretecode> | I understand, still, I find it easier to speed read on paper & printing them off is such a hassle. |
| 03:08 | <SamB> | (Yes, Knuth makes patches that you can print out and paste into the manual!) |
| 03:10 | <tantek> | aretecode, for some of these specs, by the time you're done printing them, what you've printed out is already obsolete (changes have occured). |
| 03:10 | <tantek> | even more likely for anything "preprinted" |
| 03:10 | <tantek> | like "books" |
| 03:13 | <aretecode> | True, I will just have to read these online - thank you :-) |
| 03:14 | <GPHemsley> | If you wait long enough, they'll probably stabilize eventually |
| 03:14 | <GPHemsley> | And then you could print them |
| 03:18 | <Hixie> | HTML is pretty stable, but i doubt it'll be unchanging before it's obsolete |
| 03:18 | <Hixie> | and it'll probably have a wave of desperate changes just after being obsolete :-) |
| 03:20 | <zewt> | if you want stuff on paper, buy a kindle |
| 10:53 | <jgraham> | gsnedders: r+ |
| 13:45 | <Ms2ger> | "The problem is that the CSS Working Group doesn't follow the W3C Process for maintaining specifications." |
| 13:45 | Ms2ger | giggles |
| 13:47 | <jgraham> | :-o |
| 15:23 | <galineau> | 'Not following the W3C process' kind of sounds like a feature to me. |
| 15:23 | <dglazkov> | good morning, Whatwg! |
| 15:23 | <galineau> | good morning to you too, Monsieur Glazkov |
| 15:32 | <Ms2ger> | galineau, well, you know there's one person who'd disagree :) |
| 15:34 | <dglazkov> | good morning, galineau and Ms2ger! |
| 15:34 | <galineau> | Ms2ger: only one? OMG I've never been this close to consensus before |
| 15:34 | <Ms2ger> | Ha |
| 15:34 | <Ms2ger> | One person in particular |
| 16:22 | <MikeSmith> | who says "The problem is that the CSS Working Group doesn't follow the W3C Process for maintaining specifications" |
| 16:22 | <MikeSmith> | don't make me have to go and read www-style |
| 16:23 | <MikeSmith> | nm |
| 16:24 | <MikeSmith> | I should have guessed |
| 16:53 | <TabAtkins> | Yeah, that argument from Björn is totally valid. |
| 16:53 | <TabAtkins> | The errata for CSS2 is a disgrace. :/ |
| 16:53 | <TabAtkins> | galineau: Urg, you're gonna break my name-autocompletion memory with a nick like that. |
| 16:54 | <TabAtkins> | Hixie: I remembered that I was supposed to ping you when I'd written this spec: http://dev.w3.org/csswg/css-scoping/#scoping-mechanisms |
| 16:54 | <TabAtkins> | So you can point <style scoped> to it. |
| 16:57 | <tantek> | isn't the errata for CSS2 called "CSS2.1" ? |
| 16:59 | <SimonSapin> | fwiw, I call "CSS2" all of 2.0, 2.1, and any future 2.x |
| 17:04 | <tantek> | SimonSapin - if you'd worked on CSS2 (or tried to implement it), you would have no desire to refer to anything as CSS2 except in a legacy / dismissive manner |
| 17:06 | <SimonSapin> | tantek: that’s not incompatible with what I just said |
| 17:07 | <Ms2ger> | Ha |
| 17:11 | <tantek> | SimonSapin, Y U NO LIKE CSS2.1? |
| 17:16 | <TabAtkins> | tantek: Because it's full of wrong things that are only corrected in the errata that nobody ever reads. |
| 17:16 | <tantek> | so the 2.1 errata is in a sad state, is that what's being asserted? |
| 17:17 | <Ms2ger> | s/2.1// |
| 17:17 | <tantek> | heh |
| 17:17 | <Ms2ger> | Nobody ever bothers with errata in the csswg |
| 17:18 | <annevk> | What was the thing you said about mailing lists again tantek? |
| 17:19 | <tantek> | on a long enough timeline, open mailing lists turn into support forums |
| 17:19 | <hober> | annevk: http://w3cmemes.tumblr.com/post/27939749113/the-conversation-in-whatwg-whenever-tanteks |
| 17:19 | <annevk> | Ah too bad, does not entirely feel how I think about errata |
| 17:20 | <annevk> | s/feel/match/ |
| 17:20 | <tantek> | I'm not much of a fan of errata either - the "nobody checks errata" problem makes errata not every useful in practice even if they do exist and are updated. |
| 17:21 | <tantek> | I'm much more in favor of the "luke-warm spec" model - "finished" specs continue being updated inline with any errata to their feature set |
| 17:23 | <Domenic_> | sounds like a living standard |
| 17:23 | <jgraham> | Lukewarm makes it sound like a zombie standard |
| 17:25 | <Domenic_> | i guess the distinction tantek is making is "no new features"? |
| 17:26 | <tantek> | jgraham, are zombies warm? |
| 17:26 | <rniwa> | annevk: yt? |
| 17:27 | <annevk> | rniwa: yeah |
| 17:27 | <rniwa> | annevk: do you remember why we couldn't make querySelectorAll return Elements? |
| 17:27 | <tantek> | Domenic, yes, specific (frozen) feature sets are useful to various folks. |
| 17:27 | <hober> | rniwa: Elements didn't exist yet |
| 17:27 | <rniwa> | annevk: I know we could replace all static NodeList with Array or make it inherit from Array |
| 17:27 | <annevk> | rniwa: we might be able to, it didn't seem worth the hassle of finding out |
| 17:27 | <rniwa> | hober: I know. |
| 17:27 | <annevk> | rniwa: interesting |
| 17:27 | <Ms2ger> | tantek, I'm unconvinced |
| 17:28 | <rniwa> | annevk, hober: It seems like querySelectorAll should simply return a JS Array (or Elements when it's introduced) |
| 17:28 | <annevk> | rniwa: given .queryAll() I didn't really see the need to find out |
| 17:28 | <Hixie> | TabAtkins: sweet, thanks |
| 17:28 | <rniwa> | annevk: well, it kind of sucks to force authors to use new function just because of that. |
| 17:28 | <annevk> | rniwa: I'd be okay with supporting that in the specification if you implement it |
| 17:29 | <annevk> | rniwa: yeah I guess, the new functions also do other things authors asked for |
| 17:29 | <annevk> | rniwa: e.g. jQuery selector parsing compat |
| 17:29 | <rniwa> | annevk: you mean queryAll? |
| 17:29 | <rniwa> | annevk: right, because it supports relative selector. |
| 17:30 | <annevk> | rniwa: yes and yes |
| 17:30 | <rniwa> | annevk: but it kind of sucks that we have to block the work to make querySelectorAll's results usable until we can implement the relative selector |
| 17:30 | <rniwa> | annevk: because the latter requires a substantial amount of work |
| 17:30 | <tantek> | Ms2ger, clearly you're not various folks ;) |
| 17:30 | <annevk> | rniwa: as I said, I'd be happy to back a WebKit change with a spec change |
| 17:30 | <annevk> | rniwa: you might want to ping the list and copy bz and arv_ |
| 17:30 | <jgraham> | tantek: I imagine zombies follow Newton's law of cooling |
| 17:30 | <rniwa> | annevk: I guess the only risk is that someone might calling item() on the result :/ |
| 17:31 | <rniwa> | arv_: ^ |
| 17:31 | <annevk> | rniwa: yeah |
| 17:31 | <rniwa> | bzed: are you bz? |
| 17:31 | Domenic_ | shakes fist at item() |
| 17:31 | <annevk> | bzed != bz |
| 17:31 | <rniwa> | annevk: thanks. |
| 17:31 | <tantek> | jgraham maybe warm blooded vs. cold blooded (mammals vs reptiles) could be another analogy |
| 17:31 | <TabAtkins> | rniwa: What's so hard about relative selectors? Absolutizing them is a simple algo. |
| 17:31 | <rniwa> | annevk: another risk is that WebKit has historically supported stupid namedItem :( |
| 17:31 | <annevk> | Domenic_: item() laughs at you |
| 17:32 | <rniwa> | TabAtkins: I'm not saying it's hard. It requires a lot of work. |
| 17:32 | <annevk> | rniwa: that hasn't been refactored? |
| 17:32 | <tantek> | then again, even mammals don't typically spontaneously grow never-before-seen limbs (features) |
| 17:32 | <rniwa> | annevk: you mean namedItem? |
| 17:32 | <rniwa> | annevk: not in WebKit |
| 17:32 | <rniwa> | annevk: it has been in Blink. |
| 17:32 | <annevk> | TabAtkins: proper Elements support also requires a lot of work |
| 17:33 | <rniwa> | annevk: (I think) |
| 17:33 | <annevk> | rniwa: ait |
| 17:33 | <rniwa> | annevk: yeah... |
| 17:33 | <annevk> | But going with Array for now seems safe |
| 17:33 | <rniwa> | annevk: we might just do Array first and then add Elements later. |
| 17:33 | <TabAtkins> | All right. Not really sure how (you just do a quick check on the selector, then maybe prepend :scope), but whatever. |
| 17:33 | <TabAtkins> | annevk: Yeah, I'd believe that. |
| 17:34 | <tantek> | living things typically have a static total feature set (gene sequence) |
| 17:34 | <Domenic_> | that's interesting. having queryAll return an Array and then upgrading it to Elements later might be a backward-compat change |
| 17:34 | <tantek> | living things that grow new things here and there that were outside that feature set are typically the result of cancers |
| 17:34 | <TabAtkins> | It's actually correct to just do a string search on the selector (assuming we never define a ::scope pseudo-element). |
| 17:35 | <tantek> | so perhaps "living spec" would make more sense to apply to static feature set but inline updated errata specs |
| 17:35 | <Domenic_> | this is actually really good. it means queryAll could get implemented much faster. |
| 17:35 | <rniwa> | tantek: it would be nice to have snapshots of living standards with errata. |
| 17:35 | <TabAtkins> | tantek: And "cancerous spec" to ones like HTML? |
| 17:36 | <TabAtkins> | "mutagenic" |
| 17:36 | <rniwa> | tantek: i always get surprised by how much things have changed whenever i look at living standards :( |
| 17:36 | <tantek> | and a spec that grows new features beyond its base feature set would make m ore sense labled a "cancerous spec" |
| 17:36 | <rniwa> | Domenic_: not so fast in WebKit but yeah... at least we can unblock it from having implemented Elements. |
| 17:36 | <tantek> | rniwa - ah yes, you're one of the "various folks" I mentioned then |
| 17:38 | <Domenic_> | rniwa: is implementing relativize absolute selector that much work? feels like pull-request material... |
| 17:39 | <annevk> | Domenic_: note that rniwa and I were discussing returning an Array from querySelectorAll, not queryAll, though the latter seems ok too |
| 17:39 | <tantek> | rniwa - that sort of "living spec" model is what I'm seeing if I can push W3C to do. |
| 17:39 | <tantek> | since errata are pretty broken (in many ways) |
| 17:39 | <rniwa> | tantek: yeah, that'll be nice. |
| 17:39 | <rniwa> | tantek: in fact, that's how we release software products, right? |
| 17:39 | <tantek> | right |
| 17:39 | <rniwa> | tantek: we have trunk and then we branch for each release |
| 17:40 | <tantek> | lots of lessons to be reapplied |
| 17:40 | <rniwa> | tantek: "errata's" being merged into each branch |
| 17:40 | <annevk> | tantek: as humans grow, they're able to do more things, until they die, not sure the feature set is necessarily static |
| 17:40 | <tantek> | precisely rniwa |
| 17:40 | <annevk> | However, I don't object to branching, if we can find more people working in this space first... |
| 17:40 | <rniwa> | annevk: if you consider the feature set as the physical characteristics of a person, then it doesn't change much over the course of a human life |
| 17:40 | <rniwa> | tantek: if you do consider it as his/her knowledge, then it does. |
| 17:40 | <annevk> | It's not like we have many editors to go around fixing the platform bugs |
| 17:41 | <tantek> | annevk - they're able to do more things (applications) with the same genetics/physical expression (features) |
| 17:41 | <rniwa> | annevk: THAT (scarcity of good editors) is the biggest problem we have :( |
| 17:41 | <rniwa> | annevk: I'd rather have you and other good spec. editors writing actual specs and participating in discussions |
| 17:41 | <rniwa> | annevk: than doing branches and merging fixes :( |
| 17:42 | <rniwa> | annevk: because the latter is more of a tedious work... |
| 17:42 | <Ms2ger> | rniwa, tell webapps |
| 17:42 | <tantek> | so all you "master editors" have taken an apprentice right? ;) |
| 17:42 | <rniwa> | Ms2ger: tomorrow! |
| 17:42 | <Domenic_> | for smaller specs branching/tagging meaningful versions is pretty easy i think |
| 17:42 | <Domenic_> | for html it seems infeasible |
| 17:42 | <Domenic_> | but for e.g. fullscreen probably fine |
| 17:43 | <tantek> | rniwa are you coming to the webapps f2f tomorrow? |
| 17:43 | <tantek> | (cue Annie soundtrack) |
| 17:43 | <tantek> | annevk: http://en.wikipedia.org/wiki/List_of_human_anatomical_features ;) |
| 17:43 | <annevk> | Domenic_: seems like a chore, maintaining Fullscreen currently takes a couple hours every other week, that would make it worse |
| 17:43 | <annevk> | tantek: ok ok, maybe my argument is that I don't really buy the analogy :p |
| 17:44 | <annevk> | tantek: mostly, if someone could solve the resources problem, we can look at it again |
| 17:44 | <tantek> | annevk ok that's fair ;) |
| 17:44 | <tantek> | annevk, the resources to do spec branching/tagging don't have to be as capable as those editing trunk. |
| 17:45 | <tantek> | I'll let you draw your own conclusions where there are such resources ;) |
| 17:49 | <aklein> | Hixie: I'm curious about the script "entry settings object" (http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#entry-settings-object); in particular I'm interested under what circumstances you'd expect there to be no entry settings object |
| 17:50 | <aklein> | also, from a higher level, I'm wondering if the new ES6 tasks stuff breaks some expectation of HTML that the latter (HTML, that is) is always the actor calling into script |
| 17:51 | <aklein> | Domenic_: you might also be interested in my higher level concern, above |
| 17:51 | Domenic_ | starts listening |
| 17:51 | <arv_> | rniwa, annevk: Having querySelectorAll return an Array sounds good to me. We'll be happy to follow if you make this change in WebKit. |
| 17:52 | <Domenic_> | O_O |
| 17:52 | <aklein> | Domenic_: in trying to make V8 run Promise callbacks itself, we ended up in a position where Blink didn't have enough information about the page context |
| 17:53 | <aklein> | Domenic_: https://code.google.com/p/chromium/issues/detail?id=360891 is the bug, if you're interested; the use of Object.observe could be replaced with a Promises example |
| 17:53 | <annevk> | aklein: you want to talk to bz probably |
| 17:53 | <aklein> | annevk: I definitely want someone from Mozilla, yeah, as I suspect the entry settings object goes back a long way |
| 17:54 | <aklein> | its behavior is pretty surprising |
| 17:54 | <Domenic_> | yeah these sound like similar concerns to ones bz was voicing |
| 17:54 | <Domenic_> | ES6 *does* define the Realm in which these functions are called |
| 17:54 | <aklein> | ah, where/when was bz voicing these concerns? |
| 17:54 | <Domenic_> | namely, the same realm they were created in |
| 17:54 | <Domenic_> | presumably "script settings object" could be a property of the realm |
| 17:54 | <aklein> | sure, that's how all functions work |
| 17:55 | <rniwa> | that's some super hairy stuff :( |
| 17:55 | <aklein> | the distinction is between the "entry" settings object and any old settings object |
| 17:55 | <annevk> | aklein: he posted some examples to es-discuss I believe |
| 17:55 | <aklein> | annevk: ok, will go look |
| 17:55 | <annevk> | aklein: about what promises doesn't define at the moment |
| 17:55 | <Domenic_> | aklein: I'm not sure I understand that distinction |
| 17:55 | <Hixie> | aklein: when no script is running |
| 17:56 | <Domenic_> | aklein: my understanding is that window.location.href in that callback should refer to the window.location.href for wherever the function was created |
| 17:56 | <aklein> | Domenic_: nope, it's much crazier than that |
| 17:57 | <Domenic_> | so if you got the function from another iframe it would affect the other iframe |
| 17:57 | <aklein> | Domenic_: it actually depends not on where the function that's calling window.location.href lives |
| 17:57 | <aklein> | but instead on which document had the event or script tag in it |
| 17:57 | <Domenic_> | aklein: ah ok, this is one of those crazy web-compat things where the straightforward answer is not compatible |
| 17:57 | <rniwa> | aklein: please be sure to add that to ES6/W3C test suite. |
| 17:58 | <Domenic_> | it is starting to come back to me now |
| 17:58 | <aklein> | Hixie: so you'd be surprised if there was script running but there was no entry settings object? |
| 17:58 | rniwa | feels that "those crazy web-compat things" come up way too often in anything related to ES5/ES6 |
| 17:59 | <aklein> | rniwa: there are already incompatibilities between Blink and Gecko :( |
| 17:59 | <rniwa> | aklein: I'm sure there are plenty of them |
| 17:59 | <aklein> | rniwa: I mean in this particular case of Location |
| 17:59 | <aklein> | and "entry" settings |
| 17:59 | <aklein> | rniwa: you don't happen to know how JSC handles this notion, by any chance? |
| 18:00 | <rniwa> | aklein: definitely not, sorry :( |
| 18:00 | <annevk> | aklein: http://esdiscuss.org/topic/specification-styles#content-11 is the specific email I was thinking about |
| 18:00 | <rniwa> | aklein: you might want to check with weinig or ggaren on #webkit? |
| 18:01 | <annevk> | aklein: a script running without a settings object would go horribly wrong for a number of APIs |
| 18:01 | <aklein> | annevk: it certainly goes horribly wrong in chrome :) |
| 18:01 | <annevk> | aklein: all APIs that deal with URLs for instance |
| 18:01 | <annevk> | (except for new URL, funnily enough) |
| 18:02 | <Hixie> | aklein: there should definitely be a script settings entry whatsit if a script is running |
| 18:02 | <Hixie> | aklein: any time code executes, it has to go through http://www.whatwg.org/specs/web-apps/current-work/#jump-to-a-code-entry-point to execute |
| 18:02 | <Hixie> | aklein: that first calls http://www.whatwg.org/specs/web-apps/current-work/#prepare-to-run-a-callback which pushes a script settings object onto the stack of script settings objects |
| 18:04 | <Hixie> | aklein: actually, there's one other way script can run, which is callbacks run by WebIDL; WebIDL pushes the script settings objects onto the stack manually. See WebIDL 4.8. |
| 18:05 | <Hixie> | heycam|away|away: looks like webidl hasn't been updated to the new terminology regarding script settings objects btw |
| 18:10 | <aklein> | annevk: excellent, that is exactly the case, I'll study bz's post |
| 18:11 | <aklein> | Hixie: unfortunately https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tasks-and-task-queues also calls into script and doesn't use the HTML hook |
| 18:11 | <annevk> | aklein: might be worth posting that tidbit to es-discuss; both Allen and Domenic_ were surprised ES didn't match reality |
| 18:11 | <aklein> | (for obvious reasons, but still) |
| 18:11 | <annevk> | aklein: and I'm not sure they quite followed what bz went on about |
| 18:12 | <annevk> | aklein: seems like ES should expose some hooks (one of the other hooks it still needs is for a configurable this object) |
| 18:13 | <aklein> | I'm constantly amused that the way specs are segmented leads implementations to be broken in exactly the same way as the specs they implement |
| 18:13 | <aklein> | in this case, it's V8 caring not at all about tagging things as "entry" settings objects |
| 18:13 | <hober> | conway's law + murphy's law? |
| 18:14 | <aklein> | indeed |
| 18:15 | <aklein> | Hixie: the thread annevk linked to (http://esdiscuss.org/topic/specification-styles#content-11) might be interesting to you too... |
| 18:27 | <galineau> | TabAtkins: there is another sylvaing in #whatwg |
| 18:27 | <hober> | galineau: then use sgalineau so i can still s<TAB> |
| 18:27 | <TabAtkins> | Yus. |
| 18:28 | <TabAtkins> | STAB |
| 18:28 | <galineau> | TabAtkins: Stab Atkins! |
| 18:28 | <TabAtkins> | Stab Bat-Skins is my halloween name. |
| 18:28 | <annevk> | Hixie: what if we created a custom addEventListener for service workers that did something similar to what onmessage does in the port API? See https://github.com/slightlyoff/ServiceWorker/issues/225 for context |
| 18:29 | <annevk> | JakeA: ^ |
| 18:31 | <sgalineau> | RESOLVED |
| 18:32 | sgalineau | renamed himself. Must be Last Call! |
| 18:33 | <Hixie> | aklein: sounds like a bug in ES |
| 18:35 | <Hixie> | annevk: any particular reason we're using events here rather than just having a dedicated callback mechanism with one callback per "event"? that would make it unambiguous that it had different semantics. |
| 18:38 | <JakeA> | Hixie: you can importScripts 3rd party services which may want a say too |
| 18:39 | <Hixie> | ah |
| 18:39 | <Hixie> | so what happens if two event handlers do contradictory things? |
| 18:40 | <JakeA> | With fetch in particular, you're responding to a thing that happened and potentially making it do something other then the default, events seem to fit |
| 18:40 | <Hixie> | *shrug* |
| 18:41 | <JakeA> | Hixie: handing the request (respondWith) is an implicit prevent Default and stopImmediatePropogation |
| 18:41 | <Hixie> | uh |
| 18:41 | <JakeA> | Ugh, my phone made that really difficult to type |
| 18:41 | <Hixie> | this sounds less and less like true DOM events |
| 18:43 | <Hixie> | i think if you find yourself having to adjust how the API works both in registration and in handling, you might be better off just making a new API, personally |
| 18:43 | <Hixie> | (this isn't a bad thing) |
| 18:57 | <annevk> | JakeA: that could actually be nice |
| 18:58 | <annevk> | JakeA: we could have callbacks that have a promise as return value and such |
| 19:11 | <JakeA> | annevk: well, app.get(urlRe, callback) will be the first library I build |
| 19:11 | <JakeA> | annevk: but I want a catch-all to do the usual get-it-from-the-cache-if-its-there bit |
| 19:12 | <annevk> | JakeA: I mean that instead of event.respondWith() and waitUntil(), you'd have self.add("fetch", function() { return promise }) |
| 19:13 | <JakeA> | Hixie: annevk: It feel really similar to an event. Eg, I can observe click, I can also prevent the default and do something else. Fetch is like that, but the alternative response is passed to event.respondWith, which also calls event.preventDefault & event.stopImmediatePropogation |
| 19:13 | <annevk> | or self.listen() / self.observe() |
| 19:13 | <JakeA> | I'm not against it |
| 19:13 | <JakeA> | But is it different enough to warrant it? |
| 19:14 | <JakeA> | I can see us having an API in future where there's a url match. Might be a useful optimisation, but mostly useful for third party code |
| 19:15 | <annevk> | I don't see the current system matching events much |
| 19:15 | <annevk> | We want register side effects, we want to return promises |
| 19:16 | <JakeA> | It tells you about a thing that happened at a time when you can override default behaviour. Do we have DOM APIs that do that that aren't events? |
| 19:16 | <annevk> | .sort() |
| 19:17 | <JakeA> | array.sort()? |
| 19:17 | <JakeA> | That starts a sort, it doesn't listen for one |
| 19:18 | <annevk> | The callback is called and allows overriding behavior |
| 19:18 | <othermaciej> | callbacks with a promise as a return value? why would you want that? |
| 19:19 | <JakeA> | othermaciej: Well, that's exactly how .then() is |
| 19:19 | <annevk> | othermaciej: current API is onfetch = function(e) { e.respondWith(promise) } |
| 19:19 | <othermaciej> | I probably lack sufficient context but who is the ultimate consumer of the promise? |
| 19:20 | <othermaciej> | is there another layer of API that returns it? |
| 19:20 | <othermaciej> | I agree that calling an event method with a promise in an event handler seems dodgy |
| 19:20 | <annevk> | othermaciej: the browser consumes it and extracts a response object |
| 19:21 | <JakeA> | annevk: I see what you mean, but .sort triggers the event, and once it's complete, it doesn't happen again |
| 19:21 | <othermaciej> | the idea of returning a promise that the browser itself is supposed to use seems weird to me, but probably due to lack of understanding |
| 19:22 | <annevk> | JakeA: it seems we're not really using any bit from the event API and hacking around where it does not meet our needs |
| 19:23 | <annevk> | JakeA: it's not entirely clear what it buys us |
| 19:23 | <othermaciej> | I would expect the straightforward way to do it would be that a fetch callback gets some object that it can report to when (asynchronously) done |
| 19:24 | <JakeA> | othermaciej: When the browser makes a resource request, imagine it's creating a promise for the response. If the response fails, it does something else (eg, an image with an x). You get to provide that promise. |
| 19:24 | <annevk> | othermaciej: so the idea is that a response is an async value |
| 19:24 | <othermaciej> | but I guess if the async fetch it would do already naturally returns a promise, then it’s convenient |
| 19:24 | <annevk> | othermaciej: so we don't have to load the entire thing into memory |
| 19:24 | <annevk> | othermaciej: so yes, if you do a fetch in the worker it'll return a promise, which you would then give to the browser |
| 19:25 | <othermaciej> | sure, I assume you do potentially-asynchronous I/O in response to a fetch request |
| 19:25 | <JakeA> | othermaciej: we looked at respondWith(fetch(url)) vs fetch(url).then(respondWith) - the latter gets really messy fast |
| 19:25 | <othermaciej> | I am just not sure what the promise adds other than extra levels of indirection |
| 19:26 | <annevk> | othermaciej: right, so it seems kind of natural that you have dofetchrequest(callback) and callback returns a promise that handles the request et al |
| 19:26 | <annevk> | othermaciej: what else would you do? |
| 19:26 | <othermaciej> | I don’t know what respondWith is in that example |
| 19:27 | <annevk> | othermaciej: you might want to read up a bit on https://github.com/slightlyoff/ServiceWorker/ |
| 19:27 | <othermaciej> | annevk: I’m obviously not “thinking with promises” yet because you seem to expect that statement to be completely intuititvely obvious and it’s not to me |
| 19:27 | <JakeA> | othermaciej: In ServiceWorker's onfetch event, it's the mechanism to hijack the request and respond with something else |
| 19:27 | <annevk> | othermaciej: yeah sorry |
| 19:27 | <JakeA> | actually, it should be respondWith(fetch(url)) vs fetch(url).then(respondWith, respondWith) |
| 19:27 | <annevk> | othermaciej: I wish I could explain in person |
| 19:28 | <JakeA> | othermaciej: Providing a promise allows you to synchronously state your intention to handle the request but handle it in an async way |
| 19:28 | <othermaciej> | annevk: where is the viewable form of the spec in that? |
| 19:28 | <SamB> | ... so is there special magic that the browser does when it consumes a primitive promise in the return value of this failure callback? |
| 19:29 | <SamB> | like, never actually building the promised value? |
| 19:29 | <JakeA> | I'm not sure I get what you mean |
| 19:29 | <annevk> | othermaciej: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html is some of it I suppose |
| 19:30 | <annevk> | othermaciej: but I recommend reading https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md first |
| 19:30 | <JakeA> | SamB: It waits for the promise to resolve, if it rejects it's a network error. If it resolves with not-a-response, networkerror |
| 19:30 | <othermaciej> | that seems to have large chunks of missing and/or misformatted content so I assumed it was not the right thing |
| 19:31 | <othermaciej> | ok, looking at the example of the use of onfetch |
| 19:32 | <othermaciej> | I would have thought the natural thing would be that you can call e.respondWith at any later time, so if your actual fetch is asynchronous, you end up calling it outside the scope of the fetch callback |
| 19:32 | <othermaciej> | but I assume there’s some reason that is not good enough, or something |
| 19:32 | <othermaciej> | it also seems a bit weird to use an event listener for this, because there can only be one response |
| 19:33 | <othermaciej> | if there are 10 listeners registered, which one wins? |
| 19:33 | <JakeA> | othermaciej: Providing a promise allows you to synchronously state your intention to handle the request but handle it in an async way |
| 19:33 | <othermaciej> | does respondsWith implicitly prevent further event dispatch? |
| 19:33 | <JakeA> | yes |
| 19:34 | <JakeA> | preventDefault and stopImmediatePropogation |
| 19:34 | <othermaciej> | I see |
| 19:34 | <JakeA> | If you allow e.respondWith to be called at a later time, you get that race condition you mention |
| 19:34 | <othermaciej> | this seems pretty hard to understand for the uninitiated |
| 19:35 | <othermaciej> | it almost seems better to have a single callback, since otherwise you have a strong dependency on registration order, so your callbacks have to coordinate anyway |
| 19:36 | <JakeA> | We need to allow third party imports |
| 19:36 | <JakeA> | Order matters, just as it does with click events |
| 19:36 | <othermaciej> | if you do that, there’s no need to synchronously indicate intent to reply, and the whole thing becomes a lot simpler |
| 19:37 | <JakeA> | Yep, it makes it simpler with event listeners in general |
| 19:37 | <othermaciej> | is capture supported? |
| 19:37 | <JakeA> | No |
| 19:39 | <JakeA> | I'm open to the idea of this being not-an-event-listener (should be discussed on github), but we must support multiple "listeners" |
| 19:39 | <othermaciej> | I would say I’ll review it when there’s a spec, but by then it will probably be too late to five feedback |
| 19:39 | <othermaciej> | *give |
| 19:40 | <JakeA> | There's a ts file with the API if you want to give feedback earlier. It needs updating from the most recent f2f but it's pretty solid |
| 19:41 | <JakeA> | Oh, they're gone |
| 19:45 | <annevk> | JakeA: what is gone? |
| 19:46 | <JakeA> | othermaciej: There's a ts file with the API if you want to give feedback earlier. It needs updating from the most recent f2f but it's pretty solid |
| 19:47 | <JakeA> | annevk: othermaciej vanished for a moment |
| 19:49 | <Domenic_> | returning a promise is attractive FWIW |
| 20:00 | <annevk> | We should consider adding http://www.nohello.com/ to the topic, although it happens rarely enough I suppose |
| 20:00 | <annevk> | Domenic_: yes, the current API is ugly |
| 20:18 | <JakeA> | Domenic_: although we'd have to treat some return values as "unhandled", probably just undefined |
| 20:19 | <JakeA> | Domenic_: returning an actual response object should work |
| 20:23 | <Domenic_> | JakeA: just Promise.resolve() the return value |
| 20:33 | <JakeA> | Domenic_: hmm, feels nicer not to require that of the developer |
| 20:33 | <Domenic_> | JakeA: that's what I meant; the implementation should Promise.resolve() the return value |
| 20:34 | <Domenic_> | JakeA: step 8 onward of https://github.com/whatwg/streams#constructor-start-pull-cancel- |
| 20:34 | <JakeA> | Domenic_: but that gets racey if you have multiple "listeners" |
| 20:35 | <Domenic_> | JakeA: how so more racey than e.waitUntil? |
| 20:35 | <JakeA> | Something needs to be a sync signal of "nahhh, I'm not handling this" |
| 20:35 | <Domenic_> | oh gross |
| 20:35 | <Domenic_> | so the function has both sync and async behavior |
| 20:35 | <JakeA> | Domenic_: onfetch doesn't have waituntil |
| 20:36 | <JakeA> | Domenic_: depends how you think of it. You synchronously provide a promise, but that promise represents an async value |
| 20:37 | <JakeA> | Eg, you can't asynchronously provide a value to .then(), you need to return the response synchronously |
| 20:41 | <JakeA> | But yeah, undefined becomes "not handling" in the onfetch case. I guess this is why respondWith is a better intent |
| 20:42 | <Domenic_> | I guess I still prefer promise.then(respondWith) but I'll take your word for it that it's ugly. |
| 20:43 | <Domenic_> | I can already see that it's ugly for error-handling |
| 20:51 | <JakeA> | Domenic_: and racing |
| 20:52 | <JakeA> | Domenic_: eg two handlers |
| 21:21 | <slightlyoff> | sorry for not being available (was in TC39 meetings). othermaciej: happy to answer questions about fetch events |
| 21:22 | <slightlyoff> | Domenic_: it's super ugly |
| 21:22 | <slightlyoff> | Domenic_: the control inversion also doesn't work well with the need to get out of the way early |
| 21:25 | <slightlyoff> | Domenic_: the bigger issue is that ".then(resolveOtherThing)" still misses some way of saying "i've got this, keep me alive until I'm done" |
| 21:26 | <slightlyoff> | Domenic_: so even if you refactored this into 2 apis, you'd still need the moral equivalent of waitUntil() for deciding to "own" the transaction |
| 21:26 | <slightlyoff> | Domenic_: this is something that's also going to be required when we rework IDB |
| 21:26 | <Domenic_> | slightlyoff: hmm interesting stuff |
| 21:27 | <Domenic_> | having two use cases will help refine |
| 21:28 | <slightlyoff> | Domenic_: agreed. |
| 21:42 | <full_vlad> | hi all! |
| 21:42 | <full_vlad> | Can anyone help me with this problem? https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/sBCw0_jfLhI |
| 21:46 | <full_vlad> | it involves running a content script in all frames from a webpage |
| 21:52 | <TabAtkins> | This channel probably isn't helpful for Chrome Extensions questions. |
| 21:52 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#dom-form-requestautocomplete |
| 21:53 | <SamB> | full_vlad: they haven't even begun to standardize content scripts, so they'll not be of much help I'm afraid :-P |
| 21:55 | <full_vlad> | what I found so far is this: |
| 21:56 | <JakeA> | Domenic_: Sanity check: In cases where we provide promise equivalents to events, the promise should resolve after the event right? (https://code.google.com/p/chromium/issues/detail?id=343630#c10) |
| 21:56 | <full_vlad> | the extension runs well on Facebook, Twitter, old google chat (GTalk) |
| 21:56 | <full_vlad> | it doesn't run on Hangouts |
| 21:57 | <Domenic_> | JakeA: I agree with your reasoning. I also think requestAutocomplete is *perfect* for promises |
| 21:58 | <full_vlad> | but when I change the tabs it works, it just doesn't work on refresh |
| 21:59 | <full_vlad> | The Google Plus page (with Hangouts) has many iframes in it, so the content script has to run in its specific iframe (the one with the chat). If i run the privly.run() function inside that specific iframe manually it works |
| 21:59 | <JakeA> | Domenic_: Yeah, adding promises was always the intention. They just wanted out the door before they were available. Although that availability window turned out to be like a week or something |
| 22:00 | <SamB> | full_vlad: again, we don't really know about that stuff here! |
| 22:00 | <full_vlad> | Facebook and Twitter implement their chat box in the top frame, so I think that's the difference |
| 22:00 | <full_vlad> | ok, sorry |
| 22:00 | <JakeA> | Hixie: Looking at http://www.whatwg.org/specs/web-apps/current-work/#allowed-to-show-a-popup - So touchevents aren't a strong enough signal? |
| 22:01 | <full_vlad> | SamB, I just found a reference to your site in the Google content script documentation :p lol |
| 22:02 | <Hixie> | JakeA: that list was based on what browsers did at the time; i'm happy to add more if browsers want to add more |
| 22:02 | <SamB> | you mean whatwg.org? that's not *my* site :-) |
| 22:02 | <Hixie> | though honestly, on mobile, popups are even worse |
| 22:02 | SamB | 's mind is blown ... how can there be popups on mobile? |
| 22:03 | SamB | should think about getting a smartphone sometime ... |
| 22:04 | <JakeA> | Hixie: gotcha |
| 22:04 | <Hixie> | anyone else getting frequent 408s from bugzilla? |
| 22:07 | <esprehn> | Hixie: I think we want the autocomplete events to bubble |
| 22:07 | <esprehn> | Hixie: is there a reason you have all the new events not bubbling? We've gotten complaints from developers since it doesn't work with event delegation frameworks |
| 22:10 | <Hixie> | i tried to test chrome and it didn't seem to bubble there |
| 22:10 | <Hixie> | (you can always use capturing event handlers, btw, regardless of bubbling) |
| 22:11 | <Hixie> | i'm happy to make them bubble if chrome is going to change |
| 22:13 | <Hixie> | hsivonen: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=23940 and ping on the registry proposal thread |
| 22:14 | <esprehn> | Hixie: https://src.chromium.org/viewvc/blink?revision=170827&view=revision |
| 22:14 | <SamB> | Hixie: maybe Chrome is wrong |
| 22:15 | <esprehn> | Hixie: what was the reason for making simple events not bubble by default? |
| 22:18 | <Hixie> | esprehn: i like my defaults to be 0/false/""/null, generally. no other reason. |
| 22:18 | <Hixie> | esprehn: ah, good to see that change. will make them bubble. |
| 22:21 | <Hixie> | esprehn: done |
| 22:25 | <slightlyoff> | most events should bubble unless there's a security or privacy reason not to |
| 22:26 | <SamB> | slightlyoff: or a "that will really complicate applications" reason? |
| 22:26 | <esprehn> | yeah I think we might want to change the default, or at the very least fix up some events |
| 22:27 | <esprehn> | Hixie: ex. the form validation events don't bubble |
| 22:28 | <Hixie> | like 'invalid' ? |
| 22:28 | <Hixie> | you probably don't want 'invalid' to bubble, because there's not really any logical way to handle that generically |
| 22:30 | <Hixie> | slightlyoff: i don't see how there could be a security or privacy implication to any events bubbling or not. I think a bigger concern is whether it makes the API sane or not. e.g. clicking makes sense to bubble -- you click something, you're clicking its container. But 'load' on <img> doesn't make sense to bubble, because then it would get confused with the 'load' event on Window. |
| 22:30 | <Hixie> | with <form>, since you can't nest them, it doesn't really make any difference either way, so bubbling is probably fine |
| 22:31 | <Hixie> | 'toggle' on <details> wouldn't make sense to bubble since <details> can be nested, and you'd get confused about which one just opened. |
| 22:31 | <Hixie> | and so forth |
| 22:33 | <MikeSmith> | Hixie: 408s from w3c bugzilla? |
| 22:33 | <Hixie> | [24~yeah |
| 22:33 | <Hixie> | yeah, even |
| 22:35 | <slightlyoff> | it seems significantly better to have a general "the way this works" than to try to special-case based on local reasoning. |
| 22:35 | <slightlyoff> | trying to teach the web platform is really, really hard for these sorts of reasons |
| 22:35 | <Hixie> | nah, designing APIs to just follow arbitrary rules doesn't make things better, imho. |
| 22:36 | <Hixie> | i'm all for consistency, but not to the point of making APIs hard to use. |
| 22:36 | <Hixie> | i don't think anyone has trouble with the fact that <img onload> and <body onload> are different events. |
| 22:36 | <esprehn> | Hixie: all the entities in the acknowledgements section are double escaped |
| 22:36 | <Hixie> | but i think they'd get _really_ confused if <img onload> bubbles to <body onload>. |
| 22:36 | <Hixie> | esprehn: yeah, known bug (only affects the multipage copy) |
| 22:36 | <esprehn> | ah okay |
| 22:37 | <Hixie> | esprehn: a fix is in the works but i want to do a long-term fix for a bunch of related issues so for now it's still broken :-) |
| 22:37 | <slightlyoff> | Hixie: if that was just the way "it worked", they'd start to filter by event target and/or we'd provide a good filtering API for them |
| 22:37 | <esprehn> | Hixie: why would you get confused? the event.target points to the one that toggled? |
| 22:38 | <slightlyoff> | Hixie: but as it stands there's not good filtering API, no way to teach how it works without "...except in all of these other cases becaues that's the way it is" and no clear model for what got decided in which direction |
| 22:38 | <Hixie> | esprehn: because <body onload="start()"> would work fine until you inserted an <img>, and then your code would run twice and you'd have no idea why |
| 22:38 | <esprehn> | Hixie: I meant the <details> case, not that one |
| 22:39 | <esprehn> | onload we can't change, too much content doesn't understand |
| 22:39 | <esprehn> | but modern content does check the target. Developers are used to dealing with click like things |
| 22:39 | <TabAtkins> | Hixie: Why would toggle on details be confusing? It's no more confusing than "click". Being unable to do event delegation for things like "toggle" is annoying. |
| 22:39 | <Hixie> | esprehn: well again, <details ontoggle="animate(this)"> would work fine until you nested them, then it would break |
| 22:39 | <esprehn> | how is that different than onclick="animate(this)" ? |
| 22:40 | <Hixie> | the difference is that "click", conceptually, does affect all the elements in the chain |
| 22:40 | <Hixie> | you're clicking on the whole stack |
| 22:40 | <TabAtkins> | (No less confusing than "click" either, but the solution to figure out the target element is the same in both cases.) |
| 22:40 | <TabAtkins> | Hixie: You're projecting a *particular* mental model on that, which may not make any sense in some cases. |
| 22:40 | <TabAtkins> | In some cases for the author, it's really a particular element being clicked. Like a button. |
| 22:41 | <esprehn> | Hixie: that doesn't match conversations we'e had with developers recently |
| 22:41 | <esprehn> | they've complained that "invalid" and other new events don't bubble |
| 22:41 | <TabAtkins> | More importantly, though, the ergonomics of non-bubbling is annoying, as esprehn and slightlyoff are saying. |
| 22:41 | <TabAtkins> | Because you have to specifically register a listener on every element you want to listen to, rather than doing one for a subtree or the whole page. |
| 22:41 | <esprehn> | <form oninvalid="..."> doesn't seem unreasonable, you want a single listener that opens some kind of error bubble |
| 22:42 | <esprehn> | It uses event.target to figure out what thing wants the bubble |
| 22:42 | <TabAtkins> | Each-element listeners make it more complicated to do dynamic HTML updates. |
| 22:42 | <Hixie> | file a bug, if there's no compat problem we can change it |
| 22:42 | <Hixie> | whatwg.org/newbug |
| 22:42 | <slightlyoff> | There's also the non-trivial costs to many apps of needing to do specific registration |
| 22:42 | <SamB> | yeah, onload should probably not bubble ... |
| 22:42 | <Hixie> | i'm just objecting to the idea that we should blindly make all cases bubble |
| 22:43 | <SamB> | Hixie: yeah, of course not blindly |
| 22:43 | <Hixie> | remember, btw, that you can always get the bubbling behaviour using capturing handlers |
| 22:43 | <slightlyoff> | we implemented delegation in Dojo for many of the common event types (transparently to the users) to prevent us from incurring the (pretty bad) costs of having to thunk through the DOM everywhere vs. add a node to a filter list |
| 22:46 | <slightlyoff> | I'd need to look at which events are captureable in which browsers. I think there's some legacy baggage I'm carrying around in my head which might no longer be valid |
| 22:53 | <Hixie> | all events can always be captured |
| 22:54 | <smaug____> | There are cases when non-bubbling is exactly what you want. mouseenter/leave |
| 22:54 | <Hixie> | yeah, those are a good example too |
| 22:54 | <zewt> | but capturing events has a different event order; for delegation i usually want the delegate event listener to happen in the bubble phase, not capture |
| 22:55 | <Hixie> | you could always add a capture handler that cancels the event and redispatches it with bubbling enabled :-) |
| 22:56 | <zewt> | i think i basically never, ever want any event to not be bubbling; that's something that should be decided by the person listening, not the person dispatching (if I'm a listener and I want the behavior of a non-bubbling event, I'll just check the event phase) |
| 22:56 | <zewt> | that's far worse :) |
| 22:56 | <smaug____> | zewt: mouseenter/leave don't make sense if they bubble |
| 22:58 | <zewt> | not sure that mouseenter/leave make sense at all |
| 23:01 | <zewt> | seem like a lot of complexity just to save having to say if(e.eventPhase == e.BUBBLING_PHASE) return; |
| 23:01 | <Hixie> | the difference between nothing at all, and something at all, is significant, imho. |
| 23:02 | <Hixie> | onload="if (e.target == window) start()" vs onload="start()" |
| 23:02 | <Dashiva> | And 99% of the time mouseenter/leave is exactly what you want |
| 23:02 | <zewt> | the difference between all events having the same dispatch semantics, and some bubbling and some not, is also significant |
| 23:03 | <smaug____> | zewt: if(e.eventPhase == e.BUBBLING_PHASE) return; isn't enough |
| 23:03 | <zewt> | too late to fix it now, but it should have been a flag on addEventListener |
| 23:03 | <zewt> | smaug____: was trying to think if there are differences, but none came to mind |
| 23:04 | <zewt> | (performance, maybe) |
| 23:04 | <Hixie> | zewt: yeah i'm not saying i would have designed it this way from the start, certainly |
| 23:04 | <zewt> | (but you're still going through capture phase) |
| 23:07 | <smaug____> | if you move mouse from being on top of subtree A to be on top of subtree B, all the elements in subtree A get a mouseleave and in B a mouseenter. But you'd get only one mouseout/mouseover |
| 23:10 | <MikeSmith> | Hixie: no indication of timeouts in the bugzilla server logs |
| 23:10 | <MikeSmith> | and nobody else reporting anything as far as I know |
| 23:21 | <Hixie> | MikeSmith: odd |
| 23:21 | <Hixie> | MikeSmith: might just be a Chrome dev issue |
| 23:22 | <Hixie> | MikeSmith: i just get it intermittently |
| 23:23 | <MikeSmith> | ok |
| 23:36 | <TabAtkins> | zewt: If you don't think mouseenter/leave make sense, then I'm not sure you've ever tried to do anything robust with mouseover/out. |
| 23:37 | <TabAtkins> | Ah, reading further, yeah, you've probably never done anything with it. There are several complicated edge-cases to handle. It's *way* more than just worrying about doubling. |
| 23:37 | <TabAtkins> | bubbling, rather. |
| 23:37 | <TabAtkins> | Mousing over a child fires mouseout on your element, for example. |
| 23:38 | <SamB> | that's an ... interesting choice ... |
| 23:38 | <TabAtkins> | It's possible to have a mouseover without a corresponding mouseout, and vice versa. |
| 23:38 | <zewt> | the discussion was about bubbling, not about any of that |
| 23:38 | <TabAtkins> | SamB: It makes sense *for the chosen semantics of mouseover/out*. |
| 23:38 | <TabAtkins> | But those semantics don't match what people want most of the time. |
| 23:39 | <SamB> | yeah, that's why I said interesting and not braindead |
| 23:39 | <zewt> | and I was only talking about the difference between a non-bubbling event and just checking the event phase |
| 23:39 | <TabAtkins> | zewt: Ah, ok. Yeah, a bubbling mouseenter would make sense, since you can check whether you're getting it for the element you want or not. |
| 23:39 | <SamB> | so, presumably none of these four make sense bubbling? |
| 23:40 | <zewt> | every event makes sense bubbling (eg. delegation) |
| 23:40 | <SamB> | oh, but the non-pairing doesn't really sound like a good idea |
| 23:40 | <zewt> | (it could use a more concise way to check it, of course--these old DOM APIs aren't famous for being brief) |
| 23:41 | <SamB> | hmm, well, if you just want to have one listener that feeds the events into a different API, sure |
| 23:41 | <SamB> | however for your plain old onfoo= ... |
| 23:44 | <zewt> | i doubt any change would make sense today (we're already stuck with non-bubbling events) so i'm not really suggesting a change, but one approach would be for "non-bubbling" events to really mean event handlers (not listeners) ignore the event when in the bubble phase |
| 23:45 | <TabAtkins> | Now *that* sounds really reasonable. |
| 23:46 | <Hixie> | personally i'm pretty sure if i was designing this from scratch the entire approach would be quite different :-) |
| 23:47 | <Hixie> | maybe more based on promises or something |
| 23:48 | <TabAtkins> | Promises aren't suitable for repeating events, but something *like* promises is. I drew up some initial thoughts on the matter a while ago <http://www.xanthir.com/b4PV0>;, and something like that should either pop out of Streams or show up independently soon enough. |
| 23:57 | <Hixie> | mounir: i usually take patches and complaints of lacks of a spec as the firmest indication of interest short of shipping. :-) |
| 23:58 | <a-ja> | TabAtkins: ping |