On Tue, Jun 10, 2008 at 10:14 PM, Luke <[EMAIL PROTECTED]> wrote: > This is one of the things I have been wanting to contribute to this > conversation. It's all well and good to say that people using Open source > accounting software, are going to be using OS browsers as well. I in fact > made a similar argument regarding the move to PostGreSQL, over in the > SQL-ledger list thread about LedgerSMB. > > However, this is not really the same issue: the database thing is a > radical back end case, whereas the browser is a UI case. Once you decide > that a web interface is your primary interface, standardizing on a single > browser, or even a standard set of browsers, if that browser/those > browsers is/are not the majority case (IE is the majority case), is > sounding the death knell for the software in my opinion.
I just want to make sure my point is clear: we standardize on HTML practices that we find maintainable and make a reasonable effort to support various browsers. However, we aren't going to sacrifice a great deal of maintainability to support browsers which pose major problems. Currently IE8 looks like it will be supportable* which is a good thing. IE6 and IE7 are not. Pocket IE is not. W3M is currently not. To my knowledge other browsers work. The big thing is that the <button> element has to be properly supported. If browsers aren't going to do this, then we can't handle localization properly while allowing the application to work gracefully without Javascript. Or rather if we do this, we end up with an unmaintainable mess. * supportable meaning supportable in the standard distribution. Custom solutions can of course be done differently depending on customer needs. Now, there was some talk for a while that I was supporting relating to support for IE *only with Javascript enabled* probably using Dojo or the like. While I still support AJAX-type interfaces being possible, IE8 should be such that support without Javascript should be possible. > > Yes, I dislike IE. Yes, I get my customers to switch to FireFox when > possible. However, it isn't always possible or reasonable to request > this, and in fact why should they? They've got something their people > know how to use, even if it isn't the best, which means that they are > currently experiencing maximum efficiency as far as they know, and > starting over with anything is going to impede in the moment, even if it > speeds later. There are other issues to consider as well. At the moment, as Trevor notes below, LSMB has some significant issues for many businesses. It is currently a niche product. Hence at the moment requesting the change is not a problem. However, as we fix these issues and broaden our appeal, it will become a bigger issue. Hence there is a legitimate question of where we draw the line. With IE8 supporting buttons properly, I would suggest that the line should continue to be proper support of the button tag. > > Requiring a particular browser or set of browsers, has a certain feel of > proprietary which I tend to associate with MicroSoft, not with OSS. > Well, I don't think we can support every browser out there. The QA involved is tremendous and some browsers just don't support everything we need. Why should we rearchitect the application to support W3M? Is it *that* important to support IE6 and 7 fully if IE8 support is there? I think that we should continue to document which browsers are utterly broken and make a reasonable effort to support any given browser. Reasonable being defined as an effort which does not fundamentally compromise maintainability of the codebase or translation set (moving back to submit inputs would compromise the maintainability of translations). In short I think this needs to be handled on a case-by-case basis. > In fact, I would go as far on this, as to say that if IE required the > implementation of a set of browser sensing routines, and a set of dynamic > alterations to pages, we should do that extra work necessary to make the > software work with it. Ok-- here is the technical problem: SL used <input type="sumbit"> elements to submit forms. The problem with this approach is that the displayed value on the button is submitted back to the web server. Hence when you translate what is displayed, you change what is submitted back to the server. SL handles this by maintaining 2 translation lists for every module-- one for the strings, and one for back-translating button names. If these get out of sync, you get errors in the application. In order to prevent problems, we moved to a standard format for translation files (.po files), moved to <button type="submit"> elements and thus eliminated the need for back-translation. This results in more robust software. The chief advantage of button elements is that the submitted and displayed values are supposed to be separate. I.e. one writes <button type="submit" value="save_entity">Save</button> and it displayes "Save" but submits back "save_entity." In this way we can translate just the labels. And most browsers work fine. IE is an exception. In IE6, when a button is clicked, it submits *all* button labels to the web server. Consequently, we don't have a way to determine what the user was actually trying to do as long as we use <button> elements, and it also submits the wrong data (the translated label instead of the submission value). In IE7, it submits only one button, but submits the lable instead f the correct value. Saying "we will fully support IE6 and above" thus doesn't just volunteer the core team for a *lot* of extra work but also impacts translators. In all fairness, I don't see that happening. This isn't a political decision-- it is based solely on maintainability of the software and translations. If Dojo allows for support, then this is still limited support and it would not be fully supported even there. > > If we want to advance the cause of open source, by saying that "we are > just as good as, if not better than, the big proprietary guys", then we > have to make certain compromises. We are trying to force a paradigm > shift, and that means that some times we are going to have to bend now, in > order to gain ground, knowing that the ends justify the means. > > More later--I think that's a Stallmanian OSS purist hit squad at my door, > to explain why compromising is a bad idea. Compromising on what? This isn't ideological. It is a technical problem. Microsoft has addressed the technical problem so I expect IE8 can be fully supported. I don't foresee doing a lot of work to support earlier versions though given the maintainability cost. Best WIshes, Chris Travers ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ledger-smb-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
