Re: Do we need the restrictions on the <base> element?

On 5 Jun 2007, at 17:24, Boris Zbarsky wrote:

>> But there is no law that says that global elements have to come  
>> physically before the others.
>
> True, if you're willing to break compat with all existing UAs and  
> existing content.  Is that desirable?

OK. I get your point about existing UAs. For instance, this would not  
work in existing browsers:

<head>
	<script src="...">
	<base href="http://a.org/">
	<title>...</title>
</head>

because the <base> will not have any effect on the <script> element.

However, the current spec will *also* break with existing UAs.  
Consider this markup (which I think conforms to the spec):

<head>
	<base href="a/">
	  <script>
		document.write("<base href='b/'>");
	</script>
	<script type="text/javascript">
		baseElem=document.getElementsByTagName("base").item(0);
		baseElem.setAttribute("href", "c/");
	</script>
	<title>...</title>
</head>

This will break with existing UAs for three reasons:

Firefox/Explorer/Opera (current versions) don't accept relative URLs  
in <base> (Safari does)
Firefox/Explorer don't respond to changes in the DOM. (Safari and  
Opera does)
All major browsers will use the *last* <base> while the spec says  
they should ignore all but the *first*.

So this is really a question of where to draw the line. How much of  
the old functionality should be kept in the spec? Since we are  
specifying things that may potentially last "forever", I think  
simplifications and modernizations like this are important. And how  
big will this problem actually be when HTML5 comes out?

Regarding existing content:

It would be interesting to know the extent of this problem. How many  
pages actually depend on different base hrefs inside the <head>? If  
this number is large, we should probably specify the de facto  
standard (your second option)  If it's very small we don't have a  
problem either way.

And, for the xml:base discussion, I think we need to know how many  
pages depend on different base hrefs in the <body>. If this is widely  
used we should probably have a mechanism to provide that.

NB! This is not only relevant to my suggestion. I think we need  
research on both to justify the *current decisions* made in the spec.

> Basically, I see two options:
>
> 1) <base> has to come before other things, we specify it nicely,  
> any document
>    where it _doesn't_ come before other things is non-conforming,  
> and UAs
>    handle such documents as they do right now

By "things" I assume you mean elements referring to URI's - not  
<title> or <meta>? I guess it would be safe to stick to the  
formulation in HTML4 which will also represent a simplification vs  
the current text:

The <base> element must occur "before any element that refers to an  
external source".

> 2) <base> can come after some content in conforming documents, and  
> we specify
>    the de-facto standard behavior: <base> only affects things that  
> are inserted
>    into the DOM after it has been parsed.

This is probably the one with the lowest risk of breaking things and  
easiest to understand. The text would be something like:

Only elements that occur after the <base> in the document will be  
affected by it.

But we loose the global nature of <base>, of course, because there  
may be parts of <head> that are not affected.

--
Henrik

Received on Wednesday, 6 June 2007 12:11:54 UTC