This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In reading the section about the 'img' element [1], I see the statement: "A user agent that obtains images immediately must synchronously update the image data of an img element whenever that element is either created with a src attribute, or has its src attribute set, changed, or removed." In documents (e.g. XHTML5) where xml:base is allowed, the 'src' attribute will be resolved against the element's base URI derived from the xml:base attribute. The result is that if an xml:base attribute is present in the original markup, it will affect the resolved URI derived from the 'src' attribute. If that xml:base attribute is later programmatically changed, it is unclear what the user agent should do. The 'src' attribute has not been changed and so it will not be resolved again. Unfortunately, the base URI has changed and the resolved URI is no longer necessarily valid. This gets even more complicated if the xml:base attribute is on an ancestor of the 'img' element and causes the base URI to change for a whole subtree. I believe the specification should be clear one way or the other what the user agent should do with resolved URI values if the base URI is changed programmatically via an xml:base attribute change. It may be the case that a change to the base URI after resolving URI values should be viewed as "bad practice." As such, we shouldn't incur the penalty of resolving all URI values on all such elements in the affected subtree. That is, unless someone can show a valid use case or contradiction that could subsequently be derived (e.g. consistency). It should be noted that xml:base's influence on the resolved location works quite well in browsers that currently support it for content that is added the DOM programmatically as long as the xml:base attribute exists on an element before it is added to the DOM. [1] http://www.w3.org/TR/html5/embedded-content-1.html#the-img-element
I think it's quite clear that the image should not be reloaded, but if you set a new src attribute after that it will be resolved against the new base. The same kind of thing applies to <base href="foo">.
(In reply to comment #1) > I think it's quite clear that the image should not be reloaded, but if you set > a new src attribute after that it will be resolved against the new base. The > same kind of thing applies to <base href="foo">. That is certainly the specified behavior for the 'img' element but I don't think that it is clear that it is an explicit choice. A simple non-normative statement, possibly in the resolving URI section, that says something like: "Once a URI value is resolved, further changes to the base URI caused by setting or changing xml:base attributes will not affect the resolved value. Other actions may be required to cause the URI to be resolved against the changed base URI." would be helpful if that is the intended outcome. If we expect the base URI to have a more dynamic behavior, the specification is underspecified.
I did just notice the section on "Dynamic Changes to base URLs" [1] where there is a note about the 'img' element. I think it would be much more clear to have that in section 4.8.1 "The img element" and then refer to 2.6.5. In section 2.6.5, it would make sense to make a more general statement about expected behaviors when the base URI is changed for all elements.
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: It's an explicit choice (and there's a comment in the spec source about it) but I don't intend to mention this everywhere that resolving URLs is mentioned because there's some 100+ occurrences of that and the spec is already hard enough to read as it is.