On Tue, 21 Aug 2007 19:43:05 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
* Simon Pieters wrote:
would be any kind of improvement. You would have to explain why they
need to be on Document rather than on a DocumentWithUsefulStuff inter-
face. Clearly adding them to Document would make implementers who do
not and do not plan to implement HTMLDocument anywhere at all unhappy
(important reasons being that they are poorly designed and depend on
not particularily common features like interactivity).
Indeed, I forgot to say this in my initial email. See:
http://www.w3.org/mid/[EMAIL PROTECTED]
Of course you would not require every DOM Core implementation to offer
interactivity.
Right.
Could you elaborate on how that clarifies your proposal?
I propose that some members of the HTMLDocument and HTMLElement interfaces
that are also useful for non-HTML documents and non-HTML elements are
moved either to Document and Element or to DocumentWithUsefulStuff and
ElementWithUsefulStuff interfaces (possibly with better names). If we go
with the latter option, DOM Core implementations would be able to either
not implement those interfaces or implement them on Document and Element
objects, probably using binding-specific methods.
For example, in Java you cannot implement just a subset of an interface,
you have to implement everything, even if it's just a stub that raises
a "not supported" exception. Doing that, or, alternatively, having two
versions of the interface so avoid the problem, seems highly likely to
make those implementers and indeed their implementation's users unhappy.
I don't quite follow here.
It also does not explain why your proposal is the best one to address
whatever problem is to be solved here (as I said, I don't quite see the
problem).
HTML5 says that all Document objects must implement HTMLDocument and other
supported interfaces. I presume it says so in order to dodge the question
of when to implement which interface, in addition to making e.g.
document.cookie usable in SVG documents.
While being able to use e.g. document.cookie in SVG documents is useful,
implementing all supported interfaces on all Document objects might not be
the best approach to do so (see the initial email). I have put forward two
alternative approaches to reach the same goal. I furthermore propose to do
the same with some members of the HTMLElement interface.
--
Simon Pieters