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.
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.
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?
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 ( )
There are some concerns on dynamic nature of baseURI
:
baseURI
even earlier on the moment of child attach would benefit performanceFrom 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.