Mozilla Foundation and Opera Software Describe Joint Vision for Web Application Framework
Tuesday May 25th, 2004
The Mozilla Foundation and Opera Software have published a paper outlining their vision for Web applications. The paper, submitted in preparation for next week's W3C Workshop on Web Applications and Compound Documents, describes a device-independent Web application framework based on HTML and backwards-compatible with existing Web content. The two organisations are keen to get parts of this framework in place soon to prevent a single-vendor solution (see Microsoft's position paper) becoming dominant. Co-author Ian "Hixie" Hickson's provides more insight in a recent weblog post on the matter.
Good to see Opera and Mozilla woking together against MS! Is MS's paper not loading or something? Because it seems quite short! :)
"We wish to present an overview ... but we don't always get what we wish for, eh?"
No, I get the feeling it was in error.
"Good to see Opera and Mozilla woking together" not neccessarly against anyone!
Opera and Mozilla both produce excellent products (browsers, ...), and the development of web related standards should be this way. This should be the norm and not the exception. As long as that chimp (GW) is in office, it will impossible to crack down on monopolies (as MS or others in different industires) in any way.
#2 This proposal doesn't seem enough.
Wednesday May 26th, 2004 2:20 AM
Yeah, I had a read of this article when I noticed the link n Mozillazine a few days back. To be honest I'm not sure it's all that great a direction to take. Basically from what I gathered they are proposing 'Keep it simple' as the way forward. Which is a nice idea but can you really build next generation web apps if you can't even draw to a canvas? Some would argue that you can indeed do some great stuff and that's very true, but standards agreed now will be in place for many years to come.
#4 KISS *is* the right way forward...
Wednesday May 26th, 2004 4:56 AM
This is an initial announcement. Starting off simple is a good thing, since it reduces the chance that drastic (and wrong) efforts are taken. Once the two groups work more with each other, I'm sure more drastic things will be announced...say, like what level fo support SVG and when!
#6 Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 5:20 AM
I agree that keeping things simple is a great way to start. More often that not though, that leads to not being able to extend your approach without re-engineering your solution. SVG is important enough that it's implementation should be mandatory for desktop browsers with at least SVG Tiny being support in all mobile browsers.
So how does the desire to implement SVG balance out with the desire to be "largely implementable in Windows IE6 without using binary plug-ins"?
#8 Re: Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 8:12 AM
KISS is definatley very important. I used to be a Flash developer it would always make me cringe a little when a customer wanted to do their whole web application in Flash. I always felt it was easier and worked better to just use plain HTML and serve page content up using MySQL. The flash web applications would end up getting really large, were difficult to maintain source code with (no clear separation of business logic and presentation), and loaded slowly for dialup customers. Once in a while I would like to add a graph or animation to describe the results of an inquiry. If SVG was an option then I wouldn't have had to use Flash at all. To this day I still have not seen a decent Flash web application being used commercially that has made any money. This is kind of interesting since Macromedia is pushing Flash MX as the right way to make web applications. Unless so had an intensive multimedia based application I couldn't reccomend Flash for a web application.
#9 KISS and XUL and GTK and SVG and Gnome
Wednesday May 26th, 2004 8:49 AM
I was messing around with Python and the GTK toolkit on linux the other day and I was wishing the UI could be spec'd out using XUL files. I know that the Gnome developers are looking at incorporating XUL into the desktop so the UI part of Gnome applications could be coded in XUL. Possibly this would be a good answer to Microsoft's Longhorn XML based GUI. Mozilla would need to get the GRE (Gecko runtime engine) stable and working instead of bundling a separate copy of the GRE with every Mozilla application.
#10 Re: Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 9:07 AM
This, right here, is exactly the sort of mentality that Mozilla and Opera are up against. What happens when my SVG app is viewed in a mobile SVG Tiny implementation that doesn't support some of the features that I use? Or do I have to restrict myself to only using SVG Tiny in general if I want the application to be usable across devices? In that case, what's the point of the rest of SVG? To make it possible to author applications that are NOT viewable across devices?
A lot of people seem to think that multiple versions of everything will get written -- one for mobile devices and one for desktop computers. That's about as likely as pigs flying for 99% of content, and the little content that _is_ created in multiple forms will just lead to version skew between the forms, frustration on the part of one set of users or the other, and breakage if yet another viewing setup appears.
That's why having device-independence built into the language in a way transparent to the application developer is so important.
#12 Re: Re: Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 9:51 AM
I'd say more an 'Outlook' than a 'Mentality'. I think it's just a conflict between different peoples views of what constitutes an 'Application' - you start at basic controls, basic IO (whether file or network based) and building event driven apps, pretty soon after that you find you have a monolithic app and want to split stuff out, have libraries, build custom controls etc. All I'm saying is you're always going to need flexibility and scope from a platform if you're apps are going to do much more than collect information on a form. I'd say SVG is much more flexible (in terms of device-independence) than JPG or GIF.
Ultimately the question is should graphical elements be used to convey information and functionality? If the goal is device-independance then I think that was lost a long time ago but the argument of using only further extensions to HTML is great, if that's the constraint to be imposed and it means quick and complete adoption. Meanwhile people will still be building graph applets, flash movies etc to convey visual information because the standard 'Web Application Framework' won't really do pictures. Basically there's not enough 'Application' functionality there for me, but with SVG it would be a few miles further down the road. I know it's not easy to implement and I know there's little chance of IE implementing it but that doesn't mean it's not a robust standard.
I guess I'll just wait for Avalon then, since no-one else is willing to put together what I need..
#13 Re: Re: Re: Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 9:59 AM
>> I guess I'll just wait for Avalon then, since no-one else is willing to put together what I need..
Come now, things aren't that bad on the Linux side. I think in about a year you will see an experimental incorpration of XUL into Gnome. Avalon probably won't come until 2007; that leaves times for the OS community to develop/integrate competing technology. Eventually you will see an XML based toolkit/framework come to KDE and Gnome for application development; it is just a matter of time...
#16 Re: Re: Re: Re: Re: KISS *is* the right way forwar
Wednesday May 26th, 2004 10:04 AM
Ok <sniff> I suppose it's no that bad..
I also have to accept that pesky vector graphics have nothing to do with the web, jpg and gif are more than enough for anyone after all... ;)
#23 XUL/XAML For KDE and Gnome Is Here Today
Wednesday May 26th, 2004 2:12 PM
> Eventually you will see an XML based toolkit/framework come to KDE and Gnome for application development; it is just a matter of time...
You're right. It's already here and it's called MyXAML. See <http://www.myxaml.com> for details. If you don't see the connection with Gnome and KDE may I add that MyXAML runs on Mono and you can use Qt# and GTK#, for example.
I've also written up an interview with the MyXAML mastermind Marc Clifton, see <http://xul.sourceforge.net/interviews.html> for details if anyone wants to find out more about MyXAML.
#25 Is XAML the Future of The Web? Ask The Pros
Wednesday May 26th, 2004 2:21 PM
As an addon: If you have any question about XAML and Mono/Linux I invite you to join us on the xaml-talk mailinglist over at Yahoo! Groups that includes Mr. MyXAML aka Marc Clifton himself. See <http://groups.yahoo.com/group/xaml-talk> for details.
#15 Re: Re: Re: Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 10:04 AM
I don't see a conflict as to what constitutes an application. I DO see a conflict as to who should be able to use said applications.
SVG is fine as a vector graphics language. It should NOT be an application language. That is, there doesn't need to be functionality in SVG itself to do things like I/O, etc. That should be in a specification dedicated to creating an application platform. That way, the I/O functionality would be equally available to SVG, HTML, MathML, and most importantly to mixed documents, in a reasonable way.
Unfortunately, the SVG specification IS attempting to define a complete application platform (have you seen the SVG 1.2 drafts?), including redefining all aspects of web presentation (layout, the meaning of CSS, etc, etc). So it's not just "not easy to implement", but "impossible to realistically implement if you want to support HTML as well" as things stand.
#17 Re: Re: Re: Re: Re: KISS *is* the right way forwar
Wednesday May 26th, 2004 10:10 AM
Ah, we;l that does sound a bit drastic. SVG 1.0 was enough for me. Perhaps they were just bored - they should be reassigned to spec-ing something else instead, let them spend years working on the database layer that should sort them out..
#20 Re: Re: Re: Re: Re: Re: KISS *is* the right way fo
Wednesday May 26th, 2004 12:26 PM
The problem is that the position papers talking about SVG as an application language are talking about SVG 1.2, not SVG 1.0.
Mozilla and Opera are suggesting that the application layer (I/O, databases, etc) be separated from the presentation layer (HTML, CSS, SVG), and that the latter should be such that mixed documents are possible, that you can use pure or at worst slightly modified (X)HTML with the application layer, etc.
#28 Re: Re: Re: Re: Re: Re: Re: KISS *is* the right wa
Wednesday May 26th, 2004 6:08 PM
In ASP.net and JSP with tag libraries there is an excellent separation of code and presentation if the pages are designed correctly using MVC pattern. In this case if Mozilla and Opera are advocating this position then they are heading in the right direction.
#14 Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 10:00 AM
KISS is the primary reason HTML is useless for semantic markup. It's just too limited. CSS was bolted on eventually but suffered from the same and the opposite problem (insanely complicated to implement and you are still severely limited in layout). Now the same mistakes are made for webapplications.
Basically it is a reinvent the wheel exercise. We already have mature, capable client side guitoolkits (win32, gtk, qt) that allow us to build very rich clientside applications. The problem with these toolkits that webapplications try to solve is the software distribution and the security (it's not very efficient and secure to distribute applications like that). Ideally a solution would be equally powerfull as todays client side gui toolkits (why accept less?). The reason we are currently settling for much less is that this apparently is technically hard on top of the w3c set of technologies. This is not surprising because these were never designed to do more than what we are seeing today (much less actually, it is amazing how people work around limitations in existing web technologies). Css is nice until you realize that a lot of features that you take for granted in a dtp package, word or openoffice are simply not there. (Want columns? Forget it.).
This is the context of this proposal and this is why the proposal is totally inadequate. MS seems to have a better grasp of what is needed. Avalon/xaml is much more ambitious than this. If we continue to pretend we don't need it it will just be there someday without a credible alternative. And people will build their applications in it because their clients will want all the prettyness & usability (whether they need it is an interesting but irrelevant philosophical discussion). Basically the whole notion of applications running in a browser is obsolete. The browser is just a toolkit for running applications on top of. Mozilla despite its ambitions in this area, is still nothing more than a toolkit for creating browsers (and similar applications).
So KISS is not the solution. The first company that will produce a powerfull, easy to use toolkit for building web applications will get a major portion of the market. Right now it looks like MS has a four year headstart in creating such a solution. It won't be perfect just vastly better than what is out there today. It has realizaed two important things: 1) CSS/HTML is a dead end 2) Anything less than what client applications can do today is unacceptable for web applications. The future is multimedia userinterfaces that happen to be hosted on an applicationserver and require no clientside installation beyond the run-time engine.
#18 Re: Argh...2
by roc <email@example.com>
Wednesday May 26th, 2004 11:20 AM
Actually, Flash has a multi-year head start on everything else in this space.
"CSS/HTML is a dead end" does not follow. Columns and UI-friendly layout are being added to CSS and implementations right now. We have client support for SOAP to let you talk to the server without reloading the page. Hardware accelerated SVG is coming. Etc etc.
One thing to remember about Avalon is that it will only run on Longhorn, and will require major hardware upgrades, and so it won't be ubiquitous until 2009 or later. And if non-Microsoft platforms or mobile devices capture a lot of users, it will never be ubiquitous.
#19 Re: Re: KISS *is* the right way forward...
Wednesday May 26th, 2004 12:15 PM
> Basically the whole notion of applications running in a browser is obsolete.
Unlikely. Developers are already used to creating applications that run in a browser, even if it doesn't make any sense. For example, applications that require an Windows-only ActiveX control, an IE browser, but then open in a separate window without using the browser UI or even HTML for anything.
> Right now it looks like MS has a four year headstart in creating such a solution. It won't be perfect just vastly better than what is out there today.
MS isn't building an easy to use toolkit for building web applications.
Or do you mean Avalon/XAML? That's a toolkit for building Windows applications. Which is what they've been producing for almost 20 years. But now, they're using XML for describing UI instead of resource files. And you can load content from the Internet. But you can do much of the same things with most other development tools - Java, Flash, Mozilla, etc. Just differently. Avalon doesn't even have anything to do with browsers. What makes MS offering's better for building web applications? In fact, what are you referring to as web applications?
> The future is multimedia userinterfaces
Fortunately the future will always be some time away.
#30 Re: Re: Re: KISS *is* the right way forward...
Thursday May 27th, 2004 11:10 AM
Best example against your argument is that I'm currently editing this message in a textarea instead of a wordprocessor. A wordprocessor would give me the convenience of spellchecking, all sorts of layout funcions cut and paste of other things than text, etc.. Those things are hard to realize using current web technologies. Doing wysiwyg text editing got a lot of oohs and ahs in the eighties yet this basic feature is still lacking in web applications while it has been perfected for nearly two decades outside the browser. We do have inline editing in browsers but compared to the real thing it is very buggy & limited.
Obviously the ease with which Avalon/Xaml can be transferred to the web is lost on you. MS has layed out the complete architecture for such applications already (and very uncharacteristically they even took security into account). It will take time to make it usuable and finish all the necessary parts and they'll probably get things not quite right in the 1.0 but my point is that we are giving them plenty of time to experiment while we still rely on obsolete, limited technology and do nothing.
A browser is far too limited for presenting content and applications. Outside a browser content and applications are much richer and much easier to manipulate. There is no technical reason for that. In the end it is not what developers are used to but what users are paying for that makes the difference. If there is one thing developers are used to (or should be used to) it is changing technology.
#32 Re: Re: Re: Re: KISS *is* the right way forward...
Thursday May 27th, 2004 2:09 PM
> Obviously the ease with which Avalon/Xaml can be transferred to the web
It can't be used on the web in any useful way however, since it is Windows Longhorn only, is technology dependent (.Net APis), uses little of the existing web architecture (html, dom, css) and generally requires special tools (XAML compilers, etc..) to create. If you accept these limitations, you're not actually making a web application but a Windows application. Which you can already do with existing versions of Windows and Longhorn is just the next upgrade in the cycle. So forgive me if I fail to see why MS has a 'four year headstart'.
And where's Macromedia's position paper? They've been positioning Flash towards this very thing -- did they drop the ball on this? Or are they planning on just skirting the W3C?
nice to see teamwork between mozilla and opera. i like them both & use both regularly.
This is great. It's a huge step forward.
Like Hixie says, we need the solution to be backwards compatible with IE 6. Actually, I would amend that. I would say it has to be "mostly" backwards compatible with IE 6. If a user has IE 6, he could get the basic features out of the web app. If he wants the extended features from the app, though, he will have to download Opera or Mozilla or another non-obsolete web browser.
As a hardcore Mozilla zealot and a non-Opera user, I am pleased as punch that we are working together with Opera on this.
And Boris is right, of course, on the need for the same thing to work on desktops and mobile devices. Remember that device transparency is a key point to the existence of the WWW and Internet.
Good work! Onward! Upward! Let's do it.
One more thing. If the W3C doesn't do the right thing and support an open standard, let's tell them "no."
Let's refuse their plan.
Then we might even set up our own standards body (with Mozilla and Opera to begin with) and put out a fair, well-conceived standard that is good. Then, implement that on both of our browsers. That would create a marketplace with excellent potential to grow.
If we do that, we can win, regardless of whether the W3C will choose to stay at the cutting edge with us or not.
#26 Re: W3C or another standards body
Wednesday May 26th, 2004 2:24 PM
Well 'we' (i.e. The Mozilla Foundation + Opera + Whoever) don't really need a 'standards body' - they need a mutually compatible implementation. Code trumps specifcations and if the code provides useful functionality, then authors will be prepared to use it. As far as I can tell, the W3C has a somewhat patchy history. It's policy of upfront design is nice in theory but in practice seem to lead to specifcations that no-one's happy with or specifcations that only work in edge cases. To date, the only W3C standards (I can think of, though maybe I'm wrong) that have been widely adopted /on the web/ are HTML, DOM and CSS. Other specs have been somewhat useful in other areas - XML has worked well for some forms of data interchange (but has been a total faliure on the web - even 'XML' formats such as XHTML and Atom are usually parsed by something other than an XML parser), SVG seems to have a following among the free-software community (but doesn't have anything like the penetration of, say, flash, on the web), MathML is still loosing out to PNG/GIF images, XSLT is used by some people but is generally disliked. That's not exactly a stunning track record. If Opera and Safari can be convinced to implement something like Mozilla's XBL, the -moz-box CSS extensions (which Safari already has) and whatever other things are needed to create a Web-Applications spec that's basically backwards compatible with HTML (in the sense that it doesn't require an entirely new renderng engine), then that *will* become standard, even if the W3C standard is an unholy mix of Xforms and SVG-with-network-IO that gets two compatible implementations and no users.
#27 Re: Re: W3C or another standards body
Wednesday May 26th, 2004 2:32 PM
Sorry, I don't mean "only work in edge cases", I mean "optimised to work well in edge cases, at the expense of simplicity iin common cases"
I also mean "Its" not "It's" :)
#31 Re: Re: W3C or another standards body
Thursday May 27th, 2004 1:11 PM
I agree. The W3C might not be the standards body of choice here. Our current direction of appealing to the W3C is good, though, because it gives the W3C a chance to right their ship and make a good choice (the one that Mozilla and Opera offer).
If the W3C declines us, though, then we need to put forth our own standard. A new not-for-profit organization that publishes the standard but doesn't do much else might be needed. Of course, the most important part will be working implementations from Mozilla and Opera.
#29 I think a binary IE plugin is exactly what we need
Thursday May 27th, 2004 8:40 AM
I think MS is not developing IE rerndering because it doesn't want current web standards to evolve. In fact whatever the W3C come up with will prolly not get implemented in IE and therefore not used by web-developers or users. MS is currently working on a complete XUL style markup language and I reackon it's hoping to hinder current web advancement untill it's got its own XAML (i think its called that) ready and then gues what? All of a suddenthere will be a new version of IE that supports it. "Oh No!" You may cry. "That's not fair! You said you were not going to upgrade IE!". Then MS will reply "Ahahaha! But we had to because the web is soooo old fashioned nowadays." and the whole world will suddenly be looking at them as their web savior. So I think w3c MUST move foreward *ignoring* IE compatability and making sure there is always a *good* IE plugin to keep it up with the times. So the MS developers/userbase keeps in touch with new developments as they happen and when MS finally releases XAMEL the the users will say "What do we need this for?"
- my 2p
#33 Re: I think a binary IE plugin is exactly what we need
by SpaceDogDN <firstname.lastname@example.org>
Friday May 28th, 2004 2:13 PM
> I think MS is not developing IE rerndering because it doesn't want current web standards to evolve.
Perhaps, but further development costs money and resources too. Also, don't forget that an outdated browser is yet another method of forcing people to upgrade to Longhorn.
> In fact whatever the W3C come up with will prolly not get implemented in IE and therefore not used by web-developers or users.
That depends on what the W3C approves and whether IE maintains its current marketshare prior to the release of Longhorn. If the W3C approves standards that are backwards compatible with IE 6.0, as the Mozilla/Opera alliance proposes, and alternative browsers supporting this standard gain marketshare, more web developers will use the new standards. As more sites support the standards, alternative browsers will begin to gain even more marketshare, thus setting up a feedback loop.
Remember, HTML has long been designed to be backwards compatible. W3C specifications favor standards that seperate raw information from the format it's presented in. A good example of this is the concept of alternative style sheets, where you can effectively choose the layout of the page in browsers that support the feature. Another example is the use of XSLT to convert XML formatted data into other formats such as HTML.
The Mozilla/Opera plan is based on this concept. They propose extensions an improvements that allow greater functionality on alternative browsers without rendering the code useless in IE. For example, consider the following:
<input id="time1" name="time1" type="time" min="08:00:00" max="17:00:00" value="08:00:00" />
In a complant browser, this would produce a time selection widget with the default time of 8am. In IE, it would produce a textbox with the value "08:00:00". If an IE user properly formats the text in the textbox, then the value returned by IE would be no different than the one returned by an alternative browser. If it's incorrectly formatted in the textbox, then validation could occur via a server-side validation function. In this manner, the code is identical, and the form will work correctly in most browsers, including IE, but the page will look better and be easier to use with browsers supporting the extensions.
> "That's not fair! You said you were not going to upgrade IE!". Then MS will reply "Ahahaha! But we had to because the web is soooo old fashioned nowadays."
Umm. No, that's not going to happen. XAML and Avalon are such vital Longhorn features that MS would be killing migration to Longhorn by including it in an upgrade to IE on older versions of Windows. It's far more likely that they'd upgrade IE for W3C approved extensions to HTML than they would for XAML.
> So I think w3c MUST move foreward *ignoring* IE compatability and making sure there is always a *good* IE plugin to keep it up with the times.
Let's face facts: IE has such a huge marketshare that writing web applications solely for a format that Vanilla IE doesn't support is suicide. For starters, when I see a page that requires a special plug-in to view it, my first impulse is to go somewhere else. Furthermore, if Mozilla has a hard time getting people to download a 4.6MB browser, getting them to download a plug-in of similar size will be nigh impossible.
Furthermore, creating a new standard that doesn't allow backwards compatibility with outdated browsers, such as IE, also hurts other browsers that fail to implement the standard. Will Apple's Safari support the new standard? How about Konquerer? What about businesses still using outdated browsers like Netscape 6/7?
Also, who's going to maintain this plug-in you want, and where are the funding and programming resources coming from?
To be honest, I think W3C will take three routes. First, they'll accept the Mozilla/Opera proposal because it has minimal impact on existing browsers while extending functionality significantly. It also might force MS to upgrade IE so that they can claim to be keeping up with web standards.
The second route would be to create an improved version of XForms. This will keep the XML intellectual elite happy while not really affecting popular web standards in any meaningful way.
Finally, W3C will allow to allow Microsoft to submit XAML as a web standard. This will allow the open source community to create implementations of XAML on non-Windows platforms while exposing MS to maximum criticism should they try to attack such projects.
So effectively, W3C has little to loose by accepting all viewpoints. Let the best standard win.