On Wed, 11 Jun 2008, Chris Travers wrote: > 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.
I am all for standardizing on standards (HTML, etc.), and the idea of bending that to fit what M$ requires to work with IE is anathema to me. The only case in which I deem doing so acceptable, is the case wherein we are trying to break a large and entrenched market. I see LSMB as trying to do that. Not right now, necessarily, but in the near future. > Currently IE8 looks like it will be supportable* which is a good thing. But what is the suggested release date? (Recognizing that MS release dates are somewhat malleable) > 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. I was suggesting that, if it can be done in a vacuum (meaning that no internals of the app must change, but only the UI), detecting IE7 (or IE8 in non-standards mode), and having particular UI hooks (javascript, if that's what will do it) to properly rewrite the elements, or just serving a slightly different version of the form, is not unreasonable. You talk about maintainability... My question there would be: how long would this actually have to be maintained? IE7 will eventually go away, and I am choosing to ignore IE6 completely for the sake of this discussion. When it does, with it can go the customization. > 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. I might make the opposite argument: at the moment, there is no great need to support IE7, exactly because this is a niche product. I am looking at this from a post 1.3 prospective. If a significant number of the issues can be worked out while IE7 still represents a sufficiently large segment of the market, adapting to handle it as discussed above, is reasonable in my opinion. Doing so right now, while there are still so many other usability matters on the table, would not be as reasonable, since the potential user base who would also insist on retaining IE, is probably quite low. > > 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. You're right, of course--that was a bad choice of phrasing on my part. I am suggesting that we bend on the IE issue, for one reason and one reason only: its footprint among potential users. > Why should we rearchitect the application to support W3M? Is it > *that* important to support IE6 and 7 fully if IE8 support is there? Only if any one of those represents 40-50% or more of the potential target market, at the time when targeting that market is wise (which it is not currently). I am thinking of the future with my comments that we should add workarounds for IE7--a future which may never exist, depending on the status of IE at the time when a less problematic version of LSMB is available. > 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. I am only talking about IE7, which is, I believe, the most common version installed currently. > This isn't a political decision-- it is based solely on Nor did I think that it might be. Let us clarify: is the button issue the only one known with IE6 or IE7? > >> > 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. (1) That was intended as humor, nothing else; and (2) I was speaking of a technical compromise--in particular, compromising the requirement for standards compliance, enough to support the most commonly installed browser. All of this said, I am fond of the "Install FireFox: it is the client for the accounting app" way of handling this, especially if the Prism idea gains ground. Regards, Luke ------------------------------------------------------------------------- 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
