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

Re:Start your day...

[millahtime]

The one noted difference between the previous post about this and this one is that before it was being taken to W3C and now it is being done outside W3C.

Looks like W3C rejected this.

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?

[binkzz]

I don't feel Opera and Mozilla have the marketshare and clout to pull this off in terms of setting defacto standards.

If Opera and Mozilla come up with a new standard with new useful capabilities that IE won't support, this is the way to increase their marketshare.

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?

[Anonymous Coward]

except no one will use their standards because they won't work with IE. get real man.

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?

[tolan-b]

Not true. There are a lot of cases, specifically with web-based apps where you can dictate the browser. Whether it's for administrative access to something like a content management system for a portal site, or intranet applications, specifying that a specific browser is used (after agreeing with the client obviously) can be a practical option.

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.

Re:Why WG?

[jsebrech]

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.

No, I meant html with extensions that are largely backwards compatible instead of the "clean break" that xhtml2+xforms tries to make.

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.

I read up on xforms a bit, because I have to admit that even though I'm well-versed in html4 and css2, xhtml(2) and xforms are pretty much unknown to me.

And that is the big problem. What you're proposing is a switch to an entirely new language, somewhat resembling the old one, but really very different. That would require a large amount of retraining on the part of web designers, and web designers HATE to change the way they build websites (just look at how some people are still using the font tag).

Also, unless I'm mistaken about this, xhtml2+xforms has little to no support on current client platforms. Gradual changes to html always had a reasonable chance of getting implemented in browsers, but for an example of how the web community reacts to radical change, just look at the CSS and SVG experience. CSS1 isn't even fully supported on current browsers, despite being almost a decade old, and SVG is fringe at best, despite having been out for years. How exactly do you propose to get xforms onto the client in any reasonable timeframe? Especially when mozilla and opera have given a clear signal they think it's too far too fast and want a more gradual change in the form of what this WHATWG group is doing, and they pretty much set the standard for all browsers except IE (which is the least likely to get support for any new non-MS technology).

> Html has momentum, xforms doesn't.

XHTML 2.0 includes XForms.

What I meant with momentum was developer mindshare and platform support. XHTML2 is a reasonable step up from XHTML1, but who, apart from some bloggers and some techological advocates, writes their site in XHTML1? The baseline is still HTML4+CSS1 (and lots of sites, like slashdot, are even still HTML3.2 and no css). It will be years more until people are ready for XHTML2. And even then it will have to offer clear immediate and undeniable benefits over previous generations of html (just look at the resistance to css, which did provide a clear benefit). For that it will require ubiquitous platform support. So just like CSS it's going to have the chicken and egg problem. Webdesigners won't use it until it has wide support (and so there will be little user pressure on browsers to "get it right"), and browser makers will say they have better things to do than supporting a language nobody uses.

I'm all for advocating an eventual move to XHTML2/XFORMS, but you've got to look at how to realistically get there. Making the jump in one step is just not going to happen imho. That's why I think this WHATWG effort is more realistic in what it could achieve in a reasonable timeframe.

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.

Re:Konqueror

[Anonymous Coward]

it's faster, smaller and better written than Gecko (has had things like automated regression testing a lot longer) but not quite as mature.

No SVG?

[Anonymous Coward]

Obviously, I didn't RTFA and am just knee-jerking to the blurb. But does this mean that SVG support will be held back in any way on Mozilla and Opera? That would be quite a shame...

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: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...)

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.

Re:Curl?

[Anonymous Coward]

Also worth checking out the demos (large browser plugin needed) that a commercial organiztion made based on this technology.

Seems a far richer environment than Flash. Everything from XML parsers to 3D rendering built into that browser plugin.

Re:Curl?

[hixie]

I've looked at curl. If I remember correctly, it was not compatible with HTML, and IMHO did not separate style and content cleanly enough.

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...

[D-Cypell]

Dont get bogged down in drag and drop, it was just an example.

There are lots of things that are difficult to implement in what is essentially a documentation format. CGI was a hack and it never really improved much from there.

