- 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