| 00:51 | MikeSmith | will be busy for the next half hour or so |
| 02:38 | <MikeSmith> | https://twitter.com/pamelafox/status/489541624154689536 |
| 02:38 | <MikeSmith> | "To confirm, "allow-popups" means allow window.open? There's no way to prevent window.prompt/alert, correct?" |
| 02:38 | <MikeSmith> | that true? |
| 02:38 | <MikeSmith> | Hixie: ☝️ |
| 02:39 | <caitp-> | does it actually mean anything at all in non-IE browsers? afaik all of those properties basically don't work in chrome/ff |
| 02:39 | <Domenic> | wat |
| 02:40 | <caitp-> | certainly anything involving window decorations doesn't work, but from experimentation I've noticed that some other ones didn't either, so I'd be surprised if any of them really worked |
| 02:40 | <SamB> | any of what? |
| 02:41 | <caitp-> | what are they called, the comma-separated options you can pass to window.open |
| 02:42 | <caitp-> | the interop for those has basically always been a myth |
| 02:42 | <caitp-> | oh, but I guess allow-popups isn't one of them |
| 02:42 | <caitp-> | maybe I'm talking out of my ass after a few glasses of wine :) |
| 02:43 | <caitp-> | are they talking about csp then or something? i'm confused :D |
| 02:50 | <MikeSmith> | caitp-: yeah csp |
| 02:51 | <MikeSmith> | she was replying to Mike West |
| 02:52 | <caitp-> | yeah, csp is probably less broken than window.open options |
| 02:53 | MikeSmith | goes back to listening to Bigott's The Reno Poem |
| 02:53 | <SamB> | caitp-: you're talking about those evil things that people used to use to pop up browser windows with the %^@@^@ chrome stripped off so you couldn't easily do what you wanted with them? |
| 02:54 | <caitp-> | yeah, terrible stuff |
| 02:55 | <SamB> | best interop there is probably NOP |
| 02:55 | <SamB> | for the most part |
| 02:55 | <caitp-> | i recall there was a thread on blink-dev about making those either actually work, or throwing them away entirely, recently |
| 02:56 | <caitp-> | can't remember which it was |
| 02:57 | <SamB> | maybe some way to slim them down a bit, but let the user unslim at his/her whim, would be acceptable ... |
| 02:58 | <caitp-> | anyway, it was my misunderstanding of a tweet, I blame alcohol, can't expect me to be fully lucid at any hour, let alone 11pm :) |
| 03:39 | <Hixie> | MikeSmith: there's no way to either prevent or allow window.alert and company, correct. I would expect browsers to make sandboxed window.alert() rather uninteresting, though. |
| 04:27 | <MikeSmith> | Hixie: ok |
| 09:02 | <Ms2ger> | krit, why rename DOMRectList yet again? |
| 09:02 | <Ms2ger> | krit, that has a non-trivial engineering cost that could be better used elsewhere |
| 09:07 | <krit> | Ms2ger: not that I am favour for renaming it it Legacy... What is the engineering cost? After all, Gecko would require WebKit, Blink and ie I rename it from ClientRectList to the new name anyway. |
| 09:07 | <Ms2ger> | Gecko and Servo have renamed ClientRectList already |
| 09:07 | krit | excuse typos, am on my phone |
| 09:08 | <Ms2ger> | Haven't webkit and friend? |
| 09:08 | <Ms2ger> | friends* |
| 09:08 | <krit> | So? If you don't want the renaming, speak up on the mailing list. I renamed it since everyone wanted me to |
| 09:09 | <krit> | No, no one renamed it yet |
| 09:09 | <Ms2ger> | No one except two |
| 09:09 | <Ms2ger> | Alright, I'll complain |
| 09:09 | <Ms2ger> | Also, what happened to https://dvcs.w3.org/hg/FXTF/rev/46405013c12f? |
| 09:09 | <krit> | Well, it is no bug deal to rename |
| 09:10 | <jgraham> | Putting "Legacy" in the name of things is just stupid |
| 09:10 | <krit> | Ms2ger: removed ArrayClass by request from hey am |
| 09:10 | <krit> | Heycam |
| 09:10 | <Ms2ger> | And now added it back? |
| 09:10 | <krit> | Ms2ger: but everyone else wanted it back |
| 09:11 | <Ms2ger> | At least annevk replied that he's not part of "everyone else" |
| 09:11 | <krit> | Ms2ger: yeah, heycam admitted that it might have been a mistake to remove it |
| 09:13 | <krit> | Ms2ger: vote for renaming it back on the mailing list and we will see what the TAG thinks about it |
| 09:15 | <Ms2ger> | Done |
| 09:16 | <Ms2ger> | Anyway, I've already spent more time on this spec than I can justify |
| 09:47 | <krit> | Ms2ger: k, thanks |
| 10:16 | <JakeA> | Returning true/false with a promise feels really awkward. Eg asyncMap.has(key).then(function(hasKey) { ... }) - I guess it's a lot more natural in async functions |
| 10:40 | <JakeA> | …even more awkward with asyncMap.get(key).then(function(item) { }) - where item is undefined if it's not in the map |
| 10:43 | <smaug____> | hayato: so while implementing shadow dom in blink, did anyone go through all the is-in-doc and get-current-doc (which can be null, unlink ownerDoc) cases ? |
| 10:48 | <foolip> | Ms2ger, jgraham, I'm thinking about adding some Fullscreen API tests to web-platform-tests, but all but the most trivial require a trusted click event, which would make them manual tests |
| 10:49 | <foolip> | In Blink/WebKit the test environment has a way to produce trusted clicks, which is used for this kind of thing |
| 10:49 | <Ms2ger> | Gecko has something similar, but jgraham doesn't like it :) |
| 10:49 | <Ms2ger> | Maybe WebDriver? |
| 10:49 | <jgraham> | I was going to say that I didn't think that anyone liked it :p |
| 10:49 | <foolip> | Do you have any ideas about how to write tests so that the tests can be run both manually and automatically? |
| 10:50 | <jgraham> | WebDriver is certainly the long-term solution |
| 10:50 | <foolip> | ok, I looked a bit at that yesterday actually, but wasn't sure what I was looking at |
| 10:50 | <foolip> | are there any existing tests on the form I'm talking about to compare with? |
| 10:50 | <jgraham> | Well the problem is that we're not really read to accept webdriver tests yet |
| 10:51 | <jgraham> | We need to decide on a client binding |
| 10:51 | <smaug____> | testharness could rely on some browser specific library. So when run in Gecko it would use SpecialPowers object to dispatch trusted events |
| 10:52 | <foolip> | smaug____: that was basically my thinking, yes |
| 10:53 | <jgraham> | smaug____: I think it wouldn't be quite that simple, but yeah, I guess the short term solution is to have a file that is empty by default and vendors can replace to provide a specific implementation of trusted clicks |
| 10:53 | <foolip> | I suppose I could also just write manual tests, and then when importing those to Blink add a script that clicks the magic button after onload |
| 10:54 | <jgraham> | Yeah |
| 10:54 | <foolip> | how would things look with WebDriver, in the shiny future? |
| 10:55 | <jgraham> | Well with webdriver I guess you would have a python file that did something like webdriver.get("test.html"); webdriver.getElementByCSSSelector("#button").click() |
| 10:56 | <jgraham> | Assuming we have python bindings |
| 10:56 | <foolip> | with webdriver, is the python test the top-level thing? |
| 10:56 | <foolip> | if so each test would require an identical python counterpart? |
| 10:56 | <foolip> | that would be unimpressive |
| 10:57 | <jgraham> | It would be interesting if we could invert the control somehow, or use templating |
| 10:58 | <foolip> | indeed, something like that |
| 10:58 | <jgraham> | e.g have test.webdriver.html with <meta name="webdriver" content="test.py"> and test.py would look like webdriver.get("{{location}}")[...] |
| 10:59 | <jgraham> | That actually seems like a pretyt neat solution |
| 10:59 | <smaug____> | python? |
| 10:59 | <foolip> | are there no JavaScript bindings for WebDriver? |
| 10:59 | <jgraham> | There are |
| 10:59 | <jgraham> | But |
| 10:59 | <jgraham> | They all require node |
| 10:59 | <jgraham> | and webdriver is sync |
| 11:00 | <jgraham> | So they are all hacks to make js act in a sync way |
| 11:00 | <foolip> | hmm |
| 11:00 | <jgraham> | I'm not at all crazy about making node a dependency for the testsuite when python already is |
| 11:01 | <Ms2ger> | +1 |
| 11:01 | <smaug____> | js would feel more natural ... |
| 11:01 | <foolip> | otherwise a <script language="text/javascript+webdriver"> or something that'll be ignored by the browser could be a way |
| 11:01 | <smaug____> | (and js is less horrible language) |
| 11:01 | <jgraham> | smaug____: I think that second point is highly debatable :p |
| 11:02 | <smaug____> | based on empirical data, me writing python, python is a bad language. Slow to write and easy to make errors ;) |
| 11:03 | <smaug____> | and hard to read |
| 11:03 | <jgraham> | smaug____: Curiously I have the same experience with js :p |
| 11:03 | <jgraham> | But if you think python is hard to read I don't know what to tell you |
| 11:03 | <foolip> | so, um, trolling aside, I guess right now I can't make it all nice and pretty |
| 11:03 | <jgraham> | foolip: Not really, sorry |
| 11:04 | <Ms2ger> | We all know smaug____ has poor taste in languages :) |
| 11:04 | <foolip> | so I think I'll try the manual test thing, and include a script that inserts a button to click, which could be modified when integrated with Blink or Gecko |
| 11:04 | <foolip> | unfortunately those tests will have -manual in the name, which may cause problems |
| 11:05 | <jgraham> | Given that we haven't really solved "have a testsuite requiring just web-exposed features that all browsers actually run", getting one with opt-in to non-web-exposed features hasn't been a priority |
| 11:05 | <foolip> | or would it be ok to have them fail by default? |
| 11:06 | <jgraham> | Well I don't mind tests that fail, but tests that *can't* pass even if you implement the feature are going to upset peopke |
| 11:06 | <jgraham> | *people |
| 11:06 | <foolip> | so maybe having them manual by default is the most conservative option |
| 11:07 | <jgraham> | Yeah, unfortunately I think it is |
| 11:08 | <jgraham> | Assuming we eventually solve this via webdriver, I guess there might be a plan by, say, the end of the year to get that working |
| 11:09 | <foolip> | ok, this stuff is hard, it seems |
| 11:11 | <jgraham> | Yeah, it's hard because it's not cross browser |
| 11:12 | <jgraham> | I mean we could probably solve it in a slightly hacky way, but I'm not super-desperate to extend the current gecko SpecialPowers stuff into wpt |
| 11:14 | <foolip> | One thing I realize now is that some tests will actually need trusted clicks multiple times, when entering nested fullscreen |
| 11:14 | <foolip> | the way the WebKit tests are written is to have a runWithKeyDown() helper that runs your function in a trusted event |
| 11:15 | <foolip> | converting that to WebDriver would require a way to ask the WebDriver to click somewhere, but does there exist a communication channel to make that request? |
| 11:17 | <jgraham> | Yeah, you can return data if needed |
| 11:17 | <foolip> | kind of like postMessage? |
| 11:17 | <foolip> | returning data once isn't going to be good enough I think |
| 11:18 | <jgraham> | Well the API isn't event based, so it's hard to react to a stream of events |
| 11:19 | <jgraham> | But you can do things like executeAsyncScript() which runs a function in the scope of the page, and can poll for data |
| 11:19 | <foolip> | ok, so you could fall back to polling for a button to press? |
| 11:19 | <smaug____> | how well is the svg spec maintained ? |
| 11:20 | <smaug____> | shepazu might know |
| 11:20 | <jgraham> | foolip: If you only need to find a single button and there is an event you could executeAsyncScript(onevent = function(event) {callback(event.button)}) or something |
| 11:20 | <jgraham> | Or do that once per button you need to find |
| 11:24 | <jgraham> | It's not that intuitive if you come from a browser background |
| 11:24 | <jgraham> | It would have worked better if they'd made the API async. But the theory is that people testing web sites are typically not comforatble with that kind of programming :| |
| 11:37 | <foolip> | ok... |
| 11:38 | <foolip> | I guess it's all hypothetical until I can actually try WebDriver in wpt |
| 11:42 | <jgraham> | Yeah, I guess it's a worry that trying to seperate out this kind of priviledged action will be less convenient than SpecialPowers-like APIs which just allow people to wantonly mix browser-specific stuff into otherwise cross-browser tests, so they won't bother to write cross-browser tests at all |
| 12:33 | <MikeSmit1> | smaug____: which SVG spec? 1.1? |
| 12:34 | <MikeSmit1> | smaug____: krit could help probably |
| 12:35 | <krit> | smaug____: SVG2? Depending of the kind of issue you have, pretty responsive https://svgwg.org/svg2-draft/ |
| 12:36 | <smaug____> | krit: I'm just going through is-in-doc checks |
| 12:36 | <krit> | smaug____: basic maintenance of SVG1.1… don’t expect updates till the next errata |
| 12:36 | <smaug____> | in order to figure out how shadow dom actually should work |
| 12:36 | <krit> | smaug____: oh, shadow-dom :) well, that is very vague at the moment |
| 12:37 | <krit> | smaug____: you can also email on www-svg and might get some feedback from Blink… they actively based <use> on shadow DOM |
| 12:39 | <smaug____> | krit: well, in blink shadow dom + is-in-doc is rather random |
| 12:40 | <smaug____> | things work against the current specs etc |
| 12:40 | <smaug____> | I'm mainly trying to figure out how on earth to implement shadow dom in interoperable way |
| 12:41 | <krit> | smaug____: in Blink? |
| 12:41 | <krit> | smaug____: or across HTML/SVG ? |
| 12:41 | <smaug____> | well, all that |
| 12:42 | <krit> | smaug____: ok, IIRC this is still an open question on the Shadow DOM side (I thought you meant <use> based on shadow DOM because I recently was speaking with someone about that) |
| 12:43 | <krit> | smaug____: Many thinks in the Shadow DOM spec require HTMLElements |
| 12:43 | <krit> | smaug____: currently SVGElement does not inherit from HTMLElement |
| 12:43 | <smaug____> | right |
| 12:44 | <krit> | smaug____: you should ask dglazkov_ when it comes to Shadow DOM. He might have a way forward |
| 12:55 | <JakeA> | Are there any APIs that suggest a response has status 200 (vs 4**/5**), even if the response is from another origin, aside from appcache? |
| 12:55 | <JakeA> | (assuming the request is no-cors) |
| 13:04 | <MikeSmith> | JakeA: none I can think of. Not that my knowledge could be considered broad.. |
| 13:06 | MikeSmith | looks at https://dvcs.w3.org/hg/dap/raw-file/tip/discovery-api/Overview.html |
| 13:07 | <JakeA> | MikeSmith: trying to work out if the appcache thing was a mistake that shouldn't be repeated |
| 13:09 | <MikeSmith> | JakeA: I think it wasn't an unintentional mistake at the time it was specced at least (as opposed to in hindsight now). But you'd probably want to hear from the guy who wrote it, as far as the rationale |
| 13:09 | <MikeSmith> | provided he still remembers at this point |
| 14:03 | <Domenic> | Does any browser implement add*Event*Listener for MediaQueryList? |
| 14:03 | <Ms2ger> | I doubt it |
| 14:03 | <jgraham> | foolip: So I realised on the tube that something like <script type="text/webdriver+python">getElement("#button").click()</script> would be rather straightforward to implement |
| 14:03 | <Domenic> | yeah MDN was unhelpful. but i noticed today for the first time that the spec included EventTarget |
| 14:04 | <Ms2ger> | It was discussed a while ago |
| 15:14 | <caitp> | you mean because it's not implemented in blink? |
| 16:10 | <Ms2ger> | https://twitter.com/Aeyoun/status/489790384193548288 |
| 16:17 | <Ms2ger> | showModalDialog ... was never formally standardized |
| 16:17 | <Ms2ger> | abarth, wat |
| 16:21 | <jgraham> | Ms2ger: Really? |
| 16:34 | <abarth> | Ms2ger: hi |
| 16:35 | <Ms2ger> | How is that claim true? |
| 16:35 | <abarth> | dunno |
| 16:35 | <Ms2ger> | Why'd you make it, then? |
| 16:36 | <abarth> | i didn't write the blog post |
| 16:36 | <abarth> | despite it having my name attached to it :( |
| 16:36 | <Ms2ger> | That seems like a poor situation |
| 16:37 | <abarth> | indeed |
| 16:38 | <SimonSapin> | Hixie: http://whatwg.org/html#quotes uses selectors like :root:lang(af), :not(:lang(af)) > :lang(af). Why this rather than just :lang(af)? AFAICT they’re equivalent, assuming no other 'quotes' declaration in the UA stylesheet. |
| 16:41 | <Ms2ger> | I think the issue was with <p lang=en>Voltaire said <q lang=fr>quelque chose</q> |
| 16:41 | <Ms2ger> | Does quotes apply to the element it's set on? |
| 16:41 | jgraham | is not down with the kids enough to know which blog post is being refered to |
| 16:42 | <Ms2ger> | http://blog.chromium.org/2014/07/disabling-showmodaldialog.html |
| 16:51 | <Hixie> | SimonSapin: the problem is other 'quotes' declarations in the UA stylesheet |
| 16:51 | <Hixie> | SimonSapin: or the author style sheet |
| 16:57 | <SimonSapin> | oh, right. In <div lang=en><p style="quotes: '«' '»'"><q>, :lang(en) would apply instead of the inherited value. |
| 16:58 | <Hixie> | right |
| 16:58 | <Hixie> | there's a bug on the current selector though |
| 16:58 | <Hixie> | arguably it's wrong |
| 16:58 | <Hixie> | i forget the problem |
| 16:58 | <Hixie> | something about what language to use on the quotes itself, or something |
| 16:58 | <Hixie> | or whether to reset the counter when you change languages |
| 17:05 | <Hixie> | can i just say that specificity was a mistake |
| 17:05 | <Hixie> | a cool seeming, clever-sounding, mistake. |
| 17:08 | <jgraham> | s/specificity/css/ ? :) |
| 17:10 | <Ms2ger> | s/css/the web/? |
| 17:12 | <Hixie> | css and the web as a whole aren't mistakes, they're good ideas with mistakes in them |
| 17:13 | <Hixie> | specificity is just a mistake. |
| 17:14 | <SimonSapin> | "W3C Invites Implementations of Polyglot Markup: A robust profile of the HTML5 vocabulary" |
| 17:15 | <Ms2ger> | Of course |
| 17:38 | <jgraham> | Hixie: CSS isn't a mistake, but if you started from a clean slate today you would end up with something pretty different, I think |
| 17:38 | <Ms2ger> | With or without the experience we've had with CSS? |
| 17:43 | <jgraham> | Either? |
| 17:47 | <Hixie> | jgraham: yeah. like, no specificity. :-) |
| 17:48 | <Hixie> | jgraham: and pretty different layout model primitives |
| 17:49 | <astearns> | and presumably none of these: http://wiki.csswg.org/ideas/mistakes |
| 17:50 | <jgraham> | I was mostly thinking of the layout model primitives |
| 17:51 | <jgraham> | And the sort of combinatorial explosion of complexity that happens every time you add a new one |
| 17:51 | <Domenic> | I really like that mistakes page |
| 17:51 | <Domenic> | it humanizes the CSSWG |
| 17:59 | <Hixie> | some things in that list are wrong |
| 17:59 | <Hixie> | e.g. "Table layout should be sane" isn't a CSS mistake |
| 17:59 | <Hixie> | it would have been far worse for CSS to not be compatible with what browsers already had |
| 18:00 | <Hixie> | and specificity is missing from that list :-) |
| 18:37 | <gsnedders> | It's a problem with CSS, if you call them mistakes. Whether the CSS WG could do anything about them is tangential. |
| 19:29 | <TabAtkins> | Someday fantasai and I will finish nailing down the actual layout primitives, so it'll at least be clear *what* things are exploding in complexity when you add a new one. |
| 20:09 | <mathiasbynens> | Domenic: re: https://github.com/tc39/test262/pull/4#issuecomment-49222581 sure, once I get back from vacation :) |
| 20:09 | <Domenic> | mathiasbynens: awesome :) |
| 20:10 | <mathiasbynens> | Domenic: has there been any discussion on what to do with JS tests in https://github.com/w3c/web-platform-tests? |
| 20:11 | <mathiasbynens> | WPT has a lower barrier for entry (no CLA signing etc.) but test262 has a better structure, at least for JS specifically |
| 20:11 | <Domenic> | mathiasbynens: I was not aware that those tests existed; I don't think anyone else was either. |
| 20:14 | <gsnedders> | mathiasbynens: how many of them are correct per ES6? |
| 20:14 | <mathiasbynens> | gsnedders: not sure |
| 20:15 | <mathiasbynens> | but it seems like something can be done now to avoid duplicate efforts in the future |
| 20:15 | <mathiasbynens> | even if it’s just adding a note to the WPT readme |
| 20:16 | <gsnedders> | it'd be nice to look through opjsunit too, but most of that is either really basic stuff or regression tests |
| 20:17 | <mathiasbynens> | i need to port http://mathias.html5.org/tests/javascript/ too (only the idenfitier tests need updating as per ES6) |
| 20:48 | <mathiasbynens> | JakeA: can you confirm that http://www.chromestatus.com/features/6561526227927040 should be moved to M38? |
| 20:57 | <JakeA> | mathiasbynens: yes |
| 21:19 | <Domenic> | A lot of stuff on that page is not up to date with blink-dev announcements, at least this morning |
| 21:19 | <mathiasbynens> | ok, updated the SW section. you guys should probably get edit access ;) |
| 21:21 | <Domenic> | JakeA: https://jakearchibald.github.io/isserviceworkerready/ doesn't reflect that Chrome 36 fixed Promise.resolve |
| 21:22 | <mathiasbynens> | http://domenic.me/aplus-tests-against-the-browser/ went from ~150 to 24 failures because of that |
| 21:25 | <JakeA> | Domenic: will update, cheers |
| 21:33 | <tobie_> | JakeA: have you considered returning Promise.race() for entries missing in the cache as suggested here: http://esdiscuss.org/topic/promise-any#content-7 |
| 21:33 | <TabAtkins> | tobie_: "Returning promise.race()" is a weird way to say "return an eternally pending promise". |
| 21:34 | <tobie_> | TabAtkins: well, it's a weird way to describe a weird concept. So it might be fitting. |
| 21:35 | <TabAtkins> | What's weird about a pending promise? |
| 21:36 | <tobie_> | TabAtkins: nothing. |
| 21:36 | <TabAtkins> | EXACTLY |
| 21:36 | <tobie_> | TabAtkins: an *eternally* pending one, on the other hand… |
| 21:36 | <TabAtkins> | At least say "new Promise()". ^_^ |
| 21:37 | <tobie_> | That throws. |
| 21:37 | <tobie_> | (not sure if impl or spec issue.) |
| 21:37 | <TabAtkins> | new Promise(function(){}) |
| 21:37 | <TabAtkins> | Probably on purpose. |
| 21:41 | <tobie_> | That indeed reads better (than Promise.race()). Unsure why scott used Promise.race() instead. |
| 21:41 | <TabAtkins> | It technically does the same thing. |
| 21:42 | <tobie_> | Well, sure, but one expresses the intent a lot more clearly. :) |
| 21:42 | <TabAtkins> | Indeed. ^_^ |
| 21:45 | <tobie_> | I'm curious as to whether returning an eternally pending promise works accidentally for this given cache/network race scenario or has other interesting properties. |
| 21:46 | <TabAtkins> | Depends on what you mean by "accidentally". It avoids triggering the race end-times behavior. |
| 21:46 | <tobie_> | Well sure, I understand the how it works in that case. |
| 21:48 | <tobie_> | JakeA tweeted earlier about whether cache.get(missingEntry) should resolve to undefined or reject. |
| 21:49 | <tobie_> | And both seem not ideal. Which is why I find this seemingly weird return an eternally pending promise suggestion at least worth looking into. |
| 21:50 | <tobie_> | s/And both seem not/Neither seem/ |
| 21:56 | <TabAtkins> | Hmm, interesting. |
| 21:56 | <TabAtkins> | I don't think that eternally-pending is very great, though it has some interesting properties. |
| 21:56 | <TabAtkins> | It doesn't mix with future "await", for example. |
| 21:57 | <TabAtkins> | (You'd have to guard every get() with a Promise.race(cache.get(), Promise.timeout(...)), for example.) |
| 22:09 | <tobie_> | Not sure. Wasn't he suggesting resolving the initial promise with an an eternally pending promise? (Not sure if that changes anything.) |
| 22:10 | <TabAtkins> | "the initial promise"? |
| 22:47 | <tobie_> | TabAtkins: the promise returned by cache.get would get "resolved" with an eternally pending promise as a value. |
| 22:47 | <TabAtkins> | I don't think Jake was suggesting that, but I might need to reread his post. |
| 22:47 | <tobie_> | TabAtkins: Jake wasn't. Scott was. |
| 22:48 | <tobie_> | TabAtkins: http://esdiscuss.org/topic/promise-any#content-7 |
| 22:48 | <TabAtkins> | Ah, yes. |
| 22:49 | <TabAtkins> | Still, bad idea. It makes .race() "just work", but has a number of bad properties I don't think we should accept. |
| 22:49 | <TabAtkins> | For example, you can't ever tell via .get() that the key wasn't in the map. |
| 22:50 | <TabAtkins> | We shouldn't *ever* return an eternally-pending promise from UA operations, because once we get "await", it'll be a footgun that freezes your code execution. |
| 22:50 | <Hixie> | will we always know they won't be eternal? |
| 22:50 | <TabAtkins> | (It's okay if something *ends up* as eternally-pending for outside reasons, like a network request that never happens to complete, but it shouldn't happen when we have control over everything.) |
| 22:51 | <Hixie> | ah, fair enough |
| 22:52 | <Hixie> | though usually if you have complete control over everything, you don't need to use a promise :-) |
| 22:52 | <tobie_> | TabAtkins: yeah, so that was my initial question. Is the the fact it makes .run() just work accidental or is there something more interesting behind these eternally pending promise that would make it a worthwhile pattern to use. |
| 22:52 | <tobie_> | Sounds like the answer is: nope that was accidental. |
| 22:53 | <SamB> | TabAtkins: are you saying that if it can be determined that a promise that already got returned is never gonna come back, it should then fail unless the browser has decided to apply sanctions to the relevant page anyway? |
| 22:58 | <TabAtkins> | tobie_: Okay, in that context, definitely accidental. It just happens to prevent .race() from prematurely ending. |
| 22:59 | <tobie_> | How would the UA know about that in all but the most trivial cases? (Sounds like the halting problem to me.) |
| 23:01 | <TabAtkins> | tobie_: Right, accidental. It just happens to be what's needed to keep .race() from ending prematurely. |
| 23:03 | <Hixie> | tobie_: the UA wouldn't know per se, but the UA implementor can prove it in many cases |
| 23:08 | <SamB> | tobie_: obviously I'm not saying this should happen in general, but there are often spots in the code where the UI implementor will know stuff like "this operation can't possibly complete anymore" and write it in a comment ... |
| 23:09 | <TabAtkins> | SamB: No, I'm just saying that a UA should never do the equivalent of "return new Promise(function(){});" in its code. |
| 23:09 | <TabAtkins> | That is, they should never return a promise that, intentionally, doesn't return. |
| 23:10 | SamB | is now confused about whether promises are about lazy evaluation or async I/O |
| 23:11 | <TabAtkins> | Both! |
| 23:11 | <SamB> | so I'm not the only one then! |
| 23:11 | <Hixie> | they can do both, and other stuff |
| 23:12 | <SamB> | sounds overloaded |
| 23:12 | <TabAtkins> | (And the conflict between those two sometimes means you're conflicted on whether to fulfill with a "kinda failure" value, or reject with an error. |
| 23:12 | <TabAtkins> | ) |
| 23:12 | <SamB> | are they short for "campaign promises" |
| 23:12 | <Hixie> | that's like saying a function can be used for I/O and calculation, and is therefore overloaded... |
| 23:12 | <SamB> | Hixie: yeah |
| 23:12 | <TabAtkins> | Like what Jake is stressing over - whether cache.get(), when the key isn't in the cache, should fulfill with undefined, or reject with a NotFoundError. |
| 23:12 | <SamB> | Hixie: if it's for calculation, it should be a pure function that doesn't have any side effects |
| 23:13 | <SamB> | or, well, effects |
| 23:13 | <Hixie> | so a function that does I/O should never e.g. concatenate a path and a filename? :-) |
| 23:13 | <Hixie> | because that's a calculation? :-) |
| 23:15 | <SamB> | well, if it involves IO it's stuck in the IO monad, obviously |
| 23:15 | <SamB> | ;-P |
| 23:16 | <TabAtkins> | Promises, the *construct*, can be used for plenty of things. They're a pretty general tool for representing any async computation. |
| 23:16 | <TabAtkins> | Any individual promise will only be used for one thing, of course. |
| 23:16 | <SamB> | TabAtkins: one can only hope! |
| 23:16 | <TabAtkins> | Objecting to Promises being used for multiple things is like objecting to monads. ^_^ |
| 23:16 | <SamB> | perhaps it would be helpful to have names for typical genres of promise |
| 23:17 | <SamB> | (I'm not saying that APIs should actually include those names, mind you; but they could be useful in API documentation.) |
| 23:19 | <TabAtkins> | So far we haven't been using them for lazy eval, so it's not important yet. |
| 23:19 | SamB | tries to understand what, exactly, a Monad Objector would do |
| 23:20 | <TabAtkins> | Go read es-discuss when we were discussing promises, and you'll see. |
| 23:20 | <TabAtkins> | (Lots of people opposed to the "complexity" of monadic promises, because they don't understand what monads are.) |
| 23:20 | <TabAtkins> | It's because "monad" is a stupid ugly name that should die, of course, but still. |
| 23:21 | <SamB> | maybe binding promises would be a better name for such a thing |
| 23:21 | <SamB> | or not, that might be too punny |
| 23:21 | <TabAtkins> | I think actual lazy evalutation as a use for promises is looked down on, actually. |
| 23:21 | <TabAtkins> | It means the promise waiting until it gets a listener to do some work. |
| 23:22 | <SamB> | TabAtkins: that's how lazy evaluation works, yes ;-) |
| 23:23 | <TabAtkins> | What I mean is, you shouldn't use promises for that. ^_^ At least, not directly. Returning a thunk which you can *force* to evaluate (and when then returns a promise for such) is fine. |
| 23:23 | <tokebloke> | Um... what the hell is a stylesheet with a href like this? <link href="//b.example.com/blabla.css";? |
| 23:23 | <tokebloke> | Two //s in the beginning followed by a hostname... |
| 23:23 | <TabAtkins> | tokebloke: //foo.com is a scheme-relative url. |
| 23:23 | <TabAtkins> | Means it'll use the same scheme (http or https) as the base url. |
| 23:24 | <tokebloke> | Really? You can do that?! |
| 23:24 | <TabAtkins> | Yup, supported everywhere. |
| 23:24 | <tokebloke> | ... |
| 23:24 | <Domenic> | anything but a promise for undefined is a horrible idea. |
| 23:24 | <tokebloke> | This piece of knowledge could've saved me hundreds of hours... |
| 23:24 | <TabAtkins> | Domenic: I'm pretty sure I agree with you. |
| 23:25 | <TabAtkins> | Though the idea of using rejection as a control-flow mechanism is intriguing, it really should be reserved for the same stuff that we'd throw errors for in sync code. |
| 23:25 | <TabAtkins> | (Because it'll turn into errors when we get "await".) |
| 23:25 | <Domenic> | TabAtkins: BTW I wanted to +1 your reply in pretty much every aspect. But I thought that would be contentless so I did not. |
| 23:25 | <TabAtkins> | Which one? |
| 23:25 | TabAtkins | has been doing too manyt hings today. |
| 23:25 | <Domenic> | To the Promise.any thread |
| 23:25 | <TabAtkins> | Ah, kk. |
| 23:30 | <tokebloke> | RSS feeds and HTML pages must be the most abused standards... |
| 23:30 | <tokebloke> | People just type whatever the hell they feel like with no regard to the standards. |
| 23:30 | <tokebloke> | Or logic, or common sense. |
| 23:30 | <TabAtkins> | The "thunk" thing is similar to what I specced for FontFace, for example. You can construct a FontFace with a url, and it doesn't do anything immediately. If you observe the load status via .ready(), still nothing. You have to explicitly ask it to start loading, via .load(), to get it to start doing work, and it returns a Promise at that point for the |
| 23:30 | <TabAtkins> | completion fo the work. |
| 23:30 | <TabAtkins> | tokebloke: See /topic. |
| 23:31 | <tokebloke> | :| |
| 23:46 | <SamB> | tokebloke: I'm sorry about your wasted hours! |
| 23:46 | <SamB> | and yes, RSS and HTML *are* pretty darn abused |
| 23:48 | <SamB> | I should like to see an abuse of RSS 3.0, though, for some reason ;-) |
| 23:50 | <SamB> | (See <http://www.aaronsw.com/weblog/000574>; and <http://www.aaronsw.com/2002/rss30>;) |
| 23:57 | <tokebloke> | I hate finding out actual useful stuff like that. |