W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: DOM based API

From: Mark Baker <distobj@acm.org>
Date: Sun, 8 Jun 2008 22:22:49 -0400
Message-ID: <e9dffd640806081922x16c39dccq253fe43992c27e62@mail.gmail.com>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: public-geolocation@w3.org

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT