MAC Safari compatibility problem 2

[Simon Wigzell]

document.[Form Name].[Field Name].focus() will scroll the form to move the
specified text field into view on everything I have tried it with except
Safari on the MAC. The form doesn't move. Any work around? Thanks.

[VK]

Simon Wigzell wrote:

document.[Form Name].[Field Name].focus() will scroll the form to move the
specified text field into view on everything I have tried it with except
Safari on the MAC. The form doesn't move. Any work around? Thanks.

Go to <http://www.caminobrowser.org> and get yourselve a Browser (not a
buggy HTML renderer). Advise the same to your visitors is they are
still suffering under Safari.

P.S. window object has (had?) .scroll, .scrollBy and .scrollTo methods.
Try these -but I would not hold my breath on it.

P.P.S. Usually on Safari everything either doesn't work at all or it
works in the least expected way. If you are determined to bring this
stuff to life no matter what, you may want to summarize all glitches
first - otherwise we'll come to "MAC Safari compatibility problem 122"
post rather soon ;-)

[Simon Wigzell]

"VK" <sc**********@yahoo.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...

Simon Wigzell wrote:

document.[Form Name].[Field Name].focus() will scroll the form to move
the
specified text field into view on everything I have tried it with except
Safari on the MAC. The form doesn't move. Any work around? Thanks.

Go to <http://www.caminobrowser.org> and get yourselve a Browser (not a
buggy HTML renderer). Advise the same to your visitors is they are
still suffering under Safari.

P.S. window object has (had?) .scroll, .scrollBy and .scrollTo methods.
Try these -but I would not hold my breath on it.

P.P.S. Usually on Safari everything either doesn't work at all or it
works in the least expected way. If you are determined to bring this
stuff to life no matter what, you may want to summarize all glitches
first - otherwise we'll come to "MAC Safari compatibility problem 122"
post rather soon ;-)

That bad is it? Geez! We just put in a check for IE on the MAC to just
diallow it and told them to use Safari instead. I've never even heard of
Camino. Is that now the accepted browser for the MAC? Is that what most MAC
users are now using? I've been a PC man for 20 years not out of any love for
Microsoft but because PCs always had the vast majority of the market and I
wanted to be compatible with the majority of the market. And all these years
I've been hearing how wonderfull the MAC is and now it looks like the stupid
thing doesn't even have agreement on a browser than works.

[VK]

Simon Wigzell wrote:

document.[Form Name].[Field Name].focus() will scroll the form to move the
specified text field into view on everything I have tried it with except
Safari on the MAC. The form doesn't move. Any work around? Thanks.

Go to <http://www.caminobrowser.org> and get yourselve a Browser (not a
buggy HTML renderer). Advise the same to your visitors is they are
still suffering under Safari.

P.S. window object has (had?) .scroll, .scrollBy and .scrollTo methods.
Try these -but I would not hold my breath on it. Usually on Safari
everything either doesn't work or it works not as expected.

[VK]

Simon Wigzell wrote:

That bad is it? Geez! We just put in a check for IE on the MAC to just
diallow it and told them to use Safari instead.
The latest IE for Mac is 5.2, and it's support is officially
discontinued by Microsoft a while ago. So it is indeed something to
forget.

How bad Safari is? It is not a security hole or something that crashes
your computer etc., no. But my personal experience you have two options
only with Safari: either you spit on it and hope that your solution
will be still semi-functional; or you hire a whole separate department
only to port each and every of solutions for Safari only. As I said,
too many features are missing - and too many features are implemented
in ...strange... way.
I've never even heard of
Camino.
Camino 1.0 is the same Firefox 1.5 but for Mac OS: the same features
and the same standards - made by the same organization. The only (but
huge) difference is that Camino is written as a native Mac OS
application and uses the same Cocoa graphics. These were the majore
problems with Firefox for Mac:
1) too long startup
2) lesser performance as compared with the native applications.
3) too "functional" interface.
I would guess that the latter was even the biggest problem. Many Mac
users are kind of... say... artistic natures and spoiled by the Mac
fine-tune design care: aqua, transparencies, gradients, bluring,
blah-blah :-) In such surrounding Firefox (despite any themes) was
looking like a plain-vanilla hammer in a fine art boutique. :-)

Camino was in testing for several years, but until the official release
(1.0) it was difficult to suggest it. Now: welcome to
<http://www.caminobrowser.org> And it's free - unlike Safari (OK, you
don't pay for the browser itself, but you have to pay for the OS
upgrade to get a half-descent version of this browser).
Is that now the accepted browser for the MAC? Is that what most MAC
users are now using?
Mas OS didn't have special browser for the longest time, and when it
first appeared (Safari) it happened to be a junk for several versions
in the row. So Mac OS users have everything one may imagine from
wherever they could get it, even Netscape 4.x for Mac
The question is what are you ready to support without wasting your
time and money? I told you my opinion, but it's my opinion.
I've been a PC man for 20 years not out of any love for
Microsoft but because PCs always had the vast majority of the market and I
wanted to be compatible with the majority of the market.

I wouldn't count that Microsoft will ever port again Internet Explorer
on any platform besides Windows. So you have to support standards
(Firefox and Camino) and IE - lucky it seems getting closer and closer
every year, at least in the most important aspects (XML, XSLT, XPath,
XMLHttpRequest, behaviors and so on).

[Simon Wigzell]

<snip>

Thanks, I have installed Camino and it doesn't have any of the flaky
behaviour of Safari so I'm sold on it.

Thanks for all your comments. I will be forwarding them to my client to back
up my susggestion that we throw safari into the same garbage heap with the
nasty MAC IE.

[VK]

Simon Wigzell wrote:

Thanks, I have installed Camino and it doesn't have any of the flaky
behaviour of Safari so I'm sold on it.
Good deal! :-)
Thanks for all your comments. I will be forwarding them to my client to back
up my susggestion that we throw safari into the same garbage heap with the
nasty MAC IE.

Right.
Full disclosure: Camino is made with a big care and after long
throughout testing - but not by Gods (like any software though). In
case of any problems - or to request a new feature - do not neglect
<https://bugzilla.mozilla.org/enter_bug.cgi?format=guided&product=Camino>

Good luck!

[RobG]

VK wrote:

Simon Wigzell wrote:

document.[Form Name].[Field Name].focus() will scroll the form to move the
specified text field into view on everything I have tried it with except
Safari on the MAC. The form doesn't move. Any work around? Thanks.

It works for me in version 1.0.3 (OS X 10.2.8). What version are you using?

<input type="button" value="focus on fred"
onclick="document.sue.fred.focus();">

<div style="height: 100em;">&nbsp;</div>

<form name="sue" action="">
<input id="fred" value="I'm fred">
</form>

Go to <http://www.caminobrowser.org> and get yourselve a Browser (not a
buggy HTML renderer). Advise the same to your visitors is they are
still suffering under Safari.
Perhaps you should test in Safari to see if the OP has a case. There is no
code shown and the functionality works in an old version of Safari (1.0.3),
I can't test in a newer one until later.

There were issues with Safari and focus() in older versions than 1.0.3.

P.S. window object has (had?) .scroll, .scrollBy and .scrollTo methods.
Try these -but I would not hold my breath on it.
Care to point out where any of those are described in a W3C specification?

P.P.S. Usually on Safari everything either doesn't work at all or it
works in the least expected way. If you are determined to bring this
stuff to life no matter what, you may want to summarize all glitches
first - otherwise we'll come to "MAC Safari compatibility problem 122"
post rather soon ;-)

Safari has it's problems for sure, but likely no more than other browsers.
It is generally pretty good for standards compliance.
--
Rob

[RobG]

Simon Wigzell said on 11/04/2006 6:28 AM AEST:

<snip>

Thanks, I have installed Camino and it doesn't have any of the flaky
behaviour of Safari so I'm sold on it.

Thanks for all your comments. I will be forwarding them to my client to back
up my susggestion that we throw safari into the same garbage heap with the
nasty MAC IE.

Don't be surprised if your client is as receptive as if you'd said dump
IE on Windows and install Firefox.

I don't particularly like Camino (just personal preference), you might
like to try OmniWeb too. I used version 4 until Safari became useful,
version 5 is better than Firefox (I was too lousy to buy a licence at
USD29.95 but I'm reconsidering).

<URL:http://www.omnigroup.com/applications/omniweb/>
If you include Safari in your development and test environments, you'll
quickly learn its foibles and to work with them. Overall, I don't think
it has any more scripting eccentricities than IE (but different ones) -
though it probably has more than Firefox.
--
Rob
Group FAQ: <URL:http://www.jibbering.com/FAQ>

[VK]

RobG wrote:

Safari has it's problems for sure, but likely no more than other browsers.
It is generally pretty good for standards compliance.

We must be happened to test on Safari's from parallel universes :-)

But you are right that Camino is not the *only* choice for Mac users -
but I never said that. There is OmniWeb
<http://www.omnigroup.com/applications/omniweb/>, there is iCab
<http://www.icab.de/>, there is a whole list here:
<http://darrel.knutson.com/mac/www/browsers.html> (some links are
already dead); if one diggs in public FTP archives it is still possible
to find IE 5.2 for Mac or NN 4.x for Mac.

The problem with OmniWeb and iCab (and many others) is the fee. There
is a noticeable difference between to say "go download a newer browser"
and "go buy a newer browser". The first is my holly right I reserve to
use; the second is kinda users' monetary business I'm hesitating to
implore.

