- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 21 Aug 2007 17:59:08 +0200
- To: liorean <liorean@gmail.com>, "HTML WG" <public-html@w3.org>, "Web APIs WG (public)" <public-webapi@w3.org>
On Tue, 21 Aug 2007 17:13:55 +0200, liorean <liorean@gmail.com> wrote: > > On 21/08/07, Simon Pieters <simonp@opera.com> wrote: >> We'd rather have the members of HTMLDocument that are useful for all >> types >> of documents to be moved to the Document interface. This would probably >> be: >> >> * location >> * URL (also present in SVGDocument) >> * domain (also present in SVGDocument) >> * referrer (also present in SVGDocument) >> * cookie >> * lastModified >> * getElementsByClassName >> * innerHTML >> * activeElement >> * hasFocus >> * getSelection > > How about document.title? What document.title does is different for HTML and SVG for instance... and it's not clear to me what it's supposed to do on arbitrary document types. How would you define it? Isn't it better to let each language that wants to use document.title define how it's supposed to work? >> Furthermore, it might make sense to move the following members from >> HTMLElement to the Element interface: >> >> * getElementsByClassName > > Does this make sense on Element? I mean, the class attribute and it's > semantics are HTML/XHTML specific. getElementsByClassName returns a nodelist of the descendant elements with the specified classes. You can have HTML elements, SVG elements, MathML elements, or other elements that can have classes (as defined by some spec), as descendants of any element. So yes, I think it makes sense. -- Simon Pieters Opera Software
Received on Tuesday, 21 August 2007 15:59:21 UTC