Re: Implementing HTMLDocument on all Documents (detailed review of the DOM)

> On Tue, 21 Aug 2007 17:13:55 +0200, liorean <liorean@gmail.com> wrote:
> > How about document.title?

On 21/08/07, Simon Pieters <simonp@opera.com> wrote:
> 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?

I would define it as a per default read-write string property of the
document, affecting the window title of whatever document is being
displayed. It doesn't make sense to make it default to read-only, as
it's more likely developers want to set the window title in
applications that do not have markup for doing that than the other way
around. Applications such as HTML and SVG could extend it further by
specifying side effects on the DOM, specify that DOM manipulations
affects it, or making it readonly (either through silent failure or
through the exceptions system).

> >> 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.

If doing this, I think it's make sense to at the same time define a
mechansim such as a new xml:class attribute, so that a generic method
of setting classes exists for all elements independent of application.
That would also make it sensible to add Element.className to DOM Core.
-- 
David "liorean" Andersson

Received on Tuesday, 21 August 2007 16:28:11 UTC