Users of applications expect certain things, responsiveness being up quite high on the list. Over a congested pipe it is not always acceptable to wait a couple of seconds while your browser refreshes your page with you menu expanded rather than collapsed!

Yes, I know there is a solution in Javascript but having worked with various web developers (I tend to focus on the back-end, business logic development myself) I know that Javascript is pretty much the #1 cause for complaint. Especially when it is used to provide complex functionality that should really be a part of the client container (or the browser in this case).

Anyone who has ever sat in a room with a client who is requesting features that the browsers can not easily provide should understand where I am coming from.

To the client (especially one that has seen a flash based web app interface), "The browser cant do that" doesnt cut it.

Re:HTML is not for web apps...

[swv3752]

You are so right. Look at the current uses of the internet: E-Mail, Instant Messaging, HTML Web, Games (a la Counter-Strike/Q3A), File Transfers (Ala FTP and P2P) and some upcoming technologies like VoIP.

There are a few extras like Internet Radio and Video that typically are hung off one of the previously mentioned technologies, usually the the web. And there is a fair amount of crossover between things. IM has included chat video conferencing, Games have had live chat for a while, Some games even had integrated email like tribes2. Web forums are something like email or IM. One can transfer files via IM. Most web brosers are ftp clients.

The ones that want to provide a rich client experience, are the ones that are trying to setup a rental model for software. If one can only access say thier office suite from a web browser then they get locked in to a rental model. The rental model has been predicted longer than Linux has been around, and if anything, we are moving to FOSS.

Re:HTML is not for web apps...

[tlianza]

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?

Looking through the specs that this group appears to be focused on, I think it's clear a number of them deal with web-based *applications* which are in many ways different from web *pages.*

Web-based applications have long since demanded a rich client experience in a browser, and they've gotten it. The thing is, Joe web surfer doesn't see it because they're not on the Internet - they're in web-based applications that companies use.

Some examples - Seibel's apps use ActiveX extensively for rich client experiences (because it was demanded by users/execs). Most/All of the reporting industry (Cognos, MicroStrategy, Crystal, Business Objects, etc.) makes huge use of these technologies (primarily DHTML) in their applications to provide drag and drop capabilities in the browser for manipulating data. These are companies who sell products that work on intranets but use web standards.

There is a big need here in web-based applications. It has been demanded, and it has been delivered, but it would be nice to have *standards* so we don't all have to reinvent the wheel each time.

Re:HTML is not for web apps...

[hixie]

Please do sit down and think about it. This is the kind of input we'd love to have.

What would be really helpful is having specific use cases in mind as well. For example, "Multiple document interfaces so that the user can be editing several meeting agendas at the same time with an Intranet calendar application".

Send your ideas to whatwg@whatwg.org (the WHATWG list).

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?)

Re:HTML is not for web apps...

[goon america]

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.

I think the problem isn't that user's don't want it; it's that these technologies are totally unreliably and really don't work if you expect more than three different kinds of browsers visiting your site.

A couple years ago, sites like my.aol.com and my.yahoo.com tried to go into a heavily-laden DHTML interface... only to have to take it down a couple of weeks later because it simply did not work properly for a large proportion of their users.

Re:HTML is not for web apps...

[Saeed al-Sahaf]

You are so right. Look at the current uses of the internet: E-Mail, Instant Messaging, HTML Web, Games (a la Counter-Strike/Q3A), File Transfers (Ala FTP and P2P) and some upcoming technologies like VoIP.

You are thinking in terms of primarily consumer uses of the browser. But keep in mind, as applications in business , everything from POS to accounting, CRM applications, other process management tools, become "web based", the need for a more "sophisticated" user interface will grow.

What I think is going to happen (and funny, really), is that the browser will expand and expand until it's just a skin for the OS (err, that's what Windows is!), and then there will be a special application to access Internet sites!

Re:HTML is not for web apps...

[Freexe]

