Re: Interesting coverage of our project on the SQL-Ledger-users list

["Chris Travers" <..hidden..>]

On Wed, Jun 11, 2008 at 1:27 PM, Luke <..hidden..> wrote:

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

I would be interested to see how this can be done (given the technical
issues I mentioned before) without breaking localization.  Javascript
is the only option I see and I am concerned that if we just rely on
Javascript that accessibility can become harder (ok, screen reader is
going, another part of the page updates, how does that impact things?)
and hence I tend to argue that we need to be able to operate without
Javascript and AJAX.

Now, if we say "IE is partially supported" that is one thing.  However
I woud wonder how many of the concerns will continue to be raised as
long as IE only receives second-class support.  Furthermore if you
don't do an AJAX option, the Javascript will start to look very clumsy
(buttons changing when clicked, etc).  In that case, IE would be
unpleasent to use in this case.

I am not closed to suggestions relating to IE support, but I would
want to see a technical proposal on the matter that we can discuss and
I don't have any bright ideas which could be used to give full support
to IE without forcing backwards-translation lookups or Javascript
support.

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

Is it worth the maintenance effort for a browser that will go away
probably sooner rather than later?

I have written patches to support some screens on PocketIE (which is
also broken) using browser detection.  However, this really is not
going to be pleasent regarding long-term maintenance, and I get to
ignore i18n issues with these patches because they are only for one
customer.

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

Again, if there is a nice, elegant technical option, I am all for
this.  However I don't see one which doesn't break things pre-IE8.

If someone has a proposal and wants to undertake some of the work, I
am happy to provide assistance and probably even help with the coding.

However, I would suggest that positioning the application as "partial
support" on IE would be worse than advertising no support.  I think if
we offered partial (for example, JS only) support for IE, I would
suggest we leave it as officially unsupported and rely on word of
mouth to clarify that.

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

Ok.  Misunderstanding here.

>
> Let us clarify: is the button issue the only one known with IE6 or IE7?

It is the only major showstopper.  There may be other issues but if
that was resolved, I would be open to accepting bug reports.

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

The major problem at the moment is that to my knowledge there isn't an
easy technical compromise out there that I am aware of.

One of the issues I see is a definition of supported. I would rather
suggest that all bug reports will be seen as valid, and that there are
no portions or criteria which are unsupported (this means that a no-JS
interface must continue to work).  Maintaining a compatibility matrix
("IE7 only works if you have JS enabled or if you are in the English
translation, and there the following features don't work") seems to me
to be a bad thing.
>
> 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.

XUL/Prism should be pretty easy to bootstrap onto the architecture we
are going for in 1.3.  Note that for IE users, people could still
build solutions that work on IE7 using LSMB, but this would not be
there out of the box.

Best Wishes,
Chris Travers