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

On 5 Jun 2007, at 08:27, Boris Zbarsky wrote:

>>> Doing that is not compatible with the way <script> elements need  
>>> to be handled.  So it's not an option.
>> This seems to me a rather artificial limitation.
>
> Welcome to the world of document.write.
>
>> Isn't it possible to do a preparatory parse, just to determine the  
>> base (and the charset) and then reiterate and do the actual work -  
>> parsing text, downloading/starting scripts etc?
>
> If you allow <base> anywhere, it can be dynamically inserted using  
> document.write, for example...
>
>> I think UA's have to do this anyway in order to support existing  
>> content.
>
> Right now UAs effectively allow different content in the document  
> to have different base URIs at different times. E.g. if you have a  
> <base> tag after some <script> tags, those script tags have one  
> base URI, while things after the <base> have a different base URI.   
> It's pretty confusing behavior, really.  And relied on by pages,  
> for what it's worth.

What we're after is to define the <base> element as a global element  
whose content affect the entire document, including the <head> itself.

The following restrictions follow naturally:

- There can only be one <base> element
- The <base> should be inside the <head> element.

But there is no law that says that global elements have to come  
physically before the others. This is a question of communication and  
I think the global nature of this element is better communicated by  
stating it explicitly in the spec than indirectly by means of  
syntactical definitions. Currently the spec only mentions that <head>  
contains "metadata elements". Maybe this should be explicated a bit  
in the <head> and its children.

If we remove the sequencing restrictions and instead state the global  
nature of <base> and <meta charset=...> explicitly, the spec will be  
easier to understand and less ambiguous. We will also remove some  
unnecessary error situations.

And there will be no conflict with the semantics of script execution.  
The preparatory parse suggested previously will just represent an  
optimization of the UA in order to avoid unnecessary fetches.

--
Henrik

Received on Tuesday, 5 June 2007 10:39:37 UTC