Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Mozilla The Internet Technology

Mozilla, Opera Form Group to Develop Web App Specs 311

Posted by Hemos from the working-towards-a-better-future dept.
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 discussion has been archived. No new comments can be posted.

Mozilla, Opera Form Group to Develop Web App Specs More

Mozilla, Opera Form Group to Develop Web App Specs

Comments Filter:

  • Why WG? (Score:5, Interesting)

    by peterdaly ( 123554 ) <petedaly@@@ix...netcom...com> on Monday June 07, 2004 @05:55AM (#9355065)
    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. The only logical course of action in this situation would be for the various browser developers to form their own standards group, which is what happened.

    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

    • Re:Why WG? (Score:5, Interesting)

      by Anonymous Coward on Monday June 07, 2004 @06:16AM (#9355103)
      Parent wrote: Some people within the W3C have even stated that the browser is dead.


      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.

    • Re:Why WG? (Score:5, Interesting)

      by vrmlguy ( 120854 ) <samwyse@nOSPAM.gmail.com> on Monday June 07, 2004 @07:03AM (#9355241) Homepage Journal
      From what I've read about Longhorn, I suspect that Microsoft is one of the groups opposed to "a backwards-compatible HTML-based standard". They want to replace the browser with new tools built into Longhorn that only they control. See any of these Google links [google.com] for more details.

    • Re:Why WG? (Score:2, Interesting)

      by binkzz ( 779594 )
      I don't feel Opera and Mozilla have the marketshare and clout to pull this off in terms of setting defacto standards.

      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.

      • Re:Why WG? (Score:2, Insightful)

        by Anonymous Coward
        except no one will use their standards because they won't work with IE. get real man.

    • Re:Why WG? (Score:5, Informative)

      by markbirbeck ( 736497 ) on Monday June 07, 2004 @08:15AM (#9355626) Homepage Journal
      > 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 [w3.org] 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 [w3.org].

      My proposal at the workshop [w3.org] 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.

      • Re:Why WG? (Score:5, Interesting)

        by hixie ( 116369 ) <ian@hixie.ch> on Monday June 07, 2004 @09:10AM (#9356007) Homepage
        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.

        • Re:Why WG? (Score:5, Insightful)

          by Bedouin X ( 254404 ) on Monday June 07, 2004 @11:01AM (#9356927) Homepage
          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.

    • Re:Why WG? (Score:5, Interesting)

      by pldms ( 136522 ) on Monday June 07, 2004 @08:25AM (#9355692)
      I am no w3c expert by any means, but that's an interesting statement and strong point.

      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.

  • Konqueror (Score:5, Interesting)

    by Anonymous Coward on Monday June 07, 2004 @05:55AM (#9355066)
    I think that i would be if better if konqueror/khtml people joined the group, as for
    instance khtml is representing safari too.

    • Re:Konqueror (Score:5, Informative)

      by scorp1us ( 235526 ) on Monday June 07, 2004 @08:26AM (#9355695) Journal
      It's not called Konqueror, it's called KJSEmbed, and is shipped with kde3.2. One of the components is kjscmd, which gives general javascripting to KDE. This means that you can access K* and Q* classes and write programs in javascript. It also supports DCOP so it is an easy RAD (rapid application development) and integration tool.

      Couple this with Factory.loadui(uifile) call, where you can load a QtDesigner .ui file (a XML dialog) created at design time and you have one fast RAD tool.

      // create variables that map to the widgets
      var dlg=Factory.loadui("square.ui");
      var okButton = dlg.child("buttonOk");
      var calcButton = dlg.child("buttonCalc");
      var xValLineEdit = dlg.child("xVal");

      function calc() {
      alert( xValLineEdit*XValLineEdit );
      }
      dlg.connect(calcButton, "clicked()", this, "calc");
      dlg.connect(okButton, "clicked()", this, "exit");
      dlg.show();
      application.exec();
      You can of course make dialogs on the fly too:
      var popup=new QVBox();
      var buttons= new Array;
      for (var i=0; i<10; i++){
      buttons[i]=new QToolButton(hbox);
      buttons[i].text="Button "+i;
      dlg.connect(buttons[i], "clicked()", this, "clicked_"+i);
      }

      function clicked_1 { alert("You clicked Button 1")}
      function clicked_2 { alert("You clicked Button 2")}
      ....

      popup.show();
      application.exec();
      }
      And there you have it. I spent 10 minutes typing this email and write 2 (albeiet simple) scripts.

  • No SVG? (Score:3, Interesting)

    by Anonymous Coward on Monday June 07, 2004 @05:56AM (#9355068)
    Obviously, I didn't RTFA and am just knee-jerking to the blurb. But does this mean that SVG support will be held back in any way on Mozilla and Opera? That would be quite a shame...

    • Re:No SVG? (Score:5, Informative)

      by MadMoose ( 23590 ) on Monday June 07, 2004 @06:28AM (#9355131)
      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

      Other parts of SVG will (probably/hopefully) never get into Mozilla. Like raw socket support: http://www.w3.org/TR/SVG12/#rawsocket [w3.org]

      Ian Hickson mentions other crappy things about SVG in his blog (which I'll be nice and not link to from /. - learn to google)

    • Re:No SVG? (Score:5, Interesting)

      by hixie ( 116369 ) <ian@hixie.ch> on Monday June 07, 2004 @06:45AM (#9355185) Homepage
      No, it doesn't mean SVG won't be supported. SVG 1.0 is just the thing for vector graphics, and it fits right into the HTML world if you use XBL, for instance. (Although admittedly that won't be backwards compatible and won't work in IE!)

      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...)

  • HTML is not for web apps... (Score:5, Interesting)

    by D-Cypell ( 446534 ) on Monday June 07, 2004 @06:00AM (#9355076)
    As more and more business move to 'web-deployed' business software I predict a big departure from HTML for web applications.

    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:HTML is not for web apps... (Score:5, Interesting)

      by hixie ( 116369 ) <ian@hixie.ch> on Monday June 07, 2004 @06:28AM (#9355132) Homepage
      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? :-)
      • I'm a drag 'n drop man myself, I learned the skill from Win3.1.

        The 300 people I work with are not drag 'n drop people. The idea of picking up an Access database file and dropping it on the Excel icon is totally alien to them... I borrowed a set of auto-complete JS functions to put in my latest web app. The users were gob-smacked by this too.

        I cannot see the need for drag 'n drop functions in web applications. Sorry.
        • Dont get bogged down in drag and drop, it was just an example.

          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 solut
      • Multiple document interfaces is another one that comes to mind, there are probably a few (hundred) others if I sat down and thought about it.

        Basically, anything that is currently done with client scripting languages (jscript for example).

        Java applets come close, Flash has come closer, I think the next one will be the winner, and its not far away.
        • Please do sit down and think about it. This is the kind of input we'd love to have.

          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).
      • Drag and drop already is possible within current browser standards. The event model and display model is there. Of course, you're locked within the single window/frame.

        Although, as a web application developer, I'm reasonably disappointed in what WHATWG has to say. You're trying to push web applications into the pigeonhole they're stuck in now, which is in the browser. Let them move outside the browser. Let the standards grow away from "web pages". Backwards compatibility with HTML is a crippling diversion

        • Re:HTML is not for web apps... (Score:5, Insightful)

          by hixie ( 116369 ) <ian@hixie.ch> on Monday June 07, 2004 @08:57AM (#9355909) Homepage

          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:HTML is not for web apps... (Score:4, Interesting)

            by juhaz ( 110830 ) on Monday June 07, 2004 @04:39PM (#9360247) Homepage
            Sun did this years ago with Java. Why wasn't it successful?

            1. Because applets take aeons to start up and hog tremendous amounts of memory. JVM start-up is a big problem with every stand-alone java app and vastly more so with applets.

            2. Because it was implemented as a plugin instead of part of web browser for better integrated approach.

            3. Because Microsoft tried hard to kill it with broken implementation in IE.

    • Re:HTML is not for web apps... (Score:5, Insightful)

      by jjohnson ( 62583 ) on Monday June 07, 2004 @06:40AM (#9355161) Homepage
      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.
      • not Office knockoffs

        This is true currently, but it is set to change. Web based deployment is excellent for non-tech business in that there is very little support on the desktop (no rollouts etc).

        The Java applet model was designed to solve this problem, but it failed. However, flash is fareing much better.

      • Re:HTML is not for web apps... (Score:4, Interesting)

        by swv3752 ( 187722 ) <swv3752@NOsPAM.hotmail.com> on Monday June 07, 2004 @07:54AM (#9355490) Homepage Journal
        You are so right. Look at the current uses of the internet: E-Mail, Instant Messaging, HTML Web, Games (a la Counter-Strike/Q3A), File Transfers (Ala FTP and P2P) and some upcoming technologies like VoIP.

        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.
        • You are so right. Look at the current uses of the internet: E-Mail, Instant Messaging, HTML Web, Games (a la Counter-Strike/Q3A), File Transfers (Ala FTP and P2P) and some upcoming technologies like VoIP.

          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 g

      • 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?

        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 g


      • 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?

        Good point, but IMHO those other means of enriching the web client interface towards the levels that native applications have enjoyed for years are something for which there is latent demand, particularly in the corporate and business arena.

        All those previous solutions have been afflicted

      • 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.

        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 t

  • Web Standards are USER defined. (Score:5, Interesting)

    by Whitecloud ( 649593 ) on Monday June 07, 2004 @06:09AM (#9355087) Homepage

    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:Web Standards are USER defined. (Score:4, Insightful)

      by crashnbur ( 127738 ) on Monday June 07, 2004 @08:25AM (#9355685)
      More to the point, web standards are developer defined. Users who simply use the end product don't care much about the process going in as long as the result is effective. We developers, on the other hand, are quite interested in sanitizing the web we have woven...

      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.

  • This is great news. (Score:5, Insightful)

    by gusnz ( 455113 ) on Monday June 07, 2004 @06:11AM (#9355092) Homepage
    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.

    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 .NET development tools.

    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...

    • Well said!

      The more people who are aware that "web browser" does not equal "the blue 'e' icon", the better...

      Recently I've encountered individuals who believe "the Internet" is "the blue 'e' icon". They don't even know what a browser is? Sad.

      z
    • The problem is that HTML/cookies/dhtml and server side sessions have long been used to try create applications. HTML was never designed for this it was designed as a markup language for documents.

      The current way of producing web-application using HTML templates/scripts etc, is basically just a hack that we have used for several years because the operating systems doesn't support any convenient way of running normal style applications that are served over the web. There have been a few attempts but the only

      • Re:This is great news. (Score:4, Insightful)

        by Compuser ( 14899 ) on Monday June 07, 2004 @02:49PM (#9359195)
        At that point you might as well install Microsoft
        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:This is great news. (Score:3, Interesting)

        by juhaz ( 110830 )
        Mozilla already has a way of developing non-html-hack web applications, and has had since it's beginning since Mozilla itself is built on that framework.

        It's called XUL.

  • Failure forseen. (Score:5, Insightful)

    by deragon ( 112986 ) on Monday June 07, 2004 @06:11AM (#9355093) Homepage Journal
    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.

    • Re:Failure forseen. (Score:2, Insightful)

      by areve ( 724106 )
      "If IE does not implement them, they will be simply ignored." I agree to some extent but it doesn't stop people supporting mozilla now. We may end up coding to versions of everything one for IE or one for Mozilla like in the days when netscape 4 and IE4 were popular. I for one would rather have a site work in the cross platform mozilla. (mac/windows/linux) than only in IE which I guess will remain windows only. As linux takes more of the desktop share developers will have to support it. I don't use linux d

    • Re:Failure forseen. (Score:5, Insightful)

      by hixie ( 116369 ) <ian@hixie.ch> on Monday June 07, 2004 @06:41AM (#9355163) Homepage
      How would goverments "force standards"? If I want to write a Web browser that doesn't support HTML, why shouldn't I? Are you saying goverments should make Flash illegal?

      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:4, Insightful)

        by swv3752 ( 187722 ) <swv3752@NOsPAM.hotmail.com> on Monday June 07, 2004 @08:22AM (#9355674) Homepage Journal
        The Government forces standards all the time. Sure if you are a private enterprise only dealing with private enterprise, then you can do what you want. Once you take on a government contract, you will do what the contract specifies. And even if you remian private, if your competitors take on government contracts, market pressure will work to make you conform.

        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.
      • Why do you even care whether these are implemented or implementable in IE? When it comes to web applications, the browser is irrelevant. The browser should be an all but invisible "web application runtime engine". You're not going to be able to twist IE's arm into becoming that, without having to sacrifice functionality. This all sounds like butchery of potential to me.

        What interests me though, other than bickering over direction, is where Apple are going to lay their chips.

        • Re:Failure forseen. (Score:2, Interesting)

          by hixie ( 116369 )
          Every time we've made the browser more invisible, we've been hit by security nightmares like phishing. I think it makes a lot of sense to clearly mark remote applications as remote and to show their URI and so forth.

          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.
          • Every time we've made the browser more invisible, we've been hit by security nightmares like phishing. I think it makes a lot of sense to clearly mark remote applications as remote and to show their URI and so forth.

            Fair point.

            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.

            I see that as a problem with web sites, not applications (to a degree). I may be being unduely idealistic here, but I feel as though web applications should, and will

            • Well, is Slashdot a Web site, or a Web application?

              WHATWG is targetting Web applications like Slashdot, eBay, Amazon, Voidwars [voidwars.com], etc. Not Web Applications like server-hosted versions of Word, Excel, Quake, etc. I'm sure we all agree that trying to do a real Excel clone in HTML is simply a non-starter.

              • Fair enough. I guess I'm just looking for the wrong things in WHATWG, or wrongly seeing it as an attempt to solve a problem that it's not.

                Again, I apologise if I've come across as antagonistic. Too much coffee, and too much interest in the subject matter :)
                • Yeah, one thing that came out of the Web Applications workshop last week is that the term "Web Application" means different things to different people.

                  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
    • What market share did Macromedia have when they came up with Flash? What market share did Sun have when they came up with Java? You gotta start somewhere.

      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.
    • Can I have a proper browser inside my Internet Explorer? For example, Mozilla as an Active-X applet running transparently inside my MSIE?
    • Mozilla and Opera will implement them, and then sites that see how it's easier to code for them will do so, and will recommend users do so as well. Then, Microsoft will ship XAML, and will find other standards are already more prevalant.
    • If IE does not implement them, they will be simply ignored.

      I disagree. As long as the site doesn't entirely *break* under IE, a lot of webmasters will want to play with the cool new toys. Take transparent PNG's for example - IE doesn't support them (to my knowledge) but they are starting to crop up everywhere because they're a REALLY DAMN GOOD IDEA.

    • Re:Failure forseen. (Score:4, Insightful)

      by poot_rootbeer ( 188613 ) on Monday June 07, 2004 @10:12AM (#9356484)
      Its time for goverments to step in and force standards.

      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?

  • They need Google (Score:5, Insightful)

    by tdvaughan ( 582870 ) on Monday June 07, 2004 @06:18AM (#9355110) Homepage
    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.
    • This would probably just lead to people getting annoyed at Google, and ignoring GMail in favour of the MS-Branded Hotmail.

      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 wil

  • XAML (Score:4, Interesting)

    by kwench ( 539630 ) <kwench79@yahoo.de> on Monday June 07, 2004 @06:20AM (#9355117) Homepage
    I had a quick look at XAML and it looked quite straightforward and simple.

    So... besides XAML coming from Micro$oft and aiming at being yet another WWW-defacto-standard, what's bad with it?

    • Re:XAML (Score:3, Insightful)

      by SenseiLeNoir ( 699164 )
      XMAL is proprietry to MS, and that means a big thing.

      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:XAML (Score:2, Interesting)

      by PhrostyMcByte ( 589271 )
      Exactly.

      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.

      • 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.

        XAML isn't a lot different from XUL, with two big differences. XAML won't be here for two years, whereas XUL has already been here for several years. XAML is proprietary, whereas XUL is open and provides open implementations. I can't see how you can defend XAML, really...

    • The problem is that it's coming from Microsoft and, unless they open-source XAML completely, we can never be certain that there are no lock-in mechanisms that benifit Microsoft to the detriment of developers and users. Microsoft has consistantly shown that they can and will do things of that nature, and we are right to regard any of their technologies with some suspicion.

  • We do want this in standards body at some point (Score:5, Informative)

    by hixie ( 116369 ) <ian@hixie.ch> on Monday June 07, 2004 @06:23AM (#9355120) Homepage
    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? ;-)

  • WHATGW... (Score:2, Funny)

    by Epistax ( 544591 )
    ... I read that as WHATWJD. And the answer (of course) is smote things.

  • Interesting... (Score:3, Interesting)

    by dncsky1530 ( 711564 ) on Monday June 07, 2004 @06:29AM (#9355136) Homepage
    I wonder how this will work with Opera's plans [ectnews.com] for an IPO?
    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]

  • Are you stupid ? (Score:2, Insightful)

    by Anonymous Coward

    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:Are you stupid ? (Score:2, Informative)

      by WWWWolf ( 2428 )

      Nor is IETF known for making tons of "standards", they publish "requests for comments". (81 STDs, not even all of them real, vs. 3542 RFCs, though not all of those are "real" either...)

      Really, the argument that W3C doesn't create "standards" is pretty weak. They just chose to call their standards "recommendations" just not to annoy anyone.

      To me, it's a standard if a) there's a comprehensive specification, preferrably from one authoritative source and b) everyone else decides to follow that specific spec

  • I don't get it (Score:2, Interesting)

    by wheezer ( 50418 )
    Now Opera has been known for ages for being pretty anti-XForms, mostly because integration of standards such as XForms/SVG would bloat the browserfootprint to such an extent that a lot of mobile device manufacturers might start looking for a different browser - you can basically script together a viable Word alternative using a little PHP, a lot of XForms and SVG today, but instead we are seeing another fork off into a separate direction by a new web-related splinter cell.

    It's a shame to see this developme

    • Re:I don't get it (Score:2, Interesting)

      by markbirbeck ( 736497 )
      > Now Opera has been known for ages for being pretty anti-XForms, mostly because integration
      > 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 Basi
      • Yes, I don't really understand Opera's objection to XForms. Any browser with XML, DOM, Javascript and HTML form support contain the basic capabilities for XForms.

        One legitimate complaint is that XForms isn't backwards compatible; however as I've just completed some work using XForms and I'm currently dealing with the mess of javascript and html that complex forms currently require ... well, screw backwards compatibility it this case.

  • Another Standard?! (Score:3, Interesting)

    by orangeguru ( 411012 ) on Monday June 07, 2004 @06:50AM (#9355202) Homepage
    As a developer I don't ***** care who is inventing which standard anymore.

    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.

    • IE6 development brings in the money.

      True, but for how much longer?

      If it doesn't run in Mozilla or Firefox I don't visit it. So if it's a shop, then I don't buy, they don't see my money, and therefore they can't pass it on to developers.

      Oh, I know that the lack of my spending is hardly an issue in the grand scale of things. But more and more people either don't use Windows, or use Windows but not IE.
      And as IE6 is currently frozen, and exploits and Malware still seem to abound, more and more people a

  • Compound Transactions,Documents,Streams,Proxies (Score:3, Interesting)

    by NZheretic ( 23872 ) on Monday June 07, 2004 @07:03AM (#9355244) Homepage Journal
    From the W3C recent mailing list for Web Applications and Compound Documents
    W3C home > Mailing lists > Public > public-webapps-cdf-discuss@w3.org > April 2004 [w3.org]
    Compound Transactions,Documents,Streams,Proxies.

    A proxy based approach

  • W3C proving increasingly unable to *do* anything (Score:3, Interesting)

    by the endless ( 412967 ) on Monday June 07, 2004 @07:13AM (#9355279)

    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)

    by l0ungeb0y ( 442022 ) on Monday June 07, 2004 @07:17AM (#9355300) Homepage Journal
    "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.
    • That was a very clever use of words: Web and browser developers are managing "language saturation as never before" -- that just seems brilliant, yet it was such a simple and clear statement. You deserve a medal. :-)

      On a lighter note, though, I share your sentiment. The saturation of various acronymic technologies is turning the WWW into an eyechart.
    • 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.

      Last time I checked Firefox and Mozilla were the Gecko variants, Safari was a KHTML variant and IE was a variant of the plague.
    • I'm developing an application built on pretty much the same technologies, minus a few of the extra complexities (instead of going for native XML, I've opted for native XHTML, butchered to feel a bit more like XML).

      Safari isn't a Gecko variant, it's a KHTML variant. The only browser I've had to drop support for is IE because it's too far behind the curve. For the supported browsers, I've got one single client codebase that functions identically across the board. This is possible with the standards support t

  • SVG is my make or break issue (Score:5, Interesting)

    by ynotds ( 318243 ) on Monday June 07, 2004 @07:23AM (#9355333) Homepage Journal
    Sure I would also like the form improvements that WHAT WG are promising, but I've already got a bag of tools which do pretty much all I really need in that direction, as ugly a hack as CGI might be.

    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.

  • I've started a petition to get Google to rank XHTML-valid websites higher than others. This would be one way that Google could influence the future of web standards for the better, and head off Longhorn at the pass, while delivering better results to Google's users.
    http://www.petitiononline.com/googhtml/petition.ht ml [petitiononline.com]
    Rich.
  • Who is the mole from Microsoft that has infiltrated and is making the Mozilla organization abandon W3C standards?

  • A fatter browser or a windowing system? (Score:3, Interesting)

    by Skapare ( 16644 ) on Monday June 07, 2004 @11:26AM (#9357183) Homepage

    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?

  • Why I support this (Score:3, Interesting)

    by Anthony Boyd ( 242971 ) on Monday June 07, 2004 @02:12PM (#9358823) Homepage

    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.

Slashdot Top Deals

As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"

Close