And the universal problem with all Co is that as of the year 2006 there
is a big difference between Browsers and HTML Renderers. The latter
ones may have better or worser interfaces, render HTML by W3C or by
their own etc. But it does not promote them into Browsers - thus into
something one can cover by support without having a separate
development unit or by switching onto lower-level solution model.

I'm willing to change my mind about OmniWeb though: if you visit
<http://www.geocities.com/schools_ring/test.xml> and tell me that you
see a formatted table with misic collection. It doesn't make OmniWeb
free of course, but at least I'm ready to talk about it as of a
browser.

If you see a jagged XML source text instead, then the question is over,
I'm affraid.

[VK]

RobG wrote:

Safari has it's problems for sure, but likely no more than other browsers.
It is generally pretty good for standards compliance.

We must be happened to test on Safari's from parallel universes :-)

But you are right that Camino is not the *only* choice for Mac users -
but I never said that. There is OmniWeb
<http://www.omnigroup.com/applications/omniweb/>, there is iCab
<http://www.icab.de/>, there is a whole list here:
<http://darrel.knutson.com/mac/www/browsers.html> (some links are
already dead); if one diggs in public FTP archives it is still possible
to find IE 5.2 for Mac or NN 4.x for Mac.

The problem with OmniWeb and iCab (and many others) is the fee. There
is a noticeable difference between to say "go download a newer browser"
and "go buy a newer browser". The first is my holly right I reserve to
use; the second is kinda users' monetary business I'm hesitating to
implore.

And the universal problem with all Co is that as of the year 2006 there
is a big difference between Browsers and HTML Renderers. The latter
ones may have better or worser interfaces, render HTML by W3C or by
their own etc. But it does not promote them into Browsers - thus into
something one can cover by support without having a separate
development unit or by switching onto lower-level solution model.

I'm willing to change my mind about OmniWeb though: if you visit
<http://www.geocities.com/schools_ring/test.xml> and tell me that you
see a formatted table with misic collection. It doesn't make OmniWeb
free of course, but at least I'm ready to talk about it as of a
browser.

If you see a jagged XML source text instead, then the question is over,
I'm affraid.
P.S. Does it mean that I'm excluding current Opera from the list?
Sorry, but partially true. This browser failed too much behind the
trends. I'm waiting to see the v.9 but I do not put too much of hope on
it. In the new Opera's marketing model they seem moving to thin and
ultra-thin clients: something like WORA for the Web. So they seem be
targeted not to new technologies support, but ensure that the very same
solution would be equally functional on a fat client (desktop PC),
palmtop and web-enabled cell-phone.

[Lasse Reichstein Nielsen]

"VK" <sc**********@yahoo.com> writes:

RobG wrote:

Safari has it's problems for sure, but likely no more than other browsers.
It is generally pretty good for standards compliance.

We must be happened to test on Safari's from parallel universes :-)

Without actually having access to one, the impression I get from reading
about Safari problems is that its standard compliance is a little lacking
the behind Opera and Mozilla based browsers. It might not have more bugs,
but they are in more central parts. I also get the impression that they
are continuously improving.

(A saying from my course on programming large systems: "The number of bugs
in a large system is constant over time" - bugfixes just move them further
out into obscure corners where they are less likely to cause trouble).

(And even if you discount Opera for your uses, some of us swear to it -
and it is free :)
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Thomas 'PointedEars' Lahn]

VK wrote:

[the same thing twice again, with Google Groups]

Go to <http://www.caminobrowser.org> and get yourselve a Browser
(not a buggy HTML renderer).
Go to <URL:http://www.mozilla.com/thunderbird/> and get
yourself a newsreader (not a buggy Web-to-NNTP interface).
[rest of VK nonsense moved to /dev/null, where it belongs]

PointedEars

[RobG]

VK wrote:

RobG wrote:

Safari has it's problems for sure, but likely no more than other browsers.
It is generally pretty good for standards compliance.

We must be happened to test on Safari's from parallel universes :-)

Most likely. I read the OP's comment, created a test case, tested it in an
old version of Safari (1.0.3 in Mac OS X 10.2.8) and found that the focus
method does indeed work just fine.

You, on the other hand, simply made assertions and generalisations without
a shred of evidence.

But you are right that Camino is not the *only* choice for Mac users -
but I never said that.
And I didn't say you did. I just said that OmniWeb is a good browser, and
also pointed out that it costs.

[...] The problem with OmniWeb and iCab (and many others) is the fee. There
is a noticeable difference between to say "go download a newer browser"
and "go buy a newer browser". The first is my holly right I reserve to
use; the second is kinda users' monetary business I'm hesitating to
implore.
No one is denying your right to use whatever browser you wish, nor did I
suggest OmniWeb as the solution to the OP's non-existent problem. As a
browser, I think it's better than Camino.

