W3C decided to reincarnate HTML development

W3C decided to reincarnate HTML development.

Phylosophical difference between HTML and XHTML can be demonstraed by the fact that tag <html> is optional in HTML and is not in XHTML. By definition of XML (XHTML):

Definition: A data object is an XML document if it is well-formed, as defined in this specification. In addition, the XML document is valid if it meets certain further constraints.

What means that if UA (user agent, browser) can deal with loading XHTML document only when it receives closing </html> and everything inside is valid. To be short: any partial markup is not XHTML by definition and can be interpretted as such.

Freedom or liberty?

We are getting tons of spam on our email addresses and in blogs. We all get used to it. Click on “Delete this e-mail message” button became one of our reflexes…

Coin that has “Freedom of speech” on one side has many dirty things written on other side.

Just got one of such today:

Message started as: “I hate ( name of president of the country on the other side of the Earth ) … ”
has link to site (selling something) in domain .us (USA). It has email address (fake one) from one of public e-mail servers in domain .ru (Russia). And it was sent from IP that belongs to China Telecom address range. (Machiavelli, where are you?)

This is not a spam anymore. This is provocation.

My message is not about particular countries (this stuff could come from anywhere) but about the whole system. We shall do something with this. Freedom or liberty? that is the question.

HTMLayout. Success story.

Here is a success story of one of our customers. Some goverment agency in some country.

Migrating from IE control to HTMLAYOUT


We have a suite of products deployed in multiple geographical locations to about 150 clients. The suite is implemented in Law Enforcement Agencies to leverage the use of technology in ensuring the safety of our communities. The product is taking advantage of HTML to render rich User Interface (UI) content. HTML and CSS provide flexibility in the implementation of the user interface, while being extremely user friendly. Most users are familiar with browsing the internet, thus comfortable with the concepts of ‘clicking’, ‘hyperlinks’, and basic control behaviors.

Our product is rendering its user interface through Microsoft Internet Explorer controls with Microsoft Visual Basic to handle events and data manipulation. With the advent of new versions of Internet Explorer, we are anticipating a multitude of problems in rendering the User Interface. The solution is to find a third party control capable of rendering the same HTML user interface while requiring a minimum of rewriting of the existing html code base.


Our user interface is a transformation of the data retrieved from the database into HTML by using XML/XSLT transformation. We have a variety of XSLT documents that render the user interface. By implementing HtmLayout into our legacy products, we are able to continue rendering the same UI while making a minimum of changes to the XSLT. Any discrepancy in the usability is minimum and unnoticed by our client base.

HtmLayout is straight forward in its implementation and provides a number of valuable advanced capabilities. Most of the standard HTML and CSS code is portable from IE to HtmLayout. With ‘Behaviors’, it is easy to link the HTML events to code in Visual Basic. Behaviors are also used to enhance the standard functionality of HtmLayout.

HtmLayout is bringing stability into the User Interface as it is not depending on Microsoft Internet Explorer model. HtmLayout ensures User Interface consistency throughout our products.

Why HtmLayout:
• Ease of use
• Ease of migration from IE
• Support standard HTML and CSS
• Minimum investment in conversion of HTML
• Implementation of custom ‘behaviors’
• No scripting (vbscript/javascript), fewer technologies involved = fewer defects
• Simplify pages, thus reducing risk of defects
• Robust handling of messages between HTML and VB
• Responsive support team

Delegates in JavaScript. Now with parameters.

Here is an extended delegate function:

  function delegate( that, thatMethod )
    if(arguments.length > 2)
      var _params = []; 
      for(var n = 2; n < arguments.length; ++n) _params.push(arguments[n]);
      return function() { return thatMethod.apply(that,_params); }
      return function() { return thatMethod.call(that); }

And here is an example. Note that obj.method now accepts additional parameter p

  var obj =
    name: "someName",
    method: function (p ) { alert( this.name + ":" + p );  }

  function testIt()
    window.setTimeout( delegate( obj, obj.method, "parameter!" ), 1000 );

Example of the delegate is delegate-test.

Note: this is so called parametrized delegate - parameters defined at the point of construction of the delegate - in delegate() call per se.

If you need delegate that will be inoked with parameters supplied by the caller you should use this one:

  function delegate_cp( that, thatMethod )
      return function() { return thatMethod.apply(that,arguments); }

So caller will call it as:

  var d1 = delegate_cp( obj, obj.method );
  d1( param1, param2 ); /* parameters for the delegate
           call provided at the point of invocation. */

Java GUI executable without JRE… Are you kidding me?

Three years ago (or so) I did experimental project named J-SMILE to prove that it is possible.

Main idea of it is simple – to create as small as possible Java (Virtual Machine) that can be attached to compiled Java bytecode (.class files).

Physically J-SMILE VM is an .exe file of size 200k. These 200k include:

  • Waba VM extended to support Java 1.2 language specification pretty much in full – green threads, copying GC, float support.

  • Set of native GUI functions (Graphics, Font, Window, etc).

  • Special class loader capable to load class files from trailer – .class files packaged and attached to the end of the exe file of J-SMILE VM.

I have designed mini set of GUI primitives (Widgets) like listbox, editbox, etc. and created this simple demo application:

This demo application is about 400k = 200k of J-SMILE VM + all classes needed to run it ( mini version of java.lang.* and smile.* ). Source code of class files used in this application is here.

No JRE/VM version checks, no installation step needed, self-sufficient… Cool, eh?

And now goes the question: why all Java GUI solutions so monstrous and heavy?
Premature Generalization, eh? Got Deja Vu reading excellent Eric Gunnerson’s C# Compendium.