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

Why WG?

[peterdaly]

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. The only logical course of action in this situation would be for the various browser developers to form their own standards group, which is what happened.

I am no w3c expert by any means, but that's an interesting statement and strong point. Too bad Microsoft won't jump ship as well, as I don't feel Opera and Mozilla have the marketshare and clout to pull this off in terms of setting defacto standards.

-Pete

Re:Why WG?

[Anonymous Coward]

Parent wrote: Some people within the W3C have even stated that the browser is dead.

The W3C has been working on this - the "creation of a new language designed specifically for Internet computing" - since their original darpa grant in in 1995. Tim-Berners Lee's web site says he still acts as an advisor to the company that's continuing that project.

Re:Why WG?

[vrmlguy]

From what I've read about Longhorn, I suspect that Microsoft is one of the groups opposed to "a backwards-compatible HTML-based standard". They want to replace the browser with new tools built into Longhorn that only they control. See any of these Google links for more details.

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:Why WG?

[pldms]

I am no w3c expert by any means, but that's an interesting statement and strong point.

Too right it is. I don't recognise that characterisation of the W3C at all. True, they are concerned with the web as a whole, not just browsers, but it difficult to explain announcements like annotea moves to mozilla if the W3C is hostile to browsers.

Browser companies take part in W3C working groups, and provide valuable input. W3C even develops its own browser. And, a minor point I confess, W3C presentations normally use HTML in a browser.

What I see this group doing is providing the basis for W3C work. Working groups tend to be less successful if there isn't preceding work to serve as a basis. The W3C are attempting to remedy this (incubation groups iirc) but in the meantime I think this is interesting project.

Re:Why WG?

[hixie]

So instead of a "monolithic browser" you want a "monolithic runtime" that takes too long to update, lacks basic features, and leaves the rest of you at the mercy of a few companies who are more or less radical and "open", depending on the day of the week?

I really don't understand the difference between your VM idea and the browser of today, except that you would use XForms as the core instead of HTML. Different tags, same problems.

The more I read your VM proposal the less I understand it, unfortunately. I guess I need to see a more formal proposal to really understand what it means.

Re:Why WG?

[Bedouin X]

My God you totally read my mind. This sounds like going through a whole lot of trouble to replicate the same problems. I guess the advantage would be that it starts out supporting a core level of technologies that current browsers don't, but I fail to see how it would avoid a situation analagous to the current one with respect to keeping everyone current with new developments over time.

Re:Why WG?

[markbirbeck]

> So if you say xforms should be the base for future web apps instead of html ...

Well, firstly it's obvious that HTML is not an application building language, so I assume you mean HTML plus a very large dose of script.

> ... you've got to explain why that is. Why is that?

Because it *doesn't* rely on script to get some big things done! Instead it has a large number of back-end features that are available via simple mark-up.

You need to validate a document before submitting? Easy in XForms - just add a schema to the model - not so easy in Mozilla, Opera or IE! You want to create dependencies between nodes in a DOM tree? Perhaps you want an event if node A goes higher than node B, or you want node C to be the sum of all node Ds. Easy in XForms - more spaghetti in Mozilla, Opera and IE.

How about preventing submission if some required value is missing. Easy peasy in XForms. Yet more script in M, O and IE, and which needs to be updated and maintained for every new required value you want to check.

The list goes on; we have platform-independent help, we can define hints with one tag (how many times have you written mouseovers in script?), and new CSS pseudo-classes that allow a control to appear differently if the data is invalid, to name just a few of the many things XForms gives us.

> Html has momentum, xforms doesn't.

XHTML 2.0 includes XForms.

Konqueror

[Anonymous Coward]

I think that i would be if better if konqueror/khtml people joined the group, as for
instance khtml is representing safari too.

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.

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.

HTML is not for web apps...

[D-Cypell]

As more and more business move to 'web-deployed' business software I predict a big departure from HTML for web applications.

Joe public user doesnt want to know about "You cant use drag and drop anymore, the browser doesnt support it".

There will be a migration to technologies like Flash/Actionscript where you can get the rich client experience in the browser. Users will demand this, execs will demand this and development companies/open source groups will provide this.

Having said that, I have looked at XAML and there doesnt seem to be a reason why it could not be interpreted to build a flash GUI. Perhaps this is the true of this effort too, but to include hypertext in the title indicates a degress of shortsightedness IMHO.

Re:HTML is not for web apps...

[hixie]

Drag and drop is indeed one of the things that I think HTML should allow. We'll probably be extending HTML to allow for drag and drop in WHATWG.

Anything else? :-)

Re:HTML is not for web apps...

[jjohnson]

We've had the opportunity and the ability to deliver "rich client experience in the browser" for five years (Flash, Java, DHTML, ActiveX), and users/execs haven't demanded it yet. Why do you think anything will change?

The killer app of the web is distributed services, not interfaces. Porn, Ebay, Amazon, online banking and bill payment, media channels, not Office knockoffs or Flash games. The need for richer client experiences is in developer's minds, not users.

