| 06:03 | <domfarolino> | annevk: theoretically if I had an IDL dictionary with a nullable boolean member, this would let you, in the spec, later distinguish between a number, null, and completely omitted right? |
| 06:06 | <domfarolino> | s/number/boolean |
| 06:06 | <domfarolino> | (in other words: it is fair expect implementations to distinguish between null and undefined here, no?) |
| 07:05 | <annevk> | domfarolino: yup |
| 07:05 | <annevk> | domfarolino: whether it's great API design depends a bit though, but gotta go, vacation time |
| 07:05 | <domfarolino> | annevk: Enjoy & thanks! |
| 07:26 | <domfarolino> | JakeA: You around? |
| 07:30 | <JakeA> | domfarolino: yep! |
| 07:36 | <domfarolino> | JakeA: IIRC you did a good bit of the Abort{Controller,Signal} work in Fetch. I'm curious about step 30 under the Request() constructor https://fetch.spec.whatwg.org/#dom-request |
| 07:37 | <domfarolino> | Seems that |r|, made in step 29, will have the same signal as the input request's signal |
| 07:38 | <domfarolino> | So by the time we get to 30, |signal| is either input request's signal or the signal provided via RequestInit. |
| 07:39 | <domfarolino> | And if we don't provide anything signal in RequestInit, does that mean in 30 we're essentially asking r's signal to follow itself? |
| 07:39 | <domfarolino> | (sorry for obscure question) |
| 08:00 | <JakeA> | domfarolino: r won't have the same signal, it always has a new signal |
| 08:01 | <domfarolino> | Ah ok that's what I originally thought then I talked myself in believing the opposite. |
| 08:02 | <JakeA> | domfarolino: In step 30, |signal| will only be not-null if an input request was provided, or a signal was provided in RequestInit |
| 08:02 | <domfarolino> | So r's signal will either follow 1.) input request's, when RequestInit does not provide a signal 2.) RequestInit's signal when it is non-null 3.) nothing |
| 08:03 | <domfarolino> | JakeA: Ah yeah, ^ is what you just said. Perfect thanks |
| 08:03 | <JakeA> | Correct |
| 08:03 | <JakeA> | Signal from RequestInit takes priority over input request |
| 08:04 | <domfarolino> | Right, makes sense |
| 10:11 | <hsivonen> | annevk: what URL should I navigate to when serving WPT locally to run https://github.com/web-platform-tests/wpt/pull/10329 ? |
| 10:14 | <hsivonen> | relatedly, I need to learn how to properly cherrypick an upstream WPT test into mozilla-central |
| 14:49 | <yoav> | annevk && || Domenic: I'm getting back to https://github.com/whatwg/fetch/pull/729 after getting agreement from privacy folks about a good path forward. Here's a proposed design https://docs.google.com/document/d/1eBMLVHO3p1hwltL9xJJ5LwViW1-yqOvS0w6SNioOUXc/edit# |
| 14:49 | <yoav> | can you take a look? |
| 15:19 | <Domenic> | yoav: I don't feel super qualified in this area, and annevk is out for a few weeks... :-/ |
| 15:20 | <yoav> | Domenic: hmm :/ I have Anne's guidance from a few weeks back to work on |
| 15:21 | <yoav> | but he wanted most of that stuff to move to HTML |
| 15:21 | <yoav> | I guess I can prep up a PR based on a few assumptions and we can see if they are realistic once he's back... |
| 23:22 | wfpkhc | wanders on in* |
| 23:22 | <wfpkhc> | hello |
| 23:22 | <wfpkhc> | Anyone around? |
| 23:23 | <wfpkhc> | i have a question about HTML 5 |
| 23:23 | <wfpkhc> | Warning: The type attribute is unnecessary for JavaScript resources. |
| 23:23 | <wfpkhc> | i am using the validator - |
| 23:23 | <wfpkhc> | and that is the message i get |
| 23:23 | <MikeSmith> | yeah |
| 23:23 | <wfpkhc> | why all of a sudden has this started happening in html5? |
| 23:24 | wfpkhc | waves hello to MikeSmith |
| 23:24 | <MikeSmith> | because we made a change to the HTML spec this year to make it a warning case |
| 23:24 | <MikeSmith> | and I added a warning to the HTML checker (validator) for it |
| 23:25 | <wfpkhc> | well that does not make sense - you have had it for 15+ years - why change it now? |
| 23:25 | <wfpkhc> | and how will you know if your not using another script type? |
| 23:26 | <MikeSmith> | don’t understand your question |
| 23:26 | <wfpkhc> | (no i have not seen it used often, but i have seen it used" |
| 23:26 | <MikeSmith> | if you’re using another script type, then use the type attribute with some value |
| 23:26 | <wfpkhc> | I will restate the question sir |
| 23:26 | <MikeSmith> | but if the script is javascript, then don’t use the type attribute |
| 23:27 | <wfpkhc> | So the move really favors JS over all other script types? |
| 23:27 | <MikeSmith> | lack of a the type attribute means “this is JavaScript” |
| 23:27 | <MikeSmith> | yeah I guess it does |
| 23:27 | <MikeSmith> | because that’s what the web does too |
| 23:27 | <wfpkhc> | The web does what the developers program it to do |
| 23:27 | <MikeSmith> | JavaScript is the only scripting language that browsers have native support for |
| 23:28 | <wfpkhc> | That is not true - (well it did not use to be) |
| 23:28 | <wfpkhc> | without being stoned to death - IE used to support VBscript in the client |
| 23:28 | <MikeSmith> | browsers |
| 23:28 | <MikeSmith> | plural |
| 23:28 | <MikeSmith> | not “browser” |
| 23:29 | <MikeSmith> | one browser having support for some propriety language doesn’t make it part of the web platform |
| 23:29 | <wfpkhc> | :) the arguement was "the web" - the web implies the whole - |
| 23:29 | <wfpkhc> | so it goes back to my arguement - why is JS the default :P |
| 23:30 | <wfpkhc> | yes you answered the qeustion |
| 23:30 | <wfpkhc> | as such - through forward thinking |
| 23:30 | <wfpkhc> | so is this a permanent item now? |
| 23:30 | <wfpkhc> | even though html5 is not completed? |
| 23:39 | <wfpkhc> | hello? |
| 23:40 | <wfpkhc> | (ive been ditched) :( |
| 23:41 | <wfpkhc> | hello? |
| 23:42 | <wfpkhc> | so is this now a permanent item or is there a chance it will be changed? |
| 23:44 | <wfpkhc> | well all the best MikeSmith |
| 23:44 | <wfpkhc> | thank you for your time and effort sir |
| 23:46 | <caitp> | "but feel free to also use typescript, elm, dart, coffeescript, C, rust, ..." |