- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 11 Jul 2007 12:06:20 +0200
- To: public-html <public-html@w3.org>
(This is part of my detailed review of the Document Object Model section.) I tested document.title for a bit (also did some testing in the live DOM viewer without recording it...): http://simon.html5.org/test/html/dom/interfaces/HTMLDocument/title/ This is how it works AFAICT: IE7: "A title element" is either created by the parser or by setting document.title. There is always at least one "a title element". "A title element" cannot have any child nodes, but its associated text is available e.g. with the .text or .innerHTML attributes. On getting document.title, if there is "a title element" part of the document that doesn't have a <body> element ancestor, then return the first such element's associated text. Otherwise return the empty string. On setting document.title, if there is "a title element" part of the document that doesn't have a <body> element ancestor, then associate the new text with that element. Otherwise, create a new "a title element" and associate the new text with it, and append it to the first <head> element in the document that doesn't have a <body> element ancestor (which fails if there isn't one). Firefox: There is no "the title element". The parser sets document.title when it sees a title element. The value is the element's .textContent. Changes to the DOM doesn't affect getting document.title. Setting document.title doesn't affect the DOM. Safari: There is no "the title element". The parser sets document.title when it sees a title element. The value is the element's child text nodes and CDATA nodes. Changes to the DOM doesn't affect getting document.title. Setting document.title doesn't affect the DOM. Opera: "The title element" is the first <title> element that is part of the document, if there is one, and null otherwise. On getting document.title, if "the title element" is not null, then return it's .textContent, otherwise return the empty string. On setting document.title, if "the title element" is not null, then set it's .textContent to the new value. Otherwise do nothing. All are quite different from each other and quite different from the spec too. In particular, the spec restricts what is "the title element" to html:root>head:first-of-type>title:first-of-type (in the HTML namespace), while none of the abovementioned browsers have that restriction. Also, the spec says to only use the child text and CDATA nodes (like Safari) while Firefox and Opera use .textContent. If we want to be more like IE, then I'd suggest the following spec text: The head element of a document is the first head element that doesn't have a body element ancestor. The title element of a document is the first title element that doesn't have a body element ancestor. The title attribute must, on getting, run the following algorithm: 1. If the root element is an svg element in the "http://www.w3.org/2000/svg" namespace, and the user agent supports SVG, then the getter must return the value that would have been returned by the DOM attribute of the same name on the SVGDocument interface. 2. Otherwise, it must return the .textContent of the title element, or the empty string if the title element is null. On setting, the following algorithm must be run: 1. If the root element is an svg element in the "http://www.w3.org/2000/svg" namespace, and the user agent supports SVG, then the setter must defer to the setter for the DOM attribute of the same name on the SVGDocument interface. Stop the algorithm here. 2. If the title element is null, then the following sub-algorithm must be run: 1. If the head element is null, then then the attribute must do nothing. Stop the overall algorithm here. 2. Otherwise, a new title element must be created and appended to the head element. 3. The children of the title element (if any) must all be removed. 4. A single Text node whose data is the new value being assigned must be appended to the title element. After that, the spec says: The title attribute on the HTMLDocument interface should shadow the attribute of the same name on the SVGDocument interface when the user agent supports both HTML and SVG. Don't the getting and setting algorithms already cover that? If so, I'd suggest dropping this paragraph. -- Simon Pieters Opera Software
Received on Wednesday, 11 July 2007 10:06:33 UTC