| 00:02 | <Domenic> | shu: you are in for a treat. https://github.com/whatwg/wattsi/blob/46f60c90509a7d0dd898eda234095629012c69bb/src/wattsi.pas#L310 |
| 00:03 | <shu> | can't tell if this is cursed "Wattsi is written in Free Pascal" |
| 00:04 | <shu> | anyway thanks! should be fun reading |
| 00:16 | <leobalter> | the free pascal got me concerned too early as I'm now glad that html-build just do the tricks without me worrying about it if I use docker. Even though, my concern is only out of ignorance on something not popular that exists since forever. |
| 00:35 | <Domenic> | Nobody is exactly ecstatic about the Free Pascal situation :). However the performance requirements of the HTML spec mean that our choices are basically in the C++/Rust/Swift family. (Maybe Go too; probably a GC is not that bad.) Apparently FreePascal is in that family and is Hixie's favorite language, so here we are. |
| 00:35 | <Domenic> | I am not sure if rewriting in Rust would actually improve comprehensibility enough to be worth anything. |
| 00:55 | <MikeSmith> | shu: the data that associates anchors in the HTML spec with particular MDN articles is at https://github.com/w3c/mdn-spec-links/blob/master/html.json |
| 00:56 | <MikeSmith> | the top-level keys are the spec anchors/IDs |
| 00:56 | <MikeSmith> | Bikeshed and Respec spec all use data from that same repo |
| 00:57 | <MikeSmith> | and one day we will also have MDN links in the ES spec, because we already have all the data needed |
| 00:57 | <MikeSmith> | https://github.com/w3c/mdn-spec-links/blob/master/ecmascript.json |
| 00:58 | <MikeSmith> | and for the ECMA-402 spec, and even for 10+ TC39 proposals |
| 00:58 | <MikeSmith> | for the JavaScript features the spec URLs are in the data in the https://github.com/mdn/browser-compat-data/tree/master/javascript tree |
| 01:00 | <MikeSmith> | but for all non-JavaScript features/specs (e.g., the HTML spec) the spec-URL data is regularly (re)generated by a script I run that scrapes all the MDN articles and extracts the spec URL from the Specifications sections/tables of the MDN articles |
| 01:06 | <shu> | MikeSmith: i'm calling it for the day, but speaking as an ecma262 editor, MDN linking would definitely be great for ecma262 |
| 01:06 | <shu> | let's chat more about that later |
| 01:06 | <MikeSmith> | yup |
| 01:16 | <leobalter> | Domenic: I'm definitely not advocating changes for something that just works. The little I know about wattsi, I don't see any fair reason to rewrite it. Using html-build I get what I want, it's sufficient for me so far. |
| 01:17 | <leobalter> | MikeSmith: I'm glad to know you have what you need for ECMA-402, but please let me know if there is anything else I can help |
| 01:23 | <MikeSmith> | Hi leobalter |
| 01:24 | <leobalter> | hi! |
| 01:24 | <MikeSmith> | great to see you hear and it’s also been great to see you getting involved with the web-components work |
| 01:25 | <MikeSmith> | about what we need for MDN annos and ECMA-402, it’s the same as for the ES spec itself and I think for the proposals too |
| 01:25 | <MikeSmith> | by which I mean, I think they are all published using the same build tool |
| 01:26 | <MikeSmith> | so it’s a matter of adding support to that common build tool |
| 01:26 | <MikeSmith> | and for that I think maybe some of the same code from Respec could maybe be reused |
| 01:27 | <MikeSmith> | the current Respec main maintainer is really savvy about JavaScript coding for this kind of thing |
| 01:27 | <MikeSmith> | I think he even actually has some of the source in TypeScript |
| 02:02 | <leobalter> | I'll sync this with the ECMA-262 as the build process is basically the same. For now, let me also ping Bakkot ^^ |
| 02:49 | <EveryOS> | The WhatWG HTML docs are so long, the inlined table of contents does not fit on my monitor :/ https://usercontent.irccloud-cdn.com/file/VI4Lhpkv/image.png |
| 04:44 | <annevk> | Well, it took several months, but one IANA registration is updated now: https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded |
| 04:45 | <annevk> | Not sure we’ll be done by 2022 at this rate |
| 05:13 | <MikeSmith> | annevk: are the other pending ones from the URL spec? |
| 05:16 | <MikeSmith> | I am looking for recent issue where Julian Reschke commented |
| 05:17 | <MikeSmith> | I don’t understand why github doesn’t provide an easy way to browse all comments somebody has made |
| 05:18 | <MikeSmith> | having that would make it much easier to find issue discussions when you can’t remember what issue tracker they happened to be in |
| 05:22 | <MikeSmith> | finally found it |
| 05:22 | <MikeSmith> | https://github.com/whatwg/fetch/issues/1052 |
| 05:22 | <MikeSmith> | Fetch |
| 05:23 | <MikeSmith> | (resorted to using Google search rather than trying to find it with Github’s own internal search/browsing) |
| 05:25 | <MikeSmith> | annevk: I think plh would have told me if, like the application/x-www-form-urlencoded had been, that registration were being held up due to IANA asking W3C about i |
| 05:25 | <MikeSmith> | *it |
| 05:26 | <MikeSmith> | but I’ll doublecheck with him |
| 05:28 | <MikeSmith> | but as far as any W3C relationship to it, it seems like if falls pretty much into the same criteria as the application/x-www-form-urlencoded case |
| 05:30 | <MikeSmith> | and in the W3C response in that case was basically to say, the relevant spec is completely a WHATWG spec and not in the WHATWG-W3C MoU, and so the WHATWG should have sole ownership of the registration |
| 05:41 | <MikeSmith> | annevk: pinged mnot about it the Access-Control registrations |
| 05:46 | <annevk> | MikeSmith: oh sorry, I haven't really initiated anything yet beyond the one that now succeeded |
| 05:46 | <annevk> | MikeSmith: it does seem that everything we have needs updating, including the stuff in HTML |
| 07:22 | annevk | notices the Reference column in https://www.iana.org/assignments/media-types/media-types.xhtml wasn't updated |
| 07:23 | <annevk> | Again, if they did this through Pull Requests that'd be easy to spot |
| 09:55 | <annevk> | MikeSmith: https://github.com/whatwg/html/pull/5545#discussion_r453546765 (opt into vs opt in to) |
| 09:59 | <annevk> | There are a quite a few hits for "opt into" on lists.whatwg.org |
| 12:11 | <MikeSmith> | annevk: I think it’s a judgement call but it should be styled consistently one way or the other |
| 12:12 | <annevk> | Yeah, if Domenic wants opt in to that'd be easy enough to align on |
| 12:12 | <annevk> | It reads a lil funny to me, but meh |
| 12:12 | <MikeSmith> | yeah I think Domenic’s rationale there for going with “opt in to...” is right |
| 12:14 | <MikeSmith> | well I like dashes so much that I might go so far as to always just do “opt-in to” |
| 12:51 | <Ms2ger> | Thought you'd go for "opt in-to" |
| 12:54 | <jgraham> | opt-in-to |
| 14:48 | <annevk> | opt out |
| 14:52 | <hober> | o-p-t- -i-n- -t-o |
| 17:09 | <annevk> | Domenic: what I don't want is specs adding event listeners for mouse events or some such or multiple specs adding event listeners to the same target |
| 17:09 | <annevk> | Domenic: event listeners just doesn't seem like the right kind of system for specs |
| 17:09 | <Domenic> | annevk: you'd rather they duplicate the event machinery? |
| 17:09 | <annevk> | Domenic: how would you even enforce ordering? |
| 17:10 | <Domenic> | annevk: the same way as for web-developer-added ones... first-added, first-fired. |
| 17:10 | <annevk> | Domenic: I'd rather they plug into the fundamental machinery, e.g., for mouse events, it seems wrong if a developer can trigger those algorithms with synthetic events |
| 17:10 | <annevk> | Domenic: how does that work across specifications? |
| 17:10 | <Domenic> | annevk: sure, if they don't want to react to developer-triggered events, then they definitely wouldn't use addEventListener |
| 17:11 | <Domenic> | But for cases like AbortSignal... |
| 17:11 | <annevk> | Domenic: again, https://dom.spec.whatwg.org/#action-versus-occurance is pretty important here |
| 17:11 | <Domenic> | annevk: whichever spec's step runs first... |
| 17:11 | <Domenic> | annevk: yes, I think specs can react to occurrences too |
| 17:11 | <Domenic> | annevk: such as, for example, something getting aborted |
| 17:11 | <annevk> | Domenic: AbortSignal doesn't run the user agent algorithm if you just dispatch an event |
| 17:12 | <annevk> | that's quite intentional |
| 17:12 | <Domenic> | annevk: that seems like a big bug |
| 17:12 | <annevk> | o_O |
| 17:12 | <annevk> | again, https://dom.spec.whatwg.org/#action-versus-occurance |
| 17:12 | <Domenic> | It seems like a big problem that .dispatchEvent("abort") and .abort() behave differently depending on who wrote the code |
| 17:12 | <Domenic> | annevk: again, treat specs like web developer code |
| 17:12 | <annevk> | abort() dispatches the event |
| 17:12 | <Domenic> | annevk: aborting is an occurence |
| 17:12 | <annevk> | it doesn't cause it to be dispatched |
| 17:12 | <annevk> | scratch that last sentence |
| 17:13 | <Domenic> | .dispatchEvent("abort") signals the occurrence of something being aborted |
| 17:13 | <Domenic> | It's bizarre to me that you'd want that to trigger user-defined "occurrence listeners" but not spec-defined ones. |
| 17:13 | <annevk> | it's a signal that such an action is happening, but it shouldn't cause the action |
| 17:13 | <Domenic> | Indeed, it doesn't cause any actions |
| 17:13 | <Domenic> | It just triggers event listeners |
| 17:13 | <Domenic> | Which are watching for the occurrence of aborting |
| 17:14 | <annevk> | yeah no, I guess we disagree on this |
| 17:14 | <Domenic> | It doesn't itself abort; it signals that a request for aborting is happening, which various watchers of that occurence listen for |
| 17:14 | <Domenic> | Some in specs, some in user code |
| 17:14 | <Domenic> | The fact that those diverge depending on how you signal the abort request is really bad |
| 17:15 | <annevk> | that's a pretty fundamental property of how events work everywhere |
| 17:15 | <Domenic> | I totally agree |
| 17:15 | <annevk> | a click on a link follows the link |
| 17:15 | <Domenic> | Oh, I misunderstood what you were calling a fundamental property |
| 17:15 | <annevk> | but the event doesn't necessarily cause that |
| 17:15 | <Domenic> | Clicking on a link triggers a mouse event which triggers mouse event listeners |
| 17:16 | <Domenic> | And clicking on a link also causes other things |
| 17:16 | <Domenic> | But an abort request occurring, or a message event occurring, is a signal that others are listening for to perform some actions, like cleanup, or message processing |
| 17:16 | <Domenic> | And those "others" should not be treated differently if they are UA code vs. web-dev code. |
| 17:16 | <Domenic> | They're both watching for an occurrence (abort request, or message) |
| 17:17 | <Domenic> | The action (abort request, message sending) has already happened |
| 17:17 | <annevk> | if it's a synthetic event the action might not have happened and maybe shouldn't happen though |
| 17:18 | <Domenic> | Sure, you can fake occurrences without a corresponding action |
| 17:18 | <Domenic> | But that doesn't mean that we shouldn't react to the fake occurence |
| 17:18 | <annevk> | the way the abort() action is tied to rejecting fetch()'s promise is through signal reactions (forgot what it's called) |
| 17:18 | <Domenic> | Otherwise you're blurring the action/occurrence distinction |
| 17:18 | <Domenic> | And saying some occurrences are more real than others |
| 17:19 | <Domenic> | responding to a message occurrence shouldn't depend on how that occurrence happened |
| 17:19 | <annevk> | well yes, abort() is a thing, and dispatchEvent() is not a thing |
| 17:19 | <Domenic> | I don't understand how dispatchEvent() is not a thing |
| 17:19 | <annevk> | that's what the action vs occurrence section is about |
| 17:19 | <Domenic> | Stated another way: how does author code get access to figure out if an abort request is "real"? |
| 17:20 | <Domenic> | Since you've decided that only some abort occurrences represent actions now |
| 17:20 | <Domenic> | And occurrence-handlers should apparently only react to "real" occurrences |
| 17:23 | <annevk> | I'm not sure where the mismatch comes from, but there's a reason dispatchEvent() returns a boolean, to allow the action to take different paths. If the event itself triggers the action you get a very different system |
| 17:24 | <Domenic> | The event doesn't trigger the action. There is no action when you just dispatch an event |
| 17:24 | <Domenic> | The issue is why should occurrence-handlers care about the action? |
| 17:25 | <Domenic> | An abort has occurred. That's what dispatchEvent("abort") signals |
| 17:25 | <Domenic> | s/abort/abort request/ |
| 17:25 | <Domenic> | When an abort is requested, i.e. when an abort request occurs, we run some cleanup steps |
| 17:26 | <Domenic> | Again, let's say I am writing a promise-returning setTimeout that takes an AbortSignal. I listen for abort request occurrences using addEventListener("abort", ...). But you're telling me now that doing that violates action-vs.-occurrence because those are not real occurrences. |
| 17:26 | <Domenic> | How am I supposed to code that function? |
| 17:27 | <Domenic> | I think this notion that some occurrences are not real and should be ignored is violating action-occurrence separation |
| 17:37 | <annevk> | Something else, IANA lists us as https://www.whatwg.org/ now on https://www.iana.org/assignments/media-types; I tried; they started with http://www.whatwg.org/ |
| 17:40 | <Domenic> | Interesting; do they have some www policy? |
| 17:41 | <annevk> | They did not say. I mentioned avoiding redirects and secure connections when I suggested the actual URL and they just got back to me with a different one |
| 17:41 | <annevk> | And since that thread was already a dozen emails in for a single MIME type I kinda want to leave it at that 🙂 |
| 17:43 | <annevk> | 17 emails, 3 from me |
| 18:00 | <Domenic> | link? |
| 18:01 | <annevk> | It's all private... |
| 18:01 | <annevk> | I can forward later |
| 18:01 | <Domenic> | Eh just idly curious |
| 18:04 | <annevk> | Reportedly there'll be a better process for headers soonish so I suggest we wait with registering those |
| 18:52 | <EveryOS> | When I joined IRC, I had felt like I recognized your names from somewhere, and now I figured it out. Ya'll maintain https://wpt.live/tools/runner/index.html/ |
| 18:56 | <Domenic> | Well, a lot of us contribute to https://github.com/web-platform-tests/wpt, although I don't know about that page in particular. |
| 18:58 | <EveryOS> | Ah, ok. Anyways, that page will (eventually) be some use for me. |
| 19:05 | <annevk> | Domenic: you wrote Otherwise, rather than Otherwise: |
| 19:05 | <Domenic> | Hmm, staring at too many other specs today I guess |
| 19:06 | <annevk> | I should also stop, but I do think it's good now modulo that |
| 19:06 | <Domenic> | Awesome |
| 19:06 | <Domenic> | I'm not sure I want to merge until I get the tests updated for the getter rename |
| 19:06 | <Domenic> | Which might be a bit annoying since then Chromium will lose a bunch of test coverage until we rename |
| 19:06 | <Domenic> | So no rush |
| 19:07 | <annevk> | Okay, let me know when you're satisfied and I'll read it one more time to be sure at that point |
| 19:08 | <Domenic> | Sounds good, thanks for all the review so far |
| 21:57 | <EveryOS> | People are weird. I created an almost empty GH repo earlier, and 2 people cloned it |
| 22:07 | <EveryOS> | Ug, I can't delete IRC messages |
