[Proposal] base attribute to specify base url for relative url's contained within

The base tag gives us the ability to specify a base url to apply relative url’s against within the entire document.

This proposal is to allow similar functionality, but within subtrees of the document.


Node.baseURI is a property on each Node and would be matching proposed base attribute.

There is an ambiguity in interpretation of this attribute against element with external (or internal) content defined via href or src attribute. For IFRAME it would mean ignoring the base in favor of src URL. In currently discussed INCLUDE, TEMPLATE, DCE I would expect same.

Proposing to interpret the base on inline (fallback) content and override by URL defined by src upon the content loaded and before DOM injection.

1 Like

Thanks for pointing out that attribute. It is currently read only. This proposal is to allow each node to specify a different base uri within that node. So maybe if it could be settable as well?

Could you share an example use-case?

1 Like

The biggest use case is streaming html from a third party provider to a target element, where we don’t want to cause the browser to download images with invalid url’s.

Ideally, the platform would provide first class support for client-side includes, including support for relative url’s, just as it provides with iframes, perhaps as a by-product of implementing HTML Modules.

Also ideally, the platform would provide a way to do this in a service worker - [Proposal] Support Cloudflare’s HTMLRewriter api in Workers - APIs - WICG.

But all these things seem to be frozen out by the browser vendors’ priorities, so I thought I would be an annoying squeaky wheel by proposing this alternative “primitive”, which would help overcome one obstacle, knowing full well it will be ignored as well ( :slight_smile: )

There are some concerns on dynamic nature of baseURI :

  • on the moment of attaching to DOM, URLs in content have to be resolved.
  • availability of baseURI even earlier on the moment of child attach would benefit performance
  • should already resolved URLs be re-computed?
  • should dependencies be re-fetched if URL changed?

From another side, the URL change for frame is quite legitimate, same with image.

There are cloud-based CMS, each providing own “frame” with associated resources. Those are shown perfectly in IFRAME but can not be injected into DOM as use relative URLs for own dependencies. This pattern is true for Drupal, Adobe AEM, Liferay. Most likely would be true in other CMS or publishing systems.

Also this is essential pattern of reusing 3rd party content from systems which allow the discrete access to particular feeds like Mediawiki, StackOverflow, or Craigslist.