[html5] r1818 - [e] (0) remove the open issues section for URLs
whatwg at whatwg.org
whatwg at whatwg.org
Fri Jun 27 01:30:20 PDT 2008
Author: ianh
Date: 2008-06-27 01:30:19 -0700 (Fri, 27 Jun 2008)
New Revision: 1818
Modified:
index
source
Log:
[e] (0) remove the open issues section for URLs
Modified: index
===================================================================
--- index 2008-06-27 08:14:03 UTC (rev 1817)
+++ index 2008-06-27 08:30:19 UTC (rev 1818)
@@ -222,10 +222,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>
@@ -2679,9 +2676,50 @@
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>
<p>A <dfn id=url>URL</dfn> is a string used to identify a resource. A <a
@@ -3011,62 +3049,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
Modified: source
===================================================================
--- source 2008-06-27 08:14:03 UTC (rev 1817)
+++ source 2008-06-27 08:30:19 UTC (rev 1818)
@@ -924,9 +924,53 @@
a complete description of what HTML user agents need to implement to
be compatible with Web content.</p>
- <p class="big-issue">The text in this section is not yet integrated
- with the rest of the specification.</p>
+ <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>Terminology</h4>
<p>A <dfn>URL</dfn> is a string used to identify a resource. A
@@ -1287,67 +1331,8 @@
URL without an error.</p>
- <h4>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>
-
- <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>
-
<h4>Interfaces for URL manipulation</h4>
<p>An interface that has a complement of <dfn>URL decomposition
More information about the Commit-Watchers
mailing list