- From: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
- Date: Tue, 5 Jun 2007 12:39:15 +0200
- To: HTML WG <public-html@w3.org>
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