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
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>
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.