| 12:16 | <annevk> | shu: I don't think that really works and if this is something Mozilla could object to I hope we do so |
| 12:16 | <annevk> | Going all the way back to hosts having to monkey patch is such nonsense |
| 14:03 | <zcorpan> | domfarolino: yo |
| 14:04 | <zcorpan> | domfarolino: I'm working on lazy images today again :) |
| 14:15 | <domfarolino> | zcorpan: excellent. I should be around a bit |
| 14:17 | <zcorpan> | domfarolino: did you see https://github.com/whatwg/html/issues/5408#issuecomment-610033630 ? I'll look at httparchive today to test my hypothesis |
| 14:27 | <domfarolino> | zcorpan: I see that there was activity on that issue, haven’t looked at it yet but will check it out today! Sounds exciting |
| 14:40 | <annevk> | Domenic: well, HTML doesn't have nullable DOMString for anything but enumerated attributes either |
| 14:41 | <annevk> | Domenic: so if that was the argument I'm confused |
| 14:41 | <Domenic> | annevk: I see, true. |
| 14:41 | <devsnek> | did the async iterator api on streams ever get picked up by any implementations |
| 14:41 | <Domenic> | devsnek: sadly not yet |
| 14:42 | <devsnek> | do you know if that's low priority or if something is preventing it |
| 14:44 | <Domenic> | devsnek: I think generally low priority but in Chrome the easiest path for us would be to get https://github.com/heycam/webidl/pull/808 merged and reviewed (cc edgarchen annevk) and then implement that in our Web IDL bindings system |
| 14:46 | <MikeSmith> | Domenic: I remember that a few months back you pointed out a case to me where we had a Can I Use anno in the HTML spec that provided better information than the corresponding MDN anno |
| 14:46 | <Domenic> | MikeSmith: https://github.com/whatwg/html-build/issues/213 |
| 14:46 | MikeSmith | looks |
| 14:46 | <MikeSmith> | there we go |
| 14:46 | <MikeSmith> | thanks! |
| 14:47 | <Domenic> | It would be nice to remove the caniuse stuff, for sure... |
| 14:50 | <MikeSmith> | yeah I can get make some patches for BCD |
| 14:51 | <MikeSmith> | the “MDN has 2 entries for Firefox and 2 for Firefox for Android” case was due to a bug that we since fixed |
| 14:53 | <annevk> | Domenic: edgarchen said he would have time next week, if that falls through I'm happy to take a look |
| 14:54 | <Domenic> | Great |
| 15:14 | <shu> | annevk: sorry i'm confused |
| 15:14 | <shu> | annevk: what monkey patching? |
| 15:15 | <annevk> | shu: if ECMAScript doesn't acknowledge it can be integrated as part of other specs, presumably the host hooks are going? |
| 15:16 | <shu> | annevk: oh it is acknowledging that, i think there's a miscommunication |
| 15:16 | <shu> | annevk: in a mtg atm, will elaborate in a bit |
| 15:20 | <annevk> | shu: https://github.com/heycam/webidl/pull/870#issuecomment-611586723 |
| 15:28 | <shu> | annevk: i am missing context here, unfortunately |
| 15:28 | <annevk> | shu: ECMAScript is apparently inconsistent on how to spell builtin |
| 15:29 | <annevk> | shu: it would be nice if it picked a single style so we could align |
| 15:29 | <shu> | annevk: agreed. just making sure that was a separate thing from the "doesn't acknowledge it can be integrated into other specs" concern |
| 15:30 | <shu> | annevk: as for that, you're talking about the host vs implementation discussion, right? |
| 15:30 | <annevk> | shu: yeah |
| 15:30 | <annevk> | shu: in particular the conclusion of not distinguishing the NaN implementation-defined from how to allocate a Realm |
| 15:31 | <shu> | annevk: so the editor group conclusion was to just pick a term of art, "implementation", to only mean "blackbox indistinguishable" from an observable behavior inside ecma262 point of view |
| 15:31 | <shu> | annevk: and at the same time, address the spec layering issue directly by linking to upstream specs where appropriate |
| 15:32 | <shu> | annevk: like for Realms, host hooks, etc, we'll actually link to the relevant HTML parts that specify the additional requirements |
| 15:32 | <shu> | the actual interface points of the spec are unchanged |
| 15:33 | <shu> | if this arrangement isn't acceptable for HTML folks, i'm happy to bring it up again next week and relitigate |
| 15:36 | <annevk> | shu: it doesn't make sense to me to have interface points but then not distinguish the interface points from things that are actually up to implementations entirely |
| 15:38 | <annevk> | shu: that ECMAScript can be entirely self-hosted is fine and I think could be addressed by defining a basic self-hosting implementation in an appendix, that would also make it clear how various hooks are kinda broken and how agents don't have any |
| 15:48 | <devsnek> | annevk: self hosted meaning the host doesn't provide any of its own behaviour for hooks? |
| 15:51 | <annevk> | devsnek: self-hosted is where the hooks are all implementation-defined, is the way I think about it |
| 15:51 | <devsnek> | isn't that just "normal" |
| 15:52 | <annevk> | it's not my normal, but it could be yours |
| 15:56 | <devsnek> | don't hooks only exist for implementation defined behaviour |
| 16:01 | <shu> | annevk: concretely, we're planning on distinguishing the interface points by linking to the upstream specs |
| 16:02 | <annevk> | shu: but I thought that was non-normative? |
| 16:02 | <shu> | annevk: i'm trying to understand if we distinguish the interface points explicitly somehow, is the host-implementation distinguish in prose still as important to you |
| 16:02 | <annevk> | it kinda has to be |
| 16:03 | <shu> | annevk: whether something is definable by an upstream spec or an implementation is certainly normative |
| 16:03 | <shu> | or do you mean whether something _is_ an interface point is non-normative? |
| 16:03 | <annevk> | both? |
| 16:03 | <annevk> | (I think all should be normative) |
| 16:03 | <shu> | i'm kinda confused; to say something is defined elsewhere is definitely normative |
| 16:04 | <shu> | the problem right now is for the reader, they don't know if "defined elsewhere" means "defined in another spec" or "go read the c++ of whatever implementation you're running" |
| 16:04 | <annevk> | Same, I guess I don't really see how this is going to work, an example might help |
| 16:08 | <shu> | annevk: we don't have any PRs up yet, but for example, i was imagining something like |
| 16:09 | <shu> | annevk: in https://tc39.es/ecma262/#sec-initializehostdefinedrealm, there will be a note that links to https://html.spec.whatwg.org/#realms-settings-objects-global-objects directly, saying HTML spec has additional requirements here |
| 16:11 | <shu> | annevk: as opposed to in something like https://tc39.es/ecma262/#sec-numeric-types-number-exponentiate, there'll be no links to upstream specs because there are no upstream specs that have additional requirements |
| 16:12 | <shu> | annevk: but ecma262 doesn't want to preclude that possibility, in case in the future if there's some standardized embedded device host spec that does impose a particular exponentiate algorithm on all its implementations |
| 16:19 | <devsnek> | shu: any implementation might have its own usage, are they supposed to all link to their docs/spec there? |
| 16:20 | <shu> | devsnek: if there *are* upstream specs, i recommend it |
| 16:20 | <shu> | not docs, specs |
| 16:20 | <devsnek> | node doesn't have a spec but it implements some of these hooks |
| 16:21 | <shu> | then it doesn't count |
| 16:21 | <devsnek> | why |
| 16:21 | <shu> | the point is to help readers understand additional requirements imposed by specifications that may have its own implementations |
| 16:21 | <shu> | not enumerate how it's implemented |
| 16:21 | <shu> | if node has its own spec and independent implementations and interop requirements, then we should link |
| 16:22 | <devsnek> | the only difference between for example how promises are hooked between node and html is one has a spec and one has docs |
| 16:22 | <shu> | no, the difference is one has at least 3 independent implementations that are expected to behave the same |
| 16:23 | <devsnek> | node has 3 |
| 16:23 | <devsnek> | or 2 |
| 16:23 | <devsnek> | I think chakranode is dead now but Graal has nodejs |
| 16:25 | <shu> | there is a qualitative difference between a reference implementation and a standard in my opinion |
| 16:25 | <devsnek> | I don't see the difference between "my impl of this hook has to support a browser" and "my impl of this hook has to support node" |
| 16:25 | <shu> | the difference is html has a spec that implementers consult to then implement it in their own browser |
| 16:26 | <shu> | there is a compliance issue -- a standard exists for html |
| 16:26 | <shu> | you're talking how mechanically it's the same |
| 16:26 | <devsnek> | i mean if you say your runtime supports node |
| 16:26 | <devsnek> | but it works differently |
| 16:26 | <shu> | what is a runtime that supports node |
| 16:27 | <devsnek> | chakranode, v8 node, graaljs node |
| 16:27 | <devsnek> | although i don't think chakranode is maintained anymore |
| 16:27 | <shu> | there was never a standard, that artifacts exist that may interop with a reference implementation may be a pre-step |
| 16:28 | <shu> | like maybe eventually there'll be a reason to guarantee ongoing interop and codify that in a standard and get through all the IPR hoops and all that |
| 16:28 | <devsnek> | so its a legal thing? |
| 16:28 | <shu> | part of why standards exists is a legal thing, yes. for this editorial, it's mainly about expectations of where to look next for requirements |
| 16:28 | <shu> | it's a reasonable line to draw at "link to other specs" |
| 16:29 | <shu> | and not "link to c++ code" |
| 16:29 | <shu> | or "link to docs" |
| 16:29 | <devsnek> | 🤷🏻 |
| 16:29 | <shu> | are you saying to you standards are the same as reference implementations and docs? |
| 16:30 | <devsnek> | no, but in terms of "reasons this hook exists with these requirements" |
| 16:30 | <devsnek> | * yes in terms of "reasons this hook exists with these requirements" |
| 16:31 | <shu> | i disagree. they're only the same mechanically speaking |
| 16:32 | <devsnek> | like someone representing html comes to tc39 and says "hook needs to fulfill x" and someone from node comes to tc39 and says "hook needs to fulfill y" |
| 16:32 | <devsnek> | why do we list x but not y in the spec |
| 16:32 | <devsnek> | also it occurs to me this is probably a bad channel for this |
| 16:34 | <shu> | i feel like i'm repeating myself: because one has a standard and realistic expectations of independent implementations having interop, and the other has a reference implementation only |
| 16:38 | <devsnek> | so in terms of someone implementing their js engine, they should care less about whether their exposing of the hook matches node's needs? |
| 17:09 | <annevk> | shu: aren't you precluding it by not having a host hook? |
| 17:10 | <shu> | annevk: we're not removing host hooks |
| 17:10 | <annevk> | shu: are you adding host hooks for everything that's implementation-defined? |
| 17:11 | <shu> | annevk: ah, i see what you're saying. not right now, but not having a host hook today also doesn't preclude |
| 17:11 | <shu> | annevk: if an upstream spec user materializes we can technically add host hooks to anywhere that says "implementation-defined" without normative differences, really |
| 17:12 | <annevk> | shu: right, so then it makes sense to me to acknowledge them directly |
| 17:13 | <shu> | annevk: concrete suggestions? |
| 17:15 | <annevk> | shu: have host hooks, acknowledge hosts, have the default implementation of each host hook be implementation-defined (this also helps HTML if you add hooks HTML doesn't want to override); I don't really see a need to reference HTML from the spec, but it might be nice |
| 17:16 | <annevk> | shu: this would also allow you to enforce invariants on hosts, though I guess that can also be done through asserts and might be better |
| 17:50 | <shu> | annevk: that is basically the current plan, though we're not adding new host hooks |
| 17:51 | <shu> | annevk: the difference is that the *word* that was settled on was "implementation". so the pushback i'm hearing now is that there is still very strong preference for the single word to be "host" and not "implementation" |
| 17:52 | <shu> | what do you mean by acknowledge hosts? |
| 17:53 | <annevk> | If you 1:1 implementation and host, HTML is the implementation, what does implementation-defined for https://tc39.es/ecma262/#sec-numeric-types-number-exponentiate mean? |
| 17:54 | <shu> | annevk: it means HTML has the right (but not the obligation) to impose additional requirements |
| 17:54 | <shu> | annevk: if it doesn't, that freedom passes through to HTML's implementations |
| 17:54 | <annevk> | shu: literally it says that it's HTML-defined, but HTML doesn't want to define it |
| 17:55 | <annevk> | shu: you can't say implementation is both the host and the implementation, imo |
| 17:55 | <shu> | annevk: it literally just means it's defined somewhere else |
| 17:56 | <shu> | annevk: i'm having trouble understanding why the "right but not the obligation" part is confusing |
| 17:56 | <annevk> | shu: there is no right either since there's no explicit hook |
| 17:57 | <annevk> | shu: (nor should there be) |
| 17:58 | <shu> | annevk: that's the basic disagreement |
| 17:58 | <shu> | annevk: i don't think anybody in ecma262 sees the presence of hooks as conferring the right |
| 17:58 | <shu> | annevk: well, anybody in the editor group |
| 17:58 | <annevk> | How would you do it without hook? |
| 17:59 | <shu> | let me clarify |
| 18:00 | <shu> | by "the right" i mean ecma262 already allows for upstream hosts or implementations to do its own thing there |
| 18:00 | <shu> | host hooks are one way to provide easy hooking points for host-defined behavior |
| 18:00 | <shu> | if HTML said, use the following algorithm for ecma262's Number::exponentiate, so long as its it follows the invariants laid out, HTML has the right to just provide its own algorithm, host hook or not |
| 18:01 | <annevk> | I'm not a fan of that |
| 18:01 | <shu> | sure, but the point is host hooks are mechanics |
| 18:02 | <annevk> | That's what I would call monkey patching and an extremely bad practice when it comes to specifications |
| 18:02 | <shu> | okay, i see |
| 18:02 | <shu> | why is it extremely bad practice in your opinion? |
| 18:02 | <annevk> | But I also think it's plain confusing that implementation sometimes means host and sometimes means implementation |
| 18:03 | <annevk> | shu: it's not clear to implementers from looking at the algorithm how to implement it |
| 18:03 | <annevk> | shu: I guess if you're familiar with the weird way some in TC39 use implementation-defined, you might be alerted to the fact, but otherwise |
| 18:05 | <annevk> | shu: it can also lead to hard to iron out inconsistencies between hosts that force multiple implementations of the algorithm or even conflicts within a single host if it's large enough (e.g., if some non-HTML spec tried to take ownership of some things) |
| 18:06 | <shu> | annevk: i'm very sympathetic to "unclear to implementers", which is how we ended up on "link to the upstream spec (HTML) directly" |
| 18:06 | <shu> | the host-vs-implementation distinction doesn't exist normatively in ecma262, and defining it into existence is very hard |
| 18:07 | <annevk> | It's also not the kind of abstraction you'd offer in code I think (supply your own algorithm that matches this one but fills in a couple of details differently) |
| 18:08 | <shu> | the distinction we're talking about for exponentiation vs, say, module loading, just doesn't exist in ecma262 currently |
| 18:08 | <annevk> | In practice I think it does |
| 18:08 | <annevk> | In the way it's read by implementers I think it does |
| 18:09 | <annevk> | Certainly in the way I read it, it does, but I don't think it offers enough hooks to implement a host (e.g., no way to set up an agent cluster and such) |
| 18:10 | <shu> | in practice it definitely does, but to define the difference normatively in ecma262 isn't going to get consensus |
| 18:10 | <annevk> | shu: it even starts with talking about a host environment |
| 18:10 | <shu> | sigh |
| 18:10 | <annevk> | shu: and there was this whole host objects thing, etc. |
| 18:10 | <shu> | i understand the desire to disallow monkeypatching normatively |
| 18:11 | <shu> | but there isn't consensus for that |
| 18:11 | <annevk> | Is there consensus to replace every instance of host with implementation though? |
| 18:11 | <annevk> | Again, I'd hope Mozilla objects if possible |
| 18:12 | <shu> | we're replacing host-defined with implementation-defined |
| 18:12 | <annevk> | How are the editors explaining "Jobs are scheduled for execution by ECMAScript host environments." |
| 18:12 | <shu> | not touching the word host otherwise |
| 18:13 | <annevk> | I gotta go relax for a bit as it's late here. I'm still rather confused about this direction, but I guess we'll see |
| 18:14 | <shu> | i don't know how to satisfy the stakeholders tbh, without actually precluding the right for hosts but not implementations to override e.g. exponentiate |
| 19:53 | <Domenic> | TabAtkins: Is there any way to disable the Bikeshed thing where it will append "of type X" when I define things in a <dt>? |
| 21:10 | <TabAtkins> | Domenic: I don't think so, lemme check... |