And the universal problem with all Co is that as of the year 2006 there
is a big difference between Browsers and HTML Renderers. The latter
ones may have better or worser interfaces, render HTML by W3C or by
their own etc. But it does not promote them into Browsers - thus into
something one can cover by support without having a separate
development unit or by switching onto lower-level solution model.
It has always been that way. Whenever someone has tried to create a
ubiquitous standard that, if supported, would guarantee interoperability
everywhere it has failed to be widely applicable. Browsers have, arguably,
succeeded better than any other GUI platform.

If you only want to support the two most popular browsers and ignore the
rest, fine. Some choose only one, others as many as they can. Ain't
freedom of choice great?

I'm willing to change my mind about OmniWeb though: if you visit
<http://www.geocities.com/schools_ring/test.xml> and tell me that you
see a formatted table with misic collection. It doesn't make OmniWeb
free of course, but at least I'm ready to talk about it as of a
browser.
I don't need to visit that site to see if I like OmniWeb. My test is to
use it for general browsing for a month or so, and try a library of
utilities and functions to see if they work. If it passes all that, I'll
like it.

If you see a jagged XML source text instead, then the question is over,
I'm affraid.

It displays in Safari 2.0.3 (Mac OS X 10.4.5) just like it does in Firefox
1.5.0.1. OmniWeb displays the element content as plain text, but that is
irrelevant in whether I decide to use OmniWeb or not. XML on the web is
something of a novelty, though it may be in serious use for other purposes.

My opinion is that XML is highly overrated as a data transfer medium for
most purposes to which it is put - but that's another argument altogether.
--
Rob

[RobG]

Lasse Reichstein Nielsen wrote:

"VK" <sc**********@yahoo.com> writes:

RobG wrote:

Safari has it's problems for sure, but likely no more than other browsers.
It is generally pretty good for standards compliance.
We must be happened to test on Safari's from parallel universes :-)

Without actually having access to one, the impression I get from reading
about Safari problems is that its standard compliance is a little lacking
the behind Opera and Mozilla based browsers. It might not have more bugs,
but they are in more central parts. I also get the impression that they
are continuously improving.

That's about right. Apple have decided that to get upgrades, you have
to buy a new copy of Mac OS. That annoys me, I'd rather they updated it
independently of the OS for free. Maybe that's why Apple is a
multi-billion dollar business and I get paid by the hour. :-)

(A saying from my course on programming large systems: "The number of bugs
in a large system is constant over time" - bugfixes just move them further
out into obscure corners where they are less likely to cause trouble).

(And even if you discount Opera for your uses, some of us swear to it -
and it is free :)

I haven't tried Opera on Mac for quite a while, just updated to 8.54...
--
Rob

[VK]

Thomas 'PointedEars' Lahn wrote:

[rest of VK nonsense moved to /dev/null, where it belongs]

Love you Pointy,your're giving to c.l.j that spice which gives to the
brewing stuff that kick to be the real sh**.

I mean it's often that you're like that spit in the smoking copper, but
as it never brings down the sh** strength, so you're just fine I say.
;-)

btw I'm on Bodensee once again and I have to say that Schwaben got even
more Schwabisch than they ever were before: but it did not affect the
beer, God thanks.

[Tony]

Lasse Reichstein Nielsen wrote:

"VK" <sc**********@yahoo.com> writes:

RobG wrote:

Safari has it's problems for sure, but likely no more than other browsers.
It is generally pretty good for standards compliance.

We must be happened to test on Safari's from parallel universes :-)

Without actually having access to one, the impression I get from reading
about Safari problems is that its standard compliance is a little lacking
the behind Opera and Mozilla based browsers. It might not have more bugs,
but they are in more central parts. I also get the impression that they
are continuously improving.

From my experience - Safari is painfully standards compliant WRT CSS,
and very ANNOYING WRT JavaScript. I've had some very basic js blow up on
me with Safari that worked fine on all other browsers I tried (sorry, i
can't say what, as I simply don't remember what it was)

It does seem to be getting better, slowly.

[Richard Cornford]

RobG wrote:
<snip>

If you only want to support the two most popular browsers
and ignore the rest, fine. Some choose only one, others
as many as they can. Ain't freedom of choice great?

<snip>

Do you really think VK has a choice? Surely he supports just a couple of
browsers in their default configurations because that is the limit of
his ability? Have you observed the HTML he has been posting recently?
Nobody else jumps through such ludicrous hoops to address such a minor
'issue'.

It doesn't take much observing of those who recommend Internet authoring
for just one or two browser to see that they are incapable of doing any
better themselves, don't want to learn how to do better, and are keen to
encourage others to never attempt more because that way their own sills
won't look obviously deficient.

Richard.

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

It doesn't take much observing of those who recommend Internet authoring
for just one or two browser to see that they are incapable of doing any
better themselves, don't want to learn how to do better, and are keen to
encourage others to never attempt more because that way their own sills
won't look obviously deficient.