As a developer you should explain to the client the advantages and disadvantages of other approaches, and mention the fact that googlebot cant see the infoformation in this form or that, and that means lower pagerank etc... and that for 10% of people they will not beable to see the site etc... After all, you are the expert, sometimes you really have to spell it out to them.

Re:HTML is not for web apps...

[hixie]

Sure, but as a Web browser manufacturer, that's the one I care about.

*In the context of Web Applications*, Java isn't successful. It's a different matter on the server side, and in applications that are deployed and installed on specific machines as opposed to used over the Web. But that wasn't the topic at hand.

Re:HTML is not for web apps...

[juhaz]

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

1. Because applets take aeons to start up and hog tremendous amounts of memory. JVM start-up is a big problem with every stand-alone java app and vastly more so with applets.
   
   
2. Because it was implemented as a plugin instead of part of web browser for better integrated approach.
   
   
3. Because Microsoft tried hard to kill it with broken implementation in IE.

Re:HTML is not for web apps...

[juhaz]

The other option is, of course, Longhorn, using XAML and various other Windows technologies. An open standard available before Longhorn is released would almost definitely become the defacto standard, simply because there is a demand for this.

Have you looked at XUL? It's rather similar to XAML (xml based interface/application definition framework), and they don't come much more open than that.

Mozilla and *fox/bird are built on top of it so it ought to be "rich" enough for just about everything, not to mention very cross-platform.

Re:HTML is not for web apps...

[hixie]

I meant on the client side. Like I said in other posts, yes, Java on the server has been quite successful. But on the server side interoperability is irrelevant. The server side is also already very well covered.

The scope of the WHATWG work is developing specifications for client-side, Web-based technologies so that they can be interoperably implemented in multiple hosts.

And yes, Intranet stuff doesn't really classify as "Web-based" for me, personally (other people in the WHATWG group might think differently on this matter, of course). I understand it is important but in practice it's an area where interoperability is again of a low priority since the clients can pretty much all be guarenteed to be what the IS department what them to be, so it could be IE, or Flash, or Java, or the Adobe SVG Plugin, or even a Windows executable and it wouldn't matter.

For example many companies have told Mozilla that it doesn't matter what standards they support, they will keep using IE internally.

Re:HTML is not for web apps...

[_xeno_]

Yeah, I suggested XUL, but it's not allowed: IE is the default browser, so it must work in IE. It doesn't have to work in any other browser, so it doesn't.

And XUL isn't quite rich enough for everything - part of the application includes creating SVG documents for making quasi-dynamic graphs. You need to be able to click and drag various elements of the the charts to alter them.

Unfortunately, this SVG requirement means we're IE only (various Opera bugs prevent it from working) because the SVG only works in the Adobe plugin, which doesn't work in any Mozilla build from the past two years. Last I checked Mozilla's SVG support was inadequate for our needs. That may have changed, but I'm not being paid to check that. :)

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.

Re:Web Standards are USER defined.

[crashnbur]

More to the point, web standards are developer defined. Users who simply use the end product don't care much about the process going in as long as the result is effective. We developers, on the other hand, are quite interested in sanitizing the web we have woven...

FYI, I'm using the term developer to include any user who happens to develop a web page. And I'm not talking about using one of those convenient page builders (the old type being Geocities and Xoom, the new type being LiveJournal and Blogspot). I'm talking about hard coding web developers who make web pages, even if the most advanced "language" they ever use is HTML.

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...

Re:This is great news.

[mpcooke3]

The problem is that HTML/cookies/dhtml and server side sessions have long been used to try create applications. HTML was never designed for this it was designed as a markup language for documents.

The current way of producing web-application using HTML templates/scripts etc, is basically just a hack that we have used for several years because the operating systems doesn't support any convenient way of running normal style applications that are served over the web. There have been a few attempts but the only real one - client side java applets was poorly implemented and squashed by microsoft.

I really don't think it will be possible to hold back the broad adoption of a proper way of developing web-applications.

