| 09:58 | <MikeSmith> | annevk: so the person who filed the issues about the integrity attribute with inline script elements seems to have deleted their GitHub account |
| 10:00 | <MikeSmith> | but looking again at https://after-dark.habd.as/ I think the claim that integrity works for inline scripts may not be wrong after all |
| 10:02 | <MikeSmith> | I couldn’t reproduce it when I tested, yet if I look at the source of that document, I don’t see how the inline scripts there could actually be working unless the browser is allowing it based on checking the hashes |
| 10:03 | <MikeSmith> | the policy does specify 'unsafe-inline' but that should be getting ignored since the policy also specifies a hash |
| 10:36 | <annevk> | MikeSmith: it also specifies hashes in the CSP though |
| 10:37 | <annevk> | MikeSmith: so it's not clear to me if it's that or the integrity attribute |
| 13:45 | <Ms2ger> | annevk, what kind of changes in DOM do you expect in https://github.com/heycam/webidl/issues/540#issuecomment-467841401 , besides updating the constructor to look more like https://heycam.github.io/webidl/#dom-domexception-domexception ? |
| 13:50 | <annevk> | Ms2ger: I think there's some stuff I'm missing; where does [[Realm]] come from? |
| 13:50 | <annevk> | Ms2ger: and how is that determined for a subclass? |
| 13:51 | <Ms2ger> | annevk, 1.8 in https://heycam.github.io/webidl/#create-an-interface-object |
| 13:51 | <annevk> | Ms2ger: is there a bug against Chrome for the difference I mentioned? |
| 13:51 | <annevk> | Ms2ger: (or Firefox, if wrong) |
| 13:51 | <annevk> | Ms2ger: and can we use "this" now? 😃 |
| 13:51 | <Ms2ger> | I haven't filed a but yet, but there's a test in wpt |
| 13:53 | <Ms2ger> | I'm working on a PR to make "this" more explicitly available |
| 13:53 | <annevk> | Ms2ger: so create an interface object takes a realm, it doesn't see how it obtains it |
| 13:54 | <nox> | annevk: Would it be useful to make 2 patches against HTML: one describing Chrome, the other Firefox? I mean for the insertion steps changes. |
| 13:56 | <annevk> | nox: do Chrome and Firefox agree on <script>? |
| 13:57 | <Ms2ger> | From https://heycam.github.io/webidl/#define-the-global-property-references , which gets it from https://heycam.github.io/webidl/#new , which gets it from... https://html.spec.whatwg.org/multipage/browsers.html#creating-browsing-contexts:creating-a-new-javascript-realm I guess |
| 14:00 | <annevk> | Ms2ger: the idea was that "create a new object implementing the interface" is used by others, right? So they'd always have to supply a Realm? |
| 14:00 | <Ms2ger> | Yes |
| 14:01 | <annevk> | Ms2ger: so what's the recommendation for that? E.g., https://url.spec.whatwg.org/#dom-url-url creates URLSearchParams in which Realm? |
| 14:02 | annevk | was hoping there could be a default for IDL-algorithms |
| 14:02 | <Ms2ger> | annevk, this.[[Realm]] |
| 14:02 | <annevk> | and that's 1:1 with this's relevant realm? |
| 14:03 | <nox> | annevk: No they don’t. |
| 14:04 | <Ms2ger> | annevk, I need to double-check if "relevant realm" is defined properly yet, but that's the idea |
| 14:04 | <annevk> | Ms2ger: we might as well stop using relevant realm I guess |
| 14:04 | <annevk> | (iirc it's only defined for platform objects) |
| 14:04 | <Domenic> | Noooo |
| 14:04 | <annevk> | heh |
| 14:04 | <Domenic> | We've done so much work to educate people |
| 14:05 | <Domenic> | Also I think eventually it will be a useful abstraction around both ES and platform objects |
| 14:05 | <annevk> | if ES objects will also get [[Realm]] it seems like that's the abstraction |
| 14:06 | <annevk> | but I guess that's unclear as of yet |
| 14:06 | <Domenic> | As for a default, that was debated in https://github.com/heycam/webidl/issues/135 |
| 14:07 | <Domenic> | Note that now that we have something set up "this" before calling constructor steps, relevant realm of "this" does exist in the constructor. |
| 14:08 | <Domenic> | With the previous setup it didn't so we suggested current realm |
| 14:08 | <Domenic> | Although I guess there's still debate in https://github.com/heycam/webidl/issues/135#issuecomment-411109348 |
| 14:09 | <annevk> | hmm |
| 14:09 | <annevk> | I'd like to see https://heycam.github.io/webidl/#dom-domexception-domexception for something more complex, such as URL |
| 14:10 | <annevk> | nox: sorry, I'm beginning to lose track given the longish timespan |
| 14:10 | <Domenic> | I mean, the only complexity with URL is that it creates a new platform object, right? |
| 14:10 | <annevk> | nox: I suspect two PRs doesn't make it easier for other folks to know what's going on |
| 14:10 | <nox> | annevk: That's fine. That's why maybe I should just describe both for all the cases I described and then we can pick which one we want. |
| 14:11 | <Domenic> | So it's a question as to whether when creating the URLSearchParams you do "new URLSearchParams" and it picks a right default, or you do "new URLSearchParams in the current realm/relevant realm of this" |
| 14:11 | <annevk> | nox: if there's a way to describe both abstractly in a comment that might be easier |
| 14:11 | <nox> | annevk: Ok, then I'll make the changes for each thing I found with the behaviour I prefer, and I guess I can describe the other possible behaviours in a comment. |
| 14:11 | <annevk> | Domenic: or do you use this's [[Realm]] |
| 14:11 | <Domenic> | All three are equivalent |
| 14:11 | <annevk> | or this.[[Realm]]! |
| 14:11 | <nox> | annevk: That's kinda what I did in https://github.com/whatwg/html/pull/4354#issuecomment-463566900 |
| 14:11 | <Domenic> | Well, this's [[Realm]] is just an awkward way of writing this.[[Realm]], I guess. |
| 14:11 | <annevk> | Domenic: I'm not a big fan of not having canonical answers |
| 14:12 | <Domenic> | Use relevant realm then |
| 14:12 | <Domenic> | That's been our canonical answer up until now and I don't see a reason to churn all that |
| 14:12 | <Domenic> | Or, wait for a default. That's the real debate. |
| 14:12 | <Ms2ger> | annevk, I can probably write a pr for url today or tomorrow |
| 14:14 | <annevk> | Ms2ger: no need, I think I sorta got where things are at now based on this discussion |
| 14:14 | <Domenic> | Probably we should add a default. Even if relevant is "wrong" in methods, and we eventually decide to change it (very unlikely it seems given bz's preferences), for constructors there wouldn't be any switch. And, by having a default, spec-writers would be abstracted away from the mess. |
| 14:14 | <Ms2ger> | Ok, cc me? |
| 14:14 | <annevk> | Ms2ger: I'll wait and see a bit before cleaning things up |
| 14:15 | <annevk> | nox: so that only describes Firefox and not Chrome and doesn't go into tradeoffs |
| 14:15 | <nox> | annevk: Yeah, that's not clear expect in my head. |
| 14:15 | <annevk> | nox: ideally, it's something like Firefox does A, Chrome does B, A is nice because C, B is nice because D |
| 14:15 | <nox> | annevk: I described Firefox because Chrome does what is in the PR. |
| 14:16 | <nox> | annevk: Ok, I'll think about describing things that way. |
| 14:16 | <annevk> | nox: for a higher-level discussion you want everything in a single place so folks can quickly grasp what's going on |
| 14:16 | <annevk> | nox: ta! |
| 15:12 | <annevk> | I still quite like https://www.w3.org/Bugs/Public/show_bug.cgi?id=27301#c2 |
| 15:12 | <annevk> | Maybe I'll file an issue later |
| 15:52 | <Ms2ger> | annevk, do we have/want something in infra to concatenate two lists? |
| 16:04 | <annevk> | Ms2ger: an open issue perhaps? |
| 16:05 | <annevk> | Ms2ger: do not recall that happening anywhere |
| 17:05 | <Domenic> | annevk: should all instances of <span>Content-Type</span> become `<code>Content-Type</code>`? I only changed the one that was already backticked from <span> to <code>. |
| 17:09 | <annevk> | Domenic: I guess not then |
| 17:09 | <annevk> | Domenic: a lot of that needs modernizing anyway |
| 17:09 | <Domenic> | OK, I'll make a note and leave the rest |