Mozilla, Opera Form Group to Develop Web App Specs 311
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.
Why WG? (Score:5, Interesting)
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
Konqueror (Score:5, Interesting)
instance khtml is representing safari too.
No SVG? (Score:3, Interesting)
HTML is not for web apps... (Score:5, Interesting)
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:Curl? (Score:2, Interesting)
Seems a far richer environment than Flash. Everything from XML parsers to 3D rendering built into that browser plugin.
Re:Backward compatibility for what? (Score:1, Interesting)
Web Standards are USER defined. (Score:5, Interesting)
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 [w3.org] works. Macromedias Flash app [macromedia.com] is a defacto standard, created outside the W3C. If it works, we use it. Suns Java [sun.com] 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:Why WG? (Score:5, Interesting)
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 [phptr.com]. Tim-Berners Lee's web site [w3.org] says he still acts as an advisor to the company that's continuing that project.
XAML (Score:4, Interesting)
So... besides XAML coming from Micro$oft and aiming at being yet another WWW-defacto-standard, what's bad with it?
Re:HTML is not for web apps... (Score:5, Interesting)
Anything else?
Interesting... (Score:3, Interesting)
For those who don't know:
XForms [w3schools.com]:XForms provides a richer, more secure, more reliable, and presentation independent way of handling interactive Web transactions.
I made a quick xml page [brimonet.com], with the source being here [brimonet.com], 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 [w3schools.com]
Some other XML technologies [w3schools.com]
I don't get it (Score:2, Interesting)
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:XAML parent is flamebait?) (Score:5, Interesting)
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? (Score:5, Interesting)
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...)
Another Standard?! (Score:3, Interesting)
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.
Re:XAML (Score:2, Interesting)
Because of Microsoft's pure dominance and Mono-based XAML plugins for Mozilla, it will be able to reach a lot more people than anything Moz/Opera could come up with.
There really isn't a point in creating yet another standard. Working on getting a single one to work across everything would be a big boon to everybody, but it seems Moz/Opera are both sick of following in IE's wake.
Re:I don't get it (Score:2, Interesting)
> 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 [w3.org] 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:Why WG? (Score:5, Interesting)
Re:Why WG? (Score:2, Interesting)
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.
Compound Transactions,Documents,Streams,Proxies (Score:3, Interesting)
W3C home > Mailing lists > Public > public-webapps-cdf-discuss@w3.org > April 2004 [w3.org]
Compound Transactions,Documents,Streams,Proxies.
A proxy based approach
Re:Curl? (Score:2, Interesting)
W3C proving increasingly unable to *do* anything (Score:3, Interesting)
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 (Score:5, Interesting)
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:XAML (Score:4, Interesting)
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 [csszengarden.com], 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 (Score:5, Interesting)
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 [slashdot.org] 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:HTML is not for web apps... (Score:4, Interesting)
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.
There are reasons for this. (Score:1, Interesting)
Not obvious to most, even at W3C, but it should be.
Microsoft hates browsers, becaused they are inherently non-proprietary. Their browser was an admission that they could not continue to compete without one. Obviously, Microsoft is a big company and there are people within Microsoft who feel differently, and any attempt to make PR out of the fact will be vigorously denined because continuing to coast with their IE dominance is what they want to do without improving anything.
But as much as Microsoft acts as a corporation, any influence Microsoft can bring to bear on browsers at W3C or elsewhere will be to marginalize open standards and avoid better standards-based functionality.
What browsers need is bold new initiatives.
Microsoft's desire to stick to HTML is just to avoid doing anything significant to browsers at all.
Browsers are hampered by the HTTP get/put model, as well as a number of other things that XForms addresses. Microsoft would rather have you using web applications that execute as native or other Windows-specific code, which is a natural consequence if browser-based applications are kept too hobbled.
These days, W3C browser development is throttled by Microsoft who says on most useful browser extensions proposed at W3C: "you may choose to do it, but we will not support it".
XForms is easy and useful enough that it can be efficiently implemented in much less time than the argument takes. Enhancing HTML is a good thing as well. In reality, you won't find Microsoft doing much of either, and the competition should be doing both. There are significant things that HTML is not likely to do. XForms was designed to be the next generation forms for HTML.
Opera is just trying to keep things small.
Mozilla has lost any vision for leadership in these things.
But failure of the browser will be a failure in vision on the part of the IE competition.
Re:Why WG? (Score:5, Interesting)
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 [w3.org] 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 [w3.org]. 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:HTML is not for web apps... (Score:3, Interesting)
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... (Score:2, Interesting)
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:Failure forseen. (Score:1, Interesting)
Re:Why WG? (Score:5, Interesting)
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:Failure forseen. (Score:2, Interesting)
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.
Neat stuff (Score:1, Interesting)
Microsoft, or at least their most visible W3C rep, Tantek Çelik (whom last I heard was moved off of the Mac IE project when it was end-of-lifed and onto some other project inside MS, but is still very active in the CSS committee and takes part in the XHTML discussions), doesn't see the need for xhtml/svg/xforms/etc. on the web currently either. If Tantek's attention is any hint what MS will be improving in IE7, CSS would be a safe bet.
The real meat and bones of this whole deal apparently is Web Forms 2, and is nothing new to people who have watched the XForms spec move forward. I remember Opera really having substantial issues with the XForms spec before it moved to recommended, and proposed something similar to what we see now as WF2.
It add's some handy features to some of widgets, and some nice features to forms in general (ex: elements outside of form markup, documents and standardizes a few things that have become ad-hoc standards, and for good measure adds some nice features from XForms.
What differentiates WF2 from XForms to me, is how practical and usable now the spec is today without the need to drastically reengineer web pages, or browsers to take advantage of the new features. I read through it saying stuff to myself like how much I would really have loved to have this feature on that last project, and finally! a standard datepicker widget (hopefully it's internals would be fully exposed to the DOM).
The Web Controls spec is really icing, we have all been hacking fake form controls forever. I would be great to have a standard way to do it.
The Web Applications spec only says one thing, but what a very nice one thing it is. A standard cross browser way to give fine grained control over cursor to the developer is something that has annoyed me in the past quite a bit.
While I personally might prefer to see XForms fully implemented and my co-workers up to date on how to code them in all the browsers sometime this decade, it won't happen without full Microsoft support, which from what I've seen is lukewarm at best.
I think that there is a decent chance these specs could end up implemented in IE7 if the specs get fleshed out relatively fast, and they get positive feedback from HTML coders.
Re:Konqueror (Score:2, Interesting)
What is a Web Application? (Score:3, Interesting)
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.
A fatter browser or a windowing system? (Score:3, Interesting)
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:HTML is not for web apps... (Score:2, Interesting)
Aikido Strategy in the Browser War (Score:2, Interesting)
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
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
Why I support this (Score:3, Interesting)
Down near the end of this usenet post I wrote last month [google.com] 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 [joelonsoftware.com]. It's smart.
Re:This is great news. (Score:3, Interesting)
It's called XUL.
Re:HTML is not for web apps... (Score:4, Interesting)
Re:HTML is not for web apps... (Score:3, Interesting)
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... (Score:2, Interesting)
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... (Score:2, Interesting)
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. :)