By "proper" web-application I mean ones that work like normal applications and are not pseudo-page based. Applications that can use real widgets, object based state and use web services to communicate with servers.

I hate microsoft but this will be a revolutionary change for the web and a change that is long overdue. At work when the executives realise what XAML actually means in terms of useability they will just ditch non-IE browser support claiming they are old "old browser" not supporting proper web application. And in many ways they will be right, that is unless gnome-mozilla get a move on with native widgets support and proper web/desktop integration.

Take internet banking for example. The application is the same 99% of the time but it's so slow and has a horrible page based HTML gui. It should be just cached XAML/glade files or whatever and have a secure web-API update the balance when I double click to run the app. Same with amazon and several web-apps I have developed in the past.

Matt

Re:This is great news.

[Compuser]

At that point you might as well install Microsoft
Money, or GnuCash or somesuch. If your code is
cached locally and only communicates via web, then
why do you need a browser? It is already possible
to run, say, Word from a remote share. Missing
something...

Re:This is great news.

[juhaz]

Mozilla already has a way of developing non-html-hack web applications, and has had since it's beginning since Mozilla itself is built on that framework.

It's called XUL.

Re:This is great news.

[mpcooke3]

As far as I know XUL doesn't allow you to run application outside of the browser, doesn't have native widget support and doesn't use web services. So as web-application API's go it's pants.

In short XUL is just a layout description language, it could be used as part of a full web application API but it isn't. I don't think XUL is designed specifically for web applications, I think it's mainly used for fully downloadable client side applications such as Mozilla, firefox and thunderbird.

These XUL client side application and the GUI still doesn't run very fast under linux. XAML/Avalon/.NET could end up running web application with a better/faster GUI than Mozilla manages to render itself using XUL!

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.

[areve]

"If IE does not implement them, they will be simply ignored." I agree to some extent but it doesn't stop people supporting mozilla now. We may end up coding to versions of everything one for IE or one for Mozilla like in the days when netscape 4 and IE4 were popular. I for one would rather have a site work in the cross platform mozilla. (mac/windows/linux) than only in IE which I guess will remain windows only. As linux takes more of the desktop share developers will have to support it. I don't use linux desktop much but I can't tell my customers to switch OS. i can give them Mozilla on a CD to install though.

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.

Re:Failure forseen.

[CrystalChronicles]

What market share did Macromedia have when they came up with Flash? What market share did Sun have when they came up with Java? You gotta start somewhere.

If you want your technology to become popular, one way to do is to force it upon peoples computers. The other is to make something good thats better than the rest and will draw web developers and end users to dl it on their own free will.

Re:Failure forseen.

[swv3752]

The Government forces standards all the time. Sure if you are a private enterprise only dealing with private enterprise, then you can do what you want. Once you take on a government contract, you will do what the contract specifies. And even if you remian private, if your competitors take on government contracts, market pressure will work to make you conform.

Then there are accessibility laws. Flash is not acessible to the blind. Properly written html is acessible.

Lastly, if Gecko, KHTML, and Opera support the new standards, then that is about enough market clout to force some change.

Re:Failure forseen.

[hixie]

Every time we've made the browser more invisible, we've been hit by security nightmares like phishing. I think it makes a lot of sense to clearly mark remote applications as remote and to show their URI and so forth.

We care if it's implementable in IE6 because authors don't seem to want to do anything if it doesn't work in IE6.

Re:Failure forseen.

[poot_rootbeer]

Its time for goverments to step in and force standards.

Oh god no. If we let the government force a web markup standard on us now, fifty years from now we'll STILL be writing pages in HTML 4.0 Transitional with marginal amounts of CSS 1.0.

When has a government EVER kept pace with the rapidly changing technological world?

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.

Re:They need Google

[Segway Ninja]

This would probably just lead to people getting annoyed at Google, and ignoring GMail in favour of the MS-Branded Hotmail.

The problem with getting these standards implemented would be that Microsoft wouldn't support them, and your avewrage user isn't going to go out of their way to get Mozilla just to 'visit one site'

