[whatwg] Expected behaviour when a <base> is within an innerHTML fragment

Sun Feb 11 07:14:01 PST 2007

On 11 Feb 2007, at 11:37, Jorgen Horstink wrote:
> On Feb 11, 2007, at 12:01 PM, Geoffrey Sneddon wrote:
>
>> To take this from a discussion last month on atom-syntax:
>>
>> What is meant to happen if you set innerHTML of a <div> where the  
>> set value has both a <base> and an <a>?
>>
>
> first of all the <base> element can only be inserted in HTML  
> documents.

That's perfectly fine… If you have control over the content being  
inserted.

> The spec states that there can only be one <base> element. The  
> <base> element must  be used before any elements that use relative  
> URI's.

Sure, there MUST only be one, and in <head>, but as the parsing  
section dictates, if there is one in <body> it gets moved into  
<head>. It also, as stands, leaves it possible for the parser to  
place multiple <base> elements in <head>.

>
> If the insertion mode is "in body" handle the token as follows:
>       A start tag token whose tag name is one of: "base", "link",  
> "meta", "title"
>       Parse error. Process the token as if the insertion mode had  
> been "in head". [1]
>
> So inserting a <base> element in the body results in a parse error.
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/#how-to0

As Anne has already said, the spec says how to deal with parse errors  
(they aren't fatal errors, as parsing continues as normal). Also, as  
what you quote says, the element gets inserted "in head".

The point is whether it:
	a) Gets inserted into the <head>, and changes all the links in the  
document.
	b) Appears in some magic place, and changes the links in the HTML  
fragment.
	c) Gets ignored.

I'm personally in favour of b), as using the normal parsing rules  
(placing it in <head>) may well end up changing more than what is  
wanted. I'll do some testing of current implementations later.

- Geoffrey Sneddon

(I accidentally sent this to just Jorgen! Sorry!)