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.
This is great news. (Score:5, Insightful)
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...
Failure forseen. (Score:5, Insightful)
Its time for goverments to step in and force standards. The Internet must remain open and interoperability is essential.
They need Google (Score:5, Insightful)
Re:Failure forseen. (Score:2, Insightful)
Are you stupid ? (Score:2, Insightful)
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:HTML is not for web apps... (Score:5, Insightful)
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:Failure forseen. (Score:5, Insightful)
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. (Score:2, Insightful)
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:XAML (Score:3, Insightful)
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.
Re:They need Google (Score:2, Insightful)
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.
Re:HTML is not for web apps... (Score:3, Insightful)
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:Failure forseen. (Score:4, Insightful)
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:Web Standards are USER defined. (Score:4, Insightful)
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.
Re:Just what the Wild Wild Web Needs Now (Score:2, Insightful)
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:Are you stupid ? (Score:1, Insightful)
W3C do NOT create standards, they create "reccomendations"
That depends on who you talk to. Tim Berners-Lee, in his book Weaving the Web, does state that they intentionally didn't call their specifications "standards", and it did work that way for a long time. But over the past couple of years, the W3C have increasingly referred to their publications as standards. For instance, from their markup page:
XHTML 1.0 is the first major change to HTML since HTML 4.0 was released in 1997. It brings the rigor of XML to Web pages and is the keystone in W3C's work to create standards that provide richer Web pages on an ever increasing range of browser platforms including cell phones, televisions, cars, wallet sized wireless communicators, kiosks, and desktops.
If you bother looking, you'll find many instances of W3C people talking about their "standards". Whether this is laxness or a new policy, I don't know.
Re:HTML is not for web apps... (Score:5, Insightful)
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:Why WG? (Score:2, Insightful)
Re:HTML is not for web apps... (Score:3, Insightful)
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:Failure forseen. (Score:4, Insightful)
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?
Re:here we go again! (Score:2, Insightful)
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.
Re:Why WG? (Score:2, Insightful)
Re:Why WG? (Score:5, Insightful)
Re:HTML is not for web apps... (Score:3, Insightful)
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!
Why WG?-"PAY" standards. (Score:1, Insightful)
Unfortunately for CURL. It's not really a standard. It's basically payware. Tim really should know that the standards became a standard because there was no cost to using them. Even the IE "defacto" standards were a no cost choice for developers. Same with Netscape.
Re:This is great news. (Score:4, Insightful)
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:HTML is not for web apps... (Score:2, Insightful)
*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:XAML (Score:1, Insightful)
Plus two more:
XAML will be marketed as a developer technology, with tool support, documentation, etc, not as an inhouse Netscapism.
XAML will be stable and supported and not break applications when someone upgrades their browser to the next
Re:Just what the Wild Wild Web Needs Now (Score:1, Insightful)
PHP failure or DB faiures are un-avoidable if they happen, but they shouldn't if you write proper code... and as for using a web service, sounds like a great way to integrate this thing with other languages/apps/servers/whatever.
Welcome to the real world where simple poorly written web applications won't cut it anymore. People want flexibility so you have to write in proper error checking and recovery mechanisms, there's a whole world of system architecture you are about to get exposed to, Enjoy!
Re:Why WG? (Score:4, Insightful)
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.
Re:Why WG? (Score:3, Insightful)
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.