To your average user, the "benifits" of using internet explorer is that it is there when you start. Most of the world -does- run on windows.

It seems good to them that Interent Explorer will conveniently update itself, to keep their computer 'with-the-times' of what's on the internet, here and now.

Whatsmore, most people don't even know that Mozilla exists. While a few people will have a hazy memory of Netscape, before MS really held the reigns, Mozilla is a new and foerign concept to them.

People will always go with what they trust, and from what I've seen of some people, they fear downloading anything at all from the internet because of viruses, or hackers, or both. Now, with these 'possible threats', is your average user going to consider using this thing they've never heard of? Realistically, probably not.

The use of a specifically non-IE site would annoy the general public, and would push them to seek alternatives. An alternative to GMail isn't hard to find, even if it doesn't have the same amount of space. Why, there's that free hotmail link right there when you start internet explorer... That would do.

While I agree it could work, I think that realistically it's an unlikely event. People trust MS, and they use it because there is no effort to make it go. It'd be nice if that stratergy worked, but I think Google would be shooting themselves in the foot if they did that.

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? ;-)

Interesting...

[dncsky1530]

I wonder how this will work with Opera's plans for an IPO?
For those who don't know:
XForms:XForms provides a richer, more secure, more reliable, and presentation independent way of handling interactive Web transactions.
I made a quick xml page, with the source being here, just to show some people who don't know. Please note that in the example I used css to make the page look like something, this is technically incorrect
Some other XML technologies

Are you stupid ?

[Anonymous Coward]

W3C do NOT create standards, they create "reccomendations"

big difference
even on their site the stress this, yet people seem to ignore it and believe what they want no matter how wrong it is

Re:Are you stupid ?

[WWWWolf]

Nor is IETF known for making tons of "standards", they publish "requests for comments". (81 STDs, not even all of them real, vs. 3542 RFCs, though not all of those are "real" either...)

Really, the argument that W3C doesn't create "standards" is pretty weak. They just chose to call their standards "recommendations" just not to annoy anyone.

To me, it's a standard if a) there's a comprehensive specification, preferrably from one authoritative source and b) everyone else decides to follow that specific specification, even if some follow it better than others.

No matter what W3C says, you could call W3C's Recommendations de-facto standards, just like you could call a RFC-specified (but not STD-level) protocol "standardized". True, they're not strictly standardized by any major standardization bodies, but who cares? The nature of the Internet has always been to rely on flexible, community-created specifications rather than expecting commitees to work on the things for ages.

I don't get it

[wheezer]

Now Opera has been known for ages for being pretty anti-XForms, mostly because integration of standards such as XForms/SVG would bloat the browserfootprint to such an extent that a lot of mobile device manufacturers might start looking for a different browser - you can basically script together a viable Word alternative using a little PHP, a lot of XForms and SVG today, but instead we are seeing another fork off into a separate direction by a new web-related splinter cell.

It's a shame to see this development as XForms is a really neat standard that exists today - anyone with a engineering background certainly knows how useful it can be at times to can backwards-compatibility in favor of allout innovation.

Re:I don't get it

[markbirbeck]

> Now Opera has been known for ages for being pretty anti-XForms, mostly because integration
> of standards such as XForms/SVG would bloat the browser footprint to such an extent that a
> lot of mobile device manufacturers might start looking for a different browser ...

That's a good point, although it's interesting that at the recent Web Applications workshop the guys from Opera conceded that the only 'extra' piece you needed to add to a standards-based web browser, in order to implement XForms Basic, was XPath. And that can hardly be described as 'bloat'!

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:XAML

[SenseiLeNoir]

XMAL is proprietry to MS, and that means a big thing.

Fortunately there is already XUL which is working, stable and in use. XUL is as open as it can be.

however the good thing is the difference between the models shoudl not be too great, and using XSLT stylesheets it might be possibel to make cross platform web apps yet.

Another Standard?!

[orangeguru]

As a developer I don't ***** care who is inventing which standard anymore.

