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 whatwg/url#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.