Use HTML's 'document base URL' concept.

[Ms2ger]

This definition is more correct right now, and using a getter rather than a
mutable field makes it easier to figure out what is returned.

CC whatwg/html#421.

[annevk]

Hmm, but we need some kind of callback for when it changes: #61. I guess defining that in HTML is not too bad, maybe a little weird?

[domenic]

Note that the conclusion of that thread was that the callback is only necessary for CSS; everything else is done lazily.

[annevk]

Also for custom elements that want that kind of behavior, no? Although I guess we could decide not to expose that primitive.

[domenic]

Yeah, I don't think it's a primitive really. Custom elements will probably want to do the same thing a and area do, and compute lazily. CSS could theoretically even be specced that way, although understandably implementations prefer a callback approach.

[annevk]

How can you compute this lazily? It's immediately visible.

[domenic]

When querying :visited, or when rendering, you figure out the resolved absolute URL.

[annevk]

So whenever you render you have to go through all links in the document? Rather than only that rare time someone updates the base URL? I think I know why browsers have their current setup, and why theoretically custom elements might want that too...

[domenic]

I mean, yes, whenever you render a link, you could resolve its URL lazily. With appropriate caching that seems like a totally reasonable strategy. It's certainly a reasonable model for the spec.

I don't think there are any real-world custom element use cases here.

[annevk]

Merged since as @Ms2ger indicated, this is more correct than the status quo.