D'oh! How do I get this into four lines? ;-)
Regards,
PointedEars

[VK]

VK wrote:

Love you Pointy

Did I actually write this?! I be damned... need to be careful with
Metzkater...

Please sign off as a momentary weakness of a Bud water victim.

:-)

[VK]

Richard Cornford wrote:

It doesn't take much observing of those who recommend Internet authoring
for just one or two browser to see that they are incapable of doing any
better themselves, don't want to learn how to do better, and are keen to
encourage others to never attempt more because that way their own sills
won't look obviously deficient.

First of all let's us clarify the situation, as you seem masterly
substituted the subject: 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).

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.
No one browser I'm aware of is "simply not functional" - so one could
make an easy choice of dropping it. It is always these subtle small
nasty details here and there like in the OP's case.

And this brings the old question: how many riders (browsers) one horse
(developer) can hold. 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. So Google team are lazy
bastards? Not at all if we remember that this very code was tested for
Firefox, Netscape, IE - on a great number of different versions. Opera
7 simply did not get its ticket in the line.
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. 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..."

I'm sorry, but the horse can hold only so many riders. 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.

[Michael Winter]

On 12/04/2006 11:55, VK wrote:

Richard Cornford wrote:
Why did you respond to Thomas, only to quote Richard?

[snip]
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.

Rubbish. Opera 7.0 works rather nicely with GMail, thank you very much.
So does Opera 6.0, for that matter, though you have to disable scripting
(a lack of feature detection and defensive programming - basic
principles - seems to be the reason).

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[VK]

Michael Winter wrote:

On 12/04/2006 11:55, VK wrote:

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.

Rubbish. Opera 7.0 works rather nicely with GMail, thank you very much.
So does Opera 6.0, for that matter, though you have to disable scripting
(a lack of feature detection and defensive programming - basic
principles - seems to be the reason).

I had in my mind this article:
<http://www.scss.com.au/family/andrew/opera/gmail/> You may discuss the
issue with the blog's author.

For me the principal was not a particular issue with a particular
browser.
I wanted to illustrate my thesis about "an UA without ticket". It is
not (or it least it may not be) important how small the needed change
is: you don't have a ticket - you don't get into train. And btw the
whole idea to mesure the support complexity by the amount of keystokes
is totally wrong IMHO. One need to find out first *what* and *where* to
type in; one line of code may be the result of long expensive testing
and thinking.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

It doesn't take much observing of those who recommend
Internet authoring for just one or two browser to see
that they are incapable of doing any better themselves,
don't want to learn how to do better, and are keen to
encourage others to never attempt more because that way
their own sills won't look obviously deficient.

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.

[Michael Winter]

On 12/04/2006 13:19, VK wrote:

Michael Winter wrote:
[snip]

Rubbish. Opera 7.0 works rather nicely with GMail, thank you very much.

[snip]
I had in my mind this article:
<http://www.scss.com.au/family/andrew/opera/gmail/> You may discuss the
issue with the blog's author.
Why? That entry is over a year old, and hardly relevant now (whether it
was wrong at the time, or not).
For me the principal was not a particular issue with a particular
browser.
True. Over time, you've demonstrated a disregard for several browsers.
I wanted to illustrate my thesis about "an UA without ticket".
So you choose incompetence (Google's, in this case, not that of a user
agent) as an argument against the possibility of writing cross-browser
code? That you, Google, Microsoft, or anyone else is incapable of
writing decent code does not mean that everyone else is limited to the
same fate.
It is not (or it least it may not be) important how small the needed
change is: you don't have a ticket - you don't get into train.

And as Richard pointed out, if there's no chance of 'issuing the
ticket', that's hardly surprising. Browser detection is a fine way of
limiting one's options.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[VK]

Richard Cornford wrote:

Safari is a W3C standard browser, yet you would rather dismiss it,
apparently on the grounds that you cannot cope with authoring for it.
You are again switching the subject: - and by that I mean not going off
topic, but by putting some statements into opponent mouth which he did
not say - just to easily dismiss it. Is it just you or some British
rhethoric trick?

I did not say "dismiss" - I said skip on separate testing to catch
particular browser bugs and misbehaviors. If Safari indeed W3C
compliant, then the same solution made for Firefox will be just fine
for Safari either. If it is not, then Safari is not W3C standard - at
least not up to the necessary level. In this case it needs separate
testing and adjustment - and it did not get the right for it yet; at
least not in my list (which is not necessary your list).

<snip>

The rest is rather boring and doesn't add anything substantial to the
subject. Anyone is entitled on anything she wants. You are welcome to
install 99 browsers on your computer and debug on all of them. No one
employer in good sanity will let you do it; but at your spare time on
your own machines you are the king.
P.S. 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?

