| 09:13 | <annevk> | Hmm, someone is trying to convince me to give XMLHttpRequest feature parity with fetch(); or at least that one feature nobody ever adopted but they need |
| 09:24 | <jgraham> | gsnedders: I mean, I don't disagree that some stuff is hard to test. But writing manual tests that are run once at transition time, and requiring a bunch of special infrastructure to support that exact use case, seems like the worst of all worlds in that it's high effort but has little interop impact |
| 09:28 | <jgraham> | (which is, for the record, not an example of good engineering discipline) |
| 11:26 | <annevk> | JakeA: https://github.com/whatwg/infra/pull/172 |
| 11:31 | <zcorpan> | https://github.com/w3c/web-platform-tests/issues/314 looks like an interesting issue |
| 11:54 | <annevk> | JakeA: https://github.com/whatwg/fetch/issues/703 |
| 13:05 | <wanderview> | annevk: do you know where prefetch is defined? |
| 13:06 | <annevk> | wanderview: "defined" https://w3c.github.io/resource-hints/#speculative-resource-prefetching-prefetch |
| 13:06 | <annevk> | wanderview: there's one or more issues against Fetch about improving its definition |
| 13:06 | <wanderview> | annevk: does this define how a prefetch is loaded? trying to determine if it should go through a service worker |
| 13:07 | <annevk> | wanderview: dunno |
| 13:08 | <wanderview> | annevk: I'll file an issue I guess |
| 13:08 | <annevk> | I really hope they fix it holistically instead of the whack-a-mole game folks are playing now |
| 13:12 | <wanderview> | annevk: https://github.com/w3c/ServiceWorker/issues/1302 |
| 14:06 | <jruiz> | Hello |
| 14:10 | <jruiz> | Can I ask a question to the experts that are in this channel? |
| 14:15 | <railgun> | no need to ask if you can ask questions, just ask! |
| 14:15 | <railgun> | if someone knows the answer, they'll respond :) |
| 14:16 | <jruiz> | railgun Ok, thanks ;) |
| 14:17 | <jruiz> | It's probably a very stupid question, but I'm curious about the opinion of web technology leaders. |
| 14:19 | <jruiz> | Let's imagine that I want to be as expert as possible in frontend. The logic indicates that the way would be to learn HTML, CSS and JavaScript. |
| 14:21 | <jruiz> | But would it be more logical to start perhaps by reading the DOM technology? |
| 14:23 | <railgun> | jruiz: it depends on what you want to do |
| 14:23 | <jruiz> | I ask this because in the documentation the first two chapters is not directly what we call HTML elements. |
| 14:23 | <railgun> | there are a lot of topics in front-end alone, I don't think anyone knows everything |
| 14:23 | <jruiz> | I would like to start from the base. Although it is difficult and dense. |
| 14:24 | <railgun> | I'd say learn the basics first, then learn about the specifics as you need them |
| 14:25 | <railgun> | MDN is a great resource https://developer.mozilla.org/en-US/docs/Learn |
| 14:25 | <jruiz> | I understand that when using HTML elements, I learn the principles of the DOM. But sometimes I start inspecting elements from the web developer tool, and I do not understand what I see. |
| 14:28 | <railgun> | try reading through https://developer.mozilla.org/en-US/docs/Tools and/or https://developers.google.com/web/tools/chrome-devtools/ |
| 14:29 | <railgun> | it will teach you about all the different parts of developer tools, but you should already know some HTML/CSS |
| 14:30 | <jruiz> | Yes, I have knowledge of HTML and CSS. That's why I was wondering if it would not be a good idea, read about DOM now, or directly go to JavaScript. |
| 14:31 | <jruiz> | I'm going to read those last two links that you indicate to me. Tha |
| 14:31 | <jruiz> | Thanks |
| 14:31 | <jruiz> | ;) |
| 14:33 | <railgun> | I am not an expert in DOM, but I know enough to use developer tools |
| 14:33 | <railgun> | if you read https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction it covers DOM + some JavaScript |
| 14:34 | <railgun> | I don't think you need to read the spec in this case |
| 14:41 | <railgun> | Good luck! |
| 14:49 | <Domenic> | I think you'll need some basic JavaScript knowledge to make sense of the DOM stuff. Since the DOM is a large set of JS objects that represent the HTML you see, knowing what a JS object is and how it works is good background info. |
| 14:56 | <gsnedders> | jgraham: I agree |
| 14:56 | <gsnedders> | jgraham: what I wonder about really is how to replace a lot of the old visual tests |
| 14:56 | <gsnedders> | jgraham: because not all of them can be reasonably turned into reftests |
| 14:58 | <annevk> | jruiz: learn some basic JavaScript as Domenic suggests; then you'll be able to make sense of APIs more easily |
| 14:58 | <annevk> | The other thing I did, but might not be generally applicable, is learn how IDL roughly maps to JavaScript, so it's easier to read the various standards |
| 15:52 | <jyasskin> | wanderview: I've left my current understanding on your issue. Kinuko may correct my summary. |
| 15:52 | <wanderview> | jyasskin: thanks |
| 15:52 | <jyasskin> | wanderview: I suspect the current behavior isn't actually the behavior we ought to define. |
| 15:53 | <wanderview> | jyasskin: yea, I doubt a FetchEvent makes sense for something like prefetch... but I dunno... maybe yoav has opinions |
| 15:55 | <jyasskin> | wanderview: It *could* make sense, if it were on the right Service Worker, but right now it's not on the right SW. And it's probably easier to just skip SW than identify the right one. |
| 15:55 | <wanderview> | jyasskin: oh.... uh... let me re-read what you wrote! |
| 15:55 | <jyasskin> | This is https://github.com/w3c/resource-hints/issues/78 |
| 15:57 | <wanderview> | jyasskin: I'm not sure about triggering other origin service workers from a <link> element... that sounds a lot like a tracking vector similar to foreign fetch to me |
| 16:28 | <Domenic> | annevk: to be clear, I am in general in favor of moving from flags to booleans, but I think we should probably figure out a more holistic strategy, and not upgrade piecemeal. Things I am concerned about include the possibility of tri-state, and how "call x with y and true" is less clear than "call x with y and the z flag set" |
| 16:29 | <Domenic> | For the latter, in general I think some kind of named arguments convention would be good to spell out. |
| 16:29 | <annevk> | Maybe, I'm not sure I wanna force named arguments everywhere |
| 16:30 | <Domenic> | Yeah, definitely optional |
| 16:30 | <annevk> | Though having unordered arguments would be good to have at times, to make things extensible without having to refactor all the things |
| 16:30 | <annevk> | I.e., dictionaries for specs |
| 17:23 | <JakeA> | I like how Python does this, where arguments have an order but they're also named |
| 17:23 | <JakeA> | Seems like a good convention to copy |
| 17:30 | <domfarolino> | I also like this ^ |
| 17:31 | <domfarolino> | annevk: Thanks for recent pings on issues etc, might be a few days before I'm as active as I'd like with finals approaching etc |
| 17:52 | <annevk> | I don’t really see how ordered helps with extensions and not having to refactor all callers |
| 17:54 | <JakeA> | it doesn't. Sorry, was just a general reply to unordered arguments / named arguments |
| 18:53 | <Domenic> | I think the idea is that you can call either using ordered/unnamed or unordered/named, at the caller's choice. |
| 18:54 | <Domenic> | See example 4.4 at http://www.diveintopython.net/power_of_introspection/optional_arguments.html |