Does muJS respect the <base> tag for link interception?

[jablonski]

I'm currently testing muJS and I really like it.

If I use urls without trailing slashes (/products) and use a base tag with a trailing slash () to setup the navigation context for the browser, muJS does not work properly, because linked pages (e.g. single product detail pages linked with ) use the wrong url context.

[Amaury]

Thanks a lot for the report! I checked and you're absolutely right. The fix should be straightforward. I'll look into it very soon!

[Amaury]

Thanks for reporting this. The issue was in the URL resolution logic: _resolveUrl() was using window.location.href as the base for resolving relative URLs, which ignores the <base> tag. It now uses document.baseURI, which correctly respects <base href> when present.

The fix is available on the main branch and will be included in the next tagged release.

Note that only the <base> tag from the initially loaded page is used. If dynamically fetched pages have a different <base> value, it won't be applied.

[jablonski]

Thanks for the initial fix, but this doesn't resolve the underlying problem for my use-case. If my whole site uses dynamic base tags (e.g. to use consistently non-trailing slashes), the base must be updated on route changes, otherwise links are broken after the initial navigation.

Why not dynamically updating the base tag?

Something like this works for me:

this._mergeHead = function (doc) {
      const newBase = doc.querySelector("base");
      if (newBase) {
        let docBase = document.querySelector("base");
        if (!docBase) {
          docBase = document.createElement("base");
          document.head.insertBefore(document.head.firstChild, docBase);
        }
        docBase.setAttribute("href", newBase.getAttribute("href"));
      }
     ...
}

[Amaury]

Thanks for the follow-up. I understand the issue, but dynamically updating the <base> tag on every navigation adds a non-trivial amount of code for what seems like a niche use case. Most sites use consistent URL conventions and don't need per-page <base> tags.

Before I consider adding this, could you provide a detailed example of your setup? Specifically:

• A few example page URLs.
• The <base href> value on each of these pages.
• The relative links used in each page and how they should resolve.

This would help me understand whether there's a simpler solution, or whether this really requires updating the <base> tag on each navigation.

[jablonski]

I'm not sure of a dynamic base tag is an edge case. If you want to create a website without trailing slashes, IMHO you have to use the base tag in order to allow relative links work properly. Here's an example:

/ => Homepage
/products => Lists all products
/products/laptops => Lists all laptops
/products/laptops/macbook-air => Detail page
/products/laptops/macbook-pro => Detail page
/products/smartphones => Lists all smartphones
/products/smartphones/iphone16 => Detail page
/products/smartphones/iphone17 => Detail page
/blog => Lists all blog posts
/blog/2026 => Lists all blog posts from 2026
/blog/2026/post1 => First post
/blog/2026/post2 => Second post
/blog/2025 => Lists all blog posts from 2025

If you want to use relative links (e.g. linking from "/products/laptops/macbook-air" to "/products/laptops/macbook-pro" simply via "./macbook-pro", you have to use a base-tag in your page, otherwise the browser uses the wrong context. Same for links between iphone16 and iphone17 or blog posts.

Why use relative links instead of fully qualified ones? E.g. you get content from a WYSIWYG editor, or you want to be able to change category names (e.g. laptops => notebooks) without breaking existing links and so on.

[Amaury]

You're right that the current situation is a bit half-baked: either µJS should handle dynamic <base> tags properly, or it shouldn't handle them at all. I agree.

I'm torn on this. On one hand, I'd like µJS to offer a complete solution. On the other hand, sites that rely on relative URLs typically use trailing slashes to avoid exactly this kind of issue. And looking at studies like the HTTP Archive Web Almanac, the <base> tag is so rarely used that it doesn't even appear in the HTML element rankings.

I'm reopening this issue while I take time to evaluate the amount of code needed to handle this properly, and whether it fits in a library that aims to stay under 5KB.