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.
I think that i would be if better if konqueror/khtml people joined the group, as for
instance khtml is representing safari too.
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.
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.
Do you need a website upgrade?
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...
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.
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.
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?
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
/. - learn to google)
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
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?
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).
"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.
> 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.
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.