| 08:54 | <annevk> | morning |
| 08:58 | <jgraham> | annevk: becoming a little more like dglazkov every day |
| 08:59 | <annevk> | yes |
| 09:08 | <jgraham> | Can we expect you to go through the religious stage ("God morning") and the English stage ("Good morning, what?") on your journey? |
| 09:11 | <annevk> | I'm not sure, I'd have to ask dglazkov |
| 09:35 | <jgraham> | zcorpan: I fixed testharness.js btw |
| 09:35 | <zcorpan> | jgraham: thanks |
| 09:35 | <jgraham> | Or, I think I did. Let me know if you still have problems |
| 10:01 | <annevk> | thanks zcorpan for testing that |
| 10:01 | <zcorpan> | np |
| 10:01 | <annevk> | Am I the only one not okay with Hallvord leaving large parts of copy and paste undefined? |
| 10:02 | <annevk> | I don't really want to do the explaining again :-( |
| 10:03 | <annevk> | I thought leaving large swaths of details undefined was Clearly Bad... |
| 10:03 | <jgraham> | Which parts is he leaving undefined? |
| 10:03 | jgraham | hasn't followed this spec at all |
| 10:04 | <annevk> | Whoa, so it's 2013 and tantek's name still gets messed up on http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/ |
| 10:05 | <annevk> | jgraham: "implementations may sanitize pasting" (which is pretty much required) |
| 10:05 | <annevk> | (paraphrasing) |
| 10:06 | <jgraham> | Hmm |
| 10:06 | <jgraham> | So it should clearly have requirements there about things that must be stripped |
| 10:07 | <jgraham> | I guess there could be an interop problem if a site assumes that there will never be certain kinds of input based on testing one browser |
| 10:07 | <jgraham> | So yeah, I agree, that should be defined |
| 10:15 | <annevk> | Can you maybe tell him on the list? |
| 10:16 | <jgraham> | Done |
| 10:16 | <annevk> | ta |
| 10:40 | <jonathanj> | hello, i'm looking for some clarity on the behaviour for HTTP redirects that specify a relative URL |
| 10:43 | <annevk> | jonathanj: allowed per HTTP/1.1-bis, has pretty much always worked in practice |
| 10:54 | <jonathanj> | annevk: thank you, i guess i was reading the old internet |
| 13:21 | <zcorpan> | tobie: odinho: has this happened? http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0858.html |
| 13:22 | <tobie> | zcorpan: not yet. |
| 13:22 | <zcorpan> | tobie: so if i want to submit some tests right now, i should use dvcs? |
| 13:23 | <tobie> | yup/ |
| 13:23 | <tobie> | s/\//./ |
| 13:23 | <zcorpan> | ok |
| 13:23 | <jgraham> | That *does* seem like makework |
| 13:23 | <tobie> | jgraham: what does? |
| 13:24 | <jgraham> | Submitting to dvcs now and then moving to github later |
| 13:24 | <tobie> | I guess it depends what you mean by makework |
| 13:26 | <tobie> | moving stuff to github won't take more or less time depending on how many tests are in the submission folder. |
| 13:27 | <zcorpan> | pushing to dvcs won't give a critic review |
| 13:29 | <zcorpan> | tobie: ETA on moving to github? |
| 13:30 | <tobie> | zcorpan: what's the WebApps process for CfC? |
| 13:30 | <zcorpan> | tobie: i think no objections past the deadline (22 march) means the CfC passes |
| 13:30 | <tobie> | ok. cool. Well |
| 13:31 | <zcorpan> | tobie: but maybe you should ask AB |
| 13:31 | <tobie> | Yeah. We should do this asap/ |
| 13:31 | <tobie> | Not sure whether Robin has import script we can use. |
| 13:32 | <tobie> | Also curious as to whether we can preserve versioning history somehow. |
| 13:32 | <jgraham> | He does and we can. I don't know if his script does or not though |
| 13:33 | <tobie> | That's pretty cool. I didn't know we could do that when merging into an existing repo. |
| 13:35 | <jgraham> | 13:36 < ArtB> I don't see any objections so yes |
| 13:35 | <jgraham> | [the CfC has passed] |
| 13:39 | zcorpan | *poof* |
| 13:40 | <jgraham> | tobie: One approach would be to use subtree-merge for example: http://git-scm.com/book/ch6-7.html |
| 13:44 | <tobie> | I'm swamped atm, so if anyone wants to move that forward, please be my guest. |
| 13:47 | <jgraham> | I thin it makes sense to sync with darobin. Which I think means "after Easter" |
| 14:11 | <zewt> | for great joy: gmail seems to have stopped randomly scrolling the page around whenever i focus the compose box |
| 14:30 | <annevk> | the Future is now |
| 14:30 | <annevk> | well almost |
| 14:55 | <hsivonen> | where's the implementation report for http://www.w3.org/TR/2013/REC-role-attribute-20130328/ ? |
| 15:35 | <dglazkov> | good morning, Whatwg! |
| 16:37 | <matjas> | annevk: is it too late for this? https://www.w3.org/Bugs/Public/show_bug.cgi?id=21424 |
| 16:38 | <annevk> | matjas: nah, it's a first draft |
| 16:38 | <annevk> | matjas: though I think the TC39 crowd prefers using these keywords now |
| 16:38 | <matjas> | pretty exciting for a first draft :) |
| 16:38 | <annevk> | I tried to get it right :) |
| 16:38 | <matjas> | wat |
| 16:39 | <annevk> | matjas: e.g. delete is favored over remove |
| 16:40 | <matjas> | i don’t understand. why break back-compat if it can so easily be avoided? |
| 16:42 | <annevk> | arv might know |
| 16:45 | <arv> | Yeah, keywords as property names is fine |
| 16:45 | <arv> | and used in ES6 standard library |
| 16:46 | <arv> | matjas: back compat? All browsers support ES5 |
| 16:47 | <Ms2ger> | We have always been at war with Eurasia |
| 16:52 | <matjas> | arv: older browsers don’t, and by naming a property `catch` you force people to wrap their code using Futures in `try/catch` if they don’t want it to break horribly in those older environments |
| 16:53 | <matjas> | arv: …as `foo.catch` is a SyntaxError as per ES3 |
| 16:53 | <arv> | matjas: Use foo['catch'] if you care |
| 16:53 | <matjas> | …not looking forward to that |
| 16:55 | <arv> | matjas: Design for the future, not for the past |
| 16:56 | <matjas> | arv: sure, but i’m not talking about changing the [API] design, just renaming a property |
| 16:57 | <matjas> | oh well :) |
| 16:59 | <jsbell> | This is only a problem if there's some yet-to-be-designed web API which is implementable as a polyfill itself in browsers that only support ES3 and that API uses Futures. Plausible but there is the workaround. |
| 16:59 | <jsbell> | Same debate happened with IndexedDB re: IDBCursor.continue(). |
| 17:01 | <jsbell> | Dangit, and I'd just gotten comfortable saying "... or some hypothetical standard futures/promises/deferreds API" |
| 17:01 | <matjas> | haha |
| 17:02 | <jgraham> | Presumably one can use Futures directly? |
| 17:03 | <jgraham> | That is presumably one can do something like make a library that implements Future XHR using DOM Futures? |
| 17:04 | <jgraham> | And then the DOM Futures part of that could be "polyfilled" in javascript |
| 17:04 | <jgraham> | So it doesn't depend on a hypothetical future DOM API |
| 17:04 | <jgraham> | s/it/the problem described/ |
| 17:06 | <matjas> | indeed it doesn’t. my point was that any JS file that contains `foo.catch` outside of a try/catch will throw a SyntaxError in ES3 environments |
| 17:06 | <matjas> | even if the code path itself won’t ever be reached in that browser, e.g. `if (false) { foo.catch; }` |
| 17:07 | <jsbell> | I think my point is: if that "Future XHR" is just something you've invented for your own use but not a standard API you're polyfilling, and yet you expect to use it on ES3 browsers, you're inventing your own problem. Indeed it would be nice to have your cake and eat it, but see arv's last point. |
| 17:08 | <matjas> | jsbell: this is not about _using_ Futures in ES3 environments |
| 17:09 | <matjas> | jsbell: it’s about being able to have a <script> that contains e.g. `if (featureDetect) { useFutures(); }` without it throwing an error in ES3 (graceful degradation) |
| 17:09 | <matjas> | jsbell: yes, it’s possible, but it requires using `foo['catch']` instead of `foo.catch` every time, or wrapping everything in a try/catch |
| 17:10 | <jsbell> | understood and no disagreement |
| 18:11 | <annevk> | matjas: I think in part that ship has sailed with continue, URLQuery.delete, and now catch |
| 18:11 | <annevk> | matjas: is this IE6 still? |
| 18:23 | <jamesr> | annevk, dfn.js calls a getCookie function which isn't defined in my browser |
| 18:24 | <annevk> | Hixie_: ^^ |
| 18:25 | <annevk> | jamesr: cannot fix that unfortunately |
| 18:25 | <jamesr> | also is the <!-- help --> asking for help with the intro to dom futures? |
| 18:25 | <annevk> | jamesr: will file a bug on HTML so Hixie_ gets to it at some point after adding thenable to Futures |
| 18:26 | <annevk> | jamesr: kinda, there's a ton out there, but if someone could write up a nice intro that'd be sweet, otherwise I'll get to it eventually |
| 18:44 | <jwalden> | someone should tell matjas that |try { obj.delete; } catch (e) { }| is a syntax error at parse time, not runtime, in es3 |
| 18:44 | <jwalden> | you can't try-catch away syntax errors |
| 18:52 | <annevk> | Futures in DOM now support thenable |
| 18:52 | <annevk> | basically by hooking directly into JavaScript internals |
| 18:52 | <annevk> | http://dom.spec.whatwg.org/#concept-resolver-resolve fun starts at step 3 |
| 19:34 | <zewt> | totally don't "get" futures; as far as I knew it was just a crazy bad idea on a blog somewhere, then suddenly it appeared in the spec |
| 20:10 | <Hixie_> | dfn.js users have to provide a getCookie() API |
| 20:11 | Hixie_ | comments out the call for now |
| 20:27 | <TabAtkins> | zewt: Futures/Deferreds/Promises are a great abstraction that captures a lot of concepts better than Events do, and which is used *all over* a lot of modern APIs. We're just finally settling on a design. |
| 20:36 | <zewt> | i haven't even seen an example of a problem with events, much less one that having a second, inconsistent interface solves--and it introduces all kinds of problems (two completely separate interfaces, which will make the platform badly inconsistent and fragmented) |
| 20:37 | <zewt> | it would need to solve some significant problems to be worth that |
| 20:40 | <jamesr> | events are pretty terrible |
| 20:40 | <zewt> | not at all |
| 20:40 | <zewt> | (afk, work) |
| 20:44 | <TabAtkins> | zewt: Then you're not looking. Some examples: |
| 20:45 | <TabAtkins> | zewt: Events fire once, and if you miss them, you're SOL. This means that some cases have to be architected very carefully to avoid race issues. Futures work identically whether they're pending or completed, so there's no need to worry about that. |
| 20:47 | <TabAtkins> | zewt: The design of events means that, if you have an operation that you need to wait on the result of, you need to return a value whose sole purpose is to be an event target. Futures make this less awkward, as the returned value is, in a more immediate sense, the value. |
| 20:48 | <TabAtkins> | zewt: Events don't have a useful algebra to build up from. You can't easily combine events together, or only do something when all of a list of events are finished, etc. Futures let you do this really easily. |
| 20:48 | <TabAtkins> | (And can be handled by a standard library, eventually.) |
| 20:50 | <TabAtkins> | zewt: It's much easier and more readable to chain Futures (do async thing A, when it's done do async thing B, when it's done do async thing C) than to do the same with events. |
| 20:52 | <TabAtkins> | Those are the big things, I think. Several things are equal or easier to read/write in Futures than in Events, Futures can be composed in powerful and simple ways, and Futures readily handle the reasonably common case where a value may be either pending *or* completed. |
| 21:24 | <odinho> | 14:37 < jgraham> 13:36 < ArtB> I don't see any objections so yes 14:37 < jgraham> [the CfC has passed] *dance *dance :D/-< |
| 21:32 | <odinho> | Hm... I don't see my +1 email for that, maybe I forgot sending it :P Ohwell. |
| 21:54 | <annevk> | Hixie_: could you make getCookie() optional via an existence check? |
| 21:54 | <annevk> | Hixie_: it's not needed for the core functionality as none of my specs provide that |
| 21:54 | <annevk> | Hixie_: and they work but get a console error |
| 21:55 | <annevk> | TabAtkins: yeah, need to add Future.when() at least |
| 21:56 | <annevk> | or .all() |
| 21:56 | <annevk> | whatever the most popular name is |
| 21:57 | <Hixie_> | annevk: i commented it out |
| 21:57 | <annevk> | that works :) |
| 21:58 | <TabAtkins> | Yes, .all() and .first() or whatever. |
| 21:59 | Hixie_ | is getting tired of making changes to the spec that do nothing but move prose into webidl |
| 22:05 | <annevk> | Hixie_: Gecko is implementing Web IDL / winter is coming |
| 22:18 | <jgraham> | Winter is coming? We haven't even had spring yet! |
| 22:21 | jgraham | can only do meterological complaints, not pop culture references |
| 22:21 | <odinho> | Was a touch of spring on the west coast of Ireland, -- but back here in Oslo it's still bad. |
| 22:23 | <jgraham> | Well today it was "OK". But which is mean +4C maximum. And now it is -5C. And my garden is still under 30cm of snow. |
| 22:45 | <annevk> | jgraham: you forgot that Web IDL originates from Australia |
| 22:53 | <zewt> | TabAtkins: events firing once is a non-issue; that's a well-understood, solved issue in the whole platform |
| 22:54 | <zewt> | i see no difference between returning an event target and returning some other object that's called something else |
| 22:54 | <TabAtkins> | zewt: It's hardly well-understood or solved. We have several bad instances of it in HTML (often due to legacy), and we create new ones as we go along, like Font Load Events. |
| 22:54 | <zewt> | you can easily handle things like "wait for all events" with DOM Events without making up something completely different |
| 22:55 | <jamesr> | events are pretty bad. requestAnimationFrame just avoids the completely, for instance (the original moz proposal used them and it sucked) |
| 22:55 | <zewt> | don't understand chaining (need code examples) |
| 22:55 | <TabAtkins> | No, you can't, at least not without manually coordinating across event callbacks by decrementing a global variable or something. |
| 22:56 | <zewt> | building a "do something when certain events are all received" is hardly a problem that needs a whole new incompatible inconsistent API for (and that's my main issue--ugly API fragmentation with interfaces that are utterly different in design and style) |
| 22:57 | <zewt> | also, confusion about something that seemed like a random blog suggestion suddenly appearing in the spec--i didn't see any discussion on this on any of the relevant lists that I know of, it just sort of materialized |
| 22:57 | <jwalden> | ugly API fragmentation? you must be new here :-) |
| 22:57 | <zewt> | not really :) |
| 22:57 | <jamesr> | https://github.com/slightlyoff/DOMFuture/blob/master/README.md has code examples using XHR |
| 22:58 | <zewt> | i've seen enough ugly API fragmentation in web APIs to be wary of introducing more of it, especially at such a core level |
| 22:59 | <zewt> | wow there's some bad logic in this page |
| 23:00 | <zewt> | "Making matters worse, the callback and event names don't even match! Clearly DOM needs a better way to do things." things are inconsistent, therefore we need a totally different api! |
| 23:09 | <zewt> | don't see any practical examples of chaining on that page |