Re: DOM based API

On Fri, Jun 6, 2008 at 3:08 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> I disagree that this reduces the learning curve or makes things easier for
> developers. First, accessing parts of a generic DOM document with known
> names and attributes doesn't really mean "no new API", it just replaces a
> real API with a string-based pseudo-API.

I've never heard of a markup language referred to as a "string-based
pseudo-API " before 8-)  But sure, there's obviously going to be
*something* new to learn.

The two options seem to be;

1.  Define a custom API
2.  Reuse the DOM, and define a custom markup language

> I particularly disagree as to DOM mutation events as a change notification
> mechanism. DOM mutation events are confusing and not widely used by authors,
> and they have terrible semantics both for correct implementation and for
> ease of authoring. For example, many seemingly primitive DOM operations have
> to dispatch mutation events partway through and so may only partially
> succeed!

Yes, I'm aware of that.  I think the modified-cdata event was wrong
bundled up as a mutation event, and should have been separate.
Perhaps we can create a new event that doesn't come with the mutation
baggage.

But these kind of issues are inevitable any time reuse is considered.
It's nice to be able to start with a clean state (a custom API), but
as we all know as Web developers, there's considerable value in
reusing already deployed technologies, warts and all.

> For specific kinds of data supported natively by the UA, we should use
> native APIs, not generic APIs with a document structure convention layered
> on top.

What do you mean by "native"?

Mark.

Received on Monday, 9 June 2008 02:23:26 UTC