html5/spec Overview.html,1.1006,1.1007

Update of /sources/public/html5/spec
In directory hutz:/tmp/cvs-serv23421

Modified Files:
	Overview.html 
Log Message:
remove the open issues section for URLs (whatwg r1818)

Index: Overview.html
===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.1006
retrieving revision 1.1007
diff -u -d -r1.1006 -r1.1007
--- Overview.html	27 Jun 2008 08:14:38 -0000	1.1006
+++ Overview.html	27 Jun 2008 08:30:24 -0000	1.1007
@@ -326,10 +326,7 @@
        <li><a href="#resolving"><span class=secno>2.3.3 </span>Resolving
         URLs</a>
 
-       <li><a href="#open-issues"><span class=secno>2.3.4 </span>Open
-        issues</a>
-
-       <li><a href="#interfaces"><span class=secno>2.3.5 </span>Interfaces
+       <li><a href="#interfaces"><span class=secno>2.3.4 </span>Interfaces
         for URL manipulation</a>
       </ul>
 
@@ -2783,8 +2780,49 @@
    description of what HTML user agents need to implement to be compatible
    with Web content.
 
-  <p class=big-issue>The text in this section is not yet integrated with the
-   rest of the specification.
+  <p class=big-issue>we still need to define a cheap, interoperable mechanism
+   for URL attributes and anything else that relies on xml:base and the base
+   element to handle dynamic changes to those attributes and elements,
+   possibly by defining some mechanism which causes changes to be ignored in
+   some reliable way.</p>
+  <!--
+On Sat, 1 Mar 2008, Anne van Kesteren wrote:
+>
+> Note that the new base URI would only take effect once you actually did
+> something with a potentially affected object. For instance, <img> would
+> not start loading a new image if the base URI changes. <img>.src =
+> <img>.getAttribute("src") could start loading a new resource however if
+> the base URI changed since the initial load.
+
+On Sat, 1 Mar 2008, Jonas Sicking wrote:
+> 
+> Well, that was my intention with the initial proposal. But Hixie pointed    
+> out that "did something" is a very hard thing to define. For example on 
+> a <a href="...">, does the user hovering the node count? Does resizing
+> the window count? Does removing the node from the DOM and reinserting it
+> count?
+
+On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
+> 
+> How about requiring that the base used is the one in effect when a given
+> relative URI is resolved, and define that URIs for resource-loading 
+> elements are resolved at the time the relevant attribute is set or
+> parsed (but for hyperlinks, at the time it is dereferenced). That is        
+> easy to implement, interoperable, and reasonably predictable. It makes
+> sense that changing <base> would affect future loads but not trigger
+> reloads of already loaded or already in progress resources.
+
+possibly "in the event that the xml:base or base href attribute is
+changed, user agents may, whenever convenient, pretend, for the sake
+of url resolution, that it has not changed"
+
+possibly define "base uri change notification behaviour" for all
+elements with URI attributes, and then define changing base href and
+xml:base to activate that behaviour on all elements in the affected
+subtree. Also make this algorithm get called when a node from another
+document is inserted into an HTML document. (we could define that
+you're allowed to do that, in the absence of a DOM Core update)
+-->
 
   <h4 id=terminology0><span class=secno>2.3.1 </span>Terminology</h4>
 
@@ -3115,62 +3153,7 @@
    href="#resolve" title="resolve a URL">resolving</a> it results in the same
    URL without an error.
 
-  <h4 id=open-issues><span class=secno>2.3.4 </span>Open issues</h4>
-
-  <div class=big-issue>
-   <p>This section will do the following:</p>
-
-   <ul>
-    <li>make the language used to refer to resolving a base URI consistent
-     throughout, maybe make it hyperlink to a definition each time
-
-    <li>define a cheap, interoperable mechanism for URL attributes and
-     anything else that relies on xml:base and the base element to handle
-     dynamic changes to those attributes and elements, possibly by defining
-     some mechanism which causes changes to be ignored in some reliable way.
-     <!--
-On Sat, 1 Mar 2008, Anne van Kesteren wrote:
->
-> Note that the new base URI would only take effect once you actually did
-> something with a potentially affected object. For instance, <img> would
-> not start loading a new image if the base URI changes. <img>.src =
-> <img>.getAttribute("src") could start loading a new resource however if
-> the base URI changed since the initial load.
-
-On Sat, 1 Mar 2008, Jonas Sicking wrote:
-> 
-> Well, that was my intention with the initial proposal. But Hixie pointed    
-> out that "did something" is a very hard thing to define. For example on 
-> a <a href="...">, does the user hovering the node count? Does resizing
-> the window count? Does removing the node from the DOM and reinserting it
-> count?
-
-On Sat, 1 Mar 2008, Maciej Stachowiak wrote:
-> 
-> How about requiring that the base used is the one in effect when a given
-> relative URI is resolved, and define that URIs for resource-loading 
-> elements are resolved at the time the relevant attribute is set or
-> parsed (but for hyperlinks, at the time it is dereferenced). That is        
-> easy to implement, interoperable, and reasonably predictable. It makes
-> sense that changing <base> would affect future loads but not trigger
-> reloads of already loaded or already in progress resources.
-
-possibly "in the event that the xml:base or base href attribute is
-changed, user agents may, whenever convenient, pretend, for the sake
-of url resolution, that it has not changed"
-
-possibly define "base uri change notification behaviour" for all
-elements with URI attributes, and then define changing base href and
-xml:base to activate that behaviour on all elements in the affected
-subtree. Also make this algorithm get called when a node from another
-document is inserted into an HTML document. (we could define that
-you're allowed to do that, in the absence of a DOM Core update)
--->
-     
-   </ul>
-  </div>
-
-  <h4 id=interfaces><span class=secno>2.3.5 </span>Interfaces for URL
+  <h4 id=interfaces><span class=secno>2.3.4 </span>Interfaces for URL
    manipulation</h4>
 
   <p>An interface that has a complement of <dfn id=url-decomposition>URL

Received on Friday, 27 June 2008 08:31:00 UTC