| 01:30 | <MikeSmith> | in documentation in interfaces defined with Web IDL in specs, is it OK to describe instances as “objects that are instances of the Foo interface”? |
| 01:30 | <MikeSmith> | *documentation on interfaces |
| 01:32 | <TimothyGu> | MikeSmith: technically it's "objects that implement the Foo interface" per https://heycam.github.io/webidl/#implements,https://heycam.github.io/webidl/#implements, but isn't it easier to say "Foo objects" |
| 01:33 | <MikeSmith> | TimothyGu: well the specific context I am trying to deal with is a general case, so I don’t have one specific Foo object in this context. |
| 01:34 | <MikeSmith> | lemme show you the exact wording I have... |
| 01:34 | <MikeSmith> | > See _Iterator-like methods_ in _Information contained in a WebIDL file_ for information on how an iterable declaration in an interface definition causes entries(), forEach(), keys(), and values() methods to be exposed in objects that are instances of the interface. |
| 01:35 | <MikeSmith> | where _Iterator-like methods_ hypertext is a link to https://wiki.developer.mozilla.org/en-US/docs/MDN/Contribute/Howto/Write_an_API_reference/Information_contained_in_a_WebIDL_file#Iterator-like_methods |
| 01:35 | <TimothyGu> | Okay. Yeah, "objects that implement the interface" would be the technically proper wording |
| 01:36 | <MikeSmith> | OK super |
| 01:36 | <MikeSmith> | thanks much |
| 01:37 | <MikeSmith> | oh |
| 01:37 | <MikeSmith> | "exposed *from* objects that implement the interface"? |
| 01:38 | <MikeSmith> | what preposition is best there? |
| 02:24 | <Domenic> | If this is MDN documentation, I have a long-standing pet peeve to remove all uses of the term "interface", since it it is a COBOL-ism holdover and the correct thing in JavaScript is "class". |
| 02:25 | <Domenic> | I've tried suggesting this before and been convinced it will be easier to change Web IDL first before we can convince the MDN maintainers to change. |
| 03:07 | <MikeSmith> | Domenic: yeah I personally would be much happier if we could make it align with JavaScript |
| 03:08 | <MikeSmith> | that’d certainly be more clear for web developers |
| 10:38 | <annevk> | I would love to see that change in IDL |
| 13:55 | <Domenic> | I want to tackle some easier ones first, in particular https://github.com/heycam/webidl/issues/350 |
| 14:56 | <MikeSmith> | if we wanted to get more changes made to the IDL spec more quickly, my impression is that it could happen if we had somebody willing to put (more) money into a contract to pay for the necessary work |
| 14:56 | <MikeSmith> | or maybe not and the real bottleneck is still just not having enough people to work on it, regardless of money |
| 15:00 | <annevk> | I think the problem is in part that the payoff is not direct and that there's a lot of cross-cutting concerns. |
| 15:01 | <MikeSmith> | yeah |
| 15:04 | <MikeSmith> | so by the way about the MDN annos, I notice a kind of bad usability/discoverability problem that happens in a small number of cases |
| 15:04 | <MikeSmith> | if you go to https://html-mdn.herokuapp.com/output/multipage/semantics-other.html#selector-read-only |
| 15:04 | <MikeSmith> | ... there is actually an MDN anno for ":read-only" |
| 15:05 | <MikeSmith> | but it’s not visible right there at point of use |
| 15:05 | <MikeSmith> | not aligned there |
| 15:06 | <MikeSmith> | the reason is, if you go to https://html-mdn.herokuapp.com/output/multipage/semantics-other.html#pseudo-classes and open the second anno there |
| 15:07 | <MikeSmith> | ... you’ll see it’s one giant long anno with info for every single pseudo-class in that dl/dt/dd list in the body of the spec |
| 15:09 | <MikeSmith> | but no normal reader would ever realize that they need to scroll all the way back up there to find the anno |
| 15:10 | <MikeSmith> | this is why, when I first added the MDN annos, I made them un-minimized by default — because otherwise, we run into discoverability issues like that |
| 15:11 | <MikeSmith> | so anyway if anybody has some good ideas about how we could better handle discoverability of the annos in cases like that, lemme know |
| 15:38 | <Domenic> | MikeSmith: "Pseudo-classes / No support in current engines. / No support data" seems not so good |
| 15:39 | <MikeSmith> | Domenic: yeah that’s a bug |
| 15:39 | <Domenic> | MikeSmith: interesting, I guess the problem there is that we're going up to child-of-body, which is the entire <dl>. |
| 15:40 | <MikeSmith> | yeah, that is the cause |
| 15:40 | <MikeSmith> | maybe we can special-case <dt> |
| 15:40 | <Domenic> | Yeah that's what I'm wondering |
| 15:41 | <MikeSmith> | yeah will look into that |
| 15:41 | <Domenic> | If we had a before/after diff to judge the impact i'd be comfortable with that |
| 15:41 | <Domenic> | To make sure it doesn't have worse impacts elsewhere |
| 15:41 | <MikeSmith> | right |
| 15:41 | <MikeSmith> | yeah good point |
| 15:41 | <MikeSmith> | I can do it in a way that gives us a diff |
| 16:30 | <TabAtkins> | Hm, why go up to child-of-body, rather than just nearest-ancestor-not-autoclosed-by-an-aside? |
| 16:42 | <Domenic> | That sounds more complicated :) |
| 16:43 | <Domenic> | If it was easy to know what that list was then we could probably do it |
| 19:38 | <TabAtkins> | If only there were a spec around that described the auto-closing behavior, or perhaps an editor of said spec... ^_^ |
| 22:39 | <shu> | Domenic: mind elaborating the confusion on https://github.com/tc39/ecma262/issues/1524#issuecomment-611222892? |
| 22:39 | <Domenic> | shu: just confused/sad that we got to that conclusion given the arguments presented. |
| 22:39 | <shu> | AIUI the problem we want to solve was to not mislead -- currently, sometimes implementations mean a user agent, sometimes all user agents |
| 22:40 | <shu> | the compromise was to directly address that issue by enumerating all the places where implementation actually means host |
| 22:40 | <shu> | and linking to the actual host spec |
| 22:41 | <Domenic> | Sure. We've just lost a valuable word to discuss the distinction. |
| 22:41 | <shu> | that's fair -- the plan is to clarify that in the front matter somehow, non-normatively |