[e] (0) note that we need to resolve the issue of dynamically changin…

…g base href

git-svn-id: http://svn.whatwg.org/webapps@1730 340c8d12-0b0e-0410-8428-c7bf67bfef74

index

@@ -6220,6 +6220,50 @@ data:text/xml,<script xmlns="http://www.w3.org/1999/xhtml"><![CDATA[ alert('test
 
     <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>
 

source

@@ -4683,6 +4683,51 @@ data:text/xml,<script xmlns="http://www.w3.org/1999/xhtml"><![CDATA[ alert('test
     consistent throughout, maybe make it hyperlink to a definition
     each time</li>
 
+    <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)
+-->
+    </li>
+
    </ul>
 
   </div>