The promise that HTML was going to be a simple and independent language/tool is long broken.

With every new standard and browser development gets harder, testing and debugging longer.

For years now every bigshot has been talking about standards - but true implementation is far off.

HTML has mutated over the years - not properly developed.

If Opera & Mozilla try to force new stuff on developers - they will only get ignored even quicker. Web development is mostly based on IE6 - and nothing else.

Although I love and use Opera (and a bit Firefox here and there) - IE6 development brings in the money. And as a small fry I can't afford NOT to follow the money.

Compound Transactions,Documents,Streams,Proxies

[NZheretic]

From the W3C recent mailing list for Web Applications and Compound Documents
W3C home > Mailing lists > Public > public-webapps-cdf-discuss@w3.org > April 2004
Compound Transactions,Documents,Streams,Proxies.

A proxy based approach

W3C proving increasingly unable to *do* anything

[the endless]

It's about time someone tried to circumvent the W3C.

Honestly, the timescales the W3C are working on now are a joke. CSS3 has been in development since 2000 and is still nowhere near completion. XHTML 2.0 has been in development since August 2002, has already suffered from having its mission statement rewritten without announcement, and is, frankly, a bit crap. They don't even make use of XLink, but instead decided to write their own linking specification from scratch.

In short, the W3C has become a dinosaur. It takes far too long for them to get around to do anything, and it seems riddled with political jostling between both its members and its different working groups.

I think it's time someone else took over. The W3C only really works because the public allows it to - after all, the W3C isn't an official standards body so it's "standards" aren't really standards anyway. If someone else can do a better job, I say let them.

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.

Re:Just what the Wild Wild Web Needs Now

[naden]

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.

Last time I checked Firefox and Mozilla were the Gecko variants, Safari was a KHTML variant and IE was a variant of the plague.

Re:XAML

[I confirm I'm not a]

Great, yet more web standards to learn.

I'm so sorry! Perhaps we should halt all further development on the web? It'd certainly make my life a great deal easier, although very, very dull.

I don't put a great deal of faith into Mozilla, whose w3c support history has been less than rosey.

In what way exactly has Mozilla's w3c support been less than "rosey"? Portable Network Graphics? CSS2-3? Ever heard of "MOSe" (Mozilla Opera Safari extensions)? They're the browsers that actually support the latest w3c standards - try doing alpha-blended PNGs on IE. Try doing CSS3 on IE. If you want to see just how rosy the MOSe future looks, check out the Zen Garden, and in the meantime consider this: what do the w3c use as their de facto reference browser? (hint: Mozilla)

I was under the impression XAML is to be used primarily for laying out winforms, rather than as an new alternative to the tag.

You were wrong. XAML is similar to XUL (XML UI Language), or, if you like, dotNET. Just as you can use UI elements in a dotNET Windows App, you can use the same (well, similar) UI elements in an ASP.NET (web) app.

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.

Re:XAML parent is flamebait?)

[peragrin]

Netscape isn't mozilla, Mozilla looked at the 4.x range of netscape code and chucked most of it. Any history of Mozilla says this. Netscape 4.x sucked, and most people will admit it. Netscape lost the browser wars for two reasons, MS shoved them out, and Netscape 4 really was bad.

Mozilla isn't netscape, the New Netscape Browsers is just a rebranded Mozilla. Mozilla started over, which is why it took so long to get up to speed.

What is a Web Application?

[hixie]

Yeah, one thing that came out of the Web Applications workshop last week is that the term "Web Application" means different things to different people.

As I said in another post, 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. Indeed Sun did this years ago with Java.

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?)

But as it says in http://whatwg.org/: The term "Web Application" in this context refers to applications accessed over the World Wide Web by using a Web browser. This group is not attempting to describe APIs for writing high-end sophisticated programs such as office productivity suites, graphics manipulation packages, or 3D games.

Re:here we go again!

[pappin]

How is this a "standard" besides the fact that the two companies that got together *say* it's a standard?

