[whatwg] Issues concerning the <base> element and xml:base

[Ian Hickson]

On Sat, 7 Jun 2008, Smylers wrote:
> Ian Hickson writes:
> > On Sat, 1 Mar 2008, Jonas Sicking wrote:
> > 
> > > > It seems like UAs should support a notification mechanism so that 
> > > > when a base URI is changed, all URIs in the document ...  or in 
> > > > that subtree ... get reresolved.
> > > 
> > > I have never heard of anyone that actually desired changing the base 
> > > uri for all or parts of a page dynamically.
> > 
> > I agree that it's a pretty dumb thing to do.
> 
> So it sounds like supporting it isn't necessary, and putting effort into 
> supporting it is a distraction.

Well as Anne says below, we want to make sure that we pick what the 
behavior is so that it is sane so that if anyone does end up depending on 
it, we don't have to spec something insane. That's happened a lot. :-)


> > I'm not really sure how to unspecify that without adding a really 
> > weird clause like "in the event that the attribute is changed, user 
> > agents may, whenever convenient, pretend, for the sake of url 
> > resolution, that it has not changed".
> 
> Why is that weird?  Even if it is, why is being weird worse than 
> creating an implementation burden of something which nobody will use 
> (except by accident)?

It's weird because it's not predictable.

"By accident" is the problem. It's when people accidentally rely on 
misfeatures that are unintended and that rely on weird implementation 
details that we end up with weirdness in the spec.


On Sat, 7 Jun 2008, Anne van Kesteren wrote:
> 
> Well, we want to prevent that at some point an important site will start 
> relying on the specifics of xml:base handling in a particular browser 
> while we can still make the handling something sane we can all agree on.

Right.


On Thu, 17 Jul 2008, Jonas Sicking wrote:
> 
> Assuming there is something sane we can all agree on. So far that is not 
> the case. On both points :)

I think the current text in the spec is pretty reasonable at this point. 
The main text is here:

   http://www.whatwg.org/specs/web-apps/current-work/#dynamic-changes-to-base-urls

...and other parts of the spec ensure that the "Otherwise" clause in that 
section is true (e.g. by carefully defining when a URL is resolved and 
then not resolving it again in the algorithms).

I haven't yet covered style="" attributes. The problem with CSS is that 
there is no clear point at which URLs are resolved... can we say it 
happens during parsing, so that the absolute URLs computed for the first 
cascade are set once and for all?


On Sun, 8 Jun 2008, Maciej Stachowiak wrote:
> 
> It seems weird for src and href attributes to have a URI other than what 
> the element has loaded or is loading - this would be the only case where 
> they may not match.

It's weird, but then so is changing the base URL.


> (Also, would setting href or src to itself in such a case trigger a load 
> of a different resource?)

Yes.


> I have to admit I am not especially excited about implementing instant 
> dynamic updates of everything in the document referencing a URI, whether 
> it triggers a load or not, when the <base> element is changed. That 
> seems like a lot of coding and testing work solely to serve a very 
> unimportant edge case that right now likely no one depends on. In 
> general if the spec requires significant implementation work for 
> something that has no real user or author benefit, just because that is 
> easier to define, then I think we have chosen poorly.

Agreed; I've tried to keep this to a bare minimum. Basically only links 
shown in UI need be updated, if we can get away with saying that CSS 
resolves URLs during parsing.

The UI updates are only a "should", too, since they're not really required 
for interoperability. (I recommend doing it, though, since the URL that is 
resolved when the link is clicked would differ from what the user saw in 
the UI, otherwise.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'