On Thu, 29 Apr 2004, Bryan Taylor wrote: > > I know I'm not the only person who wants it, so my goal in the post was > to perhaps attract somebody with more mozilla skills than I have to the > task.
This is probably the wrong forum then. Mozilla developers already have their hands full with more important work like performance, footprint, and CSS, HTML and DOM support. >> Mozilla staff have stated that an implementation would be accepted >> (assuming it met the same standards of code quality as all other >> patches, of course) so there is no need to convince people that XForms >> would be useful. All that is needed is a patch. > > Well, Brendan Eich also let me know this was so earlier today. I must > have missed the statement to that effect. It's what the "helpwanted" keyword means. If XForms support was to be rejected even if a quality implementation was provided, then the bug would have been marked WONTFIX. > Maybe I'm engaging in wishful thinking, but I think if the mozilla staff > had more enthusiasm for XForms, then implementers might be easier to > find. Skilled people probably don't want to spend time coding something > they aren't sure has strong support. XForms doesn't have strong support in this field, true. No browser maker has signalled any intention to implement it, several have signalled their intent to _not_ implement it, and many people have pointed out that there are fundamental flaws in XForms' design (such as its lack of backwards compatibility with deployed content) that make it inappropriate for the Web and for deployment in Web browsers. However, this doesn't mean Mozilla would refuse a patch if one was provided. It just means they are not going to spend their extremely limited resources trying to find one. Note how Mozilla staff's similar lack of enthusiasm for MNG (a feature with even more votes than XForms, which might give you some idea of how meaningless the number of votes the XForms bug has is) has not stopped MNG developers working to create an MNG implementation that is of good enough quality for being placed in Mozilla. > XForms would be a gambit to convert GUI and XML-centric middle-tier > developers to mozilla for some things that aren't traditional browser > functionality. If mozilla can simplify life for enterprise systems > developers even a little, then they will use it, and their users will A) > have to get mozilla installed and B) be forced to try it. I believe that > XForms is such an opportunity. At this point, MS and IE are heading for > XAML and so they aren't likely to try to offer incompatible XForms. This > means mozilla has an opportunity to have enterprise systems lock in to > mozilla. There is a third option, which is to work on alternatives to XAML that are much more author friendly (for example, that don't depend on XPath, are compatible with deployed content) and therefore more likely to succeed. > The mozilla leadership can certainly influece people -- things they > speak about as important are more likely to have volunteers appear. I don't see much evidence that shows that this is true. > This comes down to perceived costs and benefits. Dropping work on things > with poorer cost/benefit ratios would be a good thing. Name one. Crash fixes? SVG? Compatibility with the Web? CSS2.1? DOM? What exactly is being implemented that is less important than XForms? > Is anyone arguing XForms is this "bad" of a standard? There have been arguments against XForms, yes. For example XForms received several "no" votes when it was in the Proposed Recommendation stage at the W3C. Personally I wouldn't say XForms is bad as a standard in itself: It is quite well designed, and in and of itself, it's a good idea. The problem is that it has no backwards compatibility with deployed Web content, something that makes it a lot less attractive to a lot of people. > I'm not aware of any alternatives that come close. The choices appear to > be use this standard or do nothing. It depends what for. For the majority of Web forms, HTML4 Forms are actually fine. For another large segment, the incremental, backwards- compatible improvements I proposed to HTML4's forms features: http://www.hixie.ch/specs/html/forms/web-forms ...are quite suitable as well. XForms' power simply isn't that needed by internet-Web content much. (It is certainly possible that it is needed by Int_ra_net Web content, but in such scenarios the existing XForms plugins are enough, since typically the deployment of the content can be coordinated with the deployment of appropriate user agents.) >> I don't think anyone making the "XForms is bloated" comments has >> seriously considered implementing all of the thing. They _were_ >> talking about XForms Basic. > > Comment #89 by Mr. Hickson discusses XForms Basic as simplifying the > node validation part, replacing XML Schema comparisons with QName > comparisons. Other than this there wasn't much discussion of what > becomes simpler from an implementation point of view. There isn't anything. That is the sum total of the changes between XForms and XForms Basic. (That and an extremely minor difference relating to XML Events that is really neither here nor there.) >>> [XForms] is aimed at addressing the gap between thin HTML forms and >>> fat GUI apps. >> >> It's not clear that this aim hits target, though. It appears to be >> suitable for people writing professional form-based data entry and >> workflow systems, as in tax reports, or insurance forms. > > ... or forms for human resources, financials, order managment, > inventory, customer relationship managment, engineering change orders, > materials logistics, or any other type of business form that the large > IT departments of every company in the world spend most of their time > developing. Right. Intranet stuff. Quite adequately supported by existing XForms UAs. > If this isn't enough, you could also use XForms to configure any desktop > app that uses XML config files, and do so remotely with close > interlinking of help docs and howtos. ...which has pretty much nothing to do with the Web. >> It doesn't seem to be really suitable for your typical graphical (Web) >> application. > > Can you elaborate? How can adding capabilites with a richer event model, XForms does not add anything to the event model. > better separation of structure, logic, and layout Also known as "more indirection", something that causes authors more trouble, as shown by the trouble they have with CSS. (I went into this in more detail in my first reply). > and support for XML instance data result in a loss of suitability for > the typical web app? The typical Web app isn't a constraint-based form. Look at eBay, for instance. Or games like at voidwars.com. -- Ian Hickson )\._.,--....,'``. fL U+1047E /, _.. \ _\ ;`._ ,. http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.' _______________________________________________ mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
