Permalink
Browse files

[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
  • Loading branch information...
Hixie committed Jun 6, 2008
1 parent e423f19 commit c678768f216f6a881108f009a6602b68d8e83542
Showing with 89 additions and 0 deletions.
  1. +44 −0 index
  2. +45 −0 source
View
44 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>
View
45 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>

0 comments on commit c678768

Please sign in to comment.