Is it the most important matter bothering you in this thread? If it is,
then please start a new thread or branch with a new subject. Starting a
post with a long OT passage is misleading for future potential readers.

As I know by now at least two people dying to know this secret, my
humanity oligations require me to answer: there was one opponent's
opinion sustained by another (see the Thomas' post about dev/null in
this thread). Rather than post it twice, I simply continued the branch
where both opponents were presented - and where the opinion was
expressed in the most clear form.

[Tony]

Michael Winter wrote:

(a lack of feature detection and defensive programming - basic
principles - seems to be the reason).

LOL - I remember not long ago being told that good programmers didn't
use defensive programming...

[Michael Winter]

On 12/04/2006 18:58, Tony wrote:

Michael Winter wrote:

(a lack of feature detection and defensive programming - basic
principles - seems to be the reason).

LOL - I remember not long ago being told that good programmers didn't
use defensive programming...

I hope you didn't agree with that statement.

One should assume that calls that can fail always succeed? Incoming data
from the user should never be sanitised and validated? Yes, those
certainly are signs of a good programmer.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Simon Wigzell]

"Simon Wigzell" <si**********@shaw.ca> wrote in message
news:FPv_f.13760$_u1.10639@pd7tw2no...

document.[Form Name].[Field Name].focus() will scroll the form to move the
specified text field into view on everything I have tried it with except
Safari on the MAC. The form doesn't move. Any work around? Thanks.

Thanks for the long discussion. My original post should have been more
specific - focus on MAC Safari does work if it is set to a text field but
not to a radio box or select field. The workaround I am using is to create a
dummy text field with width and border set to 0 so it is invisible and give
it a name like [FieldName]Focus and then set the focus to that.

I would rather be spending my time developing the system but instead I have
to go back and spend quite a few hours doing this in several forms. We have
decided that we must support Safari as it is the most popular MAC browser
and a majoriy of my client's customers use MACs because they are in the
print industry and congress passed a law long ago that anyone using their
computer for anything artisitic must use a MAC. *shrug*. Personally I hate
the damn things. I still can't figure out how to change the system date on
mine - it thinks it is 2007. If only we were a communist society and there
was just one browser and one OS. That would certainly make my job easier,
though it wouldn't be as much fun with only 32 K of RAM and punch cards to
program : (

[VK]

Simon Wigzell wrote:

We have
decided that we must support Safari as it is the most popular MAC browser.
Do you have a statistic to support this statement? On my California
based servers average of all Mac users (all Mac OS) is 6%, while
average of Safari is 0.4% Something doesn't match here. ;-)

By highly biased stats of my "Array and Hash" article
<http://www.geocities.com/schools_ring/ArrayAndHash.html>
Mac OS users constutute 13.27% while Safari has only 0.83%

I call the above stats as "highly biased" because I did no mention this
article anywhere but in this newsgroup, so the main part of traffic
(2,2007 hits by now) came from this group, there the variety of system
and browsers is much higher then on an average server (because there
are a lot of developers having many browsers installed at once). Say
IE's of all versions got only humble 23.49% - which is definitely not
the real situation as it is right now. In this aspect the demonstated
Mac OS / Safari discrepancy gets even more interesting. It means that
the overhalming majority of Mac OS-based group visitors prefer
something else than Safari for the conventional browsing: despite
they'd like to point in writting the Safari's advantages.
and a majoriy of my client's customers use MACs because they are in the
print industry and congress passed a law long ago that anyone using their
computer for anything artisitic must use a MAC.
Did Congress also pass the law that any Mac OS user is obligated to use
Safari? I do not recall such one :-)

I do recall another law though about UA's free choice and about forcing
a particular UA onto particular OS users. That law nearly costed the
existence to one well known company.
But I'm affraid the US are getting socialistic too: while the big ones
are getting in full from the law, the small ones (or pretending to be
such) may count on law exempts.
If only we were a communist society and there
was just one browser and one OS.

Then most probably you wouldn't have to worry about scripting, DOM,
XMLHtpRequest and many other things - because they would simply do not
exist. The progress in Web so far was going not out of abstract love to
the humanity, but as a result of fighting for customers' preferences.
If you are the only one, then you don't need to fight, because no one
has a choice but your solution, however good or bad it is.

Having said all this: you may have all rights and more than substantial
reasons to support Safari and ask for help in this group. As a
suggestion I would propose though to decide what Safari versions will
you support. Say Safari 1.0 and Safari 2.0 are nearly two completely
different browsers (where the first one is barely usable). Their
features and bugs are too different to be covered by one "Safari fix".

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

Safari is a W3C standard browser, yet you would rather
dismiss it, apparently on the grounds that you cannot cope
with authoring for it.
You are again switching the subject: - and by that I mean not
going off topic, but by putting some statements into opponent
mouth which he did not say - just to easily dismiss it. Is it
just you or some British rhethoric trick?

You are describing a rhetorical construct know as the "straw man", and
it is not exclusively British, or restricted to the English language.
I did not say "dismiss" - I said skip on separate testing to
catch particular browser bugs and misbehaviors.
And it may be precisely because you say things like "skip on separate
testing to catch particular browser bugs and misbehaviors" that you are
likely to be misunderstood, as it is a long way form being a well-formed
and grammatical statement in English.

But you said "Go to <http://www.caminobrowser.org> and get yourselve a
Browser (not a buggy HTML rendered). Advise the same to your visitors is
they are still suffering under Safari" and "But my personal experience
you have two options only with Safari: either you spit on it and hope
that your solution will be still semi-functional; or you hire a whole
separate department only to port each and every of solutions for Safari
only". If that is not dismissing Safari I would have to conclude that
you don't understand the meaning of 'dismiss' either.
If Safari indeed W3C compliant, then the same solution made
for Firefox will be just fine for Safari either.
No, that is a common misconception but Fireforx/Mozilla/Gecko does not
define the W3C standards it just implements them. It is entirely
possible to write Firefox/Gecko specific code that will fail utterly in
other W3C DOM implementations.
If it is not, then Safari is not WC standard - at
least not up to the necessary level.
And who is deciding the 'necessary' level?
In this case it needs separate testing and adjustment - and
it did not get the right for it yet; at least not in my list
(which is not necessary your list).
So you are not dismissing safari, in any sense except refusing to
include it in your list?
<snip>
The rest is rather boring and doesn't add anything substantial
to the subject. <snip>

Yes, keep your head firmly buried in the sand and in ten years time you
will know even less about the subject of browser scripting than you do
now.

<snip> P.S.

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?

And now you are quoting out of context. That is at best disingenuous.
Is it the most important matter bothering you in this thread?
No, I am just wondering why you cannot cope with following the normal
Usenet conventions.
If it is, then please start a new thread or branch with
a new subject.
You are about the last person who should be giving people advice about
how to post to Usenet.
Starting a post with a long OT passage is misleading for
future potential readers.
Not really, the trail of (correctly) quoted material and the message's
References headers will document your misdemeanours.
As I know by now at least two people dying to know this
secret,
People asking you to justify manifest incompetence should not be
unexpected.
my humanity oligations require me to answer:
"humanity oligations"?
there was one opponent's opinion sustained by another
(see the Thomas' post about dev/null in this thread).
Rather than post it twice, I simply continued the branch
where both opponents were presented
You silly sod.
- and where the opinion was
expressed in the most clear form.

Obviously not as you edited Thomas' comments out entirely.

Still, I got the answer to my question; the ineptness way yours
personally not the result of using news reader software that would not
let you get it right.

Richard.

[VK]

Richard Cornford wrote:

So you are not dismissing safari, in any sense except refusing to
include it in your list?

I do not dismiss Safari: I do not produce solutions which would sniff
for particular browsers just to ban them. So Safari users do not have
to spoof their UA strings to get onto my pages. And Safari makers do
not have to add bogus "feature placeholders" to get onto my pages.
Everyone is welcome - no one is dismissed.

But I do deny from Safari the right for the additional care - thus for
a separate adjustments just to satisfy this particular browser's bugs
and misbehavior. It did not make its part of path yet IMHO.

P.S. What bugs me too that starting Safari 1.0 - which was by all means
just half of a browser or less - it has "Report broken site" button and
*that one* works just fine from the very beginning. Such an easy
solution one found: to make a half-a** done ugly bastard, but in case
if:- "it is not our fault, this is the page author was to lazy to spend
10min, 1hr, 3 days to make all necessary adjustment for our mutant. Bad
boy! Here is the button - press it!".

[Michael Winter]

On 12/04/2006 18:34, VK wrote:

Richard Cornford wrote:

Safari is a W3C standard browser, yet you would rather dismiss it,
apparently on the grounds that you cannot cope with authoring for
it.
You are again switching the subject: - and by that I mean not going
off topic, but by putting some statements into opponent mouth which
he did not say - just to easily dismiss it.

So, you didn't write:

Go to <http://www.caminobrowser.org> and get yourselve a
Browser (not a buggy HTML renderer). Advise the same to your
visitors is they are still suffering under Safari.

nor:

Usually on Safari everything either doesn't work at all or it
works in the least expected way.

That seems like dismissal to me; you'd rather put it out of your mind.

[snip]
If Safari indeed W3C compliant, then the same solution made for
Firefox will be just fine for Safari either.
Not true. Opera is a browser that implements the W3C DOM very well[1], and

var stylesheets = document.styleSheets;

for (var i = 0, n = stylesheets.length; i < n; ++i) {
var sheet = stylesheets[i];

/* Do something with style sheet object */
}

is some arbitrary code that will work just fine in Firefox. However, it
will error out in Opera.
If it is not, then Safari is not W3C standard
If you define "W3C standard" in terms of DOM conformance, not even
Firefox is entirely so, so the point isn't worthy of debate. I don't
believe that any browser implements all modules completely, though some
may implement certain modules (like Core) to a degree that warrants the
label 'conforming'.

Safari implements methods and properties defined in W3C Recommendations,
as do other browsers. Safari does not implement all of them, just like
other browsers.
at least not up to the necessary level.
The 'necessary level' will vary on a script-by-script basis, and scripts
- through the well-known mechanism of feature detection - can evaluate
the extent to which it can function in a particular environment. If host
support is not sufficient and it is appropriate, the script can
gracefully degrade as and when required.

But you should already know that.

[snip]

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?

[snip]
As I know by now at least two people dying to know this secret [...]

I very much doubt that /anyone/ cares why you can't manage to post a
follow-up properly. However, there are some that wish you'd make an
effort to rectify it. It's not like you're new to Usenet.

If you are only replying to comments made by Richard (and Richard's were
the only comments quoted), then reply to Richard's post.

[snip]

Mike
[1] Though I did file one complaint to the opera.tech newsgroup
about behaviour that makes feature detection difficult
without resorting to exception handling.

<du**********@news.opera.com>

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Thomas 'PointedEars' Lahn]

