W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2006

[whatwg] The Module Tag

From: Douglas Crockford <douglas@crockford.com>
Date: Tue, 31 Oct 2006 08:45:53 -0800 (PST)
Message-ID: <20061031164553.15555.qmail@web31808.mail.mud.yahoo.com>
> > It requires no changes to JavaScript and a small, incremental change to HTML.
> > The proposal is here: http://json.org/module.html

> What you propose looks very similar to the Cross-document messaging already 
> included into the current draft:
> http://whatwg.org/specs/web-apps/current-work/#crossDocumentMessages

I am proposing the module tag instead. It is the first belated step toward 
giving HTML a compositing model.

> The principal difference between this and your proposal is that you insist 
> on the messages to be JSON. I rather agree with the current WHAT spec which
> defines just sending of strings back and forth without imposing more complex
> interpretation upon them.

JSON is a safe subset of JavaScript. It is meaningful in a JavaScsript context
(which is where we currently are). If we ever have a multilingual future (and I
hope that we do), JSON has demonstrated amazing interoperability.

> Also, the current WHAT spec reuses the event handling mechanism in contract
> to introducing an ad-hoc one with send() and receive() methods. DOM event
> handling alows events to be dispatched asynchronously, which fits various
> threading models implemented in browsers better.

I am a big fan of asynchronicity, but I don't think it is indicated in this
case. I want tighter temporal binding between the sender and the receiver
so that they can cooperate in event handling. Such patterns are complicated 
if event handling is also the medium of communication. I also want an 
exception raised on sending if there isn't a corresponding receiver. This is
an important indication of willingness and ability to cooperate.

Also I am worried about the event object itself. It is possible to implement
an event mechanism such that the event object is not itself a conduit for
capability leakage, but it is not required by the current draft.
Received on Tuesday, 31 October 2006 08:45:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:49 UTC