Re:HTML is not for web apps...

[hixie]

I agree that on the long term we need a set of APIs on par with an OS, but designed so that they work cross-platform.

That's what Microsoft are doing with Longhorn, except that that is Windows-only. The Gnome people will probably come up with stuff of their own, which would be more cross-platform.

Sun did this years ago with Java. Why wasn't it successful?

The problem is that writing a spec for this stuff is insanely hard. To do this for a sophisticated application platform on par with, say, Longhorn, is simply unfeasible, IMHO. Notice how WINE has to reverse engineer Windows to determine how it should work -- the Win32 APIs aren't good enough to know exactly how to do it. Or how the various Java clones have to reverse engineer Sun's Java to get interoperability, the Java API documentation isn't good enough either. Heck DHTML is already complicated enough that we have to reverse engineer IE to work out how it should work, and that is orders of magnitude easier than an OS-level API set would be.

Then again, the W3C are likely to be working on such an API as a result of this workshop, and I'm sure Mozilla and Opera will be taking part in that work if it happens. That doesn't stop there being a need, in the meantime, for a solution for those people writing applications this year, in HTML.

(Slashdot itself is an example of such an application. Would you rather use a standalone Slashdot application instead of using a Web browser to read and post on Slashdot?)

Web Standards are USER defined.

[Whitecloud]

This is being done outside of the W3C, with the hope of getting a viable alternative to Longhorn's XAML available soon

Okay, Microsoft are trying to develop some standards. If history says anything about how the web has evolved its that the users define the standard. If it works, we use it. XML works. Macromedias Flash app is a defacto standard, created outside the W3C. If it works, we use it. Suns Java is pretty popular too. A lot of stuff is created outside the W3C, it all works, if its good we install it. simple really.

This is great news.

[gusnz]

An alliance is exactly what they should be doing. Well, ideally it would be under the auspices of the W3C, but it's a great start.

The reason is XAML. Microsoft has basically thrown in the towel with its (X)HTML rendering engine (the last release, IE6, was three years ago, and the differences from IE5.5 were not huge -- it still doesn't support stuff like translucent PNGs and much of CSS2). When Longhorn is released, expect a massive push towards the use of their proprietry XAML for web application deployment tied with their .NET development tools.

If Mozilla, Opera and hopefully Safari (which shares a few key developers with Mozilla and is implementing the Mozilla XUL box model in places) can push open standards and hopefully get a combined ~20-30% desktop share in the next 5 years before Longhorn is released and becomes semi-ubiquitous on the desktop, they'll be a large thorn in MS's side. Major businesses won't be able to ignore them, and with their focus on backwards-compatible specifications that expand upon existing CSS/JS/DOM technology and degrade well in older browsers (unlike XAML), they'll be the new default for client-side developers.

So start pushing those copies of Firefox onto friends' computers once v0.9 is released in a week or so with its auto-update notification. The more people who are aware that "web browser" does not equal "the blue 'e' icon", the better...

Failure forseen.

[deragon]

Mozilla and Opera creating new unoffical standards? If IE does not implement them, they will be simply ignored. I cannot forsee business implementing web services designed for these standards which will only be working for Mozilla and Opera users. What is the market share for the two? 5%?

Its time for goverments to step in and force standards. The Internet must remain open and interoperability is essential.

Re:Failure forseen.

[hixie]

How would goverments "force standards"? If I want to write a Web browser that doesn't support HTML, why shouldn't I? Are you saying goverments should make Flash illegal?

I agree that if IE doesn't implement new standards, then they will just be ignored. However, the WHATWG things are designed to be easily implemented using HTCs so in theory you can still use them with IE6 once we have some non-binary HTCs written to support them. How well that will go down with authors has yet to be seen.

They need Google

[tdvaughan]

Google would be a hugely useful partner in this effort. If they implemented future versions of GMail according to these standards rather than XAML/Avalon their dominance in the internet would make the difference between success and getting steamrollered by MS when Longhorn comes out.

XAML

[kwench]

I had a quick look at XAML and it looked quite straightforward and simple.

So... besides XAML coming from Micro$oft and aiming at being yet another WWW-defacto-standard, what's bad with it?

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:XAML parent is flamebait?)

[SenseiLeNoir]

Smells of troll?

But Mozilla has been VERY strict at implementing standards, and following W3C published standards. In fact its central and core to the organisation.

The introduction of Mozilla (and to an extent Opera) was instrumental in W3C ditichign its own browser efforts, as they felt that Mozilla's support for the standards was good enough to use as a reference browser.

Mozilla DOES extend some of the spec especially in CSS. This is allowed by the w3c, provided they are labelled as extesions (Mozilla uses the _moz prefix). And as some of these extenstions are incorporated into appropriate spec (CSS3 and opacity for example), Mozilla deprecates the extensions and provide support for the spec.

