- From: Geoffrey Sneddon <foolistbar@googlemail.com>
- Date: Sun, 11 Feb 2007 15:14:01 +0000
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!)
Received on Sunday, 11 February 2007 07:14:01 UTC