| 00:24 | <Domenic> | How should we decide whether to use https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin vs getting the node navigable's top-level traversible's active document's origin? I'm nervous that the former is implementation-defined. It is only implementation-defined for shared and service workers, FWIW. But, your question is a good one. I think they should be equivalent for Windows and all the complexity comes from the other global types (worklets, dedicated/shared/service workers). |
| 00:25 | <Domenic> | https://github.com/whatwg/html/issues/8014 is related |
| 00:49 | <bkardell> | bkardell: feel free to PR stuff like that btw |
| 05:23 | <annevk> | Domenic: there is also complexity when there is no Window yet |
| 05:23 | <annevk> | Domenic: that's the main reason we have the former cc Jeffrey Yasskin |
| 06:25 | <sideshowbarker> | So about the spec links such as https://dom.spec.whatwg.org/#ref-for-dom-abortcontroller-abortcontroller① — to the for-developers parts of specs — that we’re currently referencing in MDN/BCD but that aren’t guaranteed to forever keep pointing to the parts we intend: I’ve been wondering if I should just go ahead and manually add stable IDs to the specs for all those |
| 06:25 | <sideshowbarker> | that is, so the one I cited above would instead be https://dom.spec.whatwg.org/#dom-abortcontroller-abortcontroller-dev |
| 06:26 | <sideshowbarker> | …and I mean, rather than patching Bikeshed to auto-add them, I’d just manually patch the specs with patches that add the new IDs |
| 06:30 | <sideshowbarker> | Would anybody (especially the spec editors) object to me doing that? The specs that would need patching include DOM, Encoding, Fetch, File System, Fullscreen, Streams, WebSockets, IndexedDB, and a few others |
| 06:33 | <sideshowbarker> | …and most of those specs would need less than 10 new IDs added — but a few others would need dozens of them. DOM would need the most — 188, and IndexedDB and Fetch and Streams would need a few dozen each |
| 06:33 | <annevk> | sideshowbarker: I'd slightly prefer we add the generated Bikeshed ID if that doesn't change the output |
| 06:34 | <annevk> | The more stable we can keep existing IDs the better as people might have copied them from MDN and such |
| 06:35 | <sideshowbarker> | but we could keep the existing generated IDs while adding new ones in addition to those, right? |
| 06:35 | <sideshowbarker> | so no existing IDs would break |
| 06:37 | <sideshowbarker> | I can’t remember now who objected to me adding all the -① etc. links to MDN to begin with — but whoever did, their objection was that we have no way of ensuring those generated IDs will always continue to point to the for-developers targets they currently point to |
| 06:38 | <sideshowbarker> | In fact, we don’t have any way of knowing which of those might already now have changed to point to different parts of the specs (due to some new reference to a term being added somewhere earlier in a spec) |
| 06:40 | <sideshowbarker> | I don’t personally feel super strongly about it either way — it’s just something that’s been open and unresolved for a while now. And the attempt I made at patching Bikeshed to auto-generate them wasn’t approved, and I’ve not managed to make time to try completely re-doing the Bikeshed patching approach in the way that was suggested as an alternative to my Bikeshed patch |
| 06:47 | <annevk> | sideshowbarker: what I mean is that if the ID is ref-for-dom-abortcontroller-abortcontroller① for some element today, we just add that directly; or will Bikeshed trip on that? |
| 07:12 | <sideshowbarker> | sideshowbarker: what I mean is that if the ID is |
| 07:47 | <annevk> | I wonder if other browsers are interested in revisiting defining element attribute order. I guess I need to figure out where we last discussed that. |
| 07:49 | <Domenic> | IDL interface attribute order? |
| 07:50 | <Domenic> | Oh, no, element content attributes also have an order, don't they |
| 07:55 | <annevk> | Yeah, I noticed some serialization tests depend on Chromium order |
| 07:55 | <annevk> | And rniwa was like, why don't we finally fix that (not in those words) |
| 12:20 | <Ms2ger> | I thought that was well specced and implemented? |
| 12:57 | <annevk> | Ms2ger: the spec does seem to assume insertion order; I also can't find issues, but this was discussed a long time ago |
| 12:57 | <annevk> | Ms2ger: perhaps we resolved on insertion order back then though |
| 12:57 | <Ms2ger> | That was what I thought, yeah, but it's definitely been a while |
| 12:58 | <annevk> | Ms2ger: looks like it's your commit |
| 12:58 | <Ms2ger> | 😅 |
| 12:59 | <annevk> | https://github.com/whatwg/dom/commit/061b9914c2dfdd2e22984470af7e7f39915db74f |
| 12:59 | <annevk> | Alright, so the next question is which of Chromium and WebKit is wrong, thanks Ms2ger |
| 12:59 | <Ms2ger> | I vaguely recall that gecko may have had some issue with "mapped" attributes, if that's what they were called |
| 16:04 | <Maxim Vaarwel> | Good evening to everyone and excuse me if I interrupted. I have got the question about task and its 'component' - script evaluation environment settings object set. What is this case when a task has a set with more than one environment settings object? It would be nice if somebody explain this thin moment in spec. |
| 16:25 | <hacknorris> | i know you dont do in javascript but a general question - someone knows how to style both visited and unvisited links/anchors thru javascript? im stuck with making themes on my blog... and best i did for now was making first link colored. also i dont want for loops cause all code for themes i throw in onclick event of theme buttons, so for me it'd be a mess doing for's in one line... |
| 17:31 | <hacknorris> | noone ? |
| 18:36 | <Dominic Farolino> | are infra strings directly usable as ES strings? That is, in a spec, can I invoke an ES function directly with an infra string? |
| 18:36 | <Dominic Farolino> | I don't think I have to go through the WebIDL conversion functions since infra strings aren't WebIDL string types, IIUC |
| 18:42 | <Andreu Botella> | are infra strings directly usable as ES strings? That is, in a spec, can I invoke an ES function directly with an infra string? |
| 18:44 | <Jeffrey Yasskin> | Strictly, that's probably incorrect, since the ES-side string is an object with a bunch of properties. Because we know the details of %JSON.parse%, we know it doesn't look at anything besides the things Infra specifies, but we couldn't do that to an ES function in general. |
| 18:47 | <Jeffrey Yasskin> | I'd argue that a WebIDL string is an Infra string, but WebIDL doesn't actually say that since it was written before Infra. |
| 18:47 | <Jeffrey Yasskin> | (We should fix that. :) |
| 18:47 | <Andreu Botella> | The ES-side string isn't an object |
| 18:48 | <Andreu Botella> | I expect ToObject(anInfraString) to do the right things in terms of creating an object with String.prototype as its prototype |
| 18:54 | <Jeffrey Yasskin> | https://tc39.es/ecma262/#sec-tostring doesn't actually create an object here, but I think you're right that https://tc39.es/ecma262/#sec-ecmascript-language-types-string-type defines String in the same way as https://infra.spec.whatwg.org/#string except for the maximum length. |
| 18:54 | <Andreu Botella> | I meant to type ToObject 🤦 |
| 18:59 | <Dominic Farolino> | Thanks! |
| 20:25 | <TabAtkins> | So about the spec links such as https://dom.spec.whatwg.org/#ref-for-dom-abortcontroller-abortcontroller① — to the for-developers parts of specs — that we’re currently referencing in MDN/BCD but that aren’t guaranteed to forever keep pointing to the parts we intend: I’ve been wondering if I should just go ahead and manually add stable IDs to the specs for all those |
| 21:38 | <sideshowbarker> | I've been poking at fixing that issue, by the way. It's still a pretty complex issue, unfortunately. Switching to manually-specified IDs would be a good idea in any case, imo. |
| 21:39 | <TabAtkins> | Indeed. And in algos I definitely can't auto-gen IDs to steps, because steps change their position all the time. |
| 21:39 | <sideshowbarker> | Right |
| 21:39 | <TabAtkins> | Dev sections are at least a little bit easier, maybe. |
| 21:40 | <Jeffrey Yasskin> | Linking to specific steps is https://github.com/speced/bikeshed/issues/1405. |
| 21:40 | <sideshowbarker> | Dev sections are at least a little bit easier, maybe. |
| 21:41 | <TabAtkins> | That issue is about formatting a link to an (already ID'd) specific step, so it says "Step 4" or whatever. Making steps linkable is already handled, albeit requiring manual IDs. |
| 21:41 | <sideshowbarker> | Linking to specific steps is https://github.com/speced/bikeshed/issues/1405. |
| 21:42 | <sideshowbarker> | That issue is about formatting a link to an (already ID'd) specific step, so it says "Step 4" or whatever. Making steps linkable is already handled, albeit requiring manual IDs. |
| 21:44 | <TabAtkins> | (An <li> with an ID already generates a floating anchor next to it, so you can easily grab the link. Same with dt/dd too, iirc?) |
| 21:45 | <Jeffrey Yasskin> | That issue is about formatting a link to an (already ID'd) specific step, so it says "Step 4" or whatever. Making steps linkable is already handled, albeit requiring manual IDs. |
| 21:46 | <TabAtkins> | Ohhh you're right, sorry. |
| 23:58 | <Jeffrey Yasskin> | https://github.com/whatwg/html/issues/8014 is related |