| 07:59 | <annevk> | Domenic: would Construct(%Array% instrinsic object of targetRealm, <<inputLength>>) be roughly the right way to create an Array? |
| 07:59 | <annevk> | Domenic: the current setup looks a bit wonky |
| 08:00 | <annevk> | I guess I also need to carefully document how the length property is read on the input array |
| 08:00 | <annevk> | If I want to make this more precise than it was originally |
| 08:01 | <annevk> | Maybe later today |
| 08:08 | <Domenic> | annevk: I think that would work, although it feels a bit cleaner to go directly for ArrayCreate(0, %ArrayPrototype% intrinsic object of targetRealm). But, if you're going to be precise about Array, then you probably also want to be precise about Boolean/Number/Map/Set/etc... |
| 08:09 | <Domenic> | annevk: especially since a lot of other places in the ES spec use ArrayCreate |
| 08:10 | <annevk> | ArrayCreate is problematic since it assumes the current Realm in some places |
| 08:10 | <Domenic> | annevk: I guess it is probably another internal factoring thing, where Allen pulled out ArrayCreate but had no need to pull out BooleanCreate |
| 08:10 | <Domenic> | Only if you don't pass a second argument |
| 08:10 | <annevk> | "Let A be a newly created Array exotic object." |
| 08:11 | <Domenic> | That is invariant across realms |
| 08:11 | <Domenic> | Construct delegates to ArrayCreate anyway |
| 08:11 | <annevk> | Interesting, okay, maybe I can use ArrayCreate |
| 08:11 | <Domenic> | Construct just also lets you muck with NewTarget and pass non-numbers for `len` |
| 08:12 | <annevk> | I guess it makes sense that only the prototype really varies per Realm |
| 08:12 | <annevk> | Anyway, later today or tomorrow |
| 08:12 | <Domenic> | Yeah |
| 08:13 | <Domenic> | (Hmm Construct also does a Set on the length; that's strange...) |
| 08:27 | <annevk> | Domenic: I want to be precise because of length, mostly, btw |
| 08:28 | <annevk> | Domenic: the others have simple internal slots |
| 08:29 | <annevk> | Getting length from input and setting it on output leaves things undefined atm |
| 08:32 | <JakeA> | TabAtkins: could object-fit be made to work on any element's contents? I imagine it's been discussed before |
| 09:23 | <annevk> | JakeA: non-object contents seems quite a bit harder (especially as there are no intrinsic sizes, so some stuff would not work I suspect) |
| 09:24 | <JakeA> | annevk: we know the box of the parent & the boxes of the children |
| 10:12 | <annevk> | TabAtkins: I updated bikeshed to see if the reference issue was fixed for DOM as you said and now I get "FATAL ERROR: No 'dfn' refs found for '"insanity-wolf" alt'." |
| 10:13 | <annevk> | TabAtkins: I thought you ran regression tests against DOM now? |
| 10:14 | <annevk> | The reliability of bikeshed leaves a lot to be desired, perhaps everything should just use Wattsi or some such instead |
| 13:47 | <nox> | FATAL ERROR: No 'dfn' refs found for '"insanity-wolf" alt'. |
| 13:51 | <nox> | annevk, TabAtkins: ^ |
| 13:58 | <annevk> | nox: yeah, see little earlier today |
| 13:58 | <nox> | Ok. |
| 13:59 | <nox> | annevk: "If the [LegacyUnenumerableNamedProperties] extended attribute is specified on an interface, then it applies to all its derived interfaces and must not be specified on any of them."? |
| 13:59 | <annevk> | nox: seems reasonable |
| 13:59 | <nox> | annevk: As for my bikeshed error, this is because I'm trying to add a new step after 2.7 in https://dom.spec.whatwg.org/#concept-event-listener-inner-invoke. |
| 14:00 | <annevk> | nox: I'm no IDL expert |
| 14:00 | <nox> | annevk: Seems like we don't abort the steps if event's stop immediate propagation flag is set at that point. |
| 14:00 | <nox> | I think that's the intent of invoke's step 1, but it is misplaced. What do you think? |
| 14:01 | <annevk> | I think you're correct, my fault |
| 14:01 | <nox> | annevk: No problem. :) |
| 14:01 | <nox> | annevk: I have various improvements I want to make to dispatch/invoke/inner invoke. Would that be a good thing? |
| 14:01 | <nox> | More short-circuits, no more target in eventPath, etc. |
| 14:03 | <annevk> | Target needs to be in path for API |
| 14:03 | <annevk> | event.getDeepPath or some such |
| 14:04 | <nox> | annevk: Mmmh. |
| 14:04 | <annevk> | Invoke step 1 should become inner invoke 2.1 or so I think |
| 14:04 | <nox> | annevk: I mean the local variable eventPath in dispatch. |
| 14:04 | <annevk> | That used to be the setup until I messed it up recently |
| 14:05 | <nox> | We put target in eventPath, but then never do anything with it. |
| 14:05 | <annevk> | nox: yeah, that'll be exposed at some point |
| 14:05 | <nox> | Oh ok. :) |
| 14:05 | <nox> | annevk: Any idea for the wolf? |
| 14:06 | <nox> | annevk: I don't think it can be step 2.1 with the "found" mess. |
| 14:06 | <annevk> | No idea |
| 14:06 | <nox> | annevk: Invoke is never called if stop propagation is set, |
| 14:06 | <annevk> | nox: sure it can, just return false |
| 14:07 | <nox> | so step 1 in invoke is useless. |
| 14:07 | <nox> | annevk: But it should return true. |
| 14:07 | <annevk> | Ah okay, then do that |
| 14:08 | <nox> | annevk: Should I put a note in place of invoke's step 1? |
| 14:08 | <nox> | Like "this is never called when event's stop propagation is set" or something. |
| 14:09 | <annevk> | Nah |
| 14:09 | <nox> | annevk: Do I remove that step? |
| 14:10 | <annevk> | Yeah |
| 14:10 | <annevk> | Should be 2.1 |
| 14:11 | <annevk> | Of inner* |
| 14:13 | <nox> | Why 2.1? |
| 14:14 | <nox> | annevk: You can't reach 2.1 if stop propagation is set, and we know it is, so I planned to put it as 2.8. |
| 14:14 | <nox> | we know it isn't* |
| 14:15 | <annevk> | Ah right |
| 14:15 | <nox> | If you really want it to be before the actual call, it should be 2.3, but I don't really see the point. |
| 14:15 | <annevk> | Agreed |
| 14:16 | <annevk> | nox: can you create your own branches yet? |
| 14:17 | <nox> | annevk: On upstream's repos you mean |
| 14:17 | <nox> | ? |
| 14:18 | <annevk> | nox: yeah, whatwg/dom |
| 14:18 | <nox> | Yes. Do you prefer me to push stuff there? |
| 14:19 | <annevk> | nox: makes it easier to get purple PRs |
| 14:19 | <nox> | Oh? |
| 14:19 | <nox> | annevk: Should I recreate the PR? |
| 14:19 | <annevk> | nox: oh no, it's fine for now |
| 14:19 | <nox> | Ok. :) |
| 14:20 | <annevk> | nox: let me look into this tomorrow and explain then |
| 14:20 | <nox> | Explain? |
| 14:24 | <nox> | annevk: Even if it is exposed one day, we could still set eventPath to everything but its first element, and then remove the redundant "and object is not target" that is repeated twice. |
| 18:45 | <Domenic> | https://twitter.com/JustRogDigiTec/status/704013991522111488 is sad |
| 19:05 | <roc> | we should have web-platform-tests that test that non-standard features aren't implemented |
| 19:10 | <nox> | annevk: Is it known that wpt and the spec disagree with regard to Range.insertNode? |
| 19:12 | <nox> | https://github.com/w3c/web-platform-tests/pull/2065 |
| 19:14 | <nox> | Never mind I think my code is just incorrect. |
| 19:58 | <Domenic> | I think there are some such tests for Attr |