What the W3c frowns upon is not the addition of spec, but breaking exisiting spec. If a browser does not implement a spec, it should grafefully degrade. Mozilla does that well. Bugs not withstanding, Mozilla by feature does NOT break exisitng standards to be incompatible with standards developed pages.

Please explain WHAT you mean by Mozillas support of w3c is less than rosy. I am sure many others would like to know too.

Re:No SVG?

[hixie]

No, it doesn't mean SVG won't be supported. SVG 1.0 is just the thing for vector graphics, and it fits right into the HTML world if you use XBL, for instance. (Although admittedly that won't be backwards compatible and won't work in IE!)

Mozilla already supports a bunch of SVG (a pretty useful 20%, last I heard -- and they're working on the ever popular Gradients as we speak). Safari and Opera don't do SVG yet, but at least at Opera it is something we are looking at doing. (It's very popular with mobile vendors, and, well, they are our main customers, so...)

Just what the Wild Wild Web Needs Now

[l0ungeb0y]

"It will be interesting to see if any other browser developers jump on board WHATWG."

I think "WTF" would be a more appropriate acronym.
And we can all be safe to say that we wont be seeing IE join in on Opera and Mozilla's pillow casing party.

Personally, this entire little development sounds like a waste of resources that could be better spent on tuning and promoting their products. Seeing how widely adopted Mozilla's XUL architecture is, I think the Mozilla group would be better off getting Firefox up to speed and getting the rest of their projects in order before running about trying to cop some moves here.

That's not to say that I don't support Mozilla and Opera but, being a Web Developer for the last 6 years and a Internet Services Architect for the last 3, I can tell you right now that the last thing both Web Developers and Browser Developers need are more languages and competing standards. We are at a point of language saturation as never before and most these new languages are aimed at online services. While this may seem to be a great thing because choice is generally good, we have too many choices and most developers I know can only get 2-3 languages down to an expert level. So this development would most likely be ignored on a professional inplementation level while more standardized and familiar languages/feature sets would be used. In the end, it would most likely be a waste of time and resources for both Mozilla and Opera who should focus (IMO) on getting DOM Level 3/XSLT/CSS/SVG upto snuff and better integrated with the existing standards before going off on their own.

Case in point: Right now, I'm making a web service that has a native XML interface, which then gets (optionally) rendered via an XSLT interface with a 100% CSS defined GUI and the UI logic handled via DOM level 2 and Javascript. The applicational logic is handled via a PHP portal/middleware broker to the stored Postgres pgSQL database views/routines.
Got all that? I argued strongly with my client against using soch a complex interface architecture, but it was writtten in stone and they held firm and were willibg to pay for it -- so they got it. But, I can't count all the possible points of failure on one hand. Does it break in the database? maybe the XML? The PHP? Maybe the XSLT or maybe it's just the CSS or the Javascript.
The fact that Firefox requires a seperate CSS-stylesheet doesn't help matters, but I opted out of Firefox support to Support Gecko variants (safari) as well as Mozilla and IE -- but not Opera. Not proving support for certain browsers was a definite plus here -- since it's an intranet app meant to be used via VPN and not accesable to the public. But I shudder to think at the amount of CSS-stylesheets and JS includes that would be required to support this as a public service.

What we need right now is better integration/platform independence and the browser would be the common ground here. So instead of running off on their own and adding more languages/points of failure, maybe they could figure out a new means of getting everything to work together a bit better.
A good start would be getting Opera/Mozilla/Firefox all on the same page in terms of CSS/DOM level 3 compatability, that would be a lot more meaningful to me than a competing standard.

And thus ends my rant.

SVG is my make or break issue

[ynotds]

Sure I would also like the form improvements that WHAT WG are promising, but I've already got a bag of tools which do pretty much all I really need in that direction, as ugly a hack as CGI might be.

But until SVG is fully integrated into a browser and the DOM, the most important projects that have built up over a lifetime still cannot get started, and the stuff I have been working towards is only a tiny fraction of the potential applications of object graphics, an almost endless territory I became a lot more aware of in early PostScript days when potential players were attracted like bees to a honeypot.

Most people seem to have convinced themselves that SVG is primarily a more open alternative to Flash, but I see it being far more important that SVG bring the interactivity of the Web to areas which nowadays are mostly represented by static PDFs, obviously beyond print previewing.

It's really quite strange, when so much of the heritage of cooperative development came out of the technical research communities, that all that half of the current generation seems to want to do is reemulate a very tired set of office applications.

If a picture is worth a thousand words, a meaningful schematic diagram is worth ten thousand and a manipulable schematic diagram would be worth a hundred thousand.

While Flash could technically be used for such tasks it suffers from PDF's failure of not playing nicely with the browser model at the next level, and from a whole lot of historic perceptions.

For a brief moment earlier this year it appeared that the Mozilla team was going to get serious about SVG. There is another "last" opportunity during the Longhorn FUD to make some real inroads against the monopolist.

If we can finally get SVG to the point where we can seriously start building a technical visualisation web then I may not have to go to my grave with quite so many incomplete projects.