[whatwg] Issues concerning the <base> element and xml:base
ian at hixie.ch
Thu Jan 15 15:24:01 PST 2009
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.
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:
...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?)
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg