Why have you posted a follow-up to a message of Thomas' when you appear
to only be responding to a preceding message of mine? Is your Usenet
interface so poor that you cannot respond to the correct message? Or is
it you?
First of all let's us clarify the situation,
You and clarify in the same 'sentence'? That is an oxymoron.
as you seem masterly substituted the subject:
You seem to place an inappropriate significance upon the subject headers
of Usenet posts. Whatever the OP may consider a suitable subject for the
initial post has no baring on where any subsequent discussion may
wander. So long as that discussion is on-topic for the group.
it is not about supporting "two browsers only". It is about
supporting the W3C standards (Firefox, Camino) and supporting
the browser being in the widest use at the current segment of
time (IE for now).
Safari is a W3C standard browser, yet you would rather dismiss it,
apparently on the grounds that you cannot cope with authoring for it.
This is the "must" - as opposed to "may". You may support
any amount of browsers you can squeeze into your time and
funds: 2, 3 or 33 and more.
And that is why you cannot cope with more than a couple of browsers in
their default configuration. You are thinking of cross-browser authoring
as an additive process where you start with writing for one browser and
then add support for others. In reality this is merle multi-browser
scripting at best. If you do it that way the time taken, and the
consequent expense, will be proportional to the number of browsers
supported (and the result will fall over whenever it encounters a
browser/configuration outside of the specific test-set). It is also a
strategy that will accumulate complexity as it goes along, degrade
performance and multiply maintenance costs.
However, as you have been told repeatedly, cross-browser scripting is
largely a matter of deigning a system to be cross-browser, implementing
it once, and then testing and debugging to verify/ensure that it
actually does behave as designed. It is one finite process with a single
end point where the result is cross browser. And once the author has
accumulated sufficient understanding of how browsers in general handle
scripts it isn't even a process that takes longer than scripting support
for a single browser.
But even when facing a situation where the specification requires only
support for IE 6; IE 6 is user configurable software. So without even
considering its release versions, service packs and security updates you
re dealing with a browser that may or may not support ActiveX,
javascript, Java, a small set of otherwise scriptable features (such as
the clipboard), have user style sheets, etc. and runs on a user
configurable OS where the dimensions of borders, scrollbars, etc. the
menus, tool buttons, etc and much else that may impact upon DHTML
scripting is variable in a way that undermines entire classes of
assumptions.
If you design a system to accommodate the configuration variability of
just that one browser, and so long as the HTML used is not too much
Microsoft style tag-soup and scripts do not attempt to use browser
features without first verifying their availability, you have also
designed a system that pretty much is cross-browser. Because if you have
a system that is viable on script disabled IE you also have a system
that you could present to any other HTML web browser and have a
realistic expectation that the result be just as viable. And that
includes the other dynamic visual browsers along side text browsers and
speaking browsers.
Of course the javascript author wants the flashy scripted GUI
enhancements and time saving HTTP request short circuiting background
functionality to work on as many browsers as are capable of supporting
it, so designing the scripted aspects of the system to depend upon
Microsoft proprietary features is rarely desirable, but that doesn't
mean you cannot use them and not be writing a system that is actually
cross-browser by design.
As recently as two years ago I would read people declaring that it was
only sensible to write for script enabled IE as no sensible user would
consider using anything else (with lots of utterly spurious
justification for that position, to conceal the fact that they were just
reflecting the limit of their ability). This year I am reading those
same individuals declaring that you cannot author for anything but
script enabled IE and Firefox. Why the change, why add Firefox? The
answer is simple; Firefox has received coverage in the popular press
pointing out its growing popularity and this year the clients are
demanding support for it. Things change, and when things change poor
design decisions result in additional costs imposed by the need to
update web sites to accommodate the change, or sits becoming ever less
effective at delivering whatever they were intended to do.
A significant change that I recall was the release of Opera 7. Opera 6
was a barely dynamic browser in which most DHTML scripts would not do
anything useful. Not really a problem as it could do a reasonable job of
rendering HTML and could submit forms to a server. While Opera 7 was a
fully dynamic visual browser with considerable support for W3C DOM
standards. When Opera 7 was released the amount of maintenance that I
needed to perform on scripts written prior to its release was zero;
scripts that had no choice but to fall-back to underlying HTML (+server
scripts) suddenly noticed to new features available in the new browser
and took advantage of them, providing the Opera 7 users with the same
scripted experience as had previously only been available to the users
of the like of Mozilla and IE. So even if cross-browser scripting was
significantly more expensive than writing exclusively for the one or two
browsers that happen to be fashionable at the time (and it is not) the
massive reduction in the ongoing maintenance costs required just to
stand still in a changing Internet would more than compensate in the
long run.
No one browser I'm aware of is "simply not functional" -
so one could make an easy choice of dropping it.
Making a choice to disregard specific browsers is a consequence of a
misguided approach. Once a system is accommodating the configuration
variability in the most common browsers it is viable on any browser that
can render HTML and submit forms.
It is always these subtle small nasty details
here and there like in the OP's case.
The OP has not made a case; his assertion is observed to be false.
And this brings the old question: how many riders (browsers)
one horse (developer) can hold.
That would be the wrong question. The significant question is "is it
possible to design systems that are truly cross-browser and so will be
viable with dam near 100% or possible browsers", and the answer to that
question is demonstrably 'yes'.
You may go on form there to discuss the cost-effectiveness of such a
design; observing that it must maximise returns and then considering the
cost of achieving those returns. But it is important to have the such
considerations assessed by someone who knows how to deliver the results,
as someone who doesn't know how to do something is not qualified to
judge how long it will take or what it would cost (beyond observing that
it would be disproportionally expensive for them to do it as they would
have to expend time and effort in learning how to do it along the way).
I was reading one Opera adept's blog where he was
complaining for GMail support for Opera 7.x Something like "see,
they just had to move it here, this there, add this line - and it
would work":- In summary indeed just few keystrokes.
The very first releases of GMail actually used User Agent string base
browser detection, and that false assumption resulted in their opening
page informing me that I was using Opera and that I would need to switch
to IE if I wanted to use GMail, while I actually was using IE 6 to visit
the page.
So Google team are lazy bastards?
Maybe they are too lazy to learn, or just inept. It is not exactly news
that user agent strings have no baring on client browsers (that is even
formally specified in HTTP 1.1). But google's script authors do appear
to be learning, slowly. At present, on the rare occasions that I visit
google groups IE 6 puts up "'XMLHttpRequest' is undefined' errors. I
know why google's scripts cannot use the ActiveX xml http request object
(I have ActiveX disabled for Internet use) but no competent script
author should then be assuming support for XMLHttpRequest and letting
that poor assumption result in a script erroring-out. It is hardly a
difficult condition to test for.
Not at all if we remember that this very code was
tested for Firefox, Netscape, IE
Not particularly well tested else it would not be so easy to get it to
spit out script errors. Although they are not alone in not testing their
code well as MSDN keeps popping-up "'parentElement.parentElement' is
null or not an object" errors on when I visit it with IE 6 from work. It
is frankly pathetic that Microsoft should employ script authors who
write IE specific code that still errors-out on IE. It is hardly
surprising that their script documentation is so poor.
- on a great number of different versions.
But apparently not many variations of configuration.
Opera 7 simply did not get its ticket in the line.
With user-agent string based browser detection it is not a matter of a
browser gaining a ticket, but instead an author refusing to issue on. A
position that directly resulted in the notion of user-agent string based
browser detection becoming non-viable, because in the face of such
unjustified exclusions browser manufacturers had no choice reduce the
user-agent string to a variable unrelated to the browser with particular
values chosen for no more than expedience.
And it is normal, because no matter how wide your support is,
in the real (not abstract) run there is a point you have to
stop: and very possible that the UA makers you stopped before
will be "upset": "and what about us?" Well, you have to stop
somewhere, so there is always going to be a browser you've
closed the door right in front of.
If that were true there would be no such thing as a cross-browser
script. All you are actually saying here is that your approach to
scripting browsers is such that it can never practically get to the
point of producing a cross-browser script. This is of course true, but
that is just an indication that your approach is wrong. The consequences
of applying a wrong approach have no baring on what may be achieved with
a more suitable approach.
But then you have a habit of using the wrong (even the worst possible)
approach when addressing any issue (including the fictional issues that
pop into your head form time to time).
Let's us add Opera 7... then Opera 6 will be upset; add
Opera 6 - "why you did not check Safari?"; add Safary -
"why you did not fix for OmniWeb - it is so easy, look..."
Yes, that is the wrong approach; time consuming, brittle, unreliable,
maintenance heavy and ultimately incapable of achieving a cross-browser
outcome, just multi-browser scripts where the number of browsers in
'multi' is incremented with effort.
I'm sorry, but the horse can hold only so many riders.
Your horse. What can be achieved, and has been achieved by others is a
matter of record not opinion.
Any wannabe have to fight for its place: and not with
developers, but with other riders. You'll get a noticeable
share of market - you'll get you place. Until then be *exact*
as one of current winners - because no one will give a damn
about you personal bugs. And then become noticeable *better*
in some or many aspects: because to be simply as good as
someone else is not enough - why would anyone switch equal to
equal?
What happened with Opera and GMail btw? Well, current Opera
works just fine - after *Opera* adjusted its engine to be
like one of the winners.
Opera eventually implemented XMLHttpRequest but google also had to
modify its code to recognise the support provided by Opera, when if they
had initially employed the appropriate techniques, that were well known
at the time GMail was created, they could have avoided taking any action
in order to exploit the XMLHttpRequest facility on any browser that came
along with the facility.
Richard.
