The following document renders as expected in Firefox and Opera. The document fails in Webkit latest nightly: http://www.codedread.com/browser-tests/test-xml-base-xhtml xml:base should be supported in XHTML (on any valid element, of course).
You ask for implement XML Base specification: http://www.w3.org/TR/xmlbase/ So it's an enhancement request.
Just noticed that the URL I pasted in the bug report is missing the .xhtml. The correct URL is as per the URL field. http://www.codedread.com/browser-tests/test-xml-base.xhtml
See also: bug 12579.
The document completeURL method should probably take an optional node parameter. If the node is present, then resolving a relative URL to an absolute one should go up through its ancestors (including itself) to find the first available xml:base, and use it as baseURL. When no node is supplied or no xml:base is found, the document m_baseURL is used.
Worse, it should go through and check all the ancestors, as xml:base instructions can themselves be relative if they don't start with / or a scheme. This is acceptable in terms of performance (what's a log between friends?). Roughly how many callers of completeURL would need to be modified to use the new signature suggested? Could we make a test case covering every way place completeURL is called to give a target? This is a pretty annoying for me if unimplemented.
completeURL() can be called very frequently, so it is important to watch its performance.
Looking at the HTML 5 specification [1], the 'src' attribute should be resolved against the element's base URI. As the xml:base attribute correctly affects the baseURI property in the DOM, this should be straight forward to fix (but those are famous last words). One thing that isn't clear in the HTML5 specification is whether changing the xml:base attribute should cause the image URI to be recalculated. There is a whole section of how the state of the image element changes when the 'src' attribute is set. It doesn't say much about how the state is handle if the base URI changes via setting the xml:base attribute. It think it should be the same as if the 'src' attribute is set but I'll have to file a bug on the HTML5 specification to get that clarified. [1] http://dev.w3.org/html5/spec/Overview.html#resolving-urls [2] http://dev.w3.org/html5/spec/Overview.html#the-img-element
Changing the base URL only causes a reresolution where the spec says it does. I don't explicitly list all the places where it doesn't, because there's so many of them, but if you look in the spec source you'll see comments here and there saying something like "note that this doesn't happen when the base URL changes", etc.
(In reply to comment #8) > Changing the base URL only causes a reresolution where the spec says it does. I don't explicitly list all the places where it doesn't, because there's so many of them, but if you look in the spec source you'll see comments here and there saying something like "note that this doesn't happen when the base URL changes", etc. I did just notice the section on "Dynamic Changes to base URLs" [1] where there is a note about the 'img' element. I think that specifies the complete behavior for the 'img' element. 1. The base URI as calculated with respect to the xml:base must be used to resolve the value of the 'src' to get the URI of the image. 2. Changes to the base URI of the 'img' element do not cause the viewed image to be changed. You would have to set the 'src' attribute (or something like that) to cause it to be resolved again. 3. The 'src' attribute in the interface should always return the correct resolved URI value against the base URI--including one changed after the image location is resolved and presented to the user. [1] http://dev.w3.org/html5/spec/Overview.html#dynamic-changes-to-base-urls
Yup. Note that this behaviour is not a result of the note you mention (actually that's a non-normative example — I've clarified that it's an example in the spec now), it's a result of the requirements and lack of requirements throughout the spec.
This is not a feature we wish to support.