W3C home > Mailing lists > Public > public-html-commits@w3.org > June 2008

html5/spec Overview.html,1.918,1.919

From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
Date: Fri, 06 Jun 2008 19:04:17 +0000
To: public-html-commits@w3.org
Message-Id: <E1K4hEX-000812-53@lionel-hutz.w3.org>

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

Modified Files:
Log Message:
note that we need to resolve the issue of dynamically changing base href (whatwg r1730)

Index: Overview.html
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.918
retrieving revision 1.919
diff -u -d -r1.918 -r1.919
--- Overview.html	6 Jun 2008 18:55:08 -0000	1.918
+++ Overview.html	6 Jun 2008 19:04:14 -0000	1.919
@@ -6311,6 +6311,50 @@
     <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)
Received on Friday, 6 June 2008 19:04:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:09:16 UTC