This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The base element affects how URLs are opened. http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#urls http://www.w3.org/html/wg/drafts/html/master/document-metadata.html#the-base-element Citing the latter reference: ]] The base element allows authors to specify the document base URL for the purposes of resolving relative URLs, and the name of the default browsing context for the purposes of following hyperlinks. [[ PROPOSAL: Please point out that the opening of longdesc URLs *is* affected by the presence of a base element and (for XML documents) by the xml:base attribute (http://www.w3.org/html/wg/drafts/html/master/dom.html#the-xml:base-attribute-%28xml-only%29). May be this does not need to be specified in much detail. *May be* it is enough to point to HTML5. But please mention it. Why? Well, currently neither iCab or Opera seems to take <base> into account. And i should be clarified how it works. For instance, in this document, the relative longdesc URL should open relative to the page referenced in the base href attribute: <!DOCTYPE html> <title>Base element with href attribute.</title> <base href="http://www.example.com/news/index.html"/> <img src=img alt=alt longdesc="#description1" /> And in this page, the relative longdesc would display a fragment of the current page in the nested iframe element: <!DOCTYPE html> <title>Base element with target attribute.</title> <base target="theIframe"/> <img src=img alt=alt longdesc="#decription1" /> <iframe name="theIframe" id="theIframe" ></iframe> And in this case, the fragment would be taken from the page at differentpage.html <!DOCTYPE html> <title>Base element with target attribute.</title> <base href="differentpage.html" target="theIframe"/> <img src=img alt=alt longdesc="#decription1" /> <iframe name="theIframe" id="theIframe" ></iframe>
It seems that base *should* affect how longdesc is presented. I lean towards adding the statement requested. The iframe case is a little contrived - it is useful for a photo viewer, but a problem if there are any other links in the page so would probably only work in a self-contained app or within a frame.
(In reply to comment #1) > It seems that base *should* affect how longdesc is presented. I lean towards > adding the statement requested. > > The iframe case is a little contrived - it is useful for a photo viewer, but > a problem if there are any other links in the page so would probably only > work in a self-contained app or within a frame. Assuming that @longdesc should be aligned with @cite, perhpaps seciton '2.5.3 Dynamic changes to base URLs' should be considered as well? Just consider this note a note - I have not fully 'parsed' that section ... http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#dynamic-changes-to-base-urls
Leif, I believe that you have talked to implementors about this case, and their input would be greatly appreciated in helping to resolve this. FWIW in the URL spec I am trying to get drafted, relative URLs would be resolved according to the base. This is also the case in RFC 3896 - the most current finished URL spec (which is not that great in general, IMHO, but does a pretty good job for http: URLs)
Since longdesc is defined as a URL, and uses the HTML5 definition which in turn rely to RFC 3986 (and 3987) this is unnecessary - the statement is already there.