--- a/proposals/request-feature/Overview.html	Thu May 26 18:17:11 2011 +0200
+++ b/proposals/request-feature/Overview.html	Thu May 26 18:53:35 2011 +0200
@@ -15,6 +15,7 @@
           ],
           edDraftURI:   "http://w3c-test.org/dap/proposals/request-feature/",
           copyrightStart: 2011,
+          noIDLIn:      true,
           wg:           "Device APIs Working Group",
           wgURI:        "http://www.w3.org/2009/dap/",
           wgPublicList: "public-device-apis",
@@ -222,6 +223,60 @@
         with the <dfn class='external'>ECMAScript Bindings</dfn> defined by Web IDL [[!WEBIDL]].
       </p>
     </section>
+    <section>
+      <h2>Requesting Features</h2>
+      <p>
+        This interface defines a simple method for loading modular scripts that have access to a specific set of
+        privileged features.
+      </p>
+      <div title='Window implements RequestFeatures' class='idl'></div>
+      <dl title='[NoInterfaceObject] interface RequestFeatures' class='idl'>
+        <dt>void requestFeatures()</dt>
+        <dd>
+          <p>
+            Requests a list of features that are to be made available (at the user's agreement) to a list
+            of scripts, which are loaded in a contained manner as described in section <a href='#modules'></a>.
+            When these two operations are performed successfully, the callback is called with a list of 
+            objects representing each script module.
+          </p>
+          <dl class='parameters'>
+            <dt>DOMString[] features</dt>
+            <dd>
+              A list of feature strings (e.g. <code>geolocation</code>, <code>contacts</code>, <code>indexeddb</code>)
+              that the author is requesting access to. Individual feature strings are defined by their respective
+              specifications. A user agent MUST ignore feature strings which it does not know. Vendor-specific
+              features are expected to be identified using vendor-prefixed strings. Mechanisms to obtain user
+              agreement for access to these features are left up to implementations. If this list is empty, no
+              user agreement is necessary and the modules are loaded immediately.
+            </dd>
+            <dt>DOMString[] modules</dt>
+            <dd>
+              A list of paths to scripts to be loaded.
+              <!-- XXX -->
+            </dd>
+            <dt>RequestFeaturesCB successCB</dt>
+            <dd>
+              
+            </dd>
+          </dl>
+        </dd>
+      </dl>
+      <!-- 
+        XXX
+          - scripts that don't load produce an undefined object
+          - features aren't necessarily accepted in bulk, those that aren't are simply
+            automatically declined
+          - features in the main scope are automatically declined
+          - zip links
+          - need API to know which accesses were granted
+      -->
+    </section>
+    <section id='modules'>
+      <h2>Containing Access</h2>
+      <p>
+        
+      </p>
+    </section>
     <section class='appendix'>
       <h2>Acknowledgements</h2>
       <p>

Binary file proposals/request-feature/frac-unicorner.zip has changed

Binary file proposals/request-feature/xss-pwnd.zip has changed