Mozilla, Opera Form Group to Develop Web App Specs

An anonymous reader writes "MozillaZine is reporting that the Mozilla Foundation and Opera Software have formed a working group to develop specifications for Web applications. The new Web Hypertext Application Technology Working Group is working on specs for Web Forms 2.0, Web Apps 1.0 and Web Controls 1.0, among others. This is being done outside of the W3C, with the hope of getting a viable alternative to Longhorn's XAML available soon. Another reason for working outside the W3C could be the rift between Mozilla/Opera and other W3C members over what technologies Web applications solutions such be based on: Mozilla/Opera favour a backwards-compatible HTML-based standard, others are looking towards to XForms and SVG. It will be interesting to see if any other browser developers jump on board WHATWG." This story builds on our recent story concerning the group.

Comments

Curl?

[Anonymous Coward]

I wish they'd look at "The Curl Project" that was started at MIT as part of the same DARPA grant that started the W3C.

Their whitepaper describes a cool S-expression based language (kinda like a blend of HTML and Scheme) that elegantly merges the simplicity of markup languages with the power/complexity of lisp.

We do want this in standards body at some point

[hixie]

The article is misleading. There isn't a "rift" between Mozilla/Opera and the W3C, indeed Mozilla and Opera are very active members of the W3C and were both present and actively participating in the recent Web Applications workshop.

At the moment this group is basically innovating extensions to HTML, for which you need a lot more flexibility than a standards organisation would provide. Once the proposals have reached a mature point we intend to submit these proposals to a standards organisation (whether it is W3C, IETF, ECMA, or another is yet to be determined, but note that the W3C have a policy that says we would not be allowed to say if we were planning on submitting this work to the W3C).

I expect the W3C to start work on the non-backwards-compatible alternatives to WHATWG work, such as creating an XForms/SVG "uberspec" or a new language or something, and when that happens I'm sure Opera and Mozilla will want to be taking part.

All of which is explained on http://www.whatwg.org/, but since when has research had anything to do with journalism, eh? ;-)

Re:No SVG?

[MadMoose]

Certain parts of SVG - ie. all the cool vector graphics bits - will probably go into Mozilla once it's ready and if it doesn't impact the rest of Mozilla too much speedwise and footprintwise

Other parts of SVG will (probably/hopefully) never get into Mozilla. Like raw socket support: http://www.w3.org/TR/SVG12/#rawsocket

Ian Hickson mentions other crappy things about SVG in his blog (which I'll be nice and not link to from /. - learn to google)

Re:Why WG?

[hixie]

Actually Microsoft was one of the few groups in favour of work like this at the recent workshop (they didn't want scripting involved, but apart from that were in favour with extending HTML rather than going down the XForms or other new language route).

Re:Why WG?

[markbirbeck]

> WHAT WG was created not because a specific developer wanted to do it's own thing,
> but because the majority of W3C members aren't browser developers. They're plug-in developers.
> Some people within the W3C have even stated that the browser is dead. This kind of
> environment is openly hostile to the further development of existing browser-based standards.

At the recent Web Applications workshop I did openly say that the "browser is dead". I am not, however "within the W3C", although I am an 'invited expert' on a couple of Working Groups. (And I don't recall anyone else using this phrase.)

My position is simply that to build powerful applications that take advantage of internet technologies - but don't require us to constantly 'drop-down' into C++ or Java - requires a programming environment more powerful than current browsers support. Sure, browsers are great places to save a list of favourites, and most do a pretty good job of rendering HTML, but if we have to wait a few years every time a new mark-up language is bought out - and confusion reigns in the meantime whilst we all try to second guess which browser company will implement what - then there has to be something wrong with the architecture.

So, my view is that the days of the 'monolithic browser' are numbered; it takes too long to update, lacks basic features that any application really should have, and leaves the rest of us at the mercy of a few companies who are more or less radical and 'open', depending on the day of the week.

Of course, it's none of my business whether browser vendors want to create new standards for HTML, but the companies I deal with don't need any more HTML - they've got plenty thanks. What they do need though, is higher-level languages that do more, make application-building easier and quicker, and still deploy as easily as HTML. And for the record, I've been arguing since before XForms became a Full Rec that XForms is an ideal foundation for this.

My proposal at the workshop was for an application environment that allowed these new types of apps to be built, in an open standards/open source way, by defining a 'virtual machine'.

And if we still need somewhere to save our favourites, we can easily use such a VM to build a 'traditional' web browser, but genuinely based on standards.

Re:Konqueror

[scorp1us]

It's not called Konqueror, it's called KJSEmbed, and is shipped with kde3.2. One of the components is kjscmd, which gives general javascripting to KDE. This means that you can access K* and Q* classes and write programs in javascript. It also supports DCOP so it is an easy RAD (rapid application development) and integration tool.

Couple this with Factory.loadui(uifile) call, where you can load a QtDesigner .ui file (a XML dialog) created at design time and you have one fast RAD tool.

// create variables that map to the widgets
var dlg=Factory.loadui("square.ui");
var okButton = dlg.child("buttonOk");
var calcButton = dlg.child("buttonCalc");
var xValLineEdit = dlg.child("xVal");

function calc() {
alert( xValLineEdit*XValLineEdit );
}
dlg.connect(calcButton, "clicked()", this, "calc");
dlg.connect(okButton, "clicked()", this, "exit");
dlg.show();
application.exec();

You can of course make dialogs on the fly too:

var popup=new QVBox();
var buttons= new Array;
for (var i=0; i<10; i++){
buttons[i]=new QToolButton(hbox);
buttons[i].text="Button "+i;
dlg.connect(buttons[i], "clicked()", this, "clicked_"+i);
}

function clicked_1 { alert("You clicked Button 1")}
function clicked_2 { alert("You clicked Button 2")}
....

popup.show();
application.exec();
}

And there you have it. I spent 10 minutes typing this email and write 2 (albeiet simple) scripts.