- From: Timothy Gu <notifications@github.com>
- Date: Fri, 12 Jan 2018 13:00:39 -0800
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/pull/494/review/88602078@github.com>
TimothyGu commented on this pull request. > - The [=interface prototype object=] - for a given interface |A| must have a - \[[Prototype]] [=internal slot=] whose value is returned from - the following steps: + The [=interface prototype object=] for a given [=interface=] |interface| and [=Realm=] |realm| + is created as follows: I'd actually prefer ```html <h4>Named properties object</h4> For every [=interface=] declared with the [{{Global}}] [=extended attribute=] that [=support named properties|supports named properties=], there must exist an object known as the <dfn export>named properties object</dfn> for that interface on which named properties are exposed. <div algorithm> The [=named properties object=] for an [=interface=] |interface| in [=Realm=] |realm| is <dfn lt="create a named properties object">created</dfn> as follows: […] </div> ``` then ```html 1. Let |namedPropertiesObject| be the result of [=create a named properties object|creating a named properties object=] for |interface| in |realm|. ``` We don't use ES-style abstract operations much in Web IDL, and there are not many reasons to start now. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/pull/494#discussion_r161324132
Received on Friday, 12 January 2018 21:11:54 UTC