W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2007

Re: (MOB)HTML - Merge on browser HTML (was SDPML)

From: Tom Molesworth <tetra604@gmail.com>
Date: Thu, 25 Jan 2007 10:13:14 +0000
Message-ID: <6c93a9d90701250213w62bddd28n47d7d0e13ca386f1@mail.gmail.com>
To: "sunil vanmullem" <sunil.vanmullem@btopenworld.com>
Cc: www-talk@w3.org

Hi Sunil,

First, thank you for sharing the idea with the forum. The example is
certainly interesting, and could have some useful applications. I hope
you understand that any negative points raised are intended to help
you to refine the approach further and to target it appropriately,
rather than being personal attacks.

I've had a look at the example page, and I believe there's one obvious
issue with your proposed approach which will prevent it from becoming
the de-facto standard for web pages as you seem to be hoping:

It relies on Javascript.

There's no graceful fallback, there's no mechanism to show content to
people who are using noscript, restricted IE settings, lynx / w3m /
screen readers / built-in Nokia web browser. Assuming a fallback can
be implemented, this effectively means the work will have to be
duplicated, as with many Ajax approaches: once for the intended
client-side approach, and again for the server-side fallback. This may
not be a dealbreaker but should be taken into account as a potential

There's a 23 Kb script file that has to be loaded before anything
starts to happen. At dialup speeds, this exceeds the standard 4-second
page wait time -

You haven't made a convincing case for processing on the client side,
and heavily loaded sites aim to cache data as much as possible - as
you should know. Even the extra memory usage required to load PHP /
Java / Perl is something to be avoided if possible - better to have a
web accelerator such as Squid with ~1Mb footprint than ~64Mb of
scripting language that does nothing but "echo

You could argue that the static parts of the page can be cached
serverside and clientside, and explain how you'd go about that, rather
than making sweeping claims like "(MOB)HTML threatens app servers".
Most approaches nowadays are not strictly client-side or server-side
only, so "app server" as a term is something of an anachronism.

Numbers are more effective than unsupported assertions: instead of
"this in no way increases bandwidth", give some hard figures based on
real code. Your example page is 37 Kb in total, of which 203 bytes are
stylesheet content. Saving the generated result results in a 5Kb HTML
file, so even with the stylesheet added back in, that's about an order
of magnitude *smaller* for the static page.

Overall, I think there's plenty of potential in your idea for
intranets and other controlled projects, but I don't believe this is
suitable for open web exposure.

If you can construct an example which shows bandwidth, speed and/or
other advantages over the static approach, perhaps the idea might get
a better reception? I'd also recommend contrasting the pure-client
approach against pure-server or blended options, using a standard
framework such as Template::Toolkit or smarty. What does your approach
offer that is not already available in the alternatives?


Throwing around terms such as "revolutionary" is not going to impress
people unless backed up with facts and details. Your approach may have
a lot going for it, but the presentation is important - a good idea is
1% inspiration, 99% perspiration, as the saying goes.

Finally, putting some words IN CAPITALS is not a breach of email
etiquette, it serves to highlight the point in the same way *this
does* or _this does_, and is a consequence of using plain text.

best regards,

Received on Thursday, 25 January 2007 10:13:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:06 UTC