Signin
IHTML: Interactive HTML

Of late, I have been dreaming about IHTML.  IHTML is, as I define it, HTML for highly interactive web applications.  It defines new high-level tags for defining new interactive behaviors and for replacing all those custom DHTML+CSS+JavaScript-based widgets with 'native' components.  It also supports weblets, client-side web applications that extends browsers.

To make IHTML a reality, I have embedded Python and PythonCOM into Internet Explorer.  That was hard, but the hard part is over and the fun part begins.  Beyond replacing IHTML tags with native parts on the fly, I am playing with the idea of Persistent Page which are web pages with persistance and mutates over its lifetime: changes you make on the page are permanent.  Sounds weird, but is no different from writing on your newspaper.  The kicker is that these pages are smart and task-oriented.  Fun stuff.

In case you are wondering, I have little interest in what W3C might say about IHTML.

Comments
Are you aware of XUL?

"It defines new high-level tags for defining new interactive behaviors and for replacing all those custom DHTML+CSS+JavaScript-based widgets with 'native' components."

Am I aware of XUL? I implemented three XUL players so far, one native, one for Swing, and one for SWT. I am not talking about replacing HTML, but extending it with new tags. I am not thinking of Zeepe either.
OK so I guess you're aware of XUL :). Did the native XUL player work in IE? Also is the SWT implementation available anywhere on the web?

All the XUL except the SWT one was for a client. I didn't release the SWT one because I replaced XUL with a language of my own in mid-stride. XUL sucks frankly, hackish at best. Anyway, I got sidetracked and it remains in unreleasable state. If you are interested in XUL for SWT, check out Luxor on SourceForge. I think Luxor is getting too complex, but it should still be fun to play with. Jelly is interesting, but it needs to be redesigned with the lessons learned from the current version. I like the ideas behind XForms, but not the execution. I am also concerned about its relationship with XHTML.
I'm not too keen on the RDF aspect of XUL - it seems the only way to pass information into XUL; i'm suprised there's no support for just using JavaScript or XML.

James, I would reduce the need to use namespace prefixes. Application model namespace don't have to be match XML namespaces. XML namespaces exists to remove ambiguity, but if the ambiguity can be controlled by the application, there is no need to specify the prefix beyond 'import'.

Comment has been disabled for this post.