| 04:44 | <Domenic> | I wonder who thought making <object> a full-fleged form element was a good idea |
| 04:44 | <Domenic> | It has the 6 validity APIs, and a form attribute |
| 04:45 | <Domenic> | I guess in Web Apps 1.0 people still thought <object> might be a good thing, unifying iframe/img/applet/embed? Or maybe not, since they created audio/video? |
| 04:57 | <annevk> | Domenic: I think it already was and Hixie didn't want to make things inconsistent |
| 04:58 | <Domenic> | Huh OK |
| 04:58 | <Domenic> | I wonder how that worked, back in the brief period where people were excited about implementing object |
| 04:58 | <Domenic> | Maybe some plugin actually created form data or something |
| 04:58 | <annevk> | Domenic: there might have been some more love for <object> early on too, until the complexity was more unearthed |
| 04:59 | <annevk> | Domenic: yeah, maybe, I don't know |
| 06:07 | <annevk> | MikeSmith: spam: https://www.w3.org/Bugs/Public/show_bug.cgi?id=30114 |
| 06:08 | <MikeSmith> | annevk: thanks yeah saw that and banned them already |
| 06:09 | <annevk> | MikeSmith++ |
| 06:11 | <MikeSmith> | wish I could lock our old components there against changes from new users |
| 06:13 | <MikeSmith> | annevk: btw I am still not confident about my own understanding of “Main fetch” as far there being any default for the request mode when stepping through that algorithm |
| 06:13 | <annevk> | MikeSmith: there's no default for request mode |
| 06:14 | <MikeSmith> | what I wrote in https://stackoverflow.com/questions/44121783/fetch-api-default-cross-origin-behavior/44125919#44125919 I’m not sure myself that’s correct |
| 06:14 | <annevk> | MikeSmith: fetch() has a default though |
| 06:14 | <MikeSmith> | oh |
| 06:14 | <MikeSmith> | well see the part of that spec cited in that question: |
| 06:14 | <MikeSmith> | > A request has an associated mode, which is "same-origin", "cors", "no-cors", "navigate", or "websocket". Unless stated otherwise, it is "no-cors". |
| 06:15 | <MikeSmith> | that is what confused the OP |
| 06:15 | <MikeSmith> | and me, really |
| 06:15 | <annevk> | MikeSmith: ah, the default is different for fetch() |
| 06:15 | <MikeSmith> | OK I figured so but I could not find where the spec expicitly says that |
| 06:15 | <annevk> | MikeSmith: it might be worth removing the default for requests though that would require going through all downstream invocations |
| 06:16 | <MikeSmith> | well I think that we should not change |
| 06:16 | <annevk> | MikeSmith: https://fetch.spec.whatwg.org/#dom-request 5.5 |
| 06:17 | <annevk> | MikeSmith: folks continue to think (justifiably) that fetch() is fetch |
| 06:17 | <MikeSmith> | yeah |
| 06:17 | <MikeSmith> | but I think it is (relatively) clear and good, that when, e.g., the HTML invokes the fetch algorithm for, say, <script src> that gets called with mode: no-cors |
| 06:17 | <MikeSmith> | right? |
| 06:17 | <MikeSmith> | if so that I think we should not change |
| 06:18 | MikeSmith | looks at https://fetch.spec.whatwg.org/#dom-request step 5.5. |
| 06:18 | <MikeSmith> | ah yes |
| 06:18 | <MikeSmith> | > Set fallbackMode to "cors". |
| 06:18 | <MikeSmith> | so yeah I remember now I assumed that is what was being hit |
| 06:19 | <MikeSmith> | wil update that SO answer |
| 06:20 | <annevk> | MikeSmith: for <script src> it should be "no-cors" yes, but we could also note that explicitly in HTML if we wanted to |
| 06:21 | <MikeSmith> | OK yeah I may create a PR for that then |
| 06:24 | <annevk> | MikeSmith: we'd have to find all call sites first |
| 06:24 | <MikeSmith> | have done that before :) |
| 06:25 | <MikeSmith> | but still dunno.. not sure it would be worth the time, if implementors don’t find it ambiguous or confusing |
| 06:26 | <annevk> | MikeSmith: we could also add a note under request's mode that the effective default for fetch() and Request is "cors" |
| 06:27 | <annevk> | MikeSmith: or maybe there's a better place to explain that the API and underlying abstraction are separate... |
| 06:28 | <MikeSmith> | I guess for HTML if we were to explain it, it should be at point of use and the points in the spec that define things that case fetches |
| 06:29 | <MikeSmith> | I think that would be the most helpful to authors |
| 06:29 | <MikeSmith> | and it seems like authors are the ones that would benefit from have it clarified, not implementors |
| 06:30 | <MikeSmith> | anyway, not a high priority so maybe for now I will just raise an issue |
| 08:31 | <hsivonen> | I'm behind the times on Promises. What should I read to learn how to create my own Promises to return from a .then() processing a fetch-provided promise? |
| 08:36 | <annevk> | hsivonen: mdn? new Promise takes an init function that is passed a resolve and reject function, which you can use to fulfill the promise is the tl;dr |
| 08:39 | <hsivonen> | yeah, the part I have trouble with, even after reading MDN, is: I do a bit of processing in then(), but what should I return to return and always-succeeding promise to continue the chain? |
| 08:40 | <hsivonen> | examples tend to focus on doing something with an API that returns a promise and not on how to continue the promise chain after the processing you wrote yourself |
| 08:40 | <hsivonen> | (of course, I missing something *very* basic, but what?) |
| 08:42 | <hsivonen> | maybe what I want is learning async/await right away and skipping over how things were like before them |
| 08:42 | <TabAtkins> | hsivonen: If you just want the resulting promise to contain a value you obtain from doing stuff in the .then() callback, just return that value; it implicitly gets wrapped in a fresh Promise. |
| 08:43 | <TabAtkins> | If you the "stuff" you're doing ends up with you holding another Promise, and you want the result of the .then() to contain what's inside of your "other Promise", again just return it - it automatically chains the internal value. |
| 08:44 | <hsivonen> | TabAtkins: ooh. so magical. |
| 08:45 | <TabAtkins> | The only time you ever have to create a new promise manually is if you're not currently in a promise and want to start one. (Or you're using a legacy async api that doesn't return a promise, and want it to interoperate with a promise chain.) |
| 08:45 | <TabAtkins> | hsivonen: It's just a functor/monad. ^_^ |
| 08:45 | <hsivonen> | TabAtkins: So I just "return;" from a .then() callback to return a promise than simply resolves? |
| 08:45 | <TabAtkins> | Yup. |
| 08:45 | <hsivonen> | TabAtkins: thanks |
| 08:45 | <TabAtkins> | If you just "return;" like that, then the resulting promise will resolve to undefined (your return value), but it will definitely resolve successfully. |
| 08:46 | <TabAtkins> | aka: |
| 08:46 | <TabAtkins> | let x = fetch(...).then(res=>doSomeWork()); => x is a promise holding the result of doSomeWork(). |
| 08:47 | <hsivonen> | TabAtkins: thanks. that was what I was missing |
| 08:47 | <TabAtkins> | let x = fetch(...).then(res=>doSomeAsyncWork()); => x is a promise that will resolve when doSomeAsyncWork()'s promise resolves, to the same value. |
| 08:48 | <TabAtkins> | And if doSomeWork() throws, or the promise returned by doSomeAsyncWork() rejects, then x will reject as well. |
| 12:37 | <Domenic> | annevk: are you going to be unreachable for two (?) months, or just not working? Also, when exactly are you getting back? |
| 14:22 | <annevk> | Domenic: July 4, though week before that I should be available during Mozilla week |
| 14:23 | <annevk> | Domenic: vacation, will likely drop in from time to time from past experience |
| 14:24 | wanderview | should take a long vacation |
| 14:24 | <wanderview> | it takes me like 2 weeks to forget about work |
| 14:25 | <Domenic> | annevk: OK, thanks. So for your specs, I was thinking to merge things that I think you'd accept, without waiting for explicit approval, while pinging you for things I'm unsure on. WDYT? |
| 14:26 | <Domenic> | Mostly I am thinking of in-flight PRs you have mostly accepted but are still going through editorial turns or discussions |
| 14:26 | <wanderview> | all commit message should contain "while the cats away..." |
| 14:26 | <annevk> | Domenic: sgtm |
| 14:26 | <annevk> | Hah |
| 14:58 | <aleray> | hi, using HTML5lib python, how can I set the value of a tag attribute (let say href attribute of <a> tag) in a filter without HTML5lib escaping it? |
| 15:01 | <aleray> | gsnedders, ^^ |
| 15:06 | <aleray> | wip: http://dpaste.com/18JF8PD |
| 15:27 | <gsnedders> | aleray: there's no way to do that |
| 15:29 | <gsnedders> | aleray: essentially, all the escaping is done by the serializer, and the filters can merely alter the contents of the tokens |
| 15:38 | <jgraham> | jugglinmike: Ask jdm |
| 15:38 | <jgraham> | Erm |
| 15:41 | <aleray> | gsnedders, how could I do then? Working directly on the tree? |
| 15:41 | <jugglinmike> | nox: are you in today? |
| 15:41 | <nox> | In? |
| 15:42 | <jugglinmike> | put differently: are you available to talk today (since jgraham tells me that it is a French holiday, and I assume that means you must be in France)? |
| 15:45 | <jugglinmike> | I'm working on the `testharness.js` library in the Web Platform Tests project. I'd like to use Promises in that code, and jgraham has previously been reluctant about that. He suggested that this may interfere with Servo's ability to use WPT, so I wanted to learn more before committing any more time to that work |
| 15:46 | <jugglinmike> | but if you are celebrating, then by all means enjoy. This can certainly wait |
| 15:46 | <jgraham> | jugglinmike: (I can't rememeber if this is related to this question, but it isn't possible to make async_test serial by default. You could maybe make it opt-in) |
| 15:47 | <jugglinmike> | jgraham: nope, that's unrelated. This is about honoring promises returned from functions passed to `Test#add_cleanup` |
| 15:47 | <jgraham> | Oh, right |
| 15:49 | <jugglinmike> | I still don't know exactly what the problem is, but my guess is that we don't want all tests to suddenly start requiring the global Promise constructor. That way, consumers that don't define it could still run tests that don't technically need Promises |
| 15:50 | <jugglinmike> | but it's to be expected that they would continue to fail those tests that do |
| 15:50 | <jyasskin> | jugglinmike: Which consumers still don't have Promises? |
| 15:51 | <jugglinmike> | I don't know. If that is actually the issue that jgraham has in mind when he mentioned Servo, then I would assume Servo |
| 15:51 | <jgraham> | jyasskin: I don't know if servo managed to integrate promises yet |
| 15:51 | <jyasskin> | https://github.com/servo/servo/issues/4282 is closed, indicating they have. |
| 15:52 | <tobie> | jugglinmike: my understanding is the goal of testharness is to be backwards compatible with older browsers whenever possible |
| 15:52 | <jugglinmike> | Actually, I do think that the general concern may still be relevant. I'm usually |
| 15:52 | <jugglinmike> | tobie: yeah, that's the point I was just about to make ^ |
| 15:53 | <jyasskin> | There are also polyfills that older browsers could stick in their testharnessreport.js. |
| 15:53 | <jgraham> | If it will work in Servo I don't have any specific objections fwiw |
| 15:53 | <jugglinmike> | Practically speaking, though, there's nothing testharness.js can do to make tests that depend on Promises work in older browsers (short of including a polyfill) |
| 15:53 | <jugglinmike> | which is not to say we shouldn't be careful |
| 15:53 | gsnedders | points out we fixed IE6 support only a year ago in testharness.js |
| 15:54 | <jugglinmike> | because there's still value for older browsers to blacklist tests that truly depend on un-implemented features |
| 15:54 | <jyasskin> | I'd argue that you shouldn't be slowed down by worrying about a lack of Promises in particular. |
| 15:54 | <jgraham> | I don't consider testing N-1 level browsers to be particularly interesting, but I do care about keeping servo's main testsuite working in servo (and same for latest Chrome, Firefox, Safari, Edge) |
| 15:55 | <jugglinmike> | but that use case would be precluded if testharness.js assumed Promise as a matter of course |
| 15:55 | <jgraham> | gsnedders: I think we did that because it happened to be trivial |
| 15:55 | <gsnedders> | jgraham: right |
| 15:55 | <jgraham> | Anyway, I think there's an engineering tradeoff here |
| 15:55 | <gsnedders> | in general I'm against making changes that break testharness.js in old browsers unless the gain is notable |
| 15:55 | <jgraham> | It depends on the value of this feature vs the cost |
| 15:56 | <jgraham> | So to assess that we also need to know the value of the feature, not just the cost |
| 15:58 | <jugglinmike> | The feature in question is extending `Test#add_callback` to honor promises returned by the provided function |
| 15:58 | <jgraham> | jugglinmike: Right, but what's the use case? |
| 15:59 | <jugglinmike> | It's important for Service Worker tests, where the cleanup logic typically includes an invocation of `ServiceWorkerRegistration#unregisiter` |
| 15:59 | <jyasskin> | jugglinmike: You can probably do that without mentioning the window.Promise object. Just check for and use the .then() method of whatever the provided function returns. |
| 15:59 | <jugglinmike> | I'll say that lack of support here hasn't been an issue so far practically, but that lack of support makes a race condition of those tests |
| 16:00 | <jyasskin> | It's easier to do using Promise, but possible without it. |
| 16:00 | <jugglinmike> | yeah, I've been thinking about that, too |
| 16:01 | <jugglinmike> | I think the heavy lifting would come down to a custom Promise.all implementation, but that's not a difficult thing to implement |
| 16:01 | <jugglinmike> | Although I'm not sure. It's been a while since I looked at my patch. I'm happy to try that |
| 16:01 | <jgraham> | OK |
| 16:12 | <aleray> | gsnedders, what do you advise then? |
| 18:22 | <Yuhong> | It is unfortunate EdgeHTML was not based on Tasman but I guess by the time they realized they need it it was too late. |
| 18:23 | <Yuhong> | In the meantime they keep adding new "modes" on Trident with each new version of IE. |