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

[Ian Hickson]

On Fri, 16 Jan 2009, Anne van Kesteren wrote:
> On Fri, 16 Jan 2009 05:15:41 +0100, Ian Hickson <ian at hixie.ch> wrote:
> > For external resource links created with the <link> element, the URL 
> > is resolved when the resource is fetched, which can be delayed if the 
> > resource doesn't apply yet (e.g. because a media query doesn't yet 
> > match). This could lead to situations where different user agents had 
> > compliant behavior, unfortunately, but this is one case where I can't 
> > see how to avoid it without requiring suboptimal behavior.
> 
> You have the same scenario for inline <style> elements that are either 
> in alternate state or are of a medium that currently does not apply to 
> the document. The user agent is not required to parse those CSS blocks 
> directly, I believe.

Right.


On Fri, 16 Jan 2009, Jonas Sicking wrote:
> >>
> >> Out of curiosity, why make exceptions for hyperlinks here and the 
> >> cite attribute here? As opposed to for example images and iframes?
> >
> > Because the "don't do anything special" behavior (not caching the 
> > absolute URL or anything like that) leads to the following scenario:
> >
> >   user hovers over link
> >   UA resolves URL for display
> >   script changes the base URL
> >   user clicks link
> >   UA resolves URL differently for navigation
> >
> > ...leading to the UI not matching what the UA actually does unless the 
> > UI is updated when the base URL changes. It's only a "should" though, 
> > because well, if you want your UI to be out of date, it's not 
> > critical.
> >
> > I can make it a "may" if you think "should" is too strong.
> 
> I don't care much either way. I think I'd prefer it more strongly for 
> the 'cite' attribute.

Well the spec says "If the absolute URL identified by the cite attribute 
is being shown to the user, or if any data derived from that URL is 
affecting the display", which basically means that for most browsers 
there's no issue here, no?


On Sat, 17 Jan 2009, Calogero Alex Baldacchino wrote:
> 
> I understand. Perhaps, if a main (more diffused) behaviour could be 
> isolated, it might be chosen to "normalize" newer UAs behaviours, while 
> possibly breaking fewer existing pages (the same eventually behaving 
> differently in different browsers). However, I guess this might require 
> a convergence between HTML and CSS specifications for this purpose (it 
> might rise an issue on consistence for @import rules, for instance, 
> which are in CSS scope).
> 
> I don't know if it may work something like establishing that a URL, in 
> this case, is resolved any times it is explicitly set (e.g. when the 
> document is parsed and when the "href" value changes), as if the 
> resources were immediately fetched (thus, not being affected by a 
> successive change in a <base>) but not constraining UAs to do so (an 
> inline style element might be treated as an external resource being yet 
> fetched, thus it would be about to associate it with a base URI being 
> valid at the moment the style was created and maintained valid until the 
> style content is explicitely changed). Though, I guess this should be 
> somehow consistent with existing UAs and pages (or, at least, with a 
> significant group).

I don't really follow. if you are proposing a change to the spec, could 
you elaborate on what exactly the change you propose is?

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