VK wrote:

Simon Wigzell wrote:

We have decided that we must support Safari as it is the most popular MAC
browser.
Do you have a statistic to support this statement?

YMMD.
On my California based servers average of all Mac users (all Mac OS) is
6%, while average of Safari is 0.4% Something doesn't match here. ;-)

By highly biased stats of my "Array and Hash" article
<http://www.geocities.com/schools_ring/ArrayAndHash.html>
Mac OS users constutute 13.27% while Safari has only 0.83%

And even if your numbers were right[1] and would matter, they were not going
to change, unless you changed your approach. You are still confusing cause
and effect. (The fact aside that your article is still factually wrong,
and therefore not worth reading at all.)
PointedEars
___________
[1] <URL:http://pointedears.de/scripts/test/whatami>

[RobG]

Simon Wigzell wrote:

"Simon Wigzell" <si**********@shaw.ca> wrote in message
news:FPv_f.13760$_u1.10639@pd7tw2no...

document.[Form Name].[Field Name].focus() will scroll the form to move the
specified text field into view on everything I have tried it with except
Safari on the MAC. The form doesn't move. Any work around? Thanks.

Thanks for the long discussion. My original post should have been more
specific - focus on MAC Safari does work if it is set to a text field but
not to a radio box or select field.

That depends on the version you are using. I just tested Safari 1.3.2
(OS X 10.3) and 2.0.3 (OS X 10.4) and it works fine on radio buttons,
selects, whatever. The last version it didn't work on is Safari 1.0.3
(OS X 10.2).

The workaround I am using is to create a
dummy text field with width and border set to 0 so it is invisible and give
it a name like [FieldName]Focus and then set the focus to that.
Find out how many of your Mac users are still on OS X 10.2 - it's quite
a few years old now (released August 2002), most should have upgraded
to 10.3 (released October 2003). Remember that Safari was first
released in January 2003, it's actually come a long way in a short
time.

I deliberately try to stay on an old version of Safari on the premise
that if I can get stuff to work in an old version, it'll work fine in
the current one. And Firefox still runs fine on OS X 10.2 so I'm set
as far as developing on Mac is concerned.

But I've been spending more and more time with OS X 10.4 - it is just
so much better that 10.2 that I think I'll have to move to it now.
I'll keep a partition with 10.2 on it for old times sake.

I would rather be spending my time developing the system but instead I have
to go back and spend quite a few hours doing this in several forms. We have
decided that we must support Safari as it is the most popular MAC browser
and a majoriy of my client's customers use MACs because they are in the
print industry
I would find out how many are using Mac OS 10.2 and take it from there.
You can pick up OS X 10.3 for about USD30 on eBay, so there's no
reason for your clients not to upgrade - they can always switch to
Firefox (or just not have the scrolling functionality).
print industry and congress passed a law long ago that anyone using their
computer for anything artisitic must use a MAC. *shrug*. Personally I hate
the damn things. I still can't figure out how to change the system date on
mine - it thinks it is 2007.

Go to system preferences, click on 'Date & Time', click on the 'Date &
Time' button. Select 'Set date and time automatically' and it sets the
system clock based on your selection of internet time server. As soon
as the clock updates (a second or two), turn it back off.

If your system clock constantly goes out of sync whenever you shut down
for more than a few minutes, replace the system battery - they last
about 5 years or so, don't cost much and are very simple to replace.
--
RobG