Patch HTML's base URL stuff to be in terms of DOM

[annevk]

Per https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c6 base URL will become a concept of documents.

Then we need a way to set the base URL of a document from another specification. When set, this changes the URL of the document and then for each inclusive descendant, in tree order, notifies the node of a base URL change, if the node registered for base URL changes. This allows e.g., <a> to correct its URL.

We also change adopt to run these base URL change notifications. It's unclear whether they should run before the adoption notification or after, or whether the adoption notification by itself is sufficient. I suspect we want to have both separately so you don't forget any.

@ajklein @coonsta @smaug---- does this make sense to you?

[ajklein]

For which elements is notification of a base URL change necessary? Can't elements lazily look at the document's current base URL when returning complete URLs? This is how <a> works in Blink, for example. Are there cases where a change of base URL triggers some behavior? I tried this with an <img> and saw no re-fetch.

[annevk]

That is an excellent question. We just need to update https://html.spec.whatwg.org/multipage/infrastructure.html#dynamic-changes-to-base-urls then to make it clear the href attribute gets parsed on getting. It's not defined as such now I think.

We do have to make it extremely clear then though at which point the underlying URL gets copied, e.g. for navigate or fetching.

[annevk]

I will leave this open until HTML is patched.

[domenic]

You also need to update the URL spec so that every time a URLUtils getter is called, the internal url is re-parsed with respect to a fresh "get the base" call.

[ajklein]

I'm confused, why do we need to change the spec here? Is it somehow observable when the base URL update happens?

[domenic]

@ajklein if I understand correctly the spec is wrong with regard to the test case from https://github.com/whatwg/url/issues/54. Browsers show the following behavior:

console.log(document.querySelector("a").href); // http://example.com/foo.html
document.querySelector("base").href = "http://otherexample.org";
console.log(document.querySelector("a").href); // http://otherexample.org/foo.html

however the URL spec's URLUtils spec does not update href with the new base upon getting. (See: href getter, or any other getter in URLUtils.)

HTML attempts to patch this with https://html.spec.whatwg.org/multipage/infrastructure.html#dynamic-changes-to-base-urls but it only does so "If the absolute URL identified by the hyperlink is being shown to the user", which is not the case for <a href> (or for anything in real browsers, really).

[annevk]

And the way HTML patches this assumes a notification system rather than a lazy approach. While the difference is not observable, specifying it in the lazy way would avoid people suggesting custom element callbacks for it, for instance. So yes, both HTML and URL need changes.

[ajklein]

I guess I care less about spec language than requirements on implementors.

[annevk]

@ajklein how do you lazily do things like updating what :visited matches, isn't that directly observable?

[ajklein]

@annevk ah, good one, we do indeed have an updateBaseURL() call in Blink (and WebKit) that walks the document and tells anchors to check their visited status. So I guess this is necessary for HTML-as-Custom Elements.

[domfarolino]

I was revisiting https://github.com/whatwg/html/issues/7383 which brought me here. What exactly is the work that needs to be done for this issue? Is it something like:

1. Move the sort of COMEFROM-ey logic in https://html.spec.whatwg.org/multipage/urls-and-fetching.html#dynamic-changes-to-base-urls to explicit node subscription (where <a> elements etc., would explicitly subscribe to base URL updates)
2. Have base URL updates in HTML call into the DOM spec, where we traverse the DOM notifying each subscribing-element of the base URL update and run its specific "respond to base URL update" steps?

Is it something like that? I was initially confused about this sentence from the OP:

Then we need a way to set the base URL of a document from another specification.

The HTML Standard will still be responsible for setting the Document's base URL, right? Do we need to support the DOM Standard updating a Document's base URL?

[annevk]

@domfarolino back then the idea was that DOM would define the base URL field on documents.

I'm no longer certain that's needed as I don't think we want to expose base URL changes to custom elements. (Don't use base URLs would be the advice today, essentially.)

So at this point we could probably just keep it all in HTML? But we should still change the COMEFROM-ey logic as you write.

[domenic]

The base URL stuff in HTML is broken at least in the following way: it depends on concepts, "base URL change steps" and "affected by a base URL change", which no longer exist in DOM.

I think it used to be more broken, in that it used those concepts to do some complicated stuff like adjusting what aElement.href returned. Now it looks like it basically only updates UI stuff?

It's not clear to me we really need a dedicated section on that UI stuff, or anything algorithmic. It feels rather "obvious" to me that such UI needs to be a live display of the URL. The only instances of such UI that exist in today's browsers, to my knowledge, are all "just in time" (e.g. on hover or on DevTools interaction). There's no need to "push" updates to them.

So honestly I'd vote for just removing https://html.spec.whatwg.org/#dynamic-changes-to-base-urls entirely.

[annevk]

Isn't :visited a thing that's still directly observable?