This is particularly questionable since one of the "special" things about this story was that they decided to do it without the w3c being involved. Not that I think the w3c is the end-all and be-all, but they *are* a standards body... which would then make this forms crap a standard *in fact* and not just in marketing.

As for MS not implementing the "standard" I would point out that they would if it was indeed a standard... thats how they stole the market share in the first place... they simply made their browser be able to read *anything*.

I guess by now you can see that I don't agree with the excitement. it seems to be that we're simply adding another layer over top all the other garbage layers that HTML has become... so far this seems like just another unneeded framework when there is so much more that could be improved instead.

BTW - there are a lot of us who develop HTML as some part of our work... but that doesn't mean that I'm going to jump on the wagon just because the wheels move.

A fatter browser or a windowing system?

[Skapare]

So now my web browser will get fatter as all these new bells and whistles I don't need will be bundled in. What we need is to separate all these features into their own application, and have simply a small framework (a version of which could replace X and go directly to the video) that manages the screen. At least this way I can kill those particular processes (like Flash) that usually need to be killed.

Come on, seriously, putting all these application capabilities in a web browser isn't conceptually much different than a windowing system (besides the specific API and protocol differences). Pretty soon we'll do everything in a (so called) web browser super app and the windowing system will do little more than just start this one beast (and thus be a relatively lame layer). Why not merge these things and make a complete video driver, window system, and apps manager in a uniform design?

Re:XAML

[Bedouin X]

Yes to everything except the Vector Graphics. XUL is basically using web markup to build an interface. The most famous XUL example (outside of Mozilla / Fire* of course) is the Mozilla Amazon Browser.

Aikido Strategy in the Browser War

[idearat]

When confronted by an enemy stronger (in this case 10x so in terms of market share) you do not attempt to out-muscle them. If you want to live you use their strengths against them.

What is M$'s biggest strength? Monopolistic power that allowed them to create a deployed base comprising 90% or more of all browsers. The question is how to turn that strength into a weakness not how to "out-sell" M$ and get Mozilla onto those desktops. Not that that would be a bad thing, I'd love to see Firefox everywhere ;).

The real answer lies embedded in this comment, posted earlier:

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).

Now why would M$ have problems with scripting? Simple -- they can't undo having shipped hundreds of millions of "JavaScript VMs" to the world. Those browsers are sitting there, just waiting for the right combination of JavaScript and XML to bring them alive -- and M$ knows it.

Sure, unvarnished JavaScript has a lot of warts, but it also has garbage collection, prototype-based inheritance, full closures, first-class functions, and a number of other powerful features.

If you treat JavaScript not as an "endpoint" but as a starting point you can build virtually anything you like. I know, I've been doing it for 5 years creating everything from full-blown OO to web service workflows in JS and am on the verge of shipping XForms support for IE6+ and Mozilla with no applets or plugins of any kind. This isn't theory, I've got running code.

The bottom line is we don't need a new VM (browser), we need to use the ones that are already out there to their maximum effect. Those IE6 installations could just as easily become a massive anchor holding back M$'s plans for .NET if the right JavaScript took advantage of them.

What's the best news? Our benchmarks show that the same JS/XML applications run at least 2X faster in Firefox, offering a compelling reason to migrate over time to Firefox running XForms and other W3 standards, not .NET.

Why I support this

[Anthony Boyd]

Down near the end of this usenet post I wrote last month I talk about how the W3C has been a disappointment lately. Many of the specs I see from them are written for computer parsers, not humans. This is far different from the specs back in the heyday of Web growth. Lately it feels like following the W3C is like following a bureaucracy. It used to feel like I was having a conversation with fellow developers, people who were really into building Web sites and wanted to provide good, standardized ways to do more.

The bottom line is that if this new group can produce more developer-friendly documents that better address real-world problems, then I will support it. If they can get the KHTML team on board, then that's a huge bonus. Trying to do more within the realm of what already exists (rather than scrapping the old and starting again) is the right thing. It's refactoring. It's smart.