Slashdot Mirror
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.
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.
.NET development tools.
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
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...
<!-- DHTML / JavaScript menu, popup tooltip, Ajax scripts -->
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.
Remember the year 2000? They promised us flying cars. They delivered the PT Cruiser...
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.
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.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
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?)
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.
Dissolve... Resolve... Evolve...
> So if you say xforms should be the base for future web apps instead of html ...
... you've got to explain why that is. Why is that?
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.
>
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.